Recently one of my colleagues asked me to about a good explanation of PKI. So i decided to collect him some materials from Cisco. I think following explanation of PKI is brilliant. Thanks to Cisco.

PKI OVERVIEW

A substantial challenge with both asymmetric encryption and digital certificates is the secure distribution of public keys. How do you know that you have the real public key of the other system and not the public key of an attacker who is trying to deceive you? In this scenario, the public key infrastructure comes to play. Entities enroll with a PKI and receive identity certificates that are signed by a certificate authority. Among the identity information included in the certificate is the entity’s public key. The certificate authority’s digital signature on the identity certificate validates that the included public key is the real public key belonging to the associated entity. A system will only accept the signed digital certificate if it trusts the CA. The CA plays the role of a trusted third party.

TRUSTED THIRD-PARTY EXAMPLE

In the figure below, Alice applies for a driver’s license. As part of this process, Alice submits evidence of identity and qualifications to drive. Once the application is approved, a license is issued.

Later, Alice needs to cash a check at the bank. Upon presenting the check to the bank teller, the bank teller asks for ID. The bank, because it trusts the government agency that issued the driver’s license, verifies the identity with the license and cashes the check.

THE PUBLIC KEY INFRASTRUCTURE (PKI)

The public key infrastructure (PKI) is a combination of policies, procedures, hardware, software, and people that are required to create, manage, and revoke (when necessary) digital certificates. Similar to the concept of how a driver of a car can receive a license to drive, and that license because it is issued from a trusted agency can be used by others to validate the identity of the person who has the license, an identity digital certificate, issued by a trusted certificate authority (CA) , can provide similar functionality in the digital world of networking. On a bigger scale, digital certificates can be used for authenticating a specific user, system, or server, and going beyond that, the certificate can also be used as part of the protocols to establish an encrypted private session. This includes the root CA, intermediate or subordinate CAs, the registration authority, and certification revocation list (CRL) as required.

 

PUBLIC AND PRIVATE KEY PAIRS

A key pair is a set of two keys that work in combination with each other as a team. In a typical key pair, you have one public key and one private key. The public key may be shared with everyone, and the private key is not shared with anyone. For example, the private key for a web server is known only to that specific web server. If you use the public key to encrypt data using an asymmetric encryption algorithm, the corresponding private key is used to decrypt the data. The inverse is also true. If you encrypt with the private key, you then decrypt with the corresponding public key. Another name for this asymmetric encryption is public key cryptography or asymmetric key cryptography. The uses for asymmetric algorithms are not just limited to authentication, as in the case of digital signatures dis- cussed in the previous sections, but that is one example of an asymmetric algorithm.

PKI TERMINOLOGY AND COMPONENTS

A PKI is the service framework that is used to support large-scale public key-based technologies. It provides the base for security services such as encryption, authentication, and nonrepudiation. A PKI allows for very scalable solutions which require the management of systems identities, user identities, or both, and is an important authentication solution for VPNs. A PKI uses specific terminology to name its components.

Two very important terms must be defined when talking about a PKI:

• CA: The trusted third party that signs the public keys of entities in a PKI-based system.
• Certificate: A document, which in essence binds together the name of the entity and its public key, which has been signed by the CA.

Many vendors offer CA servers as a managed service or as an end-user product: VeriSign, Entrust Technologies, and GoDaddy are some examples. Organizations may also implement private PKIs using Microsoft Server or Open SSL.

PUBLIC KEY CRYPTOGRAPHY STANDARDS

There are lots of standards in use for the PKI. Many of them have Public Key Cryptography Standards (PKCS) numbers. Some of these standards control the format and use of certificates, including requests to a CA for new certificates, the format for a file that is going to be the new identity certificate, and the file format and usage access for certificates. Having the standards in place helps with interoperability between differ- ent CA servers and many different CA clients.

Here are a few standards you should become familiar with, which include protocols by themselves and protocols used for working with digital certificates:

• PKCS #10: This is a format of a certificate request sent to a CA who wants to receive their identity certificate. This type of request would include the public key for the entity desiring a certificate.
• PKCS #7: This is a format that can be used by a CA as a response to a PKCS#10 request. The response itself will very likely be the identity certificate (or certificates) that had been previously requested.
• PKCS#1: RSA Cryptography Standard.
• PKCS#12: A format for storing both public and private keys using a symmetric password-based key to “unlock” the data whenever the key needs to be used or accessed.
• PKCS#3: Diffie-Hellman key exchange.

