Chapter 2. Understanding PKI Building Blocks

This chapter covers the following topics:

• Certificates

• Certification Authorities (CA)

• Subordinate Certification Authorities (Sub-CA)

• Registration Authorities (RA)

• Endpoint Entities: Users and Devices

• Key and Certificate Storage

The principles and functions of cryptography are the building blocks for Public Key Infrastructure (PKI). This chapter describes digital certificates, the surrounding environment, and the various forms of Certification Authorities (CA).

Certificates

In the digital world, certificates establish the link between an identity (associated with either an individual or a device of any type) and the corresponding electronic material. In this case, the material is cryptographic information, commonly known as encryption keys. A digital certificate is therefore a set of initially independent digital information combined and signed by an authority. An authority is an administrative entity that has some level of trust by the users; examples are government organizations or some companies.

Structure and Content

The main information contained in a certificate follows:

• An identity (that is, a name or a reference to an object, human, or material).

• Some attributes, attached to either the identity itself or the authorized uses of the certificate. Attribute types can vary to a wide extent; the most common ones will be explained later in this chapter.

• A public key performs a given set of cryptographic operations. It is included in the certificate so that it is published at the same time and therefore becomes available to third parties (all entities different from the owner). Absolutely nothing is secret or confidential in the public key, so no security is required.

• A signature from a Certification Authority (CA), covering all preceding information fields. The signature authenticates the binding between all the information contained in the package.

Along with those four items, additional information can also be included, either to add more security or to automate operations inside the PKI.

The typical certificate is structured as follows:

• Certificate

• Version

• Serial Number

• Algorithm ID

• Issuer

• Validity period

— Not Before

— Not After

• Subject Name

• Subject Public Key Info

— Public Key Algorithm

— Subject Public Key

• Issuer Unique Identifier (Optional, Version 2 and above)

• Subject Unique Identifier (Optional, Version 2 and above)

• Extensions (Optional, Version 3 and above)

— ...

• Certificate Signature Algorithm

• Certificate Signature

OpenSSL libraries offer convenient tools to work with and view certificates. Example 2-1 shows the certificate content.

Example 2-1 OpenSSL Output of Certificate Content

Following is a description of each field based on RFC-5280:

• Version: To date, three versions of the X.509 standard have been defined. Since 1996, the latest and most commonly used version for Internet purposes is v3. The differences between versions are that additional fields have proven to be necessary over time, triggering updates in the defined standards.

• Serial number: Uniquely identifies a certificate among all the certificates issued by a given CA.

• Algorithm ID: Identifier for the algorithm used by the CA to sign the certificate.

• Issuer: Information about the particular CA that has issued and signed the certificate.

• Validity period: Defines the time interval during which the CA warrants that it will maintain information about the status (valid or revoked) of the certificate. After the expiration date, the certificate is invalid. This field contains two dates: “not before” and “not after” (therefore defining a time interval), expressed in universal time (UTC/GMT).

• Subject Name: Identifies the entity to which the public key belongs. The subject name takes the form of an X.500 distinguished name (DN). Typical Distinguished Name structures include Country, Organization, Organizational Unit, and Common Name and can be organized in a hierarchical way.

• Public Key Algorithm: Algorithm with which the subject public key can be used (that is, RSA or DSA).

• Subject Public Key: The public key associated with the entity identified in the Subject Name field. This is one of the keys used for cryptographic operations.

• Subject Unique Identifier: A unique identifier bound to the subject entity. This optional field can be used in case multiple entities (users or devices) have similar subject names.

• Issuer Unique Identifier: A reference to the subject unique identifier used in the CA certificate, in case multiple CAs have similar subject names.

• Certificate Signature Algorithm: An identifier for the algorithm used by the CA to sign the certificate. An example of such algorithm is MD5 with RSA encryption. This field must contain the same algorithm identifier as in the Algorithm ID field.

