Public Key Infrastructure part 2 – main components

• Public Key Infrastructure Part 1 – introduction to encryption and signature
• Public Key Infrastructure Part 2 – main components
• Public Key Infrastructure Part 3 – implement a PKI with Active Directory Certificate Services
• Public Key Infrastructure Part 4 – Configure CRL
• Public Key Infrastructure Part 5 – Registry key, certutil and Active Directory
• Public Key Infrastructure Part 6 – Manage certificate templates
• Public Key Infrastructure Part 7 – Enrollment and Autoenrollment
• Public Key Infrastructure Part 8 – OCSP responder
• Public Key Infrastructure Part 9 – Management accounts
• Public Key Infrastructure Part 10 – Best practices about PKI

Public Key Infrastructure

Certificates

As you have seen previously, encryption and signature operation are performed with public and private key. These two keys are mathematically related. So when an entities (users or computers) want to receive encrypted or signed data, it generates a private key and send the public key to its correspondent. The correspondent performs the same process. This is called the Key Exchange.

The first problem of key exchange, is that the key must not be duplicated by malicious guy. So it is necessary to create a secure channel to make the key exchange. The solution can be physic with a diplomatic bag for example. In 1976 a popular person called Diffie Hellman published a secure key exchange protocol called DH key exchange (Diffie Hellman key exchange). Thanks to DH, a secure channel can be used for the key exchange. But this protocol doesn’t resolve the second problem: how to be sure that the public key belong to the owner that claim to be?

This is why digital certificate (called sometime public key certificate) has been created. A certificate is a digitally signed document containing the entity information (such as name, postal address, E-mail etc.). In this way, it is possible to be sure that the public key belongs to an entity.

Usually the certificate is signed by a trusted third party called Certificate Authorities. A certificate has an expiration date, information about key using (encryption, signature or both) or the certificate using (authentication server, E-mail signing etc.).

Figure 1: Example of a certificate: outlook.com

The above certificate (figure 1) is delivered to the entity mail.live.com by a certificate authority called VeriSign. This certificate has a validity period from May, 21^st 2013 to May, 23^rd 2013.

Figure 2: Example of certificate: detailed information

Certificate contains other details such as:

• The asymmetric cryptography algorithm;
• The subject Alternative Name that contains other known identity of the entity;
• The hash algorithm;
• Key usage;
• The Certificate Revocation List (view d. Certificate Revocation List section);
• The Authority Information Access (view Authority Information Access).

