BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

2 Overview: Concepts and Constructs

NIST PIV and digital identity SP 800-73-4
All changes in this version
first version loaded 2 Overview: Concepts and Constructs

Title

Overview: Concepts and Constructs

Control

SP 800-73-4 Parts 2 and 3 define two interfaces to an ICC that contains the PIV Card Application: a low- level card command interface (Part 2) and a high-level client API (Part 3).

The information processing concepts and data constructs on both interfaces are identical and may be referred to generically as the information processing concepts and data constructs on the PIV interfaces without specific reference to the client API or the card command interface.

The client API provides task-specific programmatic access to these concepts and constructs and the card command interface provides communication access to concepts and constructs. The client API is used by client applications using the PIV Card Application. The card command interface is used by software implementing the client API (middleware).

The client API is thought of as being at a higher level than the card command interface because access to a single entry point on the client API may cause multiple card commands to traverse the card command interface. In other words, it may require more than one card command on the card command interface to accomplish the task represented by a single call on an entry point of the client API.

The client API is a program execution, call/return style interface whereas the card command interface is a communication protocol, command/response style interface. Because of this difference, the representation of the PIV concepts and constructs as bits and bytes on the client API may be different from the representation of these same concepts and constructs on the card command interface.

2.1.1 Platform Requirements

The following are the requirements that the PIV Card Application places on the ICC platform on which it is implemented or installed:

+ global security status that includes the security status of a global cardholder PIN

+ application selection using a truncated Application Identifier (AID)

+ ability to reset the security status of an individual application

+ indication to applications as to which physical communication interface – contact versus contactless – is in use

+ support for the default selection of an application upon warm or cold reset

2.2 Namespaces of the PIV Card Application

AID, names, Tag-Length-Value (BER-TLV) tags [ISO8825] , ASN.1 Object Identifiers (OIDs) [ISO8824] and Proprietary Identifier eXtensions (PIXes) of the NIST Registered Application Provider IDentifier (RID) used on the PIV interfaces are specified in Part 1. Part 1 also specifies that all unspecified names, BER-TLV tags, OIDs, and values of algorithm identifiers, key references, and cryptographic mechanism identifiers, are reserved for future use. 2.3 Card Applications

Each command that appears on the card command interface shall be implemented by a card application that is resident on the ICC. The card command enables operations on and with the data objects to which the card application has access.

Each card application shall have a globally unique name called its Application Identifier (AID) [ISO7816 , Part 4]. Except for the default applications, access to the card commands and data objects of a card application shall be gained by selecting the card application using its application identifier. 2 The PIX of the AID shall contain an encoding of the version of the card application. The AID of the PIV Card Application is defined in Part 1.

The card application whose commands are currently being used is called the currently selected application .

2.3.1 Default Selected Card Application

The card platform shall support a default selected card application. In other words, there shall be a currently selected application immediately after a cold or warm reset. This card application is the default selected card application. The default card application may be the PIV Card Application, or it may be another card application.

2.4 Security Architecture

The security architecture of an ICC is the means by which the security policies governing access to each data object stored on the card are represented within the card.

These security policy representations are applied to all PIV card commands thereby ensuring that the prescribed data policies for the card applications are enforced.

The following subsections describe the security architecture of the PIV Card Application.

2.4.1 Access Control Rule

An access control rule shall consist of an access mode and a security condition . The access mode is an operation that can be performed on a data object. A security condition is a Boolean expression using variables called security statuses that are defined below.

According to an access control rule, the action described by the access mode can be performed on the data object if and only if the security condition evaluates to TRUE for the current values of the security statuses. If there is no access control rule with an access mode describing a particular action, then that action shall never be performed on the data object.

2.4.2 Security Status

Associated with each authenticable entity shall be a set of one or more Boolean variables, each called a security status indicator of the authenticable entity. Each security status indicator, in turn, is associated

2 Access to the default application, and its commands and objects, occurs immediately after a warm or cold card reset without an explicit SELECT command. with a credential that can be used to authenticate the entity. The security status indicator of an authenticable entity shall be TRUE if the credentials associated with the security status indicator of the authenticable entity have been authenticated and FALSE otherwise.

A successful execution of an authentication protocol shall set the security status indicator associated with the credential used in the protocol to TRUE. An aborted or failed execution of an authentication protocol shall set the security status indicator associated with the credential used in the protocol to FALSE.

As an example, the credentials associated with three security status indicators of the cardholder might be: PIN, fingerprint, and pairing code. Demonstration of knowledge of the PIN is the authentication protocol for the first security status indicator wherein the PIN is the credential. Comparison of the fingerprint template on the card with a fingerprint acquired from the cardholder is the authentication protocol for the second security status indicator wherein the fingerprint is the credential. Demonstration of knowledge of the pairing code is the authentication protocol for the third security status indicator wherein the pairing code is the credential. A security condition using these three security status indicators might be “pairing code AND (PIN OR fingerprint).”

A security status indicator shall be said to be a global security status indicator if it is not changed when the currently selected application changes from one application to another. In essence, when changing from one application to another, the global security status indicators shall remain unchanged.

A security status indicator is said to be an application security status indicator if it is set to FALSE when the currently selected application changes from one application to another. Every security status indicator is either a global security status indicator or an application security status indicator. The security status indicators associated with the PIV Card Application PIN, the PIN Unblocking Key (PUK), OCC, pairing code, and the PIV Card Application Administration Key are application security status indicators for the PIV Card Application, whereas the security status indicator associated with the Global PIN is a global security status indicator.

The term global security status refers to the set of all global security status indicators. The term application security status refers to the set of all application security status indicators for a specific application.

2.4.3 Authentication of an Individual

Knowledge of a PIN is the means by which an individual can be authenticated to the PIV Card Application.

The pairing code shall be exactly 8 bytes in length and the PIV Card Application PIN shall be between 6 and 8 bytes in length. If the actual length of PIV Card Application PIN is less than 8 bytes it shall be padded to 8 bytes with 'FF' when presented to the card command interface. The 'FF' padding bytes shall be appended to the actual value of the PIN. The bytes comprising the PIV Card Application PIN and pairing code shall be limited to values 0x30 – 0x39, the ASCII values for the decimal digits '0' – '9'. For example,

+ Actual PIV Card Application PIN: “123456” or '31 32 33 34 35 36'

+ Padded PIV Card Application PIN presented to the card command interface: '31 32 33 34 35 36 FF FF'

The PIV Card Application shall enforce the minimum length requirement of six bytes for the PIV Card Application PIN (i.e., shall verify that at least the first six bytes of the value presented to the card command interface are in the range 0x30 – 0x39) as well as the other formatting requirements specified in this section.

If the Global PIN is used by the PIV Card Application, then the above encoding, length, padding, and enforcement of minimum PIN length requirements for the PIV Card Application PIN shall apply to the Global PIN.

The PUK shall be 8 bytes in length, and may be any 8-byte binary value. That is, the bytes comprising the PUK may have any value in the range 0x00 – 0xFF.

2.5 Current State of the PIV Card Application

The elements of the current state of the PIV Card Application when the PIV Card Application is the currently selected application are described in Table 1 .

Table 1. State of the PIV Card Application

State Name Always Defined Comment Location of State Global security status Yes Contains security status indicators that span all card applications on the platform. PIV Platform

Currently selected application Yes The platform shall support the selection of a card application using the full application identifier or by providing the right- truncated version and there shall always be a currently selected application. PIV Platform

Application security status Yes Contains security status indicators local to the PIV Card Application. PIV Card Application