NIST SP 800-85A-4 日本語訳

NIST Special Publication 800-85A-4

David Cooper

Hildegard Ferraiolo

Ramaswamy Chandramouli

Jason Mohler

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-85A-4

NIST Special Publication 800-85A-4

David Cooper

Hildegard Ferraiolo

Ramaswamy Chandramouli

Computer Security Division Information Technology Laboratory

Jason Mohler

Electrosoft Services, Inc. Reston, Virginia

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-85A-4

April 2016

U.S. Department of Commerce Penny Pritzker, Secretary

National Institute of Standards and Technology

Willie May, Under Secretary of Commerce for Standards and Technology and Director

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3541 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-85A-4 Natl. Inst. Stand. Technol. Spec. Publ. 800-85A-4, 153 pages (April 2016) CODEN: NSPUE2

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-85A-4

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at http://csrc.nist.gov/publications.

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: pivtesting@nist.gov

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security and its collaborative activities with industry, government, and academic organizations.

NIST Special Publication (SP) 800-73 contains the technical specifications to interface with the smart card to retrieve and use the Personal Identity Verification (PIV) identity credentials. This document, SP 800-85A, contains the test assertions and test procedures for testing smart card middleware as well as the card application. The tests reflect the design goals of interoperability and PIV Card functions.

application programming interface (API); authentication; card command interface; derived test requirements (DTR); FIPS 201; identity credential; middleware; Personal Identity Verification (PIV); smart cards; test assertions

The authors (David Cooper, Hildegard Ferraiolo Ramaswamy Chandramouli of NIST, and Jason Mohler of Electrosoft Services, Inc.) wish to thank their colleagues who reviewed drafts of this document and contributed to its development. The authors also gratefully acknowledge and appreciate the many contributions from the public and private sectors whose thoughtful and constructive comments improved the quality and accuracy of this publication.

Revision numbers between NIST Special Publications 800-73 and 800-85A were misaligned from the start because the initial publication of SP 800-85A did not occur until after the publication of SP 800-73 Revision 1 (SP 800-73-1). This resulted in versions of the two documents corresponding as follows: SP 800-73-1 with SP 800-85A; SP 800-73-2 with SP 800-85A-1 (i.e., Revision 1); and SP 800-73-3 with SP 800-85A-2.

This revision numbering mismatch created ongoing uncertainty and confusion regarding which revision of SP 800-85A was consistent with which revision of SP 800-73. To reduce this uncertainty going forward, revision number 3 has been skipped for SP 800-85A, and the present version of SP 800-85A has been given revision number 4 (SP 800-85A-4) since this version is consistent with the updates to SP 800-73 Revision 4 (SP 800-73-4). Future revisions of SPs 800-73 and 800-85A will maintain the revision number consistency.

Federal Information Processing Standard 201, Personal Identity Verification (PIV) of Federal Employees and Contractors [FIPS 201], was developed to establish standards for identity credentials. FIPS 201 sets the minimum requirements for a federal personal identification system that meets the control and security objectives of Homeland Security Presidential Directive (HSPD) 12 [HSPD 12]. FIPS 201 also gives the technical specifications of components and processes required for the interoperability of PIV Cards¹ with the access control and PIV card management systems throughout the Federal Government. FIPS 201 is accompanied by three documents:

+ NIST Special Publication 800-73-4 (NIST SP 800-73-4) [SP 800-73] specifies interface requirements for retrieving and using the identity credentials from the PIV Card. It also defines a PIV data model, which details the structure and format of the information stored on the PIV Card.

+ NIST SP 800-76-2 [SP 800-76] contains technical specifications for biometric data mandated in FIPS 201.

+ NIST SP 800-78-4 [SP 800-78] specifies the cryptographic algorithms and key sizes for performing cryptographic operations on PIV data objects defined as part of the PIV data model.

This test guidance document specifies the test plan, processes, derived test requirements, and the detailed test assertions/conformance tests for testing the following PIV software components:

+ PIV Middleware (implements PIV Client API).

+ PIV Card Application.

The present document, SP 800-85A-4, supersedes SP 800-85A-2 in its entirety, effective immediately upon publication.

The objective of this document is to provide test requirements and test assertions that could be used to validate the compliance/conformance of two PIV components – PIV Middleware and PIV Card Applications – with the specifications in NIST SP 800-73-4. Because NIST SP 800-73-4 specifications were developed for meeting interoperability goals of FIPS 201, the conformance tests in this document provide the assurance that the set of PIV Middleware and PIV Card Applications that have passed these tests are interoperable. This in turn facilitates procurement of FIPS 201-conformant products that meet the goals of HSPD-12.

This document provides guidelines for running conformance tests for the following three classes of specifications in NIST SP 800-73-4:

+ PIV Data Objects Representation (Section 4, Part 1 of SP 800-73-4) and Data Types and Their Representation (Section 5, Part 1 of SP 800-73-4). + PIV Card Application Card Command Interface (Part 2 of SP 800-73-4). + PIV Client Application Programming Interface (Part 3 of SP 800-73-4). The functions specified in the Client API are to be supported by PIV Middleware. The commands specified in the PIV Card Application Card Command Interface are to be supported by PIV Card Applications, with appropriate security conditions for executing each command and for accessing/storing each of the data objects associated with the application. The overall design of the commands has to be based on the concepts outlined in NIST SP 800-73-4 Part 2, Section 2 - Concepts and Constructs. The presence of mandatory data objects on the PIV Card has to be verified. The data objects associated with PIV Card Application have to be tested for their accessibility and storage using the specified identifiers. Thus, the three classes of specifications listed above span the following two main PIV components: PIV Middleware and PIV Card Application. Hence the test suite provided in this document consists of the following two broad categories of tests: + PIV Middleware tests. + PIV Card Application tests. The above tests are developed through the following two-step process: + Derived Test Requirements (DTR). These are constructed from the ‘shall’ statements in SP 800-73-4 specifications. + Test Assertions. These provide the tests that need to be performed to test each of the requirements under DTRs as well as tests with appropriate execution conditions for each of the commands in the interface to realize the associated return/response status codes specified in SP 800-73-4 Part 2. This document does not provide conformance tests for any other software used in the PIV system such as the back-end access control software, card issuance software, card reader/biometric reader drivers, and specialized service provider software such as cryptographic service provider modules and biometric service provider modules. This document does not address nor provide conformance tests for SP 800-76-2.

This document is intended to:

+ Enable developers of PIV Middleware and PIV Card Applications to develop their software modules to be testable for interface requirements specified in SP 800-73-4.

+ Enable developers of PIV Middleware and PIV Card Applications to develop self-tests as part of the development effort.

+ Enable testing laboratories authorized to perform conformance tests on PIV Middleware and PIV Card Applications to develop tests that cover the test suite provided in this document.

The document is organized as follows:

+ Section 2 provides a conceptual software overview of a typical PIV system and introduces the PIV test components.

+ Section 3 lists the various elements of the test suite under the two broad categories of tests (PIV Middleware tests and PIV Card Application tests) provided in this document.

+ Section 4 provides an overview of the DTR construction process.

+ Section 5 gives a brief description of the test assertion for each of the three specification classes covered by this document (refer to Section 1.3).

+ Section 6 explains the documentation required from both the component owners and test labs for conducting the testing process.

+ Section 7 details the acceptance criteria for each type of test.

+ Section 8 explains the test compliance process and failure review.

+ Appendix A includes DTRs based on specifications in SP 800-73-4.

+ Appendix B includes client application programming interface (API) test assertions.

+ Appendix C includes PIV Card command interface test assertions.

+ Appendix D contains a list of acronyms used in the document.

+ Appendix E contains the list of documents used as references by this document.

The conceptual architecture involving the PIV Middleware and PIV Card Application for which conformance tests are given in this document is shown in Figure 1. The conformance tests in this document apply to the areas highlighted with dashed lines in Figure 1.

Figure 1: PIV Conformance Test Architecture

+ PIV Middleware is a software application that is the interface between an agency’s PIV implementation and the PIV Card Application. It allows the agency’s applications to remain independent of the underlying operating system platform. The PIV Middleware has the following two functions:

The PIV Card Application resides on the card, implements the commands in the PIV Card Command Interface (Part 2 of SP 800-73-4), and provides access to objects of the PIV data model. The PIV data model defines the logical use of the on-card application space including the SP 800-73-4 Part 1 required data objects and data elements, along with the size and structure of each object.

The test plan identifies the tasks/artifacts required for testing the PIV Middleware and PIV Card Applications. These artifacts include the following: PIV Middleware and a smart card populated with a PIV Card Application; the test toolkit (or test scripts), which implements the test assertions; and the various infrastructure devices needed to interface with the card and the card reader. The components involved in the test plan and the elements of the test configuration for the two broad categories of tests presented in this document are discussed in the next two subsections.

The test system consists of the following components:²

or

These components will be used in different configurations based on the type of test being conducted in the test bed.

The test system shown in Figure 2 will be configured in both the PIV Middleware tests and the PIV Card Application tests to accommodate the different components to be tested, as explained in Section 3.

Figure 2: Test System Configuration

The middleware test configuration is used to test a vendor’s middleware software application that implements the PIV client API and generates the appropriate commands in the PIV card command interface (refer to Table A-1 for mapping between the client API and card command interface). The middleware test configuration is depicted in Figure 3.

Figure 3: Middleware Test Configuration

The following list shows the test system components included in this configuration:

+ Test toolkit application software.

+ Vendor provided PIV Middleware, which is the subject of this test (also called the implementation under test or IUT) and

One of the following combinations:

+ Contact and contactless smart card readers or a dual interface reader together with

+ A PIN input mechanism together with

+ A dual interface FIPS 201 conformant PIV Card loaded with “SP 800-73-4 Part 2 conformant PIV Card Application” (Refer to Section 7.2 for definition).

or

+ A PIV card emulator that emulates the behavior of a PIV Card Application.

The test toolkit application software resides on the test computer and facilitates the execution and management of both test suites explained in Section 3. For the PIV Middleware Test, the test system (Figure 2) will be configured so that the vendor provided PIV Middleware under test is also installed on the test computer and interacts with the SP 800-73-4 conformant test cards via the card reader(s).

The card application test configuration is used to test any PIV Card Application through commands of the PIV card command interface defined in SP 800-73-4 Part 2. The following list shows the test system components included in this configuration:

