Feature - Secure Messaging / VCI / Pairing Code

[makinako]

SM/VCI/Pairing Code is the next feature to be added and there are a couple of remaining implementation details that I could use some feedback on.

The first point is that the SM CVC is not a Data Object and is used during the General Auth command. This suggests that the CVC is a 'key element' that needs to be injected before the SM key is active. So the key preparation steps I'm implementing are:

1. Call GENERATE ASYMMETRIC KEYPAIR on the appropriate key reference (i.e. 04)
2. Take the resulting public component and generate the CVC on the client-side
3. Inject the 'CVC' element using the OpenFIPS201 administrative CHANGE REFERENCE DATA extension.
4. The key is now available for use.'

There is one issue with this, which is that in SP 800-73-4 4.1.5 it states:
Before signing the CVC the signer shall ....[other stuff] .... and shall verify that the PIV Card is in possession of the corresponding private key.

This suggests that signing functionality is required for this key also. The problem here is that to perform a signing operation you must call GENERAL AUTHENTICATE, passing a CHALLENGE tag with the data to sign and an empty CHALLENGE RESPONSE tag, which is exactly the same structure you would send for SM Key Establishment.

So if the key reference and request structure are identical, how do we tell the difference? The only way I can see to do it is to use the following logic:

1. If the card is in administration mode (i.e. SCP or 9B key), the above command results in a signing operation using the SM private key.
2. Otherwise, key establishment is performed

@dengert / @dmercer-google any thoughts?

[dengert]

NIST 800-74-4 says the CVC certificate is for the "04" private EC key used with SM:
Part 2 3.2.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. 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'."

That looks like a problem, as a ECDSA would by 00 87 11 04 (data field is different) but above says if ins==87 and P2==04 the p1 must be 27 or 2E. It does not say anything about the data fields being different.

But could you use the SM protocol to prove the card has the private key?
What about 4.1.5 Card Verifiable Certificates:
"Before signing the CVC the signer shall perform partial public-key validation [SP800-56A, Section 5.6.2.3.2] for the public key." What does SP800-56A say?

SM CVC is not a Data Object

Not until you create the certificate, But the pubkey returned by the generate keypair so it would be on the card. Or you created it, and the certificate and loaded both.

The PIV card does not have to store the public key, but in the case of the '04' it could if the card needs to use it without the

Part 1 3.3.7:
"... secure messaging CVC is an ECC key. It shall be provided in either an X.509 Certificate for Content Signing or an Intermediate CVC."

Part 2 Table 42. Secure Messaging Certificate Signer
Has the intermediate CVC if needed.