NIST validation response for KAS-ECC onePassDh responder role AFT

[jbarnesweb]

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

Protocol Question

Given the test case and response below, the NIST demo server failed the test case with the error "dkm does not match". That answer sent me on a very long investigation into the reason for the dkm not matching. It wasn't until I examined the response that I realized the public key was wrong. It's obvious when you look at the x and y values, but it's not obvious if you don't look at them because the error message was about the dkm.

SP 800-56A Rev3 states the actions for Party U (the ACVP server role in this case) to be the following. Given that it is an ordinal list, one would expect the failure to be when the server checks the public key (step 2) instead of the dkm (step 5).

I think the ACVP should have rejected the public key before (instead of) the dkm.

Actions: Party U generates a shared secret and derives secret keying material as follows:

1. Generate an ephemeral key pair (de,U,Qe,U) from the domain parameters D as specified in Section 5.6.1.2. Send the public key Qe,U to party V.
2. Use the ECC CDH primitive in Section 5.7.1.2 to derive a shared secret Z from the set of domain parameters D, party U’s ephemeral private key de,U, and party V’s static public key Qs,V. If this call to the ECC CDH primitive outputs an error indicator, destroy the ephemeral private key de,U, and destroy the results of all intermediate
3. Use the agreed-upon key-derivation method to derive secret keying material with the specified length from the shared secret value Z and other input (see Section 5.8). If the key-derivation method outputs an error indicator, destroy all copies of Z and the ephemeral private key de,U; then output an error indicator, and exit this process without performing the remaining actions.
4. Destroy de,U and all copies of the shared secret Z.
5. Output the derived keying material.

Here is the test case.

      {
        "domainParameterGenerationMode": "P-256",
        "iutId": "123456ABCD",
        "kasRole": "responder",
        "kdfConfiguration": {
          "auxFunction": "SHA2-256",
          "fixedInfoEncoding": "concatenation",
          "fixedInfoPattern": "algorithmId||uPartyInfo||vPartyInfo",
          "kdfType": "oneStep"
        },
        "l": 256,
        "scheme": "onePassDh",
        "serverId": "434156536964",
        "testType": "AFT",
        "tests": [
          {
            "ephemeralPublicServerX": "9721BD336D71B6DD84740D98BF0C590B7935600A3B134C9E0A56AA1A40288E31",
            "ephemeralPublicServerY": "F3189D7A61CB88A6F829CA4135421480C48BE247629B8E10768689FE24FCB170",
            "kdfParameter": {
              "algorithmId": "ACEC44197B575700714370B1957DD07F",
              "kdfType": "oneStep"
            },
            "tcId": 61
          }
        ]
      }

Here is the response.

        "tests": [
          {
            "dkm": "21A6AA3E39411F235C176781A67D854E948AD79FA1FDBBF499376022D3CEF130",
            "staticPublicIutX": "D452AAE3DBB2562FC485A9E3F6CF7BDE19253C6CBEA57FB7E20F09116A80DE04",
            "staticPublicIutY": "C88C28AB4D342C91446D717FA64D86808A538582EBD4C5E29E5AE7C7B346AA0F000000000000000023B3693E009F00803337BD336D71B6DD84740D98BF0C590B",
            "tcId": 61
          },
        ]

Here is the validation error message.

            {
                "expected": {
                    "dkm": "58912E7972A2F05BBAAD6E746ACC7ADA5B4AB28CEA1E3FB58B4F6F323C578D05"
                },
                "provided": {
                    "dkm": "21A6AA3E39411F235C176781A67D854E948AD79FA1FDBBF499376022D3CEF130"
                },
                "reason": "Dkm does not match",
                "result": "failed",
                "tcId": 61
            },

Again, it's very clear that staticPublicIutY is the problem child, but not so obvious if the error message is complaining about the dkm, especially since Party U is supposed to check the public key before the dkm.

[livebe01]

Thanks for sharing this with us. We'll take a look at what we can do to fix the messaging for this scenario.

[jbarnesweb]

Thank you!