Construction of OtherInfo for KAS-ECC (sp800-56ar3) for TCG TPM 2.0 specification

[seanedmond]

Protocol Section

https://pages.nist.gov/ACVP/draft-hammett-acvp-kas-ecc-sp800-56ar3.html

Our implementation is targeting:

• KasMode = KdfNoKc
• scheme =onePassDh
• kdfType = oneStep
• domainParameterGenerationMode = P-192 || P-224 || P-256 || P-384 || P-512
• kdfConfiguration->auxFunction = SHA-1 || SHA2-224 || SHA2-256 || SHA2-384

Protocol Question

We have a KAS-ECC implementation based on the TCG TPM 2.0 specification that constructs KAS-ECC "OtherInfo" as follows:

Note, the TCG TPM 2.0 spec is here:
https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf

11.4.10.3 KDFe for ECDH

OtherInfo ≔ AlgorithmID || PartyUInfo || PartyVInfo {|| SuppPubInfo} {|| SuppPrivInfo} 

AlgorithmID a bit string that indicates how the derived keying material will be parsed 
and for which algorithm(s)
PartyUInfo public information contributed by party U (the initiator)
PartyVInfo public information contributed by party V (the responder)
...
PartyUInfo the x-coordinate of the public point of an ephemeral key
PartyVInfo the x-coordinate of the public point of a static TPM key

Understandably, I'm having a lot of difficultly mapping our implementation to the KAS-ECC ACVP tests.

Comments/questions:

• ACVP spec specifies: uPartyInfo = uPartyId { || ephemeralKey } { || ephemeralNonce } { || dkmNonce } { || c } vPartyInfo = vPartyId { || ephemeralKey } { || ephemeralNonce } { || dkmNonce } { || c }
• Based on the ACVP definition of uPartyInfo/vPartyInfo, it looks like a non-NULL value must be provided for uPartyId/vPartyId. Can you confirm?
• My understanding of the ACVP definition of "ephemeralKey" is that it should be the concatenation of the ephemeralKey x and y coordinates. Can you confirm?
• The TPM specification is only using the ephemeral X coordinate to form PartyUInfo (my understanding is it should be using x | y ). For PartyVInfo it is using the static key x coordinate (my understanding is it should provide nothing since this isn't an ephemeral key). Can you confirm?

One alternative that seems possible is to perform "piecemeal" validation of KAS-ECC-SSC and KAS-KDF. Would this be a viable option to obtain KAS certification for our module (and for other modules based on the TCG TPM 2.0 specification)?

[bradlitterell]

For PartyVInfo it is using the static key x coordinate (my understanding is it should provide nothing since this isn't an ephemeral key). Can you confirm?

I believe PartyVInfo should be provided. The TPM Spec part 1 uses the phrase "static TPM key", but the word "static" is misleading. In this case the emphasis should be on the word "TPM" not "static". I think the distinction between "static" and "ephemeral" is potentially misleading on this point since the lifetime of the TPM's key is effectively indeterminate. It could be a long-term key, or it could be a key created in the TPM for a single transaction. The distinction is not part of the TPM's KDFe implementation or spec.

The TPM's usage is to provide the TPM's public key info (x-coord) as V, and I don't think it's correct to leave it empty.
The question whether the y-coord is required as well as the rest Sean's questions are still live questions I think. One reason I believe the TPM spec might omit the y-coordinate is it provides only a single bit of extra information (and other ECC applications, such as ECDSA, drop y in some calculations).

[livebe01]

Hi @seanedmond,

Sorry for the delayed response. Hopefully what I’ve provided below will be of some use.

• ACVP spec specifies: uPartyInfo = uPartyId { || ephemeralKey } { || ephemeralNonce } { || dkmNonce } { || c } vPartyInfo = vPartyId { || ephemeralKey } { || ephemeralNonce } { || dkmNonce } { || c }

Section 7 of the KAS ECC Sp800-56Ar3 spec pertains to describing the implementation that you are testing. One part of specifying your one step kdf capabilities is defining the pattern that is used for your fixedInfo construction. Section 7.5.1.3 lists a number of possible components for your fixedinfoPatternConstruction.

• Based on the ACVP definition of uPartyInfo/vPartyInfo, it looks like a non-NULL value must be provided for uPartyId/vPartyId. Can you confirm?

Yes, a non-NULL value must be provided. We expect you to construct uPartyInfo and vPartyInfo in the following fashion: uPartyId { || ephemeralKey } { || ephemeralNonce } { || dkmNonce } { || c } and vPartyId { || ephemeralKey } { || ephemeralNonce } { || dkmNonce } { || c }. Our test cases will always provide a non-null value for uPartyId and vPartyId. Whether a given test case generated by ACVTS includes values for ephemeralKey, ephemeralNonce, dkmNonce and c depends on which kasRoles and schemes you register with our servers. Consult Section 6 of SP 800-56Ar3 to determine whether or not an "optional" item is applicable to the scheme being tested and must be included as part of the uPartyInfo/vPartyInfo for a given test case.

• My understanding of the ACVP definition of "ephemeralKey" is that it should be the concatenation of the ephemeralKey x and y coordinates. Can you confirm?

Yes, the construction of the ephemeralKey should be: x coordinate | y coordinate.

• The TPM specification is only using the ephemeral X coordinate to form PartyUInfo (my understanding is it should be using x | y ). For PartyVInfo it is using the static key x coordinate (my understanding is it should provide nothing since this isn't an ephemeral key). Can you confirm?

You are correct, in order for your answers to be judged correct by the ACVTS server, you must use what the server is expecting for PartyUInfo, which is x | y and not the x from the TPM spec. For our testing, we do not include the static public key as part of the uPartyInfo and vPartyInfo construction. As such, you should not use the static key x coordinate in your vPartyInfo construction.

One alternative that seems possible is to perform "piecemeal" validation of KAS-ECC-SSC and KAS-KDF. Would this be a viable option to obtain KAS certification for our module (and for other modules based on the TCG TPM 2.0 specification)?

No, performing a piecemeal validation of KAS-ECC-SSC and KAS-KDA will not get you a KAS-ECC Sp800-56Ar3 entry on a CAVP certificate. However, I believe that a pair of KAS-ECC-SSC and KAS-KDA entries on a CAVP certificate should be viewed as being more or less equivalent to a KAS-ECC Sp800-56Ar3 entry on a CAVP certificate for the purposes of the CMVP and obtaining a CVMP FIPS 140-3 module validation.

You make good and valid observations. SP 800-56Ar3's requirements regarding the fixedInfo construction are flexible and give a lot of leeway. CAVP's KAS SP 800-56Ar3 testing tests the construction of the fixedInfo, but isn't as flexible as it should be to support every possible SP 800-56Ar3-compliant fixedInfo construction.

Best,

Ben

[livebe01]

Closing this out as completed. Please leave a comment if you need additional information.