For the PIV Card Application Test, the test system shown in Figure 2 will be configured such that the test toolkit application software directly interacts with the PIV Card under test via the card reader(s). The PIV Card Application Test configuration is depicted in Figure 4.

Figure 4: PIV Card Application Test Configuration

Based on the conceptual software architecture shown in Figure 1, the PIV software components that are subject to testing are as follows:

These tests will validate that the PIV Middleware conforms to the specification in Part 3 of SP 800-73-4. Conformance criteria include correct implementation of the functions for the PIV client API, generation of appropriate commands for the PIV card command interface to communicate with the PIV Card Application, and return of the prescribed response codes to the calling agency application. This test, however, does not validate the functional requirements or the testing of the FIPS 201-mandated card application parameters, which are covered under the PIV data model tests as specified in SP 800-85B.

The following PIV Middleware functions are tested for conformance of the PIV Middleware without support for secure messaging (SM) and the virtual contact interface (VCI):

For PIV Middleware with support for SM and VCI, the following additional PIV Middleware function is tested for conformance:

These functions will be tested for their response to both the valid and the error conditions as defined by this document. To conduct these tests, a smart card with an “SP 800-73-4-conformant PIV Card Application” (refer to Section 7.2 for definition) must be accessible.

PIV Card Application tests cover the following:

+ The PIV Card Application card command interface as per Part 2 of SP 800-73-4, including the security conditions for executing each command in the interface as well as the security conditions for accessing and storing each of the associated data objects.

+ Presence of all mandatory data objects as well as accessibility and storage of all implemented data objects using the identifiers specified in Part 1 of SP 800-73-4.

The tests are performed through test scripts communicating directly with a PIV Card through the API of the driver that comes with the card reader.

These tests will validate that the card under test can successfully execute the commands in the PIV card command interface. Successful execution constitutes the card responding with appropriate data and response status codes to the commands sent by the test system. It also involves setting state variables within the PIV Card. For example, the criteria for successful execution of the SELECT command involve the following:

+ The response status code returned is '90 00'.

+ The application property template is returned with the correct format and content.

+ The “PIV Card Application” is the value of “currently selected application” (state variable) on the card.

The card command interface test suite includes conformance tests for the following PIV Card Application commands:

The card edge commands will be validated against the following conditions:

The testing covers the following data objects:

The data objects will be validated for the following conditions:

+ Security condition for data objects storage (cryptographic authentication). + Appropriate card interface type for accessing each of the data objects (contact vs. contactless vs. secure messaging vs. virtual contact interface).

DTRs show the type of tests required based on the specifications in SP 800-73-4. These specifications cover expected command behavior (in the case of interface specification), data object representation (in the case of PIV data model) and data contents (in the case of PIV authentication use cases).

Each DTR consists of the following:

+ Actual condition statements taken/derived from the SP 800-73-4 specification – these include conditions for successful command execution for each command as well as exception behaviors explicitly called out through ‘shall’ statements in SP 800-73-4. Those exception behaviors that are implicit in SP 800-73-4 through listing of error codes associated with each command are tested only through Test Assertions (Appendices B, C and D) and are not part of the DTR condition statements. The condition statements are identified by codes starting with ‘AS’ followed by a running sequence that denotes the section in this document where they occur. All DTRs that are new to Revision 4 of this document are identified by the suffix ‘-R4’. Updated DTRs that existed previously are requirements updated in SP 800-73-4 and these retain their original identifiers.

+ Required Vendor Information – these include information that the vendors are mandated to provide in their documentation. The required vendor information is identified by codes starting with ‘VE’ followed by a running sequence that denotes the section in this document where they occur. All vendor information requirements that are new to Revision 4 of this document are identified by the suffix ‘-R4’. Updated required vendor information that existed previously are requirements updated in SP 800-73-4 and these retain their original identifiers.

+ Required Test Procedures – these are actions that the tester has to perform in order to satisfy the requirements stated in actual condition statements. These include verifying the information mandated in the “Required Vendor Information” for the condition as well as performing software-based tests. It must be mentioned, however, that some of the required test procedures will not be called out explicitly for verification of information in the associated “Required Vendor Information.” In these instances, it is implicitly assumed that the information is provided by the vendor and verified by the tester. The Required Test Procedures have identifiers starting with ‘TE’ followed by a running sequence that denotes the section in this document where they occur. All test procedure requirements that are new to Revision 4 of this document are identified by the suffix ‘-R4’. Updated required test procedures that existed previously are requirements updated in SP 800-73-4 and these retain their original identifiers.

Validations of some DTRs are not covered by the test assertions provided in this document. These DTRs require compliance of the component with an external specification or standard such as ISO/IEC 7816 or ISO/IEC 14443. No required test procedures are provided for these DTRs, and a note is added to indicate that the assertion is externally tested. The tester checks the vendor documentation for claimed compliance with such requirement or the presence of an external test/compliance certificate obtained from the related standards testing body, when applicable.

Some DTRs cannot be validated through the test tools provided in this document. For example, the test tool cannot access the asymmetric private keys generated and stored on the card. Therefore, a note is added to indicate the assertion is not separately tested for these DTRs. The same note is added for DTRs that make general statements on the nature of the PIV Card and are validated as a result of the validation of many other DTRs. For example, the statement “[e]ach command that appears on the card command interface shall be implemented by a card application that is resident on the ICC [integrated circuit card]” is validated through the entire card command interface test and does not require an individual test assertion.

Test assertions are statements of behavior, action, or condition that can be measured or tested. They provide the procedures to guide the tester in executing and managing the test. They include the purpose of the test, starting conditions and prerequisites, success criteria, and post-test conditions, when applicable. A list of test assertions can be seen in Appendices B and C.

The following three sets of test assertions are included in this document:

An overview of each of the above classes of test assertions is given in Sections 5.2 through 5.4.

All the DTRs in Appendix A conceptually come under one of the two broad categories of tests stated in Section 3, i.e., PIV Middleware tests and PIV Card Application tests. Similarly, each test assertion makes specific references to the related sections in SP 800-73-4 or the related DTRs. However, overall there is a many-to-many mapping from the test suite elements (individual tests) under each of these two broad categories of tests to the DTRs (i.e., one test can map to many DTRs and one DTR can map to many tests). A similar type of relationship exists between DTRs and test assertions. To narrow the search space for cross references, Table 5-1 presents a cross-referencing guide showing the relevant DTR sections (with the section in SP 800-73-4 from which they were derived) and test assertion sections with respect to test classes in the two broad categories of tests.

Table 5-1: Cross-referencing Guide

This section provides conformance tests in the form of test assertions for the functions specified in Section 3, SP 800-73-4 Part 3 (referred to as the client API) that the PIV Middleware is expected to support. The test assertions are described through a test assertions template. The template provides placeholders for describing the purpose of the test, the preconditions required to exercise the test, the parameter values used in test invocation, and the expected results as well as the state of the PIV system (value of state variables), if any, that will be affected by the test run (post-condition).

The conformance tests are run against the PIV Middleware, which in turn interacts with the PIV Card Application resident on the PIV Card. Hence, there are two pieces of software (PIV Middleware and PIV Card Application) that determine the outcome of each test run. Because the focus of the tests is the behavior of the PIV Middleware, the test configuration assumes the presence of a validated PIV Card Application.

The test assertions derived from SP 800-73-4 and SP 800-78-4 are demonstrated by test cases in Appendix B.

The PIV client API test cases are based on the following assumptions:

+ There is a PIV Card with a validated PIV Card Application.

+ A valid connection description is provided for the PIV Card Application.

+ A valid physical connection exists between an instance of the PIV card reader and the host where the PIV Middleware resides.

+ No other application is currently connected to the PIV Card Application.

This section provides conformance tests in the form of test assertions for the command set that is specified in Section 3, Part 2 of SP 800-73-4 (PIV Card Application Card Command Interface) that the PIV Card Application is required to support. The test assertions are described through a test assertions template. The template provides placeholders for describing the purpose of the test, the preconditions required to exercise the test, the parameter values used in test invocation, and the expected results as well as the state of the PIV system (value of state variables), if any, that will be affected by the test run (post-condition).

The conformance tests are run to validate the PIV Card Application. Interaction with the PIV Card Application takes place through the API of the driver that comes with the card reader.

The test assertions derived from SP 800-73-4 Part 2 are demonstrated in test cases in Appendix C.

The following assumptions have been made with regard to the PIV Card command interface test cases:

+ The PIV Card being tested (IUT) is inserted into the contact reader or placed near a contactless reader.

+ A valid PC/SC connection exists between the test system and an instance of the reader.

+ No application is currently connected to the PIV Card Application.

+ No other contactless card is within the proximity of the contactless reader.

The following assumptions have been made with respect to the PIV data object representation test assertions:

+ A PIV Card Application with a valid Application Identifier (AID) is resident on the card.

+ The PIV Card Application is expected to have implemented all seven mandatory PIV data objects of the PIV data model on the card.

+ The PIV Card Application is expected to have implemented both conditionally mandatory PIV data objects³ of the PIV data model on the card.

+ The presence of any one or more of the twenty-seven optional PIV data objects on the PIV Card is known from the vendor documentation.

There are two sets of compliance documentation: vendor required and test facility generated.

The vendor-required documents consist of the following:

+ Installation and Execution instructions (for PIV Middleware): The vendor provides technical instructions and other documentation to aid the testing personnel in installing and using the PIV Middleware implementation under test. The PIV Middleware implementation could be in any high-level programming language. Since all the implementations have to be tested from a common test program, the PIV Middleware vendor submitting the product for testing may have to provide Java wrapper programs in some cases to the test facility. The purpose of the wrapper program is to translate the test execution calls made using the test program to the PIV Middleware implementation’s native program calls.

+ Technical documentation (for both PIV Card Application and PIV Middleware): The vendor-supplied technical documentation must include the detailed technical description and the design of the implementation to be tested. This document includes, at a minimum, all the required vendor information specified in DTRs in Appendix A of this document.

+ Security-related information: The following security related information shall be provided by the vendor: (a) PIV Card Application PIN, (b) PIN Unblocking Key (PUK), (c) Global PIN, (d) pairing code, (e) cryptographic algorithms supported by the card, (f) minutia data, and (g) the number of unsuccessful attempts using (1) wrong PIV Card Application PIN, (2) wrong Global PIN, (3) wrong PUK, (4) and wrong minutia data.

The test facility-generated documents are required for performing and reporting the test process. The following are some of the examples:

