At its core PKI is all about certificates, how they are created, what information they contain, how they are used, the level of trust you put into them, what happens when they are lost and the simplicity of using them.
Looking at what kind of services PKI enables, secure remote access, wireless security, data cryptography, it is obvious that you want to remain in control of the infrastructure. If someone else would gain control of the service to issue certificates an outsider could be able to authenticate as your own users. When a Certificate Authority is compromised, the CA and all the certificates below in the PKI hierarchy has to be revoked and replaced. This is because you can no longer trust that branch. In short you need to be able to trust your PKI environment. Further the level of trust you, or the users of the PKI environment, have in the infrastructure will determine what the certificates can be used for. For some organizations who aren’t concerned about security this will be a non issue, they will just install the certificate services in a next-next-finish manner without giving it much thought. This could be viewed as a bad idea, however if it replaces a system where every monitor has a post-it with a username and password it’s still an improvement compared to before.
On the other hand if you want to use your PKI environment to issue certificates which will be used to access the internal network of a partner organization, they the partner will have to trust your PKI setup. Another example could be if you were to use the certificates to digitally sign financial transactions, in this scenario all parties who use the solution will have to trust the PKI environment.
In order to establish trust in the PKI you can write a Certificate Practice Statement (CPS) which is a document you create which describe your PKI setup, how you operate it and your requirement and procedures for issuing certificates. Individual certificates might also have certificate policies which describe which requirements must be met before a certificate of a certain type is issued. For example you might have a requirement that people enrolling for a smart card login certificate must show an id badge to prove their identity along with a digital signature from a manager. At the other end certificates could be automatically distributed to the computers and users on your organization.
The Certification Authority or CA is the service which is responsible for issuing and revoking certificates. This could just be a simple setup with a few (yet powerful) scripts using OpenSSL, an open source certificate toolkit, or a packaged solution such as Microsofts Certificate Services.
Through the CA software you configure the parameters for the certificates the CA will issue, along with the requirements your clients must fulfill in order to be able to enroll for a certificate.
Every digital certificate is connected to a key pair, one private key and one public key. The public key will be included in the certificate. As the name implies this information is public for all the world to see, or at least for those who will use the certificate. The private key is the counterpart to the public key and is private to the entity (person or a computer device) who will use the certificate. When information is encrypted with the public key only the private key can decrypt it. On the other hand when information is encrypted with the private key only the public key can decrypt it.
So when my friend Marien wants to send me something encrypted which only I can read, he will encrypt the information with the public key he finds on my certificate. Since I am the only one who have access to the private key I am the only one who can decrypt the information. This way confidentiallity is ensured.
Looking at the reverse scenario if I want to digitally sign a message I send to Marien, I will create a hash of the message and encrypt (sign) the hash using my private key. My friend would then be able to use the public key from my certificate and decrypt the signed hash. Since he is able to decrypt the hash with my public key, he knows that the private key was used to sign the message i.e. I signed it.
Though the private keys should only be known to the person to which the certificate belongs, there are scenarios where you will want others to be able to gain access to the private keys. This mostly depends on what the certificate will be used for. If you will use the certificate to encrypt data, all your data will be lost of you lose the private key. For example if your private key is stored on a smart card and the card is broken (perhaps you have a dog or kids?) or lost you won’t be able to read your data. To mitigate this risk the CA could be setup for key archival where the CA stores your private key for later retrieval. You could set this up so that it requires that several people have to digitally sign the approval to retrieve the private key.
If you only use the certificates to login to a service, you can just generate a new keypair and issue a new certificate if the private key is lost.
Once the public and private key pair has been generated the public key can be inserted in a certificate request which is sent to a certification authority. Along with the certificate request other information could be used, such as the name which will be included in the certificate. For a SSL certificate this would be the name of the website for example secure.networklore.com. Although information can be added in the certificate request (CSR) it is up to the CA to determine which information is kept and which information the CA will add regardless of what has been included in the CSR. Some CAs will ignore everything in the request and just keep the public key, while others require certain fields to match the requirements of the CA.
Enrollment can be manual where a file is generated and manually sent to the CA. In many cases this will mean posting a hexadecimal string into a web form and later returning to retrieve the certificate.
Using a Windows enterprise CA, enrollment can also be automatic where group policies are used to auto enroll machine or user certificates.
Once the CA has received an enrollment request the CA administrator can choose to issue the certificate or deny the request. With the auto enrollment option the certificate might also be issued without any interaction from the CA administrator.
When the certificate is issued it will be signed with the CAs private key. Anyone who trusts the CA can then verify that the certificate was signed by a trusted party, since they will have access to the CA certificate and its public key it is easy for them to use the public key and verify the new certificate.
Once the CA has issued a certificate it will include the public key along other certificate information. Together with the private key a user can now use the certificate to decrypt information sent to the user, or encrypt information which others can decrypt and thereby verify with the certificate itself.
If I have an email certificate and want to send you a digitally signed email, I don’t need to know anything about any certificate you might have since I will only use my own private key to sign the email. However if I am to send you an encrypted email I will need to have access to your email certificate so I can use your public key to encrypt the email. If I want to be able to read the email after I send it to you, I will also have to encrypt the email using my public key. That way you can decrypt the email using your private key and verify the signature with my public key. Also I can decrypt my own email with my private key since I also encrypted it with my private key.
If there is key archival setup I will want to use two email certificates. One for signing and one for encryption. I will get back to why I would want this further down in this article. Can you think of a reason now?
When talking about digital certificates there are “soft certificates” and “hard certificates”. A soft certificate is a file placed on your computer and a hard certificate is a certificate placed on a device such as a smart card. Though a private key can be marked as non exportable there are ways to circumvent this in Windows and gain access to the private key and move it to another system. Technically it is much harder to export the private key from a smart card.
Aside from email encryption and signing, there are a lot of scenarios where you can use PKI and digital certificates.
You can setup certificate based VPN. When you have site to site VPN between known locations with static IP addresses the benefit of PKI isn’t really security. It actually adds dependencies where the VPN routers need to have access to the CRL distribution points, so you could argue that the operational security is decreased because of the added dependencies. However you can still benefit from using certificates in terms of ease of use. If you don’t use certificates you have to authenticate with pre shared keys (private key encryption), and the problem here is that you have to distribute the key to the other location. The more VPN tunnels you have the more keys you will have to generate and distribute. If a router has 10 IPSec VPN connections to other locations it will have to hold 10 different pre shared keys. If you have a mesh setup where all the offices connect to each other you will end up with a lot of keys, instead of just 10 digital certificates. One certificate for each router.
However if the VPN consists of dynamic clients, i.e. remote access VPN where users login with client certificates there is a large gain by using certificates. Also with site to site VPN connections you might have offices using with DHCP addresses where you don’t know which address they will connect from. In this case use of a PSK would require all the connections to use the same key. If you are setting up DMVPN you will want to use certificates to authenticate dynamic VPN connections.
Another obvious usage scenario is plain old SSL for websites. When you shop online or do online banking a PKI certificate will allow you to encrypt the information you send to the server. Also since the server presents a certificate to you you can, using the information within the certificate, verify that it is a valid certificate and that it chains back to a Root CA which you trust. By default there will be a few trusted Root CAs installed to your operating system.
If you are setting up 802.1x authentication, for either wired or wireless you can use PKI and PEAP or EAP-TLS to secure the setup.
Code signing is another use of PKI where a developer can digitally sign her code to let users verify that they are running code that was written by a developer they trust.
With smart cards you can use PKI to allow your users to login without having them to remember complicated passwords. There are organizations who have implemented smart cards for the sole reason of saving costs after vacation times when a lot of users forget their passwords and call the helpdesk in order to reset their passwords.
Did you think about why you would need two email certificates if you use key archival? Since you can sign an email with a certificate which intended purpose is digital signing you don’t want anyone else but you to have access to this key. That would mean that they could impersonate you and sign documents or emails on your behave. So if you want to protect your encrypted data from loss it is a good idea to archive your private key in some manner. However if you lose the private key for the signing certificate no data has been lost, and you can just generate key and certificate in order to continue to sign other documents or emails.
With private key encryption, or in a login scenario where you authenticate with username and password, the password can be lost or compromised. This could be a misplaced post-it note, it could be because of shoulder surfing or the fact that the name of the users dog isn’t a secret at the office. With private key encryption the user can talk to the network administrator and setup a new private key or password if you will.
However with certificates there isn’t any shared secret which we can change if the private key has been lost or compromised. But we still don’t want anyone to be able to use a stolen private key to be able to login or authenticate using the certificate. Though we can’t change any key we can revoke the certificate, this way telling the world that a particular certificate has lost its validity.
When a certificate is revoked it is added to a Certificate Revocation List (CRL). An entry is added to the list which contains the serial number of the certificate which is to be revoked along with a time stamp which says when the certificate was revoked. Optionally you might see a reason for the revocation, such as key compromise or certificate superseded. The CRL is then signed by the CAs private key and assigned a validity period.
Once the CRL is signed it is then placed on a CRL Distribution Point (CDP). Upon verifying a particular certificate the information within that certificate will contain information for the CDP so the person or program verifying the certificate can access the CRL. The CDP is generally a HTTP URL or an LDAP URL. If the certificates serial number isn’t listed in the CRL the certificate is still valid. The downloaded CRL is often cached for the remainder of its validity period.
The process of revoking certificates only protects against compromised keys when they are used to access a service. If you lose your private keys to your laptop encryption, an attacker will be able to use the key and certificate to decrypt your data even if the certificate has been revoked. The solution is not to store your private key together with your data.
This post is part of the Getting Started with Public Key Infrastructure series.