Interfaces for Personal Identity Verification (Working Draft)

1Introduction¶

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, Personal Identity Verification (PIV) of Federal Employees and Contractors 7, 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.

1.1Purpose¶

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 23456. 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.

1.2Scope¶

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.

1.3Audience and Assumptions¶

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:

• The front matter describes configuration management recommendations.

  • Section 1.3 specifies the effective date of SP 800-73-5.

• The front matter also specifies NPIVP conformance testing procedures.

• Appendix G provides the full Revision History of SP 800-73.

1.4Content and Organization¶

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:

• Section 1, Introduction, provides the purpose, scope, audience, and assumptions of the document and outlines its structure.

• Section 2, Overview: Concepts and Constructs, describes the model of computation of the PIV Card Application and the PIV client application programming interface, including information processing concepts and data representation constructs.

• Section 3, PIV Card Application Card Command Interface, describes the set of commands accessible by the PIV Middleware to communicate with the PIV Card Application.

• Section 4, Secure Messaging, describes the secure messaging protocol that is used to enable data confidentiality and integrity.

• Appendix A demonstrates the GENERAL AUHTENTICATE command. This section is informative.

• Appendix B contains the list of acronyms used in this document. This section is informative.

• Appendix C contains a Glossary of terms used in this document. This section is informative.

• Appendix D explains the notation in use in this document. This section is informative.

2Overview: Concepts and Constructs¶

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.

2.1Platform Requirements¶

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

• Global security status that includes the security status of a global cardholder PIN

• Application selection using a truncated Application Identifier (AID)

• Ability to reset the security status of an individual application

• Indication to applications as to which physical communication interface — contact versus contactless — is in use

• Support for the default selection of an application upon warm or cold reset

2.2Namespaces of the PIV Card Application¶

Part 1 specifies the AID, names, Tag-Length-Value (BER-TLV) tags 8, ASN.1 Object Identifiers (OIDs) 9, 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.

2.3Card Applications¶

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) 2. 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.^[1] 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.

2.3.1Default Selected Card 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.

2.4Security Architecture¶

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.

2.4.1Access Control Rule¶

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 Section 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.

2.4.2Security Status¶

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.

2.4.3Authentication of an Individual¶

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 0xFF 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:

• Actual PIV Card Application PIN: “123456” or 31 32 33 34 35 36

• Padded PIV Card Application PIN presented to the card command interface: 31 32 33 34 35 36 FF FF

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.

2.5Current State of the PIV Card Application¶

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.

3PIV Card Application Card Command Interface¶

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^[2][3]. 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 2.

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.

3.1PIV Card Application Card Commands for Data Access¶

3.1.1SELECT Card Command¶

The SELECT card command sets the currently selected application. The PIV Card Application SHALL be selected by providing its application identifier (see Part 1, Section 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, Section 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.

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

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 6. 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.

3.1.2GET DATA Card Command¶

The GET DATA card command retrieves the data content of the single data object whose tag is given in the data field.^[5][6]

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

For all other PIV data objects (if present):

3.2PIV Card Application Card Commands for Authentication¶

3.2.1VERIFY Card Command¶

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 Bit 6 is one, then key reference 00 SHALL be able to be verified by the PIV Card Application VERIFY command.

• If Bit 5 is one, then key references 96 and/or 97, as specified in the Biometric Information Templates Group Template, SHALL be able to be verified by the PIV Card Application VERIFY command.

• If Bit 4 is one, then key reference 98 SHALL be able to be verified by the PIV Card Application VERIFY command.

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 key reference is 00 or 80, and the command is not submitted over either the contact interface or the VCI, or

• The key reference is 96, 97, or 98, and the command is submitted over the contactless interface without secure messaging.

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.

3.2.1.1PIV Card Application PIN and Global PIN¶

If the key reference is 00 or 80 and the authentication data in the command data field does not satisfy the criteria in Section 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.^[8] 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.

3.2.1.2On-Card Biometric Comparison¶

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.

3.2.1.3Pairing Code¶

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 Section 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.^[9][10]

3.2.2CHANGE REFERENCE DATA Card Command¶

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 Section 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 Section 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 Section 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 Section 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 Section 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.^[11] 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.

3.2.3RESET RETRY COUNTER Card Command¶

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.^[12]

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 Section 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 Section 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.^[13] 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.

3.2.4GENERAL AUTHENTICATE Card Command¶

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.^[14]

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 Section 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.

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”):