+ Checklists: Checklists provide the tester with a list of actions and requirements to complete before the test starts. Information required in the preconditions section of the assertions is included in the checklists.

+ Test logs: A test log is kept for each test run on any component and is used to summarize the results of all the tests run.

+ Test reports: These provide the background (environmental information) for each of the test cases as well as summary of outcomes from test runs (from test logs) associated with each test case.

A test case is a sequence of command/function invocations that pertain to a given execution condition for the ‘command/function under test’. For example, if the GET DATA command is the command/function under test, then the execution condition ‘Invocation of this function after PIN verification’ will consist of the following sequence of command/function invocations – SELECT, VERIFY, GET DATA, and collectively constitutes a test case. There may be many test runs for this test case. The function invocations returning the expected return codes for a test case in all test runs indicate that the command/function has been implemented correctly.

Acceptance criteria are based on the compliance of the item under the test with the requirements defined in FIPS 201 and the accompanying special publication documents. The criteria are further specified in the following sections, based on the type of test being conducted.

The PIV Middleware test acceptance criteria will be based on the middleware application under the test passing the SP 800-73-4 client API test assertions. The middleware should return appropriate return codes in response to executing the client API functions as defined in Section 3, Part 3 of SP 800-73-4. The middleware should also be able to send the correct card commands to and interpret the responses received from the “SP 800-73-4 conformant PIV Card Application” (refer to Section 7.2 for definition). The test assertions detail the pass/fail criteria defined for each test case that is designed to test a certain condition being tested.

PIV Middleware that supports the SP 800-73-4 client API with SM will be required to test against both the SP 800-73-4 client API test assertions and the SP 800-73-4 client API with SM test assertions. All SP 800-73-4 client API with SM test assertions are to be conducted over a contactless interface.

Acceptance criteria for the PIV Card Application tests are based on the PIV Card Application passing the following two classes of tests: PIV Card Application card command interface tests and PIV data objects accessibility and storage tests. The PIV Card Application that has passed these classes of tests is called an “SP 800-73-4 conformant PIV Card Application.”

For PIV Card Application card command tests, the PIV Card Application should send the appropriate response status codes and application data in response to commands. It should also set or reset certain card state variables and thus fulfill the test postconditions.

For the PIV data objects accessibility and storage tests, the PIV Card Application should show the presence of all mandatory PIV data objects and published optional PIV data objects. It should also demonstrate the ability to access and store all the above data objects using the correct BER-TLV tag under the appropriate security conditions and interfaces (contact, contactless, secure messaging, or VCI) and that the containers for storing them satisfy the specified minimum size requirements.

The acceptance criteria for the testing of PIV Card functionalities, for which FIPS 201 makes reference to external documents (such as digital signature formats), is based on visual verification of vendor-provided documents and test/compliance certificates.

The PIV software component that passes all applicable tests, as explained in this document, will be considered conformant. This document provides the technical details for the testing of the two PIV software components. In this context, compliance means: + Passing the related test assertions explained in this document, and + Passing the inspection/verification of the required vendor documentation. The certified and/or accredited test laboratory that will conduct the testing has the following responsibilities: + Prepare and provide the test application forms and the documentation, + Receive and configure the PIV software component to be tested, + Conduct the test with the testing toolkit, + Review the test results and report failures, + Inspect the vendor documentation, and + Communicate the results. Upon vendor’s submission of the request for PIV component certification, the required documentation, and the PIV software components to be tested, the test laboratory configures the test system, records all preconditions, and runs the applicable suite of tests for the submitted PIV component. After conducting the tests, the test laboratory evaluates the test results and communicates the Test Results Summary (TRS) and Test Run Details (TRD) to the vendor. The Test Results Summary provides the overall environmental information (date and time the tests were conducted, the tester name, vendor product identifier, etc.) as well as the summary conclusion for tests associated with that particular class. The format of the summary report will vary depending upon the test classes. The TRS associated with each of the three classes are: + PIV Client API Test Summary. + Card Command Interface Test Summary. + PIV Data Objects Accessibility and Storage Test Summary. The TRDs are used to log the details of each test run associated with each of the three classes in the test suite. They provide the details of the outcome of each test run for various execution conditions. This detailed report will enable the product vendor to make the necessary logic changes to the implementation of the various commands/interfaces and data object representations in order to become fully conformant.

The test will be repeated once for components that do not pass the tests. After the retest, the tester prepares, for each failure, a discrepancy report that summarizes the purpose of the test, the progression of steps, and the responses received from the tested components. The discrepancy report will be internally reviewed and discussed by the test lab before an official response is sent to the vendor. Vendors who object to the results presented in the discrepancy report must explain their reason for the objection. If the reason necessitates another retest, the test laboratory may consider repeating the test. Otherwise, the test lab will seek the guidance of the NIST personnel on the failure before the component is returned to the vendor to be corrected.

All DTRs that are new to Revision 4 of this document are new requirements introduced in SP 800-73-4. These are referenced with the suffix -R4 (e.g., AS0X-R4). Updated DTRs that existed previously are requirements updated in SP 800-73-4 and these retain their original identifiers.

AS01.01: The PIV Card Application shall place the following requirements on the ICC platform on which it is implemented or installed:

Note: This assertion is not separately tested.

AS01.02: Each command that appears on the card command interface shall be implemented by a card application that is resident on the ICC.

Note: This assertion is not separately tested – collection of DTRs for all commands implicitly tests this assertion.

AS01.03: Each card application shall have a globally unique name called its Application Identifier (AID) [ISO/IEC 7816, Part 4].

Note: This assertion is tested as part of AS05.05 through AS05.10.

AS01.04: 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.

Note: This assertion is tested as part of AS05.11.

AS01.05: The Proprietary Identifier eXtension (PIX) of the AID shall contain an encoding of the version of the card application.

Note: This assertion is tested as part of the AS05.05 through AS05.10.

A.1.2.1 Personal Identity Verification Card Application

AS01.06: The AID of the PIV Card Application shall be: 'A0 00 00 03 08 00 00 10 00 01 00'.

Note: This assertion is tested as part of the AS05.05 through AS05.10.

AS01.07: The AID of the PIV Card Application shall consist of the NIST Registered application provider IDentifier (RID) 'A0 00 00 03 08' followed by the application portion of the NIST PIX indicating the PIV Card Application '00 00 10 00' and then the version portion of the NIST PIX '01 00' for the first version of the PIV Card Application.

Note: This assertion is tested as part of the AS05.05 through AS05.10.

A.1.2.2 Default Selected Card Application

AS01.08: 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.

Required Vendor Information

VE01.08.01: The vendor shall specify in its documentation the default selected card application.

Required Test Procedures

TE01.08.01: The tester shall review the vendor’s documentation and validate that there is a default selected card application, which matches with the one specified by the vendor in VE01.08.01.

A.1.3.1 Access Control Rule

AS01.09: An access control rule shall consist of an access mode and a security condition.

Note: This assertion is not separately tested.

AS01.10: 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.

Note: This assertion is not separately tested.

AS01.11: 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.

Note: This assertion is not separately tested.

A.1.3.2 Security Status

AS01.12: 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.

Note: The security status indicators are tested indirectly through the functional testing.

AS01.13: 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.

Note: The security status indicators are tested indirectly through the functional testing.

AS01.14: A successful execution of an authentication protocol shall set the security status indicator associated with the credential used in the protocol to TRUE.

Note: The security status indicators are tested indirectly through the functional testing.

AS01.14A-R4: 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.

Note: The security status indicators are tested indirectly through the functional testing.

AS01.15: 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.

Note: This assertion is not separately tested.

AS01.16: 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.

Required Vendor Information

VE01.16.01: The vendor shall specify in its documentation that the application security status indicators are set to FALSE when the currently selected application changes from one application to another.

Required Test Procedures

TE01.16.01: The tester shall review the vendor’s documentation and validate that it contains the requirement stated in VE01.16.01.

AS01.16A-R4: 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.

Required Vendor Information

VE01.16A-R4.01: The vendor shall specify in its documentation that 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.

Required Test Procedures

TE01.16A-R4.01: The tester shall review the vendor’s documentation and validate that it contains the requirement stated in VE01.16A-R4.01.

A.1.3.3 Authentication of an Individual

AS01.17: 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.

Note: This assertion is tested as part of AS05.22A.

AS01.18: 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.

Note: This assertion is tested as part of AS05.22A.

AS01.18A-R4: 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'.

Note: This assertion is tested as part of AS05.22A.

AS01.18B-R4: 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 Section 2.4.3 of Part 2 of SP 800-73-4.

Note: This assertion is tested as part of AS05.22A.

AS01.18C-R4: 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 0x00 – 0xFF.

Note: This assertion is tested as part of AS05.22A.

AS01.18D-R4: 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.

Note: This assertion is tested as part of AS05.22A.

AS01.19: The state of the PIV Card Application shall be as follows, when the PIV Card Application is the currently selected application:

Note: This assertion is not separately tested.

AS01.20: Both single-chip/dual-interface and dual-chip implementations are acceptable.

Note: This assertion is not separately tested.

AS01.21: In the single-chip/dual-interface configuration, the PIV Card Application shall be provided the information regarding which interface is in use.

Required Vendor Information

VE01.21.01: The card operating system should inform the PIV Card Application the communication interface in use.

Required Test Procedures

TE01.21.01: The tester shall validate that the card platform informs the PIV Card Application of the interface being used.

Note: This assertion is not separately tested. This assertion is indirectly tested by verifying whether the card application returns an appropriate error response code for those commands that cannot be exercised through contactless interface. The tester shall verify an appropriate response code is returned.

TE01.21.02: The tester shall validate that the PIV Card Application checks that a contact interface is being used for contact-only APDUs.

Note: This assertion is not separately tested. This assertion is indirectly tested by verifying whether the card application returns an appropriate error response code for those commands that cannot be exercised through contactless interface when VCI is not in use and the commands are not contact only commands.

AS01.22: In the dual-chip configuration, a separate PIV Card Application shall be loaded on each chip.

Note: This assertion is not separately tested.

AS02.01: A PIV Card Application shall contain seven mandatory interoperable data objects, two conditionally mandatory data objects (if the cardholder has a government-issued email account at time of credential issuance) and twenty-seven optional data objects for interoperable use.

Note: This assertion is not separately tested.

