This appendix is normative.
This appendix provides data model and interface requirements for PKI-based derived PIV applications that are implemented on removable or wireless hardware cryptographic tokens.
The data model and representation requirements for derived PIV applications are based on the requirements for PIV Card applications, as described in [SP800-73] Part 1. The specifications for the mandatory and optional data objects listed below are the same as the specifications for the corresponding data objects on a PIV Card application, as described in [SP800-73] Part 1.
The application identifier (AID) of the derived PIV application SHALL be (in hexadecimal):
A0 00 00 03 08 00 00 20 00 01 00
The derived PIV application can be selected as the current application on the removable hardware cryptographic token by providing the full AID listed above or by providing the right truncated version, as follows (hexadecimal):
A0 00 00 03 08 00 00 20 00
The derived PIV application SHALL contain the following mandatory interoperable data object:
The following data objects MAY also be present:
0x40 to indicate that the virtual contact interface (VCI) is not implemented, 0x48 to indicate that a pairing code is required to establish a VCI, or 0x4C to indicate that no pairing code is required to establish a VCI. This also means that neither the global PIN nor the on-card biometric comparison (OCC) satisfies the access control rules for command execution and data object access within the derived PIV application.0xBB, SHALL include the derived PIV credential issuer’s certificate.\clearpage
Section 3.5 of [SP800-73] Part 1 provides the container IDs and access rules for the mandatory and optional data objects for a derived PIV application with the following mappings:
Table 1. Mapping of Data Objects
| Derived PIV Application Data Object | PIV Card Application Data Object |
|---|---|
| X.509 Certificate for Derived PIV Authentication | X.509 Certificate for PIV Authentication |
| Security Object | Security Object |
| X.509 Certificate for Digital Signature | X.509 Certificate for Digital Signature |
| X.509 Certificate for Key Management | X.509 Certificate for Key Management |
| Discovery Object | Discovery Object |
| Key History Object | Key History Object |
| Retired X.509 Certificate for Key Management [1:20] | Retired X.509 Certificate for Key Management [1:20] |
| Secure Messaging Certificate Signer | Secure Messaging Certificate Signer |
| Pairing Code Reference Data Container | Pairing Code Reference Data Container |
The detailed data model specifications for each of the data objects of the derived PIV application are the same as the specifications for the corresponding data objects (mapped per Table 1) of the PIV Card application as described in Appendix A of [SP800-73] Part 1, except for the following:
The security object for the derived PIV application is optional. It is required if the optional discovery object, the optional key history object, or the optional pairing code reference data container is present.
The minimum capacity for the security object container SHALL be 3000 bytes in order to allow space for the derived PIV credential issuer’s certificate.
The ASN.1 object identifiers (OID) and “basic encoding rules – tag length value” (BER-TLV) tags for the mandatory and optional data objects within the derived PIV application are the same as for the corresponding data objects (mapped per Table 1) of the PIV Card application, as described in Sec. 4 of [SP800-73] Part 1.
This appendix provides a description of the data types used in the derived PIV application command interface.
Key references are assigned to keys and secrets of the derived PIV application. Table 6-1 of [SP800-78] and Table 4 of [SP800-73] Part 1 define the key reference values that SHALL be used on the derived PIV application interfaces with the following mappings:
| Derived PIV Key Type | PIV Key Type |
|---|---|
| Derived PIV Activation Secret | PIV Card Application PIN |
| Activation Secret Unblocking Key | PIN Unblocking Key |
| Derived PIV Authentication Key | PIV Authentication Key |
| Derived PIV Token Management Key | Card Management Key |
| Digital Signature Key | Digital Signature Key |
| Key Management Key | Key Management Key |
| Retired Key Management Key | Retired Key Management Key |
| Derived PIV Secure Messaging Key | PIV Secure Messaging Key |
The key reference specifications in Sec. 5.1 of [SP800-73] Part 1 are applicable to the corresponding keys included in the derived PIV application (mapped per Table 2), except for the following:
References to “PIV Card application” are replaced with “derived PIV application.”
References in the “Security Condition for Use” column to “PIN or OCC” are replaced with “derived PIV activation secret.”
The algorithm identifiers for the cryptographic algorithms that MAY be recognized on the derived PIV application interfaces are the symmetric and asymmetric identifiers specified in Table 6-2 and Table 6-3 of [SP800-78]. The cryptographic mechanism identifiers that MAY be recognized on the derived PIV application interfaces are those specified in Table 5 of [SP800-73] Part 1.
The status words that MAY be returned on the derived PIV application command interface are as specified in Sec. 5.6 of [SP800-73] Part 1.
The derived PIV application supports the following validation steps:
Credential validation (CredV) is established by verifying the certificates retrieved from the derived PIV application and checking the validity and revocation status of these certificates.
Derived PIV application holder validation (HolderV) is established when the authenticator holder proves knowledge of the derived PIV activation secret associated with the derived PIV credential that contains valid and unrevoked certificates.
The derived PIV application facilitates a single authentication mechanism, which is a cryptographic challenge and response authentication protocol that uses the derived PIV authentication private key as described in Appendix B.1.2 of [SP800-73] Part 1 with the following translations:
The authentication can also be performed wirelessly over a virtual contact interface (VCI) if a VCI has been established with the derived PIV application.
This appendix contains the technical specifications for the command interface to the derived PIV application surfaced by the card edge of the integrated circuit card (ICC) that represents the removable hardware cryptographic token. The command interface for the derived PIV application SHALL implement all of the card commands supported by the PIV Card application as described in [SP800-73] Part 2, which include:
The specifications for the token command interface SHALL be the same as the specifications for the corresponding card edge commands for a PIV Card as described in [SP800-73] Part 2, except for the following deviations:
The token platform SHALL support a default selected application, which is the selected application that immediately following a cold or warm reset. This default application may be the derived PIV application or another application.
Knowledge of a memorized secret (specifically the derived PIV activation secret) is the means by which an individual can be authenticated to the derived PIV application.
The derived PIV activation secret SHALL be between 6 and 8 bytes in length. If the actual length of the derived PIV activation secret is less than 8 bytes, it SHALL be padded to 8 bytes with 0xFF when presented to the token command interface. The 0xFF padding bytes SHALL be appended to the actual value of the secret. The bytes that comprise the derived PIV activation secret SHALL be limited to values 0x30 – 0x39, 0x41 – 0x5A, and 0x61 – 0x7A: the ASCII values for the decimal digits ‘0’ – ‘9’; upper case characters ‘A’ – ‘Z’; and lower case characters ‘a’ – ‘z’. For example,
50 61 72 74 32 3150 61 72 74 32 31 FF FFThe derived PIV application SHALL enforce the minimum length requirement of 6 bytes for the derived PIV activation secret (i.e., SHALL verify that at least the first 6 bytes of the value presented to the card command interface are in the range 0x30 – 0x39, 0x41 – 0x5A, or 0x61 – 0x7A) as well as the other formatting requirements specified in this section.