Epass2003 incorrect CMAC subkey

[popovec]

Problem Description

For some EPASS2003 tokens, AES CMAC is used to ensure the authenticity of secure messages. This code should probably correspond to the specification described in RFC4493. This specification describes the subkey derivation procedure.

K1 is derived through the following operation:
If the most significant bit of L is equal to 0, K1 is the left-shift of L by 1 bit.

Otherwise, K1 is the exclusive-OR of const_Rb and the left-shift of L  by 1 bit.

The "C" code used in the opensc driver implements this operation with the following sequence of commands:

	check = out[0];
	enc1 = BN_new();
	lenc1 = BN_new();
	BN_bin2bn(out,16,enc1);
	BN_lshift1(lenc1,enc1);
	BN_bn2bin(lenc1,k1Bin);
	if(check > 0x80){
		offset = 1; 
		k1Bin[15+offset] ^= 0x87; 
	}

I assume that there was a mistake in writing, where if(check & 0x80) should have been used instead of if(check > 0x80). Both subkeys (k1,k2) are affected by this error. The error does not always occur. The CMAC calculation is incorrect only for some keys.

I can't say for sure that the code written like this wasn't just a workaround to the epass2003 token error. This CMAC calculation is used here only for a special APDU (00 82 01 00) where a different error is corrected (no initialization vector is used for MAC calculation for this APDU).

Code was introduced in commit 622e6e2, @xaqfan as the author of this code, can you comment on it?

[Jakuje]

@FeitianSmartcardReader can probably comment on this too. I unfortunately dont have this token to check.

[FeitianSmartcardReader]

@Jakuje let me forward to our team, and would you please send email to me with your address? I will ship few samples to you too. [email protected]

[xaqfan]

I don't have the authority to merge.
Of course, with another question, I just submitted the request.
thanks

[xaqfan]

Sorry for the late reply.

[Jakuje]

Should be fixed with #2759

[popovec]

I agree, using #2759 will fix this issue. Well thank you.

[popovec]

I am closing this issue. #2759 is already merged in master.