Subject: [jose] Issue #13 - use AES-GCM for Key Wrapping

From: "Jim Schaad" <[email-masked]>
Date: Tue, 25 Jun 2013 09:53:22 -0700

We now have two documents - one from Richard and one from Mike - which
provide the two different ways that have been proposed for doing key
wrapping with an AEAD algorithm.

Please review the two documents and provide comments to the list.

Jim

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 27 Jun 2013 12:40:05 +1000

I don't think we should standardize draft-jones-jose-aes-gcm-key-wrap-00. No rationale is apparent. We already have an AES-based key wrap algorithm (A128KW, A256KW), which has a 64-bit size overhead. The AES-GCM key wrap algorithm in this draft add almost no useful properties, but has a 224-bit size overhead.

I like the concatenation of the IV, ciphertext, and tag byte arrays. But doing this here while content encryption serializes the same values as dot-separated B64 blobs does smell of poor ad hoc design. It is nice to highlight how a previous choice complicates extending JOSE to other algorithms, but only if we then fix that previous choice.

If the additional authenticated data (AAD) was used to bind the CEK algorithm id (or other context info, as ConcatKDF does) to the wrapped key, then there would at least be an extra security property that would make this key wrap algorithm worth considering. For instance, instead of AAD being empty, AAD could be the "key wrap: " + "enc" value.

By reusing a CEK algorithm as a KEK algorithm, and supporting direct encryption, we substantially increase the risk that an attacker can rearrange some encrypted content so a legitimate recipient treats it as an encrypted key leading to security flaws.

For example, Alice sends "Start of PIN = 8" confidentially to Bob:
  {alg:dir,enc:A128GCM,kid:1}..iv.ciphertext.tag
An attacker seeing this JOSE message learns nothing about the 1st digit of the PIN.
But if the attacker sends 10 messages to Bob for 10 guess of that digit:
  {alg:A128GCMKW,enc:A128GCM,kid:1}.iv|ciphertext|tag.ivN.ciphertextN.tagN
where ivN.ciphertextN.tagN are calculated using an AES key of "Start of PIN = <N>", then 9 messages will cause errors, while 1 message will be accepted -- revealing the supposedly confidential information in 10 guesses instead of 2^128.

Actually the above attack does not quite work for the compact encoding as AAD is never empty for content encryption. I not certain for the JSON encoding. In any case, an explicit and unambiguous AAD value for key wrapping would be good.

Finally, a key wrap algorithm like this should go to the IETF crypto group (CRFG) instead of being invented in JOSE. We have already spent a year unpicking a JOSE-special AEAD algorithm.

--
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jim Schaad
> Sent: Wednesday, 26 June 2013 2:53 AM
> To: [email-masked]
> Subject: [jose] Issue #13 - use AES-GCM for Key Wrapping
> 
> We now have two documents – one from Richard and one from Mike – which

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 27 Jun 2013 09:48:46 -0700

James,

The small devices use case does present a reason for wanting to use AES-GCM rather than AESKW for this case.  Specifically, there is no need to have silicon devoted to doing AES decrypt.  All operations can be done just with AES encrypt.

jim

