key-index.htm

globus4.0.4中与GSI(Globus Security Infrastructure)相关的文档

  Anyone who knows the private key can easily impersonate the owner. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="s-security-key-digitalsig"></a>2.2.燚igital Signatures </h3></div></div></div><p>Using public key cryptography, it is possible to digitally "sign" a piece
  of information. Signing information essentially means assuring a recipient
  of the information that the information hasn't been tampered with since it
  left your hands. </p><p>To sign a piece of information, first compute a mathematical hash of the information.
  (A hash is a condensed version of the information. The algorithm used to compute
  this hash must be known to the recipient of the information, but it isn't a
  secret.) Using your private key, encrypt the hash, and attach it to the message.
  Make sure that the recipient has your public key. </p><p>To verify that your signed message is authentic, the recipient of the message
  will compute the hash of the message using the same hashing algorithm you used,
  and will then decrypt the encrypted hash that you attached to the message.
  If the newly-computed hash and the decrypted hash match, then it proves that
  you signed the message and that the message has not been changed since you
  signed it. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="s-security-key-certificates"></a>2.3.燙ertificates</h3></div></div></div><p>A central concept in GSI authentication is the <span class="emphasis"><em>certificate</em></span>. Every user and
  service on the Grid is identified via a certificate, which contains information
  vital to identifying and authenticating the user or service.</p><p>A GSI certificate includes four primary pieces of information:</p><div class="itemizedlist"><ul type="disc"><li>A subject name, which identifies the person or object that the certificate
    represents.
  </li><li>The public key belonging to the subject.
  </li><li>The identity of a Certificate Authority (CA) that has signed the certificate
      to certify that the public key and the identity both belong to the subject.
  </li><li>The digital signature of the named CA. </li></ul></div><p>Note that a third party (a CA) is used to certify the link between the public
  key and the subject in the certificate. In order to trust the certificate and
  its contents, the CA's certificate must be trusted. The link between the CA
  and its certificate must be established via some non-cryptographic means, or
  else the system is not trustworthy.</p><p>GSI certificates are encoded in the X.509 certificate format, a standard data
  format for certificates established by the Internet Engineering Task Force
  (IETF). These certificates can be shared with other public key-based software,
  including commercial web browsers from Microsoft and Netscape.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="s-security-key-mutualauthentication"></a>2.4.燤utual Authentication </h3></div></div></div><p>If two parties have certificates, and if both parties trust the CAs that signed
  each other's certificates, then the two parties can prove to each other that
  they are who they say they are. This is known as <span class="emphasis"><em>mutual
  authentication</em></span>. GSI uses the Secure Sockets Layer (SSL) for its mutual authentication protocol,
  which is described <a href="#s-security-key-delegation" target="_top">below</a>. (SSL is also known by a new, IETF standard name:
  Transport Layer Security, or TLS.)</p><p>Before mutual authentication can occur, the parties involved must first trust
  the CAs that signed each other's certificates. In practice, this means that
  they must have copies of the CAs' certificates--which contain the CAs' public
  keys--and that they must trust that these certificates really belong to the
  CAs.</p><p>To mutually authenticate, the first person (<span class="emphasis"><em>A</em></span>) establishes a connection to
the second person (<span class="emphasis"><em>B</em></span>). </p><p>To start the authentication process, <span class="emphasis"><em>A</em></span> gives <span class="emphasis"><em>B</em></span> his certificate. </p><p>The certificate tells <span class="emphasis"><em>B</em></span> who <span class="emphasis"><em>A</em></span> is claiming to be (the identity), what <span class="emphasis"><em>A</em></span>'s
public key is, and what CA is being used to certify the certificate.  </p><p><span class="emphasis"><em>B</em></span> will
      first make sure that the certificate is valid by checking the CA's digital
      signature to make sure that the CA actually signed the certificate and
  that the certificate hasn't been tampered with. (This is where <span class="emphasis"><em>B</em></span> must trust
  the CA that signed <span class="emphasis"><em>A</em></span>'s certificate.) </p><p>Once <span class="emphasis"><em>B</em></span> has checked out <span class="emphasis"><em>A</em></span>'s certificate, <span class="emphasis"><em>B</em></span> must make sure that <span class="emphasis"><em>A</em></span> really is
