NIST SP 800-73-5 日本語訳

Part 2 – PIV Card Application Card Command Interface

Hildegard Ferraiolo Ketan Mehta Salvatore Francomacaro Ramaswamy Chandramouli Sarbari Gupta

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-73pt2-5

Part 2 – PIV Card Application Card Command Interface

Hildegard Ferraiolo Ketan Mehta Salvatore Francomacaro Ramaswamy Chandramouli Computer Security Division

Information Technology Laboratory

Sarbari Gupta Electrosoft Services, Inc.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-73pt2-5

July 2024

U.S. Department of Commerce Gina M. Raimondo, Secretary

National Institute of Standards and Technology

Laurie E. Locascio, NIST Director and Under Secretary of Commerce for Standards and Technology

Certain equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified 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.

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.

NIST Technical Series Policies Copyright, Use, and Licensing Statements NIST Technical Series Publication Identifier Syntax

Publication History Approved by the NIST Editorial Review Board on 2024-07-03 Supersedes NIST SP 800-73-4 (May 2015; updated February 8, 2016) https://doi.org/10.6028/NIST.SP.800-73-4

How to Cite this NIST Technical Series Publication: Ferraiolo H, Mehta K, Francomacaro S, Chandramouli R, Gupta S (2024) Interfaces for Personal Identity Verification: Part 2 – PIV Card Application Card Command Interface. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-73pt2-5. https://doi.org/10.6028/NIST.SP.800-73pt2-5

Hildegard Ferraiolo: 0000-0002-7719-5999

Ketan Mehta: 0009-0001-1191-8656

Salvatore Francomacaro: 0009-0009-0487-2520

Ramaswamy Chandramouli: 0000-0002-7387-5858

Sarbari Gupta: 0000-0003-1101-0856

piv_comments@nist.gov

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

Additional Information Additional information about this publication is available at https://csrc.nist.gov/pubs/sp/800/73/pt2/5/final including related content, potential updates, and document history.

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

FIPS 201 defines the requirements and characteristics of government-wide interoperable identity credentials. It specifies that these identity credentials must be stored on a smart card and that additional common identity credentials, known as derived PIV credentials, may be issued by a federal department or agency and used when a PIV Card is not practical. This document contains the technical specifications to interface with the smart card to retrieve and use the PIV identity credentials. The specifications reflect the design goals of interoperability and PIV Card functions. The goals are addressed by specifying a PIV data model, card edge interface, and application programming interface. Moreover, this document enumerates requirements for the options and branches in international integrated circuit card standards [ISO7816]. The specifications go further by constraining interpretations of the normative standards to ease implementation, facilitate interoperability, and ensure performance in a manner tailored for PIV applications.

authentication; FIPS 201; identity credential; logical access control; on-card biometric comparison; Personal Identity Verification (PIV); physical access control; smart cards; secure messaging.

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.

Patent Disclosure Notice

NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication. As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL. No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

The authors — Hildegard Ferraiolo, Ketan Mehta, Salvatore Francomacaro, and Ramaswamy Chandramouli of NIST and Sarbari Gupta of Electrosoft Services, Inc. — gratefully acknowledge the contributions of David Cooper, James Dray, William MacGregor, Scott Guthery, Teresa Schwarzhoff, and Jason Mohler, who co-authored prior versions of this three-part publication. The authors also gratefully acknowledge and appreciate the many contributions from the public and private sectors whose thoughtful and constructive comments improved the quality and usefulness of this publication.

Homeland Security Presidential Directive-12 (HSPD-12) called for the adoption of a common identification standard to govern the interoperable use of identity credentials to allow physical and logical access to federally controlled facilities and information systems. In response, Federal Information Processing Standard (FIPS) 201 [FIPS201], Personal Identity Verification (PIV) of Federal Employees and Contractors, was developed to define reliable, government-wide identity credentials for use in applications such as access to federally controlled facilities and information systems. FIPS 201 supports multiple types of authenticators, including authenticators on smart cards (also known as PIV cards) and derived PIV credential authenticators in various other form factors. This publication contains technical specifications to interface with PIV Cards to retrieve and use identity credentials. Other specifications, such as NIST Special Publication (SP) 800-157r1 (Revision 1), contain procedures and life cycle activities to issue, maintain, and use derived PIV credentials.

FIPS 201 defines processes for binding identities to authenticators, such as the PIV Card and derived PIV credentials used in the federal PIV system. SP 800-73-5 contains the technical specifications to interface with the PIV Card to retrieve and use the identity credentials. The specifications reflect the design goals of interoperability and PIV Card functions. The goals are addressed by specifying a PIV data model, card edge interface, and application programming interface. Moreover, SP 800-73-5 enumerates requirements for the options and branches in international integrated circuit card (ICC) standards [ISO7816]. The specifications go further by constraining interpretations of the normative standards to ease implementation, facilitate interoperability, and ensure performance in a manner tailored for PIV applications.

SP 800-73-5 specifies the PIV data model, application programming interface (API), and card interface requirements necessary to comply with the use cases, as defined in Section 6 of FIPS 201 and further described in Appendix B of SP 800-73-5 Part 1. Interoperability is defined as the use of PIV identity credentials such that client-application programs, compliant card applications, and compliant ICCs CAN be used interchangeably by all information processing systems across federal agencies. SP 800-73-5 defines the PIV data elements’ identifiers, structure, and format, as well as the client API and card command interface for use with the PIV Card.

This document — SP 800-73-5, Interfaces for Personal Identity Verification: Part 2 – PIV Card Application Card Command Interface — contains the technical specifications for the PIV Card command interface to the PIV Card. The specifications define the set of commands surfaced by the PIV Card Application at the card edge of the ICC.

This document is intended for federal agencies and implementers of PIV systems. Readers are assumed to have a working knowledge of smart card standards and applications.

Readers should also be aware of the following important content in SP 800-73-5 Part 1:

All sections in this document are normative (i.e., mandatory for compliance) unless specified as informative (i.e., non-mandatory) and are structured as follows:

SP 800-73-5 Parts 2 and 3 define two interfaces to an ICC that contain the PIV Card Application: a low-level card command interface (Part 2) and a high-level client API (Part 3). SP 800-73-5 Part 3 is optional, and NIST Personal Identity Verification Program (NPIVP) conformance testing for PIV Middleware in accordance with SP 800-73 Part 3 is discontinued since endpoints support high-level client API natively at the time of this publication.

