NIST PIV and digital identity SP 800-116
All1 Executive Summary10 Avoid long-term, side-by-side operation of deployed and PIV technologies. Once PIV11 CAK BIO CPB12 CAK BIO-A PKI13 CAK BIO-A CPB2 Introduction3 Terminology4 Threat Environment5 Limitations of Deployed Physical Access Control Systems6 The PIV Vision7 PIV Authentication Mechanisms8 PACS Use Cases9 Migration Strategy
| Ref | Title | Text | |
|---|---|---|---|
| 1 | Executive Summary | The physical access control systems (PACS) deployed in most Federal buildings are facility- centric rather than enterprise-centric and utilize proprietary PACS architectures. Therefore, many issued identification (ID) cards operate only wit | |
| 2 | Introduction | ||
| 2.1 in 2 |
Authority | This document has been developed by the National Institute of Standards and Technology (NIST) to further its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, P.L. 107-347. NIST is responsible | |
| 2.2 in 2 |
Background | HSPD-12 mandates the establishment of a government-wide standard for identity credentials to improve physical security in Federally controlled facilities 2 . To that end, HSPD-12 requires all government employees and contractors be issued a | |
| 2.3 in 2 |
Purpose and Scope | The purpose of this document is to describe a strategy allowing agencies to PIV-enable their PACS, and migrate to government-wide interoperability. Specifically, the document recommends a risk-based approach for selecting appropriate PIV au | |
| 2.4 in 2 |
Audience | This document is intended for the government officials responsible for implementing HSPD-12. This document will also aid government executives (i.e., decision makers) to evaluate business cases and develop strategies for their departments o | |
| 3 | Terminology | The following terms are used in this document and are not defined in FIPS 201. Access Control: A function or a system that restricts access to authorized persons only. Access Control List: A list of (identifier, permissions) pairs associate | |
| 4 | Threat Environment | The PIV System is intended to enhance security and trust in identity credentials, but no practical system can guarantee perfect security. This section discusses known technical threats to PIV authentication mechanisms, especially the CHUID | |
| 4.1 in 4 |
Identifier Collisions | By definition, a unique identifier for a PIV Card is a data artifact with a fixed value unique to one particular PIV Card. PCIs create unique identifiers during the card issuance process. The presence of a unique identifier allows a PIV Car | |
| 4.2 in 4 |
Terminated PIV Cards | PIV Cards may be terminated for a number of reasons, including a lost or stolen card. A terminated PIV Card could continue to open doors with the CHUID authentication mechanism long after the card has been terminated. As described in FIPS 2 | |
| 4.3 in 4 |
Visual Counterfeiting | PIV Cards are used in the VIS authentication mechanism that requires visual inspection of the PIV Card by a security guard. A visual counterfeit mimics the appearance, but not the electronic behavior, of an actual PIV Card. A PIV replica ma | |
| 4.4 in 4 |
Skimming | A contactless PIV Card reader with a sensitive antenna can be concealed in a briefcase, and is capable of reading ISO/IEC 14443 contactless smart cards like the PIV Card at a distance of at least 25 cm, as demonstrated in [SKIMMER]. The ran | |
| 4.5 in 4 |
Sniffing | When a PIV Card is presented to a contactless reader at an access point, the reader supplies power to the PIV Card through inductive coupling and a series of messages is exchanged between the PIV Card and reader using RF communications. A s | |
| 4.6 in 4 |
Social Engineering | If an attacker persuaded the cardholder to give them possession of the PIV Card, the attacker could quickly insert the card into a contact reader and copy all of the information available as free-read (the CHUID, the security object, the Ca | |
| 4.7 in 4 |
Electronic Cloning | If an attacker has successfully conducted a skimming, sniffing, or social engineering attack, he or she possesses verbatim copies of some of the data objects from an issued PIV Card. The objects that are signed (e.g., the certificates and C | |
| 4.8 in 4 |
Electronic Counterfeiting | An attacker could construct a battery-powered, microprocessor-based device that emulates a PIV Card for purposes of the CHUID authentication mechanism. The attacker could program the microprocessor to generate and test CHUIDs repetitively a | |
| 4.9 in 4 |
Other Threats | The PIV System and PACS are complex, and this brief discussion has focused on properties of the PIV Card. A number of other attack vectors have not been discussed in detail, including sophisticated technical attacks against the integrity of | |
| 5 | Limitations of Deployed Physical Access Control Systems | FIPS 201 and its supporting special publications impose specific requirements on PACS interfaces with PIV Card and PIV System. These requirements will present technical challenges in migrating to PIV Card use in the areas of cardholder iden | |
| 5.1 in 5 |
Cardholder Identification | PACS that are currently deployed in Federal government facilities use cards with data formats that are often proprietary to the specific enterprise. Many of the installed PACS use an ID number based on a 26-bit standard, which is comprised | |
| 5.2 in 5 |
Door Reader Interface | Deployed PACS readers come in varying configurations and offer multiple interface options for the card and the Controller. FIPS 201 standardizes the use of the ISO/IEC 14443 interface for the contactless reader to card communication. Note t | |
| 5.3 in 5 |
Authentication Capability | Deployed PACS readers use proximity or magnetic stripe technology to interface with identity cards and use proprietary protocols to communicate data. Some of these proprietary protocols employ cryptography, but their use is limited to the l | |
| 5.4 in 5 |
Deployed Wiring | Selecting a particular reader type and its interface with the Controller requires careful attention to wiring. Existing wiring should be assessed for its ability to meet the requirements of new readers and Controllers. The existing wiring m | |
| 5.5 in 5 |
Software Upgrades | Vendors may be able to upgrade their existing PACS software to minimize the hardware changes needed for an existing PACS to accept PIV Cards. Software or firmware upgrades to Controllers or Door readers may be available to agencies. PACS su | |
| 5.6 in 5 |
Deployed Non-PIV PACS Cards and PIV Card Differences | The list below compares the basic differences in the technology offerings between the deployed Non-PIV PACS cards and the PIV Card. + Some deployed PACS use site-specific card technology, with the result that a card cannot be used at sites | |
| 6 | The PIV Vision | HSPD-12 begins, “Wide variations in the quality and security of forms of identification used to gain access to secure Federal and other facilities where there is potential for terrorist attacks need to be eliminated.” HSPD-12 continues, in | |
| 6.1 in 6 |
Interoperability | In this publication, the term interoperability means the ability to use any PIV Card with any PACS application performing one or more PIV authentication mechanisms. The data objects and keys placed on a PIV Card during issuance use specific | |
| 6.2 in 6 |
Qualities of the Complete Implementation | The PIV System implementation will be complete when the following qualities have been achieved. | |
| 6.3 in 6 |
Benefits of the Complete Implementation | The complete PIV System will be an identity infrastructure that is attractive to Federal agencies, application owners, and contractors because of these benefits: + Enhanced trust. PIV Cards will be issued in accordance with a standardized, | |
| 6.4 in 6 |
Infrastructure Requirements | The qualities and benefits of the complete PIV System can only be achieved if its implementation is supported by general advances in infrastructure used by PACS. The following areas have significant influence on the rate at which the comple | |
| 7 | PIV Authentication Mechanisms | This section provides a discussion of PIV authentication mechanisms and their application in PACS environments. PIV authentication mechanisms offer a range of security measures (of different throughputs) that can be applied in a PACS enviro | |
| 7.1 in 7 |
Authentication Factors | One of the functions of the PACS application is to verify the identity of the cardholder presenting a PIV Card. The PACS application may perform one or more authentication mechanisms using the PIV Card to establish confidence in the identit | |
| 7.1.1 in 7.1 |
Deployed Proximity or Magnetic Stripe Authentication | Deployed proximity and magnetic stripe authentication are not PIV authentication mechanisms and when used in conjunction with PIV authentication mechanisms, there is a strong potential for “collisions”. Proximity and magnetic stripe card te | |
| 7.1.2 in 7.1 |
Visual (VIS) Authentication | Visual authentication entails inspection of the topographical features on the front and back of the PIV Card. The human guard checks to see that the PIV Card looks genuine, compares the cardholder’s facial features with the picture on the c | |
| 7.1.3 in 7.1 |
Cardholder Unique Identifier (CHUID) Authentication | The CHUID, as defined in FIPS 201, is one of the data objects on PIV credentials. The CHUID includes a FASC-N data element that uniquely identifies the PIV Card. The CHUID also uniquely identifies an individual since each PIV Card is issued | |
| 7.1.4 in 7.1 |
Card Authentication Key (CAK) Authentication | The CAK is an optional key that may be present on any PIV Card. As the name implies, the purpose of the CAK authentication mechanism is to authenticate the card and therefore its possessor. The CAK is unique among the PIV keys in several re | |
| 7.1.5 in 7.1 |
PIV Authentication Key (PKI) Authentication | PACS may be designed to perform public key cryptography-based authentication using the PIV Authentication Key. Use of the PKI provides two-factor 6 authentication, since the cardholder must enter a PIN to unlock the card in order to success | |
| 7.1.6 in 7.1 |
BIO Authentication | PACS may be designed to perform biometric authentication using the fingerprint information stored on the PIV Card. 8 The biometric on the PIV Card is signed by the issuer, so the authenticity of the biometric can be checked by the PACS. Ver | |
| 7.1.7 in 7.1 |
BIO-A Authentication | This authentication mechanism is the same as BIO authentication but an attendant supervises the use of the PIV Card and the submission of the PIN and the sample biometric by the cardholder. Some fingerprint biometric readers have been shown | |
| 7.1.8 in 7.1 |
CAK + BIO(-A) Authentication | As discussed in Section 7.1.6 and 7.1.7, BIO(-A) by itself does not provide three-factor authentication. However, when BIO(-A) and CAK authentication mechanisms are performed at the same time, the verification of the PIN can be trusted beca | |
| 7.2 in 7 |
Multi-Factor Authentication | Possession of a valid PIV Card as evidenced by visual inspection of the card, reading a signed object from the card, or performing challenge/response authentication with the card, provides one-factor authentication. For this reason, the VIS | |
| 7.3 in 7 |
Selection of PIV Authentication Mechanisms | A risk-based approach should be used when selecting appropriate PIV authentication mechanisms for physical access to Federal government buildings and facilities. Determining risk to the facility is beyond the scope of this document; however | |
| 7.4 in 7 |
PACS Registration | Before a PACS may grant access to a cardholder, the cardholder must be authorized for access in the PACS. Authorization may be granted to a group of individuals, such as all PIV cardholders, or all PIV cardholders sponsored by a specific ag | |
| 7.5 in 7 |
Credential Validation and Path Validation | Credential validation is the process of determining if a presented identity credential is valid, i.e., was legitimately issued and has not expired or been terminated. On-line credential validation is extremely valuable to relying parties be | |
| 7.6 in 7 |
Lost PIV Card or Suspicion of Fraudulent Use | If a lost PIV Card is found by a person other than the cardholder, or if a pattern of PIV Card activity raises suspicions of fraudulent use, the security office of the issuing agency, or of the cardholder’s duty station, should be notified. | |
| 8 | PACS Use Cases | HSPD-12 requires that PIV credentials include graduated criteria, from least secure to most secure, for authentication to ensure flexibility in selecting the appropriate level of security for each application. PIV credentials, as defined in | |
| 8.1 in 8 |
Single-Tenant Facility | In single-tenant facilities, a single tenant defines its own security requirements and controls its own security measures. Implementation of security measures is uniform. The facility may be an owned or a leased space. If the space is lease | |
| 8.2 in 8 |
Multi-Tenant Facility | The challenge with a multi-tenant facility is to meet the security policies and requirements of the individual tenants in the facility. Some tenants may need higher security than others. The security policies may not be uniform and cannot b | |
| 8.3 in 8 |
Mixed-Multi-Tenant Facility | The mixed-multi-tenant facility use case is an example of a facility with a mix of PIV cardholders and non-PIV cardholders. Therefore, some tenants in this facility may not possess PIV Cards for authentication. It may be difficult if not im | |
| 8.4 in 8 |
Single-Tenant Campus | As opposed to a single-tenant facility, a campus is a collection of buildings, labs, and parking spaces that are geographically co-located within a large perimeter. The large perimeter is typically a fenced compound with a gate through whic | |
| 8.4.1 in 8.4 |
FSL I or II Campus Facility | Figure 8-3 depicts a security posture of a FSL I or II Campus Facility. It includes one or more Controlled areas that are available to authorized personnel. Since a FSL I or II Campus Facility can be considered a low-risk area, a PACS may o | |
| 8.4.2 in 8.4 |
FSL III Campus Facility | Figure 8-4 depicts a security posture of a FSL III Campus Facility. It includes one or more Controlled areas as well as Limited areas that are restricted to specific group of individuals. Since a FSL III Campus Facility can be considered a | |
| 8.4.3 in 8.4 |
FSL IV or V Campus Facility | Figure 8-5 depicts a security posture of a FSL IV or V Campus Facility. It includes one or more Controlled areas, Limited areas, and Exclusion areas that are restricted to specific groups of individuals. Controlled area Limited area Exclus | |
| 8.5 in 8 |
Multi-Tenant Campus | The multi-tenant campus environment is similar to the single-tenant campus except that individual tenants will have their own security policies and the enforcement may be different. A tenant may benefit from the authentication mechanism(s) | |
| 8.6 in 8 |
Role-Based Access Control | Authorization of identities enrolled in a PACS is viewed as separate from cardholder authentication. PACS may grant access only to cardholders who were enrolled and authorized in the PACS Server prior to presenting their credentials for aut | |
| 8.7 in 8 |
Temporary Badges | HSPD-12 mandated the issuance of electronic identity credentials to Federal employees and contractors. OMB Memorandum M-05-24 clarified the eligibility requirements for PIV Cards to temporary Federal employees and contractors, by requiring | |
| 8.8 in 8 |
Disaster Response and Recovery Incidents | In addition to the use of a PIV credential for cardholder authentication during routine everyday use, the PIV credentials may also be used for access to Federal facilities and Federally controlled areas internal to disaster response and rec | |
| 9 | Migration Strategy | Earlier sections provide the tools agencies will need to prepare a migration plan for PIV enabling their PACS environment. This section discusses how these tools may be used to aid agencies with developing a migration plan. | |
| 9.1 in 9 |
Project Planning | Planning for a migration to PIV-enabled PACS should be viewed as an opportunity to modernize deployed PACS. Given the threat environment, as described in Section 4, migrating to PIV- enabled PACS enhances security, fosters trust among agenc | |
| 9.2 in 9 |
Risk Assessment | Vulnerability analyses and risk assessments provide a method of prioritizing the criticality of assets (or the impact of the loss of assets), threats, and countermeasure strategies. A structured process allows for the documentation of risks | |
| 9.3 in 9 |
Business and Functional Requirements | Each agency has a unique operational environment. Agencies vary in size, organizational structure, and geographic topography. Moreover, their PACS requirements are driven by their mission and by risk and vulnerability assessment. The result | |
| 9.4 in 9 |
Develop Migration Plan | Developing a migration plan requires a vision for PIV-enabled PACS operations. Specifically, a new business process needs to be charted to address the use of PIV credentials. This business process will be dependent on the flexibility availa | |
| 9.5 in 9 |
Migration Strategy & Tactics | Continuity of operations planning is essential to the success of a migration from deployed PACS to PIV-enabled PACS. Planning lays the strategic framework that makes tactical, moment-to- moment change management possible without catastrophi | |
| 10 | Avoid long-term, side-by-side operation of deployed and PIV technologies. Once PIV | Cards have been issued to half the users, cut costs by aggressive completion of the migration. 9.6 PIV Implementation Maturity Model (PIMM) In a document focused on the integration of PIV authentication mechanisms with PACS systems, it is | |
| 10.1 in 10 |
Generalized Credential Identifier | FIPS 201 states that the CHUID data object contains the FASC-N data element, “which uniquely identifies each card.” The FASC-N actually serves two purposes: 1) identifying a PIV Card (and by correspondence, the cardholder); and 2) binding P | |
| 10.2 in 10 |
Secure Biometric Match-On-Card | FIPS 201 defines the biometric authentication mechanisms BIO and BIO-A. According to these definitions, the PIV reference template object is stored on the PIV Card during issuance. When a PIV Card is inserted into a contact biometric reader | |
| 11 | CAK BIO CPB | ||
| 12 | CAK BIO-A PKI | ||
| 13 | CAK BIO-A CPB | 14 CAK PKI BIO-A 15 CAK CPB → 16 CAK CPB BIO-A 17 CAK CPB PKI 18 CAK CPB CPB 19 BIO BIO-A PKI 20 BIO BIO-A CPB 21 BIO PKI → 22 BIO PKI BIO-A 23 BIO PKI PKI 24 BIO PKI CPB Access Point A (Controlled) Access Point B (Limited) Access Point C ( |
68 of 68.