KAS ECC - key confirmation with curves of fieldsize greater than 384 bits causes failure with some schemes and some options

[dghgit]

The latest update does result in more vectors passing, but there is still an issue. I've attached a transcript from /acvp/v1/testSessions/97229 on demo - the .rsp.json file contains our responses.

The test is based on the following request:

[{"acvVersion":"1.0"},{"isSample":false,"algorithms":[{"algorithm":"KAS-ECC","revision":"1.0","prereqVals":[{"algorithm":"DSA","valValue":"same"},{"algorithm":"DRBG","valValue":"same"},{"algorithm":"SHA","valValue":"same"},{"algorithm":"AES-CCM","valValue":"same"},{"algorithm":"CMAC","valValue":"same"},{"algorithm":"HMAC","valValue":"same"}],"function":["keyPairGen","dpGen"],"scheme":{"onePassMqv":{"kasRole":["responder","initiator"],"kdfKc":{"kdfOption":{"concatenation":"uPartyInfo||vPartyInfo"},"kcOption":{"kcRole":["recipient","provider"],"kcType":["unilateral","bilateral"],"nonceType":["randomNonce"]},"parameterSet":{"ed":{"curve":"B-409","hashAlg":["SHA2-384"],"macOption":{"HMAC-SHA2-384":{"keyLen":[192],"macLen":128}}}},"dkmNonceTypes":["randomNonce"]}}}}]}]

transcripts.zip

A lot of the AFT tests appear to be now passing as are some of the VAL tests, there seems to be a bit of inconsistency between the two groups though, in some case an AFT test group will pass, but the same {kasRole, kcRole, kcType} will see the related VAL test group fail.

Changing the curve to P-384 results in everything passing.

[Kritner]

Hmm... ok I'll take another look, thanks @dghgit

[Kritner]

Hey @dghgit I'm trying to dig a bit into this, but if you would be able to produce some intermediate values for me based on a failing test case that could prove to be most useful.

I'm just going to try to reproduce our mismatch for a single test case from the vector set you inquired about, specifically tcId 51:

Prompt from server:

{
	"scheme": "onePassMqv",
	"parmSet": "ed",
	"curve": "B-409",
	"tgId": 6,
	"testType": "AFT",
	"kasRole": "initiator",
	"kasMode": "kdfKc",
	"hashAlg": "SHA2-384",
	"macType": "HMAC-SHA2-384",
	"keyLen": 192,
	"macLen": 128,
	"kdfType": "concatenation",
	"idServerLen": 48,
	"idServer": "434156536964",
	"kcRole": "recipient",
	"kcType": "bilateral",
	"tests": [{
		"staticPublicServerX": "012FE188907418A2A3908E387C5651E4A8DADE4BC87A229A03E2FF6F4EE31BABF1BC09A228F8E3758BB9E0CBF4F8B79C36840FDB",
		"staticPublicServerY": "011190DFE859474A8216264949B6AA42E22F50900CFD46D96A1558ABED86237E64F190D5BF82B542E698E53FE39F222EFF98F600",
		"tcId": 51,
		"nonceEphemeralServer": "057A81200E0E7DD00E9AAB63F089BF6B23E9DCBED36E7377972C365A1D37D842E78C1FEE50C606B3D12B33EBB419758C45D8605F8FA4CE652911E654C24EFB02861F7D265605038449AC23E1939C497D40F8E9187A5EA224B2B633948A901FF4CC8787FD56B680"
	}]
}

Response from IUT:

{
	"tgId": 6,
	"tests": [{
		"tcId": 51,
		"staticPublicIutX": "017a34ad2769e1a68bca80c0d3b5a3d6d980cc9b81af02f4c7a4dbef72e6c3817bcd61660e71f883de3eb891d24b03d7c4a355d3",
		"staticPublicIutY": "008a111fcd9b24dc28c318e9832e598579a5757d81beeab2cc9abbecb8f22194bea467970de0e99b2e9fea7b53dfde457a09ac3d",
		"ephemeralPublicIutX": "013c06618a28208b1acdc7a233c53d1e0e9ea77c2dc71c45e703f53bbdc9bacb75104a8be3eb8524cfc4676ceda8dd0faf92f141",
		"ephemeralPublicIutY": "0146c14a61ee963602f40289769e2418b02bfc3c778fe8e4a70c5615482bba781e337169126e70b0ad9af05acf81164b033f2bd6",
		"oiLen": 376,
		"oi": "6b606d9a64434156536964ac58b58d8a93dd86c698f0d97734fec1c7af8541e92229ce48d1796a1b4ef8666181b9ab",
		"idIutLen": 40,
		"idIut": "6b606d9a64",
		"dkm": "792febdd0e0f9fa4b2b2b5d902ec9cb9238646b249fafb8e",
		"tagIut": "7071549402f33c56537b4a2e86af2942"
	}]
}

