Special Report: Government Security - How to Get FIPS Compliant

A government access control roadmap to credentialing, authentication and validation

Furthermore, because each PIV card contains a unique identifier called a FASC-N (the unique identifier on PIV-I and CIV cards is the UUID), new functionality must be added to extract the unique identifiers from the card data and use them in the access control decision process. Another new functionality that must be performed as part of the enrollment process and at the time of access includes incorporating a level of authentication and validation to ensure secure use of the PIV.

To get the record of the PIV card into the PACS cardholder database, there are two approaches. One involves each PIV card being created by an authoritative data source, which is typically the identity management or card management system that encoded the personal information onto the PIV card’s chip. This data source may be able to provide card information in a format that a PACS can use. In most cases, middleware is required to link these two systems in order to accomplish the data exchange. But in the absence of a data feed from the authoritative data source, PIV cards themselves have much of the information required to populate a PACS cardholder record.

Another approach involves using a software package that has the ability to harvest data from a PIV card and provision the information into the PACS database. Still, because the authoritative data source is not involved, it is important to maintain some level of authentication and validation to ensure that the PIV card being registered is authentic and not a clone or forgery.


There Is No Substitute for Authentication

Without a doubt, ensuring that a PIV credential is authentic is one of the most important steps to achieving FIPS 201 compliance. For PIV cards, there are five basic threats associated with authenticating a user claiming to be the person identified on that PIV card.

1. Counterfeit credentials: At the point and time of access, it is imperative to know that the presented identifier is genuine and has not been forged or changed by someone seeking unauthorized access. A digital signature, such as certificates, fingerprint template or facial image, can mitigate the threat.

2. Cloned or copied PIV cards: Executing a PKI private key challenge to ensure the certificate (through its public key) is bound to the private key embedded in the PIV card can address this problem. This process binds the identifier contained in the certificate to the card to which it was issued.

3. Stolen cards: From time to time, a PIV card might become lost or stolen. To make sure that the person presenting the card is the same person who was issued the card, the PACS system can require a PIN, something that only the legitimate card holder would know.

4. Shared cards: To protect against shared identities, a biometric — something that cannot be shared and is only possessed by the person to whom the card was issued, such as a fingerprint — can be used as part of the authentication process.

5. Revoked cards: In the event that cardholder no longer has the authority to use the PIV card, such as when an employee leaves the agency or company, the PACS can periodically check for new revocations of credentials by the trusted authority.


Validation: What You Need to Know

Validation during enrollment should include several checks and balances to ensure that all enrollees are in fact who they claim to be at the highest level possible. This would typically be done as a function in conjunction with the PACS head-end.

Validation at the time of access will involve a subset of these checks depending on the assurance level required and authentication mechanism chosen for the specific access point being addressed; however, the question of where this validation should be done is more challenging. It can take place at multiple locations, including the head-end, the reader, at the panel/ door controllers or involve a separate module.

At the head-end: Performing time-of-access validation at the head-end would seem to be a logical choice, since it could take advantage of the full PKI validation functionality used for enrollment. This approach would require adding new wiring to support two-way communications between the readers and the head-end to facilitate signature checking on the credential data elements (CHUID, certificates, biometric templates), execution of a private key challenge and execution of a biometric match. In most cases, this would be prohibitively expensive. In addition, this approach would fail to operate properly during a loss of power or reader to head-end communication.