Currently, digital identity certificates use the X.509 version 3 structure:

• Version
• Serial number
• Algorithm ID
• Issuer
• Validity
• Not before
• Not after
• Subject
• Subject public key info
• Public key algorithm
• Subject public key
• Issuer unique identifier (optional)
• Subject unique identifier (optional)
• Extensions (optional)
• Certificate signature algorithm
• Certificate signature

As you can see, digital identity certificates contain a set of identity information about an entity, including that entity’s public key. The last element in the certificate is a signature. The CA signs the certificate. It takes all the certificate data and runs it through the specified hash algorithm to compute a fingerprint of the certificate data. It then encrypts the hash using its private key. The encrypted hash is the signature and it is appended to the certificate. Any system can then validate a certificate using the CA’s public key. The system takes the certificate data and runs it through the specified hash algorithm to produce a fingerprint of the certificate which it received. It then decrypts the certificate signature using the CA’s public key. If the computed hash and the decrypted signature match, then the signature is valid.

DIGITAL SIGNATURES

Suppose that a customer sends transaction instructions via an email to a stockbroker, and the transaction turns out badly for the customer. It is conceivable that the customer could claim never to have sent the transaction order or that someone forged the email. The brokerage could protect itself by requiring the use of digital signatures before accepting instructions via email.

Handwritten signatures have long been used as a proof of authorship of, or at least agreement with, the contents of a document. Digital signatures can provide the same functionality as handwritten signatures, and much more.

Digital signatures are commonly used in the following two situations:

• Code signing – This is used for data integrity and authentication purposes. Code signing is used to verify the integrity of executable files downloaded from a vendor website. It also uses signed digital certificates to authenticate and verify the identity of the site.
• Digital certificates – These are similar to a virtual ID card and used to authenticate the identity of system with a vendor website and establish an encrypted connection to exchange confidential data.

There are three Digital Signature Standard (DSS) algorithms that are used for generating and verifying digital signatures:

• Digital Signature Algorithm (DSA) – DSA is the original standard for generating public and private key pairs, and for generating and verifying digital signatures. Figure 3 summarizes DSA.
• Rivest-Shamir Adelman Algorithm (RSA) – RSA is an asymmetric algorithm that is commonly used for generating and verifying digital signatures. Figure 4 summarizes RSA.
• Elliptic Curve Digital Signature Algorithm (ECDSA) – ECDSA is a newer variant of DSA and provides digital signature authentication and non-repudiation with the added benefits of computational efficiency, small signature sizes, and minimal bandwidth.

RSA DIGITAL SIGNATURES

The current signing procedures of digital signatures are not simply implemented by public key operations. In fact, a modern digital signature is based on a hash function and a public key algorithm, as illustrated below.

The signature process is as follows:

1. The signer makes a hash, or fingerprint, of the document, which uniquely identifies the document and all its contents.
2. The signer encrypts the hash with only the private key of the signer.
3. The encrypted hash, which is known as the signature, is appended to the document.

The verification process is as follows:

1. The verifier obtains the public key of the signer.
2. The verifier decrypts the signature using the public key of the signer. This step unveils the assumed hash value of the signer.
3. The verifier makes a hash of the received document, without its signature, and compares this hash to the decrypted signature hash. If the hashes match, the document is authentic. The match means that the document has been signed by the assumed signer and has not changed since it was signed.

The example illustrates how the authenticity and integrity of the message is ensured, even though the actual text is public. Both encryption and digital signatures are required to ensure that the message is private and has not changed.

Digital signatures provide three basic security services in secure communications:

• Authenticity of digitally signed data: Digital signatures authenticate a source, proving that a certain party has seen and has signed the data in question.
• Integrity of digitally signed data: Digital signatures guarantee that the data has not changed from the time it was signed.
• Nonrepudiation of the transaction: The recipient can take the data to a third party, and the third party accepts the digital signature as a proof that this data exchange did take place. The signing party cannot repudiate that it has signed the data.

To achieve these goals, digital signatures have the following properties:

• The signature is authentic: The signature convinces the recipient of the document that the signer signed the document.
• The signature is not forgeable: The signature is proof that the signer, and no one else, signed the document.
• The signature is not reusable: The signature is a part of the document and cannot be moved to a different document.
• The signature is unalterable: After a document is signed, it cannot be altered.
• The signature cannot be repudiated: Signers cannot claim later that they did not sign it.

A PKI facilitates highly scalable trust relationships. PKIs can be further scaled using a hierarchy of CAs with a root CA signing the identity certificates of subordinate CAs. For simplicity, this discussion will present a single CA PKI.