AS02.02: For the purpose of constructing PIV Card Application data object names in the CardApplicationURL in the Card Capability Container of the PIV Card Application, the NIST RID ('A0 00 00 03 08') shall be used and the card application type shall be set to '00'.

Note: This assertion is not separately tested as it is being deprecated.

AS02.03: For all data objects present on the card, the object identifiers (OIDs) used by PIV Middleware to refer to them, and associated BER-TLV tags used by PIV Card Application command interface shall conform to the entries in Table 3, Part 1 of SP 800-73-4.

Required Vendor Information

VE02.03.01: The vendor shall state in its documentation the list of all the data objects present on the card along with the BER-TLV tags associated with them.

VE02.03.01A: The vendor shall state in its documentation the list of all OIDs used by the PIV Middleware to refer to PIV data objects and the associated BER-TLV tags to which they refer.

Required Test Procedures

TE02.03.01: The tester shall validate that the BER-TLV tags of all the data objects present on the card conform to the Table 3, Part 1 of SP 800-73-4, and accurately represent the actual data objects observed by the tester as being implemented on the card.

TE02.03.01A: The tester shall validate that all of the OIDs in Table 3, Part 1 of SP 800-73-4 can be used to read PIV data objects from a PIV Card using the pivGetData function.

AS03.01: The algorithm identifiers for the cryptographic algorithms implemented on the card shall conform to entries in Table 6-2 of SP 800-78-4.

Required Vendor Information

VE03.01.01: The vendor shall state in its documentation the identifiers associated with all the algorithms supported by the card.

Required Test Procedures

TE03.01.01: The tester shall review the vendor’s documentation and validate the algorithm identifiers implemented on the card as being compliant with Tables 6-2 and 6-3 of SP 800-78-4.

AS03.02: Upon selection, the PIV Card Application shall return the application property template described in Table 3, Part 2 of SP 800-73-4.

Required Test Procedures

TE03.02.01: The tester shall validate that the information returned upon selection of the PIV application is in conformance with Table 3, Part 2 of SP 800-73-4.

AS03.03: The authenticator BER-TLV used on the PIV client application programming interface shall have the structure described in Table 3, Part 3 of SP 800-73-4.

Required Vendor Information

VE03.03.01: The vendor shall provide in its documentation a list of all the authenticators along with their tags and possible values, when applicable.

Required Test Procedures

TE03.03.01: The tester shall review and validate the vendor’s documentation to ensure that it states the correct tags for the “Reference Data” and “Key Reference” as specified in Table 3, Part 3 of SP 800-73-4.

AS03.04: Moved to Appendix A.4.1.1 (AS04.02A-R4).

AS03.05: Withdrawn

AS03.06: The key reference, when represented as a byte, occupies bits b8 and b5-b1, while b7 and b6 shall be set to 0.

Note: This assertion is not separately tested.

AS03.07: The key references used on all PIV interfaces shall be from the list found in Tables 4a and 4b, Part 1 of SP 800-73-4 and SP 800-78-4, Table 6-1.

Note: This assertion is not separately tested.

AS03.08: Withdrawn

AS03.09-R4: If OCC is implemented, the export of the biometric reference data shall not be allowed.

Required Vendor Information

VE03.09-R4.01: The vendor shall state in its documentation that the exportation of the biometric reference data is not allowed by the card.

Required Test Procedures

TE03.09-R4.01: The tester shall review the vendor’s documentation and validate that the exportation of the biometric reference data is not allowed by the card.

AS04.01: Entry points on the PIV client API shall include all functions listed in Table 1, Part 3 of SP 800-73-4 for middleware that supports secure messaging. For middleware that does not support secure messaging entry points on the PIV client API shall include all functions listed in Table 1, Part 3 of SP 800-73-4 with the exception of pivEstablishSecureMessaging.

Note: This assertion is tested as part of AS04.02 through AS04.10A-R4.

Required Vendor Information & Required Test Procedures

To test the entry points or commands that are supported by the PIV Middleware the only information that the vendor has to provide is the PIV Middleware version. All parameter values for exercising the commands have to be obtained from the vendor documentation, using the mapping of PIV Middleware functions to the PIV Card Application card commands that are listed in Table A-1 below. Hence this section contains only tester requirements in terms of Required Test Procedures.

Table A-1: PIV Command Mapping

A.4.1.1 pivConnect

AS04.02: The purpose of pivConnect is to connect the PIV API to the PIV Card Application on a specific ICC.

TE04.02.01: The tester shall validate that the PIV Middleware implements pivConnect as per SP 800-73-4, Part 3.

AS04.02A-R4: The connection description BER-TLV used on the PIV client API shall have the structure described in Table 2, Part 3 of SP 800-73-4.

Required Vendor Information

VE04.02A-R4.01: The vendor shall provide in its documentation the format and content of the connection description templates implemented.

Required Test Procedures

TE04.02A-R4.01: The tester shall review the vendor’s documentation to confirm the presence of the information provided in VE04.02A-R4.01 and that the connection description template conforms to Table 2, Part 3 of SP 800-73-4.

A.4.1.2 pivDisconnect

AS04.03: The purpose of pivDisconnect is to disconnect the PIV API from the PIV Card Application and the ICC containing the PIV Card Application.

Required Test Procedures

TE04.03.01: The tester shall validate that the PIV Middleware implements pivDisconnect as per SP 800-73-4 Part 3.

AS04.03A-R4: If secure messaging has been established then the PIV Middleware shall zeroize the secure messaging session keys when the pivDisconnect command is sent.

Required Vendor Information

VE04.03A-R4.01: The vendor shall specify in its documentation that the PIV Middleware zeroizes the secure messaging session keys as a part of the implementation of pivDisconnect.

Required Test Procedures

TE04.03A-R4.01: The tester shall review the vendor’s documentation and validate that it asserts that the PIV Middleware zeroizes the secure messaging session keys as part of the implementation of pivDisconnect.

A.4.1.3 pivMiddlewareVersion

AS04.03B-R4: PIV Middleware that returns a versionString of “800-73-4 Client API with SM” shall implement all PIV Middleware functions listed in Table 1 of SP 800-73-4 Part 3 and be able to recognize and process all mandatory and optional PIV data objects. PIV Middleware that returns a versionString of “800-73-4 Client API” shall implement all PIV Middleware functions listed in Table 1 except pivEstablishSecureMessaging and shall be able to recognize and process all mandatory and optional PIV data objects. The pivMiddlewareVersion’s purpose is to return the PIV Middleware version string. For SP 800-73-4 Part 3 conformant PIV Middleware, the parameter returns “800-73-4 Client API” or “800-73-4 Client API with SM” if optional secure messaging is supported.

Required Test Procedures

TE04.03B-R4.01: The tester shall validate that the PIV Middleware supports all functions listed in Table 1 of SP 800-73-4 Part 3 and implements the pivMiddlewareVersion as per SP 800-73-4 Part 3 by returning the appropriate parameter string “800-73-4 Client API” parameter string or “800-73-4 Client API with SM” if optional secure messaging is supported.

A.4.2.1 pivSelectCardApplication

AS04.04: The purpose of pivSelectCardApplication is to set the PIV Card Application as the currently selected card application and establish the PIV Card Application’s security state.

Required Test Procedures

TE04.04.01: The tester shall validate that the PIV Middleware implements pivSelectCardApplication as per SP 800-73-4, Part 3.

AS04.04A-R4: If the length of application properties is longer than the buffer allocated by the PIV client application, then the PIV Middleware shall return PIV_INSUFFICIENT_BUFFER, but shall still set APLength to the length of the application properties.

Required Test Procedures

TE04.04A-R4.01: The tester shall ensure that the PIV Middleware returns PIV_INSUFFICIENT_BUFFER if the length of application properties is longer than the buffer allocated by the client application.

A.4.2.2 pivLogIntoCardApplication

AS04.05: The purpose of pivLogIntoCardApplication is to set the security state within the PIV Card Application.

Required Test Procedures

TE04.05.01: The tester shall validate that the PIV Middleware implements the pivLogIntoCardApplication as per SP 800-73-4 Part 3.

AS04.05A-R4: The PIV Middleware shall not submit authenticators to the PIV Card over a contactless interface without secure messaging. If secure messaging has not been established, then the pivLogIntoCardApplication function shall return PIV_SECURITY_CONDITIONS_NOT_SATISFIED.

Required Vendor Information

VE04.05A-R4: The vendor shall state in its documentation that the card supports the assertions made in AS04.05A-R4.

Required Test Procedures

TE04.05A-R4.01: The tester shall validate that that the vendor documentation contains the information required in VE04.05A-R4.

A.4.2.3 pivGetData

AS04.06: The purpose of pivGetData is to return the entire data content of the named data object.

Required Test Procedures

TE04.06.01: The tester shall validate that the PIV Middleware implements the pivGetData as per SP 800-73-4 Part 3.

AS04.06A-R4: If the length of the retrieved data is longer than the buffer allocated by the client application, then the PIV Middleware shall return PIV_INSUFFICIENT_BUFFER, but shall still set DataLength to the length of the retrieved data.

Required Test Procedures

TE04.06A-R4.01: The tester shall ensure that the PIV Middleware returns PIV_INSUFFICIENT_BUFFER if the length of the retrieved data is longer than the buffer allocated by the client application

A.4.2.4 pivLogoutOfCardApplication

AS04.07: The purpose of pivLogoutOfCardApplication is to reset the application security state/status of the PIV Card Application.

Required Test Procedures

TE04.07.01: The tester shall validate that the PIV Middleware implements the pivLogoutOfCardApplication as per SP 800-73-4 Part 3.

A.4.2.5 pivEstablishSecureMessaging

AS04.07A-R4: The purpose of pivEstablishSecureMessaging is to establish secure messaging with the PIV Card Application.⁶

Required Test Procedures

TE04.07A-R4.01: The tester shall validate that the PIV Middleware implements the pivEstablishSecureMessaging as per SP 800-73-4 Part 3.

AS04.07B-R4: After successful execution of the key establishment protocol, the PIV Middleware shall perform all subsequent GET DATA, VERIFY, and GENERAL AUTHENTICATE commands over secure messaging, with the exception of any subsequent uses of the GENERAL AUTHENTICATE command to perform the key establishment protocol.

Required Test Procedures

TE04.07B-R4.01: The tester shall validate that upon successful execution of the key establishment protocol the GET DATA, VERIFY, and GENERAL AUTHENTICATE commands are only sent to the card using secure messaging when the pivGetData, pivLogIntoCardApplication, and pivCrypt middleware functions are called.