The information processing concepts and data constructs on both interfaces are identical and MAY be referred to generically as the information processing concepts and data constructs on the PIV interfaces without specific reference to the client API or the card command interface.

The client API provides task-specific programmatic access to these concepts and constructs, and the card command interface provides communication access. The client API is used by client applications using the PIV Card Application. The card command interface is used by software that implement the client API (middleware).

The client API is thought of as being at a higher level than the card command interface because access to a single entry point on the client API may cause multiple card commands to traverse the card command interface. In other words, it may require more than one card command on the card command interface to accomplish the task represented by a single call on an entry point of the client API.

The client API is a program execution, call/return style interface, whereas the card command interface is a communication protocol, command/response style interface. Because of this difference, the representation of the PIV concepts and constructs as bits and bytes on the client API may be different from the representation of these same concepts and constructs on the card command interface.

The PIV Card Application places the following requirements on the ICC platform on which it is implemented or installed:

Part 1 specifies the AID, names, Tag-Length-Value (BER-TLV) tags [ISO8825], ASN.1 Object Identifiers (OIDs) [ISO8824], and Proprietary Identifier eXtensions (PIXes) of the NIST Registered Application Provider IDentifier (RID) used on the PIV interfaces. Part 1 also states that all unspecified names, BER-TLV tags, OIDs, and values of algorithm identifiers, key references, and cryptographic mechanism identifiers are reserved for future use.

Each command that appears on the card command interface SHALL be implemented by a card application that is resident on the ICC. The card command enables operations on and with the data objects to which the card application has access.

Each card application SHALL have a globally unique name called its Application Identifier (AID) [ISO7816, Part 4]. Except for the default applications, access to the card commands and data objects of a card application SHALL be gained by selecting the card application using its application identifier.¹ The PIX of the AID SHALL contain an encoding of the version of the card application. The AID of the PIV Card Application is defined in Part 1.

The card application whose commands are currently being used is called the currently selected application.

The card platform SHALL support a default selected card application. In other words, there SHALL be a currently selected application immediately after a cold or warm reset. This card application is the default selected card application. The default card application MAY be the PIV Card Application, or it MAY be another card application.

The security architecture of an ICC is the means by which the security policies governing access to each data object stored on the card are represented within the card. These security policy representations are applied to all PIV card commands, thereby ensuring that the prescribed data policies for the card applications are enforced.

The following subsections describe the security architecture of the PIV Card Application.

An access control rule SHALL consist of an access mode and a security condition. The access mode is an operation that CAN be performed on a data object. A security condition is a Boolean expression using variables called security statuses (see Sec. 2.4.2).

According to an access control rule, the action described by the access mode CAN be performed on the data object if and only if the security condition evaluates to TRUE for the current values of the security statuses. If there is no access control rule with an access mode that describes a particular action, then that action SHALL never be performed on the data object.

A set of one or more Boolean variables — each called a security status indicator of the authenticable entity — SHALL be associated with each authenticable entity. Each security status indicator is, in turn, associated with a credential that CAN be used to authenticate the entity. The security status indicator of an authenticable entity SHALL be TRUE if the credentials associated with the security status indicator of the authenticable entity have been authenticated and FALSE otherwise.

A successful execution of an authentication protocol SHALL set the security status indicator associated with the credential used in the protocol to TRUE. An aborted or failed execution of an authentication protocol SHALL set the security status indicator associated with the credential used in the protocol to FALSE.

As an example, the credentials associated with three security status indicators of the cardholder might be a PIN, fingerprint, and pairing code. Demonstrating knowledge of the PIN is the authentication protocol for the first security status indicator wherein the PIN is the credential. Comparing the fingerprint template on the card with a fingerprint acquired from the cardholder is the authentication protocol for the second security status indicator wherein the fingerprint is the credential. Demonstrating knowledge of the pairing code is the authentication protocol for the third security status indicator wherein the pairing code is the credential. A security condition using these three security status indicators might be “pairing code AND (PIN OR fingerprint).” A security status indicator SHALL be said to be a global security status indicator if it is not changed when the currently selected application changes from one application to another. In essence, when changing from one application to another, the global security status indicators SHALL remain unchanged.

A security status indicator is said to be an application security status indicator if it is set to FALSE when the currently selected application changes from one application to another. Every security status indicator is either a global security status indicator or an application security status indicator. The security status indicators associated with the PIV Card Application PIN, the PIN Unblocking Key (PUK), OCC, pairing code, and the PIV Card Application Administration Key are application security status indicators for the PIV Card Application, whereas the security status indicator associated with the Global PIN is a global security status indicator.

The term global security status refers to the set of all global security status indicators. The term application security status refers to the set of all application security status indicators for a specific application.

Knowledge of a PIN is the means by which an individual CAN be authenticated to the PIV Card Application.

The pairing code SHALL be exactly 8 bytes in length, and the PIV Card Application PIN SHALL be between 6 and 8 bytes in length. If the actual length of the PIV Card Application PIN is less than 8 bytes, it SHALL be padded to 8 bytes with 'FF' when presented to the card command interface. The 'FF' padding bytes SHALL be appended to the actual value of the PIN. The bytes that comprise the PIV Card Application PIN and pairing code SHALL be limited to values 0x30 – 0x39, the ASCII values for the decimal digits '0' – '9'. For example:

The PIV Card Application SHALL enforce the minimum length requirement of 6 bytes for the PIV Card Application PIN (i.e., SHALL verify that at least the first 6 bytes of the value presented to the card command interface are in the range 0x30 – 0x39) and the other formatting requirements specified in this section.

If the Global PIN is used by the PIV Card Application, then the above encoding, length, padding, and enforcement of minimum PIN length requirements for the PIV Card Application PIN SHALL apply to the Global PIN.

The PUK SHALL be 8 bytes in length and MAY be any 8-byte binary value. That is, the bytes that comprise the PUK MAY have any value in the range 0x00 – 0xFF.

The elements of the current state of the PIV Card Application when the PIV Card Application is the currently selected application are described in Table 1.

Table 1. State of the PIV Card Application

Table 2 lists the card commands surfaced by the PIV Card Application at the card edge of the ICC when it is the currently selected card application. All PIV Card Application card commands SHALL be supported by a PIV Card Application. Card commands indicated by a “Yes” in the Command Chaining column SHALL support command chaining for transmitting a data string that is too long for a single command, as defined in [ISO7816].

Table 2. PIV Card Application card commands

