Introduction
As is true with so many other changes in our daily lives, the evolving changes to Physical Access Control Systems (PACS) are directly linked to the terrorist attacks in 2001. Some of the most important changes affecting our industry are the ways identities are now vetted and identity credentials are issued and used.
It took nearly three years, but in August 2004, Homeland Security Presidential Directive-12 (HSPD-12) was issued and signed into law. HSPD-12 states that identity credentials shall be issued only by a recognized and accredited provider be strongly resistant to identity fraud, tampering, counterfeiting, forgery and terrorist exploitation and, most importantly for use with PACS be interoperable and rapidly authenticated electronically.
The interoperable and rapid electronic authentication requirements are the items that challenged and drove leading PACS manufacturers to develop new system solutions. With the new functional demands came a long list of Federal standards, documents and new terminology. Additionally new policies including the policies defined for Federal Identity Credential and Access Management (FICAM) that impact all PACS and logical access control systems (LACS). As the initial challenges are now solved, a few manufacturers are introducing the second generation of conformant PACS.
This article is focused on topics related to PACS. The article reviews how Federal identity credential interoperability is achieved, how the Federal identity card is proved authentic and valid when used in PACS and LACS, how the system proves the rightful owner of the card is using it, and how these Federal credentialing standards are now being used by commercial organizations. In discussing these topics, the article explains the impact of these Federal standards and policies on PACS design, installation and procurement.
It is important to note that this article refers to the "card" as the plastic object that is held and used by a cardholder, and "credential" as the electronic data (such as certificates) that are stored in the card’s smart chip. For additional details and coverage of other topics, please see the list of reference documents.
Interoperability and Identifiers
"Interoperability" as defined in HSPD-12 is built on two main pillars: common technical standards and
policies. This article discusses both. The objective is simple: move to an environment where employees don’t need to carry a bundle of cards and where each site requires a separate card; simply issue one identity card for all locations. Although the credential is designed for both logical as well as physical access control, this article is focused on PACS.
The Federal Personal Identity Verification (PIV) standard defines a set of common policies that, among other items, govern the procedural details of on-boarding, identity vetting, background investigation, adjudication, issuance, and life cycle management. In addition, PIV policies require that identity management and credentialing systems are configured and certified to enforce the processes mentioned above with separation of operator duties. Separation of duties mitigates the risk of one operator being able to produce and issue a PIV credential. The list of policy driven procedures and details is long and some items are quite complex. A Policy Object Identifier, OID, serves as proof that a credential’s certificate is issued in compliance with relevant policies.
PIV policies’ OID allows one agency to trust that an identity credential was indeed created under the same PIV policies and issued to employees of another agency. Knowing that these procedures are consistent across all PIV issuing agencies is intended to remove the distrust that sometimes existed between different agencies. Although some distrust still remains, the majority of agencies now allow visiting employees from different agencies to use their PIV credential for unescorted building access. PIV credentials may also be registered and provisioned in a local PACS, as per local agency policies.
In addition to policies, standards govern what information is collected during the on-boarding process and how it is stored, used, read and authenticated.
The traditional data model of legacy cards was often a short string of bits, such as the 26-bit Wiegand that used a three-digit number to represent a location and five digits to represent the unique sequential number of the specific card. Although longer identifier formats are available, the 26-bit Wiegand model is still common. The card data was simply read by the reader and sent to a PACS controller or, in some cases a reader interface unit, using a one way (simplex) data stream. A three-digit facility code determined if the card belonged in the system at this location and, if yes, the sequential number was processed for authorization.
Interoperability was in many cases deliberately limited. Each PACS operated in a site-centric, stove-piped environment; the legacy data model severely limited system capability to support large user populations. PIV interoperability, as described above, means that a Federal employee who has a PIV credential can, regardless of issuing agency, use the card for access to both physical and logical resources at any Federal agency where the cardholder is authorized. This is quite contrary from legacy thinking and required significant system changes.
Large user populations as represented in all federal agencies require a drastically longer credential identifier to eliminate the risk of duplication, or identifier collision. To mitigate this potential vulnerability, PIV uses a 14-digit identifier, a 48-bit subset of the full Federal Agency Smart Credential Number (FASC-N). Organized using a central registry approach, the FASC-N is controlled by NIST and the CIO of the issuing agency.
The FASC-N identifier consists of three data objects: a four digit Agency Code determined by NIST; a four digit System Code; and a six digit Credential Number. The issuing agency is responsible for allocating the System Code and Credential Number within the agency in a manner that guarantees that each card is unique. This central registry approach is shared among NIST and the agencies and is working well.
Is the Card Authentic and Valid?
As stated in the HSPD-12, the PIV credential is strongly resistant to duplication, alteration and forgery. To achieve these goals, technical standards include specific cryptographic methods and cryptographic keys. Authentication methods include use of both hash algorithms, symmetric keys as well as asymmetric key pairs, and validation dates. Part of the solution includes cryptography to create a digital signature (hash) of the PIV data objects.
When using the card for access requests, one part of the process is that the PACS must authenticate the card’s credential by comparing the hash values of the original with that of the presented card. This effectively eliminates the risk of an adversary being able to successfully substitute a data object that contains the authentic biometric of the authorized cardholder with one of his own. The hash is the encrypted by the private key stored in the smart chip of the card. Only the matching public key can decrypt the hash for verification. (See Figure 1)
Let us take a look at what this cryptographic process actually accomplishes. First, using cryptography achieves more than the secrecy (i.e., confidentiality, where only the intended recipient can read the sent data) most commonly associated with cryptographic deployments. In addition to confidentiality, cryptography is a tool that is also used to ensure:
- Integrity (no alteration of original data),
- Non-Repudiation (proof of trusted origin) and
- Authenticity (proof that the identity of the sender, or receiver, is true).
A Public Key Infrastructure (PKI) approach using digitally signed X.509 certificates is one of the tools used to protect the credential data from unauthorized modification of any kind. The hash algorithm, key size, public key and expiration date are some of the information included in an X.509 Public Key Certificate. (See Figure 2)
For today’s PACS, two PIV certificates are commonly used and electronically authenticated. One is the Card Authentication Key (CAK); the other is the PIV Authentication Key (PIV Auth Cert). These certificates with their unique keys are created by the smart chip of the card at the time of issuance.
To authenticate the card, the credential data is digitally signed by the issuer at the time of production. In addition the PACS' certificate validation service establishes communication to the card and requests the CAK certificate, performs challenge-response with the asymmetric CAK, and sends a validation status request to the issuer certificate authority (CA). When an employee separates from the parent agency, the agency must revoke the employee’s certificates within 18 hours. The CA updates the status of the certificate(s) to “revoked" and add the certificate to a Certificate Revocation List, CRL. The revoked certificate is add Any further attempts to use the certificate to gain access to facilities, or agency networks, will be declined.
This approach enables near-instant, global de-provisioning of a revoked certificate at every location enterprise-wide from one single location mitigate potential threats of a disgruntled former employees to access agency, or company recourses and is a significant security enhancement from the previous approach which focused on a single location. For PIV, each issuing CA must support an Online Certificate Status Protocol (OCSP) responder as well as regularly publish a CRL. To find the appropriate CRL, each certificate includes URLs to where the CRL and OCSP responder may be located. In addition, CRLs may be downloaded to local PACS.
The content of each certificate is also signed by a CA, which is managed by an entity authorized and certified under the common PIV policies to sign such certificates. This CA serves as a trust anchor for the subordinate certificates and validates the subordinate issuing CA(s). The number of CAs between the card’s credential and top level, or root CA, may vary. Full Path Discovery and Path Validation means that each CA in the path between the card (end-entity) and the root CA is validated. (See Figure 3)
During subsequent access control transactions, the certificates are validated and authenticated before the local PACS makes an access grant/access deny decision. A properly deployed and configured PACS will detect any alteration and use of an expired credential, or other non-valid credential status, and deny access where so required.
This establishes trust that the presented credential is indeed authentic, not copied or altered, and is still valid. One factor, possession (referred to as CardV authentication), is achieved. (See Figure 3)
Binding - Is the Right Person Holding the Card?
The shift from a site-centric to an interoperable, identity-centric approach is fundamental and requires strong binding between the legitimate credential owner and the credential itself. The traditional legacy card-card reader offered no resistance to the use of a valid card by an unauthorized person. This weakness is now mitigated by enabling both two and three-factor authentication, effectively eliminating the threat of an imposter using a valid credential to gain access to sensitive areas.
As described above, using CAK authentication establishes trust in the authenticity of the credential, which provides one-factor authentication. The second certificate used for PACS, the PIV Auth Cert, enables two- and three-factor authentication. To enable this, the reader must have a keypad where the cardholder can enter his or her personal identification number (PIN). The PIN is selected by the card owner at the time of issuance and is known only to the card owner.
The PACS establishes the session with the card, requests the PIV Auth Cert, and sends the certificate to be validated. While this is in process, the cardholder enters the PIN on the PACS reader and the PIN is sent to the card’s smart chip. The smart chip verifies the PIN and sends an acknowledgement to the PACS reader. Just like the CAK process, the PACS reader sends a challenge nonce to the card and the card signs the challenge with the private PIV Auth key and returns the signed nonce to the PACS. The PACS verifies the signed nonce before the PACS makes an access grant/deny decision. The benefit of this two-factor authentication is that both the card and PIN are authenticated.
Preventing use of a card that the card owner might share with another person requires a biometric match. Just as with the PIN, biometric templates are securely stored in a specific card data object that is authenticated as described above and available only after the correct PIN is entered.
Both the PIN and biometric templates are part of the authenticated data that are stored on the card’s smart chip; using these for authentication mitigates alteration of a card’s credential as an attack vector. Alteration or substitution of a PIN or biometric can be immediately detected and the card will not authenticate.
Using this three-factor authentication method achieves strong binding between the card and the legitimate card owner.
Where Are these Authentication Methods Used?
Soon, these authentication methods will be used everywhere in the Federal space. The General Services Administration (GSA) is only one agency preparing an upgrade project. An RFQ/RFP for 9,400 buildings nationwide is in the final phases and is widely expected to be posted in the next month or so. Other agencies are making their own upgrade plans.
NIST developed numerous supporting technical standards and documents to specify all credential details and use cases. Based on the Office of Management and Budget, OMB, M04-04 “E-Authentication Guidance for Federal Agencies,” NIST SP800-116 is a document that shows how the PACS shall be configured for the agency to claim FICAM compliance at a local site.
What Is PIV-I?
Following the PIV credential came the PIV – Interoperable, or PIV-I, credential issued by non-federal issuers (NFIs). While NFIs are unable to conduct the background vetting process employed by the Federal government, they can and must perform identity proofing in a manner that promotes trust in the process and in the authenticity of the claimed identity.
NFI PIV-Interoperable issuers must include an Identity Authentication PKI Certificate issued by a CA that is linked to the Federal Bridge Certification Authority (FBCA) via cross-certification. This greatly expands the PKI trust as required for interoperability of certificates linked to credentials issued by other organizations. It enables the Federal government to verify the validity of an identity credential by first verifying the issuing organization (i.e., CA Policy is cross-certified with FBCA), and then providing assurance that the certificate has not been revoked or invalidated.
The Identity Authentication PKI Certificate in an NFI PIV-I card contains a policy OID other than the one mandated for Federal PIV authentication use. This helps to satisfy the requirement of electronic distinctiveness for the NFI PIV-I card. Each cross certified PIV-I issuer has their own distinct Policy OID that maps back to the FBCA.
PIV-I credentials are issued primarily by Federal contractors. PIV and PIV-I credentials issued in compliance with FIPS 201-2 follow, with one exception, the same technical standards and specifications. As opposed to PIV, PIV-I credentials use no central registry to organize the identifiers. As NFIs are private enterprises, there is no agency code that could be assigned to identify an issuing organization. PIV-I credentials populate the Agency Code, System Code and the risk of duplicate UUIDs is Credential Numbers with "9’s".
The complex question of how to allow multiple, independent NFI's to create unique credential identification numbers without risk of duplications, or collisions has been solved. RFC 4122 uses a method that combines a time stamp and a random number to generate a Unique User Identification (UUID) number. The UUID is 128-bits long; it is universally accepted that so miniscule as to be virtually non-existent. The long UUID presented a significant challenge for PACS manufacturers who were already struggling to make system modifications to support the 48-bit FASC-N. However this too was solved and the second generation PACS included on the GSA Approved Product List (APL) 2.0 have demonstrated their capability to process this large number as a unique user identifier.
A second generation FICAM-compliant PACS must be able to distinguish the various policy OIDs of different certificates, determine if the presented credential is a PIV credential, PIV-I credential or Department of Defense (DoD) Common Access Card (CAC), select the correct application, validate the certificate path from the card to the trust anchor and process the FASC-N identifier or the UUID, and, from the server, change the reader authentication mode from one to two factor.
Proven Systems and Certification Requirements
Standards are now updated to consider the many lessons learned from the past several years. Too often PACS were installed at Federal sites using incorrect and incorrectly configured components. In many instances readers did read data from the PIV card, PIV-I card or DoD CAC. However, the data was often simply the serial number of the smart chip of the card; or some in some cases, the system simply parsed out a small portion of the FASC-N identifier.
At the local sites, the system may indeed have seemed to work as intended. Subsequent compliance audit or other instances eventually revealed serious compliance issues and trigged post-installation PACS modifications.
GSA updated the PACS test and evaluation requirements so that each system manufacturer must demonstrate that their equipment is capable of performing in order to be included in the GSA APL. The GSA APL 2.0 requirements are well defined, stringent and do indeed prove that APL-listed equipment complies when installed and configured correctly. To be included in the APL 2.0, each manufacturer must submit a complete end-to-end solution to be evaluated in a GSA-certified test laboratory. Only systems proven capable of satisfying all Federal Identity Credential and Access Management (FICAM) requirements are included in the GSA APL.
To avoid spending scarce funds on non-compliant equipment, OMB directs Federal agencies to only select and procure systems included in the GSA APL. To view, use the link, http://www.idmanagement.gov/documents/pacs-apl.
System components are indeed more complex and now part of the IT infrastructure. Just as FICAM PACS equipment are on the APL, increasing system complexity and installation practices have resulted in a new staff competency requirement.
Today, GSA and a growing number of agencies require that system engineering staff, integrators and other stakeholders involved with PACS design and implementation prove they have demonstrated competencies as required in order to properly design, install, configure and maintain FICAM PACS equipment. GSA recognize and requires the Certified System Engineer ICAM PACS (CSEIP) training and certification as a bid-prequalifying item for staff that will be involved with FICAM PACS projects on contracts including Schedule 70 and 84 labor categories.
The CSEIP certification course is offered by the Smart Card Alliance, a vendor-agnostic industry organization. A list of CSEIP accredited individuals is on the GSA list of qualified HSPD-12 qualified service providers at http://www.idmanagement.gov/qualified-hspd-12-service-providers
What Is Next?
Today, interoperability reaches far beyond the U.S. borders. Adherence to standards and common policies are the main core for making possible the interoperability and universal trust framework that now have global reach. Federal agencies have issued approximately 5.6 million high assurance PIV credentials. In addition a large number of PIV-I credentials have been issued by U.S. contractors located both within the U.S., as well as by U.S. allies overseas.
Furthermore, the proven interoperability of standards-compliant PACS created the groundwork for non-Federal, commercial enterprise PACS (E-PACS) architectures. Various standards-compliant manufacturers already have a mix of interoperable systems in design phases. These system solutions will become increasingly common as the risk of an end-user organization being locked in with "all eggs in one basket" of one system supplier is removed. Locally manufactured systems may be part of an international, even global, E-PACS. This may become both a significant cost reduction factor, as well as a way to make an international enterprise more politically appealing to business locations outside of the contiguous U.S.
A non-federal, high assurance credential has been defined specifically to support the larger, commercial market. The Commercial Identity Verification (CIV) credential follows the PIV-I technical specifications. This means that a commercial entity, such as a Fortune 5000 company, is able to leverage the technology benefits of the second generation PACS (and logical access control systems (LACS)) that are now created, tested, proven and increasingly used by the U.S. Federal government market.
The significant difference with the CIV credential is that all costly FBCA policy certifications and accreditations required of PIV and PIV-I issuers are not applicable. A CIV issuer may themselves determine what on-boarding policies and procedures are acceptable for their own employees. No policy enforcement and cross certification that identities and identity management equipment is conforming to Federal policies are required, or expected for commercial, or private organizations.
A CIV issuer may use a standard Microsoft CA, or other commercially available CA, to ensure that their own employees’, suppliers’ and business partners’ credentials are authentic and able to be used both as log on credentials to access company networks (See Figure 4) as well as credentials for physical access. The same benefits of consistency, credential authentication, and central revocation that Federal agencies enjoy are available to commercial organizations -- at a fraction of the cost.
Summary
The Federal agencies spearheaded development of a secure "High-Assurance" identity credential. Harmonizing the identity vetting and lifecycle procedures across all Federal agencies and creating a consistent, uniform adjudication policy for issuing an identity credential resulted in increased efficiencies and minimized redundant operations across the federal enterprise. The near impossibility of creating a forged or altered credential enhanced the security profile of all Federal resources. Other obvious security benefits, such as from one location very quickly revoke all access privileges of card holders who leave their parent organization. This minimizes the threat of disgruntled former employees to maliciously access both physical as well as network resources and corporate intellectual property.
Leading PACS manufacturers have now developed and are marketing a second generation systems that are subject to strict compliance testing at specially accredited testing laboratories to demonstrate conformance with all relevant technical standards applicable for the Federal market.
The larger, non- federal market are beginning to realize (and take advantage of) the security benefits of a PIV-I type, high assurance credential. Some of the large, nationwide financial institutions and members of the health care industry are early adopters in the commercial market of those who embrace the CIV that is not subject to the costly Federal policy certification.
Interoperability has indeed reached a new phase!
About the Author:
Lars R. Suneborn, CSCIP/G, CSEIP , is the Director, Training Program for the Smart Card Alliance
