[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] CKM_ECDH_AES_KEY_WRAP investigation
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.
This is compounded by the fact that the wrapped key and the
public key are one concantenated blob. This is a problem because
it generates an implicit protocol. If the application where using
this mechanism 'blindly', some other tool (not PKCS #11) would
still need to understand this wrapped format to interoperate. The
mechanism should have separated the public key and the wrapped
key, but it didn't.
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?
Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen â€“ Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO
This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.