AS04.07C-R4: The session keys established after successful execution of the key establishment protocol in Section 4.1 of SP 800-73-4 Part 2 shall be zeroized in the following circumstances: (i) the card is reset; (ii) an error occurs in secure messaging; or (iii) new session keys are requested by the client application by sending a GENERAL AUTHENTICATE command to the card to perform the key establishment protocol using the PIV Secure Messaging key.

Required Vendor Information VE04.07C-R4.01: The vendor shall state in its documentation that the card supports the assertions made in AS04.07C-R4.

Required Test Procedures

TE04.07C-R4.01: The tester shall validate that the vendor documentation contains the information required in VE04.07C-R4.01.

AS04.08: The purpose of pivCrypt is to perform a cryptographic operation such as encryption or signing on a sequence of bytes.⁷

Required Test Procedures

TE04.08.01: The tester shall validate that the PIV Middleware implements the pivCrypt as per SP 800-73-4 Part 3.

AS04.08A-R4: If the value of keyReference is '04' (PIV Secure Messaging key) then the PIV Middleware shall return PIV_INVALID_KEYREF_OR_ALGORITHM.

Note: This assertion is tested as part of AS04.08.

AS04.08B-R4: If the length of the algorithm output is longer than the buffer allocated by the client application, then the PIV Middleware shall return PIV_INSUFFICIENT_BUFFER, but shall still set outputLength to the length of the algorithm output.

Required Test Procedures

TE04.08B-R4.01: The tester shall ensure that the PIV Middleware returns PIV_INSUFFICIENT_BUFFER if the length of the algorithm output is longer than the buffer allocated by the client application.

A.4.4.1 pivPutData

AS04.09: The purpose of pivPutData is to replace the entire data content of the named data object with the provided data.

Required Test Procedures

TE04.09.01: The tester shall validate that the PIV Middleware implements the pivPutData as per SP 800-73-4 Part 3.

AS04.09A-R4: The PIV Middleware shall not submit data provided to the pivPutData function over the contactless interface. If the PIV Middleware is not communicating with the PIV Card via the card’s contact interface then the pivPutData function shall return PIV_FUNCTION_NOT_SUPPORTED.

VE04.09A-R4: The vendor shall state in its documentation that the card supports the assertions made in AS04.09A-R4.

Required Test Procedures

TE04.09A-R4.01: The tester shall validate that that the vendor documentation contains the information required in VE04.09A-R4.

A.4.4.2 pivGenerateKeyPair

AS04.10: The purpose of pivGenerateKeyPair is to generate an asymmetric key pair in the currently selected card application.

Required Test Procedures

TE04.10.01: The tester shall validate that the PIV Middleware implements the pivGenerateKeyPair as per SP 800-73-4 Part 3.

AS04.10A-R4: If the length of public key related data retrieved from the PIV Card is longer than the buffer allocated by the client application, then the PIV Middleware shall return PIV_INSUFFICIENT_BUFFER, but shall still set KeyLength to the length of the public key related data retrieved from the PIV Card.

Required Test Procedures

TE04.10A-R4.01: The tester shall ensure that the PIV Middleware returns PIV_INSUFFICIENT_BUFFER if the length of public key related data retrieved from the PIV Card is longer than the buffer allocated by the client application.

AS04.11-R4: The PIV Middleware shall not submit data provided to the pivGenerateKeyPair function over the contactless interface. If the PIV Middleware is not communicating with the PIV Card via the card’s contact interface then the pivGenerateKeyPair function shall return PIV_FUNCTION_NOT_SUPPORTED.

Required Vendor Information

VE04.11-R4.01: The vendor shall state in its documentation that the card supports the assertions made in AS04.11-R4.01.

Required Test Procedures

TE04.11-R4.01: The tester shall validate that that the vendor documentation contains the information required in VE04.11-R4.01.

The Derived Test Requirements, and their associated required test procedures, for the pivMiddlewareVersion client application command have been moved to Appendix A.4.1.3.

AS05.01: All PIV Card Application card commands listed in Table 2, Part 2 of SP 800-73-4 shall be supported by a PIV Card Application.

Required Vendor Information

VE05.01.01: The vendor shall provide the list of all PIV Card Application card commands, along with the interface(s) (contact or contactless, SM, VCI) they support, the security condition(s) they are subject to and their support for command chaining as implemented by the card.

Required Test Procedures

TE05.01.01: The tester shall review the vendor’s documentation and validate that the information presented in response to VE05.01.01 by the vendor complies with Table 2, Part 2 of SP 800-73-4.

TE05.01.02: The tester shall validate that the card implements all the commands as required in Table 2, Part 2 of SP 800-73-4.

TE05.01.03: The tester shall validate that the commands are implemented only through the interfaces allowed as shown in Table 2, Part 2 of SP 800-73-4.

TE05.01.04: The tester shall validate that the commands are performed only if the security conditions associated with them are satisfied, as shown in the table, via the specified interface.

TE05.01.05: The tester shall validate that the commands as indicated in the table are allowed for chaining via the interface supported after the security condition is satisfied.

AS05.02: Card commands indicated with a 'Yes' in the Command Chaining column of Table 2, Part 2 of SP 800-73-4 shall support command chaining for transmitting a data string too long for a single command as defined in ISO/IEC 7816-4 [6].

Note: This assertion is tested as part of AS05.01.

AS05.03: The PIV Card Application shall return the status word of '6A 81' (Function not supported) when it receives a card command on the contactless interface marked “No” in the Contactless Interface column in Table 2, Part 2 of SP 800-73-4. The PIV Card Application may return a different status word (e.g., '69 82') if the card command can be performed over the contactless interface in support of card management. The PIV Card Application will only perform the command in support of card management if the requirements specified in Section 2.9.2 of FIPS 201-2 are satisfied.

Note: This assertion is tested as part of AS05.01.

AS05.04: Cryptographic protocols using private/secret keys that require the “PIN” or “OCC” security condition shall only be used on the contactless interface after a Virtual Contact Interface (VCI) has been established.

Note: This assertion is tested as part of AS05.01.

A.5.1.1 SELECT Card Command

AS05.05: The PIV Card Application shall be selected by providing its application identifier, 'A0 00 00 03 08 00 00 10 00 10 00', in the data field of the SELECT command.

Required Vendor Information

VE05.05.01: The vendor shall specify in its documentation the PIV Card Application Identifier.

Required Test Procedures

TE05.05.01: The tester shall validate that the PIV Card Application is selected by providing its application identifier as specified in AS05.05.

AS05.06: There shall be at most one PIV Card Application on any ICC.

Required Vendor Information

VE05.06.01: The vendor shall state in its documentation that there is only one PIV Card Application on the ICC.

Required Test Procedures

TE05.06.01: The tester shall review and validate the vendor’s documentation as stated in VE05.06.01.

AS05.07: The PIV Card Application can also be made the currently selected application by providing a right-truncated version – that is, without the two-byte version number, '10 00' – in the data field of the SELECT command 'A0 00 00 03 08 00 00 10 00'

Required Vendor Information

VE05.07.01: The vendor shall provide the list of valid AIDs that the card supports and the mechanism(s) implemented to select the PIV Card Application.

Required Test Procedures

TE05.07.01: The tester shall review and validate that the information provided in VE05.07.01.

TE05.07.02: The tester shall validate that the PIV application is selectable by the right-truncated AID in the SELECT command.

AS05.08: The complete AID, including the two-byte version, of the PIV Card Application that became the currently selected application upon successful execution of the SELECT command (using the full or right-truncated PIV AID) shall be returned in the application property template.

Note: This assertion is tested as part of AS03.02.

AS05.09: If the currently selected application is the PIV Card Application when the SELECT command is sent and the AID in the data field of the SELECT command is either the AID of the PIV Card Application or its right-truncated version thereof, then the PIV Card Application shall continue to be the currently selected card application and the setting of all security status indicators in the PIV Card Application shall be unchanged.

Required Vendor Information

VE05.09.01: The vendor shall provide information in its documentation stating compliance as required by AS05.09.

Required Test Procedures

TE05.09.01: The tester shall validate that when the currently selected application is the PIV Card Application and the SELECT command is sent with an AID that is either the AID of the PIV Card Application or its right-truncated version, then the PIV Card Application continues to be the currently selected application and the setting of all security status indicators in the PIV Card Application remains unchanged.

AS05.10: If the currently selected application is the PIV Card Application when the SELECT command is sent and the AID in the data field of the SELECT command is an invalid AID not supported by the ICC then the PIV Card Application shall remain the currently selected application and all PIV Card Application security status indicators shall remain unchanged.

Required Vendor Information

VE05.10.01: The vendor shall provide information in its documentation validating the compliance with the statement in AS05.10.

Required Test Procedures

TE05.10.01: The tester shall validate that when the currently selected application is the PIV Card Application and the SELECT command is sent with an AID that is not a valid AID supported by the card, then the PIV Card Application continues to be the currently selected application and the setting of all security status indicators in the PIV Card Application remains unchanged.

AS05.11: If the currently selected application is the PIV Card Application when the SELECT command is given and the AID in the data field of the SELECT command is not the PIV Card Application (nor the right-truncated version thereof), but a valid AID supported by the ICC, then the PIV Card Application shall be deselected and all the PIV Card Application security status indicators in the PIV Card Application shall be set to FALSE.

Required Vendor Information

VE05.11.01: The vendor shall provide information in its documentation validating the compliance with the statement in AS05.11.

Required Test Procedures

TE05.11.01: The tester shall validate that when the currently selected application is the PIV Card Application and the SELECT command is sent with a valid AID supported by the ICC that is different from the PIV Card Application AID (or its right-truncated version), then PIV Card Application is deselected and its security status indicators are set to FALSE.

AS05.11A-R4: A PIV Card Application may use a subset of the cryptographic algorithms defined in SP 800-78-4. Tag 0xAC encodes the cryptographic algorithms supported by the PIV Card Application. The encoding of tag 0xAC shall be as specified in Table 5, Part 2 of SP 800-73-4. Each instance of tag 0x80 shall encapsulate one algorithm. The presence of algorithm identifier '27' or '2E' indicates that the corresponding cipher suite is supported by the PIV Card Application for secure messaging and that the PIV Card Application possesses a PIV Secure Messaging key of the appropriate size for the specified cipher suite. Tag 0xAC shall be present and indicate algorithm identifier 0x27 or 0x2E (but not both) when the PIV Card Application supports secure Messaging.