• Certificate Signature: The digital signature computed on the certificate fields, added by the CA when creating the certificate. By generating this signature, a CA certifies the validity and authenticity of the information in the fields. In particular, the CA certifies the binding between the public key material and the subject of the certificate. When receiving a certificate from a peer, one of the first steps is to verify the signature to ensure that the certificate has not been tampered with.

• Extensions: Provide a way to associate various attributes to user or public keys. Private extensions can be defined as required by the implementation.

Each extension is marked as either critical or noncritical. If a system cannot understand or process a critical extension, it must reject the certificate. Meanwhile, noncritical extensions might be ignored in similar situations. Therefore, caution must be taken before flagging an extension as critical in a PKI deployment.

Following is a review of the most common standard extensions seen in PKI implementations:

• Authority Key Identifier: Provides a way to uniquely identify the key pair used to sign a certificate. This is useful if the CA has multiple certificates.

• Subject Key Identifier: Provides a way to uniquely identify certificates that contain a particular public key. This extension is mandatory for CA certificates and optional for others.

• Key Usage: Defines the usage that can be done with the key contained in the certificate. Typical usages are encipherment, digital signatures, CRL signing, and certificate signing.

• Subject Alternative Name: Binds identities to the subject of the certificate. Those identities can be an email address, a DNS name, or an IP address.

• Basic Constraints: Identifies whether the subject of the certificate is a Certification Authority (allowed to issue child certificates) and the maximum depth of valid certification chain (including this certificate).

• Extended Key Usage: Indicates purposes for which the certified public key can be used, in addition to or in place of the basic purposes indicated in the key usage extension. Examples key usages include TLS Web server authentication, TLS Web client authentication, signing of downloadable executable code, email protection, or signing OCSP responses.

• CRL Distribution Points: Defines how CRL information should be retrieved. That field contains most commonly an HTTP or LDAP URI.

Standards

X.509v3 is the standard for Internet PKI. It is based on a hierarchical model and is described in RFC-5280, published by IETF.

Although there is little discussion about the format (X.509 is the standard), the encoding used often causes headaches or nightmares for the individual trying to understand and deploy a PKI. The objective of this section, therefore, is to shed some light in that area so that you can become efficient in working with PKI.

The Privacy Enhanced Mail (PEM) encoding is common for representing certificates in text format. It can be easily identified through the use of headers and trailers indicating the content (certificate, private key, and so on). Example 2-2 shows a certificate in PEM format.

Example 2-2 Certificate in PEM Format

In between those headers, the certificate itself is actually represented using Distinguished Encoding Rules (DER) encoding.

DER provides the advantage to have a unique way of encoding each ASN.1 value. Now you might wonder what an ASN.1 value is. ASN.1 provides a set of rules for representing, encoding, transmitting, and decoding data structures. Example 2-3 shows ASN.1 parsing with OpenSSL.

Example 2-3 Parsing ASN.1 with OpenSSL

PKCS#7: .p7b .p7c file extensions

This is a standard for enveloping data. It is defined in RFC-2315. In a PKCS#7 envelope, you can, for example, place a user certificate and the issuing CA root certificate so that the receiver has all the material required to start using the certificate.

PKCS#12: .p12 .pfx file extensions

This is used to exchange public and private objects in a single file. It can therefore contain a certificate and the associated private key. It provides an encryption mechanism so that private keys can be protected. This is the Cisco preferred format for carrying PKI material.

Example 2-4 Exporting a Key Pair from a Cisco IOS Router

Certification Authority (CA)

You now know what a certificate is and what it contains. Now we look at the CA responsible for creating and distributing them.

Role and Functions

A certificate creates a relationship between an identity and a key pair. Now, an external entity is called into the game to formally state and guarantee the existence of that link. The idea is to build a trusted relationship with the authority. This authority is then responsible to validate the authenticity of certificate requests: to guarantee that the identity requested to be included in the certificate is the actual identity of the requester or the entity that will own and use the certificate.

