NIST PIV and digital identity SP 800-73-5
All1 Introduction2 Overview: Concepts and Constructs3 PIV Card Application Card Command Interface4 Secure Messaging5 04 03 02 8 2 00 00'
| Ref | Title | Text | |
|---|---|---|---|
| 1 | Introduction | 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 facilitie | changed here |
| 1.1 in 1 |
Purpose | 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 retrie | changed here |
| 1.2 in 1 |
Scope | 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- | changed here |
| 1.3 in 1 |
Audience 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 | changed here |
| 1.4 in 1 |
Content 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 assum | changed here |
| 2 | Overview: 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 Ve | changed here |
| 2.1 in 2 |
Platform 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 | changed here |
| 2.2 in 2 |
Namespaces of the PIV Card Application | 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 | changed here |
| 2.3 in 2 |
Card 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 | changed here |
| 2.3.1 in 2.3 |
Default 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 | changed here |
| 2.4 in 2 |
Security 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 comma | changed here |
| 2.4.1 in 2.4 |
Access 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 | changed here |
| 2.4.2 in 2.4 |
Security 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 | changed here |
| 2.4.3 in 2.4 |
Authentication 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 | changed here |
| 2.5 in 2 |
Current 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 . Table 1. State of the PIV Card Application State Name Always Defined Comment Loca | changed here |
| 3 | PIV 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. All PIV Card Application card commands SHALL be supported by a PIV Card Application. Card c | changed here |
| 3.1 in 3 |
PIV Card Application Card Commands for Data Access | ||
| 3.1.1 in 3.1 |
SELECT 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, Sec. 2.2) in the data field of the SELECT command. There SHALL be at most one | changed here |
| 3.1.2 in 3.1 |
GET 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 5 The GET RESPONSE command is used in conjunction with GET DATA to read larger PIV data objects. The GET RESPONSE comman | changed here |
| 3.2 in 3 |
PIV Card Application Card Commands for Authentication | ||
| 3.2.1 in 3.2 |
VERIFY 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., loc | changed here |
| 3.2.1.1 in 3.2.1 |
PIV 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 Sec. 2.4.3 , then the card command SHALL fail, and the PIV Card Application SHALL return either the status word '6A | changed here |
| 3.2.1.2 in 3.2.1 |
On-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 SH | changed here |
| 3.2.1.3 in 3.2.1 |
Pairing 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 | changed here |
| 3.2.2 in 3.2 |
CHANGE 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 s | changed here |
| 3.2.3 in 3.2 |
RESET 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 | changed here |
| 3.2.4 in 3.2 |
GENERAL 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 dat | changed here |
| 3.3 in 3 |
PIV Card Application Card Commands for Credential Initialization and Administration | changed here | |
| 3.3.1 in 3.3 |
PUT 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. Command Syntax CLA '00' or '10' indicating command chaining INS 'DB' P1 '3F' P2 'FF' Lc Length of data fie | changed here |
| 3.3.2 in 3.3 |
GENERATE 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 t | changed here |
| 4 | Secure 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 proto | changed here |
| 4.1 in 4 |
Key Establishment Protocol | 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 | changed here |
| 4.1.1 in 4.1 |
Client Application Steps | Table 15: Protocol Steps for Client Application Step # Description Comment H1 Set CBH to 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 | changed here |
| 4.1.2 in 4.1 |
PIV Card Application Protocol Steps | Table 16: Protocol Steps for PIV Card Application Step # Description Comment C1 IDsICC = T8(SHA256(CICC)) IDsICC — the leftmost 8 bytes of the SHA-256 hash of CICC — is used as an input for session key derivation. (Note that IDsICC is stat | changed here |
| 4.1.3 in 4.1 |
Notations | Table 17: Notations used in Protocol Description Name Comment Format Size (in bytes) ICC Integrated Circuit Card (PIV Card) N/A N/A IDsICC Static, non-anonymous PIV Card identifier, which is the truncated hash of CICC Binary 8 bytes GUID | changed here |
| 4.1.4 in 4.1 |
Cipher Suite | 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 Applic | changed here |
| 4.1.5 in 4.1 |
Card Verifiable Certificates | Table 15 specifies the format for the secure messaging CVC, CICC. Table 20 specifies the format for the optional Intermediate CVC. CICC is used to authenticate the PIV Card Application. The specific data object tags and specified order mus | changed here |
| 4.1.6 in 4.1 |
Key Derivation | 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 leng | changed here |
| 4.1.7 in 4.1 |
Key Confirmation | Key confirmation SHALL be performed in Steps C9 and H12 of the protocol by the generation of AuthCryptogramICC in accordance with Sections 5.9.1.1 and 6.2.2.3 of [SP800-56A ]. AuthCryptogramICC SHALL be computed as CMAC( MacKey , MacLen , M | changed here |
| 4.1.8 in 4.1 |
Command Interface | The following command interface SHALL be used for the key establishment protocol. Command Syntax CLA '00' INS '87' P1 Algorithm reference ('27' or '2E'), as specified in the 0xAC tag of the application property template P2 '04' (PIV Secure | changed here |
| 4.2 in 4 |
Secure 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 | changed here |
| 4.2.1 in 4.2 |
Secure Messaging Data Objects | The command and response messages SHALL be BER-TLV encoded according to Table 21 . Table 21. Secure messaging data objects Tag Description '87' Padding content indicator byte followed by the encrypted data '8E' Cryptographic checksum (MAC | changed here |
| 4.2.2 in 4.2 |
Command and Response Data Confidentiality | Under secure messaging, the PIV data is encrypted using AES in Cipher Block Chaining (CBC) mode with the SKENC session key, where SKENC is a 128-bit key for CS2 and a 256-bit key for CS7, as per Table 18 . The encryption and encoding proces | changed here |
| 4.2.3 in 4.2 |
Command Integrity | 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 SKMAC session key. If fragmentation is required for data transmission, the command SHALL be c | changed here |
| 4.2.4 in 4.2 |
Command 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; 21 21 The data field may be absent in the case of the VERIFY command. • The 3-btye | changed here |
| 4.2.5 in 4.2 |
Response Integrity | 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 SKRMAC session key. An R-MAC SHALL be generated for each response that corresponds to a command that was s | changed here |
| 4.2.6 in 4.2 |
Response 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-encode | changed here |
| 4.2.7 in 4.2 |
Error 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'. Otherw | changed here |
| 4.3 in 4 |
Session 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, 25 25 An error has occ | changed here |
| 05 | 04 03 02 8 2 00 00' | The client application returns the decrypted witness ( ' 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10’), which references algorithm '08' and key reference '9B'. The client application requests the encryption of challenge data ('09 0A 0B | changed here |
50 of 50.