KAS-ECC: fixedInfoPattern restrictions

[smuellerDD]

Protocol Section See FixedInfoPatternConstruction in the KAS-ECC (and perhaps in the FFC specification).

Protocol Question The specification outlines a number of options. It does not hint that the listed options can only be used once. With that in mind, I tried to define a fixedInfoPattern with multiple literals which is used by one of our clients.

E.g. I would like to define a fixedInfoPattern along the following line of tought:

literal1 || partyUId || literal2 || some other data || partyVId || some other data || literal3

Note, this "some other data" is even a part that is not yet defined in the specification. Anyhow, leaving that out for the moment, the server still returns me:

[
  {
    "acvVersion": "1.0"
  },
  {
    "error": "Validation error(s) on JSON payload.",
    "context": [
      "KAS-ECC-Sp800-56Ar3: Duplicate pieces of fixedInfoPattern found; pieces should be unique."
    ]
  }
]

Thus, the server seems to require the uniqueness of fixedInfoPattern components. Is there a reason for that?

Can we add additional components to the fixedInfoPattern which implies that the protocol is extended by more possibilities?

[livebe01]

Hi @smuellerDD, no I don't think there's a particularly good reason for that. I'm sure KAS could be updated to allow multiple literals in the construction. But I wonder if it would be more productive to update KAS to remove the fixedInfo construction from the testing scope, i.e., allow the tester to specify the fixedInfo value that was used?

[rnunez83]

Hi @livebe01. I am working with @smuellerDD on this issue and wanted to add a bit of background. The implementation we are attempting to test is protocol specific format used for PIVP. Our customer implements the fixed inf as such: literal1 || partyU ID || literal2 || partyU leftmost 16 bytes public key || partyV ID || partyV nonce || literal3 Is this format something we could have assistance testing?

[livebe01]

Sure, can you get me the registration you would like to use?

[smuellerDD]

So, you are saying that we shall have a generic registration, send the test session to you and you will "fix" the fixed info definition?

[livebe01]

Not quite. I'm saying, can you send me the registration that you would use for the algorithm assuming that ACVTS supported the fixedInfoPattern you need. I'd like to look at the registration and think about how to handle it. ACVTS doesn't support the fixedInfoPattern you need, but pretend that it does. I'm thinking that we'll want to accomplish this testing by CAVP generating a custom vector set for your IUT.

[smuellerDD]

Am Donnerstag, 7. September 2023, 18:07:49 CEST schrieb livebe01:

Hi livebe01,

Not quite. I'm saying, can you send me the registration that you would use for the algorithm assuming that ACVTS supported the fixedInfoPattern you need. I'd like to look at the registration and think about how to handle it. ACVTS doesn't support the fixedInfoPattern you need, but pretend that it does. I'm thinking that we'll want to accomplish this testing by CAVP generating a custom vector set for your IUT.

Well, this would require adding new keywords, such as a reference to the used key and a substring thereof.

Ciao Stephan

[livebe01]

Hi Stephan, you and @rnunez83 have described your needs in relation to fixedInfoPattern. But there is much more to describing a KAS-ECC Sp800-56Ar3 algorithm implementation. For example see section 7 of the KAS-ECC Sp800-56Ar3 algo spec. Can you describe for me the remainder of your IUT's KAS-ECC Sp800-56Ar3 capabilities?

[rnunez83]

Hi Stephan, you and @rnunez83 have described your needs in relation to fixedInfoPattern. But there is much more to describing a KAS-ECC Sp800-56Ar3 algorithm implementation. For example see section 7 of the KAS-ECC Sp800-56Ar3 algo spec. Can you describe for me the remainder of your IUT's KAS-ECC Sp800-56Ar3 capabilities?

@livebe01, this is the FixedInfo usually prepared to derive the keys:

[literal1 : e.g: 0x0409090909] || [partyU ID] || [literal2 : 0x0100] || [partyU leftmost 16 bytes public key] || [partyV ID] || [partyV nonce (16 bytes for ECC P-256, 24 bytes for ECC P-384/512)] || [literal3 : 0x0100]

Is this what you are looking for?

[livebe01]

Not exactly. I think that I understand how the IUT in question is preparing the FixedInfo. What I'm asking for is for you to describe its other attributes in relation to its implementing/conforming to KAS-ECC Sp800-56Ar3. What would the rest of its registration look like? E.g., https://pages.nist.gov/ACVP/draft-hammett-acvp-kas-ecc-sp800-56ar3.html#name-example-kas-ecc-registratio.

[rnunez83]

Hi @livebe01

Not exactly. I think that I understand how the IUT in question is preparing the FixedInfo. What I'm asking for is for you to describe its other attributes in relation to its implementing/conforming to KAS-ECC Sp800-56Ar3. What would the rest of its registration look like? E.g., https://pages.nist.gov/ACVP/draft-hammett-acvp-kas-ecc-sp800-56ar3.html#name-example-kas-ecc-registratio.

