Columnist Adam Shane is a product manager with AMAG Technology and the company's primary technical interface with the federal government and physical security industry efforts on standardization.
In November 2008, the National Institute of Standards and Technology (NIST) released a new document that will likely have significant impact on all physical access control systems (PACS) in use at federal government facilities today. The new document is called Special Publication (SP) 800-116 and is titled "A Recommendation for the Use of PIV Credentials in Physical Access Control Systems (PACS)" (download PDF of NIST SP 800-116). This new document redefines how the PIV card issued to Federal Government employees and contractors should be used for access control, and this new recommendation goes well beyond what typical PACS implementations have done in the past. Such a drastic change to the status quo will necessarily create challenges for PACS vendors to meet these requirements, and will cause all Federal Government agencies to re-evaluate their systems.
In February 2005 NIST released Federal Information Processing Standard (FIPS) publication 201, "Personal Identity Verification (PIV) of Federal Employees and Contractors." This standard defines not only the minimum requirements for identity vetting and card issuance, but also the requirements for use of the so-called PIV card from a technological perspective. FIPS 201 includes many options for unique identification of the cardholder: the Cardholder Unique Identifier (CHUID), the Globally Unique Identifier (GUID), Federal Agency Smart Credential Number (FASC-N), and digital signatures.
Optional data elements lead to a lowest common denominator approach
The goal of FIPS 201 is to provide a framework to allow interoperability of credentials issued to all Federal Government employees and contractors at federally controlled facilities. Without such a standard, different agencies would not be able to trust the identity vetting and card authenticity of credentials issued at other agencies. Providing this framework for trust has been crucial. However, a desire for interoperability of the credential across disparate PACS posed various problems.
The intent of a PACS is to restrict access to only those known, validated and authorized entities -- if the card is not known then access is denied. In an interoperable world, all PACS should at a minimum be able to read a credential presented and determine if access is authorized. This requires that all credentials be encoded to the same data model. NIST recognized this necessity, but also recognized that not all agencies would be able to make use of very large identifiers like the GUID, or have the PACS sophistication in place to support digital certificates and public key infrastructure (PKI). Therefore, a minimal solution was also allowed -- the FASC-N. The CHUID is a free read from the card over the contactless interface and contains the FASC-N as well as the GUID and digital signature. A reader can extract any or all of this information, but in the case of legacy PACS, there is only so much information that can be utilized. Typically the first three to five fields of the FASC-N (providing up to 16 digits of an identifier which is defined to be unique within the federal government). The fact is that most legacy PACS can't even support that and further simplify the FASC-N to something smaller that they can handle. This eliminates the uniqueness of the credential, and there is a higher probability that the limited data will be duplicated by unique cards. This is absolutely unacceptable.
NIST was faced with a difficult situation. If agencies were allowed to implement solutions for access control using only a portion of the FASC-N (and even that identifier on the card could be duplicated), then there was a significant potential for counterfeit cards to be produced and used undetected in the system. If such an event occurred while the breached system was in compliance with FIPS 201, it would completely erode the trust in the standard that was designed to meet the security expectations of Homeland Security Presidential Directive 12 (HSPD-12). Therefore, NIST endeavored to create recommendations for the migration from legacy PACS implementations to a truly FIPS 201 compliant solution.
Change the way you think about factors of authentication
Woven throughout the SP800-116 document is the concept of authentication factors. Generally speaking there are three factors - something you have (card), something you know (PIN), and something you are (measured by a biometric). However, SP800-116 points out that if the authentication factor cannot be validated by a trusted authority, it cannot be considered in supporting a graduated scale of increasing levels of confidence in the cardholder identity. For instance, if the card is not authenticated by a digital signature then there is no confidence that it is not a forgery, and therefore any data from the card (FASC-N) or authenticated by the card (PIN) is questionable. By this reasoning, use of FASC-N without a CHUID signature check does not count as even a single authentication factor.
SP800-116 recommends use of asymmetric Card Authentication Key (CAK) for single factor authentication. CAK is available through the contact or contactless interface. Asymmetric key use requires interfacing with an external authority (download PDF showing assymetric key usage for PIV card implementations). Two-factor authentication requires entering a PIN in addition to presentation of the card. PIN validation is only available through the contact interface. Three-factor authentication uses the card, PIN and a biometric (from the card or from an external trusted source) and requires the contact interface.
Measuring progress on the path to implementation
The new recommendations from NIST are not yet part of the standard. Therefore, they have included in the document a means to measure how well an agency or a facility is progressing along the path to a full PIV implementation. NIST calls this the PIV Implementation Maturity Model (PIMM). There are five defined levels that range from Ad Hoc verification of PIV credentials mixed with legacy systems and badges to a future that entails the PIV card as the only credential that a federal employee or contractor carries and is the only credential accepted for access to controlled areas.
Meeting the challenges of complete implementation
The PIV vision is a credential that is issued to all federal government employees and contractors by their respective agencies, and that those agencies have reciprocal trust in other agencies' ability to vet employees and produce and issue a compliant credential. The vision is that such a credential be the sole identifier required for these users for physical as well as logical access to controlled areas or information.
NIST provides a number of qualities of the complete implementation of the PIV vision.
1. PIV authentication mechanisms are used wherever they are applicable, in accordance with HSPD-12 and FIPS 201.
2. Electronic authentication (as opposed to visual authentication, flash pass) is the common practice.
3. Electronic validation of the PIV card is done at or near the time of authentication.
4. All PIV card access control decisions are made by comparing an initial string of the FASC-N Identifier against the ACL entries.
5. PIV authentication mechanisms are applied based on the impact assessed for the area.
6. Cryptographic and biometric authentications are applied widely in moderate- and high-impact (FIPS199) areas.
7. Agencies exhibit reciprocal trust in the process assurance of PIV issuers.
8. Both new and upgraded PACS applications accept PIV cards as proof of identity for user registration/provisioning, user authentication, or both.
However, this poses a number of challenges for agencies that are struggling to meet basic requirements of using the PIV card. The most basic requirement that all of these qualities is built upon is the development of a risk-based impact assessment for the facility. This assessment will define the areas that SP800-116 designates as "unrestricted," "controlled," "limited," and "exclusion." The risk-based analysis of the assets to be protected will help facility security managers define the level of authentication (one-, two- or three-factor) that will be required to gain access to these facilities or areas.
With this information available, the next challenge is to augment or install a new PACS including readers that are capable of meeting the requirements. As described above, even single-factor authentication has evolved from a simple card issued to the cardholder, to something more sophisticated. Now the card must be authenticated before the data is accepted. Asymmetric card authentication will require validating the certificate (as described as "at or near the time of authentication") in real-time with online certificate infrastructure.
Since PACS are traditionally configured with fixed or wall-mounted readers, the requirement for CAK authentication will require new readers capable of reading large amounts of data from the PIV card quickly. These readers will have to be connected to online infrastructure such as certificate authorities, certificate revocation lists, and other similar public key infrastructure functions. For many agencies, this means new readers. For some it is new PACS and new PKI infrastructure, or at a minimum, allowing the logical access control system to be on the same network with a physical access control system.
Other security related functions will necessarily come along with the PACS onto the logical network; those may include video surveillance, IP-based intercom, IP-based storage, and security monitoring workstations. These functions put incredible demands on bandwidth of the network, therefore, network architecture changes may also be required.
Migration is the key
NIST has identified the goal for security managers at federal facilities. However, it is up to the facility security managers to determine the path. NIST has developed the PIMM to allow people to understand and advertise their progress toward compliance with the PIV vision. Yet, there are many challenges to getting there. The reader will have recognized that there are significant costs associated with various parts of the end-point solution: network bandwidth requirements, network segmentation and services availability, PKI infrastructure, and connection with a federal bridge to other agencies' PKI infrastructure, a new breed of PIV readers, and possibly the PACS to support it.
The readers required to support CAK have only recently been made available. Support for digital certificates in the PACS world is very new. There are limited resources available to the security manager. There is a limited number of vendors providing compatible products, and there is a number of integration service providers with the PKI knowledge to fit the pieces together. Finally, test procedures are not yet in place to provide compliance certification.
The future will be much more secure due in part to NIST SP800-116, but the road to get there will surely be a challenging one. Partnership is going to be the key. Security managers should build a team of dedicated stakeholders including internal personnel (in particular, IT management), security integrators, and PACS vendors. The solution will come together when everyone works toward a common goal with all assumptions and requirements clearly communicated across disciplines. A good PACS manufacturer should be willing to work with the team, blaze a trail through new territory, be able to provide the equipment and knowledge to enable the smooth transition, and support the team throughout.
About the author: Adam Shane is a product manager with AMAG Technology. Adam is the primary technical interface between AMAG Technology and the federal government and physical security industry efforts on standardization.