The following section provides a summary of the card application features implemented by OpenFIPS201, including those specified PIV card application standard [SP800-73-4] as well as extended (non-standard) functionality.
1 Contents
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
2 PIV Standard
The purpose of the PIV card application is to provide secure identification and cryptographic functionality at a variety of assurance levels. It provides functionality to support common PKI operations such as authentication, digital signatures and key establishment. Aside from this functionality, PIV contains a number of supporting data objects that include cardholder information and certificates.
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. |
4 Standard Cryptographic Mechanisms
| Info |
|---|
OpenFIPS201 detects which underlying cryptographic primitives are supported by the Javacard Runtime upon installation and so not all of these may be available for a given deployment. |
ID | Feature | Requirement | OpenFIPS201 Status | ||
|---|---|---|---|---|---|
‘00’ and ‘03’ | TDEA-192-ECB | Optional | Supported for Internal, External and Mutual Authentication operations | ||
‘08’ | AES-128-ECB | Optional | Supported for Internal, External and Mutual Authentication operations | ||
‘0A’ | AES-192-ECB | Optional | Supported for Internal, External and Mutual Authentication operations | ||
‘0C’ | AES-256-ECB | Optional | Supported for Internal, External and Mutual Authentication operations | ||
‘06’ | RSA-1024 | Optional | Supported for Key Transport, Digital Signature and Card Authentication operations
| ||
‘07’ | RSA-2048 | Optional | Supported for Key Transport, Digital Signature and Card Authentication operations | ||
‘11’ | ECC-P-256 | Optional | Supported for Key Agreement (ECDH), Digital Signature (ECCDSA) and Card Authentication (ECCDSA) operations | ||
‘14’ | ECC-P-384 | Optional | Supported for Key Agreement (ECDH), Digital Signature and Card Authentication (ECCDSA) operations | ||
‘27’ | Cipher Suite 2 | Optional | Supported for Secure Messaging | ||
'2E' | Cipher Suite 7 | Optional | Supported for Secure Messaging |
5 Standard Key Capabilities
All OpenFIPS201 keys are defined during pre-personalisation and so there is no hard requirement to have any keys. The provided NIST pre-personalisation profile complies with the keys below for all permitted mechanisms.
...
2 Only asymmetric key is mandatory, symmetric is optional.
6 Standard Data Object Capabilities
All OpenFIPS201 data objects are defined during pre-personalisation and so there is no hard requirement to have any keys. The provided NIST pre-personalisation profile specifies the data objects below according to the NIST specification, including permissions.
...
1 Mandatory only for U.S. deployments containing federal government-issued email address.
7 Cardholder Verification Methods
OpenFIPS201 verification methods are currently defined at compile-time. Whilst there is no flexibility to define custom methods, these can be enabled or disabled via applet configuration.
...