• 80 00 Returns 80 TL <encrypted random> (as per definition)

• 81 00 Returns 81 TL <random> (as per external authenticate example)

3.3PIV Card Application Card Commands for Credential Initialization and Administration¶

3.3.1PUT DATA Card Command¶

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

For the 0x7E Discovery Object:

For the 0x7F61 BIT Group template:

For all other PIV data objects:

3.3.2GENERATE ASYMMETRIC KEY PAIR Card Command¶

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.

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

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.

4Secure Messaging¶

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.^[15] 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 FIPS 201, Section 2.9.2 7.

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

4.1Key Establishment Protocol¶

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

Message 1 — Client Application (H) → PIV Card Application (ICC):

• [H1] Set $CB_H = \texttt{0x00}$

• [H2] Generate ephemeral key pair $(d_{eH},\ Q_{eH})$ from the domain parameters specified in the response to the SELECT command

• [H3] Send $CB_H \| ID_{sH} \| Q_{eH}$

Message 2 — PIV Card Application (ICC) → Client Application (H):

• [C1] $ID_{sICC} = T_8(\text{SHA-256}(C_{ICC}))$

• [C2] $CB_{ICC} = CB_H\ \&\ \texttt{0xF0}$

• [C3] Check that $CB_{ICC} = \texttt{0x00}$

• [C4] Verify that $Q_{eH}$ is a valid public key for the domain parameters of $Q_{sICC}$

• [C5] $Z = \text{ECC\_CDH}(d_{sICC},\ Q_{eH})$

• [C6] Generate nonce $N_{ICC}$

• [C7] $SK_{CFRM} \| SK_{MAC} \| SK_{ENC} \| SK_{RMAC} = \text{KDF}(Z,\ \textit{len},\ \textit{OtherInfo})$

• [C8] Zeroize $Z$

• [C9] $\text{AuthCryptogram}_{ICC} = \text{CMAC}(SK_{CRFM},\ \text{“KC\_1\_V”} \| ID_{sICC} \| ID_{sH} \| Q_{eH})$

• [C10] Zeroize $SK_{CFRM}$

• [C11] Return $CB_{ICC} \| N_{ICC} \| \text{AuthCryptogram}_{ICC} \| C_{ICC}$

Verification — Client Application (H):

• [H4] Check that $CB_{ICC} = \texttt{0x00}$

• [H5] Verify $C_{ICC}$ signature and subject public key

• [H6] $ID_{sICC} = T_8(\text{SHA-256}(C_{ICC}))$

• [H7] Extract $Q_{sICC}$ from $C_{ICC}$

• [H8] $Z = \text{ECC\_CDH}(d_{eH},\ Q_{sICC})$

• [H9] Zeroize $d_{eH}$

• [H10] $SK_{CFRM} \| SK_{MAC} \| SK_{ENC} \| SK_{RMAC} = \text{KDF}(Z,\ \textit{len},\ \textit{OtherInfo})$

• [H11] Zeroize $Z$

• [H12] Check that $\text{AuthCryptogram}_{ICC} = \text{CMAC}(SK_{CFRM},\ \text{“KC\_1\_V”} \| ID_{sICC} \| ID_{sH} \| Q_{eH})$

• [H13] Zeroize $SK_{CFRM}$

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.

4.1.1Client Application Steps¶

• [H1] Set $CB_H = \texttt{0x00}$

  The client application’s control byte is set to 0x00 to indicate that the client application does not support persistent binding.

• [H2] Generate an ephemeral key pair $(d_{eH},\ Q_{eH})$

  Generate an ephemeral ECC key pair for the client application using an approved method 15, and perform partial public-key validation per NIST SP 800-56A, Section 5.6.2.3.2 13, either as part of the key generation process or as a separate process. If the 0xAC tag of the application property template (APT) includes 27, generate an ephemeral key pair over Curve P-256. If it includes 2E, generate an ephemeral key pair over Curve P-384.

• [H3] Send $CB_H \| ID_{sH} \| Q_{eH}$

  (wait) Wait for response from PIV Card Application: $CB_{ICC} \| N_{ICC} \| \text{AuthCryptogram}_{ICC} \| C_{ICC}$

