25.5 Public Key Cryptography Basics
This sections describes the basics of Public Key Cryptography.
25.5.3 Key Pairs
Authentication and encryption are both provided through the use of mathematically related pairs of digital codes or “keys.” One key in each pair is publicly distributed; the other is kept strictly private.
Each data transmitter, whether it is a person, a software program, or some other entity such as a bank or business, is issued a key pair by a public key cryptography system.
The basic principles and functions of each key in the key pair are summarized in the following illustration:
Figure 25-1 Basic Key Pair Description
Key Pairs and Authentication
Authentication means that the data receiver knows that the data sender is exactly who or what it claims to be.
Suppose that you want to authorize your bank to transfer funds from your account to another account. The bank needs proof that the message came from you and that it has not been altered during transit. The following illustrates the process that your online transaction would follow, using public key cryptography.
Figure 25-2 Public Key Process
For information about digital signatures and their verification, see Digital Signatures.
Key Pairs and Encryption
Encryption means that the data can be read only by the intended receiver.
Suppose you want to order a book from an Internet vendor and you need to use your credit card to pay for it. You don't want your credit card number read by anyone other than the intended recipient.
The encryption process in the following illustration provides the mechanisms through which your credit card number can be safely transmitted.
Figure 25-3 Encryption Process
25.5.4 Establishing Trust
If a sender and receiver know and trust each other, they can simply exchange public keys and establish secure data transmission, including authentication and encryption. To do this, they would use each other's public keys and their own private keys.
Under normal circumstances, however, parties needing secure data transmissions have no foundation for trusting the identity of each other. Each needs a third party, whom they both trust, to provide proof of their identity.
Certificate Authorities
A party needing to prove its identity in a public key cryptography environment enlists the services of a trusted third party known as a certificate authority.
The primary purpose of the certificate authority is to verify that a party is who or what it claims to be, and then to issue a public key certificate for that party to use. The public key certificate verifies that the public key contained in the certificate belongs to the party named in the certificate.
Figure 25-4 Certificate Request
After the identity of the requesting party has been established to the satisfaction of the certificate authority, the certificate authority issues an electronic “certificate” and applies its digital signature.
Digital Signatures
Just as a personal signature applied to a paper document indicates the authenticity of the document, a digital signature indicates the authenticity of electronic data.
To create a digital signature, the software used to create the signature links the data being signed with the private key of the signer. The following illustration shows the process that a CA follows to create its digital signature for a public key certificate.
Figure 25-5 Digital Signature
A digital signature is uniquely linked to the signer and the data. No one else can duplicate the signature because no one else has the signer's private key. In addition, the signer cannot deny having signed the data. This is known as non‑repudiation.
When a certificate authority signs a public key certificate, it guarantees that it has verified the identify of the public key owner according to the certificate authority's established and published policies.
After signed data (such as a public key certificate) is received, software verifies data authenticity by applying the same computation to the data that the signing software used originally. If the data is unaltered, both computations produce identical results. It can then be safely assumed that neither the data nor the signature was modified in transit.
Certificate Chain
A certificate chain is an ordered list of certificates. The certificates are ordered such that the server or user certificate is first, followed by the certificate of its CA.
CAs can either sign their own certificates (that is, they are self-signed) or they can be signed by another certificate authority. If they are self-signed, they are typically called root CAs. If they are not self-signed, they are typically called subordinate CAs or intermediate CAs.
If a user or server certificate was signed by a CA with a self-signed certificate, the certificate chain is composed of exactly two certificates: the end entity certificate and the root CA.
If a user or server certificate was signed by an intermediate CA, then the certificate chain is longer. The first two elements are still the end entity certificate, followed by the certificate of the intermediate CA. But the intermediate CA’s certificate are then followed by the certificate of its CA. This listing then continues until the last certificate in the list is for a root CA. Thus, a certificate chain can be infinitely long. In practice, however, most certificate chains have only two or three certificates.
Trusted Roots
In order to validate a digital signature, you must trust at least one of the certificates in the user or server’s certificate chain. You can directly trust the certificate of the user or server, or you can choose to trust any other certificate in the chain. Typically, the certificate that is trusted is the root CA’s certificate.
Most application software that can use certificates already has a list of trusted certificates installed. These certificates are for root CAs and, hence, are called “trusted roots.”Typically these CAs are commercial CAs. If you choose, you can add additional CAs to this list or remove CAs from the list.