NIST.SP.800-116r1.pdf

NIST Special Publication 800-116 Revision 1

Guidelines for the Use of PIV Credentials in Facility Access

Hildegard Ferraiolo Ketan Mehta

Nabil Ghadiali Jason Mohler

Vincent Johnson Steven Brady

This publication is available free of charge from:

https://doi.org/10.6028/NIST.SP.800-116r1

I N F O R M A T I O N S E C U R I T Y

NIST Special Publication 800-116 Revision 1

Guidelines for the Use of PIV Credentials in Facility Access Hildegard Ferraiolo Ketan Mehta

Computer Security Division Information Technology Laboratory

Nabil Ghadiali

National Gallery of Art Washington, DC

Jason Mohler

Vincent Johnson Steven Brady

Electrosoft Services, Inc.

Reston, Virginia

This publication is available free of charge from:

https://doi.org/10.6028/NIST.SP.800-116r1

June 2018

U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary

National Institute of Standards and Technology

Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology

Authority

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-116 Revision 1 Natl. Inst. Stand. Technol. Spec. Publ. 800-116 Revision 1, 71 pages (June 2018)

CODEN: NSPUE2

This publication is available free of charge from:

https://doi.org/10.6028/NIST.SP.800-116r1

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, Federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

Comments on this publication may be submitted to:

National Institute of Standards and Technology

Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

Email: piv_comments@nist.gov

All comments are subject to release under the Freedom of Information Act (FOIA).

https://csrc.nist.gov/publications mailto:piv_comments@nist.gov?subject=Comments%20on%20Draft%20SP%20800-116%20Revision%201

NIST SP 800-116 REV. 1 GUIDELINES FOR THE USE OF PIV CREDENTIALS

IN FACILITY ACCESS

ii

This publication is available free of charge from : https://doi.org/10.6028/N

IST.SP.800-116r1

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

Abstract

This recommendation provides a technical guideline to use Personal Identity Verification (PIV) Cards in facility access; enabling federal agencies to operate as government-wide interoperable enterprises. These guidelines cover the risk-based strategy to select appropriate PIV authentication mechanisms as expressed within Federal Information Processing Standard (FIPS) 201.

Keywords credential; e-authentication; identity credential; issuance; personal identity verification (PIV);

physical access control system (PACS); PIV authentication mechanisms; PIV cards; public key infrastructure (PKI); validation iii

This publication is available free of charge from

Acknowledgements

The authors of SP 800-116 Revision 1 (Hildegard Ferraiolo of NIST; Nabil Ghadiali of the National Gallery of Art; and Jason Mohler, Vincent Johnson, and Steven Brady of Electrosoft Services, Inc.) wish to thank William MacGregor, Ketan Mehta, and Karen Scarfone for their substantial contribution towards the original version of this publication, and David Cooper for his substantial contribution towards both the original version of this publication and the draft version of this revision. The authors also gratefully acknowledge and appreciate the support and contributions by many others in the public and private sectors whose helpful and beneficial comments greatly enhance the utility of this publication. Special thanks to the Interagency Security Committee (ISC), the General Services Administration, the Department of Homeland Security, the Department of Defense, and the Office of Management and Budget for their review and contributions to this document.

Audience

This document is intended for government officials responsible for implementing Homeland Security Presidential Directive-12 (HSPD-12) compliant physical access control systems (PACS). Information in this document is also useful to government contractors and physical security vendors that provide HSPD-12 systems, products, and integration services. It is expected that readers have a general knowledge of PIV standards, including [FIPS 201-2], [SP800-73], and [SP800-78].

This publication is available free of charge from

Executive Summary

Homeland Security Presidential Directive-12 [HSPD-12] sets a clear goal to improve federal facility access through the use of government-wide identity standards. These goals are reflected in the Office of Management and Budget (OMB) Circular A-130, which references SP 800-116 to ensure continued deployment and use of the identity credentials accessing Federal facilities.1

Federal Information Processing Standard 201 [FIPS201] defines characteristics of the identity credential that can be interoperable government-wide. In the context of [HSPD-12], the term interoperability means the ability to use any Personal Identity Verification (PIV) Card with any application performing one or more PIV authentication mechanisms. [FIPS201] also defines authentication mechanisms at four assurance levels (LITTLE or NO, SOME, HIGH, and VERY HIGH). These levels provide for the risk based approach as directed in HSPD-12 to “include graduated criteria, from least secure to most secure, to ensure flexibility in selecting the appropriate level of security for each application.”

The risk-based approach for facility access is stipulated via the designation of “Controlled, Limited, Exclusion” areas (see Section 4.3). Specifically, this document recommends PIV authentication mechanisms for “Controlled, Limited, Exclusion” in terms of authentication factors as shown in Table ES-1. Some agencies may have different names for their security areas, however each agency should establish their criteria to implement authentication consistent with this document.