The PIV Card Application shall return the status word of '6A 81' (Function not supported) when it receives a card command on the contactless interface marked “No” in the Contactless Interface column in Table 2. The PIV Card Application may return a different status word (e.g., '69 82') if the card command can be performed over the contactless interface in support of card management. The PIV Card Application will only perform the command in support of card management if the requirements specified in Section 2.9.2 of FIPS 201-2 are satisfied.

Note 1: For SM, OCC and pairing code alone CAN be submitted via secure messaging (SM) over the contactless interface. All other key references require VCI for communication over the contactless interface.

Note 2: Cryptographic protocols using private/secret keys that require the “PIN” or “OCC” security condition SHALL only be used on the contactless interface after a virtual contact interface (VCI) has been established. The VCI⁴ is established when the following security condition is met:

(command is submitted over secure messaging) AND (the Discovery Object is present) AND (Bit 4 of the first byte of the PIN Usage Policy is one) AND ((the security status indicator associated with the pairing code is TRUE) OR (Bit 3 of the first byte of the PIN Usage Policy is one))

The SELECT card command sets the currently selected application. The PIV Card Application SHALL be selected by providing its application identifier (see Part 1, Sec. 2.2) in the data field of the SELECT command.

There SHALL be at most one PIV Card Application on any ICC. The PIV Card Application CAN also be made the currently selected application by providing the right-truncated version (see Part 1, Sec. 2.2) — that is, without the 2-byte version number in the data field of the SELECT command.

The complete AID of the PIV Card Application – including the 2-byte version – that became the currently selected card application upon successful execution of the SELECT command (using the full or right-truncated PIV AID) SHALL be returned in the application property template.

If the currently selected application is the PIV Card Application when the SELECT command is given and the AID in the data field of the SELECT command is either the AID of the PIV Card Application or the right-truncated version thereof, then the PIV Card Application SHALL continue to be the currently selected card application, and the setting of all security status indicators in the PIV Card Application SHALL be unchanged.

If the currently selected application is the PIV Card Application when the SELECT command is given and the AID in the data field of the SELECT command is not the PIV Card Application (or the right-truncated version thereof) but a valid AID supported by the ICC, then the PIV Card Application SHALL be deselected, and all the PIV Card Application security status indicators in the PIV Card Application SHALL be set to FALSE.

If the currently selected application is the PIV Card Application when the SELECT command is given and the AID in the data field of the SELECT command is an invalid AID not supported by the ICC, then the PIV Card Application SHALL remain the currently selected application, and all PIV Card Application security status indicators SHALL remain unchanged.

Command Syntax

Response Syntax

Upon selection, the PIV Card Application SHALL return the application property template described in Table 3.

Table 3. Data objects in the PIV Card Application property template (Tag '61')

Table 4. Data objects in a coexistent tag allocation authority template (Tag '79')

A PIV Card Application MAY use a subset of the cryptographic algorithms defined in SP 800-78. Tag 0xAC encodes the cryptographic algorithms supported by the PIV Card Application. The encoding of tag 0xAC SHALL be as specified in Table 5. Each instance of tag 0x80 SHALL encapsulate one algorithm. The presence of algorithm identifier '27' or '2E' indicates that the corresponding cipher suite is supported by the PIV Card Application for secure messaging and that the PIV Card Application possesses a PIV Secure Messaging key of the appropriate size for the specified cipher suite. Tag 0xAC SHALL be present and indicate algorithm identifier 0x27 or 0x2E (but not both) when the PIV Card Application supports secure messaging.

Table 5. Data objects in a cryptographic algorithm identifier template (Tag 'AC')

The GET DATA card command retrieves the data content of the single data object whose tag is given in the data field.⁵

Command Syntax

Table 6. Data objects in the data field of the GET DATA card command

Response Syntax

For the 0x7E Discovery Object (if present) and the 0x7F61 BIT Group Template (if present):

For all other PIV data objects (if present):

The VERIFY card command initiates the comparison in the card of the reference data indicated by the key reference with authentication data in the data field of the command.

Key reference '80' specific to the PIV Card Application (i.e., local key references) and, optionally, the Global PIN with key reference '00', the OCC data (key references '96' and '97'), and pairing code (key reference '98') are the only key references that MAY be verified by the PIV Card Application’s VERIFY command. The PIV Card Application MAY allow other key references to be verified by the PIV Card Application’s VERIFY command if they are used for card management operations.

Key reference '80' SHALL be able to be verified by the PIV Card Application VERIFY command. If the PIV Card Application does not contain the Discovery Object as described in Part 1, then no other key reference SHALL be able to be verified by the PIV Card Application VERIFY command. If the PIV Card Application contains the Discovery Object, then the ability of the PIV Card Application’s VERIFY command to verify key references '00', '96', '97', and '98' SHALL be as specified by the first byte of the Discovery Object’s PIN Usage Policy value:

If any key reference value is specified that CANNOT be verified by the PIV Card Application, then the PIV Card Application SHALL return the status word '6A 88'.

The VERIFY command MAY be submitted over the contact interface and, under some conditions, over the contactless interface. The card command SHALL fail if:

The P1 parameter SHALL be either '00' or 'FF'. If any other value is specified for the P1 parameter, then the PIV Card Application SHALL return the status word '6A 86'.

If the VERIFY command fails for one of the reasons specified above, then the security status and the retry counter of the key reference SHALL remain unchanged.

If P1='00' and \(L_c\) and the command data field are absent, the command CAN be used to retrieve the number of further retries allowed ('63 CX') or to check whether verification is not needed ('90 00').

If P1='00' and \(L_c\) and the command data field are present, then the authentication data in the command data field SHALL be compared against the reference data associated with the key reference, as specified in the following subsections. However, if the key reference is '00', '80', '96', or '97' and the current value of the retry counter associated with the key reference is zero, then the PIV Card Application SHALL return the status word '69 83'.7 In order to protect against blocking over the contactless interface, PIV Card Applications that implement secure messaging SHALL define an issuer-specified intermediate retry value for each of these key references and return '69 83' if the command is submitted over the contactless interface (over secure messaging or the VCI, as required for the key reference) and the current value of the retry counter associated with the key reference is at or below the issuer-specified intermediate retry value. If status word '69 83' is returned, then the comparison SHALL NOT be made, and the security status and the retry counter of the key reference SHALL remain unchanged.

If P1='FF', and \(L_c\) and the command data field are absent, the command SHALL reset the security status of the key reference in P2. The security status of the key reference specified in P2 SHALL be set to FALSE, and the retry counter associated with the key reference SHALL remain unchanged.