Note: This assertion is tested as part of AS05.34.

A.5.1.2 GET DATA Card Command

AS05.12: The GET DATA card command retrieves the data content of the single data object whose tag is given in the data field.

Note: This assertion is tested as part of AS05.01.

AS05.12A: The GET DATA card command retrieves the data content of the data object only after the access rule associated with the data object (Appendix A, Table 7, Part 1 of SP 800-73-4) evaluates to TRUE.

Required Vendor Information

VE05.12A.01: The vendor shall specify in its documentation the access rule for each of the data objects or make a reference to Table 7 in Appendix A, Part 1 of SP 800-73-4.

Required Test Procedures

TE05.12A.01: For implementations without the Discovery Object or implementations with the Discovery Object implemented and Bit 6 of the first byte of the PIN Usage Policy set to zero, the tester shall validate that all data objects that require a PIN are only accessible after a successful validation of the PIV Card Application PIN through the VERIFY command.

TE05.12A.02: For implementations with the Discovery Object implemented and Bit 6 of the first byte of the PIN Usage Policy set to one: 1) the tester shall validate that all data objects are accessible after a successful VERIFY with the PIV Card Application PIN; and 2) the tester shall validate that all data objects that require a PIN are accessible after a successful VERIFY with the Global PIN.

TE05.12A.02A-R4: For implementations with the Discovery Object implemented and Bit 5 of the first byte of the PIN Usage Policy set to one, the tester shall validate that the appropriate data objects are accessible after a successful VERIFY with OCC.

TE05.12A.03: The tester shall validate that all data objects whose access rule is “Always” are accessible with or without PIV Card Application PIN validation, Global PIN validation (if implemented as indicated in the Discovery Object), or OCC validation (if implemented as indicated in the Discovery Object) using the permitted interface.

A.5.2.1 VERIFY Card Command

AS05.13: PIV Card Applications for which both the PIV Card Application PIN and the Global PIN satisfy the PIV ACRs for PIV data object access and command execution shall implement the Discovery Object with the PIN Usage Policy set to 0x60 zz, 0x6C zz, 0x70 zz, or 0x7C zz, where zz is either 0x10 or 0x20, and may optionally implement the Discovery Object with the PIN Usage Policy set to 0x68 zz or 0x78 zz, where zz is either 0x10 or 0x20.

Required Vendor Information

VE05.13.01: The vendor shall confirm that the PIV Card Application PIN can be used for PIV data object access and command execution. If the Global PIN (in addition to the PIV Card Application PIN) is used for data access and command execution while the PIV Card Application is the currently selected application, the vendor shall state in its documentation that the card supports the assertion made in AS05.13.

Required Test Procedures

TE05.13.01: The tester shall validate that the PIV Card Application PIN can be used for PIV data object access and command execution. The tester shall validate that when the Global PIN satisfies the PIV ACRs for PIV data object access and command execution then: 1) the Discovery Object is implemented with the PIN Usage Policy set to 0x60 zz, 0x68 zz, 0x6C zz, 0x70 zz, 0x78 zz, or 0x7C zz, where zz is set to either 0x10 or 0x20; and 2) the Global PIN can be used for PIV data object access and command execution.

AS05.13A-R4: PIV Card Applications for which OCC satisfies the PIV ACRs for PIV data object access and command execution shall implement the Discovery Object with the first byte of the PIN Usage Policy set to 0x50, 0x58, 0x5C, 0x70, 0x78, or 0x7C.

Required Vendor Information

VE05.13A-R4.01: If OCC (in addition to the PIV Card Application PIN, and possibly the Global PIN) is used for data access and command execution while the PIV Card Application is the currently selected application, the vendor shall state in its documentation that the card supports the assertion made in AS05.13A-R4.

Required Test Procedures

TE05.13A-R4.01: The tester shall validate that when OCC satisfies the PIV ACRs for PIV data object access and command execution then: 1) the Discovery Object is implemented with the first byte of the PIN Usage Policy set to 0x50, 0x58, 0x5C, 0x70, 0x78, or 0x7C; and 2) OCC can be used for PIV data object access and command execution.

AS05.13B-R4: PIV Card Applications that implement the VCI shall implement the Discovery Object with the first byte of the PIN Usage Policy set to 0x4C, 0x5C, 0x6C, or 0x7C, and may optionally also implement the Discovery Object with the first byte of the PIN Usage Policy set to 0x48, 0x58, 0x68, or 0x78.

Required Vendor Information

VE05.13B-R4.01: If the PIV Card Application implements the VCI, the vendor shall state in its documentation that the card supports the assertion made in AS05.13B-R4.

Required Test Procedures

TE05.13B-R4.01: The tester shall validate that PIV Card Applications that implement the VCI implement the Discovery Object with the first byte of the PIN Usage Policy set to 0x4C, 0x5C, 0x6C, or 0x7C (see Table 1 of SP 800-73-4 Part 1).

AS05.14: Key reference '80' specific to the PIV Card Application (i.e., local key references) and, optionally, the Global PIN with key reference '00', the OCC data (key references '96' and '97'), and pairing code (key reference '98') are the only key references that may be verified by the PIV Card Application’s VERIFY command. The PIV Card Application may allow other key references to be verified by the PIV Card Application’s VERIFY command, if they are used for card management operations.

Required Vendor Information

VE05.14.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.14.

Required Test Procedures

TE05.14.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.14.01.

AS05.15: Key reference '80' shall be able to be verified by the PIV Card Application VERIFY command.

Note: This assertion is tested as part of AS05.13.

AS05.16: If the PIV Card Application contains the Discovery Object as described in Part 1 of SP 800-73-4 and Bit 6 of the first byte of the PIN Usage Policy value is one, then key reference '00' shall be able to be verified by the PIV Card Application VERIFY command.

Required Vendor Information

VE05.16.01: The vendor shall specify in its documentation if the Global PIN is implemented with the VERIFY command to satisfy access control rules to read PIN protected PIV data objects. If implemented, the vendor shall also specify the Discovery Object to be present on card with Bit 6 of the first byte of the PIN Usage Policy value set to one.

Required Test Procedures

TE05.16.01: The tester shall validate that if the PIV Card Application contains the Discovery Object and Bit 6 of the first byte of the PIN Usage Policy value is one, then key reference '00' is able to be verified by the PIV Card Application VERIFY command.

AS05.16A-R4: If the key reference is '98' and the authentication data in the command data field does not match the reference data associated with the key reference, the command shall fail and the PIV Card Application shall return the status word '63 00'. If the authentication data in the command data field does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4, then the PIV Card Application may return the status word '6A 80' instead of '63 00'. If status word '6A 80' is returned, the security status of the key reference shall remain unchanged. If status word '63 00' is returned, the security status of the key reference shall be set to FALSE.

Required Test Procedures

TE05.16A-R4.01: The tester shall validate that the card implements AS05.16A-R4 as specified.

AS05.17: If the key reference is '00', '80', '96', or '97' and the current value of the retry counter associated with the key reference is zero, then the comparison shall not be made and the PIV Card Application shall return the status word '69 83'. In order to protect against blocking over the contactless interface, PIV Card Applications that implement secure messaging shall define an issuer-specified intermediate retry value for each of these key references and return '69 83' if the command is submitted over the contactless interface (over secure messaging or the VCI, as required for the key reference) and the current value of the retry counter associated with the key reference is at or below the issuer-specified intermediate retry value. If status word '69 83' is returned, then the comparison shall not be made, and the security status and the retry counter of the key reference shall remain unchanged.

Required Vendor Information

VE05.17.01: The vendor shall specify in its documentation the reset value of the retry counters associated with all the key references implemented on the card.

Required Test Procedures

TE05.17.01: The tester shall validate that the PIV Card Application returns '69 83' in response to the VERIFY command when the retry counter associated with the key reference is zero.

AS05.18: The card command shall fail if the key reference is '00' or '80' and the VERIFY command is not submitted over either the contact interface or the VCI or if the key reference is '96', '97', or '98' and the VERIFY command is submitted over the contactless interface without secure messaging. In either case, the security status and the retry counter of the key reference shall remain unchanged.

Required Vendor Information

VE05.18.01: The vendor shall specify in its documentation the conditions (and associated status word) when the command will fail.

Required Test Procedures

TE05.18.01: The tester shall validate that if the key reference is '00' or '80' and the VERIFY command is not submitted over either the contact interface or the VCI, or if the key reference is '96', '97', or '98' and the VERIFY command is submitted over the contactless interface without secure messaging, then the card command fails and the security status and the retry counter of the key reference remain unchanged.

AS05.18A-R4: If the key reference is '96' or '97' and the authentication data in the command data field is not of length 3N, where N satisfies the requirements for minimum and maximum number of minutiae specified in the BIT, then the card command shall fail, and the PIV Card Application shall return the status word '6A 80'. The security status and the retry counter of the key reference shall remain unchanged.

Required Vendor Information

VE05.18A-R4.01: The vendor shall specify in its documentation that if the key reference is '96' or '97' and the authentication data in the command data field is not of length 3N, where N satisfies the requirements for minimum and maximum number of minutiae specified in the BIT, then the card command fails, the PIV Card Application returns the status word '6A 80', and the security status and the retry counter of the key reference remain unchanged.

Required Test Procedures

TE05.18A-R4.01: The tester shall validate that the card implements AS05.18A-R4 as specified.

AS05.19: If the key reference is '00', '80', '96', or '97' and the authentication data in the command data field is properly formatted and does not match reference data associated with the key reference, then the card command shall fail, the PIV Card Application shall return the status word '63 CX', the security status of the key reference shall be set to FALSE, and the retry counter associated with the key reference shall be decremented by one.

Required Vendor Information

VE05.19.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.19.

Required Test Procedures

TE05.19.01: The tester shall validate that when the VERIFY command fails the retry counter associated with the key reference is decremented by one.

AS05.20: If the card command succeeds then the security status of the key reference shall be set to TRUE. If the key reference is '00', '80', '96', or '97' then the retry counter associated with the key reference shall be set to the reset retry value associated with the key reference.

Required Vendor Information

Note: This vendor information is reviewed as part of VE05.17.01.

Required Test Procedures

Note: This assertion is tested as part of AS05.17.

AS05.21: Moved requirement into AS05.19.

