This appendix is normative.
This appendix provides data model and interface requirements for PKI-based derived PIV applications implemented on removable or wireless cryptographic authenticators. Use of wireless cryptographic authenticators in this appendix is applicable to logical access. Wireless authenticators for physical access (e.g., facility access) are specified in Appendix D.
The data model and representation requirements for derived PIV applications are based on the requirements for PIV Card applications, as described in [SP800-73pt1]. Test requirements and test assertions for testing the derived PIV application and associated derived PIV data objects implemented on removable hardware tokens are specified in [SP800-166], Derived PIV Application and Data Model Test Guidelines. 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-73pt1].
The PIV application ID (AID) SHOULD be used to maximize interoperability with PIV Cards. For reference, that application ID is (in hexadecimal):
A0 00 00 03 08 00 00 10 00 01 00
Alternatively, the derived PIV application identifier defined in the previous edition of this guideline MAY be used. This application ID is deprecated and may not be included in future editions of this guideline. That application ID is (in hexadecimal):
A0 00 00 03 08 00 00 20 00 01 00
No other application ID SHALL be used.
The PIV or derived PIV application can be selected as the current application on the removable cryptographic token by providing the full AID listed above or the right-truncated version, as follows (hexadecimal):
A0 00 00 03 08 00 00 x0 00
where ‘x’ is either 1 for the PIV application or 2 for the derived PIV application.
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-73pt1] 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-73pt1], 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 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-73pt1].
This appendix describes 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 8 of [SP800-78] and Table 4 of [SP800-73pt1] 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-73pt1] apply 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 9 and Table 10 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-73pt1].
The status words that MAY be returned on the derived PIV application command interface are as specified in Sec. 5.6 of [SP800-73pt1].
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-73pt1] with the following translations:
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 cryptographic authenticator. 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-73pt2], 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-73pt2], except for the following deviations:
The token platform SHALL support a default selected application, which is the application chosen following a cold or warm reset. This default application may be the derived PIV application or another application.
Knowledge of a secret (specifically the derived PIV activation secret) is how 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.