If the key reference is '00' or '80' and the authentication data in the command data field does not satisfy the criteria in Sec. 2.4.3, then the card command SHALL fail, and the PIV Card Application SHALL return either the status word '6A 80' or '63 CX'. If status word '6A 80' is returned, the security status and the retry counter of the key reference SHALL remain unchanged.⁸ If status word '63 CX' is returned, the security status of the key reference SHALL be set to FALSE, and the retry counter associated with the key reference SHALL be decremented by one.

If the authentication data in the command data field is properly formatted (see previous paragraph) and does not match reference data associated with the key reference, then the card command SHALL fail, the PIV Card Application SHALL return the status word '63 CX', the security status of the key reference SHALL be set to FALSE, and the retry counter associated with the key reference SHALL be decremented by one.

If the card command succeeds, then the security status of the key reference SHALL be set to TRUE, and the retry counter associated with the key reference SHALL be set to the reset retry value associated with the key reference. The initial value of the retry counter and the reset retry value associated with the key reference (i.e., the number of successive failures/retries before the retry counter associated with the key reference reaches zero) is 10 or less for both key references in accordance with FIPS 201, Section 2.9.3.

If the key reference is '96' or '97' and the authentication data in the command data field is not of length 3N, where N satisfies the requirements for the minimum and maximum number of minutiae specified in the BIT, then the card command SHALL fail, and the PIV Card Application SHALL return the status word '6A 80'. The security status and the retry counter of the key reference SHALL remain unchanged.

If the authentication data in the command data field is properly formatted (see previous paragraph) and does not match the reference data associated with the key reference, then the card command SHALL fail, the PIV Card Application SHALL return the status word '63 CX', the security status of the key reference SHALL be set to FALSE, and the retry counter associated with the key reference SHALL be decremented by one.

If the card command succeeds, then the security status of the key reference SHALL be set to TRUE, and the retry counter associated with the key reference SHALL be set to the reset retry value associated with the key reference. The initial value of the retry counter and the reset retry value associated with the key reference (i.e., the number of successive failures/retries before the retry counter associated with the key reference reaches zero) are 10 or less in accordance with FIPS 201, Section 2.9.3.

If the key reference is '98' and the authentication data in the command data field does not match the reference data associated with the key reference, the command SHALL fail, and the PIV Card Application SHALL return the status word '63 00'. If the authentication data in the command data field does not satisfy the criteria in Sec. 2.4.3, then the PIV Card Application MAY return the status word '6A 80' instead of '63 00'. If status word '6A 80' is returned, the security status of the key reference SHALL remain unchanged. If status word '63 00' is returned, the security status of the key reference SHALL be set to FALSE.

If the card command succeeds, then the security status of the key reference SHALL be set to TRUE.

Command Syntax

Response Syntax

The CHANGE REFERENCE DATA card command initiates the comparison of the authentication data in the command data field with the current value of the reference data and replaces the reference data with new reference data if the comparison is successful. This command CAN be used by the PIV Card Application Administrator and the Cardholder. The CHANGE REFERENCE DATA command SHALL support command chaining if the PIV Card Application supports OCC.

Only reference data associated with key references '80', '81' specific to the PIV Card Application (i.e., local key reference), and the Global PIN with key reference '00' MAY be changed by the PIV Card Application CHANGE REFERENCE DATA command. The PIV Card Application MAY allow the reference data associated with other key references (e.g., ‘96’ and ‘97’) to be changed by the PIV Card Application CHANGE REFERENCE DATA if they are used for card management operations and the requirements specified in Section 2.9.2 of FIPS 201-3 are satisfied. If any key reference value is specified that is not supported by the card, the PIV Card Application SHALL return the status word '6A 88'. Key reference '80' reference data SHALL be changed by the PIV Card Application CHANGE REFERENCE DATA command. The ability to change reference data associated with key references '81' and '00' using the PIV Card Application CHANGE REFERENCE DATA command is optional.

If key reference '81' is specified and the command is not submitted over the contact interface, then the card command SHALL fail. If key reference '00' or '80' is specified and the command is not submitted over either the contact interface or the VCI, then the card command SHALL fail.

In each case, the security status and the retry counter of the key reference SHALL remain unchanged.

If the current value of the retry counter associated with the key reference is zero, then the reference data associated with the key reference SHALL NOT be changed, and the PIV Card Application SHALL return the status word '69 83'. If the command is submitted over the contactless interface (VCI) and the current value of the retry counter associated with the key reference is at or below the issuer-specified intermediate retry value (see Sec. 3.2.1), then the reference data associated with the key reference SHALL NOT be changed, and the PIV Card Application SHALL return the status word '69 83'.

If the authentication data in the command data field does not match the current value of the reference data or if either the authentication data or the new reference data in the command data field of the command does not satisfy the criteria in Sec. 2.4.3, the PIV Card Application SHALL NOT change the reference data associated with the key reference and SHALL return either status word '6A 80' or '63 CX', with the following restrictions. If the authentication data in the command data field satisfies the criteria in Sec. 2.4.3 and matches the current value of the reference data, but the new reference data in the command data field of the command does not satisfy the criteria in Sec. 2.4.3, the PIV Card Application SHALL return status word '6A 80'. If the authentication data in the command data field does not match the current value of the reference data, but both the authentication data and the new reference data in the command data field of the command satisfy the criteria in Sec. 2.4.3, the PIV Card Application SHALL return status word '63 CX'. If status word '6A 80' is returned, the security status and retry counter associated with the key reference SHALL remain unchanged.¹⁰ If status word '63 CX' is returned, the security status of the key reference SHALL be set to FALSE, and the retry counter associated with the key reference SHALL be decremented by one.

If the card command succeeds, then the security status of the key reference SHALL be set to TRUE, and the retry counter associated with the key reference SHALL be set to the reset retry value associated with the key reference.

The initial value of the retry counter and the reset retry value associated with the key reference (i.e., the number of successive failures/retries before the retry counter associated with the key reference reaches zero) are issuer-dependent.

Command Syntax

Response Syntax

The RESET RETRY COUNTER card command resets the retry counter of the PIN to its initial value and changes the reference data. The command enables recovery of the PIV Card Application PIN if the cardholder forgets it.

The only key reference allowed in the P2 parameter of the RESET RETRY COUNTER command is '80', the PIV Card Application PIN. The PIV Card Application MAY allow the reference data associated with other key references to be changed by the PIV Card Application RESET RETRY but only if the requirements specified in Section 2.9.2 of FIPS 201-2 are satisfied. If a key reference is specified in P2 that is not supported by the card, the PIV Card Application SHALL return the status word '6A 88'.11