Table ES-1 - Authentication Factors for Security Areas

Security Areas Minimum Number of Authentication Factors Required

Controlled 1

Limited 2

Exclusion 3

[FIPS201] identifies a number of authentication mechanisms supported by mandatory features of PIV Cards. These mechanisms include Authentication using Authentication with the Card Authentication Certificate Credential (PKI-CAK), Authentication Using Off-Card Biometric Comparison (BIO), Attended Authentication Using Off-Card Biometric Comparison (BIO-A), Authentication with the PIV Authentication Certificate Credential (PKI-AUTH). In addition, PIV Cards may optionally support a number of other authentication mechanisms; these include Authentication with the Symmetric Card Authentication Key (SYM-CAK) and Authentication Using On-Card Biometric Comparison (OCC-AUTH). Access points should not rely solely on an

1 The OMB Circular A-130 can be located at https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf.

https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf i

This publication is available free of charge from authentication mechanism that requires optional card features as it is not guaranteed that the optional features to be used for authentication are present on all cards.

Many changes in this document were made to align SP 800-116 with revision 2 of FIPS 201 (FIPS 201-2). For example, credential validation is now required (see Section 4.4). The CHUID authentication mechanism has been deprecated due to security concerns. For this reason, this publication marks the authentication mechanism as deprecated to signify that it is not a viable authentication mechanism to deploy for physical access control system (PACS). The CHUID data element on the PIV Card, however, remains a mandatory element as the BIO(-A) and SYM- CAK authentication mechanisms use the data element as a source for the card’s expiration date.

It also provides unique identifiers for PACS ACLs. The previous version of this document also included the combined VIS + CHUID authentication mechanism as an option to transitioning from Unrestricted to Controlled areas. VIS + CHUID, however, is not included in this version of the document since it provides “LITTLE or NO” confidence in the identity of the cardholder.

Other changes in this version of the guideline include the removal of the migration strategy as PACS implementation in the Federal Government have moved beyond the described strategy and are more advanced. The future topics (i.e., global identifier and secure biometric match on card) have been addressed in FIPS 201-2 and associated technical specification and thus have become part of this version of guidelines rather than topics for future considerations. Finally, a new Appendix C describes possible improvements to PKI authentication for fast contactless transaction at access points. Appendix I, Revision History, provides a list of changes. This document focuses on the use of PIV Cards to gain access to federal buildings and facilities. It does not address non-PIV credentials that may be issued to populations that do not fall under the scope of HSPD-12 but require access to federal facilities.

ii

This publication is available free of charge from

Table of Contents

1. Introduction

1.1 Background

1.2 Purpose and Scope

2. Characteristics of PIV Implementations

2.1 Benefits of the Complete Implementation

2.2 Qualities of the Complete Implementation

2.3 Interoperability Qualities

2.4 Infrastructure Requirements

3. Threat Environment

3.1 Identifier Collisions

3.2 Revoked PIV Cards

3.3 Visual Counterfeiting

3.4 Skimming

3.5 Sniffing

3.6 Social Engineering

3.7 Electronic Cloning

3.8 Electronic Counterfeiting

3.9 Other Threats

4. PIV Authentication Mechanisms in PACS Applications

4.1 PIV Authentication Mechanisms

4.2 Authentication Factors

4.3 Selection of PIV Authentication Factors

4.4 Credential Validation

5. PACS Use Cases

5.1 Single-Tenant Facility

5.2 Federal Multi-Tenant Facility

5.3 Mixed-Multi-Tenant Facility

5.4 Single-Tenant Campus

5.4.1 FSL I or II Campus

5.4.2 FSL III Campus

5.4.3 FSL IV or V Campus

5.5 Federal Multi-Tenant Campus

iii

This publication is available free of charge from

6. Deployment Consideration

6.1 PIV Identifiers

6.2 PACS Registration

6.3 Role-Based Access Control

6.4 Disaster Response and Recovery Incidents

6.5 Temporary Badges

6.6 Lost PIV Card or Suspicion of Fraudulent Use

6.7 PACS and ICAM Infrastructure

Appendix A — An Overview of PIV Authentication Mechanisms

A.1 Authentication using PIV Visual Credentials (VIS)

A.2 Authentication using the Cardholder Unique Identifier (CHUID)

A.3 Authentication with the Card Authentication Certificate (PKI-CAK)

A.4 Authentication with the Symmetric Card Authentication Key (SYM-CAK)

A.5 Unattended Authentication Using Off-Card Biometric Comparison (BIO)

A.6 Attended Authentication Using Off-Card Biometric Comparison (BIO-A)

A.7 Authentication with the PIV Authentication Certificate (PKI-AUTH)

A.8 Authentication Using On-Card Biometric Comparison (OCC-AUTH)