For example, if someone is requesting a certificate with the name “Alice” in it, the certification authority is responsible for validating that it is actually Alice asking for it (and owning the corresponding keys) and not Bob. To document the involvement of the certification authority, the CA digital signature (generated with a private key) is added to the certificate as a proof. As the certification authority is also trusted by the other members of the PKI, verifying the CA signature on a certificate guarantees its authenticity and therefore the identity of its owner.

The CA is the most important link in a PKI system. If the CA is ever compromised, the entire PKI implementation can no longer be trusted. Further sections show how the CA can be efficiently protected to minimize the risk.

Private Versus Public CAs

As you have seen, one of the main roles of the CA is to guarantee a trusted relationship. For that to happen, the CA must be “known” (and also trusted) by all parties involved in the PKI. Depending on the targeted scope and scale of the PKI deployment, you can differentiate two types of CAs: private and public.

Private CAs are entirely created, operated, and maintained by a limited private organization, usually a company or even a single department within a company. The private CA provides its services only for functions that are internal to the company (or department). An external component will typically not know or trust a private CA. Everyone can choose to deploy his own private CA; however, it will then be limited in terms of trusted relationships. The main advantage of a private CA is that it offers you complete freedom in terms of structure (multiple levels of sub-CAs, for example) and content of certificates. (Names and attributes can be chosen to accommodate the requirements.) A private CA is free in the sense that there is no subscription fee to create it or obtain certificate from it. The main limitation has already been mentioned, and the trust relationships are limited; although, it is always possible to cross-link multiple private PKI.

Public CAs, on the other hand, are well known, reachable, and trusted on a more global basis (at the Internet level). They are usually operated and maintained by dedicated companies for which running a CA is a core business. Some of the most popular ones include Verisign, Entrust, GlobalSign, and Thawte. They are so widely used that the corresponding root certificates are installed by default in popular Internet web browsers. To make use of their services (that is, get a certificate issued from them), a fee must usually be paid. The content of the certificate (name format and attributes) is usually more constrained. More and more government authorities are also creating their own CAs so that public services and institutions can make use of them. In some countries (Belgium, for example), each citizen now receives a personal certificate, usually stored on a personal identity card in the form of a smartcard.

Subordinate Certification Authorities (Sub-CA)

When the number of enrolled entities is increasing, to scale while keeping manageability, it is necessary to introduce hierarchical levels for the certification authority functions. The role and functions of the CA become distributed to multiple sub-CAs.

Role and Functions

The roles and functions of a sub-CA are exactly the same as the ones of a CA:

• Act as trusted authority

• Verify identities of requesters

• Issue certificates

The only difference is that although a CA can be seen as an autonomous, or top of structure, PKI component, a sub-CA is always a child of a CA.

Hierarchies

Hierarchical PKIs are created to answer scalability and management challenges. They use a tree model with the root CA at the top and sub-CAs at intermediate levels. The top CA (also called the root CA) stays the central point of aggregation; however, it can now delegate some of its responsibilities to the subordinate CAs so that scalability is restored.

Figure 2-1 shows a typical enterprise hierarchical PKI. The central security department owns and operates the root CA. It then creates a subordinate CA for each department in the company that will be operated by the department itself. Now each department can use it according to its needs: The network department uses it to enroll network devices, and the computer department generates certificates for servers and user laptops.

Figure 2-1 PKI Hierarchy Example

It was mentioned previously that one of the roles of the CA is to establish the trust relationship between two enrolled entities. What’s happening now within a hierarchical PKI? Now look deeper at the example.

Imagine that you would like to connect a user laptop through a VPN service using certificates for authentication. Focus on the trust relationships, not on the technical details of the VPN.

The following components are part of the infrastructure:

• Root CA: CA at the top of the hierarchy.

• SubCA-network: Sub-CA administered by the networking department