AS05.22A: If the PIN value in the reference data field of the command field is not padded to 8 bytes, the PIV Card Application shall return the status word '6A 80'.

VE05.22A.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.22A.

Required Test Procedures

TE05.22A.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.22A.01 and the card returns status word '6A 80' when the PIN information in the reference data field of the command is not padded to 8 bytes.

AS05.22B: If the key reference is set to a value other than what is supported by the card, the PIV Card Application shall return the status word '6A 88' (key reference not found).

Required Vendor Information

VE05.22B.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.22B.

Required Test Procedures

TE05.22B.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.22B.01.

AS05.22C-R4: The VERIFY command shall reset the security status of the key reference in P2 when the P1 parameter is 'FF' and both Lc and the data field are absent. The security status of the key reference specified in P2 shall be set to FALSE and the retry counter associated with the key reference shall remain unchanged.

Required Vendor Information VE05.22C-R4.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.22C-R4.

Required Test Procedures

TE05.22C-R4.01: The tester shall validate that when using the VERIFY command the security status of the key reference in P2 is reset when the P1 parameter is 'FF' and both Lc and the data field are absent. The tester shall also validate that in this scenario the retry counter remains unchanged.

AS05.22D-R4: If the key reference is '00' or '80' and the authentication data in the command data field does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4, then the card command shall fail and the PIV Card Application shall return either the status word '6A 80' or '63 CX'. If status word '6A 80' is returned, the security status and the retry counter of the key reference shall remain unchanged. If status word '63 CX' is returned, the security status of the key reference shall be set to FALSE and the retry counter associated with the key reference shall be decremented by one.

Required Vendor Information

VE05.22D-R4.01: The vendor shall state in its documentation that the card supports the assertions made in AS05.22D-R4

Required Test Procedures

TE05.22D-R4.01: The tester shall validate that: 1) the vendor documentation contains the information required in VE05.22D-R4.01; and 2) the card returns status word '6A 80' or '63 CX' based on the conditions mentioned in AS05.22D-R4.

A.5.2.2 CHANGE REFERENCE DATA Card Command

AS05.23: Only reference data associated with key references '80' and '81' specific to the PIV Card Application (i.e., local key reference) and the Global PIN with key reference '00' may be changed by the PIV Card Application CHANGE REFERENCE DATA command. Key reference '80' reference data shall be changed by the PIV Card Application CHANGE REFERENCE DATA command. The ability to change reference data associated with key references '81' and '00' using the PIV Card Application CHANGE REFERENCE DATA command is optional. The PIV Card Application may allow the reference data associated with other key references to be changed by the PIV Card Application CHANGE REFERENCE DATA, if PIV Card Application will only perform the command with other key references if the requirements specified in Section 2.9.2 of FIPS 201-2 are satisfied.

Required Vendor Information

VE05.23.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.23.

Required Test Procedures

TE05.23.01: The tester shall validate that reference data associated with key reference '80' can be changed by the PIV Card Application’s CHANGE REFERENCE DATA command. If the Discovery Object is implemented with Bit 6 of the first byte of the PIN Usage Policy set to one and the implementation supports changing the Global PIN with the CHANGE REFERENCE DATA command, then the tester shall also validate that key reference '00' reference data can be changed by the CHANGE REFERENCE DATA command. If the PUK can be changed with CHANGE REFERENCE DATA, the tester shall validate that reference data associated with key reference '81' can be changed by the PIV Card Application CHANGE REFERENCE DATA command.

AS05.24A-R4: If key reference '81' is specified and the command is submitted over the contactless interface (including SM or VCI), then the card command shall fail. If key reference '00' or '80' is specified and the command is not submitted over either the contact interface or the VCI, then the card command shall fail. In each case, the security status and the retry counter of the key reference shall remain unchanged.

Required Vendor Information

VE05.24A-R4.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.24A-R4.

Required Test Procedures

TE05.24A-R4.01: The tester shall validate that if the CHANGE REFERENCE DATA command is submitted over the contactless interface (including SM or VCI) with key reference '81', the PIV Card Application fails. The tester shall validate that if the CHANGE REFERENCE DATA command, with key reference '00' or '80', is submitted over the contactless interface, but not the VCI, then the card command fails. In both cases, the tester shall validate that the security status and the retry counter of the key reference remain unchanged.

AS05.25: If the current value of the retry counter associated with the key reference is zero, then the reference data associated with the key reference shall not be changed and the PIV Card Application shall return the status word '69 83' (Reference data change operation blocked). If the command is submitted over the contactless interface (VCI) and the current value of the retry counter associated with the key reference is at or below the issuer-specified intermediate retry value (see Section 3.2.1 of Part 2 of SP 800-73-4), then the reference data associated with the key reference shall not be changed and the PIV Card Application shall return the status word '69 83'.

Required Vendor Information

VE05.25.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.25.

Required Test Procedures

TE05.25.01: The tester shall validate that when the current value of the retry counter associated with the key reference is zero, the reference data associated with the key reference does not change and the PIV Card Application returns '69 83' (Reference data change operation blocked). The tester shall validate that when the CHANGE REFERENCE DATA command is submitted over the VCI and the current value of the retry counter associated with the key reference is at or below the issuer-specified intermediate retry value, the reference data associated with the key reference does not change and the PIV Card Application returns '69 83'.

AS05.25A-R4: If the authentication data in the command data field does not match the current value of the reference data or if either the authentication data or the new reference data in the command data field of the command does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4, the PIV Card Application shall not change the reference data associated with the key reference and shall return either status word '6A 80' or '63 CX', with the following restrictions:

(b) If the authentication data in the command data field does not match the current value of the reference data, but both the authentication data and the new reference data in the command data field of the command satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4, the PIV Card Application shall return status word '63 CX'.

(c) If status word '6A 80' is returned, the security status and retry counter associated with the key reference shall remain unchanged.

Required Vendor Information

VE05.25A-R4.01: The vendor shall state in its documentation that the card supports the assertions made in AS05.25A-R4.

Required Test Procedures

TE05.25A-R4.01: The tester shall validate that: 1) the vendor documentation contains the information required in VE05.25A-R4.01; and 2) the card returns status word '6A 80' or '63 CX' based on the conditions mentioned in AS05.25A-R4.

AS05.26: If the card command succeeds, then the security status of the key reference shall be set to TRUE and the retry counter associated with the key reference shall be set to the reset retry value associated with the key reference.

Required Vendor Information

VE05.26.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.26.

Required Test Procedures

TE05.26.01: The tester shall validate that the vendor documentation states the required information in VE05.26.01 and the retry counter associated with the key reference is set to the reset retry value associated with the key reference when the command succeeds.

AS05.27: If status word '63 CX' is returned, the security status of the key reference shall be set to FALSE and the retry counter associated with the key reference shall be decremented by one.

Required Vendor Information

VE05.27.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.27.

Required Test Procedures

TE05.27.01: The tester shall validate that the vendor’s documentation contains the information required in VE05.27.01 and the retry counter associated with the key reference is decremented by one if the card command fails.

AS05.28: Moved to AS05.25A-R4.

AS05.28A: If the key reference is set to a value other than what is supported by the card, the PIV Card Application shall return the status word '6A 88'.

Required Vendor Information

VE05.28A.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.28A.

Required Test Procedures

TE05.28A.01: The tester shall validate that the vendor’s documentation contains the information required in VE05.28A.01.

A.5.2.3 RESET RETRY COUNTER Card Command

AS05.29: The only key reference allowed in the P2 parameter of the RESET RETRY COUNTER command is the PIV Card Application PIN. The PIV Card Application may allow the reference data associated with other key references to be changed by the PIV Card Application RESET RETRY COUNTER, if PIV Card Application will only perform the command with other key references if the requirements specified in Section 2.9.2 of FIPS 201-2 are satisfied. If a key reference is specified in P2 that is not supported by the card, the PIV Card Application shall return the status word '6A 88'.

Required Vendor Information

VE05.29.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.29.

Required Test Procedures

TE05.29.01: The tester shall review the vendor’s documentation and validate that includes the information required in VE05.29.01.

AS05.30: If the current value of the PUK’s retry counter is zero then the PIN’s retry counter shall not be reset and the PIV Card Application shall return the status word '69 83'.

Required Vendor Information

VE05.30.01: This information is requested as part of VE05.17.01.

VE05.30.02: The vendor shall specify in its documentation that the RESET RETRY COUNTER card command will not reset the PIN’s retry counter and the card will return '69 83' (Reset operation blocked) when the PUK’s retry counter is zero.

Required Test Procedures

TE05.30.01: The tester shall review the vendor’s documentation and validate that the information requested in VE05.30.02 and VE05.30.01 are present. (NOTE: Testing this condition will leave the card unusable for further tests of the RESET RETRY COUNTER command since the reset counter is zero).

AS05.31: If the card command succeeds, then the PIN’s retry counter shall be set to its reset retry value. Optionally, the PUK’s retry counter may be set to its initial reset retry value. The security status of the PIN’s key reference shall not be changed.

Required Vendor Information

VE05.31.01: This information is requested as part of VE05.17.01.

VE05.31.02: The vendor shall specify in its documentation that the card supports the assertion made in AS05.31.

Required Test Procedures

TE05.31.01: The tester shall validate that when the card command succeeds, the PIN’s retry counter is set to the PIN’s reset retry value specified in VE05.31.01, and the security status of the PIN’s key reference is not changed. If the PUK’s retry counter can be reset, the tester shall validate that the PUK’s retry counter was reset to its initial reset retry value.

AS05.32: If the PIV Card Application returns status word '63 CX' then the retry counter associated with the PIN shall not be reset, the security status of the PIN’s key reference shall be set to FALSE, and the PUK’s retry counter shall be decremented by one.

Required Vendor Information

VE05.32.01: The vendor shall state in its documentation that card supports the assertion made in AS05.32.

Required Test Procedures

TE05.32.01: The tester shall validate that if the PIV Card Application returns '63 CX', then the retry counter associated with the PIN is not reset, the security status of the PIN’s key reference is set to FALSE, and the PUK’s retry counter is decremented by one.