• [H4] Check that $CB_{ICC} = \texttt{0x00}$

  Verify that the card executed the protocol in accordance with the parameters specified in Step H1. Return an authentication error if check fails.

• [H5] Verify $C_{ICC}$ signature and subject public key

  Verify signature on $C_{ICC}$ and, using standards-compliant PKI path validation, validate the content signing certificate needed to verify the signature on $C_{ICC}$.^[16][17] Verify that the domain parameters of the subject public key in $C_{ICC}$ are the same as the domain parameters for $Q_{eH}$ by checking the Algorithm OID in the CardHolderPublicKey data object (see Table 24). Return an authentication error if either verification fails.

• [H6] $ID_{sICC} = T_8(\text{SHA-256}(C_{ICC}))$

  $ID_{sICC}$ — the leftmost 8 bytes of the SHA-256 hash of $C_{ICC}$ — is used as an input for session key derivation.

• [H7] Extract $Q_{sICC}$ from $C_{ICC}$

• [H8] $Z = \text{ECC\_CDH}(d_{eH},\ Q_{sICC})$

  Compute the shared secret $Z$ using the ECC CDH primitive per NIST SP 800-56A, Section 5.7.1.2 13.

• [H9] Zeroize $d_{eH}$

  Destroy the ephemeral private key generated in Step H2.

• [H10] $SK_{CFRM} \| SK_{MAC} \| SK_{ENC} \| SK_{RMAC} = \text{KDF}(Z,\ \textit{len},\ \textit{OtherInfo})$

  Compute the key confirmation key and the session keys. See Section 4.1.6.

• [H11] Zeroize $Z$

  Destroy the shared secret generated in Step H8.

• [H12] Check that $\text{AuthCryptogram}_{ICC} = \text{CMAC}(SK_{CFRM},\ \text{"KC\_1\_V"} \| ID_{sICC} \| ID_{sH} \| Q_{eH})$

  Perform key confirmation by verifying the authentication cryptogram, as described in Section 4.1.7. Return an authentication error if verification fails.

• [H13] Zeroize $SK_{CFRM}$

  Destroy the key confirmation key derived in Step H10.

4.1.2PIV Card Application Protocol Steps¶

• [C1] $ID_{sICC} = T_8(\text{SHA-256}(C_{ICC}))$

  $ID_{sICC}$ — the leftmost 8 bytes of the SHA-256 hash of $C_{ICC}$ — is used as an input for session key derivation. (Note that $ID_{sICC}$ is static and MAY be pre-computed off-card.)

• [C2] $CB_{ICC} = CB_H\ \&\ \texttt{0xF0}$

  Create the PIV Card Application’s control byte from the client application’s control byte, indicating that persistent binding has not been used in the transaction even if $CB_H$ indicates that the client application supports it. This MAY be done by setting $CB_{ICC}$ to the value of $CB_H$ and then setting the four least significant bits of $CB_{ICC}$ to 0.

• [C3] Check that $CB_{ICC} = \texttt{0x00}$

  Return an error (6A 80) if $CB_{ICC}$ is not 0x00.

• [C4] Verify that $Q_{eH}$ is a valid public key for the domain parameters of $Q_{sICC}$

  Perform partial public-key validation of $Q_{eH}$ per NIST SP 800-56A, Section 5.6.2.3.3 13,^[18] where the domain parameters are those of $Q_{sICC}$. Verify that P1 is 27 if the domain parameters of $Q_{sICC}$ are those of Curve P‑256 or that P1 is 2E if the domain parameters of $Q_{sICC}$ are those of Curve P‑384. Return 6A 86 if P1 has the incorrect value. Return 6A 80 if public-key validation fails.

• [C5] $Z = \text{ECC\_CDH}(d_{sICC},\ Q_{eH})$

  Compute the shared secret $Z$ using the ECC CDH primitive per NIST SP 800-56A, Section 5.7.1.2 13.

• [C6] Generate nonce $N_{ICC}$

  Create a random nonce, where the length is as specified in Table 23. The nonce should be created using an approved random bit generator where the security strength supported by the random bit generator is at least as great as the bit length of the nonce being generated per NIST SP 800-56A, Section 5.3 13.

