US Federal PKI: Part I - Getting Started and the Value of Validation

Understanding the Basics: Bare Necessities

In order to understand Federal PKI systems, it is first imperative to understand the concepts, components, and challenges around it. The following are high level overviews of these topics.

What is PKE?

Public Key Encryption is a type of asymmetric encryption, used to ensure confidentiality, integrity, and nonrepudiation of a message. In Public Key Cryptography, the user has a private key, which only they will ever have, and a public certificate that is published for external use. The private key and public key work in opposites to encrypt and decrypt data. Anything encrypted by the public key can only be decrypted by the private key, and visa versa. The benefit here is that anything a user signs with their private key proves that they did in fact sign it, as only they have that key. Anything encrypted with the user’s public key, can then only be decrypted by them.

What is PKI?

Public Key Infrastructure is the underlying process, policies, and services that make up the generation, distribution, and revocation of the key pairs.

What is Identification?

The process of proving an identity through supporting evidence, in our discussion through a Smart Card credential.

What is Authentication (AuthN) and Authorization (AuthZ)?

This is the idea of ensuring a credential is authentic and legitimate, as well as determining if they can access a resource. This is effectively used to answer the question “Who are you, how can I be sure, and what are you allowed to do?”.

What is a Credential?

This is something that a user can bring and use or present to identify themselves. This could be a username/password set, biometrics, or a digital certificate, perhaps housed on a smartcard. This is effectively used to answer the question “What can you give me to prove who you are?”.

What is a CAC, PIV, PIVi, etc.?

These are Smart Cards that house the keys used for PKE on tamper resistant chip, embedded in a card, that can be read and used as part of the AuthN/Z process to identify US Federal employees and contractors. They apply to certain standards and guidelines, and are used for identification and authentication of users for both Physical Access Control Systems (PACS) and Logical Access Control Systems (LACS).

What is Validation?

This is the process of seeing if a credential, while perhaps authentic, has been revoked due to issues around the user or the creation of the credential itself. This is effectively used to answer the question “Can your credential still be trusted, even if it is authentication and not expired?”.

The Value of Validation: Illustrating the Issue

One issue we have seen over and over with PKI deployments are solutions that ignore the value and power of validation. The best way I have found to illustrate the issue is looking at a US Driver’s License.

 

Let’s look at how this applies to the concepts we have already covered.

• Credential: This ID in itself is something a user can bring to prove their identity.
• Identity: It is simple to look at the picture, sex, eye color, height, and age of the person compared to the ID to get a good idea of if the identity they are asserting is true.
• Authentication: We can see the patterns, security text, and other unique identifying features of the license to derive a level of assure that the credential presented is real.
• Authorization: By looking at this ID we can confirm things about what this person is allowed to do. For example, there is no ‘M’ class license code, so this user cannot drive a motorcycle on the road legally. The user’s DOB can be used to indicate if they meet age restrictions to enter an establishment.

Putting aside any manipulation to the image here to obfuscate information, and assuming an authentic credential with an appropriate DOB, given what we see here, can the user drive a sedan in Virginia? The initial answer might seem like it is yes.

What if the user was caught driving 130mph in a 25mph zone however? They very well could lose their privilege to drive a car for a period of time. How is that actually relayed on this ID though? It is not reprinted with that restriction noted, in fact there is no manipulation at all. How therefore can we confirm such a thing? In the case of the driver’s license, you would query a DB that contained this information.

A similar need exists with PKE credentials. If a user holds a credential for an agency or contractor and is then fired or changes companies, it is necessary to be able to check if the credential they hold, even if authentic and not expired, is still valid. The method to do this lies in the use of a Certificate Revocation List (CRL).

Understanding the Basics: Extending the Understanding

To better understand why this is an issue and how we can resolve it, first we must delve a bit further into the PKI issuance process.

What is a Certificate Authority (CA)?

Simply put, this is an entity that issues digital certificates. The CA asserts that the person they issued the credential to owns the identity relayed on that card. There are a few terms that help us to define a CA relationship however that need to be examined:

• Issuing CA/Issuer: This is the CA that directly asserts the identity relayed through the PKI credential.
• Trust Chain: An issuing CA may have been issued by another CA. Think about Linkedin and how you may have a connection in common with a second degree connection. If that second degree connection asks to speak to you, you may speak to your mutual connection who you trust to give you assurances about that person. Similarly, you could think about a messenger that comes bearing a king’s seal to prove the source of the message. A trust chain is a hierarchy that works under the assumption that if you trust the person at the top of the chain, who asserted the identity of the next person, who asserted the identity of the next person, all the way down to the end user, then since you trust the top level person, you can trust the people in between.
• Trust Anchor: A CA you trust. If you can trace a trust chain from the issuer to this trust anchor, you can trust the issuer.
• Intermediary CA: A CA that lies between the end user and the trust anchor.
• Root CA: The highest level CA. This CA has no issuer. It is top of the pyramid and all other CAs in its hierarchy can trace back to it.

What is a CRL?

If a CA asserts your identity on behalf of themselves, and finds cause to need to nullify that assertion, there needs to be a way for the CA to do so. A CRL is a list of revoked certificates that is publically published by a CA to confirm if a previously issues certificate is now invalid.

How is this Tracked?

A properly created certificate will include the CRL Distribution Point (CRLDP), or web/ldap address, and information identifying its issuer in the AIA field. As a result, all certificates should allow you to build a trust chain and check for validation if properly created.

The Value of Validation: The US Federal Bridge

How does all this play into US Federal? The US Federal Bridge is unique in that all Smart Cards chain back up to a single trusted root authority. This means that if a key pair has been properly generated, you should be able to manage identification, authentication, and validation for any Smart Card out there for any user or system, for both PACS and LACS solutions. Once this has been ascertained, all that is left is authorization to determine if they are allowed to access the location or resource they request. 

If this capability is utilized properly, this means you never would need to issue contractors, non-Federal public sector staff (state/local), or other government agencies (OGAs) credentials for your agency again. Furthermore, there would never be the concern that if the resource was fired or transitioned from their parent entity that they would have the opportunity to leverage a separate set of credentials for your environment. Utilizing a CRL allows for global revocation from a single source of truth (SSOT).