OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: CKM_ECDH_AES_KEY_WRAP investigation


All,

 

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.

 

Sincerely,

Jonathan

 

 

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Daniel Minder
Sent: Wednesday, July 22, 2020 11:12 AM
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] CKM_ECDH_AES_KEY_WRAP investigation

 

All,

 

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?

 

Best,

Daniel

 

 



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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]