...
A detailed explanation of the operational guidelines for these features is documented in NIST SP800-73-4 (link).
Feature
Description and OpenFIPS201 Support
Secure Channel Administration
Permits card data objects, keys and configuration to be managed by an entity authenticated using a GlobalPlatform Secure Channel Protocol with command encryption (C-ENC) and integrity (C-MAC).
| Note |
|---|
Response encryption (R-ENC) and integrity (R-MAC) is not enforced as sensitive security parameters (such as Key or PIN values) are never permitted to be returned by the card, even by an administrator. |
Flexible Filesystem and Key Store
(Pre-Personalisation)
To maintain a high level of flexibility, OpenFIPS201 deliberately does not define any data objects or key references. Instead, it provides a simple pre-personalisation command so these can be defined by your card/application management system. This permits any number of use cases where additional data objects, certificates or cryptographic keys are required for specific use cases. In fact, you can completely define your own file system that has nothing to do with PIV!
The command interface for this is almost identical to the PIV ‘PUT DATA’ command to reduce integration requirements.
| Info |
|---|
This functionality must be executed with administrative (issuer) rights. |
| Info |
|---|
If you want your applet to be PIV-compliant, at a minimum you must implement the pre-defined set of mandatory data objects and keys from NIST SP800-73-4, so a script has been provided below defines all mandatory and optional PIV objects, supporting all available cryptographic mechanisms. |
Key Injection and PIN management
All asymmetric keys may be generated on-card as-per the PIV standard, however it is also possible to directly inject key values into the applet. This is useful if keys are archived, escrowed or simply generated from a HSM.
| Note |
|---|
When planning your key generation policies, it is important to consider privacy and repudiation concerns before deciding to inject keys. For example, it is not recommended to generate any keys used with Digital Signatures off-card as this can lead to doubts about the authenticity of signatures. |
PIN unblocking, PIN and PUK management
Feature | Description and OpenFIPS201 Support | |||||
|---|---|---|---|---|---|---|
Verification - Cardholder via Applet PIN | Permits the cardholder to be verified by supplying a PIN which is maintained within the applet. Although some functionality can be performed by anyone, access to keys and data objects is generally restricted until the cardholder has authenticated verified themselves in one of the approved ways.
| |||||
Verification - Cardholder via Global PIN | Permits the cardholder to be verified by supplying a PIN which is maintained globally by the card issuer.
| |||||
Verification - Cardholder via Biometric On-Card Comparison | TBD | |||||
Verification - Security Officer via Applet PUK | Permits the cardholder PIN (either applet or global) to be unlocked and reset by means of a PIN Unblocking Key (PUK). | |||||
Verification - Pairing Code | Provides protection against interception of contactless communications by the use of an 8-digit value randomly generated by the issuer. | |||||
Verification - PIN Extended Length | Supports PIN and PUK lengths up to 16 characters | |||||
Verification - PIN Extended Character Sets | Supports a number of additional character sets for PIN entry, including alpha-numeric (case sensitive or insensitive) and raw (any value). | |||||
Verification - PIN Complexity | Supports enforcing PIN complexity rules to prevent commonly known weak PIN patterns from being used. | |||||
Verification - PIN History | Supports preventing PIN values from being re-used by storing and checking against the last [n] cardholder PIN values set. | |||||
Verification - PUK Retry Limits | Supports preventing PUK brute-forcing by applying the configurable retry limits to PUK verifications. In the event that the PUK is blocked, it can only be unblocked over a secure administrative interface. | |||||
Card Management - Symmetric Key | Permits card data objects and keys to be managed by an entity in possession of an administrative symmetric key.
| |||||
Card Management - Data Objects | Permits data object content to be set when an administrative authentication has successfully occurred. | |||||
Algorithm - RSA | Supports RSA key-pair generation and usage. Allows keys with 1024 or 2048 bits length. | |||||
Algorithm - Elliptic Curve Cryptography (ECC) | Supports ECC key-pair generation and usage using the NIST approved curves P-256 and P-384. | |||||
Algorithm - Triple DES | Supports Card, Client and Administrative authentication using 192-bit key length only (TDEA-3KEY).
| |||||
Algorithm - AES | Supports Card, Client and Administrative authentication using 128, 192 and 256 bit key lengths. | |||||
Crypto - Key Generation (Asymmetric) | Supports generation of asymmetric key-pair values, returning the public value for certificate generation. | |||||
Crypto - Card Authentication (Symmetric) | Supports one-way authentication of the Card to the Client using a challenge / response protocol. Typically used for symmetric-key PACS systems only.
| |||||
Crypto - Client Authentication (Symmetric) | Supports one-way authentication of the Client to the Card using a Card Management - Symmetric Key | Permits card data objects and keys to be managed by an entity in possession of an administrative symmetric key.
| ||||
Card Management - Data Objects | Permits data object content to be set when an administrative authentication has successfully occurred. | |||||
Algorithm - RSA | Supports RSA key-pair generation and usage. Allows keys with 1024 or 2048 bits length. | |||||
Algorithm - Elliptic Curve Cryptography (ECC) | Supports ECC key-pair generation and usage using the NIST approved curves P-256 and P-384. | |||||
Algorithm - Triple DES | Supports Card, Client and Administrative authentication using 192-bit key length only (TDEA-3KEY).
| |||||
Algorithm - AES | Supports Card, Client and Administrative authentication using 128, 192 and 256 bit key lengths. | |||||
Crypto - Key Generation (Asymmetric) | Supports generation of asymmetric key-pair values, returning the public value for certificate generation. | |||||
Crypto - Card Authentication (Symmetric) | Supports one-way authentication of the Card to the Client using a challenge / response protocol. Typically used for symmetric-key PACS systems only.
| |||||
Crypto - Client Authentication (Symmetric) | Supports one-way authentication of the Client to the Card using a challenge / response protocol. Permits administrative authentication.
| |||||
Crypto - Card and Client Authentication (Symmetric) | Supports two-way (mutual) authentication of both the Client and the Card using a two-pass challenge / response protocol. Permits administrative authentication.
| |||||
Crypto - Card and Client Authentication (Symmetric) | Supports two-way (mutual) authentication of both the Client and the Card using a two-pass challenge / response protocol. Permits administrative authentication. | |||||
Crypto - Card Authentication (Asymmetric) | Provides authentication of the Card and Cardholder by digitally signing a challenge request using the appropriate private key. | Provides digital signature generation functionality on a pre-computed message digest.
| ||||
Crypto - Key Establishment | Supports the establishment of a shared secret, which can then be used for further encryption operations. Modes of Key Establishment are:
| |||||
Crypto - Secure Messaging | Provides an implementation of Opacity Zero-Key-Management (ZKM) which is then used to secure further communications with the card in environments where passive interception is possible (i.e. sniffing of RF modulation or serial communications). | |||||
Other - Virtual Contact Interface | Supports the application state where a contactless interface is treated as a contact interface for the purposes of assessing Key and Data Object usage rights. This state is reached by the following two conditions being both met (or just the first condition if the card policy allows):
|
3 Extension Features
There are a number of essential functions that are not defined by SP 800-73, especially with regards to administrative management. This is likely a deliberate decision by NIST to ensure that vendors could capitalise on their own existing or novel methods of card and application management. OpenFIPS201 addresses these areas in a way that increases both the flexibility and security of the application and card administration.
Crypto - Card Authentication (Asymmetric) | Provides authentication of the Card and Cardholder by digitally signing a challenge request using the appropriate private key. | ||
Crypto - Digital Signature | Provides digital signature generation functionality on a pre-computed message digest.
| ||
Crypto - Key Establishment | Supports the establishment of a shared secret, which can then be used for further encryption operations. Modes of Key Establishment are:
| ||
Crypto - Secure Messaging | Provides an implementation of Opacity Zero-Key-Management (ZKM) which is then used to secure further communications with the card in environments where passive interception is possible (i.e. sniffing of RF modulation or serial communications). | ||
Other - Virtual Contact Interface | Supports the application state where a contactless interface is treated as a contact interface for the purposes of assessing Key and Data Object usage rights. This state is reached by the following two conditions being both met (or just the first condition if the card policy allows):
|
3 Extension Features
There are a number of essential functions that are not defined by SP 800-73, especially with regards to administrative management. This is likely a deliberate decision by NIST to ensure that vendors could capitalise on their own existing or novel methods of card and application management. OpenFIPS201 addresses these areas in a way that increases both the flexibility and security of the application and card administration.
Feature | Description and OpenFIPS201 Support | ||||
|---|---|---|---|---|---|
Secure Channel Administration | Permits card data objects, keys and configuration to be managed by an entity authenticated using a GlobalPlatform Secure Channel Protocol with command encryption (C-ENC) and integrity (C-MAC).
| ||||
Flexible Filesystem and Key Store (Pre-Personalisation) | To maintain a high level of flexibility, OpenFIPS201 deliberately does not define any data objects or key references. Instead, it provides a simple pre-personalisation command so these can be defined by your card/application management system. This permits any number of use cases where additional data objects, certificates or cryptographic keys are required for specific use cases. In fact, you can completely define your own file system that has nothing to do with PIV! The command interface for this is almost identical to the PIV ‘PUT DATA’ command to reduce integration requirements.
| ||||
Key Injection and PIN management | All asymmetric keys may be generated on-card as-per the PIV standard, however it is also possible to directly inject key values into the applet. This is useful if keys are archived, escrowed or simply generated from a HSM.
| ||||
PIN unblocking, PIN and PUK management | PIV provides a mechanism for PIN and PUK values to be changed, however OpenFIPS201 allows you to also remotely perform these operations under SCP to prevent interception of the PIN by a tampered host system or card reader. | ||||
PIN Extended Length | Supports PIN and PUK lengths up to 16 characters | ||||
PIN Extended Character Sets | Supports a number of additional character sets for PIN entry, including alpha-numeric (case sensitive or insensitive) and raw (any value). | ||||
PIN Complexity | Supports enforcing PIN complexity rules to prevent commonly known weak PIN patterns from being used. | ||||
PIN History | Supports preventing PIN values from being re-used by storing and checking against the last [n] cardholder PIN values set. | ||||
PUK Retry Limits | Supports preventing PUK brute-forcing by applying the configurable retry limits to PUK verifications. In the event that the PUK is blocked, it can only be unblocked over a secure administrative interface. | ||||
Dynamic Configuration | The applet contains a number of configuration parameters that govern behavior. Dynamic configuration permits these parameters to be changed post-issuance and without re-compiling the applet. | ||||
Delegated Administration | Permits off-line administration of the application by constructing card-specific commands that may be sent without establishing a real-time administrative channel. The commands it supports are:
| ||||
Status Reporting | The applet supports reporting of its current status. | ||||
Version Reporting | The applet supports reporting of its current version. |
...