A.9 (PKI-CAK | SYM-CAK) + BIO(-A) Authentication

Appendix B —Combinations of PIV Authentication Mechanisms in PACS

Appendix C — Improving Authentication Transaction Times

Appendix D — FASC-N Uniqueness

D.1 Full FASC-N Comparison

D.2 FASC-N Identifier Comparison

D.3 Partial FASC-N Comparison

D.4 Isomorphic FASC-N Comparison

Appendix E — Limitations of Legacy Physical Access Control Systems

E.1 Cardholder Identification

E.2 Door Reader Interface

E.3 Authentication Capability

E.4 Wiring

E.5 Software Upgrades

E.6 Legacy PACS Cards and PIV Card Differences

Appendix F — References iv

This publication is available free of charge from

Appendix G — Terminology

Appendix H — Abbreviations and Acronyms

Appendix I — Revision History

List of Figures

Figure 4-1: Innermost Use of PIV Authentication Mechanisms

Figure 4-2: Examples of Mapping PIV Authentication Mechanisms

Figure 5-1: Single-Tenant Facility Example

Figure 5-2: Multi-Tenant Facility Example

Figure 5-3: FSL I or II Campus Example

Figure 5-4: FSL III Campus Example

Figure 5-5: FSL IV or V Campus Example

List of Tables

Table 4-1 - PIV Authentication Mechanisms on the Contact Interface Table 4-2 - PIV Authentication Mechanisms on the Contactless Interface

Table 4-3 - Authentication Factors for Security Areas

Table 6-1 - PIV Identifiers https://nistgov-my.sharepoint.com/personal/hferraio_nist_gov/Documents/FIPS%20201%20documents/SP%20800-116/SP%20800-116%20R1/clean_5_30_18_JF_sp800-116r1-markup%20(AutoRecovered).docx#_Toc517949942 https://nistgov-my.sharepoint.com/personal/hferraio_nist_gov/Documents/FIPS%20201%20documents/SP%20800-116/SP%20800-116%20R1/clean_5_30_18_JF_sp800-116r1-markup%20(AutoRecovered).docx#_Toc517949943 https://nistgov-my.sharepoint.com/personal/hferraio_nist_gov/Documents/FIPS%20201%20documents/SP%20800-116/SP%20800-116%20R1/clean_5_30_18_JF_sp800-116r1-markup%20(AutoRecovered).docx#_Toc517949944 https://nistgov-my.sharepoint.com/personal/hferraio_nist_gov/Documents/FIPS%20201%20documents/SP%20800-116/SP%20800-116%20R1/clean_5_30_18_JF_sp800-116r1-markup%20(AutoRecovered).docx#_Toc517949946

This publication is available free of charge from

1. Introduction

1.1 Background

Homeland Security Presidential Directive-12 [HSPD-12] mandated the establishment of a government-wide standard for identity credentials to improve physical security in federally-controlled facilities.2 To that end, [HSPD-12] required government employees and contractors be issued a new identity credential based on [FIPS201], Personal Identity Verification (PIV) for Federal Employees and Contractors, in accordance with OMB and OPM guidance.3 Following [FIPS201], this credential is referred to herein as the PIV Card.4

[HSPD-12] explicitly requires the use of PIV credentials “in gaining physical access to Federally-controlled facilities and logical access to Federally-controlled information systems.”

The PIV Card employs microprocessor-based smart card technology, and is designed to be counterfeit-resistant, tamper-resistant, and interoperable across Federal Government facilities.

Additionally, the [FIPS201] standards suite defines the authentication mechanisms as transactions between a PIV Card and a relying party. [FIPS201] does not, however, elaborate on the uses and applications of the PIV Card. This document provides guidelines on the uses of PIV Cards with physical access control systems (PACS). This guideline is the first revision of the original version, and a list of changes from the initial guideline is provided in Appendix I, Revision History.

1.2 Purpose and Scope

The purpose of this document is to describe PIV-enabled PACSs that are government-wide interoperable. Specifically, the document recommends a risk-based approach for selecting appropriate PIV authentication mechanisms to manage physical access to Federal Government facilities and assets. With the intent to facilitate and encourage greater use of PIV Cards, this document:

+ Describes the implementation of PIV-enabled PACS.

+ Discusses the PIV Card capabilities so that a risk-based assessment can be aligned with the appropriate PIV authentication mechanism.

+ Outlines an overall strategy for PIV authentication mechanisms with agency facility

PACS.

As stated above, this document focuses on the use of PIV Cards to gain access to federal buildings and facilities. It does not address non-PIV credentials that may be issued to populations that do not fall under the scope of HSPD-12 but require access to federal facilities.

Although the ergonomic design of PACS components is outside the scope of this publication, the 1998 Amendment to Section 508 of the Rehabilitation Act has special relevance to PACS