> Manger, James H
> Sent: Wednesday, June 26, 2013 7:40 PM
> To: [email-masked]
> Subject: Re: [jose] Issue #13 - use AES-GCM for Key Wrapping
> 
> I don't think we should standardize draft-jones-jose-aes-gcm-key-wrap-00. No
> rationale is apparent. We already have an AES-based key wrap algorithm
> (A128KW, A256KW), which has a 64-bit size overhead. The AES-GCM key
> wrap algorithm in this draft add almost no useful properties, but has a 224-bit
> size overhead.
> 
> I like the concatenation of the IV, ciphertext, and tag byte arrays. But doing
> this here while content encryption serializes the same values as dot-separated
> B64 blobs does smell of poor ad hoc design. It is nice to highlight how a
> previous choice complicates extending JOSE to other algorithms, but only if
> we then fix that previous choice.
> 
> If the additional authenticated data (AAD) was used to bind the CEK algorithm
> id (or other context info, as ConcatKDF does) to the wrapped key, then there
> would at least be an extra security property that would make this key wrap
> algorithm worth considering. For instance, instead of AAD being empty, AAD
> could be the "key wrap: " + "enc" value.
> 
> By reusing a CEK algorithm as a KEK algorithm, and supporting direct
> encryption, we substantially increase the risk that an attacker can rearrange
> some encrypted content so a legitimate recipient treats it as an encrypted key
> leading to security flaws.
> 
> where ivN.ciphertextN.tagN are calculated using an AES key of "Start of PIN =
> <N>", then 9 messages will cause errors, while 1 message will be accepted --
> revealing the supposedly confidential information in 10 guesses instead of
> 2^128.
> 
> Actually the above attack does not quite work for the compact encoding as
> AAD is never empty for content encryption. I not certain for the JSON
> encoding. In any case, an explicit and unambiguous AAD value for key
> wrapping would be good.
> 
> Finally, a key wrap algorithm like this should go to the IETF crypto group
> (CRFG) instead of being invented in JOSE. We have already spent a year
> unpicking a JOSE-special AEAD algorithm.
> 
> --
> James Manger
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Jim Schaad
> > We now have two documents   one from Richard and one from Mike   which
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Matias Woloski <[email-masked]>
Date: Thu, 27 Jun 2013 21:37:09 -0300

While I like the detailed examples of barnes draft. I have to agree, that
the explosion of combinations is not good for implementers. It's
overwhelming and doesn't foster interop on the open web. Look at XMLEnc and
all the options you have, imho that's why standards don't end up being
adopted wildly in every language (only some of those algos end up being
implemented in each language creating an interop nightmare). Jones draft is
simple enough (although it would be good to add some examples).

On Thu, Jun 27, 2013 at 1:48 PM, Jim Schaad <[email-masked]> wrote:

> James,
>
> The small devices use case does present a reason for wanting to use
> AES-GCM rather than AESKW for this case.  Specifically, there is no need to
> have silicon devoted to doing AES decrypt.  All operations can be done just
> with AES encrypt.
>
> jim
>
> > An attacker seeing this JOSE message learns nothing about the 1st digit
> of the
> > PIN.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 Jun 2013 08:14:21 +0200

Well, we actually like to use AES-CCM in the small devices.
Not having to do AES decrypt is a good thing, indeed.

Sent from my mobile device

---

From: "Peck, Michael A" <[email-masked]>
Date: Mon, 1 Jul 2013 04:49:08 +0000

The concerns I raised in issue #28 also apply here, though the potential consequences may be worse here since it's keys that are being encrypted.  
GCM is not safe to use without automated key management.  

ECDH-ES+AES128GCMKW / ECDH-ES+AES256GCMKW seem OK, but AES-GCM Key Wrap directly using a pre-shared key is unsafe.  

I don't think adding Security Considerations text is sufficient, because it's not practical to expect implementations will be able to keep track of how many times the same pre-shared key has been used.

As there appears to be a use case for AES-GCM Key Wrapping, could we explore options to try to ensure a new key is used for each AES-GCM Key Wrap operation?  For example, run the pre-shared key through the Counter Mode KDF (NIST SP 800-108 Section 5.1) to get the AES-GCM Key Wrap Key -- the KDF could mix in information like algorithm identifiers (might help prevent the issue James Manger pointed out of mixing up AES-GCM Content Encryption with AES-GCM Key Wrap, though I still think direct encryption should be prohibited with AES-GCM Content Encryption) and  a sender-provided random value (to make sure a new key is used each time).
Section 2 of SP 800-108 says its KDFs can be used to derive keys from a pre-shared key.

Mike

>Carsten Bormann
>Sent: Friday, June 28, 2013 2:14 AM
>To: Jim Schaad
>Cc: Manger, James H; <[email-masked]>
>> The small devices use case does present a reason for wanting to use AES-
>GCM rather than AESKW for this case.  Specifically, there is no need to have
>silicon devoted to doing AES decrypt.  All operations can be done just with AES
>encrypt.
>>
>> jim
>>
>>> An attacker seeing this JOSE message learns nothing about the 1st digit of
>the
>>> PIN.