Ok. how about this then:

  {
    "isSample":true,
    "operation":"register",
    "certificateRequest":"no",
    "debugRequest":"yes",
    "production":"no",
    "encryptAtRest":"yes",
    "algorithms":[
      {
        "prereqVals":[
          {
            "algorithm":"SHA",
            "valValue":"same"
          },
          {
            "algorithm":"DRBG",
            "valValue":"same"
          },
          {
            "algorithm":"ECDSA",
            "valValue":"same"
          },
          {
            "algorithm":"HMAC",
            "valValue":"same"
          }
        ],
        "revision":"Sp800-56Ar3",
        "algorithm":"KAS-ECC",
        "function":[
          "keyPairGen"
        ],
        "iutId":"1234567890abcdef",
        "scheme":{
          "onePassDh":{
            "kasRole":[
              "responder"
            ],
            "kdfMethods":{
              "oneStepKdf":{
                "auxFunctions":[
                  {
                    "auxFunctionName":"SHA2-256"
                  },
                  {
                    "auxFunctionName":"SHA2-384"
                  },
                  {
                    "auxFunctionName":"SHA2-512"
                  }
                ],
                "fixedInfoPattern":"literal[040909090908000000000000000001001000000000000000000000000000000000080000000000000000100000000000000000000000000000000001000400]||l||uPartyInfo||vPartyInfo",
                "encoding":[
                  "concatenation"
                ]
              }
            },
            "l":1024
          }
        },
        "domainParameterGenerationMethods":[
          "P-256"
        ]
      }
    ]
  }
]

[livebe01]

Thanks @rnunez83, this is helpful. Let me take a look and come up with some options for addressing this.

[rnunez83]

Thanks @rnunez83, this is helpful. Let me take a look and come up with some options for addressing this.

Hi @livebe01. I just wanted to check if you had any update for this?

[celic]

Hi, I'm picking this item up from Ben, @livebe01. From what I see, you tried a registration that was rejected because it contained duplicate fixedInfoPatterns. It looks like our tests expect distinct patterns here to do a wider range of testing rather than just a single value. I think we want to continue supporting this.

If you have the Gen/Vals running yourself, you can remove the lines around https://github.com/usnistgov/ACVP-Server/blob/master/gen-val/src/generation/src/NIST.CVP.ACVTS.Libraries.Generation/KAS/Sp800_56Ar3/ParameterValidator.cs#L621. Otherwise if you send me a registration that was failing previously, I can generate some files for you. The registration @rnunez83 provided a couple weeks ago runs without issue already.

[rnunez83]

hi @celic.

the registration request is the following: { "isSample":true, "operation":"register", "certificateRequest":"no", "debugRequest":"yes", "production":"no", "encryptAtRest":"yes", "algorithms":[ { "prereqVals":[ { "algorithm":"SHA", "valValue":"same" }, { "algorithm":"DRBG", "valValue":"same" }, { "algorithm":"ECDSA", "valValue":"same" }, { "algorithm":"HMAC", "valValue":"same" } ], "revision":"Sp800-56Ar3", "algorithm":"KAS-ECC", "function":[ "keyPairGen" ], "iutId":"1234567890abcdef", "scheme":{ "onePassDh":{ "kasRole":[ "responder" ], "kdfMethods":{ "oneStepKdf":{ "auxFunctions":[ { "auxFunctionName":"SHA2-256" }, { "auxFunctionName":"SHA2-384" }, { "auxFunctionName":"SHA2-512" } ], "fixedInfoPattern":"literal[040909090908000000000000000001001000000000000000000000000000000000080000000000000000100000000000000000000000000000000001000400]||l||uPartyInfo||vPartyInfo", "encoding":[ "concatenation" ] } }, "l":1024 } }, "domainParameterGenerationMethods":[ "P-256" ] } ] } ]

[celic]

This is the same one that you posted a couple comments ago? This ran with no issues. I'm looking for the one that you all want to run but are prevented due to the original error message.

[rnunez83]

@celic, see that is the thing. I am unable to create a request that allows two different literal values. What I am trying to form is the following fixedinfo: [literal1 : e.g: 0x0409090909] || [partyU ID] || [literal2 : 0x0100] || [partyU leftmost 16 bytes public key] || [partyV ID] || [partyV nonce (16 bytes for ECC P-256, 24 bytes for ECC P-384/512)] || [literal3 : 0x0100] but ACVTS does not have a field for more than 1 literal definition, so how do we create the request with the above fixedinfo?

[ylu0926]

But I wonder if it would be more productive to update KAS to remove the fixedInfo construction from the testing scope, i.e., allow the tester to specify the fixedInfo value that was used?

Totally agree. Why do we need to test fixedInfo construction? Allow the tester to specify fixedInfo would be more favourable.