PKI ingredients
My next project is to explore "PKI" using Active Directory Certificate Services (ADCS).
First of all, what is PKI? And how does it work?
Public Key Infrastructure is a system that manages digital certificates.
This includes requests for certificates by various entities (users and computers), delivery of certificates to these entities, the possible revocation of the certificates and storage of the certificates.
Ingredients of PKI include hardware (servers), software (Active Directory Certificate Services, for example), administrators, and a set of policies governing the use of the system.
Brian Komar includes the following among the "building blocks" of PKI:
- Certificates
- Certificate authorities
- Certificate revocation lists (CRL)
To paraphrase, "certificates are electronic representations of users and computers [...], issued by a certificate authority (CA), [and] associated with a public and private key pair."
From "PKI and Certificate Security" (Brian Komar, Microsoft Press, 2008, p. 21)
Certificates have been compared to "digital passports" - and governments to certificate authorities.
Certificate authorities are a combination of hardware and software that issue certificates, managed by administrators who regulate the distribution of certificates and can revoke them as well - just like a government can revoke a passport.
The CRL is the list of revoked certificates that clients consult so these revoked certificates cannot be used to access a network (for example).
***
Now let's take a closer look at each of these "ingredients" of PKI.
Certificates
Once again, a certificate is a digital passport that proves the identity of a user or computer (or service, network device, driver or software code).
A certificate exists in the form of a small file, literally a couple of kilobytes in size.
Certificates are based on a standard called "X.509" and have evolved over the years. Modern certificates contain information such as:
- the subject of the certificate. This is the name of the user or computer that the certificate represents (like the name on a passport).
- information about the certificate authority (CA) that issued the certificate (just like the passport authority that delivered the passport).
- the "public key" (please see the explanation that follows)
- the serial number of the certificate (this distinguishes it from other certificates issued by the CA).
- the validity period of the certificate (in particular, when it expires - and needs to be replaced)
- key usage or "what the certificate can be used for": data encryption, software code signing and so forth.
- the "CDP" or "CRL distribution points". This is where systems (to which the certificate is presented) can verify that the certificate has not been revoked.
- the "AIA" or "Authority Information Access". This is the location where the certificate of the issuing CA can be found.
Concerning the "AIA", certificate authorities typically function in a hierarchy where a well-secured "root certificate authority" (essentially a server) issues certificates to one or more subordinate certificate autorities (other servers) that issue certificates to end-users. All these certificates must be verified as valid for the authentication of the user (or computer, etc.) to be successful.
So what is a "public key"?
This has to do with encryption.
There are three ingredients to encryption.
- the message or text we want to encrypt
- the algorithm used to encrypt the text
- the key: in simplest terms, this is the password (passphrase) we enter when encrypting and then decrypting the message. In reality, it can be much longer than a word or even a phrase.
There are two main types of encryption:
- symmetric encryption
- asymmetric encryption
With symmetric encryption, the same key is used to encrypt and decrypt the message.
Examples of symmetric algorithms include DES (obsolete), DES3 and AES, which is one of the most current and commonly known standards (there are others).
Symmetric encryption has one disadvantage: once we encrypt our message, we have to send the key to the recipient so they can decrypt the message. Most often, this is not practical. Obviously, we cannot send the key with the message, since anyone intercepting the message would have the key that decrypts it!
Asymmetric encryption uses two different but related keys: a private key and a public key.
The owner of the private key keeps this key secure but makes the public key available.
What is encrypted with one key can only be decrypted with the other.
If I want to send an encrypted messages to someone, I obtain their public key (made available to the public), encrypt the message and send it to the recipient.
But what if someone else has the recipients public key? After all, it is public (at least if one knows where to look).
It simply does not matter: only the private key can decrypt what the public key has encrypted (and not another copy of the public key).
So as long as the private key is secure, the message remains protected.
Two common asymmetric algorithms are "Diffie-Hellman" (named after the inventors) and RSA (Rivest Shamir Adleman).
In fact, there is no opposition (or "rivalry") between symmetric and asymmetric encryption. Most often, the two types of encryption work together. Asymmetric encryption, using the private key/public key pair, encodes the key that is used for symmetric encryption.
Why not just use asymmetric encryption, since it apparently avoids having to expedite an identical key to the partner?
Symmetric encryption and decryption is hundreds (even thousands) of times faster than asymmetric. For a simple phrase, it would make no difference, but when transmitting large amounts of data, it is better to use asymmetric encryption to transmit the symmetric encryption key and nothing else.
Lastly, applications use these algorithms to encrypt (or digitally sign) messages. Strictly speaking, the algorithms do not encrypt or decrypt all by themselves.
There is abundant information online about encryption. For further information, I would conduct a search for "encryption" or "how encryption works" and select the results most appropriate for your skill level.
Certificate Authority
The certificate authority (CA) is essentially a computer (a server) but also involves the intervention of administrators who either approve certificate requests manually or configure a mechanism for automatic certificate delivery.
The CA performs these tasks:
- Verification of the identity of the user/computer requesting the certificate.
This verification can consist in responding to an email sent to a mailbox that only the legitimate requestor would normally have access.
It can depend on the user (or computer) belonging to a particular Active Directory security group and thus having the right to request - and obtain - certain certificates.
In some cases, the certificate manager (the person in charge of the CA) would meet with the requestor face-to-face and require a form of identity (passport, driver's license).
- Delivery of the certificate to the requestor
- Revocation of certificates
For example, an employee uses a smart card, in which their certificate is electronically embedded, to access a secure area. The employee looses their smart card. The CA must revoke the certificate so it can no longer be used to grant access, and make available an up-to-date list of revoked certificates that the authenticating devices can consult.
The certificate authority can be a single server but most often involves several servers organized in a hiearchy of two to three levels (or tiers).
At the summit of the hierarchy, we have the "root CA".
At the lower levels, we have "subordinate CAs". They can be "intermediate CAs" that issue certificates to another level of CAs or issue certificates directly to users or computers. In this case, we call them "issuing CAs".
Most often, a two tier hierarchy is sufficient but it is possible to have a single CA (in very small PKI implementations) or even more than two or three tiers in very large and complex implementations.
CRL (Certificate Revocation Lists)
As already mentioned, it is sometimes necessary to revoke a certificate because it has been compromised. The CRL is a list of all revoked certificates.
There are two types of CRLs:
- base CRL: a complete list of all revoked certificates
- delta CRL: a list of certificates revoked since the last base CRL was published.
Only a base CRL is absolutely necessary. The delta CRL, smaller by nature, can be useful if the base CRL is very large and we have limited bandwidth.
OCSP (Online Certificate Status Protocol)
Since Windows 2008, there is a new variation to the consultation of the CRL by clients. OCSP servers obtain a copy of the CRL and clients query the OCSP server instead of the CA. The OCSP server (also called OCSP responder) consults the CRL on behalf of the clients and lets them know if the certificate in question has been revoked. OCSP represents an additional level of complexity but avoids the need to download (repeatedly) potentially large CRLs.
Regardless, OCSP is optional.
***
Lastly, Active Directory Certificate Services (ADCS) is the Windows Server Role that allows us to deploy the Microsoft version of PKI.
Thank you for reading the article about PKI (Public Key Infrastructure) with ADCS, Part 1: Introduction on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.