2 Federally-controlled facilities as defined in Section 1D of OMB Memorandum M-05-24 [M-05-24].

3 OMB Memorandum [M-05-24] and credentialing guidance issued the Office of Personnel Management (OPM) clarifies the eligibility requirements for a PIV Card.

4 Federal agencies may refer to PIV Cards by other names, for example, “Common Access Cards (CAC),” “LincPass,” “identity badges,” or “access cards.” In this document, all such credentials issued by an accredited PIV Card Issuer are called PIV Cards.

This publication is available free of charge from components [SECTION508]. PACS access controls are intended to be unavoidable.

[SECTION508] should be considered early during projects that integrate the PIV System with PACS. [SECTION508] should be considered as it applies to enrollment software, smart card and biometric readers, monitoring systems, and access control point sensors and actuators.

Many other aspects of physical access control are outside the scope of this publication.

Authorization (i.e., granting permission within a PACS for an identified person to pass access control points) is a critical security function, but is out of scope for the PIV System. Other out of scope functions include area protection, intrusion detection, egress, monitoring and tracking (other than at access control points), and enforcement of access control decisions. It is understood that PACS may also be integrated with surveillance systems, fire control systems, evacuation systems, etc., within a facility. This document does not address the integration of PACS with other facility-centric information technology (IT) systems, although it has been written to minimize conflicts during such integration. Therefore, if the integration of the measures outlined in this document creates a life-safety risk, organizations will need to mitigate these risks before applying the measures.

The evaluation of specific PACS architectures or implementations is also outside the scope of this publication, as is the standardization of PACS. Unless normatively referenced, this document is a best practice guideline.

Recommendation 1.1: This document recommends a risk-based approach for selecting appropriate PIV authentication mechanisms to manage physical access to Federal Government facilities and assets. Agencies should seek recommendations on PACS architectures, authorization, and facility protection from other sources.

Recommendation 1.2: Information systems security protections apply to PACSs as PACSs are considered IT systems. PACS information systems include, for example, servers, databases, workstations and network appliances in either shared or isolated networks.

This publication is available free of charge from

2. Characteristics of PIV Implementations

[HSPD-12] directs federal departments and agencies to improve identification and authentication of federal employees and contractors requiring access to federally controlled facilities through the widespread application of [FIPS201], the Standard that was developed in response to [HSPD- 12]. This standard defines the characteristics of the PIV System.

This section describes the main characteristics and qualities of a deployed PIV System that uses the PIV Card for electronic authentication of people for facility access managed by the United States Government. The [FIPS201] authentication mechanisms that can be performed electronically at facility access points are PKI-CAK, SYM-CAK, BIO, BIO-A, PKI-AUTH and OCC-AUTH.5 The VIS authentication mechanism cannot be verified electronically and provides “LITTLE to NO” confidence in the identity of the cardholder. It should not be used when another mechanism is practical. Similarly, authentication mechanisms other than the CHUID authentication mechanisms must be implemented, since [FIPS201] deprecates the use of the CHUID authentication mechanism as it provides ‘LITTLE or NO’ confidence in the identity of the cardholder.6 Newly purchased systems must support other authentication mechanisms (e.g., PKI-CAK) besides the CHUID mechanism.

2.1 Benefits of the Complete Implementation

The complete PIV System is an identity infrastructure that is attractive to federal agencies, application owners, and contractors because of these benefits:

+ Enhanced trust. PIV Cards are issued in accordance with standardized, audited processes, which exceeds the level for low- and moderate-impact legacy applications, and equals best practice reached for high-impact applications.

+ Resistance to misuse and cloning. Electronic validation of the PIV Card, using digital signatures, makes it tamper-resistant. Cryptographic challenge/response protocols make the PIV Card counterfeit-resistant. Biometric authentication makes the PIV Card non-transferable.

+ Status and revocation. PIV Card Issuer process assurance will extend beyond the issuance action to PIV Card validation and revocation services (see Section 4.4).

These services are required elements of the PIV infrastructure, and will be implemented, monitored, and audited with the same care as the PIV issuance process.

+ Standard identity infrastructure. Application developers will assume, as a default, that registration and authentication will use a PIV Card identity, reducing

5 The PIV authentication mechanisms are also described in Appendix A.

6 While use of the CHUID authentication mechanism has been deprecated, the on-card CHUID data element has not been deprecated and continues to be mandatory. In addition to being the only data element in which the optional Cardholder UUID appears, [FIPS201] permits the CHUID data element to be used in the BIO(-A) and SYM-CAK authentication mechanisms as a source for the card’s expiration date and for a unique identifier from the PIV Card..

This publication is available free of charge from development cost, registration time, and the application learning curve for new subjects.

+ Integrated system. PACS will be fully integrated with other PIV system components that perform provisioning, enrollment, and finalization.