If the reset retry counter authentication data (PUK) in the command data field of the command does not match the reference data associated with the PUK, then the PIV Card Application SHALL return the status word '63 CX'. If the current value of the PUK’s retry counter is zero, then the PIN’s retry counter shall not be reset, the PIV Card Application shall return the status word '69 83', and the reset operation shall be blocked.

If the new reference data (PIN) in the command data field of the command does not satisfy the criteria in Sec. 2.4.3, then the PIV Card Application SHALL return the status word '6A 80'. If the reset retry counter authentication data (PUK) in the command data field of the command does not match the reference data associated with the PUK and the new reference data (PIN) in the command data field of the command does not satisfy the criteria in Sec. 2.4.3, then the PIV Card Application SHALL return status word '6A 80' or '63 CX'. If the PIV Card Application returns status word '6A 80', then the retry counter associated with the PIN SHALL NOT be reset, the security status of the PIN’s key reference SHALL remain unchanged, and the PUK’s retry counter SHALL remain unchanged.¹² If the PIV Card Application returns status word '63 CX', then the retry counter associated with the PIN SHALL NOT be reset, the security status of the PIN’s key reference SHALL be set to FALSE, and the PUK’s retry counter SHALL be decremented by one.

If the card command succeeds, then the PIN’s retry counter SHALL be set to its reset retry value. Optionally, the PUK’s retry counter MAY be set to its initial reset retry value. The security status of the PIN’s key reference SHALL NOT be changed.

The initial retry counter associated with the PUK (i.e., the number of failures of the RESET RETRY COUNTER command before the PUK’s retry counter reaches zero) is issuer-dependent.

Command Syntax

Response Syntax

The GENERAL AUTHENTICATE card command performs a cryptographic operation, such as an authentication protocol, using the data provided in the data field of the command and returns the result of the cryptographic operation in the response data field.¹³

The GENERAL AUTHENTICATE command SHALL be used with the PIV authentication keys ('9A', '9B', '9E') to authenticate the card or a card application to the client application (INTERNAL AUTHENTICATE), to authenticate an entity to the card (EXTERNAL AUTHENTICATE), and to perform a mutual authentication between the card and an entity external to the card (MUTUAL AUTHENTICATE).

The GENERAL AUTHENTICATE command SHALL be used with the digital signature key ('9C') to realize the signing functionality on the PIV client application programming interface. Data to be signed is expected to be hashed off-card. Appendix A.4 illustrates the use of the GENERAL AUTHENTICATE command for signature generation.

The GENERAL AUTHENTICATE command SHALL be used with the key management key ('9D') and the retired key management keys ('82' – '95') to realize the key establishment schemes specified in SP 800-78 (ECDH and RSA). Appendix A.5 illustrates the use of the GENERAL AUTHENTICATE command for key establishment schemes aided by the PIV Card Application.

The GENERAL AUTHENTICATE command SHALL be used with the PIV Secure Messaging key ('04') and cryptographic algorithm identifier '27' or '2E' to establish session keys for secure messaging, as specified in Sec. 4. If key reference '04' is specified in P2, then algorithm identifiers in P1 other than '27' and '2E' SHALL NOT be permitted, and the PIV Card Application SHALL return the status word '6A 86'.

The GENERAL AUTHENTICATE command supports command chaining to permit the uninterrupted transmission of long command data fields to the PIV Card Application. If a card command other than the GENERAL AUTHENTICATE command is received by the PIV Card Application before the termination of a GENERAL AUTHENTICATE chain, the PIV Card Application SHALL roll back to the state it was in immediately prior to the reception of the first command in the interrupted chain. In other words, an interrupted GENERAL AUTHENTICATE chain has no effect on the PIV Card Application.

Command Syntax

Table 7. Data objects in the dynamic authentication template (Tag '7C')

The data objects that appear in the dynamic authentication template (tag '7C') in the data field of the GENERAL AUTHENTICATE card command depend on the authentication protocol being executed. The Witness (tag '80') contains encrypted data (unrevealed fact), which is decrypted by the card. The Challenge (tag '81') contains clear data (byte sequence), which is encrypted by the card. The Response (tag '82') contains either the decrypted data from tag '80' or the encrypted data from tag '81'. Exponentiation SHALL NOT be allowed on keys 9A, 9C, and 9E. Note that the empty tags (i.e., tags with no data) return the same tag with content (they CAN be seen as “requests for requests”):

Response Syntax

The PUT DATA card command completely replaces the data content of a single data object in the PIV Card Application with new content.

Command Syntax

For the 0x7E Discovery Object:

Table 8. Data field of the PUT DATA card command for the Discovery Object

For the 0x7F61 BIT Group template:

Table 9. Data field of the PUT DATA card command for the BIT Group template

For all other PIV data objects:

Table 10. Data field of the PUT DATA card command for all other PIV data objects

Response Syntax

The GENERATE ASYMMETRIC KEY PAIR card command initiates the generation and storage of the reference data of an asymmetric key pair (i.e., a public key and a private key) in the card. The public key of the generated key pair is returned as the response to the command. If there is reference data currently associated with the key reference, it is replaced in full by the generated data.

Command Syntax

Table 11. Data objects in the template (Tag 'AC')

Response Syntax

Table 12. Data objects in the template (Tag '7F49')

The public-key data object in tag '86' is encoded as follows:

Table 13. Public-key encoding for ECC

The octet '04' indicates that the X and Y coordinates of point P are encoded without the use of point compression. The length L is 65 bytes for points on Curve P-256 and 97 bytes for points on Curve P-384.

If a PIV Card Application implements the optional secure messaging protocol for non-card management operations, it SHALL be implemented as specified in this section. Secure messaging is initiated through the use of a key establishment protocol. The key establishment protocol defined here is a one-way authentication protocol that authenticates the PIV Card Application to the client application and establishes a set of session keys that MAY be subsequently used to protect the communication channel between the two parties.¹⁴ PIV Cards MAY implement a different secure messaging protocol for card management operations. Such a protocol is outside of the scope of this document. However, if it is to be used for remote post-issuance updates, it SHALL satisfy the requirements of [FIPS201, Section 2.9.2].

Section 4.1 describes the key establishment protocol used to support secure messaging in the PIV Card Application. Section 4.2 describes the use of secure messaging to protect the commands and responses sent between the client application and the PIV Card Application.