The PKI is an example of a trusted third-party system. The basis of the trust is the CA’s public key. All systems that leverage the PKI must have the CA’s public key, from the CA’s own identity certificate. The CA’s own identity certificate is unique as it is self-signed. For many systems, the distribution of CA certificates is handled automatically. For example, commercial web browsers come with a set of public CA root certificates pre-installed, and organizations push their private CA root certificate to clients through various software distribution methods. But in some instances, particularly when a system needs to enroll with a PKI to obtain an identity certificate for itself, the CA certificate must be requested and installed manually. Then, it is advisable to use an out-of-band method to validate the certificate. For example, the CA administrator can be contacted via the phone to obtain the fingerprint of the valid CA identity certificate. The goal is to verify that the CA certificate that was received was the authentic CA certificate containing the authentic CA public key and not a certificate that is provided by an attacker containing the attacker’s public key.

Digital Certificates can be used for clients who want to authenticate a web server to verify they are connected to the correct server using HTTP Secure (HTTPS) , Transport Layer Security (TLS) , or Secure Sockets Layer (SSL) . For the average user who does not have to write these protocols, but simply benefits from using them, they are all effectively the same, which is HTTP combined with TLS/SSL for the security benefits. This means that digital certificates can be used when you do online banking from your PC to the bank’s website. It also means that if you use SSL technology for your remote-access VPNs that you can also use digital certificates for authenticating the peers (at each end) of the VPN.

You can also use digital certificates with the protocol family of IPsec, which can also use digital certificates for the authentication portion.

Digital certificates can also be used with protocols such as 802.1X, which involves authentication at the edge of the network before allowing the user’s packets and frames to progress through the network. An example is a wireless network, controlling access and requiring authentication, using digital certificates for the PCs/users, before allowing them in on the network

CERTIFICATE ENROLLMENT

To obtain an identity certificate, a system administrator will enroll with the PKI. The first step is to obtain the CA’s identity certificate. The next step is to create a CSR (PKCS #10). The CSR contains the identity information that is associated with the enrolling system, which can include data such as the system name, the organization to which the system belongs, and location information. Most importantly, the enrolling system’s public key is included with the CSR. Depending on the circumstance, the CA administrator may need to contact the enroller and verify the data before the request can be approved. If the request is approved, the CA will take the identity data from the CSR, and add in the CA-specified data, such as the certificate serial number, the validity dates, and the signature algorithm, to complete the X.509v3 certificate structure. It will then sign the certificate by hashing the certificate data and encrypting the hash with its private key. The signed certificate is then made available to the enrolling system.

Authentication Using Certificates

It is important to understand that the CA is not involved in the certificate validation process. Systems that need to validate the identity certificate of other systems will have the root CA certificate. They will use the CA’s public key to validate the signature on any certificate they receive. It is also important to understand that the certificate does not so much identify the entity of the peer. It only identifies the valid public key of the peer. To be sure that the peer is actually the entity that is identified in the certificate, a system must challenge the peer to prove that it has the private key that is associated with the validated public key. For example, a message can be encrypted with the validated public key and sent to the peer. If the peer can successfully decrypt the message, then the peer must have the associated private key and is therefore the system that is identified by the digital certificate.

CERTIFICATE REVOCATION

Digital certificates can be revoked if keys are thought to be compromised, or if the business use of the certificate calls for revocation (for example, VPN access privileges have been terminated). If keys are thought to be compromised, generating new keys forces the creation of a new digital certificate, rendering the old certificate invalid and a candidate for revocation. On the other hand, a consultant might obtain a digital certificate for VPN access into the corporate network only during the contract.

Certificate revocation is also a centralized function, providing “push” and “pull” methods to obtain a list of revoked certificates—frequently or on-demand—from a centralized entity. In some instances, the CA server acts as the issuer of certificate revocation information.

CERTIFICATE REVOCATION CHECK METHODS

Several methods can be used to check for certificate revocation. Currently, the most prevalent methods are CRLs and OCSP. The table lists benefits and limitations of each protocol:

• CRL: A list of revoked certificate serial numbers is distributed as a time-stamped, CA-signed file. PKI entities regularly poll the CRL repository to receive the current CRL. There is a window of opportunity for attackers while the new CRL is not yet propagated.
• OCSP: Revocation information is immediately pushed to an online database. Entities can query the OCSP server at any time to check for validity of the received certificate.

I’ve collected this material from several Cisco papers.