+ Fewer credentials. A single PIV Card provides a small set of authentication methods that are applicable to many applications and in many contexts. This means significantly fewer identity credentials that need to be issued and significantly fewer account enrollments.

Each of these points both enhances security and creates efficiency of operation. Reusing identity enrollment across multiple applications, collapsing redundant status and revocation processes (separate processes for revocation on termination across multiple applications), and replacing authentication credentials that are easily shared or transferred will reduce operating costs borne by federal agencies. Availability of a skilled workforce familiar with the standardized PIV identity infrastructure, implementation of PIV issuance with a standardized identity verification methodology, the existence of high-availability online services for PIV Card status and validation, and pre-enrollment in a graduated, multi-factor authentication scheme all enhance security current practice in many applications.

2.2 Qualities of the Complete Implementation

The PIV System implementation is complete when it exhibits the following qualities.

1. PIV authentication mechanisms are used wherever they are applicable, in accordance with [HSPD-12] and [FIPS201].

2. Electronic authentication (as opposed to VIS authentication) is the common practice.

3. Electronic validation of the PIV Card is done at or near the time of authentication (see Section 4.4).7

4. All PIV Card access control decisions are made by comparing the selected PIV identifier to access control list (ACL) entries. See Section 6.1 and Appendix D for details. PIV authentication mechanisms are applied based on the impact assessed for the area so that each facility is mapped to the “Controlled, Limited, Exclusion” model and an assignment of PIV authentication mechanisms to all access control points in accordance with Section 4.2.

5. Cryptographic and biometric authentications are applied widely in low, moderate, and high impact [FIPS199] areas.

6. Agencies exhibit reciprocal trust in the process assurance of PIV card issuers (PCIs).

7 In some cases, validating PIV Cards at the time of authentication is not practical. In these instances, it is possible to maintain a local cache of validated PIV Cards, provided that the cache is updated regularly.

This publication is available free of charge from

7. Both new and upgraded PACS applications accept PIV Cards as proof of identity for user authentication, and, where applicable, user registration/provisioning.

8. Authentication transactions have been optimized; especially at access points that only require one-factor authentication and that have high throughput requirements.

2.3 Interoperability Qualities

Interoperability for PIV-based facility access means the ability of a PACS to use any PIV Card issued by any agency to authenticate the cardholder by performing one or more PIV authentication mechanisms. In other words, the PACS has to support at least one PIV authentication mechanism that is supported by all PIV Cards.8

The interoperability goal of a PIV-enabled PACS can be stated:

1. Any PIV Card can provide verification of identity to the PACS (access is granted only if the identity is so authorized).

2. After a successful authentication, the authentication mechanism provides the cardholder’s authenticated identity (see Section 6.1) to the relying party.

+ The PACS supports at least one PIV authentication mechanism that is supported by all PIV Cards. For example, a PACS may use the PKI-AUTH authentication mechanism to authenticate all cardholders. Alternatively, the PACS may use the BIO authentication mechanism to authenticate most cardholders but use the PKI-AUTH authentication mechanism to authenticate those cardholders from whom fingerprints could not be collected.

+ A relying PACS application needs to support all acceptable algorithms, key lengths, and key material that could be presented, either by a PIV Card or by the PIV infrastructure. For PIV Card, these data objects and keys are placed on a PIV Card during issuance and use specific cryptographic algorithms selected from the acceptable algorithms in [SP800-78], Cryptographic Algorithms and Key Sizes for Personal Identity Verification. The PACS application interrogates the card to learn which algorithms are used.

o If the PKI-CAK authentication mechanism is performed by a PACS application, the PACS should support all of the asymmetric algorithms permitted for the asymmetric Card Authentication key, as specified in Table 3-1 of [SP800-78], i.e., RSA 2048 and ECDSA P-256, and the PACS should accept all valid Card Authentication certificates.

8 Section 4.2 indicates which authentication mechanisms can be implemented using only data objects that are mandatory under FIPS 201-2. However, not all these authentication mechanisms are supported by all PIV Cards, as PKI-CAK is not supported by some cards issued under FIPS 201-1 and fingerprints cannot be collected from all cardholders.

This publication is available free of charge from o If the PKI-AUTH authentication mechanism is performed by a PACS, the accepted algorithms will be the same as PKI-CAK, but the PACS will accept only PIV Authentication certificates and require PIN entry.

o If authentication using off-card biometric comparison is performed (BIO or BIO-A), the PACS should support all of the signature algorithms and key sizes permitted by Table 3-2 of [SP800-78].

o Signature verification and path validation is performed on all signed data objects for the PIV authentication mechanisms used. Failure of signature verification or path validation results in a failed authentication attempt that does not admit a cardholder for access. Caching of validation results (with periodic recheck) is preferred in certain circumstances (see Section 4.4).