AS05.33: If the reset retry counter authentication data (PUK) in the command data field of the command does not match reference data associated with the PUK, then the PIV Card Application shall return the status word '63 CX'. If the new reference data (PIN) in the command data field of the command does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4, then the PIV Card Application shall return the status word '6A 80'. If the reset retry counter authentication data (PUK) in the command data field of the command does not match reference data associated with the PUK and the new reference data (PIN) in the command data field of the command does not satisfy the criteria in Section 2.4.3 of Part 2 of SP 800-73-4, then the PIV Card Application shall return either status word '6A 80' or '63 CX'. If the PIV Card Application returns status word '6A 80', then the retry counter associated with the PIN shall not be reset, the security status of the PIN’s key reference shall remain unchanged, and the PUK’s retry counter shall remain unchanged.

Required Vendor Information

VE05.33.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.33.

Required Test Procedures

TE05.33.01: The tester shall review and validate that the vendor’s documentation includes the information required in VE05.33.01 and the tester shall also validate that card inplements the RESET RETRY COUNTER card command in a manner consistent with AS05.33 by ensuring the following conditions:

(d) If the PIV Card Application returns status word '6A 80', then the retry counter associated with the PIN is not reset, the security status of the PIN’s key reference remains unchanged, and the PUK’s retry counter remains unchanged.

AS05.33A: Moved requirement into AS05.29.

A.5.2.4 GENERAL AUTHENTICATE Card Command

AS05.34: The GENERAL AUTHENTICATE card command performs a cryptographic operation, such as an authentication protocol, using the data provided in the data field of the command and returns the result of the cryptographic operation in the response data field.

1) The GENERAL AUTHENTICATE command shall be used with the PIV authentication keys ('9A', '9B', '9E') to authenticate the card or a card application to the client application (INTERNAL AUTHENTICATE), to authenticate an entity to the card (EXTERNAL AUTHENTICATE), and to perform a mutual authentication between the card and an entity external to the card (MUTUAL AUTHENTICATE).

2) The GENERAL AUTHENTICATE command shall be used with the digital signature key ('9C') to realize the signing functionality on the PIV client application programming interface. Data to be signed is expected to be hashed off card.

3) The GENERAL AUTHENTICATE command shall be used with the key management key ('9D') and the retired key management keys ('82' – '95') to realize key establishment primitives specified in SP 800-78-4 (ECDH and RSA).

4) The GENERAL AUTHENTICATE command shall be used with the PIV Secure Messaging key ('04') and cryptographic algorithm identifier '27' or '2E' to establish session keys for secure messaging as specified in Section 4 of SP 800-73-4, Part 2. If key reference '04' is specified in P2 then algorithm identifiers in P1 other than '27' and '2E' shall not be permitted and the PIV Card Application shall return the status word '6A 86'.

Required Vendor Information

VE05.34.01: The vendor shall specify in its documentation the types of cryptographic operations (authentication, key establishment primitives, signing primitives, and secure messaging) supported by the card.

Required Test Procedures

TE05.34.01: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to authenticate the card to the client application (Pertains to AS05.34-(1)).

TE05.34.02: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to authenticate the client application to the card (Pertains to AS05.34-(1)).

TE05.34.03: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to mutually authenticate the card to the client application and the client application to the card (Pertains to AS05.34-(1)).

TE05.34.04: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to realize signing functionality (Pertains to AS05.34-(2)).

TE05.34.05: The tester shall validate that the GENERAL AUTHENTICATE command is implemented to support the RSA key transport or Elliptic Curve Diffie-Hellman key agreement primitives specified in SP 800-78-4 (Pertains to AS05.34-(3)).

TE05.34.06: If the '04' key is implemented, the tester shall validate that the GENERAL AUTHENTICATE command is implemented to support only cryptographic algorithm identifiers '27' and/or '2E' to establish session keys for secure messaging. The tester shall validate that if key reference '04' is specified in P2 and an algorithm identifier other than '27' or '2E' is specified in P1 then the card returns the status word '6A 86' (Pertains to AS05.34-(4)).

AS05.35: The GENERAL AUTHENTICATE command shall be implemented to realize the signing functionality on the PIV client application programming interface.

Note: This assertion is tested as part of AS05.34.

AS05.36: If an invalid value of algorithm reference (P1) and/or key reference (P2) is sent to the card, the PIV Card Application shall return the status word '6A 86'.

Required Vendor Information

VE05.36.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.36.

Required Test Procedures

TE05.36.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.36.01 and the card returns status word '6A 86' when an invalid value of algorithm reference (P1) or key reference (P2) is sent to the card.

AS05.36A: If an invalid value is sent in the data field, the PIV Card Application shall return the status word '6A 80'.

Required Vendor Information

VE05.36A.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.36A.

Required Test Procedures

TE05.36A.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.36A.01 and the card returns status word '6A 80' when an invalid value in data field of the command is sent to the card.

AS05.36B: If the command is used to authenticate the card to the client application using a PIN-protected PIV key without prior PIN or OCC verification the PIV Card Application shall return the status word '69 82'.

Required Vendor Information

VE05.36B.01: The vendor shall state in its documentation that the card supports the assertion made in AS05.36B.

Required Test Procedures

TE05.36B.01: The tester shall review the vendor’s documentation and validate that it contains the information required in VE05.36B.01 and the card returns status word '69 82' whenever the command is used to authenticate the card to the client application using a PIN-protected key without prior PIN verification.

AS05.36C: If a card command other than the GENERAL AUTHENTICATE command is received by the PIV Card Application before the termination of a GENERAL AUTHENTICATE chain, the PIV Card Application shall rollback to the state it was in immediately prior to the reception of the first command in the interrupted chain.

Required Vendor Information VE05.36C.01: The vendor shall specify in its documentation that the card supports the assertion made in AS05.36C.

Required Test Procedures

TE05.36C.01: The tester shall review the vendor’s documentation and validate that it states that the PIV Card Application reverts back to the state it was in if a command other than GENERAL AUTHENTICATE is received before the termination of a GENERAL AUTHENTICATE chain.

AS05.37: The PUT DATA card command completely replaces the data content of a single data object in the PIV Card Application with new content.

VE05.37.01: The vendor shall specify in its documentation the format, encoding, and the parameters of the PUT DATA command supported by the card.

Required Test Procedures

TE05.37.01: The tester shall validate that the card complies with the PUT DATA command as defined in SP 800-73-4, Part 2.

A.5.3.2 GENERATE ASYMMETRIC KEY PAIR Card Command

AS05.38: The GENERATE ASYMMETRIC KEY PAIR card command initiates the generation and storing in the card of the reference data of an asymmetric key pair, i.e., a public key and a private key.

Required Vendor Information

VE05.38.01: The vendor shall specify in its documentation the cryptographic mechanism identifiers (specified in Table 5, Part 1 of SP 800-73-4) that have been implemented on the card.

Required Test Procedures

TE05.38.01: The tester shall validate that the card implements the algorithms associated with identifiers specified as part of VE05.38.01 requirement and that the public key returned is formatted based on data object tags specified in Table 11, Part 2 of SP 800-73-4.

AS05.39: The public key of the generated key pair is returned as the response to the command.

Note: This assertion is tested as part of AS05.38.

AS05.40: If there is reference data currently associated with the key reference, it is replaced in full by the generated data.

Required Test Procedures

TE05.40.01: The tester shall validate that the initial key pair is replaced in full by the generated data, by issuing a GENERAL AUTHENTICATE command following a GENERATE ASYMMETRIC KEY PAIR command and verifying the cryptographic results using the public key returned by the GENERATE ASYMMETRIC KEY PAIR command.

AS05.41-R4: When secure messaging is established, the PIV Card Application shall authenticate to the relying system and a set of symmetric session keys will be established.

Required Vendor Information

VE05.41-R4.01: The vendor shall specify in its documentation whether the card implements secure messaging.

Required Test Procedures

Note: This assertion is tested as a part of establishing the VCI interface.

AS05.42-R4: When implemented, SM for non-card-management operations shall only be established using the PIV Secure Messaging key specified in Table 4b of SP 800-73-4, Part 1, and the SM protocol in accordance with the specifications in SP 800-73-4 Section 4 of Part 2.

Required Vendor Information

VE05.42-R4.01: The vendor shall specify in its documentation that secure messaging is implemented in accordance with AS05.42-R4.

Required Test Procedures

TE05.42-R4.01: The tester shall review the vendor’s documentation and validate that the SM for non-card-management operations shall only be established using the PIV Secure Messaging key.

AS05.43-R4: The SW protocol is the status byte of the overall secure messaging command and response processing. It indicates if the secure messaging was performed successfully. If the processing was successful, it shall be '90 00'; otherwise, it shall be as follows: '68 82' if secure messaging is not supported; '69 82' if the security status is not satisfied; '69 87' if the expected secure messaging data objects are missing; and '69 88' if the secure messaging data objects are incorrect. If the command processing was unsuccessful, the card shall return one of the above errors without performing further secure messaging.

Required Vendor Information

VE05.43-R4.01: The vendor shall specify in its documentation that the card conforms to the assertion stated in AS05.43-R4.

Required Test Procedures

TE05.43-R4.01: The tester shall review the vendor’s documentation and validate that the PIV Card returns the applicable SW identified in AS05.43-R4 without performing further secure messaging if the command processing was unsuccessful.

AS05.44-R4: If the PIV Card supports secure messaging, the PIV Secure Messaging key shall be generated on the PIV Card and the PIV Card shall not permit exportation of the PIV Secure Messaging Key.

Required Vendor Information

VE05.44-R4.01: The vendor shall specify in its documentation that the card conforms to the assertion stated in AS05.44-R4.

Required Test Procedures

TE05.44-R4.01: The tester shall review the vendor’s documentation and validate that the PIV Secure Messaging key is generated on the PIV Card and the PIV Card does not permit exportation of the PIV Secure Messaging Key.

AS05.45-R4: The cryptographic operations that use the PIV Secure Messaging key shall be available through the contact and contactless interfaces of the PIV Card.

Note: This assertion is not separately tested since it is tested as a part of initiating the SM and VCI interfaces.

All tests in Appendices B.1 to B.10 are performed over the contact interface only except where stated otherwise. These tests apply to both PIV Middleware versions (with and without SM/VCI). Tests in Appendix B.11 are performed for PIV Middleware version “800-73-4 Client API with SM” only, using a contactless reader interface.

Test Assertion Template

Initiate Shared Connection

Test Assertions for Error Conditions

B.1.2

Malformed Connection Description

Attempting to Share/Lock an Exclusive Connection

Attempting to Lock a Shared Connection

Disconnect a Shared Connection

Test Assertions for Error Cases

B.2.2

Attempt Disconnect with Invalid Card Handle