Asymmetric Key Encryption and Public Key Infrastructure

Asymmetric Key Encryption and Public Key Infrastructure

One of the main issues with symmetric key cryptosystems is that they don’t scale very well. Asymmetric key cryptosystems, where different keys are used for encrypting and decrypting, scale well. This is mainly because the management of these asymmetric keys is integral to the same infrastructure that is used to generate and issue them in the first place. In this section, we examine the principles behind asymmetric key encryption and look at popular encryption algorithms that use asymmetric keys including Rivest Shamir Adleman (RSA), Diffie-Hellman (DH), and public key infrastructure (PKI).

Asymmetric algorithms are slower than symmetric algorithms because they are more mathematically complex. Because they are slower, they are not typically used in real-time encrypted data flows and are instead used as key exchange protocols. Symmetric algorithms are discussed in the section, “Exploring Symmetric Key Encryption.”

Asymmetric encryption algorithms provide for both confidentiality and authentication. They are often called public key algorithms. They are asymmetric in that each party to the cryptosystem has two keys, contained in a “key pair” consisting of a private key and a corresponding public key:

• Private key. This key is not freely distributed, and is closely guarded, thus ensuring confidentiality.
• Public key. Usually freely available, and distributed to any entity that wants to enter into confidential communication with the system that holds the corresponding private key.

Both keys are capable of encrypting data. If the private key is used for encrypting data, the corresponding public key is used to decrypt the data and vice versa.
Examples of public key encryption algorithms include the following:

• RSA:
• Invented in 1997 by Rivest, Shamir, and Adleman.
• Often used in digital signatures for authentication and non-repudiation.
• 100 times slower than DES in hardware and 1,000 times slower than DES in software.
• Consequently, it can be used for encryption but not typically for large quantities of data.
• DSA. Digital Signature Algorithm (part of DSS).
• DH. Diffie-Hellman key exchange algorithm. Describes a method for generating a shared secret encryption key in a secure fashion over an unsecure network. The DH key exchange uses the peers’ public and private key pairs as part of its algorithm. Very commonly used by Internet Key Exchange (IKE) Phase I during the establishment of an IPsec VPN
  session. See the next chapter for more information.
• ElGamal. An asymmetric key encryption algorithm based on the DH key agreement. First described by Taher Elgamal in 1984.
• Elliptic Curve. Used for both encryption and also part of DSS.

Encryption with Asymmetric Keys

In order to encrypt a message to an entity (a box or a person), you need their public key. The transmitter encrypts the message with an agreed-upon encryption algorithm and the receiver’s public key. The receiver decrypts the message with the receiver’s private key. Confidentiality is assured because only the holder of the private key can decrypt the message. Thus: Encrypt (public key) + Decrypt (private key) = confidentiality

Authentication with Asymmetric Keys

We discussed digital signatures in the last section. This is an example of how authentication works with asymmetric keys. Remember how Bob’s boss signed the email message with her private key, and Bob verified the email message with the boss’s public key? Authentication is assured because only Bob’s boss could have encrypted a message that is verified with the boss’s public key. Thus: Encrypt (private key) + Decrypt (public key) = authentication

Public Key Infrastructure Overview

In large-scale asymmetric encryption cryptosystems, Public Key Infrastructure (PKI) is often used to manage the keys. The integrity of the cryptosystem itself revolves around the trust inherent in the PKI employed. Because the cryptosystem’s private keys are managed by the framework of the PKI, a badly managed PKI would lead to an untrustworthy cryptosystem. All the devices, users, and other entities within the cryptosystem leverage on this trust. If their credentials (certificates, keys, and so on) can be proved to be issued by the same, trusted third-party authority, then the entities will trust one another.
Thus, in a PKI, it is all about trust. Here is some terminology providing a framework for a discussion of PKI:

• PKI. A trust framework that supports technologies in a Public Key technology implementation.
• Certificate Authority (CA). The trusted third party that signs public keys.
• Certificates. Documents that associate names to the public keys that have been signed by the CA.

PKIs don’t just happen. Neither are they just users and certificates. PKIs comprise five main areas, as follows:

• CAs. Address key management and issuance.
• PKI Users. Some examples are VPN gateways, routers, people, and ecommerce servers
• Storage and Protocols:
• How are credentials (keys, certificates) safely stored and distributed?
• Some of the enrollment and issuance procedures can be automated.
• Supporting Organizational Framework. Practices and procedures and user authentication using Local Registration Authorities (LRAs), integrated into the organization’s comprehensive security policy.
• Supporting Legal Framework. Acceptable Use Policy (AUP), incident response, policies for lost or stolen keys, and so on.

PKI Topologies

There are two basic PKI topologies, central (single-root) and hierarchical. These are illustrated in Figures 6.11.

Central (Single-Root) CA

This is the simplest way to implement a PKI. Certificates are issued by one CA. Its most obvious advantage is its simplicity, but having one root CA has some disadvantages:

• Not scalable to large environments; for example, across several departments within a federal government.
• Topology requires one centralized administration where all the trust decisions are made.
• Single point of failure. If the single root CA is compromised, then the whole PKI is, because all the public keys have been signed by the same CA.

Hierarchical CA

A hierarchical CA delegates the root CA’s authority to subordinate CAs, thereby distributing trust. A compromise of a subordinate CA’s private key only compromises the public keys that it has signed. Ultimately, all subordinate CAs’ public keys have been signed by the same root CA; no matter the depth of the hierarchy, there is only one root. Thus, users trust certificates issued to other users within the same hierarchy. In Figure 6.11, even though Alice and Bob are in different departments of the same company, their CA’s certificates were issued by the same root CA, and thus Alice trusts Bob.
This chain of logic is called the certification path.

Cross-Certified CAs

With cross-certified CAs, two or more separate organizations’ root CAs are configured to trust or “cross-certify” each other. In this manner, all entities within each organization’s PKI trust entities in the other organization’s PKI. This is another approach to hierarchical CAs.

PKI and Usage Keys

Some Public Key Infrastructures are designed such that users are required to possess two key pairs: one for encryption and another one for signing. These key pairs can be different strengths. This necessitates two certificates for the user: one for encryption and another for signing. (Recalling that the certificate contains the user’s public key.)

PKI Server Offload and Registration Authorities (RAs)

Many organizations require that the CA be kept under lock and key and, in some cases, powered down until it is needed to sign certificates. This is because the security of the CA defines the security and trustworthiness of the whole PKI. Depending on the scale of the solution, some of the day-to-day management tasks in a PKI can be offloaded (delegated) to a Registration Authority (RA), minimizing the CA’s exposure. Some of these tasks may include the following:

• User authentication during enrollment.
• User key generation. (If required, normally the client will create its own public key, which is signed by the CA when the enrollment request is approved and the certificate issues.)
• Certificate distribution.

PKI Standards

Standardization of PKI protocols is crucial, especially when interoperability of PKI protocols is required. One example of this that we’ve already seen is in cross-certification of CAs. PKI also should work with other standards, such as the following:

• X.500 directory services
• Public Key Cryptography Standards (PKCS)
• Lightweight Directory Access Protocol (LDAP)

Some of these standards define user information databases and information repositories. It is very convenient (especially when these other services already exist) that PKI interoperates with them.

X.509 v3

The most common standard for the PKI framework is X.509 v3. X.509 defines the certificate structure. Its use is widespread in the following:

• Servers. Web, email, LDAP, and other servers using SSL and TLS.
• Web Browsers. SSL and TLS.
• Email Programs. Secure Multipart Internet Mail Extension (S/MIME) attachments.
• IPsec VPNs. Used for authentication instead of simple pre-shared keys
  (PSKs) during the IKE Phase I negotiation. (See Chapter 7.)

Public Key Cryptography Standards (PKCS)

PKCS defines the formatting of data that is exchanged between the different elements within a PKI. It was developed to promote interoperability, as well as standardize PKI APIs. Some important examples of these standards include the following:

• PKCS #1: RSA Cryptography.
• PKCS #2: DH Key Agreement.
• PKCS #7: Cryptographic Message Syntax (see note below).
• PKCS #10: Certificate Request Syntax (see note below).

Simple Certificate Enrollment Protocol (SCEP)