+ PINs required for PIV authentication mechanisms are strings of six to eight decimal digits. For PKI-AUTH, BIO, and BIO-A authentication mechanisms, a PIN entry device must acquire the PIN from the cardholder and present it to the PIV Card for activation.

As per OMB policy, installed PACS readers are required to be from the approved products list of the General Services Administration (GSA) FIPS 201 Evaluation Program [FIPS 201 EP]. Each of these readers are capable of one or more PIV authentication mechanisms, such that each PACS reader can support the authentication of any PIV cardholder using a PIV authentication mechanism, including those with PIV Cards that do not implement any of the optional card capabilities. Note that in this document, a PACS reader’s authentication capabilities is assumed to be supported by a PACS controller since the controller is usually the component to execute or support execution of the PIV authentication mechanisms, while the reader functions as the interface between the PIV Card and the controller.

The ability of a PIV Card and cardholder to authenticate at a reader does not mean they will be granted access—it means only that the cardholder’s identity has been verified, with the assurance level of the authentication mechanism employed, by the reader. A cardholder must authenticate and be authorized to be granted access. Authorization policies and mechanisms are outside the scope of [FIPS201].

2.4 Infrastructure Requirements

The qualities and benefits of the complete PIV System can only be achieved if its implementation is supported by bi-directional communications infrastructure used in modern PACS. The following areas have significant influence on the rate at which the complete PIV System integration can be achieved by PACS, and should therefore be supported by PACS upgrades and new PACS procurements:

1. Fast network or two-way serial communication among PACS readers and controllers, panels and head-end components.

2. Fast network communication for PIV status and validation services.

Point (1) allows the PACS to quickly issue commands to cards and receive responses while Point

(2) allows direct access to PIV status and validation services, if needed.

This publication is available free of charge from

3. 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. The CHUID authentication mechanism especially is vulnerable to security threats as described in this section. For that reason, the authentication mechanism has been deprecated. Other authentication mechanisms other than the CHUID authentication mechanisms (e.g., PKI-CAK) must be implemented. Methods of attack are described in general terms, and this is not an exhaustive list of possible attacks. Attackers often succeed by exploiting overlooked or newly introduced vulnerabilities in operational systems.

The PIV System protects the trustworthiness of the PIV Card data objects through PIV Card access rules and digital signatures. Overall trust in the execution of a PIV authentication mechanism is also dependent on correct operation of the PIV Card, the PACS, and the PIV Card validation infrastructure, and, to a degree, on protecting the confidentiality, integrity, and availability of the communication channels among them. Attacks may, therefore, be directed against any of these components, with varying difficulty and potential impact.

The factors critical to sustained trust in the PIV System are:

+ The strength of cryptographic operations.

+ The protection of private and secret keys by system components.

+ The successful decryption and/or signature verification of data objects at expected times.

+ The continuous implementation of access rules by the PIV Card to protect access to the data and keys on the card.

+ The dependable operation of other system elements in the PIV System and the PACS.

To execute a PIV authentication mechanism, the cardholder presents his or her card to the PACS.

The presentation of the PIV Card occurs outside the security perimeter to which access is requested. When the presentation occurs at the outermost perimeter of a facility, the cardholder is in an Unrestricted area, and various technical attacks on PACS are easily carried out. Special security precautions must be taken to ensure protection of these devices at the outermost perimeters of the facility. Even at interior perimeters, the degree of protection provided by enclosing perimeters may be modest when the means of attack can be easily concealed. Possible attack vectors include identifier collisions, revoked PIV Cards, visual counterfeiting, skimming, sniffing, social engineering, electronic cloning, and electronic counterfeiting. These methods of attack, as well as others, are discussed below.

3.1 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. PIV Card Issuers (PCIs) create unique identifiers during the card issuance process. The presence of unique identifiers allows a PIV Card to be uniquely identified by a relying system, such as a PACS. If the unique identifier is ever truncated, compressed, This publication is available free of charge from hashed, or modified, information could be lost. If information is lost from the unique identifier before it is compared against access control list (ACL) entries, multiple cards may generate the same reduced identifier. This is called an identifier collision. A collision means that multiple PIV Cards will appear to belong to the same person and will all be granted the same access privileges.

The PIV Card mitigates the risk of collision by defining a unique Federal Agency Smartcard Number (FASC-N) Identifier for the purposes of physical access control decisions. To prevent collisions, all access control decisions based on the FASC-N should be made by comparing the 14-decimal-digit FASC-N Identifier, and optionally the values of additional FASC-N fields, against the ACL entries. [FIPS201] added the mandatory card universally unique identifier (Card UUID), which is also a unique identifier that can be used reliably in access control decisions. See Section 6.1 for PIV identifiers.

3.2 Revoked PIV Cards

