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.
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. 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! Although the TDEA-192 algorithm is supported, it is not recommended for any new deployments and is expected to be deprecated by 2023.
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). Although the TripleDES algorithm is supported for legacy reasons, it is deprecated and should not be used for any new deployments except for retired encryption keys.
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. Symmetric keys with administrative authority must never permit this operation as it can be used to arbitrarily generate encrypted values on behalf of other target cards.
Crypto - Client Authentication (Symmetric)	Supports one-way authentication of the Client to the Card using a challenge / response protocol. Permits administrative authentication. It is advised never to permit this mode of authentication as it is trivial for a hostile card to induce an administrative process to then leak sensitive security parameters, or encrypt an arbitrary nonce value which can then be used to authenticate to a second target card.
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. Keys with this functionality can (and should) make use of the PIN_ALWAYS attribute, which will require a PIN to be supplied each time a digital signature operation is requested. This is to prevent malicious actors from waiting until a cardholder is verified and then digitally signing arbitrary payloads without the knowledge of the cardholder.
Crypto - Key Establishment	Supports the establishment of a shared secret, which can then be used for further encryption operations. Modes of Key Establishment are: RSA Key Transport Elliptic Curve Diffie-Hellman
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): A Secure Messaging session key has been established between the client and the card. The pairing code has been transmitted to the card over a secure messaging interface.

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). 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. This functionality must be executed with administrative (issuer) rights. 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. 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	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.
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: PUT DATA ADMIN CHANGE REFERENCE DATA ADMIN
Status Reporting	The applet supports reporting of its current status.
Version Reporting	The applet supports reporting of its current version.

4 Standard Cryptographic Mechanisms

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 PIV mandates that no RSA-1024 key be used except for Key Transport of retired keys only. The provided NIST profile of OpenFIPS201 complies with this limitation.
‘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	Mandatory¹
'9D’	Key Management Key	Mandatory¹
'9E’	Card Authentication Key	Mandatory²
'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

¹ Mandatory only for U.S. deployments containing federal government-issued email address.

² 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	Mandatory¹
‘5FC10B’	X.509 Certificate for Key Management	Mandatory¹
‘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