• SubCA-computers: Sub-CA administered by the computer department

• Laptop: Certificate installed (with the corresponding key pair) on the laptop

• Router: Certificate installed (with the corresponding key pair) on the VPN router

The laptop certificate has been issued by SubCA-computers; therefore, the laptop trusts the SubCA-computers sub-CA. But SubCA-computers has been issued by the Root CA, so the laptop also trusts the Root CA.

The router certificate has been issued by SubCA-network; therefore the router trusts the SubCA-network sub-CA. But the SubCA-network has been issued by the Root CA, so the router also trusts the Root CA.

The common point between the two trust branches is the Root CA, which is trusted by both the laptop and the router. As a result, all other children of Root CA will be trusted by the router and laptop. Therefore, using the entire chain back to the common point (Root CA in this case), the laptop can verify and potentially trust the certificate installed on the router, using the intermediate step of verifying the SubCA-network certificate before trusting it. The same is valid in the reverse direction. (The router can trust the certificate installed on the laptop.)

You are not limited to a single level of subordination: It is quite common to have several layers of sub-CAs, as shown in Figure 2-2.

Figure 2-2 PKI Hierarchy with Multiple Levels

In addition, the different branches do not have to be symmetric in any way: Both the number of horizontal and vertical levels can be different in each branch. Another good reason to build your PKI using hierarchical sub-CAs is that it enables you to put the root CA offline, hence increasing its security. If a sub-CA is compromised, only the underlying subtree would be impacted. A good approach is therefore to align your PKI topology to the administrative responsibility of your organization.

Registration Authority (RA)

A Registration Authority (RA) is also a child in the hierarchy of a CA (or sub-CA); however, its roles and functions are more limited.

Role and Functions

Although a sub-CA has the same roles, responsibilities, and functions as a root CA, an RA receives delegation only for the administrative tasks:

• Receive certificate requests

• Verify requester identity

After those have been performed, the RA contacts its parent CA (or sub-CA) to have the certificate created and issued. The new certificate will then be returned to the RA first, that then handles the final distribution to the requester. Figure 2-3 shows the enrollment process involving an RA.

Figure 2-3 Enrollment Using an RA

An RA is only a frontend to the actual CA. Except to authenticate the transaction with the RA, the requester does not need to establish a trust relationship with the RA because the registration authority does not actually sign any certificate. That means that several RAs can work for the same CA, or that the RA can be replaced easily by another one. The main purpose of the RA is to reduce the load on the CA by delegating some of the administrative tasks: You can see the RA as the front-facing agent, working for the CA.

A trust relationship does exist between the RA and the CA because the CA must rely on the requester identity verification performed by the RA on its behalf.

Endpoint Entities: Users and Devices

This section dedicated to users and devices covers the actual recipients of digital certificates.

Role and Functions

The user or device is a leaf of the PKI tree: It is an endpoint. That means that it cannot issue child certificates further down the chain, so the only thing that can be done with such a certificate is to use it for cryptographic operations involving the endpoint directly. Some more popular uses are authentication toward an IT system (VPN, web server, and so on), digital signature of emails, and content encryption.

Security Considerations

The digital certificate is the digital identity of the endpoint; therefore, it is critical to ensure that it is protected to avoid identity theft. The certificate itself is public information; however, the associated key pair (more specifically the private key) is secret information because it is the one used to generate cryptographic content linked to the certificate.

Although the private key must stay accessible so that it can actually be used, it must be protected against copy or theft. Later this chapter covers several storage means available that can potentially (or partially) address the security challenges. However, for the most basic PKI system, the key pair can be simply stored somewhere on a laptop hard disk with simple password protection.

In summary, using a certificate-based solution does not mean the overall solution is secure; the certificates and keys must be protected as well.

Users Versus Devices

