...

...

...

1. To provide a production quality implementation that can be openly used, shared and reviewed by the wider industry, in keeping with Kerkchoff's Principle.

2. To serve as a commonly shared reference between departments and organisations that wish to interoperate using FIPS-201 for logical and physical access control, both within the context of government departments and the industry at large (i.e. CIV).

3. To provide an openly described solution to the gaps in the PIV standard, particularly with regards to card management functions and personalisation.

4. To provide a foundation for the first fully accredited open source PIV implementation that will provide a high assurance alternative to commercial solutions on the market, operating on FIPS 140 accredited tokens with Javacard 3.0.4 and Global Platform 2.1.1 or above

5. To be accreditable against FIPS PUB 201 and SP 800-73 under the NIST NPIVP program.

Contents

Frequently Asked Questions

Q - What is FIPS PUB 201-2 and HSPD-12?

This answer is straight from the horses mouth:

...

• NIST FIPS 201-2 - Personal Identity Verification (PIV) of Federal Employees and Contractors

• NIST SP 800-73-4 - Interfaces for Personal Identity Verification

• NIST SP 800-78-4 - Cryptographic Algorithms and Key Sizes for Personal Identity Verification

Q - What is the PIV Card Application ?

The PIV Card Application is a contact and/or contactless ISO-7816 smart card applet, which provides a number of basic features:

• It contains a file system that allows reading and writing of a number of Data Objects (DO’s). It controls access to each DO using access control conditions, which require some form of authentication by either the cardholder or the Card Management System.

• It provides a number of verification mechanisms utilising PIN's, symmetric and asymmetric (PKI) algorithms to authenticate the cardholder

• It allows card authentication processes, digital signatures to be generated and also participates in key establishment mechanisms for encryption in-flight or at-rest.

• It provides a means to generate asymmetric keys on-card to provide high assurance, especially where digital signatures are involved

Q - What can I do with a PIV token ?

The PIV standard permits you to securely store PKI keys and use them with almost any PKI-compatible solution for Encryption, Digital Signatures, Authentication, Key Establishment, etc.

• Authentication - Allows you to provide multi-factor login support to your Microsoft Windows, Apple OSX or Linux computer / network. In addition to this, it can also be used to authenticate to:

  • Remote Control tools such as SSH, Microsoft RDP, VMWare, and Citrix

  • Multi-Function Devices such as Konica Minolta and Citrix to support follow-me printing and scanning.

• Encryption and Digital Signatures - Digitally protect documents and emails with PKI-compliant software such as Microsoft Office, Adobe Acrobat, Microsoft Outlook, and Mozilla Thunderbird.

• Integrate with Physical Access Control (PACS) systems for boundary protection.

Q - What doesn't this implementation do?

As of the accreditation release, although the biometric data objects exist, there is no support for biometric On-Card Comparison. Other than that, all mandatory and optional PIV features are implemented.

Q - Why aren't individual object field values and lengths validated?

There are a number of reasons:

1. It isn't practical to validate every object within the applet itself without considerably increasing the code size, while the card management system seems the logical place to have much more robust data validation.

2. With many PIV middleware/clients out there requiring backwards compatibility and differing interpretations of object requirements, there isn't a simple one-size-fits-all validation for every installation.

3. Some objects are candidates for GZip compression, which would then necessitate on-card deflation to validate

Q - Does this support PIV-I or CIV?

Most likely! It seems that PIV-I and CIV are just relaxed versions for the current PIV data object, security and access mode requirements. The flexibility built-in to OpenFIPS201 means that it should be fairly easy to create adapted versions to suit non-federal requirements.

Q - Will OpenFIPS201 be formally accredited?

Yes! OpenFIPS201 is currently in the preliminary stages of accreditation for FIPS 140-3.

Q - Can I contribute to this project?

Yes! Contributions to OpenFIPS201 are welcome, whether they be in the form of code improvements, tests, security audits or even just bug/feature reports. As this project has been developed on behalf of the Commonwealth of Australia, there are some conditions applied:

• Any contributions, submissions, suggested amendments or fixes will not be considered for adoption unless they are provided under the MIT license terms, or a similar permissive open source licence which does not place obligations or restrictions for use and modification of the licensed material.

• Changes will only be accepted if they are of sufficient quality and our team reserves the right to reject any submissions that don't meet our quality control processes.

• This project is intended for use in production and as such, changes that substantially deviate from the PIV standard may not be accepted (we want to keep the code-base clean). You are of course welcome to fork the project if you have grand ideas for a new direction!

PIV Concepts

Roles

There are a number of roles in the PIV scheme which are described below and referred to throughout the rest of the OpenFIPS201 documentation:

Card Issuer

The card issuer is the entity responsible for the issuance and management of PIV cards in a scheme. They typically perform the following tasks:

• Creation and configuration of PIV cards using the Token Management System (sometimes also called Card Management System)

• Confirming the identity of the cardholder prior for the purposes of requesting digital certificates

• Management of cardholder information (or at the very least that which is stored or physically printed on the card)

• Management of keys, data objects and verification data such as PIN, PUK and biometric templates

• Post-issuance management of the PIV card applet and data including re-issuance)

Card Holder

The card holder is the individual who is in physical possession of the card and whose identity is bound to keys, certificates and data on the card. They make use of the card functionality to perform cryptographic operations and (aside from changing the PIN value) typically have no ownership or management authority over the card. A cardholder is almost always an individual person (especially when digital signatures are involved), although in some cases it can refer to an organisation.

A cardholder verifies their authority to use the card by presenting the correct PIN for verification, which then permits the use of the private keys stored on the card.

Security Officer

The security officer is the role responsible for unlocking cards that have been blocked due to too many invalid PIN attempts being made. They are in possession of the PIN Unblocking Key (PUK), which when used with the PIV VERIFY card command will unlock and reset the cardholder PIN value. The ‘security officer’ role is often a system, rather than individuals and can include self-unlocking services where the PUK is remotely issued to the card.

Certificate Authority

The certificate authority is the trusted entity responsible for issuing all digital certificates stored on the card. Each private key must have an associated certificate which binds it to the named individual or organisation. They are also responsible for maintaining Certificate Revocation Lists to track invalidated key pairs (for instance, when a card is lost or the cardholder has left the organisation).

...

Pin Always

TBD describe PIN Always here