The key establishment protocol for the PIV Card Application uses the One-Pass Diffie-Hellman, C(1e, 1s, ECC CDH) Scheme from [SP800-56A] in a manner that is based on a simplified profile of OPACITY with Zero Key Management [ANSI504-1], as depicted in below.

Table 14: Key Establishment Protocol for PIV Card Application

Client Application (H)

PIV Card Application (ICC)

CBH = 0x00

H1

C1

C2

Check that CBICC is 0x00

C3

C5 C6

C7

Zeroize Z

C8

AuthCryptogramICC =

C9

C10

C11

Check that CBICC is 0x00

H4

Verify CICC signature and subject public key

H5

H6

Extract QsICC from CICC

H7

H8

Zeroize deH

H9

H11

Check that AuthCryptogramICC equals

H12

Zeroize SKCFRM

H13

Sections 4.1.1 and 4.1.2 provide additional details about each of the protocol steps performed by the client application and the PIV Card Application. Section 4.1.3 defines the notations used in the description of the protocol. Section 4.1.4 provides details about the two cipher suites that MAY be supported by the PIV Card Application. Section 4.1.5 specifies the format for the secure messaging card verifiable certificate (CVC) that is used to authenticate the PIV Card Application and for the optional Intermediate CVC that is used to verify the signature on the secure messaging CVC when the public key needed to verify the signature on the secure messaging CVC does not appear in an X.509 content signing certificate. Section 4.1.6 provides additional information about the key derivation function (KDF) used to derive the session keys that are used during secure messaging. Section 4.1.7 provides additional information about the computation of the authentication cryptogram for key confirmation. Section 4.1.8 demonstrates the use of the GENERAL AUTHENTICATE command to perform the key establishment protocol.

Table 15: Protocol Steps for Client Application

Table 16: Protocol Steps for PIV Card Application

Table 17: Notations used in Protocol Description

This document specifies two cipher suites (see Table 18) that MAY be used for key establishment and secure messaging: one that provides 128 bits of channel strength and one that provides 192 bits of channel strength. If the PIV Card Application supports the VCI and either the digital signature key ('9C'), the key management key ('9D'), or one of the retired key management keys ('82' – '95') is an ECC (Curve P-384) key, then PIV Card Application SHALL only support cipher suite CS7. Otherwise, the PIV Card Application MAY support either CS2 or CS7.

Table 18. Cipher suite for PIV secure messaging

Table 15 specifies the format for the secure messaging CVC, \(C_{ICC}\). Table 20 specifies the format for the optional Intermediate CVC.

\(C_{ICC}\) is used to authenticate the PIV Card Application. The specific data object tags and specified order must be used for both CVCs to allow the CVC processing within authentication protocols. The specific data object tags for \(C_{ICC}\) and the optional Intermediate CVC are provided in Table 19 and Table 20, respectively.

Table 19. Secure messaging card verifiable certificate format

Table 20. Intermediate card verifiable certificate format

Before signing the CVC, the signer SHALL perform partial public-key validation [SP800-56A, Section 5.6.2.3.2] for the public key that will be placed in the public-key object and SHALL verify that the subject is in possession of the corresponding private key (see [SP800-56A, Section 5.6.2.2.3.2] and [SP800-57, Section 8.1.5.1.1.2] for discussions on methods to obtain assurance of private-key possession).

The session keys SHALL be derived in Steps C7 and H10 of the protocol using the key derivation function from [SP800-56A, Section 5.8.1], with the auxiliary function H being the hash function specified as the KDF hash in Table 18, the length of the keying material to be derived (len) being 512 bits for CS2 and 1024 bits for CS7, and OtherInfo being constructed using the following concatenation format:

For Q , the coordinates of the ephemeral public key are converted from field elements to byte

eH

strings (as specified in [SP800-56A, Appendix C.2]), Field-Element-to-Byte String Conversion, and concatenated (with x first) to form a single byte string. The first 16 bytes from this byte string are included in OtherInfo.

Key confirmation SHALL be performed in Steps C9 and H12 of the protocol by the generation of AuthCryptogram in accordance with Sections 5.9.1.1 and 6.2.2.3 of [SP800-56A].

ICC

AuthCryptogram SHALL be computed as CMAC(MacKey, MacLen, MacData ), where MacKey

p

ICC

sICC sH eH

byte ASCII string ('4B 43 5F 31 5F 56'). For Q , the coordinates of the ephemeral public key are eH converted from field elements to byte strings (as specified in [SP800-56A, Appendix C.2]), Field-Element-to-Byte String Conversion, and concatenated (with x first) to form a single byte string.

CMAC is a cipher-based message authentication code from [SP800-38B], where the block cipher is AES.

The following command interface SHALL be used for the key establishment protocol.

PIV secure messaging is used to protect the integrity and confidentiality of the PIV data being transmitted between the card and the relying system. PIV secure messaging SHALL be provided using symmetric session keys derived through the key establishment protocol defined Section 4.1.

Once session keys are established and the card is authenticated as specified in Section 4.1, subsequent communication with the card CAN be performed using secure messaging by setting bits b3 and b4 of the CLA byte of the command APDU to 1, resulting in a '0C' or '1C' CLA byte. If bits b3 and b4 of the CLA byte are set, then both the command and the response SHALL be encrypted and integrity protected, as described in this section. If the PIV Card Application CANNOT encrypt and integrity protect the response (e.g., because it does not support secure messaging or no session keys have been established), the PIV Card Application SHALL return an error (see Section 4.2.7). In the case of command chaining, if bits b3 and b4 of the CLA are set in any command in the chain, then they SHALL be set in every command in the chain.

When secure messaging is used, the data field of the card command (or response) is encrypted first and then a message authentication code (MAC) is applied to the entire command (or response). When command (or response) chaining is required, the encryption and MAC are applied to the entire message, and the result is then fragmented into separate command (or response) data fields.

In order to ensure that message reordering or replay attacks CAN be detected, a 16-byte MAC chaining value (MCV) is used. For the first command, and for the first response, sent after successful completion of the key establishment protocol the MCV consists of 16 bytes of '00'. For each subsequent command the MCV is the 16-byte MAC value computed on the previous command, and for each subsequent response the MCV is the 16-byte MAC value computed on the previous response. The MCV is included as part of the message over which the MAC value for each command (or response) is computed.