PIV Cards may be revoked for a number of reasons, including a lost or stolen card. A revoked PIV Card could continue to open doors with the CHUID authentication mechanism long after the card has been revoked. As described in [FIPS201], the check for revocation should be performed by a status check, using either the Online Certificate Status Protocol (OCSP) or certificate revocation lists (CRL), on the PIV Authentication certificate or the Card Authentication certificate. Credential validation (see Section 4.4) is required by [FIPS201] for all PIV authentication mechanisms, however, validation of biometric and the CHUID credentials do not include a revocation check. If a PACS caches the status of PIV Cards, the cached status of a revoked PIV Card will remain “valid” until the cache is refreshed. The process for PACS de-authorization is not required or defined by [FIPS201], raising the possibility that online credential validation may not be implemented, or not effectively implemented, where the CHUID authentication mechanism is employed.

The PIV System mitigates the risk of use of a misappropriated PIV Card (which has been successfully reported and revoked) through the process of credential validation. Section

5.5 of [FIPS201] states that “the presence of a valid, unexpired, and unrevoked authentication certificate on a card is proof that the card was issued and is not revoked.”

In the CHUID authentication mechanism, only the CHUID data object is read from the PIV Card, and a reader cannot check the status of a PIV Authentication certificate on the basis of the CHUID alone. Therefore, it is recommended that path validation of the PIV Authentication certificate or the Card Authentication certificate be done at PIV registration, and periodically repeated by the PACS as long as registration is maintained.

Implementation methods are further discussed in Section 6.2 and Section 4.4.

3.3 Visual Counterfeiting

PIV Cards used in the VIS authentication mechanism are visually inspected by a security guard.

A visual counterfeit mimics the appearance, but not the electronic behavior, of an actual PIV Card. A PIV replica may be created by color photocopying or graphic illustration methods and color printing to blank stock. Because of the required presence of one or more security features on the PIV Card, a visual counterfeit is unlikely to pass close examination, provided guards are trained to recognize security features. However, ID cards may receive only cursory examination when used as “flash passes.”

This publication is available free of charge from

The PIV Card mitigates the risk of visual counterfeiting through its capability for rapid electronic authentication, and to a lesser degree, by the presence of one or more security features on the surface of the card. Given the ready availability of high-quality scanners, graphic editing software, card stock, and smart card printers, electronic verification is strongly recommended, either in place of the VIS authentication mechanism or in combination with it. (Note that [FIPS201] downgraded the VIS Authentication mechanism to indicate that it provides “LITTLE or NO” confidence in the identity of the cardholder.)

3.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 range of a skimmer is limited primarily by the requirement for the skimmer to supply power to the PIV Card by inductive coupling. A concealed skimmer could immediately obtain the free-read data from the PIV Card through the contactless interface. [FIPS201] introduced the concept of an optional virtual contact interface (VCI), which allows all data on the PIV Card that is not protected by a PIN to be read once this interface is established. [SP 800-73], Interfaces for Personal Identity Verification, specifies an optional pairing code that can be used to authenticate the card reader to a PIV Card before the card establishes a VCI session. If agencies deploy PIV Cards that support establishing a VCI without requiring the submission of a pairing code, all data on these cards that is not protected by a PIN is vulnerable to skimming.

The PIV Card mitigates the risk of skimming by implementing access rules that prevent the release of biometric and other data over the contactless interface when a VCI has not been established, by requiring the use of a pairing code in order to establish a VCI. The risk of skimming can also be mitigated by employing shielding techniques that positively deactivate the PIV Card when not in use. The electromagnetically opaque holder mentioned in Section 2.11 of [FIPS201] is one such technique.

3.5 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 radio frequency (RF) communications. A sniffer is a passive receiver that does not supply power to the smart card. A sniffer can operate at greater distance than a skimmer (sniffing at a distance of about 10 m has been reported), because a legitimate reader powers the PIV Card at the nominal distance of a few centimeters, while the sniffer’s RF receiver is farther away. Potentially, a sniffer could capture the entire message transaction between the contactless reader and the PIV Card.

The PIV Card mitigates the risk of sniffing by the same access rules that prevent the release of biometric and other data over the contactless interface. The CHUID can be sniffed, however, when used over a contactless interface. Shielding techniques that positively deactivate a PIV Card when not in use cannot mitigate the risk of sniffing, because a PIV Card must be activated to perform a legitimate authentication transaction.

This publication is available free of charge from

When a PIV Card that supports secure messaging9 communicates with a contactless card reader, the card reader can leverage the secure channel, which would protect data objects being read from the risk of a sniffing attack.

3.6 Social Engineering

