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.