• [C7] $SK_{CFRM} \| SK_{MAC} \| SK_{ENC} \| SK_{RMAC} = \text{KDF}(Z,\ \textit{len},\ \textit{OtherInfo})$

  Compute the key confirmation key and the session keys. See Section 4.1.6.

• [C8] Zeroize $Z$

  Destroy the shared secret generated in Step C5.

• [C9] $\text{AuthCryptogram}_{ICC} = \text{CMAC}(SK_{CFRM},\ \text{"KC\_1\_V"} \| ID_{sICC} \| ID_{sH} \| Q_{eH})$

  Compute the authentication cryptogram for key confirmation, as described in Section 4.1.7.

• [C10] Zeroize $SK_{CFRM}$

  Destroy the key confirmation key derived in Step C7.

• [C11] Return $CB_{ICC} \| N_{ICC} \| \text{AuthCryptogram}_{ICC} \| C_{ICC}$

4.1.3Notations¶

4.1.4Cipher Suite¶

This document specifies two cipher suites (see Table 23) 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.

4.1.5Card Verifiable Certificates¶

Table 24 specifies the format for the secure messaging CVC, C_ICC. Table 25 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 24 and Table 25, respectively.

The signature of the secure messaging CVC (DigitalSignature object) is calculated over the concatenation of the TLV-encoded Credential Profile Identifier, Issuer Identification Number, Subject Identifier, CardHolderPublicKey Data Object, and Role Identifier (i.e., { ‘5F29’ 01 80 } || { 42 08 IIN } || { ‘5F20’ 10 GUID } || { ‘7F49’ L1 { { 06 L2 OID } { 86 L3 04 X Y } } } { ‘5F4C’ 01 00 }). Before signing the CVC, the signer SHALL perform partial public-key validation (see NIST SP800-56A, Section 5.6.2.3.2 13) for the public key that will be placed in the public-key object and SHALL verify that the PIV Card is in possession of the corresponding private key (see NIST SP 800-56A, Section 5.6.2.2.3.2 13 and SP 800-57, Section 8.1.5.1.1.2 16 for discussions on methods to obtain assurance of private-key possession).

The signature of the Intermediate CVC (DigitalSignature object) is calculated over the concatenation of the TLV-encoded Credential Profile Identifier, Issuer Identification Number, Subject Identifier, PublicKey Data Object, and Role Identifier (i.e., { ‘5F29’ 01 80 } || { 42 08 IIN } || { ‘5F20’ 08 SI } || { ‘7F49’ L1 { { 06 L2 OID } { 86 L3 04 X Y } } } { ‘5F4C’ 01 12 }). Before signing the CVC, the signer SHALL perform partial public-key validation SP 800-56A, Section 5.6.2.3.2 13, 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 SP 800-56A, Section 5.6.2.2.3.2 13, and S P800-57, Section 8.1.5.1.1.2 16, for discussions on methods to obtain assurance of private-key possession).

4.1.6Key Derivation¶