Although digital certificates for devices or human users are technically identical, their storage and usages can differ. A device “acts as configured” when performing certification validation steps. However for users, the human factor plays a non-negligible part. Few people actually read all certificate warnings displayed by web browsers when navigating through the web. This unfortunately typical behavior means users click Accept independently of the message presented, defeating the security mechanisms of PKI. An expired, unknown, or changed certificate should catch your attention that something is not “as expected.” With your PKI knowledge and understanding, a more detailed look at the error or the certificate can clarify what’s actually happening, and the system administrator should be, at a minimum, notified.

Key and Certificate Storage

Secure storage of certificates and associated keys is of utmost importance. Storage is implemented differently, depending on the operating system or media used.

Generalities

As previously mentioned, the certificate is public information; therefore, it does not require any special protection besides ensuring that a copy is available for use. However the associated keys, more specifically the private key, must be secured so that only the actual owner can use it. For certificates bound to a computer or embedded system (a router for example), this is usually achieved through a file system on which the keys are saved using password-based encryption. Although such a mechanism provides an acceptable solution, it also has limitations: The keys can still be copied or stolen, for example, by reading the computer memory after the keys have been unlocked by the legitimate user and loaded in RAM.

Using such storage, the keys are installed only on a given system; therefore, for more agility or when certificates are issued to human users instead of systems, smartcards are usually preferred because they offer additional advantages that will be reviewed.

Microsoft Windows Certificate Stores

In Microsoft Windows operating systems, certificates are located in dedicated certificate stores that you can manipulate through the Certificates snap-in (reachable through the mmc.exe utility). Multiple stores exist by default, each with a dedicated usage: user, computer, and services stores that contain certificates for use by the respective entity. Within each of those, separate folders host trusted root CAs certificates, personal certificates, and others.

In addition to the operating systems stores, third-party applications can have their own repository. The Cisco IPsec VPN Client is an example. Firefox also uses its own certificate manager.

When accessing the appropriate store, you can perform view, delete, import, or export operations on the certificates.

Linux

In Linux, each application has its own certificates and keys repositories. It is usually implemented through a database file stored in the user home directory. If you look at the example of Firefox, it uses the Mozilla shared crypto library consisting of (among others) the cert8.db and key3.db files. Those files can be manipulated to view, add, delete, and export certificates using the certutil utility.

MAC

On MAC, the Apple Keychain is the central security repository for passwords, certificates, and keys. It can be manipulated using the Keychain Access application.

Cisco IOS

In Cisco IOS, keys and certificates are stored through files in NVRAM, as shown in Example 2-5.

Example 2-5 Certificates Stored on NVRAM

Materials can be added through the CLI configuration mode, and part of the information can be displayed through show commands, as shown in Example 2-6.

Example 2-6 Displaying Information About Keys and Certificates on Cisco IOS Router

Using the show running-config command, certificates are displayed using a hexadecimal representation of the DER encoding. Using some PERL scripts for example, you can convert the output to a human readable format.

In Cisco IOS, note that keys cannot be exported unless they have been explicitly marked as exportable at the time of generation.

Cisco ASA

In Cisco ASA (version 8.2 and above), keys and certificates are stored in hidden files on the flash file system. Therefore, the only way to view and manage crypto material is through the command-line interface (CLI), as shown in Example 2-7.

Example 2-7 Displaying Information About Keys and Certificates on Cisco ASA

Similar to Cisco IOS-based devices, certificates are displayed via the show running-config command using a hexadecimal representation of the DER encoding.

On Cisco ASA, you can export certificates and keys using crypto ca export commands.

Smartcards

The computer system-based storages explained previously have one main drawback: The certificates and keys are bound to the system on which they are installed, and they cannot easily be moved between different systems. Smartcards try to address this limitation by providing mobility capabilities, while increasing the level of security at the same time.

Although the most basic smartcards just act as storage devices, the more advanced ones also offer some embedded computing capabilities, making them more secure.

The most common physical formats of smartcards are credit card-like systems with an embedded chip and USB token devices.

