Re: [TLS] TLS and hardware security modules - some issues related to PKCS11

["Paterson, Kenny" <[e-mail]>]

Comments in-line.

On 23/09/2013 17:29, "Michael StJohns" <[e-mail]> wrote:

>On 9/23/2013 5:20 AM, Juraj Somorovsky wrote:
>> On 09/21/2013 09:09 PM, Michael StJohns wrote:
>>> Thanks for this.  I think it can be fixed though and relatively simply,
>>> but will require changes to the key expansion step that are a bit more
>>> than I suggested:
>>>
>>> E.g. in addition to the master_key, label and random data being fed
>>>into
>>> the KDF, also feed in - in order for each output key - 2 or 4 bytes
>>>each
>>> that describe the length of the key.  And that's taken directly from
>>>the
>>> inputs for the key lengths requested.
>>>
>>> That means that any time you vary the length of ANY key in the key
>>> expansion, the entire key stream changes.
>>>
>>> It also means that there isn't a need for a separate IV sub key for the
>>> key expansion stage (I think....)
>> I do not think this is enough to solve this problem. There are
>> algorithms that have the same key and IV lengths....e.g. an AES-128 key
>> has the same length as the IV used in AES-CBC. I think this would break
>> your key derivation???
>
>The general problem here is that pretty much all encryption modes are
>based on ECB - if you can do ECB, you can do the operations that make up
>the mode.
>
>I don't think this is as much of an issue.  The DES key issue was of
>more interest because its substantially easier to brute force 2 keys of
>length 64 than it is a single key of length 128.  This appears to be no
>change in the attack surface to extract the key.
>

Agreed. But this is not the only attack of interest. See below.


>> An additional problem is that the same key would be used for the same
>> block ciphers in different modes of operation, e.g. AES-CBC would use
>> the same key as AES-GCM.
>>
>> As mentioned in my previous post, a solution would be to derive the
>> material based on the master secret and the encryption scheme / IV it is
>> used for. For example you could derive :
>> - a symmetric key for AES-GCM:
>> k_GCM = PRF(master_secret, "AES_GCM", [further params])
>> - a symmetric key for AES-CBC:
>> k_CBC = PRF(master_secret, "AES_CBC", [further params])
>> - initialization vector:
>> IV = PRF(master_secret, "IV", [further params])
>
>The issue with the above approach is that the KDF is currently pretty
>generic - a key plus some public data (e.g. the label, the random
>stuff.  I can't prevent a re-derivation using whatever label the
>attacker wants to use.  So it would be pretty easy to generate either
>k_GCM or k_CBC given the master secret and the random stuff.
>
>But mostly, I don't see this as a large threat  - how would this benefit
>an attacker with access to the master key?

Juraj was too polite to point out this paper from NDSS 2013:

http://www.isg.rhul.ac.uk/~kp/BackwardsCompatibilityAttacks.pdf


for an example of what can go wrong when the same key is used in two
different modes one of which
is subject to plaintext recovery attacks (full disclosure: Juraj and I are
co-authors on this paper along
with Tibor Jager).

TL;DR: you can recover low entropy GCM plaintexts if the same key is used
in a mode like CBC.

>The arguments against CBC tend to be with respect to attacks to recover
>the plain text, not the key.  The question I would ask for the above is
>whether being able to use the same AES key in multiple encryption modes
>provides additional attack surface to recover the key?

Not as far as we know. But if I can recover your AES-GCM plaintext,
wouldn't you
just be a little bit concerned?


>If not, then 
>it's a don't care for PKCS11 I think.

So, do you care now? :-)

Cheers,

Kenny