Public Key Infrastrcuture (PKI)

Public Key Infrastructure (PKI) is a technology whose purpose is to create and manage Digital Certificates. There are both public PKIs (available online) and private PKIs (deployed by any organization for in-house or customer use). The organization that runs the PKI service can be called a Certification Authority or a Trusted Third Party.

Examples of online public Certification Authorities are VeriSign (now part of Symantec), DigiCert, GlobalSign and Comodo.

You can also set up and run your own in-house PKI using various products, including the Microsoft Certificate Services (included free with Windows Server).

There are two Open Source PKI projects, OpenCA and XCA.Most PKIs support the creation of server certs (to enable SSL/TLS on a network server). Some also support the creation of client certs (for S/MIME secure email, strong client authentication with SSL/TLS, etc). See this writeup for information on how to deploy a real PKI with XCA, for server and/or client certs. XCA is free, but it is defintely not for beginners (as you can see from the writeup).

Sixscape Communications has created a very complete PKI based on a comprehensive new protocol (IRP - Identity Registration Protocol). This single protocol supports requesting certificates, downloading them, installing them in your local certificate store, revoking or renewing them, retrieving certs of other users, backing up or restoring your key material securely, and determining validity and revocation status of certs. No other protocol includes all of these functions.

Server certs are much simpler to obtain, install and manage than client certs. This is because only one server cert is required per secure network server. On the other hand, with client certs, a distinct cert is required for every user of the secure system (secure website, secure email system, etc). There may be hundreds (or hundreds of thousands) of users of a single secure network server. Each user must request and certificate and install it in their client computer, or in some cases, the PKI might issue tokens, each of which contains the certificate and private key for a single user. Verifying an applicant's authority to obtain a single server cert is far simpler than verifying the identities of many users. Finally, there is no need to publish a server cert in a directory - client software will automatically download it when it connects to the secure network server. With Client Certs, users may need to obtain the cert of other users, so you may need to publish all of them in an online directory.

PKI is called that because it is primarily concerned with creating and managing just the public key of an asymmetric key pair, in the context of a Digital Certificate. The private key pair typically never leaves the client's computer (for a PKI without key backup/recovery or key escrow).

 

Key Backup/Recovery

It is possible for a PKI to allow users to upload both their public key digital certificate and their private key, encrypted in a PKCS #12 package. This package is encrypted with a pass phrase known only to the end user. The PKI can store this package, and allow the key owner to retrieve it, but only the key owner can recover the key material from it by use of the secret passphrase. It is possible that users could be required to register their passphrase with the PKI operator, or escrow it with a lawyer, allowing the PKI operator to obtain it only under very specific circumstances. Without the passphrase, the PKCS #12 package is of no use to anyone, even the PKI operator. This is called key backup and recovery.

This design requires each user to generate their public/private keypair within their own computer (or possibly within a hardware security token), and then upload the public key in a PKCS #10 Certificate Signing Request (along with identifying information such as their name, their email address, their company, their department within company, etc.) to the Certification Authority. Someone there (called the Registration Authority) must verify the accuracy and currency of that information and approve or deny the certificate request. If it is approved, the Certification Authority builds an X.509 digital certificate from that public key and identity information (adding additional information such as the name of the Certification Authority, a validity period, the valid uses for the digital certificate, etc) and then digitally sign the entire thing using their signing key (normally the lowest level intermediate private key). The resulting issued digital certificate is returned to the user.

Optionally, if the user wants to backup their keying material, they can build a PKCS #12 package from the issued digital certificate and private key (which never left their possession), encrypted with a passphrase known only to them, and then upload that to the PKI's directory, for later retrieval.

In the future, if the user loses their keying material (say their computer crashed or they accidentally deleted their private key), then they could easily restore it by downloading it from the PKI's directory and installing it by use of the passphrase. They could also load their keying material onto additional computers or devices in the same way.