SCEP automates the procedure of enrolling in a CA and the issuing of certificates. It is most commonly used in IPsec VPNs where the VPN peers use certificatebased authentication and where manual enrollment is not practical. SCEP not only automates the secure issuance of certificates, but it manages the whole PKI life cycle, including automatic renewal of certificates that are close to their expiry date.
Figure 6.12 shows a simple depiction of this process using the reference network design introduced with Figure 4.1 in Chapter 4, “Implementing Secure Management and Hardening the Router.”

Certificate Enrollment Process

There are three basic steps involved in enrolling in a CA. Naturally, the first step is making sure that the participants in the PKI trust the CA. This is done by retrieving and validating the CA’s certificate. At a high-level, the three steps are as follows:

1. Retrieving the CA Certificates. The PKI participants retrieve the CA’s certificate and validate (authenticate) it. Cisco recommends using some out-of-band (relative to the network) channel for the most secure solution. For example, validation of the CA certificate may be as simple as faxing the information found in the CA’s X.509 certificate and the CA’s public key to the CA administrator and asking that they validate it by return fax.
2. Certificate Enrollment. Assuming that the CA’s certificate is validated successfully, the PKI participants now trust the CA to issue identity certificates. The PKI participants enroll in the CA by sending a certificate request to the CA. This request contains the user’s self-generated public key; the user’s corresponding private key is retained on the user’s device. (The PKI can also be configured so the CA generates the private and public key pair.) The CA issues the certificate after validating the user’s enrollment request. Like the validation of the CA’s certificate on the part of the user, Cisco recommends that the user’s certificate request is validated using an out-of-band method by the CA. (Only seems fair!)
   NOTE
   Note the terminology in step 2. The participants enroll in the Certificate Authority. This process can be automated (SCEP) or it can be a manual process. When SCEP is used, steps 1 through 3 are all automated, though the CA administrator will likely reserve the right to manually issue the pending enrollment requests before they can be retrieved. The participants in a PKI can be people or machines.
3. Certificate Issuance/Retrieval. The certificate is issued by the CA. As noted, this process is typically manual for security reasons. The PKI participants can now retrieve the issued certificates from the CA. This might involve visiting a special web page on the CA or some other method,

such as an attachment to an email message from the CA administrator. When steps 1 through 3 are complete, each participant in the PKI will possess the following:

• The CA’s certificate.
• Participant’s identity certificate (containing the participant’s signed public key) signed by the CA.
• A key pair:
  • Participant’s public key.
  • Participant’s corresponding private key.

Certificate-Based Authentication

Now that the participants have the CA’s certificate, their own identity certificate and a key pair, they can authenticate to one another without the involvement of the CA. Because they possess identity certificates that have been signed by the same CA, they should naturally trust one another. The PKI participants could be IPsec VPN peers, as in Figure 6.13.

The actual mechanics of certificate-based authentication are as follows:

1. The PKI participants exchange certificates.
2. The participants verify each other’s digital signatures. This step consists of each participant:
   • Hashing the plaintext portion of the other participant’s certificate.
   • Decrypting the other participant’s digital signature using the CA’s public key (contained in the CA’s certificate).
   • Comparing the results in steps a and b. If they match, the participant’s certificate has been issued by the same CA.
3. Internet Key Exchange (IKE) Phase I completes. (The mechanics of what happens inside IKE Phase I beyond this authentication process will be examined in Chapter 7.)

Certificate Applications

We’ve mentioned IPsec, SSL VPN servers and application layer servers (such as email and web servers) as common applications of certificates. One CA server can issue certificates that can be used for all these types of authentication, as long as the participants in the PKI support the same procedures for enrollment, issuance, and installation. Certificates are often seen at the application layer of the OSI model in the following ways:

• SSL
• TLS
• S/MIME (Secure Multi-part Internet Mail Extension)
• PGP (Pretty Good Privacy) The most common Cisco uses of certificates include:
• IPsec—certificate-based authentication during IKE Phase I
• 802.1X using EAP-TLS (Extensible Authentication Protocol-TLS)
• TN3270 over SSL (IBM Telnet protocol using SSL encryption)
• SSL VPN Servers (WebVPN solution; see Chapter 7)

• CCNA Security Study Notes