The introduction of the PIV card represents a major step forward in the standardization of access control within the federal government. There is now one standard identity card that is centrally issued and is recognizable and trustable by all government agencies.
According to a memo issued in 2012 by the Office of Management and Budget, called OMB M-11-11, “logical access control systems must be upgraded to use PIV credentials, in accordance with NIST guidelines, prior to the agency using development and technology refresh funds to complete other activities.” Because of this, it’s important for security professionals to truly understand how to upgrade their PACS to achieve a FIPS-201 conformant physical access control solution.
While using the PIV card in existing physical access control systems (PACS) will require some changes, it will not necessitate a wholesale rip-and-replace of existing PACS components, including door controllers and door readers. Still, conforming to FIPS-201 involves a multi-step process that goes beyond thoroughly understanding all of the components that comprise of a FIPS-201-compatible PACS to also encompass knowing how to select the right PIV enabling solution, how to get that data into the system and how to validate the credential.
By following a few steps, it is truly possible to accomplish a secure and interoperable approach with PIV identity cards that is both cost-effective and provides a strong PKI based validation at the time of access.
Compatible Credentials
By upgrading existing PACS as opposed to deploying new ones, security professionals have several potential approaches to enabling the support of FIPS 201 credentials. Some of these are less costly and more secure than others. Regardless of the approach taken, a suitable approach to PIV enabling an existing PACS should meet the following criteria:
- Minimal custom modification, which is typically expensive and difficult to maintain when compared with a commercial, off-the-shelf approach.
- Don’t box yourself in: A PIV-enabling solution should not be tied to a specific make or model to ensure that future upgrades of the PACS components will be much easier to achieve.
- GSA approved: GSA’s FIPS 201 Evaluation Program provides an Approved Products List (APL) with four “Authentication System” categories: CHUID Authentication System, CAK Authentication System, PIV Authentication System and BIO Authentication System. In addition to the four “Authentication System” categories identified by the GSA APL, NIST Special Publication 800-116 identifies four authentication mechanisms suitable for controlling access to “controlled”, “limited” and “exclusion” areas. The PIV enabling solution should support all of these mechanisms and provide the capability to dynamically switch between them in response to changes in threat level.
- Support for both PIV-I and CIV cards: PIV Interoperable cards are used by federal contractors who are included in the HSPD-12 mandate and may need access to a controlled facility. This capability will enable PIV-I visitors as well as temporary PIV-I cardholding employees to use the access control system. CIV cards have the same technical format as PIV-I cards and are technically usable in a PIV-enabled access control system.
Understanding PIV Credentials and Enrollment Options
In order to use a PIV card to open a door, the system needs to be capable of reading the card. Also, a record of that PIV card must exist in the PACS cardholder database. A PIV card is as an ISO 14443 type smart card with a contactless interface that operates at 13.56 MHz. The most common identity cards in use today are contactless proximity cards, which operate at 125 kHz. This creates an incompatibility in communication protocol and in some cases to support the contact interface it may require replacement of the readers.
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.
- 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.
- 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.
- 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 that was issued the card, the PACS system can require a PIN, something that only the legitimate card holder would know.
- 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.
- 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.
At the reader: Replacement readers could include the validation functionality; however, the new readers would require more powerful (and costly) processors to perform the cryptographic processes associated with PKI validation. This approach also requires two-way communications with external networks or the head-end in order to receive periodic downloads of certificate status data, trust anchors for signature verification and to service path discovery requests for any visitors with PIV or PIV-I cards.
At the panel/door controller: Putting the time-of-access validation into the panel or door controller components is a more attractive approach in that it addresses most of the deficiencies and security issues associated with the first two strategies. This is because security-related processing is performed on the secured side of the PACS boundary. This approach also supports the potential for less rewiring; and the system would continue to operate in the event of power loss due to a battery backup.
A separate module: An alternative to upgrading or replacing all the panels and/or door controllers is to augment the existing system functionality with the addition of a new “plug-in” module. To be successful, this new module must work with existing PACS panels and door controllers as they are, without any changes. This approach is the most cost-effective way to enable PIV.
Regardless of the approach taken to upgrade the PACS to achieve a FIPS-201 physical access control solution, security professionals should keep mind that changes touch a few key areas. Make sure that any new card readers installed are technically compatible with the physical characteristics of the PIV card and add the ability to read and interpret the data on the PIV card. And, using strong PKI based validation at enrollment and time-of access will guard against cloned, forged or revoked credentials.
Bob Dulude is director of the Federal Identity Initiative with HID Global Corp. To request more info about HID, visit www.securityinfowatch.com/10213866.
