Applet Features
- Kim O'Sullivan
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
Â
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 |
|---|---|
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. This is the most common PIN usage scenario. |
Verification - Cardholder via Global PIN | Permits the cardholder to be verified by supplying a PIN which is maintained globally by the card issuer. This is useful when you wish to have a single PIN used across multiple applets on the same card and don’t wish to manage them separately. OpenFIPS201 is capable of using and managing (updating) global PIN values in GlobalPlatform. |
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. |
Card Management - Symmetric Key | Permits card data objects and keys to be managed by an entity in possession of an administrative symmetric key. This method of administrative authentication is not recommended except where legacy management systems are unable to support administration utilising Secure Channel Protocol. This is because the symmetric key authentication does not provide confidentiality or integrity checking of administrative commands! |
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 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
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.
ID | Name | NIST Status |
|---|---|---|
‘04’ | PIV Secure Messaging Key | Optional |
‘9A’ | PIV Authentication Key | Mandatory |
‘9B’ | PIV Card Application Administration Key | Optional |
'9C’ | Digital Signature Key | Mandatory1 |
'9D’ | Key Management Key | Mandatory1 |
'9E’ | Card Authentication Key | Mandatory2 |
'82’ | Retired Key Management Key 01 | Optional |
'83’ | Retired Key Management Key 02 | Optional |
'84’ | Retired Key Management Key 03 | Optional |
'85’ | Retired Key Management Key 04 | Optional |
'86’ | Retired Key Management Key 05 | Optional |
'87’ | Retired Key Management Key 06 | Optional |
'88’ | Retired Key Management Key 07 | Optional |
'89’ | Retired Key Management Key 08 | Optional |
'8A’ | Retired Key Management Key 09 | Optional |
'8B’ | Retired Key Management Key 10 | Optional |
'8C’ | Retired Key Management Key 11 | Optional |
'8D’ | Retired Key Management Key 12 | Optional |
'8E’ | Retired Key Management Key 13 | Optional |
'8F’ | Retired Key Management Key 14 | Optional |
'90’ | Retired Key Management Key 15 | Optional |
'91’ | Retired Key Management Key 16 | Optional |
'92’ | Retired Key Management Key 17 | Optional |
'93’ | Retired Key Management Key 18 | Optional |
'94’ | Retired Key Management Key 19 | Optional |
'95' | Retired Key Management Key 20 | Optional |
1 Mandatory only for U.S. deployments containing federal government-issued email address.
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.
ID | Name | NIST Status |
|---|---|---|
‘5FC107’ | Card Capability Container | Mandatory |
‘5FC102’ | Card Holder Unique Identifier | Mandatory |
‘5FC105’ | X.509 Certificate for PIV Authentication | Mandatory |
‘5FC103’ | Cardholder Fingerprints | Mandatory |
‘5FC106’ | Security Object | Mandatory |
‘5FC108’ | Cardholder Facial Image | Mandatory |
‘5FC101’ | X.509 Certificate for Card Authentication | Mandatory |
‘5FC10A’ | X.509 Certificate for Digital Signature | Mandatory1 |
‘5FC10B’ | X.509 Certificate for Key Management | Mandatory1 |
‘5FC109’ | Printed Information | Optional |
‘7E’ | Discovery Object | Optional |
‘5FC10C’ | Key History Object | Optional |
‘5FC10D’ | Retired X.509 Certificate for Key Management 1 | Optional |
‘5FC10E’ | Retired X.509 Certificate for Key Management 2 | Optional |
‘5FC10F’ | Retired X.509 Certificate for Key Management 3 | Optional |
‘5FC110’ | Retired X.509 Certificate for Key Management 4 | Optional |
‘5FC111’ | Retired X.509 Certificate for Key Management 5 | Optional |
‘5FC112’ | Retired X.509 Certificate for Key Management 6 | Optional |
‘5FC113’ | Retired X.509 Certificate for Key Management 7 | Optional |
‘5FC114’ | Retired X.509 Certificate for Key Management 8 | Optional |
‘5FC115’ | Retired X.509 Certificate for Key Management 9 | Optional |
‘5FC116’ | Retired X.509 Certificate for Key Management 10 | Optional |
‘5FC117’ | Retired X.509 Certificate for Key Management 11 | Optional |
‘5FC118’ | Retired X.509 Certificate for Key Management 12 | Optional |
‘5FC119’ | Retired X.509 Certificate for Key Management 13 | Optional |
‘5FC11A’ | Retired X.509 Certificate for Key Management 14 | Optional |
‘5FC11B’ | Retired X.509 Certificate for Key Management 15 | Optional |
‘5FC11C’ | Retired X.509 Certificate for Key Management 16 | Optional |
‘5FC11D’ | Retired X.509 Certificate for Key Management 17 | Optional |
‘5FC11E’ | Retired X.509 Certificate for Key Management 18 | Optional |
‘5FC11F’ | Retired X.509 Certificate for Key Management 19 | Optional |
‘5FC120’ | Retired X.509 Certificate for Key Management 20 | Optional |
‘5FC121’ | Cardholder Iris Images | Optional |
‘7F61’ | Biometric Information Templates Group Template | Optional |
‘5FC122’ | Secure Messaging Certificate Signer | Optional |
5FC123' | Pairing Code Reference Data Container | Optional |
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.
ID | Name | NIST Status | OpenFIPS201 Status |
|---|---|---|---|
‘00’ | Global PIN | Optional | Supported |
‘80’ | PIV Card Application PIN | Optional | Supported |
‘81’ | PIN Unblocking Key | Optional | Supported |
‘96’ | Primary Finger OCC | Optional | Not currently Supported |
‘97’ | Secondary Finger OCC | Optional | Not currently Supported |
‘98’ | Pairing Code | Optional | Supported |
Â