line 7288: I will add the line break, to have same formatting as in C_WrapKey and C_UnwrapKeyAuthenticated.
line 7379: The proposal stated "wrapped" as well. Comparing to C_WrapKeyAuthenticated I agree that the sentence should say "unwrapped". Comparing to C_UnwrapKey I noticed that C_UnwrapKey does not include this sentence at all; and I don't know whether there is a specific reason for not having this sentence in C_UnwrapKey. In order to achieve consistency, the sentence in line 7379 should either be removed, or the same sentence also be added to C_UnwrapKey.
Original Message:
Sent: 07-11-2024 12:36
From: Darren Johnson
Subject: Comments on pkcs11-GCM-CCMWrapIVnonceupdate
THALES GROUP LIMITED DISTRIBUTION to email recipients
100% agree on the attribute discussion.
Dieter, here are two more minor comments on the draft you uploaded.
line 7288
"Of course, tokens vary in which types of keys can actually be wrapped with which mechanisms. To"
If we want to mirror C_Wrapkey, there should be a line break before the "To".
line 7379
Should this line say "which types of keys can actually be unwrapped with which mechanisms" instead of "which types of keys can actually be wrapped with which mechanisms"?
I could argue it either way. But as this is the C_UnwrapKeyAuthenticated, maybe it should say "unwrapped".
Thanks
Darren
Original Message:
Sent: 7/11/2024 12:12:00 PM
From: Robert Relyea
Subject: RE: Comments on pkcs11-GCM-CCMWrapIVnonceupdate
It's really hard for us to add attributes without a external standard to point to. All application could choose to add attributes by hand, but we really can't at the PKCS #11 layer because other applications need to use our primitives to implement their specific standards. Say we add implicit attributes through the AAD, then someone uses AES-GCM to encrypt their private key for PKCS #12. Suddenly their use of AES-GCM will be incompatible with other implementations of PKCS #12.
If there were a separate OASIS, or ietf, or ansi standard for how to wrap keys with attributes using GCM, we could then define a mechanism to do that new standard (and specify what parts of that standard map to PKCS #11 attributes and how much the mechanism automatically puts together). The best example of this is CKM_RSA_PKCS signing and encryption. We specify that the mechanism adds the RSA PKCS #1 wrapper, but not the DER encoded hash oid and hash value while CKM_SHA256_ RSA_PKCS does all the hashing and provides both.
------------------------------
Robert Relyea
Principle Software Engineer
Red Hat
Mountain View CA
Original Message:
Sent: 07-10-2024 12:32
From: Darren Johnson
Subject: Comments on pkcs11-GCM-CCMWrapIVnonceupdate
THALES GROUP LIMITED DISTRIBUTION to email recipients
Thanks Dieter!
That all sounds good. I'll take a look at the updated draft.
I remember the Cryptosense proposal. I forget how/why that never progressed any further.
While I do think we should have a way to include attributes when wrapping keys, I don't know if I entirely agree with Roberts suggestion to include the attributes in the AEAD data as in some use cases key attributes may be considered as sensitive information. If they were part of the AEAD data, then they would be fully exposed once outside of the token. For most use cases, this probably wouldn't be an issue. And it would be a benefit as it would allow the attributes to be visible/searchable.
It will be something to discuss if/when we move this topic forward.
Thanks
Darren
Original Message:
Sent: 7/10/2024 8:39:00 AM
From: Dieter Bong
Subject: RE: Comments on pkcs11-GCM-CCMWrapIVnonceupdate
Hi Darren,
thank you for sharing Robert's feedback. I have fixed selected feedback in WD04, for details see my comments inline below. I leave Robert's other feedback until we have discussed in our next TC meeting.
@All,
Robert's suggestion "it would be great if there was a specification of a default method to serialise the key's attributes. I think the use of AEAD is in most cases to bind the attributes to the wrapping ..." reminded me of Cryptosense's proposal https://groups.oasis-open.org/higherlogic/ws/public/document?document_id=58091&wg_id=922ef643-1e10-4d65-a5ea-018dc7d3f0a4 "Adding attributes to Wrapped keys" that we discussed back in 2016.
Thanks,
Dieter
| Hi, I received some feed back from Robert Künnemann <robert.kuennemann@uni-saarland.de>, who originally asked for for support for authenticated wrap/unwrap. He sent the comments directly to me, and I have echoed them below. Most of the comments may require some updates on the wording used for clarification purposes. I think we can probably accommodate those. There are questions that are related to AEAD data and encoding of attributes. While it is an important and useful feature, it won't be something we try to solve as part of this proposal. Thanks Darren Thanks! I finally found the time to meet up with Alexander Dax (in CC), who is a colleague at CISPA and authored the related paper cispa.de/de/research/publications/... with me. Most of the comments are trivial, some might be important but it may just be that we misinterpreted the text (which we hope is also helpful in removing ambiguities). Section 2, or 5.18 > • CK_*_MESSAGE_PARAMS with a mechanism as opposed to passing in the IV (GCM) or nonce (CCM) this can then be used as part of the mechanism standard CK_*_MESSAGE_PARAMS for C_UnWrapAuthenticated. A full stop is missing here. [DB] Fixed in WD04. > pAssociatedData and ulAssociatedDataLen specify the associated data for an AEAD mechanism; We could not really find how the associated data is specified, this seems to be an application matter. This is very flexible, but (from a user perspective) it would be great if there was a specification of a default method to serialise the key's attributes. I think the use of AEAD is in most cases to bind the attributes to the wrapping, as serialisation if not always easy this could otherwise encourage developers to encode informal key "roles" in the associated data. If this is done well, all is fine, if the intended attributes of key "roles" change over time, this could have unintended effects on security. Section 3.3. or 6.13.3 > • If ulIvFixedBits is not zero, then the most significant bits of pIV contain the fixed IV. If ivGenerator is set to CKG_NO_GENERATE, pIv is an input parameter with the full IV. - could be precised to say the " ulIvFixedBits most significant bits contain" [DB] Fixed a total of 6 occurencies in WD04. - the text is not explicit what happens if ulIvFixedBits is zero (implicitly it is clear, though) > • Call C_WrapKeyAuthenticated() for CKM_AES_GCM mechanism wrapping key wK. wrapped key, parameter and obtaining a wrapped key and authentication tag output in the parameter block. This sentence, in its current form, leaves the mechanism underspecified, but I think it is work in progress. > On WrapKeyAuthenticated, the meaning of ivGenerator is as follows: CKG_NO_GENERATE means the IV is passed in on WrapKeyAuthenticated and no internal IV generation is done. CKG_GENERATE means that the non-fixed portion of the IV is generated by the module internally. The generation method is not defined. > CKG_GENERATE_COUNTER [..] The text formatting made us think that CKG_GENERATE and CKG_NO_GENERATE are the two possible values of one parameter, and then CKG_GENERATE_COUNTER etc. the possible values of another parameter that is only relevant if ivGenerator=CKG_GENERATE. A paragraph break before CKG_GENERATE and CKG_NO_GENERATE could help here. [DB]: When integrating the proposal into WD04, I also felt that inserting a paragraph break before CKG_GENERATE improves readability. I did so in sections existing sections 6.13.2 and 6.13.4 (previously 6.13.3), and new sections 6.13.3 and 6.13.5. > CKG_GENERATE_COUNTER means that the non-fixed portion of the IV is generated by the module internally by use of an incrementing counter, the initial IV counter is zero. > CKG_GENERATE_COUNTER_XOR means that the non-fixed portion of the IV is xored with a counter. The value of the non-fixed portion passed must not vary from call to call. Like CKG_GENERATE_COUNTER, the counter starts at zero. - The terminology is unusual and could lead to confusion. IV stands for initialisation vector (as you know, of course) so initial IV does not really make sense. I think "IV counter" aims to describe the auxillary values in modes of operation that are typically described as "counters" or "nonces". I feel the word "nonce" is a natural choice her, as "counter" designates a specific choices of nonce generation here, judging from the other values. - CKG_GENERATE_COUNTER_XOR rings some alarm bells for us. "The value of the non-fixed portion passed must not vary from call to call. " -- this sounds like a constraint for the API user to us. We were not sure about this, but in case the user *can* set the non-fixed portion of the IV then, even if the initial counter value is unique, there is the possibility of creating clashes in IV+counter which could lead to OTP attacks and key leakage. We hope this was just a misinterpretation on our part, but then this paragraph could be clearer on who generated the non-fixed portion. - Is there a minimal size for the non-fixed portion? If the non-fixed portion is guessable, key secrecy is lost again. - CWrapkey is sometimes written without the capital K. [DB] Fixed in WD04. We hope that our comments are not totally out of date by now and that the nitpicks are also helping a bit. Cheers, Robert
------------------------------
Darren Johnson
THALES
------------------------------
| |
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
Managing Directors: Stefan Auerbach, Martin Stamm, Hacan Tiwemark
You will find our data protection information for customers and business partners here.
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.
Original Message:
Sent: 7/3/2024 4:15:00 PM
From: Darren Johnson
Subject: Comments on pkcs11-GCM-CCMWrapIVnonceupdate
Hi,
I received some feed back from Robert Künnemann <robert.kuennemann@uni-saarland.de>, who originally asked for for support for authenticated wrap/unwrap.
He sent the comments directly to me, and I have echoed them below. Most of the comments may require some updates on the wording used for clarification purposes. I think we can probably accommodate those.
There are questions that are related to AEAD data and encoding of attributes. While it is an important and useful feature, it won't be something we try to solve as part of this proposal.
Thanks
Darren
Thanks! I finally found the time to meet up with Alexander Dax (in CC), who is a colleague at CISPA and authored the related paper
https://cispa.de/de/research/publications/2895-how-to-wrap-it-up---a-formally-verified-proposal-for-the-use-of-authenticated-wrapping-in-pkcs-11
with me. Most of the comments are trivial, some might be important but it may just be that we misinterpreted the text (which we hope is also helpful in removing ambiguities).
Section 2, or 5.18
> • CK_*_MESSAGE_PARAMS with a mechanism as opposed to passing in the IV (GCM) or nonce (CCM) this can then be used as part of the mechanism standard CK_*_MESSAGE_PARAMS for C_UnWrapAuthenticated.
A full stop is missing here.
> pAssociatedData and ulAssociatedDataLen specify the associated data for an AEAD mechanism;
We could not really find how the associated data is specified, this seems to be an application matter. This is very flexible, but (from a user perspective) it would be great if there was a specification of a default method to serialise the key's attributes. I think the use of AEAD is in most cases to bind the attributes to the wrapping, as serialisation if not always easy this could otherwise encourage developers to encode informal key "roles" in the associated data. If this is done well, all is fine, if the intended attributes of key "roles" change over time, this could have unintended effects on security.
Section 3.3. or 6.13.3
> • If ulIvFixedBits is not zero, then the most significant bits of pIV contain the fixed IV. If ivGenerator is set to CKG_NO_GENERATE, pIv is an input parameter with the full IV.
- could be precised to say the " ulIvFixedBits most significant bits contain"
- the text is not explicit what happens if ulIvFixedBits is zero (implicitly it is clear, though)
> • Call C_WrapKeyAuthenticated() for CKM_AES_GCM mechanism wrapping key wK. wrapped key, parameter and obtaining a wrapped key and authentication tag output in the parameter block.
This sentence, in its current form, leaves the mechanism underspecified, but I think it is work in progress.
> On WrapKeyAuthenticated, the meaning of ivGenerator is as follows: CKG_NO_GENERATE means the IV is passed in on WrapKeyAuthenticated and no internal IV generation is done. CKG_GENERATE means that the non-fixed portion of the IV is generated by the module internally. The generation method is not defined.
> CKG_GENERATE_COUNTER [..]
The text formatting made us think that CKG_GENERATE and CKG_NO_GENERATE are the two possible values of one parameter, and then CKG_GENERATE_COUNTER etc. the possible values of another parameter that is only relevant if ivGenerator=CKG_GENERATE. A paragraph break before CKG_GENERATE and CKG_NO_GENERATE could help here.
> CKG_GENERATE_COUNTER means that the non-fixed portion of the IV is generated by the module internally by use of an incrementing counter, the initial IV counter is zero.
> CKG_GENERATE_COUNTER_XOR means that the non-fixed portion of the IV is xored with a counter. The value of the non-fixed portion passed must not vary from call to call. Like CKG_GENERATE_COUNTER, the counter starts at zero.
- The terminology is unusual and could lead to confusion. IV stands for initialisation vector (as you know, of course) so initial IV does not really make sense. I think "IV counter" aims to describe the auxillary values in modes of operation that are typically described as "counters" or "nonces". I feel the word "nonce" is a natural choice her, as "counter" designates a specific choices of nonce generation here, judging from the other values.
- CKG_GENERATE_COUNTER_XOR rings some alarm bells for us. "The value of the non-fixed portion passed must not vary from call to call. " -- this sounds like a constraint for the API user to us. We were not sure about this, but in case the user *can* set the non-fixed portion of the IV then, even if the initial counter value is unique, there is the possibility of creating clashes in IV+counter which could lead to OTP attacks and key leakage. We hope this was just a misinterpretation on our part, but then this paragraph could be clearer on who generated the non-fixed portion.
- Is there a minimal size for the non-fixed portion? If the non-fixed portion is guessable, key secrecy is lost again.
- CWrapkey is sometimes written without the capital K.
We hope that our comments are not totally out of date by now and that the nitpicks are also helping a bit.
Cheers, Robert
------------------------------
Darren Johnson
THALES
------------------------------