All,
I ve uploaded a draft document for RSA KEM and ECDH key agreement in an attempt to address this.
Sincerely,
Jonathan
From: Daniel Minder <
Daniel.Minder@utimaco.com>
Sent: Tuesday, September 8, 2020 11:20 AM
To: Jonathan Schulze-Hewett <
schulze-hewett@infoseccorp.com>;
pkcs11@lists.oasis-open.org Subject: RE: [pkcs11] CKM_ECDH_AES_KEY_WRAP investigation
Jonathan, All,
thank you for your input. What you describe for RSA-KEM is quite similar to CKM_RSA_AES_KEY_WRAP.
The crucial point is what you state at the beginning: To decrypt, you need to know the length of the RSA key, the KDF information, and the size of the symmetric key.
This is true for all such schemes (or implicit protocols) where two blobs are concatenated. For RSA, you can deduce the length of the encrypted random value from the RSA key because there is only one possible encoding. However, for CKM_ECDH_AES_KEY_WRAP
the first part is a temporary (transport) public EC key, which can be encoded in different formats of different length. In that case, splitting the concatenated blob becomes cumbersome as I ve elaborated in my previous mail.
The same approach as CKM_RSA_AES_KEY_WRAP or CKM_ECDH_AES_KEY_WRAP might be used for future asymmetric PQC algorithms. However, the exact encoding of the two parts of the final BLOB need to be described each time. Therefore, I would assume
that a new mechanism (CKM_XXX_AES_KEY_WRAP) has to be invented every time.
Your remark concerning NIST SP800-56a rev3 is very valid. IFF there is no current implementation of CKM_ECDH_AES_KEY_WRAP anywhere we could now 1. define a format for the public key part of the BLOB and 2. switch to the cofactor primitive
to get a NIST compliant key wrapping algorithm.
In any case we should do #1, and for #2 we could also add CKM_ECDH_COF_AES_KEY_WRAP (or something like that).
Regards,
Daniel
From:
pkcs11@lists.oasis-open.org <
pkcs11@lists.oasis-open.org>
On Behalf Of Jonathan Schulze-Hewett
Sent: Donnerstag, 3. September 2020 15:50
To:
rrelyea@REDHAT.COM;
pkcs11@lists.oasis-open.org Subject: RE: [pkcs11] CKM_ECDH_AES_KEY_WRAP investigation (WARNING!!! S/MIME with incorrect signature)
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
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.