If an attacker persuaded the cardholder to give them possession of the PIV Card, the attacker could quickly copy all of the information that was not protected by the PIN. An attacker could also attempt a remote attack similar to well-known phishing attacks by creating a web page that asks the subject to “insert PIV Card and enter PIN” for an apparently legitimate purpose. If the cardholder complies, under some assumptions the attacker could capture the cardholder’s PIN and all of the PIV data objects.

The PIV Card mitigates the risk of social engineering attacks by blocking the release of all private and secret keys, and by requiring two-factor authentication (PIV Card and PIN) to perform cryptographic operations with the PIV Authentication key. Moreover, the PIV Card is blocked upon exceeding the allocated number of bad PIN tries.

3.7 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 CHUID) retain their signatures, and the signatures are valid if the original card is valid. The attacks described, however, cannot copy the private or secret keys needed for cryptographic authentication methods. The attacker is thus able to create a partial clone of the PIV Card that would succeed in a CHUID authentication but is not able to create a clone that would succeed in the PKI-CAK or PKI-AUTH authentication mechanisms.

The CHUID authentication mechanism has been deprecated. The PIV Card mitigates the risk of electronic cloning by providing alternative authentication mechanisms (e.g., PKI-

CAK).

3.8 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 against a PACS reader, changing the FASC-N credential identifier on each trial. This approach would not require prior capture of a valid CHUID, but since the counterfeit CHUIDs would not possess valid issuer signatures, a successful exploit depends on the absence of signature verification in the CHUID processing done by the reader.

The PIV Card mitigates the risk of electronic counterfeiting by storing a CHUID with a digital signature field. Electronic counterfeiting will be extremely difficult if CHUID

9 Secure messaging is an optional mechanism specified in [SP 800-73] that provides confidentiality and integrity protection for the card commands that are sent to the card as well as for the responses received from the PIV Card.

This publication is available free of charge from signature verification is performed as required in [FIPS201].

3.9 Other Threats

The PIV and PACS systems 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 the PIV Card, PIV System, or PACS components, and cryptanalysis of the PIV cryptographic algorithms. While the impact of successful attacks such as these could be moderate to high, the probability of success is believed to be extremely low.

This publication is available free of charge from

4. PIV Authentication Mechanisms in PACS Applications

This section provides a discussion of the application of the PIV authentication mechanisms in PACS environments. PIV authentication mechanisms offer a range of security measures (of different throughputs) that can be applied in a PACS environment. This section describes a measurement scale for authentication assurance relevant to PACS. It also provides recommendations on the use of PIV authentication mechanisms in a PACS environment. While a wide range of authentication mechanisms is identified, departments and agencies may adopt additional mechanisms that use the identity credentials on the PIV Card.

4.1 PIV Authentication Mechanisms

The [FIPS201] authentication mechanisms that can be performed electronically at facility access points are PKI-CAK, SYM-CAK, BIO, BIO-A, PKI-AUTH and OCC-AUTH. These mechanisms operate in several different ways as defined in [FIPS201], [SP800-73], and [SP800- 76].10 For example, a private key on the PIV Card may be used to sign a challenge (PKI-CAK and PKI-AUTH authentication mechanisms). A valid biometric from the card may be compared against a live scan (BIO, BIO-A, and OCC-AUTH authentication mechanisms).

Recommendation 4.1: The VIS authentication mechanism cannot be verified electronically and provides “LITTLE to NO” confidence in the identity of the cardholder. It should not be used when another mechanism is practical.

Recommendation 4.2: [FIPS201] deprecates the use of the CHUID authentication mechanism as it provides ‘LITTLE or NO’ confidence in the identity of the cardholder.

Newly purchased systems must support other authentication mechanisms (e.g., PKI- CAK) in place of the CHUID authentication mechanism.

4.2 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 identity of the cardholder. The authentication of an identity is based on the verification of one, two, or three factors: a) “something you have,” for example, possession of the PIV Card; b) “something you know,” for example, knowledge of the PIN; and c) “something you are,” for example, presentation of live fingerprints or irises by a cardholder.

The confidence in the cardholder’s identity increases with the number of factors used to authenticate the PIV Card. Table 4-1 and Table 4-2 provide lists of PIV authentication mechanisms and their authentication factors when used on the contact and contactless interfaces, respectively. Many different combinations of the PIV authentication mechanisms are possible and an exhaustive list of combinations is provided in Appendix B.

Note that an authentication mechanism is not considered to provide any factors of authentication

10 The PIV authentication mechanisms are also described in Appendix A.

This publication is available free of charge from if the authentication is not successful. For example, in the case of the PKI-AUTH and PKI-CAK authentication mechanisms, if the PACS application is unable to validate the authentication certificate from the presented card or does not receive a response to its challenge that can be verified using the public key in the certificate, then the PACS application cannot count the authentication attempt towards meeting the requirements for granting access to an area.

As noted in Section 2.3, in order to achieve interoperability, each access point in a PACS needs…