All,
Bob asked for protocol level documentation that could act as an example for CKM_ECDH_AES_KEY_WRAP. The closest thing Iâve found is RFC 5990 which covers RSA-KEM in CMS and requires the output of a random value encrypted with the RSA public key of the recipient and the AES wrapped symmetric key. Basically to wrap/encrypt a symmetric key:
- Generate a random value approximately the same size as the RSA public key
- Encrypt the random value with the RSA public key
- Use a KDF to derive a key encryption key (KEK)
- Wrap the input symmetric key with the KEK
- Output the encrypted random value concatenated with the wrapped symmetric key
To decrypt, you need to know the length of the RSA key, the KDF information, and the size of the symmetric key. This additional data and the output of the KEM/Wrap is conveyed in the RecipientInfo field of the resulting CMS data.
This basic key wrapping mechanism (generate a random value, encapsulate, derive, wrap) appears to be how all the PQC KEM algorithms are designed to be used.
PKCS#11 has the functions to do most of this in a generic way:
Encrypt:
C_DeriveKey with mechanism CKM_ECDH1_COFACTOR_ONE_PASS_UNIFIED, CKM_KEM (which should cover RSA and PQC since the key type defines the algorithm to use), etc., takes the base public key and creates a new object whose CKA_VALUE contains the shared secret, and a new attribute CKA_SHARED that holds either the ECDH/DH ephemeral public key or the wrapped random value (whatever the âsharedâ information needs to be).
C_DeriveKey with a KDF mechanism (this might take some doing as most of the KDFs are defined as parameters), takes the key output from the first call, performs the KDF on the CKA_VALUE attribute as usual, and creates a new key object whose CKA_VALUE is the derived key as usual.
C_Encrypt/C_Wrap as usual with AES key wrapping.
Decrypt:
C_DeriveKey with the normal mechanism for ECDH or C_UnwrapKey for RSA/PQC which will create an object whose CKA_VALUE is the shared secret.
C_DeriveKey with a KDF mechanism (this might take some doing as most of the KDFs are defined as parameters), takes the key output from the first call, performs the KDF on the CKA_VALUE attribute as usual, and creates a new key object whose CKA_VALUE is the derived key as usual.
C_Decrypt/C_Unwrap as usual with AES key wrapping.
Finally, NIST SP800-56a rev3 uses the cofactor primitive for the key agreement step and CKM_ECDH_AES_KEY_WRAP does not which seems odd to me. Perhaps we should deprecate CKM_ECDH_AES_KEY_WRAP and do something more generic?
Sincerely,
Jonathan
From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Robert Relyea
Sent: Thursday, July 23, 2020 5:24 PM
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] CKM_ECDH_AES_KEY_WRAP investigation
On 7/22/20 9:12 AM, Daniel Minder wrote:
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.
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.
bob
Ã
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.