| Question # |
|
Posted by | |
| 1 |
|
Hildegard Ferraiolo |
|
| Question: |
In my reading of SP 800-73, there is little, if any, mention of how these data objects will be written to the PIV card or what types of authentication will be required to do so.
The way it is written it would appear that one PIV card vendor could use the Put Data card application command interface service to load these data objects, and another card vendor could use a different method like the Global Platform secure channel to write these data objects. I am concerned about the interoperability of various PIV cards among the numerous PIV card vendors.
I am also concerned about the security of the various methods that these PIV card vendors will utilize if the method of loading these data objects is left up to them to decide.
As each agency will undoubtedly be loading their own fingerprint buffer data onto their own cards, there would seem to be a security issue if a card holder could enter his PIN and then change his own biometric data on the card. Some of these PIV data objects may be static and never change while others may require updating during the life of the card.
Updating the SP 800-73 document to also specify the method and Access Rules for writing the data objects to the PIV card, I believe, would lead to a more secure and interoperable PIV implementation.
|
|
| Answer: |
SP800-73 does not address PIV card management in detail. It provides a rudamentary set of commands(PUT DATA, GENERATE ASYMMETRIC KEYPAIR) for Credential Initialization and Administration but their use is not mandatory. Other card management schemes that do not use these commands are allowed, as long as they provide a level of security equivalent to the optional card management scheme detailed in FIPS 201, SP800-73, and SP800-78.
FIPS 201 Sec. 4.1.6.2 (page 30) describes the requirements for PIV card activation by a card management system. SP800-73 further requires authentication of card management entities via a symmetric key challenge-response protocol.
SP800-73 specifies Access Control Rule(s) for the PUT DATA command to indicate that the symmetric Card Application Administration key is required to write data objects to the card once the PIV card application has been loaded IF the implementation uses PUT DATA for card management.
In the case where the optional Card Application Administration key is not present, the PIV card application must still implement the PUT DATA command but it will be nonfunctional since the security condition for use cannot be satisfied without that key. The same is true of the other PIV Credential Initialization and Administration command that depends on the Card Application Administration key, GENERATE ASYMMETRIC KEYPAIR.
Finally, NIST Inter-Agency Report 7284 (http://csrc.nist.gov/piv-program/) provides an overview of card management systems, identifies generic card management requirements, and considers some technical approaches to filling the existing gaps in PIV card management.
|
|
| 2 |
|
Hildegard Ferraiolo |
|
| Question: |
| It seems the key buffer for the Card Management key, which is a symmetric key described in FIPS 201 page 33 is missing from this spec. Could you add it or remove its reference in FIPS 201? |
|
| Answer: |
| Symmetric and private keys are not stored in a PIV container. Rather they are stored in a format internal to the card platform and selected by key references. The Card Management key reference value is specified in SP 800-78-1, table 6.1. |
|
| 3 |
|
Chad Blomquist |
|
| Question: |
Reset Retry Counter reads in Part 2: “If the current value of the reset counter associated with the key reference is zero, then retry counter associated with the key reference shall not be reset and the PIV Card Application shall the status word '69 83'.”
Usually a PIN try counter is decremented and the PIN gets blocked when its counter reaches zero. Here it seems the counter is incremented after a failed PIN verify, but in that case, the command could still be used when the PIN is not yet blocked, i.e. after just one failed verification. To avoid the ambiguity, could you just state that the command is authorized only if the application PIN is blocked (i.e. number of remaining attempts is zero).
|
|
| Answer: |
| The Retry Counter limits the number of unsuccessful PIN verifications, and is decremented each time a verification attempt fails. When the Retry Counter reaches zero, the associated PIN is blocked until the Retry Counter is reset. |
|
| 4 |
|
Chad Blomquist |
|
| Question: |
This questions pertains to Part 2 of SP 800-73 and the General Authenticate Card Command (external auth):
When the General authenticate command is used for an external authentication using asymmetric key, the card is supposed to verify a signature using a public key. How is that public key provided to the PIV? Can the PIV contains a list of public keys susceptible to be used? What would be the key references ? Or is the external authenticate function always performed using symmetrical keys? In that case, what key reference should be supported? Please clarify.
|
|
| Answer: |
| The only mandatory external authentication is for the card application administrator via the PIV Card Administration key (aka Card Management Key - 9B), which is a symmetric key in accordance with SP800-78. It is beyond the current scope of SP800-73 to specify mechanisms for installation and usage of public keys on the card for purposes of external authentication. |
|
| 5 |
|
Hildegard Ferraiolo |
|
| Question: |
Part 2 of SP800-73 specifies the General Authenticate Card Command (administrative rights):
What key ref used in general authenticate command can give the administrative rights? In other words, can a general authenticate command in mutual authentication mode with the key exchange key, set the status administrative rights checked, or does it have to be with the card authentication key ? Could it be with the PIV authentication key as well? Please clarify what key ref gives what rights.
|
|
| Answer: |
| Administrative rights are assigned to the PIV Card Application Administrator via a symmetric external authenticate operation using the PIV Card Administration key (aka Card Management Key - 9B). |
|
| 6 |
|
James Dray |
|
| Question: |
| Could you add the support for binary files within PIV to give agencies flexibility to store additional data in potentially proprietary format. This was requested also for PIV cards with dual interface to “emulate” the file structure of a [reference to a commercial product deleted] chip. |
|
| Answer: |
| Addition of data objects to the PIV application domain requires a formal revision of the PIV specifications, to ensure interagency interoperability. Proprietary data objects may be added to other applications resident on PIV cards, and these applications may or may not choose to implement separate instances of the SP800-73 Part 2 Card Edge. Please refer to the PIV Namespace Management supplemental information on the PIV Project web page. |
|
| 8 |
2005-10-07 15:10:46 |
|
|
| Question: |
| In SP800-73, there is no corresponding PIV API command to Change Reference Data & Reset Reference Data APDU commands. Why is that? If applications can only interface with card via APDU for these commands, its not very consistent regarding the use of PIV API interface for PIV data. |
|
| Answer: |
| These APDUs were added to SP800-73 later in the publication cycle and were therefore not reflected in the Client API. Until such time as PIV card management is fully standardized, it is permissible to exercise these APDUs from non-PIV middleware components of card management systems. |
|
| 9 |
|
James Dray |
|
| Question: |
| Table 12 in SP800-73 lists all defined key reference values and states that all unlisted key reference values are reserved for future use. Does this mean that we are limited to those specifically defined keys and may not add new ones? Some feel that the best approach to handling application-specific extension requirements is to create application-specific certificates; this would seem to prevent that. Also, some PKI vendors maintain old encryption key pairs facilitate post-key-rollover decryption; this would seem to prevent that as well. |
|
| Answer: |
| The PIV card application can only have the keys explicitly listed in the PIV standards and specifications. However, a PIV card can have other card applications with other key sets that are outside the scope of the PIV specs. |
|
| 10 |
|
Hildegard Ferraiolo |
|
| Question: |
SP800-73, Part 2 leaves ambiguity on whether or not successful execution of VERIFY PIN is required prior to successful execution of CHANGE REFERENCE DATA.
Table 15. "PIV Card Application Card Command" indicates "Security Condition for Use" of CHANGE REFERENCE DATA command is "Card Holder PIV Card Application PIN".
The CHANGE REFERENCE DATA command description indicates that execution of this command performs a PIN verification (either allows the change of the reference data if correct PIN value is given, or deny it and decrement retry counter if incorrect PIN value).
This verification included in the command makes VERIFY PIN prior to it useless. The command itself enforces the access condition defined in SP 800-73 Part 1.
This would argue for no need of VERIFY PIN prior to CHANGE REFERENCE DATA.
Please precise if successful execution of VERIFY PIN is required or not prior to successful execution of CHANGE REFERENCE DATA.
|
|
| Answer: |
| VERIFY command APDU is not required because, as you point out, PIN verification is performed during execution of CHANGE REFERENCE DATA. |
|
| 11 |
|
Hildegard Ferraiolo |
|
| Question: |
In SP 800-73 Part 3, it is indicated that pivConnect connects the client application to the PIV Card Application on a specific ICC.
- Does pivConnect return an error if there is no PIV Card Application present on the Card?
|
|
| Answer: |
| As specified in Part 3 of SP 800-73, the pivConnect Client API command shall return PIV_CONNECTION_FAILURE any time a pivConnect call with a properly formatted Connection Description fails. One of the possible reasons for failure might be a failed Select command. |
|
| 12 |
|
JHildegard Ferraiolo |
|
| Question: |
In Part 2 of SP 800-73, it states that the platform shall support a default selected application but the default selected application does not have to be the PIV application.
If the PIV application may not be the default selected one, the middleware will have to start any session with a select PIV APDU in case the card's default application is not the PIV but does support a data object with the same identifier as the CHUID.
|
|
| Answer: |
| Correct, an implicit SELECT APDU with the PIV AID will start the PIV card application session (if present). However, there is another alternative method (besides the possibly flawed CHUID method) to discover that the PIV card application is the default application: The PIV middleware can send a GET DATA APDU (without a prior SELECT APDU) to retrieve the Discovery Object. If the the Discovery Object is returned (and contains the PIV AID in the Application Identifer substructure), then the default application is the PIV card application. If the GET DATA APDU command failed, or the retrieved Discovery Object does not match the PIV AID, then the PIV card application should be emplicityly selected with a SELECT APDU command. |
|
| 13 |
|
Hildegard Ferraiolo |
|
| Question: |
| Is it permissable to change the value of the PUK using CHANGE REFERENCE DATA? |
|
| Answer: |
|
|
| 14 |
|
Hildegard Ferraiolo |
|
| Question: |
| what is the expected error code for pivLogIntoCardApplication when the card is locked? |
|
| Answer: |
| PIV_AUTHENTICATION_FAILURE |
|
| 15 |
|
James Dray |
|
| Question: |
| For pivConnect, shall the ConnectionDescription parameter be modified with the actual reader list? |
|
| Answer: |
| How the parameters are passed in and out for the ConnectionDescription is ultimately up to the middleware designer. An implementation might be for the ConnectionDescription to be overwritten by the returned reader list, but this is not required. |
|
| 16 |
|
James Dray |
|
| Question: |
| How shall piv functions implement "out string" parameters if the allocated size is insufficient: Shall an error code indicate that the buffer is too small and shall the expected length be returned? |
|
| Answer: |
| SP 800-73 does not specify language bindings in any way, so this is up to the middleware author. |
|
| 17 |
|
James Dray |
|
| Question: |
| In examining SP800-73, Part 1, I discover that on
Appendix A, the Expiration date in the the Card Holder Unique Identifier Data Object is 8 bytes long.
The expiration date in the Printed Information Data Object, however is 9 bytes long.
Is this an inconsistency, or am I just confused? |
|
| Answer: |
These are actually 2 different numbers that are also encoded differently. The expiration date in the CHUID applies to the validity period of that particular CHUID instance, and the one in the Printed Information object applies to the expiration date (and time) of the PIV Card itself.
As specified in section 1.8.3 of SP 800-73 page 6, the CHUID's Expiration Date is an 8-byte ASCII representation in the form YYYYMMDD.
As specified in section 4.1.4.1 of FIPS 201, page 18, the required Expiration Date is to be formatted YYYYMMMDD, where the MMM characters represent the three alphabetical character month abbreviation (e.g. 2006FEB19) |
|
| 18 |
|
James Dray |
|
| Question: |
It appears that the CCC data object attributes format are not defined by 800-73. NISTIR 6887 (GSC-IS2.1) defines that format.Here are some references to existing requirements and directions:
[1] 800-73 "The CCC is mandatory for compliance with the GSC-IS specification. It supports minimum capabilities for lookup on data model and application information".
[2] NISTIR 6887 (GSCIS2.1), sections 6.3 and 7.3 define the format of CCC attributes.
Here are related questions about the use and format of the CCC and its attributes .
a) Can you clarify the use of the CCC when applied to the end-point PIV card application. Can it be used to discover PIV data objects? Can it be used to discover GSCIS2.1 objects outside of the PIV Card Application?
b) Are the format of CCC attributes free or must they follow [2]? Must all PIV data model objects be defined with ApplicationsCardURLs ?
c) If the response to b) is yes, 800-73 does not specify how the ApplicationsCardURL format defined in [2] is applicable to end point PIV Application. Can you confirm or comment the following asumptions:
- a 5-byte RID. The value proposed is 'A0 00 00 03 08', as defined in the namespace management document for PIV Data Objects.
- a 1 byte AppType: set to 0
- a 2-byte GSCIS2.1 ObjectID such as the values provided in 800-73.
- a 2-byte AppID. In GSCIS2.1 this was the PIX of the application hosting the object, this application could be different than the CCC. Since the application including the object also includes the CCC, we may set this to 0000.
- AccProfile (1 byte), PinID (1 byte), AccKeyInfor (4 bytes), all set to 0.
d) Is the ExtendedApplicationscardURL intended to specify objects not defined in the PIV data model 0x10? Is the format of ExtendedApplicationsCardURL free?
e) The AccessControlRuleTable CCC attribute is defined as a non NULL attribute in 800-73. It is defined in GSCIS2.1 as either:
- The declaration of the Access Rules for all non-administrative APDUs operating on the DataObjects and keys specified in the data model.
- The AID of the GSCIS2.1 Application hosting the access control information.
What value should be present if no GSCIS2.1 Access Control application is present on the card? . Would it be acceptable to set the attribute with NULL length or declare the attribute optional? .
|
|
| Answer: |
Although the CCC is a mandatory PIV data object, there is no requirement for its use on endpoint cards. The PIV CCC's primary purpose is to facilitate backward compatibility of endpoint cards with legacy middleware that relies on the CCC discovery mechanisms. As such, it is expected that the CCC will only be useful to legacy systems if it follows the format defined in legacy specifications (NISTIR 6887).
The core PIV data objects exist in a namespace that is tightly managed by NIST, and discovery mechanisms are therefore not required for the use of these objects by endpoint-aware middleware. The PIV CCC could be used to discover objects outside the PIV Card Application, but this use is outside the scope of SP800-73.
|
|
| 19 |
|
Hildegard Ferraiolo |
|
| Question: |
Part 2 of 800-73 describes the use of the RESET RETRY COUNTER command:
?If the card command succeeds, then the retry counter associated with the key reference shall be set to the reset retry value associated with the key reference. Neither the security status of the key reference or the reset counter shall be changed.?
This implies that the successful execution of the RESET RETRY COUNTER command resets the PIN's retry counter and DOES NOT reset the PUK's retry counter.
Should there be any way to reset the retry counter for the PUK? In other words, does the PIV Card Application want to trap a number of TOTAL or SEQUENTIAL unsuccessful PIN retry counter reset attempts? Please clarify.
|
|
| Answer: |
| No method has been provided for resetting the retry counter associated with the PUK. This would require designation of an additional administrative key, since the PUK itself should not be used to reset its own retry counter. NIST may consider adding this capability to future versions of the PIV specifications based on public comment. |
|
| 20 |
|
James Dray |
|
| Question: |
| Since PIV cards can use either T=0 or T=1 communication protocol, to guarantee interoperability, do you confirm that the PIV middleware shall be able to communicate with cards both in T=0 and T=1 mode. |
|
| Answer: |
| PIV middleware must be able to communicate with cards in both T=0 and T=1 mode. |
|
| 21 |
|
Hildegard Ferraiolo |
|
| Question: |
| Should one be able to perform an INTERNAL AUTHENTICATE using Key 9B, the card authentication key? If so, seeing as it is a Triple DES key, is there a maximum size that the challenge can be (like 8 bytes) or does it have to be a multiple of the size of key 9B? Any more information here would be greatly appreciated. |
|
| Answer: |
| Yes, INTERNAL AUTHENTICATE is supported with key 9B. Since the card does no padding or hashing, the challenge sent to the card should be appropriate to the cryptographic algorithm and key size used in the INTERNAL AUTHENTICATE operation. In the case of triple DES the challenge would be 8 bytes. |
|
| 22 |
|
James Dray |
|
| Question: |
SP800-73, Part 2, defines Interface device – PKCS#11. How to use this interface type. What is this "PKCS#11 interface" mean?.
Please give a valid connectionDescription string for this type. |
|
| Answer: |
| See ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf for a description of the PKCS#11 interface. The Connection Description Template defined in SP800-73 Table 11 simply identifies the device interface below the PIV Client API, it does not describe how to use it. Client applications communicating directly with the PIV Client API should use the interface methods defined in SP800-73. |
|
| 23 |
|
James Dray |
|
| Question: |
The Table 11 of SP800-73 describes the structure of the connectionDescription Template. Does it impose condition on order of its subfields (first Interface device and then Network type). I think the reference implementation does not check the order for the subfields.
|
|
| Answer: |
| Since these structures use BER-TLV encoding, the order of the subfields is not significant. A parser for these objects should be able to extract subfields regardless of their physical order. |
|
| 24 |
|
|
|
| Question: |
In Part 3 of SP 800-73, pivLogIntoCardApplication function, the parameter authenticators is given as "A sequence of zero or more BER TLV encoded authenticators". what is the use of passing zero authenticator?
Do we need to support more than one authenticator structure in the parameter in PIV Client API implemenation.
|
|
| Answer: |
| A compliant PIV Client API implementation will need to have a LogIntoCardApplication function that can accept multiple authenticators as described and deal with them appropriately. |
|
| 25 |
|
Hildegard Ferraiolo |
|
| Question: |
Is it valid to return our own error code(example: PIV_INSUFFICIENT_BUFFER) that is not given in SP800-73 from PIV Client APIs. |
|
| Answer: |
No. Only the error codes specified in SP800-73, Part 3 are valid. Allowing other error codes would hamper interoperability. |
|
| 26 |
|
Ramaswamy Chandramouli |
|
| Question: |
| Can the pivLogIntoCardApplication function's authenticators parameter mentioned in Part 3 of SP 800-73-2 have more than one authenticator structure in it. If it can accepts more then one authenticator structure then ,What is the pivLogIntoCardApplication behaviour if one of the authenticator is wrong? what is the return value in this scenario. |
|
| Answer: |
The 'authenticators' parameter is a concatenated series of one or more BER TLV strings, each formatted as specified in section 5.3.
If any authenticator is improperly constructed, the host-side PIV API implementation should notice this and return PIV_AUTHENTICATOR_MALFORMED.
If the contents of any of the properly formatted authenticator is invalid, the cryptogram or PIN will be passed on to the appropriate card-edge command, and will come back with an appropriate failure status word. Upon receipt, the API software should return PIV_AUTHENTICATION_FAILURE. |
|
| 27 |
|
James Dray |
|
| Question: |
Regarding question 122:
"Which keys are resident on the card? Is there a private key held outside of the card?"
I cannot find where this is answered.
FIPS-201 says the PIV Authentication Key (PAK) is generated on the card. Therefore, in FIPS-201 6.2.4 and SP800-73, Part 1 B.1.4, how is the PAK certificate checked for revocation? Is it somehow tied to an external CA?
Thanks
|
|
| Answer: |
1. Key references apply to private and secret (symmetric) keys. In all cases, the existence of a key reference means that the corresponding private or secret key resides on the card.
2. Certificate revocation checks are handled by PIV back-end systems and not the cards themselves. FIPS 201-1 and SP800-78-1 address these issues.
All PIV certificates are issued by external CAs. The card generates the key pair and signs the certificate request, but the X.509 certificate itself is generated by an agency or vendor operated CA. The PKI policies referenced by FIPS 201 require a cardholder to report loss or theft of a PIV card. The external CA would add the certificates on this card to its revocation lists.
Note that the card does not need to check for revocation status on its own certificates. The relying party, who uses the public key in the certificate, will perform that check itself. |
|
| 28 |
|
Ramaswamy Chandramouli |
|
| Question: |
The pivCrypt functionality suggests an authenticate template closely resembling an internal authenticate sequence. Is this correct?
Or, put in another way, is the pivCrypt command expected to form a GENERAL AUTHENTICATE card command, using the 81 tag for a "challenge" and the data to be encrypted or signed in the challenge data field?
|
|
| Answer: |
| That is correct. Since this command contains parameters for Algorithm code and key reference, it could also be used to perform external authentication and even mutual authentication as well using the same encoding used in the dynamic authentication template of GENERAL AUTHENTICATE command. |
|
| 29 |
|
James Dray |
|
| Question: |
1) SP 800-73, Part 1,section 5.1 Key References says:
"A key reference is a 6-bit identifier of cryptographic material in the PIV Card Application used in a cryptographic protocol. When represented as a byte, the key reference occupies b8 and b5-b1 while b7 and b6 shall be set to 0. If b8 is 0 then the key reference names global reference data. If b8 is 1 then the key reference names application-specific reference data.
When using the VERIFY, RESET RETRY COUNTER and CHANGE REFERENCE DATA commands the only error status word is 0x6A88 (key reference not found) but nothing indicates how to handle a bad formatted key reference.
2) SP 800-73 Part 2 (PUT DATA APDU setion)
The PUT DATA card command completely replaces the data content of a single data object in the PIV Card Application with new content.
Due to the size of the PIV containers it’s impossible to use a transaction buffer to restore container data in the case of card tearing or wrong use of the PUT DATA command, what about the old data in the case of a card tearing or chaining break ?
3) The 0x9A key is RSA 1024, during the INTERNAL AUTHENTICATION scheme, the host sends a 1024bits long random to the card. The RSA algo as defined in PKCS#1 needs that the value of the data to cipher shall not be greater than the value of the private key modulus. Nothing protect us from this in the GENERAL AUTHENTICATE command.
|
|
| Answer: |
1) An incorrectly formatted key reference is treated as an invalid key reference, since the two are indistinguishable.
2) The data on the card will only be overwritten upon a successful transmission of the entire payload. If there is an interruption of any kind mid-transfer, the data on card will not change.
3) This statement is incorrect. If the data passed to the General Authenticate command is of improper length, the card will respond with 0x6A80, indicating a failure due to incorrect incoming data. |
|
| 30 |
|
Hildegard Ferraiolo |
|
| Question: |
PACS V2.2 section 3.2 'medium assurance profile' number 7 reads 'The reader using a site specified algorithm computes a Hashed Message Authentication Code (HMAC).'
questions:
1) Do any restrictions apply on the HMAC (such as e.g. NIST SP 800-78) or may this algorithm be fully freely chosen by the 'site' ?
2) What HMAC algorithm(s) must a vendor for reader chips implement to claim formal compliance to the 'medium asurance profile' ?
|
|
| Answer: |
| SP800-73 makes normative reference to PACS V2.2 for the CHUID format only. Other PACS requirements and assurance profiles are beyond the scope of current PIV standards and specifications. |
|
| 31 |
|
Hildegard Ferraiolo |
|
| Question: |
It seems that the PUK is only used in the RESET RETRY COUNTER, which
implicitly verifies the PUK as part of its processing. Are there circumstances
in which one would want to use the VERIFY command with the PUK?
Is this
the correct interpretation?
|
|
| Answer: |
| The PUK is intended to be used in the RESET RETRY COUNTER command to reset the PIV Application PIN. It is not recommended to use PUK in other commands outside the issuer controlled environment. |
|
| 32 |
|
Hildegard Ferraiolo |
|
| Question: |
| The CHUID includes a Buffer Length data element with tag 0xEE. Does this element represent the length of the entire CHUID? |
|
| Answer: |
| The Buffer Length, a TLV Element with Tag Value 0xEE, was added to the CHUID based on a request from DoD. This element was added to specify the length of the entire CHUID, excluding the Buffer Length element itself, but including the CHUID's Asymmetric Signature element. The calculation of the Asymmetric Signature must exclude the Buffer Length element if it is present. |
|
| 33 |
|
Hildegard Ferraiolo |
|
| Question: |
I have run across a couple of certified cards for which the CHUID signature includes the Error Detection Code TLV in its message digest calculation. I believe this is incorrect since the idea of the Error Detection Code was that it would be calculated over the entire block of data preceding it, including the already calculated signature (though for PIV it is always zero-length).
I believe there are three TLVs not included in the CHUID signature message digest calculation: Buffer Length (tag EE), Error Detection Code (tag FE), and, of course, the signature itself (tag 3E).
Can you verify my statement above? |
|
| Answer: |
According to -85B, the Error Detection Code (tag 0xFE) TLV is included in the calculation of the asymmetric signature. The signature TLV (tag 0x3F) and the Buffer Length TLV (if present, tag 0xEE), on the other hand, are excluded.
For the elements included in the signature, the calculation is performed over all TLV fields (Tag field, Length field and the Value field), not just the value field. One exception: the Error Detection Code tag does not have a V-field and as such its V field naturally cannot be included in the calculation. Please note that the calculation of the signature is based on SP 800-73 / SP 800-78-1 specification and not PACS 2.2.
|
|