The session keys SHALL be derived in Steps C7 and H10 of the protocol using the key derivation function from SP 800-56A, Section 5.8.1 13, with the auxiliary function H being the hash function specified as the KDF hash in Table 23, 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_eH, the coordinates of the ephemeral public key are converted from field elements to byte strings (as specified in SP 800-56A, Appendix C.2 13, 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.

4.1.7Key Confirmation¶

Key confirmation SHALL be performed in Steps C9 and H12 of the protocol by the generation of AuthCryptogram_ICC in accordance with Sections 5.9.1.1 and 6.2.2.3 of SP 800-56A 13. AuthCryptogram_ICC SHALL be computed as CMAC(MacKey, MacLen, MacData_p), where MacKey is SK_CFRM, MacLen is 128 bits, and MacData_p is “KC_1_V” || ID_sICC || ID_sH || Q_eH. “KC_1_V” is a 6-byte ASCII string (‘4B 43 5F 31 5F 56’). For Q_eH, the coordinates of the ephemeral public key are converted from field elements to byte strings (as specified in SP 800-56A, Appendix C.2, 13), 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 SP 800-38B, where the block cipher is AES 17.

4.1.8Command Interface¶

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

4.2Secure Messaging¶

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:

• GET DATA

• VERIFY

• CHANGE REFERENCE DATA

• GENERAL AUTHENTICATE

4.2.1Secure Messaging Data Objects¶

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

4.2.2Command and Response Data Confidentiality¶

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 23. 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 Figure 1. The encryption SHALL be computed over the entire message before applying fragmentation for data transportation.

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_ENC using AES in the electronic codebook (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_ENC using AES in the ECB mode of operation. The encryption counter 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 Figure 1, the input and output of encryption are as follows:

• Encryption input:

  Plain Text

• Encryption output:

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

4.2.3Command Integrity¶

The Command MAC (C-MAC) SHALL be generated by applying the cipher-based MAC (CMAC) 17 to the header and data field of a command using the SK_MAC session key. If 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_C-MAC, SHALL be constructed by concatenating the following:

1. The 16-byte MAC chaining value (MCV). For the first command 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 for the previous command.

2. A 16-btye encoded header. The encoded header SHALL consist of the CLA byte (0C), the INS byte, P1, and P2, followed by twelve bytes of padding, consisting of 80 followed eleven bytes of 00. (The length of the data field, L_c, is not included in the data to be MACed.)

3. The data field, which is the BER-TLV-encoded encrypted message.^[20]

4. L_e encapsulated in BER-TLV format with tag 97 if the L_e field is included in the command.^[21]

Let T_C-MAC = CMAC(SK_MAC, M_C-MAC), as described in NIST SP 800‑38B 17. The BER-TLV-encoded C-MAC for the command SHALL be the 8 most significant bytes of T_C-MAC encapsulated in BER-TLV format with tag 8E. The entire 16-byte value T_C-MAC will be the MCV for the next command.

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

4.2.4Command With PIV Secure Messaging¶

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

• The BER-TLV-encoded encrypted PIV data;^[22]

• The 3-btye BER-TLV-encoded L_e, as described in Section 4.2.3, if L_e would have been included in a message sent without secure messaging;

• The 10-byte BER-TLV-encoded C-MAC of the command, as described in Section 4.2.3; and

• A new L_e field, which SHALL be 1 byte and SHALL have a value of 00.^[23]

Figure 3 shows the APDU for secure messaging when command chaining is not required. The APDU consists of the CLA byte (0C), INS, P1, P2, the length of the secure messaging data field (L_c’), the secure messaging data field, and the new L_e field (00).

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_e field (00). The PIV Card Application 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.

4.2.5Response Integrity¶

The response MAC (R-MAC) SHALL be generated by applying CMAC 17 to the data field and status bytes of the response using the SK_RMAC session key. An R-MAC SHALL be generated for each response that corresponds to a command that was sent to the card using secure messaging.

The data to be MACed, M_R-MAC, SHALL be constructed by concatenating the following:

1. The 16-byte MAC chaining value (MCV). For the first response sent after successful completion of the key establishment protocol the MCV consists of 16 bytes of 00. For each subsequent response the MCV is the 16-byte MAC value computed for the previous response.

2. The data field (if present), which is the BER-TLV-encoded encrypted message

3. The status word, SW1, and SW2 encapsulated in BER-TLV format with tag 99

Let T_R-MAC = CMAC(SK_RMAC, M_R-MAC), as described in NIST SP 800-38B 17. The BER-TLV-encoded R-MAC for the response SHALL be the 8 most significant bytes of T_R-MAC encapsulated in BER-TLV format with tag 8E. The entire 16-byte value T_R-MAC will be the MCV for the next response.

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

4.2.6Response With PIV Secure Messaging¶

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:

• The BER-TLV-encoded encrypted message (when present);

• The 4-byte BER-TLV-encoded status word, as described in Section 4.2.5; and

• The 10-byte BER-TLV-encoded R-MAC of the response, as described in Section 4.2.5.

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.

Response chaining^[24] 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.

4.2.7Error Handling¶

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:

• 68 82 – Secure messaging not supported

• 69 82 – Security status not satisfied^[25]

• 69 87 – Expected secure messaging data objects are missing

• 69 88 – Secure messaging data objects are incorrect

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

4.3Session Key Destruction¶

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

• The card is reset,

• An error occurs in secure messaging,^[26] or

• New session keys are requested by the client application by sending a GENERAL AUTHENTICATE command to the card to perform the key establishment protocol using the PIV Secure Messaging key.

References¶

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.

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

The PIV Card Application Administrator and the PIV Card Application authenticate each other using a challenge-response protocol. A witness retrieved from the PIV Card Application is decrypted by the client application and returned to the PIV Card Application associated with key reference 9B, the key reference of the PIV Card Application Administration key. The command includes the decrypted witness and a challenge for the PIV Card Application. The PIV Card Application verifies that the decrypted witness matches the value that it encrypted to create the witness. If it does, then the security status indicator of the PIV Card Application Administration key is set to TRUE within the PIV Card Application, and the PIV Card Application encrypts the challenge that it received from the client application and returns the result. The witness and challenge are encrypted and decrypted using the same the key and algorithm. The following shows the GENERAL AUTHENTICATE card commands sent to the PIV Card Application to realize mutual authentication using AES – ECB (algorithm identifier '08’).

The PIV cardholder is authenticated by first retrieving and validating either the X.509 Certificate for PIV Authentication or the X.509 Certificate for Card Authentication. Assuming that the certificate is valid, the client application requests the PIV Card Application to sign a challenge using the private key associated with this certificate (i.e., key reference 9A or 9E) and the appropriate algorithm (e.g., algorithm identifier 07^[27]), which CAN be determined from the certificate, as described in SP 800-73-5 Part 1, Appendix C.1. The response from the card is verified using the public key in the certificate. If the signature is verified, then the PIV cardholder is authenticated.

The following 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^[28] RSA public key. It is assumed that the cardholder PIN or OCC data has been successfully verified prior to sending the GENERAL AUTHENTICATE command.

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 2048^[29] (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.

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.

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:

1. RSA key transport and

2. Elliptic Curve Diffie-Hellman (ECDH) key agreement.

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.

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.

As specified in SP 800-78, the on-card private KMK CAN be an RSA transport key that complies with PKCS#1 18. 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.

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.^[30]

Command 1 — GENERAL AUTHENTICATE (first chain)

An ECDH key agreement scheme does not send an encrypted symmetric key to the participating entities. Instead, the two entities involved in the key agreement scheme compute a shared secret by combining their ECC private key(s) with the other party’s public key(s). The resulting shared secret (Z) serves as an input to a key derivation function (KDF), which each entity independently invokes to derive a common secret key. The secret key MAY be used as a session key or to encrypt a session key.

The PIV Card supports ECDH key agreement by performing the elliptic curve cryptography cofactor Diffie-Hellman (ECC CDH) primitive (SP 80-56A, Section 5.7.1.2 13) using its ECC KMK private key and an ECC public key that is provided as input to the GENERAL AUTHENTICATE command. All other procedures required to complete key agreement are performed by the cardholder’s client application and its associated cryptographic module.

The sequence of commands to perform the ECC CDH primitive from SP 800-56A, Section 5.7.1.2 13, with the private ECC KMK is illustrated below for ECC: Curve P-256.

SP 800-56A describes five different ECDH key agreement schemes that a client application cryptographic module MAY implement. These schemes differ in the number of keys (i.e., 1 or 2) and the type of keys (i.e., ephemeral or static) used by each party. Since the PIV Card only computes the ECC CDH primitive using its static private key, the client application cryptographic module only employs the PIV Card to implement an ECDH key agreement scheme when the scheme involves the use of the cardholder’s static key pair. The ECDH key agreement schemes that involve the use of at least one party’s static key pair and, thus, MAY involve the use of the PIV Card are:

• C(2e, 2s) — Each party has a static key pair and generates an ephemeral key pair per SP 800-56A, Section 6.1.1 13.
  In this scheme, the information sent between the client application and the PIV Card is the same when acting as the initiator or the responder. The other party’s static public key is sent to the PIV Card, and a static shared secret is returned by the PIV Card in plaintext. Note that an ephemeral key pair is generated by the client application, and the private key of that key pair is combined with the other party’s ephemeral public key to produce an ephemeral shared secret.

• C(1e, 2s) — The initiator has a static key pair and generates an ephemeral key pair, while the responder has a static key pair SP 800-56A, Section 6.2.1 13.
  When the cardholder is acting as the initiator, the other party’s static public key is sent to the PIV Card, and a static shared secret is returned in plaintext by the PIV Card. Note that, in this case, an ephemeral key pair is generated by the client application’s cryptographic module, and the corresponding ephemeral private key is combined with the other party’s static public key to produce a second shared secret.

  When the cardholder is acting as the responder, two public keys are sent by the client application to the PIV Card (i.e., the other party’s static and ephemeral public keys), and two shared secrets are returned in plaintext (i.e., the static shared secret and the ephemeral shared secret). Note that two GENERAL AUTHENTICATE commands are required to provide the two shared secrets to the client application’s cryptographic module.

• C(1e, 1s) — The initiator only generates an ephemeral key pair, while the responder only has a static key pair per SP 800-56A, Section 6.2.2 13.
  *In this scheme, the PIV Card is only employed by the client application if the cardholder is acting as the responder. In this case, the other party’s ephemeral public key is sent to the PIV Card, and the shared secret is returned by the PIV Card in plaintext.

• C(0e, 2s) — Both the initiator and responder use only static key pairs per SP 800-56A, Section 6.3 13.
  In the C(0e, 2s) scheme, the information sent between the client application’s cryptographic module, and the PIV Card is the same when acting as the initiator or the responder. The other party’s static public key is sent to the PIV Card, and the static shared secret is returned in plaintext. Note that, for this scheme, the client application’s cryptographic module also generates a nonce when acting as the initiator of the scheme.

The C(2e, 0s) scheme does not involve the use of static keys, so the PIV Card would not be involved in the implementation of this scheme.

If the PIV Card supports the virtual contact interface, then all non-card management operations of the PIV Card Application MAY be performed over the contactless interface. In order to perform an operation that would otherwise be restricted to the contact interface, the key establishment protocol in Section 4.1 needs to be performed to establish session keys for secure messaging, and the pairing code needs to be submitted over secure messaging in order to establish a virtual contact interface.^[31]

This appendix shows an example of the establishment of a VCI and its use to perform cardholder authentication using the PIV Authentication key. First, the GENERAL AUTHENTICATE command is used to perform the key establishment protocol. The VERIFY command is then used to submit the pairing code and establish the VCI. At that point, the GET DATA command is used to read the X.509 Certificate for PIV Authentication. The GENERAL AUTHENTICATE command is used to perform a challenge/response with the PIV Authentication key after the PIN is submitted using the VERIFY command.

Phase 1: Key Establishment

After the client application verifies $C_{ICC}$, the authentication cryptogram, and the certificate(s) needed to verify the signature on $C_{ICC}$, the PIV Card is authenticated and session keys $SK_{ENC}$, $SK_{MAC}$, and $SK_{RMAC}$ are established.

Phase 2: Pairing Code Submission

The VERIFY command is used to submit the pairing code (“65135275”) to the PIV Card Application. For the command,

Phase 3: Certificate Retrieval

Once the VCI has been established, the GET DATA command MAY be used to retrieve the X.509 Certificate for PIV Authentication. For the command,

Phase 4: PIN Retry Counter Check

At this point the PIV Card Application PIN could be submitted directly, but for illustration a VERIFY command is first sent without a data field to retrieve the current retry counter value.

Phase 5: PIN Submission

The VERIFY command is used to submit the PIV Card Application PIN to the PIV Card Application. Other than the key reference and the PIN value, the command and response are the same as when using the VERIFY command to submit the pairing code. For the command,

Note: the encryption counter was incremented by the previous VERIFY command even though no encryption was performed.

Phase 6: Challenge/Response Authentication

With the VCI established and PIN verified, privileged operations MAY now be performed over the contactless interface.

The challenge is 7C 82 01 06 82 00 81 82 01 00 00 01 FF FF … BC A7 from Section A.3.

The response is 7C 82 01 04 82 82 01 00 29 69 44 3B … E2 F1 2E from Section A.3.

PIV Cards that implement VCI or OCC use the key establishment protocol described Section 4.1 to establish a secure messaging key and subsequently protect communication between the PIV Card and the host. During the key establishment protocol, the PIV Card and the Cardholder are authenticated. Departments and agencies CAN use these authentication steps as a stand-alone authentication mechanism known as SM-AUTH.

The SM-AUTH authentication mechanism is performed with the GENERAL AUTHENTICATE command as follows:

After the client application verifies $C_{ICC}$, the authentication cryptogram, and the certificate(s) needed to verify the signature on $C_{ICC}$, the PIV Card is authenticated and session keys $SK_{ENC}$, $SK_{MAC}$, and $SK_{RMAC}$ are established. The session keys are then zeroized since they are not used^[32] in subsequent communication.