Not all Certification Authorities offer this service. Having possession of user's private keys can potentially compromise that user's security or privacy. It's possible a government or law enforcement agency could demand to be given the encrypted PCKS #12 file, and then require the user to provide the passphrase. A hacker could in theory obtain the passphrase (from a keyboard sniffer on the client's computer) and then obtain the PKCS #12 package and use it. Users can backup their key material to any device (e.g. a USB thumb drive) that can remain in their possession. Providing key backup at the PKI is just a convenience.

 

Key Escrow

This is a very different model for running a PKI. With this, the PKI operator can recover a user's key material (including their private key) without the user's cooperation or even their knowledge. Some government or corporate installations may require this in a PKI.

For this to work, each user's public/private keypair must be created in the PKI itself. The user's digital certificate is then created from the public key and additional identity information. Then the PKI creates a PKCS #12 package containing both the user's digital certificate and their private key, encrypted with a passphrase created by the PKI operator.  The PKCS #12 package and the passphrase must then be delivered securely to the user (e.g. by the HR department, upon verification of their identity). The user then installs the keying material on one or more computers and/or devices, from the PKCS #12 package, using the supplied pass phrase.

This design is much more difficult to make truly secure. If the government or a law enforcement agency demands some user's private key, there is no technical reason it can't be provided to them, without the user's consent or even knowledge.

 

Dual Key Pairs

Legally, if the private key is used to encrypt company or agency information, a case can be made that this information belongs to the corporation anyway, and the user should be aware that other people may be able to obtain access to their private key.

In this case, it makes sense to issue one keypair for encryption (which is escrowed) and a second keypair is issued for digital signing (which is not escrowed). Some cryptographic software (e.g. Outlook) can manage dual keys like this (one for encrypting, one for signing). They only reason to escrow a signing key would be to forge documents in the user's name, which should never be a legitimate thing even for law enforcement or government to do. If there is only one keypair created and escrowed, there is no way to keep it from being used to digitally sign documents if it is obtained by some other party in order to access encrypted documents. If dual keypairs are issued, the digital certificates can be created in such a way that one will only sign and the other will only encrypt (using Key Usage options).

If dual key pairs are used, the keypair for that should be created on the user's computer, and only the digtial certificate should be uploaded to the PKI. If both keypairs are created within the PKI, there is nothing physical keeping the PKI operator from keeping a copy of the signing key.

 

Certificate Revocation

In addition to issuing digital certificates, a PKI must be able to manage certificate revocation. This is done when a user's private key has been compromised, or the user is no longer allowed to use the certificate (maybe they didn't pay their bill for some servivce, or were fired), before the end of the validaty period. This is comparable to your credit card being stolen or cancelled before the expiration date. There is no way the PKI can reach out and delete or mark every copy of a revoked certififcate as invalid. They must somehow allow users to check if a given cert has been revoked before it is accepted as valid. There are two common methods for doing this: Certificate Revocation List (CRL) and Open Certificate Status Protocol (OCSP).

A CRL is a list of revoked certificate serial numbers, digtially signed by the Certification Authority. It contains an expiration date as well. It is published periodcially via HTTP or LDAP (typically once a day, or once an hour). There is no way a client can know when CRLs are published, so it might just miss a newly published list. If a cert is revoked just after one list is published, it will have to wait until the next one is published to be included. This can add up to quite a bit of delay (maybe 2-3 days) from time a cert is revoked, until all clients can become aware of this fact. To check revocation status for a presented cert, the client checks the expiration time on its current copy of the CRL (if any), and downloads a new one if it has expired. It then verifies the digtial signature on the CRL. If the signature is valid, the client checks for the presence of the presented digtial certificate's serial number. If it is not found, then the certificate is valid. Once the client starts checking for CRLs, the expiration date gives some indication of when the next one should be published. Each certificate should have a URL that points to where the current CRL relevant for this cert can be found. There may be many certificate hierarchies at a given PKI. Each hierarchy will have its own CRL.