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.