Certificate is based on a standard called X.509 to be sure that the certificate is interoperable. This standard defines a certificate structure. For example the entity and certificate authority identity must be distinguished name as LDAP protocol (X.501 standard). For more information about X.509 please read RFC 2459 (https://www.ietf.org/rfc/rfc2459.txt).

Certificate Authority

A Certificate Authority called CA, is the trusted third party that digitally signed certificate. So it is the CA that approves certificates that ensures that public key belong to an entity. So it is a critical component in security.

Because a CA digitally sign certificates, it needs also a public and a private key and so a certificate. This certificate can be self-signed by the CA or signed by a top CA. When a CA uses a self-signed certificate, it is called a Root CA while in the other case it is a subordinate CA (called also Sub CA or intermediate CA).

A certificate authority performs mainly these actions:

• Issue certificate requests by signing them;
• Revoke certificates for many reasons (end of validity, compromised key etc.).

A Public Key Infrastructure (PKI) can be composed from one to many Certificate Authorities. Usually at least two certificate authorities participate to a PKI: one Root CA and one Sub CA. A PKI is always composed of one Root CA. The others CA are Sub CA.

Root CA or Sub CA can sign CA certificates or client certificates but as best practices, it is recommended that:

• Root CA should sign only CA Certificates;
• Sub CA should sign for CA certificates OR client certificates but not both.

For example, a PKI architecture can seems as Figure 3.

Figure 3: Example of PKI design

The Root CA signs the CA certificate for Sub CA Users and Computers. The Sub CA users signs Sub CA certificates of Marketing and Engineers. To finish Sub CA marketing and Engineers sign certificates for users while sub CA computers signs certificates for computer.

When a user or a computer uses a certificate, it must verify the validity of its certificate authority and all CA on top until the Root CA: it is called the chain of trust.

Chain of trust

All certificates from Root CA to end-users either a computer, a user, a CA or other entity, is called the chain of trust. When a certificate is used, each certificate in the chain of trust must be checked. Figure 10 is a screenshot of outlook.com certificate on certification path tab. This chain of trust is composed of:

• A Root CA called VeriSign;
• A Sub CA called VeriSign Class 3 Extended Validation SSL SGC CA;
• The end-user certificate.

Figure 4: Chain of trust of outlook.com certificate

When a user connects to outlook.com, he verifies that the certificate is valid from the intermediate CA. But the user must verify also the validity of the intermediate CA certificate from the Root CA VeriSign.

Certificate Revocation List

As I said previously, certificate authorities can revoke a certificate. When a certificate is revoked, it must be no longer useable. This is why Certificate Revocation List (CRL) exists. Each time a certificate is revoked, its ID is added to a file called CRL. This CRL is signed by the CA itself.

To be available to entities which use certificate, CRL is published on distribution point called CDP (CRL Distribution Point). It can be a Web Server, an LDAP server such as Active Directory or a share. These CDP are added to the certificate in CDP extension. Many CDP can be referenced in the CDP extension.

Figure 5: CDP extension of outlook.com certificate

When a client checks a certificate validity, it downloads the CRL referenced in certificate CDP extension. If several CDP are included in CDP extension, the client will download the CRL from the first location. If the client can’t download the CRL from this location, it will attempt with the next CDP included in CDP extension and so on. The CRL is downloaded and cached by the client for the validity period of the CRL.

For example if a CRL has a validity period of 3 days, the CRL will be cached by the client for 3 days. Once 3 days have passed, the client download again the CRL.

Moreover, more the CRL validity period is longer, more you take security risk. If a certificate is revoked when the client has cached the CRL, the client will not know that the certificate is revoked. This topic will be discussed in Design Part.

CRL can become a very large file if your organization revokes regularly certificate. It can be a problem for your bandwidth and sometime because the CRL is very large, the threshold time limit to download CRL can be reached. That result that the revocation checking process fails. To limit these issues, Delta CRL can be used.

Delta CRL is a partial CRL that contains revoked certificate IDs since the last CRL has been published. In this way CRL validity time can be lengthy and the publication of Delta CRL can be performed regularly. So the client will download the CRL for a greater period of time and will download only Delta CRL most of the time. That result to save bandwidth.

Figure 6: Outlook.com certificate CRL

As you have seen, CRL presents some disadvantage:

• CRL can become a large file that result bandwidth issue;
• The validity period must be balanced between bandwidth saving and security risks;
• Depending on where the CRL is located, some client can’t access to it (for example if CRL is hosted on Active Directory, usually the internet client can’t download it).

To resolve CRL disadvantage, an alternative protocol can be used: Online Certificate Status Protocol.

Online Certificate Status Protocol

Online Certificate Status Protocol (OCSP) is a standard protocol used to validate the certificate. OCSP uses ASN.1 as data structure. Usually and in Microsoft world, OCSP uses HTTP to transport messages. OCSP uses the model client/server and the OCSP server is called OCSP responder. Sometime OCSP responder is also called Validation Authority (VA).

When an OCSP responder is asks about certificate validity, it indicates just the certificate status. So the data transmitted over network between OCSP responder and client are always the same, independently of the number of revoked certificates.

Except some case, OCSP relies on CRL published by CA to determine the certificate status. But when an OCSP responder is used, only it will download CRL and no longer clients. So the CRL validity period can be reduced regardless bandwidth saving.

The OCSP responder signs each response made to client with its own private key. So the integrity of this key must be checked by the client after that OCSP responder sends a status.

Because OCSP is usually based on HTTP, the client doesn’t cached a revoked certificate database as CRL process. So each time a certificate must be validated, a request is sent to OCSP responder. So in large PKI infrastructure, OCSP responder can be overloaded and so requires load-balancer and geographical deployment to ensure high-availability.

Authority Information Access

To validate a chain of trust, each certificate in this last must be checked. To validate certificates, the client must access to it to be sure that the certificate is in validity period and to find related CRL or OCSP responder.

Authority Information Access (AIA) is used to locate CA certificate. AIA contains the CA certificate path and is referenced in certificate AIA extension. AIA can indicate CA certificate path over HTTP, LDAP or share.

Figure 7: AIA extension in Outlook.com certificate

Public Key Cryptographic Standards

Public Key Cryptographic Standards (PKCS) are a set a “standards” to describe some cryptographic process. I have written the word standard between quote because it is not really standards. PKCS specifications are published by RSA Security (belong to EMC since 2006) company and only a few of them are taken up by the normalization agency.

PKCS specifications are numbered after a hash. For example the DH key exchange is called PKCS#3. In this part I will not present you all PKCS specification. Only the most important to understand PKI are described. For more information, you can visit https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-rsa-cryptography-standard.htm.

PKCS#7 (RFC 2315)

PKCS#7 is standardized by the IETF as RFC 2315. This standard defines syntax for cryptographic message either to sign or encrypt data. This standard also describes how to respond to a PKCS#10 message.

PKCS#7 certificate is based on PKCS#7 specification and it is a X.509 certificate as described previously. PKCS#7 certificates can have these file extensions: .p7b, .p7c, .der, .cer, .crt or .pem. On Microsoft environment, .cer and .der are mainly used.

PKCS#10 (RFC 2986)

PKCS#10 is standardized by the IETF as RFC 2986. This standard describes the certificate request process. Usually this request is sent to a certificate authority. The CA can sign the request and so issue a PKCS#7 certificate. On Microsoft environment, the certificate request file has .req, .csr or .txt extension. On other environment, this file can be found with .p10 extension.

The certificate request contains the identity of the issuer and his public key. The certificate request is signed by the private key of the issuer.

PKCS#11

PKCS11 is an API for security token such as HSM (Hardware Security Module) or Smartcard. When you plug a smartcard on your Windows, the communication is done across PKCS11 API. Usually this API is added to system when you install the smartcard drivers.

PKCS#12

PKCS#12 specification describes how to store and transport safety private keys, certificates or other sensitive information. PKCS#12 file act as a container usually protected by password. Because PKCS#12 can store certificates, the chain of trust can be included in the file. On Microsoft environment, the PKCS#12 file extension is .pfx. On other environment it can be found as .p12 file.