The description of the use of digital signatures above leaves open one security question that must be resolved in an infrastructure for secure electronic commerce: How can the verifier obtain the alleged signer’s public key in a way that ensures that the public key is, in fact, that of the signer? Some mechanism is necessary to avoid the scenario of an attacker intercepting the message, rewrapping the plaintext of the message with his own digital signature, and giving the verifier his own public key. The attacker could pass off his own public key as if it were the public key of the intended signer. The verifier, using the attacker’s public key, will find that the public key is able to process the digital signature on the message he received. Moreover, the verifier will think that the message originated with the signer, not the attacker. The verifier needs a mechanism to obtain the public key of the signer in a reliable way to avoid this kind of substitution.
Within a PKI, the method for preventing this kind of substitution attack is the digital certificate (Barr, 2002). A certificate is a message stating that a public key belongs to or is associated with a given individual, organization, or device. The party issuing the certificate is a certification authority, or “CA,” and the party receiving it is called the subscriber. A digital certificate is itself a digitally signed message. The issuing CA signs the message with its private key. The digital signature on the certificate itself provides assurances of the origin of the CA signing it, and the fact that the certificate has not been tampered with since issuance. Thus, the certificate is the CA’s signed assertion that a particular public key belongs to a specific individual, organization, or device.
To the extent the relying party trusts the CA, the relying party can trust in this binding and use the public key in the certificate with confidence to verify digital signatures of the subscriber. Of course, if the certificate is a digitally signed message binding a subscriber to a public key, it is also necessary to obtain the CA’s public key, or root certificate, to verify the digital signature on the certificate.
If the verifiers that need the root certificate are small in number, it is possible to distribute the root in person. Root certificates may also be distributed on media using trustworthy non-Internet delivery mechanisms, such as reputable courier services or even postal mail. While this option may be satisfactory for small communities, it is difficult to scale this solution to large populations. As a result, many CAs have arranged with software manufacturers to embed their roots within the software itself. Under this solution, when a verifier needs to refer to a root certificate, the root certificate is already within the verifier’s software and is available for use. To date, this solution has proved to be the most effective method of distributing roots widely.
In addition to digital signatures, public key technology may be used to encrypt messages in order to protect the confidentiality of the information contained within them. In the encryption process, the sender of the data to be kept confidential uses the recipient’s public key to encrypt the data. The recipient uses the recipient’s private key to decrypt the data. The principle of irreversibility here means that it is computationally infeasible for anyone intercepting the message and having knowledge of the recipient’s public key to derive the private key and decrypt the data. Moreover, only the recipient, who holds that private key, will have the ability to decrypt the data.
Widely deployed encryption software, such as e-mail clients, can perform these encryption functions. This software, however, does not use the asymmetric key to encrypt the entire plaintext of the message. Asymmetric key operations tend to be costly in terms of time and computing power. Therefore, software commonly uses a symmetric key used only for this one operation (called a “session key”) to encrypt the plaintext message and then, in turn, uses the recipient’s public key to encrypt the symmetric session key. The message sent to the recipient includes the encrypted message and the encrypted session key. The recipient then uses the recipient’s private key to decrypt and recover the session key. The session key is then used to decrypt the message itself. As with digital signatures, a sender of a confidential message can obtain the public key of the recipient using the recipient’s certificate.
Secure Sockets Layer (SSL)
One of the best-known uses of public key technology is the protocol known as the Secure Sockets Layer (SSL), which protects the communications between a browser on a client machine and a server over an insecure network, such as the Internet. People every day access e-commerce sites to purchase goods and services over the Internet, and wish to secure their sessions with these sites to protect the confidentiality of information such as credit card numbers. The magnitude of this everyday use of SSL to protect these sites indicates that SSL is by far the most widespread commercially deployed PKI technology. An SSL session consists of the following procedures:
• A browser sends a request to connect to a site that has a server certificate.
The user performs this request by clicking on a link indicating that it leads to a secure site or the user types in a URL with an “https” protocol specifier.
• The server responds and provides the browser with the server’s certificate.
• The browser verifies the digital signatures on the server certificate with reference to a certificate chain leading to a trusted root certificate.
• The browser also compares the server’s domain with the domain listed in the certificate to ensure that they match. If these steps are successful, the server has been authenticated to the user, providing assurances to the user that the user is accessing a real site whose identity was validated by a CA. This process is called server authentication.
• Optionally, the server may request the user’s certificate. The server can use the user’s certificate to identify the user, a process called client authentication.
• The browser generates a symmetric session key for use by the browser and server in encrypting communications between the two.
• The browser encrypts the session key with the server’s public key obtained from the server certificate and sends the encrypted key to the server.
• The server decrypts the session key using its private key.
• The browser and server use the session key to encrypt all subsequent communications.
Following these procedures, the user may notice a padlock symbol appearing on the screen. In addition, the user will be able to inspect the certificate on the site using the browser.
Biometrics is a term referring to the measurement of one or more biological characteristics of an individual, such as fingerprints, voice recognition, eye imaging, hand geometry, and the like. Primarily a form of identification and authentication, biometrics can enhance PKI and can be enhanced by PKI.
• A biometric can augment or replace the access control placed over a subscriber’s private key.
• The integrity and authenticity of the biometric template can be ensured via digital signature and can even be enveloped within a digital certificate.
• The biometric reader device can be authenticated via PKI (similar to existing mechanisms used for point of sale (POS) and automated teller machines (ATM).
Because cryptographic keys are very special pieces of data that require extraordinary handling, the subject warrants particular attention. Symmetric and asymmetric algorithms and their cryptographic keys all have different strengths, weaknesses, and properties that require distinct policy and practices to protect them.
The controls over the asymmetric private and public keys inherent in a properly deployed PKI ensure its reliability. For the public key, a digital certificate ensures the integrity and authentication of the subscriber’s public key and provides the cryptographic binding between the subscriber’s identity (and/or other attributes) and public key. Key recovery is the ability to reconstitute a decryption key for the purposes of recovering encrypted data. This may be necessary in the event of a hardware failure, where the key has been lost, the untimely death of a person when the PIN guarding access to the key is no longer available, or other circumstances where encrypted data must be recovered.
In order to provide key recovery services, the PKI service provider may store activation data or the decryption key itself. The design and implementation of a storage and retrieval process will usually be specific to the PKI service provider and may involve a combination of chain of custody, dual control, split knowledge, encryption, and other techniques by the parties involved to provide procedural protections for the private key.
Private key recovery presents the security risks of unauthorized access to the private key, which can be used to decrypt sensitive information. In the case of single key pair schemes, in which one key services both signature creation and decryption purposes, there may be reasons for escrowing or managing the single key. When such systems are used, unauthorized access to a private key also entails the risk that an attacker could create digital signatures using the recovered key and thereby impersonate the subscriber. Consequently, there is a business need to limit the circumstances under which a private key can be recovered and also control access to the private keys to prevent unauthorized private key recoveries. Circumstances under which recovery is appropriate or required generally fall into two categories: voluntary requests from the subscriber and requests for a subscriber’s private key that originate from another responsible and authorized party, which are likely to be involuntary from the perspective of the subscriber.
Certificate Revocation List (CRL)
A CRL is a digitally signed list of revoked certificates’ serial numbers that is generally issued by the CA that issued the (revoked) certificate. CRLs provide information regarding a certificate’s status. CRLs are issued periodically and downloaded to relying party systems on a scheduled basis (e.g., every twenty-four hours. CRLs contain an issue date as well as the date that the next CRL should be issued.
The frequency of CRL issuance tends to reflect the risks and assurances associated with the certificates. In some cases, unscheduled “interim” or “delta” CRLs may be issued, particularly in the event of key compromises. CRLs have other advantages, and they have disadvantages as well. In addition to the short response time that a local CRL provides, a CRL may be a cost-effective means to validate certificates in low-value transactions in which the infrequent revocation of a certificate keeps the CRL relatively small. In such situations, the relying party’s system can be designed to check for and pull down updated CRLs as often as convenience and risk management dictates. However, a CRL may only be considered valid at the time it is published. As the size of the CRL and the value of the underlying transaction grow, the CRL becomes a less cost-effective solution.
The solution chosen in some situations might include a combination of both CRL and status checking (for example, Online Certificate Status Protocol). Online mechanisms are capable of communicating the current (real-time or near real-time) status of a certificate. These mechanisms eliminate latency issues affecting CRLs, although they may introduce other risks (certificate status responder and Internet connection downtime). The predominant online revocation/status-checking mechanism is the IETF Online Certificate Status Protocol (OCSP). OCSP provides a standardized protocol for online status requests for specific certificates. Upon request, an OCSP “responder” provides a signed status response message that reflects the current status of the certificate. The responder’s signature can be verified by the relying party.
The timeliness of any certificate status information depends on the implementation. Some OCSP responders are merely front-ends for CRL-based revocation systems or base their response on the most current operational records of the CA. In these cases an OCSP response will not contain more current information than the CRLs. Relying parties may need to retain OCSP responses used to verify signatures, since each response is unique to a particular transaction. OCSP is only one of many types of online checking mechanisms.