[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: CKM_ECDH_AES_KEY_WRAP investigation
A suggestion for the output of this mechanism: make the first byte the version of the output format. Then we can use the version to determine whether or not the public key is DER encoded. Version “4” would remain ambiguous for existing implementations. This would also allow future updates to the output format.
Dieter added a pointer to his last “Update to AES Key wrap specification_V2.docx” upload saying that I’m investigating Timo’s questions on CKM_ECDH_AES_KEY_WRAP in https://markmail.org/message/yzttolaqlbnts7dm So, here is my report.
Timo is right:
- The format of the public key that becomes part of the final CKM_ECDH_AES_KEY_WRAP output is not defined.
- CKA_EC_POINT requires DER encoding of the public key
- CK_ECDH1_DERIVE_PARAMS.pPublicData MUST accept the raw form, but only MAY accept DER encoded version. However, CKM_ECDH1_DERIVE is used internally by CKM_ECDH_AES_KEY_WRAP.
CKM_ECDH_AES_KEY_WRAP currently specifies for unwrapping: “Splits the input into two parts. The first part is the public key material of the transport key and the second part is the wrapped target key. The length of the first part is equal to the length of the public key material of the unwrapping EC key.”
If DER encoding was used the length could be directly taken from ASN.1 header and it would not necessary to look at the length of the public key of the unwrapping EC key. In that case, the last sentence in the specification does not make sense.
The length of the public key of the unwrapping EC key (L) is only needed if raw format is used. Then, the first part is either L+1 or 2*L+1 octets long (compress or uncompressed/hybrid format), and the format used can be distinguished by the first byte.
What should NOT be done in my opinion: support both DER encoding and raw format. The reason is that there is seems to be quite inconvenient and error prone for a PKCS#11 provider/token to distinguish ASN.1 octet string from raw uncompressed format since the first byte is 04 for both of them and the length of the first part is not known.
It's probably easier to require DER encoding here since then a CKM_ECDH_AES_KEY_WRAP wrapping can be easily created manually.
And it’s possible to add additional checks on unwrapping since the length of the public key is encoded in the blob, which can be checked against the private key used for unwrapping.
(At the same time, we could raise the requirement for CK_ECDH1_DERIVE_PARAMS.pPublicData from MAY to SHOULD accept DER…)
The question is now: has any vendor already implemented CKM_ECDH_AES_KEY_WRAP and is using raw format for the first part?
Description: S/MIME cryptographic signature