hopefully if the difference here is found it will help inform for other failing tests in the VS.

It looks like for this particular test case we do agree on a DKM, just not a tag, so that's interesting. Perhaps providing your z (even though we agree), as well as the inputs into the MAC function. I suppose we already agree on the key portion input into the mac through the dkm, but could you provide the macData or message that gets plugged into the HMAC? (hopefully these terms are accurate, it's been a while 👍 )

I am intentionally asking for some intermediate values we already agree on, but I'm doing it in case we need to do this sort of comparison for multiple failing test cases, cases where we disagree starting at an earlier point in the process.

[Kritner]

Hmm... though actually now I'm realizing that you might no longer have the private key associated to the public key posted in the above test case; I'll try to dig a failing VAL test case up where we supply both parties key pairs. (If you do still have that private key available, then I'll still take the intermediate values)

[dghgit]

I kept the original request so I can reproduce it. Here's the output with the private keys, z, and the macData.

{
"tcId":51,   "staticPrivateIut":"00315e6641e700f8b2f803372ad135a7ba355682d3fcbef6ab1e949ae5ad8c4685d437b4eaa729a17904d4064099d4f7049c6cbe",
   "staticPublicIutX":"017a34ad2769e1a68bca80c0d3b5a3d6d980cc9b81af02f4c7a4dbef72e6c3817bcd61660e71f883de3eb891d24b03d7c4a355d3",
    "staticPublicIutY":"008a111fcd9b24dc28c318e9832e598579a5757d81beeab2cc9abbecb8f22194bea467970de0e99b2e9fea7b53dfde457a09ac3d",
    "ephemeralPrivateIut":"00fa2c06be1a4043f00f4a6fcc65189353a1c4a4d474c0481087db194a5e3ffce4ecd1aa6d9568cb847c22ae510f84e68c3df58d",
    "ephemeralPublicIutX":"013c06618a28208b1acdc7a233c53d1e0e9ea77c2dc71c45e703f53bbdc9bacb75104a8be3eb8524cfc4676ceda8dd0faf92f141",
    "ephemeralPublicIutY":"0146c14a61ee963602f40289769e2418b02bfc3c778fe8e4a70c5615482bba781e337169126e70b0ad9af05acf81164b033f2bd6",
    "z":"00366d01289c14c31734c56d4cf7bef767318c36cd1c76329302c4ff2d500ce85d01b6839aa851b2a3834251d61aa46a602cf303",
    "macData": "4b435f325f564341565369646b606d9a64057a81200e0e7dd00e9aab63f089bf6b23e9dcbed36e7377972c365a1d37d842e78c1fee50c606b3d12b33ebb419758c45d8605f8fa4ce652911e654c24efb02861f7d265605038449ac23e1939c497d40f8e9187a5ea224b2b633948a901ff4cc8787fd56b680013c06618a28208b1acdc7a233c53d1e0e9ea77c2dc71c45e703f53bbdc9bacb75104a8be3eb8524cfc4676ceda8dd0faf92f1410146c14a61ee963602f40289769e2418b02bfc3c778fe8e4a70c5615482bba781e337169126e70b0ad9af05acf81164b033f2bd6",
    "oiLen":376,
    "oi":"6b606d9a64434156536964ac58b58d8a93dd86c698f0d97734fec1c7af8541e92229ce48d1796a1b4ef8666181b9ab",
    "idIutLen":40,
    "idIut":"6b606d9a64",
    "dkm":"792febdd0e0f9fa4b2b2b5d902ec9cb9238646b249fafb8e",
    "tagIut":"7071549402f33c56537b4a2e86af2942"
}

[Kritner]

Ah thanks, I think I see the issue on our end I was able to confirm the above tc now passes with your provided tag, and able to confirm another case within that same group, and another group that was reporting failures.

I haven't been able to check that this fix works with the VAL test groups (though I suspect it does). Would you be able to provide your generated tag for the following test:

{
          "staticPublicServerX": "019D9AC69D63F472733FCEA108F5B4620F08E9E675082D9620197B8480CEEF14EFE6DE6FD7FB07217063A67513F82A4DF8F43EF3",
          "staticPublicServerY": "018E5BF863639989BD712C8278543C595A72FD66D86BBD9A64DEA4A4A1C1A28B3CB00332F4D880EED3BD7E00A605D226A3070077",
          "ephemeralPublicServerX": "01308E09994AB2B7F0849CFCB755187158A0774AA8926CB1DA50C96A552A043ED27D59EE47598926991DEFCE489BD32DF2EC8A33",
          "ephemeralPublicServerY": "007B3D2A57DC787957674299617218ABC9AB378ED5C3A4BEC8DEF9E11F95498568DEC887D093D3B74309AB8E36B85FF128351D4F",
          "staticPrivateIut": "00EB210ECEDC9835F6B2C58B23BFDF980141A3854CC4D2306BA306E5C30A95146B56E81402497AE2A606330D40D6E6BD41992917",
          "staticPublicIutX": "00F284F1BED2B959DAC0FE46FFEDE99EDECC8A4A90983B6501BB3A2E3AF75E8DC394ACF4CA694E3B1A293C5DE1428F5ACAFEFD49",
          "staticPublicIutY": "012B3EEE38EEE409F2298B7D697C97129ED34F79C8C3BCBE7E3F9D47C5D21924B6DEACC425871902C9CAE0FAEA179D3676ADF6C3",
          "tcId": 81,
          "nonceEphemeralIut": "824AF45EC5B4FAAD1127B9A14DB710CC9B074DB1F0D9F9012475424B4F89C8622515B68A838A946C83BDC7C8817B05FC5F7EA4188D25A938D577E959E17E2B18F03ADC93B3704B7F5FDAD75A128EB90DCF63897AE2F89D01A92A3ACF09F4475AD81A573A491500",
          "oiLen": 376,
          "oi": "434156536964A1B2C3D4E541378881DF6738743957CAC1A2AC70F19F1F6444AC0A4AA21E758DCB8EDFED7C2D9E0F18",
          "tagIut": "B2D4833BB52166F3C4B5775A3FB71BCB"
        }

[dghgit]

If I've understood correctly, I get: 6da6d68cc7351814a6ab709bc4d78aa. How does that sound?

[Kritner]

@dghgit I didn't realize that your tag is actually included in your submitted results, looks like we do agree on the tag now that I've corrected the issue on this end.

I'm curious when I was looking through these files that we're not actually including the iutId in the prompt file as we should. Were you just inferring the iutId from the provided macData? I'll correct that part of the file while I'm in here.

[dghgit]

We were inferring the iutId to be the default one from the old CAVS. The test harness uses that if it doesn't find one. A lucky mistake it seems.

[Kritner]

All right thanks for the confirmation @dghgit, I have a fix in place in our internal environments and it should go out in the next release to demo and prod.

The underlying issue was around the ephemeral nonce (though slightly different issue than from #900), it seems to make sense just to always treat the nonce as a byte boundary nonce, this is similar behavior to how the shared secret zs get padded to a mod 8 prior to use anyway.

[dghgit]

@Kritner sorry to hassle, but is there an expected date for an update? We've found ourselves in the position where we need to do a retest. I gather we can get a waiver to use the old CAVP system, but we'll avoid going down that path if this is likely to be fixed soon. Thanks.

[Kritner]

Sorry @dghgit we have a (at a minimum) demo release planned for this week. We have a meeting this morning and I'll see about getting it scheduled sooner rather than later.

[Kritner]

@dghgit the fix for this should be on demo in the release going out at 5est. The prod release is not yet scheduled, but once you're able to confirm the fix I can work on getting it scheduled.

[Kritner]

This change is now on demo. Please confirm the fix when you are able. I'll leave this issue open until the change has been pushed to production.

[dghgit]

Overall it looks a lot better. There seems to be something wrong with K-203 and K-409 - they don't even work for fullMQV now. K-283 on the other hand works. I've attached the transcripts.

transcripts.zip

My hunch is everything else is probably now working, I still need to run some more tests though.

[Kritner]

I'm taking a look now @dghgit, on the first test case I checked, we're coming up with the same dkm, just different tags for key confirmation. I don't think anything changed around the key confirmation in the last release, but something seems off about it on our end.

[Kritner]

A fix for this is now on demo, this was related to a not mod 8 curve and the padding used for constructing the mac data for key confirmation; as opposed to the ephemeral nonce used for not mod 8 curves like in an earlier part of this issue.

Hopefully this gets us through the remaining issues, I'm curious as to how this hasn't come up before, unless we've just not had anyone testing against these particular curves until now.

[dghgit]

The following now passing: ephemeralUnified, fullMqv, fullUnified, onePassDh, onePassMqv, onePassUnified

With staticUnified only P-224, P-256, and P-384 are working. With the other curves it appears that only the validation (VAL) tests are failing - the generation tests seem fine so the server appears to be okay with what's produced here, it's just we disagree on validation, so my end is always failing validation tests that are expected to pass.

[Kritner]

@dghgit do you have a vector set / test session id handy that I could take a look at regarding the failed val tests?

[dghgit]

Here's the set:

transcripts.zip

[Kritner]

Ok, so for tcId 81 from vsId 301031:

{
	"scheme": "staticUnified",
	"parmSet": "eb",
	"curve": "B-233",
	"tgId": 9,
	"function": "dpGen, keyPairGen",
	"testType": "VAL",
	"kasRole": "responder",
	"kasMode": "kdfKc",
	"hashAlg": "SHA2-256",
	"macType": "HMAC-SHA2-256",
	"keyLen": 192,
	"aesCcmNonceLen": 0,
	"macLen": 128,
	"kdfType": "concatenation",
	"idServerLen": 48,
	"idServer": "434156536964",
	"idIutLen": 40,
	"idIut": "A1B2C3D4E5",
	"oiPattern": "uPartyInfo||vPartyInfo",
	"kcRole": "recipient",
	"kcType": "unilateral",
	"nonceType": "randomNonce",
	"tests": [{
		"staticPrivateServer": "0097D3BE7F23F9F5C6626FD6C8206C215FA0E76ED81B4A72AB7077C83C15",
		"staticPublicServerX": "0179DBD4DA502438DDDE8DBE6FAF1913E3386A95349CCDB7E6080C3A24A0",
		"staticPublicServerY": "00F05078A344FCA415342A18425F8924E6F7F225207A77CBB311D010D9B5",
		"staticPrivateIut": "0073C2DFD284532AFC310D923FF3D368ECEFB37E5A6DD03B746ACF2884FA",
		"staticPublicIutX": "00ECD37D3E78AF82EA29455926B80C22D3F3CF8B5A9AF73BDBE04AAA6E43",
		"staticPublicIutY": "0171FB6D0DF87E44D0FF44012F06F5763947DD951AF6F23B71793E2DB724",
		"tcId": 81,
		"testPassed": true,
		"deferred": false,
		"testCaseDisposition": "Success - leading zero nibble shared secret Z.",
		"nonceDkmServer": "0E70BAB94AEED5C2077056ED7C6EF0",
		"nonceEphemeralIut": "763A0BDFF261ABD26F02174620D8DF4F06DC5EEFB2ECDE03750E5B883FBFA6E26D0F0643922019EB2FD3C174463BE3A14C89F59BD0DDA37C7DDE00",
		"oiLen": 376,
		"oi": "4341565369640E70BAB94AEED5C2077056ED7C6EFA1B2C3D4E5390BE40A3CB0C4BA97BF1D94BB461F70B2071C0CDDD",
		"z": "006E387F797C646ED2B4FBF16F09A5991C06043EC2EDF7DC1EB9ECBF19D4",
		"dkm": "3B03320B40E8D9D9A3DDCC5FC00CB0608DDD1C3A531EF2AE",
		"macData": "4B435F315F55434156536964A1B2C3D4E50E70BAB94AEED5C2077056ED7C6EF763A0BDFF261ABD26F02174620D8DF4F06DC5EEFB2ECDE03750E5B883FBFA6E26D0F0643922019EB2FD3C174463BE3A14C89F59BD0DDA37C7DDE0",
		"tagIut": "B310B840F58006AA807709848507A91F"
	}]
}

This should be a passing test as far as the server is concerned. Can you provide some of your intermediate values and the point at which our ends no longer agree?

[dghgit]

The dkm matches (we get "3b03320b40e8d9d9a3ddcc5fc00cb0608ddd1c3a531ef2ae"). There's a difference in the macData though, we get:

4b435f315f55434156536964a1b2c3d4e50e70bab94aeed5c2077056ed7c6ef0763a0bdff261abd26f02174620d8df4f06dc5eefb2ecde03750e5b883fbfa6e26d0f0643922019eb2fd3c174463be3a14c89f59bd0dda37c7dde00

In the example above it looks like the last four bits of the nonceDkmServer has been dropped and it has been added to the macData string as 0E70BAB94AEED5C2077056ED7C6EF and the last 4 bits of the nonceEphemeralIut has also been dropped.

With the corrected macData I get 53135100f8e7d65ce066e65012b505a6 for the tagIut - there might be something going on with input to the mac calculation as well - I don't see "B310B840F58006AA807709848507A91F" even if I change the macData to the value in the example I get "599b743c21ba8f91a8c65ebe9615ec1a" there might be a nibble getting dropped on input there as well.

[Kritner]

Thanks @dghgit that helped. This is another similar situation to the other parts of this issue - related to a non mod 8 curve and nonces created for in this case static schemes.

I had been generating nonces with a bitlength of "the curve length" rather than doing "the curve length to the next (or current) mod 8". This was fixed for (seemingly) all the schemes except for static scheme nonces.

I'll get this fixed deployed to demo and let you know when it's out there. Sorry about that!

[Kritner]

The fix for static schemes and non mod 8 curves has been pushed to demo

[dghgit]

It works! I think the quest (well at least this one) is now complete. All schemes are now passing. Thanks.