The \(SK_{ENC}\) session key SHALL be used to encrypt the command data field and response data field, as described in Section 4.2.2. The \(SK_{MAC}\) session key SHALL be used to add integrity to the command, as described in Section 4.2.3. The \(SK_{RMAC}\) session key SHALL be used to add integrity to the response, as described in Section 4.2.5.

Secure messaging specified in this section CAN be applied to the following commands:

The command and response messages SHALL be BER-TLV encoded according to Table 21.

Table 21. Secure messaging data objects

Under secure messaging, the PIV data is encrypted using AES in Cipher Block Chaining (CBC) mode with the \(SK_{ENC}\) session key, where \(SK_{ENC}\) is a 128-bit key for CS2 and a 256-bit key for CS7, as per Table 18. The encryption and encoding process for command data and response data SHALL be the same. The encryption of the command data or response data and encoding in BER-TLV format is illustrated Fig. 1. The encryption SHALL be computed over the entire message before applying fragmentation for data transportation.

Fig. 1. PIV data confidentiality

Initialization Vector (IV). The IV for the AES CBC encryption of command data SHALL be generated by applying the AES block cipher to a 16-byte encryption counter. The initial value of the encryption counter upon successful completion of the key establishment protocol SHALL be '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01'. The encryption counter SHALL be incremented by one after each APDU sent over secure messaging (except for the GET RESPONSE command and APDUs with a CLA of '1C'), and it SHALL be reset to its initial value after each successful completion of the key establishment protocol. The 16-byte IV SHALL be created by encrypting the encryption counter with SK using AES in the electronic codebook

ENC

(ECB) mode of operation.

The IV for the AES CBC encryption of response data SHALL also be generated by encrypting an encryption counter with SK using AES in the ECB mode of operation. The encryption counter

ENC

value used to generate the IV to encrypt the response data SHALL be the same as the encryption counter value used to generate the IV to encrypt the corresponding request data, with the exception that the most significant byte of the 16-byte counter SHALL be set to '80' (i.e., the IV used to encrypt the first response after successful completion of the key establishment protocol SHALL be generated by encrypting '80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01' with SK ).

ENC

Padding. Prior to encryption, 1 – 16 bytes of padding data SHALL be appended to the PIV data. The padding SHALL be '80' followed by the number of zeros needed to make the total length of the message to be encrypted (i.e., PIV data plus padding) a multiple of 16 bytes. The first byte of the value field of tag '87' — the padding content indicator byte — SHALL be '01' to indicate that padding has been applied.

As illustrated in Fig. 1, the input and output of encryption are as follows:

Plain Text

BER-TLV-encoded encrypted message, which consists of tag '87' followed by the length of the encoded encrypted message (L + 1), the padding indicator byte ('01'), and then cc the encrypted data. L is the length of the encrypted PIV data; it SHALL be a multiple of

cc

16.

The Command MAC (C-MAC) SHALL be generated by applying the cipher-based MAC (CMAC) [SP800-38B] to the header and data field of a command using the SK session key. If

MAC

fragmentation is required for data transmission, the command SHALL be constructed without fragmentation for the purposes of computing the MAC, and the CLA byte used in the computation of the MAC SHALL be '0C'.

The data to be MACed, M , SHALL be constructed by concatenating the following:

C-MAC

MAC C-MAC

the command SHALL be the 8 most significant bytes of T encapsulated in BER-TLV format

C-MAC

with tag '8E'. The entire 16-byte value T will be the MCV for the next command. C-MAC

Figure 2 illustrates how the C-MAC is generated for each command.

Fig. 2. PIV data integrity of command

For secure messaging, the secure messaging data field SHALL be constructed as the concatenation of the following:

Fig. 3. Single command under secure messaging

Command chaining will be needed if the secure messaging data field to be transported is larger than 255 bytes. Figure 4 shows the APDUs for secure messaging when the length of the secure messaging data field is between 256 and 510 bytes, which requires the data to be fragmented across two APDUs. The APDUs are constructed in the same manner as when fragmentation is not required, except that the CLA byte for the first APDU is '1C', the first APDU contains the first 255 bytes of the secure messaging data field, and the second APDU contains the remaining bytes of the secure messaging data field and the new L field ('00'). The PIV Card Application

e

provides a 2-byte response of '90 00' for the first APDU. After receiving the second APDU, the PIV Card Application reconstructs and processes the entire command.

Fig. 4. Chained command under secure messaging

The response MAC (R-MAC) SHALL be generated by applying CMAC [SP800-38B] to the data field and status bytes of the response using the SK session key. An R-MAC SHALL be

RMAC generated for each response that corresponds to a command that was sent to the card using secure messaging.

The data to be MACed, M , SHALL be constructed by concatenating the following:

R-MAC

RMAC R-MAC

for the response SHALL be the 8 most significant bytes of T encapsulated in BER-TLV format

R-MAC

with tag '8E'. The entire 16-byte value T will be the MCV for the next response. R-MAC

Figure 5 illustrates how the R-MAC is generated for the response.

Fig. 5. PIV data integrity of response

For secure messaging, the secure messaging data field that is sent by the PIV Card Application SHALL be constructed as the concatenation of the following:

Figure 6 illustrates a response under secure messaging when response chaining is not required. The APDU consists of the secure messaging data field and the 2-byte SW processing status ('90 00'), which indicates that the PIV Card Application successfully verified the C-MAC on the command and decrypted the data field in the command (if present). If the PIV Card Application was unable to verify the C-MAC on the command or decrypt the data field in the command, then it SHALL return a 2-byte error response, as described in Section 4.2.7.

Fig. 6. Single response under secure messaging

Response chaining²³ will be needed if the secure messaging data field to be transported is larger than 256 bytes. Figure 7 shows the APDUs for secure messaging that are sent by the PIV Card Application when the length of the secure messaging data field is between 513 and 768 bytes, which requires the data to be fragmented across three APDUs. After the first response, an APDU of '00 C0 00 00 00' will be sent to request the second response. After the second response, an APDU of '00 C0 00 00 xx' will be sent to request the third response.

Fig. 7. Chained response under secure messaging

The SW processing status is the status word of the overall secure messaging command and response processing. It indicates whether the secure messaging was performed successfully. If the processing was successful, it SHALL be '90 00'. Otherwise, it SHALL be as follows:

If the command processing was unsuccessful, the card SHALL return one of the above status words without performing further secure messaging.

The session keys established after successful execution of the key establishment protocol in Section 4.1 SHALL be zeroized in the following circumstances:

References

