|
|
Asymmetric encryption uses a public/private key pair. Data encrypted with the private key can be decrypted only with the corresponding public key and vice versa.
Public keys (as their name suggests) are made generally available. Conversely, a private key remains private to a specific individual. The distribution mechanism by which public keys are transported to users is a certificate. Certificates are normally signed by a certification authority (CA) in order to confirm that the public key is from the subject who claims to have sent the public key. The CA is a mutually trusted entity.
The typical implementation of digital certification involves a process for signing the certificate. The process is shown in Figure 1.
The sequence of events shown in Figure 1 is as follows:
Alice sends a signed certificate request containing her name, her public key, and perhaps some additional information to a CA.
The CA creates a message from Alice’s request. The CA signs the message with its private key, creating a separate signature. The CA returns the message and the signature, to Alice. Together, the message and signature form Alice’s certificate.
Alice sends her certificate to Bob to give him access to her public key.
Bob verifies the certificate’s signature, using the CA’s public key. If the signature proves valid, he accepts the public key in the certificate as Alice’s public key.
As with any digital signature, any receiver with access to the CA’s public key can determine whether a specific CA signed the certificate. This process requires no access to any secret information. The preceding scenario assumes that Bob has access to the CA’s public key. Bob would have access to that key if he has a copy of the CA’s certificate that contains that public key.
X.509 digital certificates include not only a user’s name and public key, but also other information about the user. These certificates are more than stepping stones in a digital hierarchy of trust. They enable the CA to give a certificate’s receiver a means of trusting not only the public key of the certificate’s subject, but also that other information about the certificate’s subject. That other information can include, among other things, an e-mail address, an authorization to sign documents of a given value, or the authorization to become a CA and sign other certificates.
X.509 certificates and many other certificates have a valid time duration. A certificate can expire and no longer be valid. A CA can revoke a certificate for a number of reasons. To handle revocations, a CA maintains and distributes a list of revoked certificates called a Certificate Revocation List (CRL). Network users access the CRL to determine the validity of a certificate.
Certificates are stored in safe locations called a certificate stores. A certificate store can contain certificates, CRLs, and Certificate Trust Lists (CTLs). Each user has a personal store (called the “MY store”) where that user’s certificates are stored. The MY store can be physically implemented in a number of locations including the registry, on a local or remote computer, a disk file, a data base, a directory service, a smart device, or another location.
While any certificate can be stored in the MY store, this store should be reserved for a user’s personal certificates, that is the certificates used for signing and decrypting that particular user’s messages.
In addition to the MY store, Windows also maintains the following certificate stores:
CA and ROOT. This store contains the certificates of certificate authorities that the user trusts to issue certificates to others. A set of trusted CA certificates are supplied with the operating system and others can be added by administrators.
Other. This store contains the certificates of other people to whom the user exchanges signed messages.
The CryptoAPI provides functions to manage certificates. These APIs can be accessed only through unmanaged code. Also, CAPICOM is a COM-based API for the CryptoAPI, which can be accessed via COM Interop.
For more information, see “Cryptography, CryptoAPI, and CAPICOM” on MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/Security/cryptography_cryptoapi_and_capicom.asp).
|
|