the person identified in the certificate.  </p><p><span class="emphasis"><em>B</em></span> generates a random message and
sends it to <span class="emphasis"><em>A</em></span>, asking <span class="emphasis"><em>A</em></span> to encrypt it.  </p><p><span class="emphasis"><em>A</em></span> encrypts the message using his private
key, and sends it back to <span class="emphasis"><em>B</em></span>.  </p><p><span class="emphasis"><em>B</em></span> decrypts the message using <span class="emphasis"><em>A</em></span>'s public key. </p><p>If this results in the original random message, then <span class="emphasis"><em>B</em></span> knows that <span class="emphasis"><em>A</em></span>  is who he says he is. </p><p>Now that <span class="emphasis"><em>B</em></span> trusts <span class="emphasis"><em>A</em></span>'s identity, the same operation must happen in reverse. </p><p><span class="emphasis"><em>B</em></span> sends <span class="emphasis"><em>A</em></span> her certificate, <span class="emphasis"><em>A</em></span> validates the certificate and sends a challenge
message to be encrypted.  </p><p><span class="emphasis"><em>B</em></span> encrypts the message and sends it back to <span class="emphasis"><em>A</em></span>, and
<span class="emphasis"><em>A</em></span> decrypts it and compares it with the original. </p><p>If it matches, then <span class="emphasis"><em>A</em></span>  knows that <span class="emphasis"><em>B</em></span> is who she says she is. </p><p>At this point, <span class="emphasis"><em>A</em></span> and <span class="emphasis"><em>B</em></span> have established a connection to each other and are
  certain that they know each others' identities. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="s-security-key-confcommunication"></a>2.5.燙onfidential Communication </h3></div></div></div><p>By default, GSI does not establish confidential (encrypted) communication
  between parties. Once mutual authentication is performed, GSI gets out
  of the way so that communication can occur without the overhead of constant
  encryption and decryption. </p><p>GSI can easily be used to establish a shared key for encryption if confidential
  communication is desired. Recently relaxed United States export laws now allow
  us to include encrypted communication as a standard optional feature of GSI. </p><p>A related security feature is communication integrity. Integrity means that
  an eavesdropper may be able to read communication between two parties but is
  not able to modify the communication in any way. GSI provides communication
  integrity by default. (It can be turned off if desired). Communication integrity
  introduces some overhead in communication, but not as large an overhead as
  encryption. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="s-security-key-securingprivatekeys"></a>2.6.燬ecuring Private Keys </h3></div></div></div><p>The core GSI software provided by the Globus Toolkit expects the user's private
  key to be stored in a file in the local computer's storage. To prevent other
  users of the computer from stealing the private key, the file that contains
  the key is encrypted via a password (also known as a passphrase). To use GSI, the user must enter the passphrase required to decrypt the file containing
  their private key. </p><p>We have also prototyped the use of cryptographic smartcards in conjunction
  with GSI. This allows users to store their private key on a smartcard rather
  than in a file system, making it still more difficult for others to gain access
  to the key. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="s-security-key-delegation"></a>2.7.燚elegation, Single Sign-On and Proxy Certificates </h3></div></div></div><p>GSI provides a delegation capability: an extension of the standard SSL
  protocol which reduces the number of times the user must enter his passphrase.
  If a Grid computation requires that several Grid resources be used (each requiring
  mutual authentication), or if there is a need to have agents (local or remote)
  requesting services on behalf of a user, the need to re-enter the user's passphrase
  can be avoided by creating a <span class="emphasis"><em>proxy</em></span>. </p><p>A proxy consists of a new certificate and a private key. The key
  pair that is used for the proxy, i.e. the public key embedded in the
  certificate and the private key, may either be regenerated for each
  proxy or obtained by other means. The new certificate contains
  the owner's identity, modified slightly to indicate that it is a
  proxy. The new certificate is signed by the owner, rather than a
  CA. (See diagram below.) The certificate also includes a time
  notation after which the proxy should no longer be accepted by
  others. Proxies have limited lifetimes. </p><div class="mediaobject" align="center"><img src="http://www.globus.org/toolkit/docs/4.0/security/key/gssapi1.gif" align="middle" alt="The new certificate is signed by the owner, rather than a CA."></div><p>The proxy's private key must be kept secure, but because the proxy isn't valid
  for very long, it doesn't have to kept quite as secure as the owner's private
  key. It is thus possible to store the proxy's private key in a local storage
  system without being encrypted, as long as the permissions on the file prevent
  anyone else from looking at them easily. Once a proxy is created and stored,
  the user can use the <a href="#proxy-cert" target="_top">proxy certificate</a> and private key for mutual authentication
  without entering a password.</p><p>When proxies are used, the mutual authentication process differs slightly.
  The remote party receives not only the proxy's certificate (signed by the owner),
  but also the owner's certificate. During mutual authentication, the owner's
  public key (obtained from her certificate) is used to validate the signature
  on the proxy certificate. The CA's public key is then used to validate the
  signature on the owner's certificate. This establishes a chain of trust from
  the CA to the proxy through the owner.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="/docbook-images/note.gif"></td><th align="left">Note</th></tr><tr><td align="left" valign="top"><p>GSI, and software based on it (notably the Globus Toolkit, GSI-SSH,
  and GridFTP), is currently the only software which supports the delegation extensions
  to TLS (a.k.a. SSL).   The Globus Alliance has worked in the GGF and the IETF to standardize 
  this extension in the form of Proxy Certificates (RFC 3820) [<a href="http://www.ietf.org/rfc/rfc3820.txt" target="_top">http://www.ietf.org/rfc/rfc3820.txt</a>].</p></td></tr></table></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="s-security-key-relateddocs"></a>3.燫elated Documents</h2></div></div></div><div class="itemizedlist"><ul type="disc"><li><a href="GT4-GSI-Overview.pdf" target="_top">Globus Toolkit Version 4 Grid Security
    Infrastructure: A Standards Perspective</a> </li><li><a href="http://www.cacr.math.uwaterloo.ca/hac/" target="_top">Handbook of Applied
    Cryptography </a></li></ul></div></div><div class="glossary"><div class="titlepage"><div><div><h2 class="title"><a name="id2523258"></a>GT 4.0 Security Glossary</h2></div></div></div><div class="glossdiv"><h3 class="title">C</h3><dl><dt><a name="ca"></a> Certificate Authority ( CA )</dt><dd><p> An entity that issues certificates.</p></dd><dt><a name="ca-cert"></a> CA Certificate</dt><dd><p> The CA's certificate. This certificate is used to verify signature on