[ANSI504-1] InterNational Committee for Information Technology Standards (2023) INCITS 504-1-2013 (R2023) - Information Technology - Generic Identity Command Set – Part 1: Card Application Command Set, [or as amended]. Available at https://webstore.ansi.org/standards/incits/incits5042013r2023

[FIPS201] National Institute of Standards and Technology (2022) Personal Identity Verification (PIV) of Federal Employees and Contractors. (Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 201-3. https://doi.org/10.6028/NIST.FIPS.201-3

[ISO7816] International Organization for Standardization/International Electrotechnical Commission (2004-2020) ISO/IEC 7816 — Identification cards — Integrated circuit cards. (multiple parts):

[ISO8824] International Organization for Standardization/International Electrotechnical Commission (2021) ISO/IEC 8824-2:2021 — Information technology — Abstract Syntax Notation One (ASN.1) – Part 2: Information object specification. (International Organization for Standardization, Geneva, Switzerland) [or as amended]. Available at https://www.iso.org/standard/81417.html

[ISO8825] International Organization for Standardization/International Electrotechnical Commission (2015) ISO/IEC 8825-1:2015— Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) Part 1. (International Organization for Standardization, Geneva, Switzerland) [or as amended]. Available at https://www.iso.org/standard/81420.html

[PKCS1] Moriarty K, Kaliski B, Jonsson J, Rusch A (2016). Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.2. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 8017. Available at https://www.rfc-editor.org/rfc/rfc8017

[SECG] Certicom (2009) Standards for Efficient Cryptography, SEC 1: Elliptic Curve Cryptography, Version 2.0. Available at https://www.secg.org/sec1-v2.pdf

[SP800-38B] Dworkin MJ (2005) Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-38B, Includes updates as of October 6, 2016 [or as amended]. https://doi.org/10.6028/NIST.SP.800-38B

[SP800-56A] Barker EB, Chen L, Roginsky AL, Vassilev A, Davis R (2018) Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56A, Rev. 3 [or as amended]. https://doi.org/10.6028/NIST.SP.800-56Ar3

[SP800-76] Grother PJ, Salamon WJ, Chandramouli R (2013) Biometric Specifications for Personal Identity Verification. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-76-2 [or as amended]. https://doi.org/10.6028/NIST.SP.800-76-2

[SP800-78] Ferraiolo H, Regenscheid A (2024) Cryptographic Algorithms and Key Sizes for Personal Identity Verification. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-78-5 [or as amended]. https://doi.org/10.6028/NIST.SP.800-78-5

A.1. Authentication of the PIV Card Application Administrator

The PIV Card Application Administrator is authenticated by the PIV Card Application using a challenge-response protocol. A challenge retrieved from the PIV Card Application is encrypted by the client application and returned to the PIV Card Application associated with key reference '9B', which is the key reference of the PIV Card Application Administration key. The PIV Card Application decrypts the response using this reference data and the algorithm associated with the key reference (e.g., AES-128 – ECB, algorithm identifier '08'). If this decrypted value matches the previously provided challenge, then the security status indicator of the PIV Card Application Administration key is set to TRUE within the PIV Card Application.

Table 22 shows the GENERAL AUTHENTICATE card commands sent to the PIV Card Application to realize this particular challenge-response protocol.

Table 22. Authentication of PIV Card Application Administrator

Table 23. Mutual authentication of client application and PIV Card Application

Table 24 shows the GENERAL AUTHENTICATE card commands sent to the PIV Card Application to realize cardholder authentication when the X.509 Certificate for PIV Authentication includes a 2048-bit²⁷ RSA public key. It is assumed that the cardholder PIN or OCC data has been successfully verified prior to sending the GENERAL AUTHENTICATE command.

Table 24. Validation of the PIV Card Application using GENERAL AUTHENTICATE

A.4. Signature Generation With the Digital Signature Key

The GENERAL AUTHENTICATE command CAN be used to generate signatures. The pre-signature hash and padding (if applicable) are computed off-card. The PIV Card Application receives the hashed value of the original message, applies the private signature key (key reference '9C'), and returns the resulting signature to the client application.

The card commands sent to the PIV Card Application to generate a signature are listed below. It is assumed that the cardholder PIN or OCC data has been successfully verified prior to sending the GENERAL AUTHENTICATE command.

This example illustrates signature generation using RSA 204828 (i.e., algorithm identifier '07'). Command chaining is used in the first command since the padded hash value sent to the card for signature generation is bigger than the length of the data field.

Command 1 — GENERAL AUTHENTICATE (first chain)

Response 1

Command 2 — GENERAL AUTHENTICATE (last chain)

Response 2

Command 3 — GET RESPONSE APDU)

Response 3

The following example illustrates signature generation with ECDSA using ECC: Curve P-256 (i.e., algorithm identifier '11'). Command chaining is not used in this example, as the hash value fits into the data field of the command. Padding does not apply to ECDSA.

Command — GENERAL AUTHENTICATE

Response

A.5. Key Establishment Schemes With the PIV Key Management Key

FIPS 201 specifies a public key pair and associated X.509 Certificate for Key Management. The key management key (KMK) is further defined in SP 800-78, which defines two distinct key establishment schemes for the KMK:

The use of the KMK for RSA key transport and ECDH key agreement is discussed in Appendices A.5.1 and A.5.2, respectively.

A.5.1. RSA Key Transport

In general, RSA transport keys are used to establish symmetric keys, where a sender encrypts a symmetric key with the receiver’s public key and sends the encrypted key to the receiver. The receiver decrypts the encrypted key with the corresponding private key. The decrypted symmetric key is subsequently used by both parties to protect further communication between them. Many types of security protocols employ the RSA key transport technique, such as Secure/Multipurpose Internet Mail Extensions (S/MIME) for secure email.

A.5.1.1. RSA Key Transport With the PIV KMK

As specified in SP 800-78, the on-card private KMK CAN be an RSA transport key that complies with [PKCS1]. In the scenario described above, a sender encrypts a symmetric key with the public RSA transport key of the recipient’s KMK. The role of the on-card KMK private RSA transport key is to decrypt the sender’s symmetric key on behalf of the cardholder and provide it to the client application cryptographic module.

A.5.1.1.1GENERAL AUTHENTICATE Command

The card commands sent to the PIV Card to decrypt the symmetric key are listed below. It is assumed that the cardholder’s PIN or OCC data has been successfully verified prior to sending the GENERAL AUTHENTICATE command to the card.

Command 1 — GENERAL AUTHENTICATE (first chain)

Response 1

Command 2 — GENERAL AUTHENTICATE (last chain)

Response 2