[!IMPORTANT] This revision (and latest official release) of OpenFIPS201 is v1.10.2. Although this works fine for many people, it has not been updated for a while due to the work on the FIPS 140-3 certified v2.0.0 FIPS code base.

Once final feedback is received from NIST and our lab, we will formally release the v2.0.0 version (in both FIPS and NON-FIPS Approved modes as separate binaries). Note that the v2.0.1-jc304 branch is a patch to support JC3.0.4 cards and is not a later/better code base as the version # suggests.

Thank you for your patience and of course feel free to play around with the new version!

OpenFIPS201

This project has been commissioned and funded by the Australian Department of Defence, to provide an open source implementation of the card application for the NIST Personal Identity Verification (PIV) standard as specified by NIST FIPS PUB 201-2 and NIST SP 800-73-4.

OpenFIPS201 implements the following functionality:

• A flexible filesystem that can be defined easily without recompilation
• A flexible key store that defines key roles instead of hard-coding which key is used for what function
• It compiles to Javacard 3.0.4 as a minimum
• Secure personalisation over SCP w/CENC+CMAC using the CHANGE REFERENCE DATA and PUT DATA commands
• The following is out-of-scope at this time:
  • Virtual Contact Interface
  • Secure Messaging (Opacity)
  • Biometric On-Card Comparison (OCC)

To get started, please head on over to the OpenFIPS201 Wiki The latest binary release is: OpenFIPS201 v1.10.2

Want to get in touch?

Contact us at piv@makina.com.au if you want to talk about the project, or just to even say how you're using it!

To contact the author directly, email kim@makina.com.au

This project makes use of the following Open Source tools:

• Apache Ant by the Apache Foundation
• Ant-JavaCard by Martin Paljak
• Google Java Format by Google

---

UPDATE 31st August 2022 - OpenFIPS201 v1.10.2 Release

This is a bug-fix release for OpenFIPS201. The following bugs have been addressed:

Bugs

• OF-132 Applet doesn't install on JCardSim
• OF-130 Applet does not uninstall unless the package is also deleted
• OF-127 retriesContact and retriesContactless for PIN/PUK should be limited to 15
• OF-122 Applet does not permit contact and contactless retries to be the same value
• OF-119 RESET RETRY COUNTER not checking intermediate PUK value
• OF-118 Contactless intermediate retries incorrectly evaluated

Notes

• Access to the OpenFIPS201 JIRA is currently restricted, if you wish to have access please contact kim@openfips201.org.
• Documentation relating to OpenFIPS201 can be found here.
• Discussions have been enabled, we welcome any feedback you have or let us know how you're using OpenFIPS201!

---

UPDATE 4th April 2022 - OpenFIPS201 v1.10.0 Release

The latest revision of OpenFIPS201 is ready! Here are a few features and enhancements that have been added:

Documentation

• Documentation relating to OpenFIPS201 has now been moved here to a public Confluence instance, as the docs were outgrowing the GitHub wiki.
• Discussions has now been enabled, we welcome any feedback you have or let us know how you're using OpenFIPS201!

Dynamic Configuration

All FEATURE compilation constants are now gone and been replaced with a more extensive set of configuration registers for controlling aspects of applet behaviour. This means there is no longer a need to modify or build from source code in order to configure it.

All configuration elements can be updated either individually, or batched into a single command (using OPTIONAL ASN.1 elements). If you choose not to update the configuration, you can just use the default values that have all been defined to adhere to PIV, or if PIV doesn't specify something then sensible default values have been used.

Pre-Personalisation Interface

The PUT DATA ADMIN command has changed a bit due to dynamic configuration. The following BER-TLV structures are defined:

• Create Data Object
• Delete Data Object (Defined but not implemented)
• Create Key Command
• Delete Key (Defined but not implemented)
• Update Configuration
• Legacy Operation

Your current pre-perso will still work via the Legacy Operation, but you will not be able to take advantage of some of the extended features, notably dynamic configuration. We encourage you to migrate over to the new commands, which have been kept as similar as possible to ease the transition.

Bulk Pre-Personalisation

You can combine any number of the above pre-perso commands into the same APDU to reduce the command overheads of sending so many of them!

The command is identical to the normal PUT DATA ADMIN format, with the exception that you have an outer BER-TLV tag that contains a SEQUENCE OF individual commands.

You can also mix and match different kinds of updates in one (i.e. Keys, Data Objects and Config).

PIN Enhancements

The applet supports a number of additional useful enhancements to PIN functionality:

• PIN Extended Length - You can define PIN lengths up to 16 digits in dynamic configuration
• PIN Character Set - You can define PIN format requirements as either numeric, alpha numeric, alpha numeric (case insensitive) or raw (any byte value)
• PIN History - You can configure the applet to remember up to the last 12 PIN values that were changed and prevent the user from re-using them.
• PIN Complexity Rules - Two basic 'weak PIN' prevention rules have been added as optional parameters:
  • Sequence Rule - Allows you to prevent more than [n] consecutive digits from being used (for example, 123456).
  • Distinct Rule - Allows you to prevent more than [n] instances of the same character being used (for example, 111111).
• PUK Retry Limits - PUK retries can now be defined in the same way PIN retries are (including separate counters for the Contact and Contactless interface). If the PUK is locked, it can only be unlocked by an administrative role over SCP03.

<u>PIV Impacts:</u>

• Setting the PIN Extended Length feature above 8 or below 6 will cause the padding/length to no longer comply with SP 800-73.
• Setting the PIN Character Set to anything other than numeric will not work with any middleware that enforces numeric-only digits.
• PIN History and Complexity Rules should be transparent and simply result in an error condition that should be handled by PIV middleware / clients.

Dynamic Admin Keys

For each data object and asymmetric key, you can now optionally define which symmetric key is responsible for managing it. This gives you the capacity to give write / key generation access to targeted objects. This feature is optional and if you do not specify an admin key, objects will default to the9B key.

<u>PIV Impact</u>: PIV defaults to the 9B key as the administrative key, so to maintain compatibility, simply define this key or don't specify the key.

User Manageable Data Objects

For asymmetric keys and data objects, it is possible to now add the User Admin access mode privilege. If this is set, the data object can be written to, or the key generated as long as the access conditions for that card have been met. This can be separated for contact / contactless and the special 'always' access mode may not be paired with this.

This has been included to permit the possibility of lower security applications whereby it is useful for regularly-changing operational data to be managed on the card without the requirement for administrative keys. Of course if the thought of this horrifies you, do nothing to your pre-perso scripts and the functionality will stay disabled.

Optional Cryptographic Mechanisms

The applet now attempts to instantiate all the required cryptographic mechanisms, but if there are any that it can't this now only results in those corresponding mechanisms being disabled, not prevention of the entire applet install.

<u>PIV Impact:</u> None, provided the card is able to support at least one of the asymmetric key pair types.

Other

• The GlobalPlatform library now targets GP 2.2.1 instead of GP 2.1.1. This should not pose a problem for JC 3.0.4+ cards.
• The Admin key attribute has now been deprecated as it replaced by the adminKey option
• A Permit Mutual key attribute has been added for symmetric keys so it needs to be explicitly enabled. For legacy operations this attribute is automatically applied to maintain compatibility.
• The discovery object is generated at run-time instead of applet compilation now, so you can change configuration parameters and it will reflect correctly.
• `FEATURE_STRICT_APDU_CHA