1 The value of the GUID data element of the CHUID data object shall be a 16-byte binary
All changes in this version
Title
The value of the GUID data element of the CHUID data object shall be a 16-byte binary
Control
representation of a valid UUID [RFC4122] . The UUID shall be version 1, 4, or 5, as specified in [RFC4122 , Section 4.1.3].
2. The same 16-byte binary representation of the UUID value shall be present as the value of an entryUUID attribute, as defined in [RFC4530] , in any CMS-signed data object that is required to contain a pivFASC-N attribute on a PIV Card, i.e., in the mandatory cardholder fingerprint template and facial image data objects as well as in the optional cardholder iris images data object when present.
3. If the PIV Card supports secure messaging, then the same 16-byte binary representation of the UUID value shall be used as the Subject Identifier in the secure messaging CVC, as specified in Part 2, Section 4.1.5.
4. The string representation of the same UUID value shall be present in the X.509 Certificate for PIV Authentication and the X.509 Certificate for Card Authentication, in the subjectAltName extension encoded as a URI, as specified by [RFC4122 , Section 3].
10 A valid PIV Card is defined as a PIV Card that is neither expired nor revoked. 3.4.2 Cardholder UUID
As defined in Section 3.1.2 , the CHUID may optionally include a Cardholder UUID. When present, the Cardholder UUID shall be a 16-byte binary representation of a valid UUID, and it shall be version 1, 4, or 5, as specified in [RFC4122 , Section 4.1.3].
3.5 Data Object Containers and associated Access Rules and Interface Modes
Table 2 defines a high level view of the data model. Each on-card storage container is labeled either as Mandatory (M), Optional (O), or Conditional (C). The conditional data objects are the digital signature key and the key management key, which are mandatory if the cardholder has a government- issued email account at the time of credential issuance. This data model is designed to enable and support dual interface cards. For dual chip implementations, for any container that can be accessed over both the contact interface and the contactless interface (including the virtual contact interface) the data object shall be copied into the corresponding containers on both chips. 11
Table 2. Data Model Containers
Container Name Container ID Access Rule for Read M/O/ C Contact Contactless 12 Card Capability Container 0xDB00 Always VCI M Card Holder Unique Identifier 0x3000 Always Always M X.509 Certificate for PIV Authentication 0x0101 Always VCI M Cardholder Fingerprints 0x6010 PIN VCI and PIN M Security Object 0x9000 Always VCI M Cardholder Facial Image 0x6030 PIN VCI and PIN M X.509 Certificate for Card Authentication 0x0500 Always Always M X.509 Certificate for Digital Signature 0x0100 Always VCI C X.509 Certificate for Key Management 0x0102 Always VCI C Printed Information 0x3001 PIN or OCC VCI and (PIN or OCC) O Discovery Object 0x6050 Always Always O Key History Object 0x6060 Always VCI O Retired X.509 Certificate for Key Management 1 0x1001 Always VCI O Retired X.509 Certificate for Key Management 2 0x1002 Always VCI O Retired X.509 Certificate for Key Management 3 0x1003 Always VCI O Retired X.509 Certificate for Key Management 4 0x1004 Always VCI O Retired X.509 Certificate for Key Management 5 0x1005 Always VCI O Retired X.509 Certificate for Key Management 6 0x1006 Always VCI O Retired X.509 Certificate for Key Management 7 0x1007 Always VCI O
11 As a consequence of this requirement, any keys that have to be generated on card cannot be made available over the contactless interface (including the virtual contact interface) in a dual chip implementation. In addition, the asymmetric CAK needs to be generated off-card and loaded onto both chips for dual chip implementations. 12 The term virtual contact interface (VCI) is used in this document as a shorthand for the following security condition: (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)) Container Name Container ID Access Rule for Read M/O/ C Contact Contactless 12 Retired X.509 Certificate for Key Management 8 0x1008 Always VCI O Retired X.509 Certificate for Key Management 9 0x1009 Always VCI O Retired X.509 Certificate for Key Management 10 0x100A Always VCI O Retired X.509 Certificate for Key Management 11 0x100B Always VCI O Retired X.509 Certificate for Key Management 12 0x100C Always VCI O Retired X.509 Certificate for Key Management 13 0x100D Always VCI O Retired X.509 Certificate for Key Management 14 0x100E Always VCI O Retired X.509 Certificate for Key Management 15 0x100F Always VCI O Retired X.509 Certificate for Key Management 16 0x1010 Always VCI O Retired X.509 Certificate for Key Management 17 0x1011 Always VCI O Retired X.509 Certificate for Key Management 18 0x1012 Always VCI O Retired X.509 Certificate for Key Management 19 0x1013 Always VCI O Retired X.509 Certificate for Key Management 20 0x1014 Always VCI O Cardholder Iris Images 0x1015 PIN VCI and PIN O Biometric Information Templates Group Template 0x1016 Always Always O Secure Messaging Certificate Signer 0x1017 Always Always O Pairing Code Reference Data Container 0x1018 PIN or OCC VCI and (PIN or OCC) O
Appendix A provides a detailed spreadsheet for the data model. ContainerIDs and tags within the containers for each data object are defined by this data model in accordance with SP 800-73-4 naming conventions. 4. PIV Data Objects Representation
4.1 Data Objects Definition
A data object is an item of information seen on the card command interface for which is specified a name, a description of logical content, a format, and a coding. Each data object has a globally unique name called its object identifier (OID) , as defined in ISO/IEC 8824-2:2002 [ISO8824] .
A data object whose data content is encoded as a BER-TLV data structure as in ISO/IEC 8825-1:2002 [ISO8825] is called a BER-TLV data object.
4.1.1 Data Object Content
The content of a data object is the sequence of bytes that are said to be contained in or to be the value of the data object. The number of bytes in this byte sequence is referred to as the length of the data content and also as the size of the data object. The first byte in the sequence is regarded as being at byte position or offset zero in the content of the data object.
The data content of a BER-TLV data object may consist of other BER-TLV data objects. In this case the tag of the data object indicates that the data object is a constructed data object. A BER-TLV data object that is not a constructed data object is called a primitive data object.
The PIV data objects are BER-TLV objects encoded as per [ISO8825] , except that tag values of the PIV data object’s inner tag assignments do not conform to BER-TLV requirements. 13 This is due to the need to accommodate legacy tags inherited from [GSC-IS] .
Before the card is issued, data objects that are created but not used shall be set to zero-length value.
4.2 OIDs and Tags of PIV Card Application Data Objects
Table 3 lists the ASN.1 object identifiers and BER-TLV tags of the thirty-six PIV Card Application data objects. For the purpose of constructing PIV Card Application data object names in the CardApplicationURL in the CCC of the PIV Card Application, the NIST RID ('A0 00 00 03 08') shall be used and the card application type shall be set to '00'.
4.3 Object Identifiers
Each of the data objects in the PIV Card Application has been provided with a BER-TLV tag and an ASN.1 OID from the NIST personal identity verification arc. These object identifier assignments are given in Table 3 .
A data object shall be identified on the PIV client-application programming interface using its OID. An object identifier on the PIV client-application programming interface shall be a dot-delimited string of the integer components of the OID. For example, the representation of the OID of the CHUID on the PIV client-application programming interface is “2.16.840.1.101.3.7.2.48.0.”
13 The exception does not apply to the BIT Group Template, the Discovery Object or the Application Property Template (APT), since these objects use interindustry tags from ISO/IEC 7816-6. A data object shall be identified on the PIV Card Application card command interface using its BER- TLV tag. For example, the CHUID is identified on the card command interface to the PIV Card Application by the three-byte identifier '5FC102'.
Table 2 lists the ACRs of the thirty-six PIV Card Application data objects.
Table 3. Object Identifiers of the PIV Data Objects for Interoperable Use
Data Object for Interoperable Use ASN.1 OID BER-TLV Tag M/O/ C Card Capability Container 2.16.840.1.101.3.7.1.219.0 '5FC107' M Card Holder Unique Identifier 2.16.840.1.101.3.7.2.48.0 '5FC102' M X.509 Certificate for PIV Authentication 2.16.840.1.101.3.7.2.1.1 '5FC105' M Cardholder Fingerprints 2.16.840.1.101.3.7.2.96.16 '5FC103' M Security Object 2.16.840.1.101.3.7.2.144.0 '5FC106' M Cardholder Facial Image 2.16.840.1.101.3.7.2.96.48 '5FC108' M X.509 Certificate for Card Authentication 2.16.840.1.101.3.7.2.5.0 '5FC101' M X.509 Certificate for Digital Signature 2.16.840.1.101.3.7.2.1.0 '5FC10A' C X.509 Certificate for Key Management 2.16.840.1.101.3.7.2.1.2 '5FC10B' C Printed Information 2.16.840.1.101.3.7.2.48.1 '5FC109' O Discovery Object 2.16.840.1.101.3.7.2.96.80 '7E' O Key History Object 2.16.840.1.101.3.7.2.96.96 '5FC10C' O Retired X.509 Certificate for Key Management 1 2.16.840.1.101.3.7.2.16.1 '5FC10D' O Retired X.509 Certificate for Key Management 2 2.16.840.1.101.3.7.2.16.2 '5FC10E' O Retired X.509 Certificate for Key Management 3 2.16.840.1.101.3.7.2.16.3 '5FC10F' O Retired X.509 Certificate for Key Management 4 2.16.840.1.101.3.7.2.16.4 '5FC110' O Retired X.509 Certificate for Key Management 5 2.16.840.1.101.3.7.2.16.5 '5FC111' O Retired X.509 Certificate for Key Management 6 2.16.840.1.101.3.7.2.16.6 '5FC112' O Retired X.509 Certificate for Key Management 7 2.16.840.1.101.3.7.2.16.7 '5FC113' O Retired X.509 Certificate for Key Management 8 2.16.840.1.101.3.7.2.16.8 '5FC114' O Retired X.509 Certificate for Key Management 9 2.16.840.1.101.3.7.2.16.9 '5FC115' O Retired X.509 Certificate for Key Management 10 2.16.840.1.101.3.7.2.16.10 '5FC116' O Retired X.509 Certificate for Key Management 11 2.16.840.1.101.3.7.2.16.11 '5FC117' O Retired X.509 Certificate for Key Management 12 2.16.840.1.101.3.7.2.16.12 '5FC118' O Retired X.509 Certificate for Key Management 13 2.16.840.1.101.3.7.2.16.13 '5FC119' O Retired X.509 Certificate for Key Management 14 2.16.840.1.101.3.7.2.16.14 '5FC11A' O Retired X.509 Certificate for Key Management 15 2.16.840.1.101.3.7.2.16.15 '5FC11B' O Retired X.509 Certificate for Key Management 16 2.16.840.1.101.3.7.2.16.16 '5FC11C' O Retired X.509 Certificate for Key Management 17 2.16.840.1.101.3.7.2.16.17 '5FC11D' O Retired X.509 Certificate for Key Management 18 2.16.840.1.101.3.7.2.16.18 '5FC11E' O Retired X.509 Certificate for Key Management 19 2.16.840.1.101.3.7.2.16.19 '5FC11F' O Retired X.509 Certificate for Key Management 20 2.16.840.1.101.3.7.2.16.20 '5FC120' O Cardholder Iris Images 2.16.840.1.101.3.7.2.16.21 '5FC121' O Biometric Information Templates Group Template 2.16.840.1.101.3.7.2.16.22 '7F61' O Secure Messaging Certificate Signer 2.16.840.1.101.3.7.2.16.23 '5FC122' O Pairing Code Reference Data Container 2.16.840.1.101.3.7.2.16.24 '5FC123' O 5. Data Types and Their Representation
This section provides a description of the data types used in the PIV Client Application Programming Interface (SP 800-73-4, Part 3) and PIV Card Command Interface (SP 800-73-4, Part 2). Unless otherwise indicated, the representation shall be the same on both interfaces.
The data types are defined in Part 1, rather than in Parts 2 and 3 in order to achieve smart card platform independence from Part 1. Thus, non-government smart card programs can readily adopt the interface specifications in Parts 2 and 3 while customizing Part 1 to their own data model, data types, and namespaces. 14
5.1 Key References
A key reference is a one-byte reference data identifier that specifies a cryptographic key or PIN according to its PIV Key Type. Tables 4a and 4b and SP 800-78, Table 6-1, define the key reference values that shall be used on the PIV interfaces. The key reference values are used, for example, in a cryptographic protocol such as an authentication or a signing protocol. Key references are only assigned to private and secret (symmetric) keys, PINs, PIN Unblocking Key (PUK), OCC, and the pairing code. All other PIV Card Application key reference values are reserved for future use.
Table 4a. PIV Card Application Authentication Data References
Key Reference Value PIV Reference Data Type Authenticable Entity Security Condition for Use Retry Reset Value Number of Unblocks Contact Contactless
'00' Global PIN Cardholder Always VCI Platform Specific Platform Specific
'80' PIV Card Application PIN Cardholder Always VCI Issuer Specific Issuer Specific
'81' PIN Unblocking Key PIV Card Application Administrator Always Never Issuer Specific Issuer Specific
'96' Primary Finger OCC Cardholder Always SM Issuer Specific Issuer Specific
'97' Secondary Finger OCC Cardholder Always SM Issuer Specific Issuer Specific
'98' Pairing Code Cardholder Always 15 SM Issuer Specific Issuer Specific
14 A customized Part 1 data model exists in the PIV-Interoperable card (PIV-I card) specification as defined in [PIV-I NFI] and further clarified in [PIV-I FAQ] . The intent of [PIV-I NFI] is to enable issuers to issue cards that are technically interoperable with Federal PIV Card readers and their applications, and that may be trusted for particular purposes at the discretion of the relying Federal departments and agencies. PIV-I cards use the same namespace and data types as PIV Cards, however, the data model is slightly different since some of the ASN.1 OIDs that appear in PIV certificates are specific to PIV Cards and since non-Federal issuers do not have Agency Codes assigned to them, which means that they are unable to create unique FASC-N identifiers for the cards they issue. As a result, [PIV-I FAQ] requires the first 14 digits of the FASC-Ns for PIV-I cards (the Agency Code, System Code, and Credential Number) to be populated with all nines. 15 The sole use of the pairing code is the establishment of a VCI. Its use over the contact interface serves no purpose. Table 4b. PIV Card Application Key References
Key Reference Value (i.e., Key ID) PIV Key Type Administrator Security Condition for Use
Contact Contactless
'04' PIV Secure Messaging Key PIV Card Application Administrator Always Always
'9A' PIV Authentication Key PIV Card Application Administrator PIN or OCC VCI and (PIN or OCC)
'9B' PIV Card Application Administration Key PIV Card Application Administrator Always Never
'9C' Digital Signature Key PIV Card Application Administrator PIN Always or OCC Always VCI and (PIN Always or OCC Always)
'9D' Key Management Key PIV Card Application Administrator PIN or OCC VCI and (PIN or OCC)
'9E' Card Authentication Key 16 PIV Card Application Administrator Always Always
'82', '83', '84', '85', '86', '87', '88', '89', '8A', '8B', '8C', '8D', '8E', '8F', '90', '91', '92', '93', '94', '95' Retired Key Management Key PIV Card Application Administrator PIN or OCC VCI and (PIN or OCC)
Secure Messaging (SM) is defined in Section 5.4 and VCI is defined in Section 5.5 . Table 2 of Part 2 specifies the security conditions for each command.
When represented as a byte, the key reference occupies bits b8 and b5-b1, while b7 and b6 shall be set to 0. If b8 is 0 then the key reference names global reference data. If b8 is 1, then the key reference names application-specific reference data.
The access control rules for PIV data object access shall reference the PIV Card Application PIN and may optionally reference the cardholder Global PIN or OCC data. If the Global PIN is used by the PIV Card Application then the Global PIN format shall follow the PIV Card Application PIN format defined in Section 2.4.3 of Part 2.
PIV Card Applications with the Discovery Object and Bit 6 of the first byte of the PIN Usage Policy value set to one, as per Section 3.3.2 , shall reference the PIV Card Application PIN as well as the cardholder Global PIN in the access control rules for PIV data object access. Additionally, the PIV
16 A card may optionally have a symmetric CAK in addition to the mandatory asymmetric CAK, in which case both keys would share the same key reference and access control rules. Card Application card commands can change the status of the Global PIN, and may change its reference data while the PIV Card Application is the currently selected application.
Note: The rest of the document uses “PIN” to mean either the PIV Card Application PIN or the Global PIN.
5.1.1 OCC Data
This document does not specify how the biometric reference data and comparison parameters are stored internally on the card. Moreover, the export of the biometric reference data shall not be allowed. Configuration data related to the biometric reference data may be read from the tag 0x7F61 BIT Group Template data object (see Section 3.3.6 ). Configuration data is defined in Table 7 of [SP800-76] .
5.1.2 PIV Secure Messaging Key
If the PIV Card supports secure messaging, the PIV Secure Messaging key shall be generated on the PIV Card and the PIV Card shall not permit exportation of the PIV Secure Messaging key. The cryptographic operations that use the PIV Secure Messaging key shall be available through the contact and contactless interfaces of the PIV Card. The PKI cryptographic function (see Table 4b ) is under an “Always” access rule, and thus private key operations (i.e., use of the key to establish session keys for secure messaging) can be performed without access control restrictions.
The PIV Card shall store a corresponding secure messaging CVC to support validation of the public key by the relying party. The format for the secure messaging CVC shall be as specified in Part 2, Section 4.1.5. The public key required to verify the digital signature of the secure messaging CVC shall be provided in a certificate in the Secure Messaging Certificate Signer data object, as specified in Section 3.3.7 .
5.1.3 Pairing Code
If the PIV Card supports the virtual contact interface, then it shall implement support for the pairing code. If implemented, the pairing code shall consist of eight decimal digits and it shall be generated at random by the PIV Card Issuer. The results of each random pairing code generation shall be loaded onto at most one PIV Card and cannot be changed by the cardholder. The pairing code value for a PIV Card shall be stored in the Pairing Code Reference Data Container (see Section 3.3.8 ) on the card and may be printed on the back of the card in an agency-specific text area (Zones 9B or 10B). PIV Card Issuers may choose to provide the pairing code value to the cardholder in another manner, such as printing it on a slip of paper, rather than printing it on the back of the card. 17
Unlike the PIV Card Application PIN or the Global PIN, there are no restrictions on the caching of the pairing code by client applications. It is recommended that a client application that needs to communicate with a PIV Card over its virtual contact interface obtain the card’s pairing code during a registration step, either by asking the cardholder to enter the value or by reading it from the card over the contact interface from the Pairing Code Reference Data Container, and then cache the pairing
17 While printing the value of the pairing code on the back of the card provides maximum convenience for use by the cardholder and avoids any risk that the cardholder will forget the pairing code, it may create a risk that an attacker could obtain the value of the pairing code by surreptitiously reading it from the back of the card. Departments and agencies will need to make a risk-based decision in determining the method by which they provide cardholders with the values of their pairing codes. code until the card expires. 18 The client application may then connect to the card and establish a virtual contact interface with it whenever the card is within read-range of the client application’s contactless card reader without needing to prompt the cardholder.
5.2 PIV Algorithm Identifier
A PIV algorithm identifier is a one-byte identifier of a cryptographic algorithm. The identifier specifies a cryptographic algorithm and key size. For symmetric cryptographic operations, the algorithm identifier also specifies a mode of operation (i.e., ECB). SP 800-78, Table 6-2 lists the PIV algorithm identifiers for the cryptographic algorithms that may be recognized on the PIV interfaces.
5.3 Cryptographic Mechanism Identifiers
Cryptographic mechanism identifiers are defined in Table 5 . These identifiers serve as inputs to the GENERATE ASYMMETRIC KEY PAIR card command and the Part 3 pivGenerateKeyPair() client API function call, which initiates the generation and storage of the asymmetric key pair.
Table 5. Cryptographic Mechanism Identifiers
Cryptographic Mechanism Identifier Description Parameter
'07' RSA 2048 Optional public exponent encoded big-endian '11' ECC: Curve P-256 None '14' ECC: Curve P-384 None
All other cryptographic mechanism identifier values are reserved for future use.
5.4 Secure Messaging
A PIV Card Application may optionally support secure messaging (SM). When secure messaging is established, the PIV Card Application is authenticated to the relying system and a set of symmetric session keys are established, which are used to provide confidentiality and integrity protection for the card commands that are sent to the card using secure messaging as well as for the responses from the PIV Card.
If implemented, SM for non-card-management operations shall only be established using the PIV Secure Messaging key specified in Table 4b and the SM protocol in accordance with the specifications in Section 4 of Part 2.
5.5 Virtual Contact Interface
The term virtual contact interface (VCI) is used in this document as shorthand for a security condition. As described in access control rules in this document and in Part 2, all non-card- management operations that are allowed over contact interface may be carried out over the contactless interface if the VCI security condition is satisfied. Support for the VCI is optional.
18 As noted in Section 5.5 , the pairing code does not need to be submitted if the Bit 3 of the first byte of the PIN Usage The VCI security condition supports two different configurations for the establishment of the VCI. In the default (and recommended) configuration, the VCI is only established after both secure messaging has been established and the pairing code has been presented to the card using secure messaging. In the non-default configuration, the VCI is established by the establishment of secure messaging, without any further steps.
The VCI security condition is
(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))
PIV Card Applications that support the VCI shall support the configuration in which Bit 3 of the first byte of the PIN Usage Policy is set to zero (i.e., the configuration in which submission of the pairing code to the PIV Card Application is required to establish the VCI) and may additionally support the configuration in which Bit 3 of the first byte of the PIN Usage Policy is set to one. Card management systems (CMS) shall be configured to set Bit 3 of the first byte of the PIN Usage Policy to zero by default whenever the Discovery Object is present.
Requiring that the pairing code be submitted to the PIV Card Application in order to establish the VCI protects the previously contact-restricted X.509 certificates from skimming 19 and also protects PIN-based card activation from being blocked. While it is recommended that the default configuration of CMSs remain unchanged, the configuration of a CMS may be changed to set Bit 3 of the first byte of the PIN Usage Policy to one (i.e., to configure PIV Cards to establish VCIs without the submission of a pairing code) if the configuration change is approved by the Designated Approving Authority (DAA) and if compensating controls are implemented to ensure personally identifiable information (i.e., name, email address, and organization) cannot be skimmed from the PIV Card when in close proximity when the card is outside of its protective sleeve.
A DAA’s decision to approve the issuance of PIV Cards that implement the VCI without requiring the pairing code shall be based on a risk assessment that weighs the perceived benefit against the risk of unauthorized disclosure of cardholder data exposing previously contact-restricted X.509 certificates to skimming. The previously contact-restricted X.509 certificates include information about the cardholder such as name and email address. Compensating controls shall be captured in the appropriate system security plan. 20 Systems that accept external issued PIV Cards shall be able to accept PIV Cards with either VCI configuration.
5.6 Status Words
A Status Word (SW) is a 2-byte value returned by a card command at the card edge. The first byte of a status word is referred to as SW1 and the second byte of a status word is referred to as SW2.
Recognized values of all SW1-SW2 pairs used as return values on the card command interface and their interpretation are given in Table 6 . The descriptions of individual card commands provide additional information for interpreting returned status words.
19 Skimming is when data is surreptitiously obtained from a contactless card, using a hidden reader that powers, commands, and reads from the card within the maximum read distance (reported as about 25 cm with ISO/IEC 14443 smart cards like the PIV Card). 20 See SP 800-18 Rev1, Guide for Developing Security Plans for Federal Information Systems. Table 6. Status Words
'61' 'xx' Successful execution where SW2 encodes the number of response data bytes still available '63' '00' Verification failed '63' 'CX' Verification failed, X indicates the number of further allowed retries or resets '68' '82' Secure messaging not supported '69' '82' Security status not satisfied '69' '83' Authentication method blocked '69' '87' Expected secure messaging data objects are missing '69' '88' Secure messaging data objects are incorrect '6A' '80' Incorrect parameter in command data field '6A' '81' Function not supported '6A' '82' Data object or application not found '6A' '84' Not enough memory '6A' '86' Incorrect parameter in P1 or P2 '6A' '88' Referenced data or reference data not found Appendix A–– PIV Data Model
The PIV data model number is 0x10, and the data model version number is 0x01.
The SP 800-73-4 specification does not provide mechanisms to read partial contents of a PIV data object. Individual access to the TLV elements within a container is not supported. For each container, compliant cards shall return all TLV elements of the container in the order listed in this appendix.
Both single-chip/dual-interface and dual-chip implementations are feasible. In the single-chip/dual- interface configuration, the PIV Card Application shall be provided the information regarding which interface is in use. In the dual-chip configuration, a separate PIV Card Application shall be loaded on each chip.
Table 7. PIV Data Containers
Container Description ContainerID BER-TLV Tag Container Minimum Capacity (Bytes) 21 Access Rule for Read M/O/ C Contact Contactless
Card Capability Container 0xDB00 '5FC107' 287 Always VCI M Card Holder Unique Identifier 0x3000 '5FC102' 2916 Always Always M X.509 Certificate for PIV Authentication (Key Reference '9A') 0x0101 '5FC105' 1905 Always VCI M
Cardholder Fingerprints 0x6010 '5FC103' 4006 PIN VCI and PIN M Security Object 0x9000 '5FC106' 1336 Always VCI M Cardholder Facial Image 0x6030 '5FC108' 12710 PIN VCI and PIN M X.509 Certificate for Card Authentication (Key Reference '9E') 0x0500 '5FC101' 1905 Always Always M
X.509 Certificate for Digital Signature (Key Reference '9C') 0x0100 '5FC10A' 1905 Always VCI C
X.509 Certificate for Key Management (Key Reference '9D') 0x0102 '5FC10B' 1905 Always VCI C
Printed Information 0x3001 '5FC109' 245 PIN or OCC VCI and (PIN or OCC) O
Discovery Object 0x6050 '7E' 19 Always Always O Key History Object 0x6060 '5FC10C' 128 Always VCI O Retired X.509 Certificate for Key Management 1 (Key reference '82') 0x1001 '5FC10D' 1905 Always VCI O
Retired X.509 Certificate for Key Management 2 (Key reference '83') 0x1002 '5FC10E' 1905 Always VCI O
21 The values in this column denote the guaranteed minimum capacities, in bytes, of the on-card storage containers. Cards with larger containers may be produced and determined conformant. Container Description ContainerID BER-TLV Tag Container Minimum Capacity (Bytes) 21 Access Rule for Read M/O/ C Contact Contactless
Retired X.509 Certificate for Key Management 3 (Key reference '84') 0x1003 '5FC10F' 1905 Always VCI O
Retired X.509 Certificate for Key Management 4 (Key reference '85') 0x1004 '5FC110' 1905 Always VCI O
Retired X.509 Certificate for Key Management 5 (Key reference '86') 0x1005 '5FC111' 1905 Always VCI O
Retired X.509 Certificate for Key Management 6 (Key reference '87') 0x1006 '5FC112' 1905 Always VCI O
Retired X.509 Certificate for Key Management 7(Key reference '88') 0x1007 '5FC113' 1905 Always VCI O
Retired X.509 Certificate for Key Management 8(Key reference '89') 0x1008 '5FC114' 1905 Always VCI O
Retired X.509 Certificate for Key Management 9 (Key reference '8A') 0x1009 '5FC115' 1905 Always VCI O
Retired X.509 Certificate for Key Management 10 (Key reference '8B') 0x100A '5FC116' 1905 Always VCI O
Retired X.509 Certificate for Key Management 11 (Key reference '8C') 0x100B '5FC117' 1905 Always VCI O
Retired X.509 Certificate for Key Management 12 (Key reference '8D') 0x100C '5FC118' 1905 Always VCI O
Retired X.509 Certificate for Key Management 13 (Key reference '8E') 0x100D '5FC119' 1905 Always VCI O
Retired X.509 Certificate for Key Management 14 (Key reference '8F') 0x100E '5FC11A' 1905 Always VCI O
Retired X.509 Certificate for Key Management 15 (Key reference '90') 0x100F '5FC11B' 1905 Always VCI O
Retired X.509 Certificate for Key Management 16 (Key reference '91') 0x1010 '5FC11C' 1905 Always VCI O
Retired X.509 Certificate for Key Management 17 (Key reference '92') 0x1011 '5FC11D' 1905 Always VCI O
Retired X.509 Certificate for Key Management 18 (Key reference '93') 0x1012 '5FC11E' 1905 Always VCI O Container Description ContainerID BER-TLV Tag Container Minimum Capacity (Bytes) 21 Access Rule for Read M/O/ C Contact Contactless
Retired X.509 Certificate for Key Management 19 (Key reference '94') 0x1013 '5FC11F' 1905 Always VCI O
Retired X.509 Certificate for Key Management 20 (Key reference '95') 0x1014 '5FC120' 1905 Always VCI O
Cardholder Iris Images 0x1015 '5FC121' 7106 PIN VCI and PIN O Biometric Information Templates Group Template 0x1016 '7F61' 65 Always Always O
Secure Messaging Certificate Signer 0x1017 '5FC122' 2471 Always Always O
Pairing Code Reference Data Container 0x1018 '5FC123' 12 PIN or OCC VCI and (PIN or OCC) O
Note that all data elements of th e following data objects are mandatory unless specified as optional or conditional.
Table 8. Card Capability Container
Card Capability Container 0xDB00 Data Element (TLV) Tag Type Max. Bytes Card Identifier 0xF0 Fixed 0 or 21 Capability Container version number 0xF1 Fixed 0 or 1 Capability Grammar version number 0xF2 Fixed 0 or 1 Applications CardURL 0xF3 Variable 128 PKCS#15 0xF4 Fixed 0 or 1 Registered Data Model number 0xF5 Fixed 1 Access Control Rule Table 0xF6 Fixed 0 or 17 Card APDUs 0xF7 Fixed 0 Redirection Tag 0xFA Fixed 0 Capability Tuples (CTs) 0xFB Fixed 0 Status Tuples (STs) 0xFC Fixed 0 Next CCC 0xFD Fixed 0 Extended Application CardURL (Optional) 0xE3 Fixed 48 Security Object Buffer (Optional) 0xB4 Fixed 48 Error Detection Code 0xFE LRC 0 Note: The optional Extended Application CardURL and Security Object Buffer data elements are deprecated and will be eliminated in a future version of SP 800-73. Table 9. Card Holder Unique Identifier
Card Holder Unique Identifier 0x3000 Data Element (TLV) Tag Type Max. Bytes Buffer Length (Optional) 0xEE Fixed 2 FASC-N 0x30 Fixed 25 Organizational Identifier (Optional) 0x32 Fixed 4 DUNS (Optional) 0x33 Fixed 9 GUID 0x34 Fixed 16 Expiration Date 0x35 Date (YYYYMMDD) 8 Cardholder UUID (Optional) 0x36 Fixed 16 Issuer Asymmetric Signature 0x3E Variable 2816 ** Error Detection Code 0xFE LRC 0
Note: The optional Buffer Length, Organizational Identifier and DUNS data elements are deprecated and will be eliminated in a future version of SP 800-73.
The Error Detection Code is the same element as the Longitudinal Redundancy Code (LRC) in [TIG SCEPACS] . Because TIG SCEPACS makes the LRC mandatory, it is present in the CHUID. However, this document makes no use of the Error Detection Code, and therefore the length of the TLV value is set to 0 bytes (i.e., no value will be supplied).
Table 10. X.509 Certificate for PIV Authentication
X.509 Certificate for PIV Authentication 0x0101 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 11. Cardholder Fingerprints
Cardholder Fingerprints 0x6010 Data Element (TLV) Tag Type Max. Bytes Fingerprint I & II 0xBC Variable 4000 **** Error Detection Code 0xFE LRC 0
** Recommended length: The signer certificate may cause the “Max. Bytes” value in the Issuer Asymmetric Signature field to be exceeded. **** Recommended length. The certificate that signed the Fingerprint I & II data element in the Cardholder Fingerprints data object can either be stored in the CHUID or in the Fingerprint I & II data element itself. If the latter, the “Max. Bytes” value quoted is a recommendation and the signer certificate in CBEFF_SIGNATURE_BLOCK can exceed the “Max. bytes.” Table 12. Security Object
Security Object 0x9000 Data Element (TLV) Tag Type Max. Bytes Mapping of DG to ContainerID 0xBA Variable 30 Security Object 0xBB Variable 1298 Error Detection Code 0xFE LRC 0
Table 13. Cardholder Facial Image
Cardholder Facial Image 0x6030 Data Element (TLV) Tag Type Max. Bytes Image for Visual Verification 0xBC Variable 12704 ***** Error Detection Code 0xFE LRC 0
Table 14. Printed Information
Printed Information 0x3001 Data Element (TLV) Tag Type Max. Bytes Name 0x01 Text (ASCII) 125 Employee Affiliation 0x02 Text (ASCII) 20 Expiration date 0x04 Date (YYYYMMMDD) 9 Agency Card Serial Number 0x05 Text (ASCII) 20 Issuer Identification 0x06 Fixed Text (ASCII) 15 Organization Affiliation (Line 1) (Optional) 0x07 Text (ASCII) 20 Organization Affiliation (Line 2) (Optional) 0x08 Text (ASCII) 20 Error Detection Code 0xFE LRC 0
In order to successfully match the printed information for verification on Zone 8F (Employee Affiliation) and Zone 10F (Agency, Department, or Organization) on the face of the card with the printed information stored electronically on the card, agencies should use tags 0x02, 0x07 and 0x08.
Table 15. X.509 Certificate for Digital Signature
X.509 Certificate for Digital Signature 0x0100 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
***** Recommended length. The certificate that signed the Image for Visual Verification data element (tag 0xBC) can be stored in the CHUID or in the Image for Visual Verification data element itself. If the latter, the “Max. Bytes” value quoted is a recommendation and the signer certificate in CBEFF_SIGNATURE_BLOCK can exceed the “Max. bytes.” Table 16. X.509 Certificate for Key Management
X.509 Certificate for Key Management 0x0102 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 17. X.509 Certificate for Card Authentication
X.509 Certificate for Card Authentication 0x0500 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 18. Discovery Object
Discovery Object (Tag '7E') 0x6050 Data El Data Element (TLV) Tag Type Max. Bytes PIV Card Application AID 0x4F Fixed 12 PIN Usage Policy 0x5F2F Fixed 2
Table 19. Key History Object
Key History Object 0x6060 Data Element (TLV) Tag Type Max. Bytes keysWithOnCardCerts 0xC1 Fixed 1 keysWithOffCardCerts 0xC2 Fixed 1 22 offCardCertURL (Conditional) 23 0xF3 Variable 118 Error Detection Code 0xFE LRC 0
22 The numeric values indicated in keysWithOnCardCerts and keysWithOffCardCerts are represented as unsigned binary integers. 23 The offCardCertURL data element shall be present if keysWithOffCardCerts is greater than zero and shall be absent if both keysWithOnCardCerts and keysWithOffCardCerts are zero. The offCardCertURL may be present if keyWithOffCardCerts is zero but keysWithOnCardCerts is greater than zero. Table 20. Retired X.509 Certificate for Key Management 1
Retired X.509 Certificate for Key Management 1 0x1001 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 21. Retired X.509 Certificate for Key Management 2
Retired X.509 Certificate for Key Management 2 0x1002 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 22. Retired X.509 Certificate for Key Management 3
Retired X.509 Certificate for Key Management 3 0x1003 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 23. Retired X.509 Certificate for Key Management 4
Retired X.509 Certificate for Key Management 4 0x1004 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73. Table 24. Retired X.509 Certificate for Key Management 5
Retired X.509 Certificate for Key Management 5 0x1005 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 25. Retired X.509 Certificate for Key Management 6
Retired X.509 Certificate for Key Management 6 0x1006 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 26. Retired X.509 Certificate for Key Management 7
Retired X.509 Certificate for Key Management 7 0x1007 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 27. Retired X.509 Certificate for Key Management 8
Retired X.509 Certificate for Key Management 8 0x1008 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73. Table 28. Retired X.509 Certificate for Key Management 9
Retired X.509 Certificate for Key Management 9 0x1009 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 29. Retired X.509 Certificate for Key Management 10
Retired X.509 Certificate for Key Management 10 0x100A Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 30. Retired X.509 Certificate for Key Management 11
Retired X.509 Certificate for Key Management 11 0x100B Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 31. Retired X.509 Certificate for Key Management 12
Retired X.509 Certificate for Key Management 12 0x100C Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73. Table 32. Retired X.509 Certificate for Key Management 13
Retired X.509 Certificate for Key Management 13 0x100D Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 33. Retired X.509 Certificate for Key Management 14
Retired X.509 Certificate for Key Management 14 0x100E Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 34. Retired X.509 Certificate for Key Management 15
Retired X.509 Certificate for Key Management 15 0x100F Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 35. Retired X.509 Certificate for Key Management 16
Retired X.509 Certificate for Key Management 16 0x1010 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73. Table 36. Retired X.509 Certificate for Key Management 17
Retired X.509 Certificate for Key Management 17 0x1011 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 37. Retired X.509 Certificate for Key Management 18
Retired X.509 Certificate for Key Management 18 0x1012 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 38. Retired X.509 Certificate for Key Management 19
Retired X.509 Certificate for Key Management 19 0x1013 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73.
Table 39. Retired X.509 Certificate for Key Management 20
Retired X.509 Certificate for Key Management 20 0x1014 Data Element (TLV) Tag Type Max. Bytes Certificate 0x70 Variable 1856 CertInfo 0x71 Fixed 1 MSCUID (Optional) 0x72 Variable 38 Error Detection Code 0xFE LRC 0 Note: The optional MSCUID data element is deprecated and will be eliminated in a future version of SP 800-73. The CertInfo byte in the certificate data objects identified in this appendix shall be encoded as follows:
b8 b7 b6 b5 b4 b3 b2 b1 RFU8 RFU7 RFU6 RFU5 RFU4 IsX509 CompressionTypeLsb CompressionTypeMsb
CompressionTypeMsb shall be 0 if the certificate is encoded in uncompressed form and 1 if the certificate is encoded using GZIP compression. 24 CompressionTypeLsb and IsX509 shall be set to 0 for PIV Card Applications. Thus, for a certificate encoded in uncompressed form CertInfo shall be 0x00, and for a certificate encoded using GZIP compression CertInfo shall be 0x01.
Table 40. Cardholder Iris Images
Cardholder Iris Images 0x1015 Data Element (TLV) Tag Type Max. Bytes Images for Iris 0xBC Variable 7100 ∗∗∗∗∗∗ Error Detection Code 0xFE LRC 0
Table 41. Biometric Information Templates Group Template
BIT Group Template (Tag '7F61') 0x1016 Data Element (TLV) Tag Type Max. Bytes Number of Fingers 0x02 Fixed 1 BIT for first Finger 0x7F60 Variable 28 BIT for second Finger (Optional) 0x7F60 Variable 28
Table 42. Secure Messaging Certificate Signer
Secure Messaging Certificate Signer 0x1017 Data Element (TLV) Tag Type Max. Bytes X.509 Certificate for Content Signing 0x70 Variable 1856 CertInfo 0x71 Fixed 1 Intermediate CVC (Conditional) 25 0x7F21 Variable 601 Error Detection Code 0xFE LRC 0 The CertInfo byte in the Secure Messaging Certificate Signer data object shall provide information about the X.509 Certificate for Content Signing. The Intermediate CVC, if present, shall be stored in uncompressed form.
24 GZIP formats are specified in RFC 1951 and RFC 1952. ∗∗∗∗∗∗ Recommended length. The certificate that signed the Images for Iris data element (tag 0xBC) can be stored in the CHUID or in the Images for Iris data element itself. If the latter, the “Max. Bytes” value quoted is a recommendation and the signer certificate in CBEFF_SIGNATURE_BLOCK can exceed the “Max. bytes.” 25 The Intermediate CVC shall be absent if the X.509 Certificate for Content Signing contains the public key needed to verify the signature on the secure messaging CVC and shall be present otherwise. Table 43. Pairing Code Reference Data Container
Pairing Code 0x1018 Data Element (TLV) Tag Type Max. Bytes Pairing Code 0x99 Fixed Text (ASCII) 8 Error Detection Code 0xFE LRC 0 Appendix B–– PIV Authentication Mechanisms
To provide guidelines on the usage and behavior supported by the PIV Card, PIV authentication mechanisms and application scenarios are described in this section. FIPS 201 describes PIV authentication as “the process of establishing confidence in the identity of the cardholder presenting a PIV Card.” The fundamental goal of using the PIV Card is to authenticate the identity of the cardholder to a system or person that is controlling access to a protected resource or facility. This end goal may be reached by various combinations of one or more of the validation steps described below:
Card Validation (CardV) — This is the process of verifying that a PIV Card is authentic (i.e., not a counterfeit card). Card validation mechanisms include:
+ visual inspection of the tamper-proofing and tamper-resistant features of the PIV Card as per Section 4.1.2 of FIPS 201;
+ use of cryptographic challenge-response schemes with symmetric keys; and
+ use of asymmetric authentication schemes to validate private keys embedded within the PIV Card.
Credential Validation (CredV) — This is the process of verifying the various types of credentials (such as visual credentials, CHUID, biometrics, and certificates) held by the PIV Card. Credential validation mechanisms include:
+ visual inspection of PIV Card visual elements (such as the photo, the printed name, and rank, if present);
+ verification of certificates on the PIV Card;
+ verification of signatures on the PIV biometrics and the CHUID;
+ checking the expiration date; and
+ checking the revocation status of the credentials on the PIV Card.
Cardholder Validation (HolderV) — This is the process of establishing that the PIV Card is in the possession of the individual to whom the card has been issued. Classically, identity authentication is achieved using one or more of these factors: a) something you have, b) something you know, and c) something you are. The assurance of the authentication process increases with the number of factors used. In the case of the PIV Card, these three factors translate as follows: a) something you have – possession of a PIV Card, b) something you know – knowledge of the PIN, and c) something you are – the visual characteristics of the cardholder, and the live fingerprint or iris image samples provided by the cardholder. Thus, mechanisms for PIV cardholder validation include:
+ presentation of a PIV Card by the cardholder;
+ matching the visual characteristics of the cardholder with the photo on the PIV Card;
+ matching the PIN provided with the PIN on the PIV Card; and + matching the live fingerprint samples provided by the cardholder with the biometric information embedded within the PIV Card.
B.1 Authentication Mechanism Diagrams
This section describes the activities and interactions involved in interoperable usage and authentication of the PIV Card. The authentication mechanisms represent how a relying party will authenticate the cardholder (regardless of which agency issued the card) in order to provide access to its systems or facilities. These activities and interactions are represented in functional authentication mechanism diagrams. These diagrams are not intended to provide syntactical commands or API function names.
Each of the PIV authentication mechanisms described in this section can be broken into a sequence of one or more validation steps where Card, Credential, and Cardholder validation is performed. In the illustrations, the validation steps are marked as CardV, CredV, and HolderV to signify Card, Credential, and Cardholder validation respectively.
Depending on the assurance provided by the actual sequence of validation steps in a given PIV authentication mechanism, relying parties can make appropriate decisions for granting access to protected resources based on a risk analysis. B.1.1 Authentication Using PIV Biometrics (BIO)
The general authentication mechanism using the PIV biometrics for off-card matching is illustrated in Figure B-1 .
Figure B-1. Authentication using PIV Biometrics (BIO) The assurance of authentication using the PIV biometric can be further increased if the live biometric sample is collected in an attended environment, with a human overseeing the process. The attended biometric authentication mechanism (BIO-A) is illustrated in Figure B-2 .
Figure B-2. Authentication using PIV Biometrics Attended (BIO-A) B.1.2 Authentication Using PIV Authentication Key
The authentication mechanism using the PIV Authentication key is illustrated in Figure B-3 .
Figure B-3. Authentication using PIV Authentication Key B.1.3 Authentication Using Card Authentication Key
Authentication mechanisms using the Card Authentication key are illustrated in Figures B-4 and B-5 . Figure B-4 illustrates the use of the mandatory asymmetric Card Authentication key, while Figure B- 5 uses the optional symmetric Card Authentication key for the authentication mechanism.
Figure B-4. Authentication using an asymmetric Card Authentication Key Figure B-5. Authentication using a symmetric Card Authentication Key B.1.4 Authentication Using OCC (OCC-AUTH)
The OCC-AUTH authentication mechanism is implemented by performing on-card biometric comparison (OCC) over secure messaging. The PIV Application authenticates the PIV Card as part of the process of establishing secure messaging. When the live-scan fingerprint biometric is supplied to the card for OCC over secure messaging, both the request and the response are protected using message authentication codes (MAC), allowing the PIV Application on the local system to verify that the response has not been altered and that it was created by the PIV Card that was authenticated during the establishment of secure messaging.
The OCC-AUTH authentication mechanism is performed by establishing secure messaging as described in Section 4 of Part 2 and then performing the VERIFY command, as illustrated in Figure B-6 .
Figure B-6. Authentication using OCC B.1.5 Authentication Using PIV Visual Credentials
This is the authentication mechanism where a human guard authenticates the cardholder using the visual credentials held by the PIV Card, and is illustrated in Figure B-7 .
Figure B-7. Authentication using PIV Visual Credentials B.1.6 Authentication Using PIV CHUID
The PIV CHUID may be used for authentication in several variations. The use of the PIV Card to implement the CHUID authentication mechanism is illustrated in Figure B-8 . The minimum set of data that must be transmitted from the PIV Application on the Local System to the host is application dependent and therefore not defined in this Specification.
Figure B-8. Authentication using PIV CHUID PRESENT CARD (HolderV) Connect Begin Transaction Select Application Select Application
PIV Card App ID and Version Read Value CHUID Read CHUID CHUID Returned RETRIEVE CHUID
REJECT
CARDHOLDER IDENTIFIER No
Yes Validation PIV Application on Local System API PIV Card Edge
No REJECT End Transaction Disconnect VALIDATE EXPIRATION (CredV)
VERIFY SIGNATURE (CredV) B.2 Summary Table
The following table summarizes the types of validation activities that are included in each of the PIV authentication mechanisms described earlier in this section.
Table 44. Summary of PIV Authentication Mechanisms
PIV Authentication Mechanism Card Validation Steps (CardV) Credential Validation Steps (CredV) Cardholder Validation Steps (HolderV) PIV Biometric Expiration check CHUID signature check PIV Bio signature check Match CHUID FASC-N with PIV Bio FASC-N Possession of Card Match PIN provided by Cardholder Match Cardholder bio with PIV bio PIV Biometric (Attended) Expiration check CHUID signature check PIV Bio signature check Match CHUID FASC-N with PIV Bio FASC-N Possession of Card Match PIN provided by Cardholder Match of Cardholder bio to PIV bio in view of attendant PIV Authentication Key Perform challenge and response with a PIV asymmetric key, and validate signature on response Certificate validation of a PIV certificate Possession of Card Match PIN or OCC data provided by Cardholder
Asymmetric Card Authentication Key Perform challenge and response with a PIV asymmetric Card Authentication key, and validate signature on response Certificate validation of a PIV certificate Possession of Card
Symmetric Card Authentication Key Perform challenge and response with a PIV symmetric key Possession of Card
On-card Biometric Comparison Establish Secure Messaging Certificate validation of a PIV certificate Possession of Card Match OCC data provided by Cardholder PIV Visual Authentication Counterfeit, tamper, and forgery check Expiration check Possession of Card Match of card visual characteristics with cardholder PIV CHUID Expiration check CHUID signature check Possession of Card Appendix C–– PIV Algorithm Identifier Discovery
Relying parties interact with many PIV Cards with the same native key type implemented by different key sizes and algorithms. 26 For example, a relying party performing the authentication mechanism described in Appendix B.1.2 (Authentication using the PIV Authentication key) can expect to perform a challenge and response cryptographic authentication with a 2048-bit RSA key or an ECDSA (Curve P-256) key.
This appendix describes recommended procedures for key size and algorithm discovery (PIV algorithm ID discovery) to facilitate cryptographic authentication initiated by the relying party to make appropriate decisions for granting access to logical networks and systems as well as physical access control systems. The discovery procedure is defined in terms of asymmetric and symmetric cryptographic authentication.
C.1 PIV Algorithm Identifier Discovery for Asymmetric Cryptographic Authentication
As illustrated in the authentication mechanisms in Appendix B , an asymmetric cryptographic authentication involves issuing a challenge (request to sign a nonce) to the PIV Card. The relying party issuing the command provides the nonce to be signed, the key reference, and the PIV algorithm identifier as parameters of the command. The nonce is random data generated by the relying party and the key reference is known. The PIV algorithm identifier, on the other hand, is unknown to the relying party and needs to be identified in order to issue the challenge command. The PIV algorithm identifier can be derived from the previous steps of the authentication mechanism. The relying party, prior to issuing the challenge command, retrieved and parsed the X.509 certificate from the card in order to 1) validate the certificate and 2) extract the public key for the pending verification of the signed nonce once returned from the card. It is during the parsing of the X.509 certificate that the PIV algorithm identifier can be identified in two steps: 27
Step 1: Algorithm Type Discovery: The X.509 certificate stores the public key in the subjectPublicKeyInfo field. The subjectPublicKeyInfo data structure has an algorithm field, which includes an OID that identifies the public key’s algorithm (RSA or ECC) as listed in Table 3-4 of SP 800-78.
Step 2: Key Size Discovery: If the algorithm type, as determined in Step 1, is ECC then the key size is determined by the elliptic curve on which the key has been generated, which is P-256 for all elliptic curve PIV Authentication keys and Card Authentication keys.
If the algorithm type, as determined in Step 1, is RSA then the key size is determined by the public key’s modulus. The public key appears in the subjectPublicKey field of subjectPublicKeyInfo and is encoded as a sequence that includes both the key’s modulus and public exponent.
26 Table 3-1, SP 800-78 lists the various algorithms and key sizes that may be used for each PIV key type. 27 The PIV algorithm identifiers specify both the key size and the algorithm for the key references. Thus both values have to be discovered in order to derive the PIV algorithm identifier. As a final step, the discovered X.509 algorithm OID and key size are mapped to the PIV algorithm identifiers as defined in Table 6-2 of SP 800-78. The relying party then proceeds to issue the GENERAL AUTHENTICATE command to the card.
C.2 PIV Algorithm Identifier Discovery for Symmetric Cryptographic Authentication
In the absence of an X.509 certificate, as is the case with symmetric cryptography, the PIV algorithm identifier discovery mechanism has to rely on a lookup table residing at the local system. The table maps a unique card identifier and key reference (inputs) to an associated PIV algorithm identifier (output). The unique identifier supplied by the card may be the Agency Code || System Code || Credential Number of the FASC-N or the Card UUID.
The symmetric Card Authentication key is optional to implement and a relying party has no prior knowledge of the key’s existence. The following routine discovers the Card Authentication key’s native implementation:
+ Read the CHUID and either extract the Card UUID or extract the Agency Code || System code || Credential Number from the CHUID’s FASC-N.
+ Retrieve the PIV algorithm identifier from the local lookup table. If no algorithm identifier is returned, authentication cannot be performed using the optional symmetric Card Authentication key either because the PIV Card does not implement the key or the local system cannot authenticate the response from the card.
C.3 PIV Algorithm Identifier Discovery for Secure Messaging
The Application Property Template, which is included in the response to the SELECT command, optionally includes a tag 0xAC, which indicates what cryptographic algorithms the PIV Card Application supports. 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. Appendix D–– Terms, Acronyms, and Notation
D.1 Terms
Algorithm Identifier A PIV algorithm identifier is a one-byte identifier that specifies a cryptographic algorithm and key size. For symmetric cryptographic operations, the algorithm identifier also specifies a mode of operation (i.e., ECB).
Application Identifier A globally unique identifier of a card application as defined in ISO/IEC 7816-4.
Application Session The period of time within a card session between when a card application is selected and a different card application is selected or the card session ends.
Authenticable Entity An entity that can successfully participate in an authentication protocol with a card application.
BER-TLV Data Object A data object coded according to ISO/IEC 8825-2.
Card An integrated circuit card.
Card Application A set of data objects and card commands that can be selected using an application identifier.
Client Application A program running on a computer in communication with a card interface device.
Card Management Any operation involving the PIV Card Application Administrator. Operation
Card Verifiable A certificate stored on the card that includes a public key, the signature of a Certificate certification authority, and further information needed to verify the certificate.
Data Object An item of information seen at the card command interface for which is specified a name, a description of logical content, a format, and a coding.
Key Reference A key reference is a one-byte identifier that specifies a cryptographic key according to its PIV Key Type. The identifier is part of the cryptographic material used in a cryptographic protocol, such as an authentication or a signing protocol.
MSCUID An optional legacy identifier included for compatibility with Common Access Card and Government Smart Card Interoperability Specifications.
Object Identifier A globally unique identifier of a data object as defined in ISO/IEC 8824-2. Paring Code An 8 digit code used to establish a relationship between the PIV Card and a device for the purpose of creating the virtual contact interface after secure messaging has been established.
PIV Key Type The type of a key. The PIV Key Types are 1) PIV Authentication key, 2) Card Authentication key, 3) digital signature key, 4) key management key, 5) retired key management key, 6) PIV Secure Messaging key, and 7) PIV Card Application Administration key.
Relying Party An entity that relies upon the subscriber’s credentials, typically to process a transaction or grant access to information or a system.
Status Word Two bytes returned by an integrated circuit card after processing any command that signify the success of or errors encountered during said processing.
D.2 Acronyms
ACR Access Control Rule AID Application Identifier APDU Application Protocol Data Unit API Application Programming Interface ASCII American Standard Code for Information Interchange ASN.1 Abstract Syntax Notation One
BER Basic Encoding Rules BIT Biometric Information Template
CAK Card Authentication Key CBEFF Common Biometric Exchange Formats Framework CCC Card Capability Container CHUID Card Holder Unique Identifier CMS Cryptographic Message Syntax CVC Card Verifiable Certificate
DER Distinguished Encoding Rules DG Data Group DTR Derived Test Requirement
ECB Electronic Code Book ECC Elliptic Curve Cryptography ECDH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature Algorithm
FASC-N Federal Agency Smart Credential Number FIPS Federal Information Processing Standards FISMA Federal Information Security Management Act
GSC-IS Government Smart Card Interoperability Specification GUID Global Unique Identification number HSPD Homeland Security Presidential Directive HTTP Hypertext Transfer Protocol
ICC Integrated Circuit Card IEC International Electrotechnical Commission INCITS InterNational Committee for Information Technology Standards ISO International Organization for Standardization ITL Information Technology Laboratory
LSB Least Significant Bit LRC Longitudinal Redundancy Code
MAC Message Authentication Code MRTD Machine Readable Travel Document MSB Most Significant Bit
NIST National Institute of Standards and Technology NPIVP NIST Personal Identity Verification Program
OCC On-Card biometric Comparison OID Object Identifier OMB Office of Management and Budget
PACS Physical Access Control System PIN Personal Identification Number PI Person Identifier, a field in the FASC-N PIV Personal Identity Verification PIX Proprietary Identifier Extension PKCS Public-Key Cryptography Standards PKI Public Key Infrastructure PUK PIN Unblocking Key
RFU Reserved for Future Use RID Registered application provider IDentifier RSA Rivest, Shamir, Adleman
SCEPACS Smart Card Enabled Physical Access Control System SHA Secure Hash Algorithm SP Special Publication SM Secure Messaging SW1 First byte of a two-byte status word SW2 Second byte of a two-byte status word
TIG Technical Implementation Guidance TLV Tag-Length-Value
URI Uniform Resource Identifier URL Uniform Resource Locator UUID Universally Unique Identifier
VCI Virtual Contact Interface D.3 Notation
The sixteen hexadecimal digits shall be denoted using the alphanumeric characters 0, 1, 2, …, 9, A, B, C, D, E, and F. A byte consists of two hexadecimal digits, for example, '2D'. The two hexadecimal digits are represented in quotations '2D' or as 0x2D. A sequence of bytes may be enclosed in single quotation marks, for example 'A0 00 00 01 16', rather than given as a sequence of individual bytes, 'A0' '00' '00' '01' '16'.
A byte can also be represented by bits b8 to b1, where b8 is the most significant bit (MSB) and b1 is the least significant bit (LSB) of the byte. In textual or graphic representations, the leftmost bit is the MSB. Thus, for example, the most significant bit, b8, of '80' is 1 and the least significant bit, b1, is 0.
All bytes specified as RFU shall be set to '00' and all bits specified as RFU shall be set to 0.
All lengths shall be measured in number of bytes unless otherwise noted.
The expression 'X' & 'Y' is a bitwise AND operation between bytes 'X' and 'Y'.
The symbol || means concatenation of byte strings. For example, if X is '00 01 02' and Y is '03 04 05', then X || Y is '00 01 02 03 04 05'.
Data objects in templates are described as being mandatory (M), optional (O), or conditional (C). 'Mandatory' means the data object shall appear in the template. 'Optional' means the data object may appear in the template. In the case of 'Conditional' data objects, the conditions under which they are required are provided.
In other tables the M/O/C column identifies properties of the PIV Card Application that shall be present (M), may be present (O), or are conditionally required to be present (C).
BER-TLV data object tags are represented as byte sequences as described above. Thus, for example, 0x4F is the interindustry data object tag for an application identifier and 0x7F61 is the interindustry data object tag for the Biometric Information Templates Group Template. Appendix E–– References
[COMMON] X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework , Version 1.23, May 2014, or as amended. (See http://www.idmanagement.gov/documents/common-policy- framework-certificate-policy )
[FIPS180] Federal Information Processing Standard 180-4, Secure Hash Standard (SHS) , March 2012. (See http://csrc.nist.gov )
[FIPS201] Federal Information Processing Standard 201-2, Personal Identity Verification (PIV) of Federal Employees and Contractors , August 2013. (See http://dx.doi.org/10.6028/NIST.FIPS.201-2 )
[GSC-IS] Government Smart Card Interoperability Specification, Version 2.1 , NIST Interagency Report 6887 – 2003 Edition, July 16, 2003. (See http://csrc.nist.gov )
[IR7676] NIST Interagency Report 7676, Maintaining and Using Key History on Personal Identity Verification (PIV) Cards , June 2010. (See http://csrc.nist.gov )
[ISO7816] ISO/IEC 7816 (Parts 4, 5, 6, 8, and 9), Information technology — Identification cards — Integrated circuit(s) cards with contacts.
[ISO8824] ISO/IEC 8824-2:2002, Information technology — Abstract Syntax Notation One (ASN.1): Information object specification.
[ISO8825] ISO/IEC 8825-1:2002, Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[MRTD] ICAO 9303 Machine Readable Travel Documents, Part 3: Machine Readable Official Travel Documents, Volume 2: Specifications for Electronically Enabled MRtds with Biometric Identification Capability , Third Edition – 2008. Published by authority of the Secretary General, International Civil Aviation Organization.
[NISTIR7863] NISTIR 7863, Cardholder Authentication for the PIV Digital Signature Key , NIST.
[PIV-I NFI] Personal Identity Verification Interoperability for Non-Federal Issuers, May 2009, or as amended. (See https://cio.gov/wp-content/uploads/downloads/2012/09/PIV_Interoperabillity_Non- Federal_Issuers_May-2009.pdf )
[PIV-I FAQ] Personal Identity Verification Interoperable (PIV-I) Frequently Asked Questions (FAQ), Version 1.0, June 28, 2010, or as amended. (See https://www.idmanagement.gov/sites/default/files/documents/PIV-I_FAQ.pdf )
[RFC2616] IETF RFC 2616, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999. (See http://www.ietf.org/rfc/rfc2616.txt )
[RFC2585] IETF RFC 2585, “Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP,” May 1999. (See http://www.ietf.org/rfc/rfc2585.txt ) [RFC4122] IETF RFC 4122, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005. (See http://www.ietf.org/rfc/rfc4122.txt )
[RFC4530] IETF RFC 4530, “Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute,” June 2006. (See http://www.ietf.org/rfc/rfc4530.txt )
[RFC5280] IETF RFC 5280, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008. (See http://www.ietf.org/rfc/rfc5280.txt )
[RFC5652] IETF RFC 5652, “Cryptographic Message Syntax (CMS),” September 2009. (See http://www.ietf.org/rfc/rfc5652.txt )
[SP800-76] NIST Special Publication 800-76-2, Biometric Specifications for Personal Identity Verification, July 2013. (See http://dx.doi.org/10.6028/NIST.SP.800-76-2 )
[SP800-78] NIST Special Publication 800-78-4, Cryptographic Algorithms and Key Sizes for Personal Identity Verification , May 2015. (See http://csrc.nist.gov )
[SP800-87] NIST Special Publication 800-87 Revision 1, Codes for Identification of Federal and Federally-Assisted Organizations , April 2008. (See http://csrc.nist.gov )
[SP800-85A-4] Draft NIST Special Publication 800-85A-4, PIV Card Application and Middleware Interface Test Guidelines (SP800-73-4 Compliance) , 2015. (See http://csrc.nist.gov )
[TIG SCEPACS] PACS v2.2, Technical Implementation Guidance: Smart Card Enabled Physical Access Control Systems , Version 2.2, The Government Smart Card Interagency Advisory Board’s Physical Access Interagency Interoperability Working Group, July 30, 2004. (See https://www.idmanagement.gov/sites/default/files/documents/TIG_SCEPACS_v2.2_0.pdf ) Verification – Part 2: PIV Card
Application Card Command
Interface
David Cooper Hildegard Ferraiolo Ketan Mehta Salvatore Francomacaro Ramaswamy Chandramouli Verification – Part 2: PIV Card
Application Card Command
Interface
David Cooper Hildegard Ferraiolo Ketan Mehta Salvatore Francomacaro Ramaswamy Chandramouli Computer Security Division Information Technology Laboratory
Electrosoft Services, Inc.
May 2015 INCLUDES UPDATES AS OF 02-08-2016: SEE PART 1, PAGE VIII This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Modernization Act (FISMA), Public Law (P.L.) 107-347. 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, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A- 130, Appendix III, Security of Federal Automated Information Resources.
Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.
National Institute of Standards and Technology Special Publication 800-73-4 Natl. Inst. Stand. Technol. Spec. Publ. 800-73-4, 61 pages (May 2015) CODEN: NSPUE2
Comments on this publication may be submitted to: Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: [email protected] Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by Federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, Federal noted above, are available at http://csrc.nist.gov/publications. The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in Federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.
Abstract
FIPS 201 defines the requirements and characteristics of a government-wide interoperable identity credential. FIPS 201 also specifies that this identity credential must be stored on a smart card. This document, SP 800-73, 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 where the international integrated circuit card standards [ISO7816 ] include options and branches. The specifications go further by constraining implementers’ interpretations of the normative standards. Such restrictions are designed to ease implementation, facilitate interoperability, and ensure performance, in a manner tailored for PIV applications.
Keywords
authentication; FIPS 201; identity credential; logical access control; on-card biometric comparison; Personal Identity Verification (PIV); physical access control; smart cards; secure messaging
Acknowledgements
The authors (David Cooper, Hildegard Ferraiolo, Ketan Mehta, Salvatore Francomacaro, and Ramaswamy Chandramouli of NIST, and Jason Mohler of Electrosoft Services, Inc.) wish to thank their colleagues who reviewed drafts of this document and contributed to its development. 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. 1. INTRODUCTION ............................................................................................................................................. 1 1.1 PURPOSE ..................................................................................................................................................... 1 1.2 SCOPE ......................................................................................................................................................... 1 1.3 AUDIENCE AND ASSUMPTIONS .................................................................................................................... 1 1.4 CONTENT AND ORGANIZATION ................................................................................................................... 2 2. OVERVIEW: CONCEPTS AND CONSTRUCTS ........................................................................................ 3 2.1.1 Platform Requirements .......................................................................................................................... 3 2.2 NAMESPACES OF THE PIV CARD APPLICATION ........................................................................................... 3 2.3 CARD APPLICATIONS .................................................................................................................................. 4 2.3.1 Default Selected Card Application ......................................................................................................... 4 2.4 SECURITY ARCHITECTURE .......................................................................................................................... 4 2.4.1 Access Control Rule ............................................................................................................................... 4 2.4.2 Security Status ........................................................................................................................................ 4 2.4.3 Authentication of an Individual .............................................................................................................. 5 2.5 CURRENT STATE OF THE PIV CARD APPLICATION ...................................................................................... 6 3. PIV CARD APPLICATION CARD COMMAND INTERFACE ................................................................. 7 3.1 PIV CARD APPLICATION CARD COMMANDS FOR DATA ACCESS ................................................................ 8 3.1.1 SELECT Card Command ....................................................................................................................... 8 3.1.2 GET DATA Card Command ................................................................................................................ 10 3.2 PIV CARD APPLICATION CARD COMMANDS FOR AUTHENTICATION ........................................................ 11 3.2.1 VERIFY Card Command ...................................................................................................................... 11 3.2.2 CHANGE REFERENCE DATA Card Command ................................................................................. 14 3.2.3 RESET RETRY COUNTER Card Command ........................................................................................ 15 3.2.4 GENERAL AUTHENTICATE Card Command .................................................................................... 17 3.3 PIV CARD APPLICATION CARD COMMANDS FOR CREDENTIAL INITIALIZATION AND ADMINISTRATION .. 19 3.3.1 PUT DATA Card Command ................................................................................................................ 19 3.3.2 GENERATE ASYMMETRIC KEY PAIR Card Command .................................................................... 20 4. SECURE MESSAGING ................................................................................................................................. 22 4.1 THE KEY ESTABLISHMENT PROTOCOL ...................................................................................................... 22 4.1.1 Client Application Steps ....................................................................................................................... 23 4.1.2 PIV Card Application Protocol Steps .................................................................................................. 24 4.1.3 Notations .............................................................................................................................................. 26 4.1.4 Cipher Suite ......................................................................................................................................... 26 4.1.5 Card Verifiable Certificates ................................................................................................................. 27 4.1.6 Key Derivation ..................................................................................................................................... 29 4.1.7 Key Confirmation ................................................................................................................................. 29 4.1.8 Command Interface .............................................................................................................................. 30 4.2 SECURE MESSAGING ................................................................................................................................. 30 4.2.1 Secure Messaging Data Objects .......................................................................................................... 31 4.2.2 Command and Response Data Confidentiality .................................................................................... 31 4.2.3 Command Integrity .............................................................................................................................. 33 4.2.4 Command with PIV Secure Messaging ................................................................................................ 34 4.2.5 Response Integrity ................................................................................................................................ 35 4.2.6 Response with PIV Secure Messaging ................................................................................................. 36 4.2.7 Error Handling .................................................................................................................................... 37 4.3 SESSION KEY DESTRUCTION ..................................................................................................................... 37
APPENDIX A— EXAMPLES OF THE USE OF THE GENERAL AUTHENTICATE COMMAND ........... 39 A.1 AUTHENTICATION OF THE PIV CARD APPLICATION ADMINISTRATOR ...................................................... 39 A.2 MUTUAL AUTHENTICATION OF CLIENT APPLICATION AND CARD APPLICATION ...................................... 39 A.3 AUTHENTICATION OF PIV CARDHOLDER .................................................................................................. 40 A.4 SIGNATURE GENERATION WITH THE DIGITAL SIGNATURE KEY ................................................................ 42 A.4.1 RSA ...................................................................................................................................................... 42 A.4.2 ECDSA ................................................................................................................................................. 43 A.5 KEY ESTABLISHMENT SCHEMES WITH THE PIV KEY MANAGEMENT KEY ................................................ 43 A.5.1 RSA Key Transport .............................................................................................................................. 44 A.5.2 Elliptic Curve Cryptography Diffie-Hellman ....................................................................................... 45 A.5.2.1.1 The GENERAL AUTHENTICATE Command ................................................................................... 46 A.6 AUTHENTICATION OF THE PIV CARDHOLDER OVER THE VIRTUAL CONTACT INTERFACE ........................ 47 APPENDIX B— TERMS, ACRONYMS, AND NOTATION ............................................................................. 51 B.1 TERMS ....................................................................................................................................................... 51 B.2 ACRONYMS ............................................................................................................................................... 52 B.3 NOTATION ................................................................................................................................................. 53 APPENDIX C— REFERENCES ........................................................................................................................... 55
List of Tables
Table 1. State of the PIV Card Application ................................................................................................................. 6 Table 2. PIV Card Application Card Commands ......................................................................................................... 7 Table 3. Data Objects in the PIV Card Application Property Template (Tag '61') ...................................................... 9 Table 4. Data Objects in a Coexistent Tag Allocation Authority Template (Tag '79') ................................................ 9 Table 5. Data Objects in a Cryptographic Algorithm Identifier Template (Tag 'AC') ................................................. 9 Table 6. Data Objects in the Data Field of the GET DATA Card Command ............................................................ 10 Table 7. Data Objects in the Dynamic Authentication Template (Tag '7C') .............................................................. 18 Table 8. Data Field of the PUT DATA Card Command for the Discovery Object ................................................... 19 Table 9. Data Field of the PUT DATA Card Command for the BIT Group Template .............................................. 19 Table 10. Data Field of the PUT DATA Card Command for all other PIV Data Objects ......................................... 19 Table 11. Data Objects in the Template (Tag 'AC') ................................................................................................... 20 Table 12. Data Objects in the Template (Tag '7F49') ................................................................................................ 20 Table 13. Public Key encoding for ECC .................................................................................................................... 21 Table 14. Cipher Suite for PIV Secure Messaging .................................................................................................... 26 Table 15. Secure Messaging Card Verifiable Certificate Format .............................................................................. 27 Table 16. Intermediate Card Verifiable Certificate Format ....................................................................................... 28 Table 17. Secure Messaging Data Objects ................................................................................................................. 31 Table 18. Authentication of PIV Card Application Administrator ............................................................................ 39 Table 19. Mutual Authentication of Client Application and PIV Card Application .................................................. 40 Table 20. Validation of the PIV Card Application Using GENERAL AUTHENTICATE ....................................... 41
List of Figures
Figure 1. PIV Data Confidentiality ............................................................................................................................ 32 Figure 2. PIV Data Integrity of Command ................................................................................................................ 34 Figure 3. Single Command under Secure Messaging ................................................................................................ 35 Figure 4. Chained Command under Secure Messaging ............................................................................................. 35 Figure 5. PIV Data Integrity of Response .................................................................................................................. 36 Figure 6. Single Response under Secure Messaging ................................................................................................. 37 Figure 7. Chained Response under Secure Messaging .............................................................................................. 37 Homeland Security Presidential Directive-12 (HSPD-12) called for a common identification standard to be adopted governing the interoperable use of identity credentials to allow physical and logical access to Federally controlled facilities and information systems. Federal Information Processing Standard 201 [FIPS201 ], Personal Identity Verification (PIV) of Federal Employees and Contractors, was developed to establish standards for identity credentials. Special Publication 800-73-4 (SP 800-73-4) contains technical specifications to interface with the smart card (PIV Card 1 ) to retrieve and use the identity credentials.