Smartcards offer two main functions for PKI implementations:

• Secure storage: Smartcards offer ways to store keys so that they cannot be exported (or copied) afterward. It is therefore (theoretically) impossible to make a copy of the keys or the card. Of course, it must be mentioned that there is a lot of research (and hacking) done into that area to identify vulnerabilities and bypass the security in place. This results in smartcards becoming increasingly more secure.

• Cryptographic functions: Making the private keys unreadable is a good thing from a security point of view; however, how can those keys perform cryptographic operations (signature, encryption, and so on) if you cannot get access to them?

The solution is provided by the embedded computer chip on which cryptographic functions have been implemented. The chip is the only component that has authorized access to the keys. It can perform the crypto operations requested by the system to which the smartcard is connected. For example, if a signature must be generated, the computer sends the data to the smartcard (through the appropriate smartcard reader or USB port), which then returns the signature as a result.

Smartcards are therefore providing a secure solution for certificate storage and use:

• Keys are safeguarded.

• Crypto functions are performed by embedded implementations of the cryptographic algorithm, which can, if certified appropriately, protect against weaknesses as well.

When using smartcards (in their various formats), the crypto system becomes isolated from the user system, preventing tampering problems. Indeed, the use of smartcards increases your control over cryptographic components because they become part of the PKI system you manage. That removes the risk associated with giving the user the possibility to manipulate certificates and keys.

Smartcards also offer some additional advantages for key distribution. The administrators of the PKI can package everything onto the smartcard and ship it to the end user who can then immediately start using it by inserting the smartcard into a reader. Using secure Web access or emails becomes much more user-friendly.

Smartcards also protect the keying material through the use of a PIN, which must be entered by the user before the keys are unlocked and ready for operations. The PIN must be secretly kept by the user and entered into the system through either a keypad on the reader (the most secure solution) or through a graphical user interface on the computer system. This results in a multifactor authentication:

• Something you have: your smartcard

• Something you know: your PIN

Smartcards are becoming quite popular: Most bank and credit cards have been equipped for several years now, and other systems have started using them as well. In Belgium, traditional identity cards (the national version of the passport) have been replaced with smartcards: All citizens now have an official digital certificate issued by the country authorities that they can use to access websites for administration operations, requesting documents, or log in to their bank accounts.

On the device side, all recent Cisco devices are equipped with USB ports to connect cryptographic USB tokens. On ISR routers, Cisco IOS Software already offers a wide set of capabilities to access and use those tokens for all crypto operations and make easier the deployment of PKI-based solutions.

Standards of Interests (ITU-T, PKCS, and ISO)

You can find more information on the protocols and technology referenced in this chapter in the following standards. Although some of these documents are free, others require purchasing from the respective authoring organization:

• ITU-T X.509: “Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks”

• ITU-T X.500: “Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models, and services”

• ITU-T X.680: “Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation”

• RFC-2315: “PKCS #7: Cryptographic Message Syntax Version 1.5”

• RFC-2898: “PKCS #5: Password-Based Cryptography Specification Version 2.0”

• RFC-2986: “PKCS #10: Certification Request Syntax Specification Version 1.7”

• RFC-3447: “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1”

• RSA PKCS #8: “Private-Key Information Syntax Standard”

• RSA PKCS #12: “Personal Information Exchange Syntax Standard”

• ISO/IEC 7816: “Identification cards–Integrated circuit cards”

• ISO/IEC 14443: “Identification cards–Contactless integrated circuit cards–Proximity cards”

Summary

This chapter reviewed the different components that constitute a PKI. First, you looked at what a digital certificate is and then compared the various types of certificate authorities and their interactions in a hierarchical PKI. You analyzed the available techniques to store cryptographic materials so that it is available for use by the end user and devices. Finally, the strengths and advantages of smartcards were detailed as they become more widely deployed in your daily lives.