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

[Michael StJohns <[e-mail]>]

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.



> 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?

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?  If not, then 
it's a don't care for PKCS11 I think.

>
> This solution however assumes that if k_GCM is generated, the attacker
> cannot enforce the PKCS11 module to use it for the AES-CBC computation.
> Again, I am not that familiar with PKCS11...can this be achieved in a
> typical PKCS11 module?
>
> In other words: can a PKCS11 module admin/user enforce that if a
> specific material is derived with a "AES-GCM" parameter, the resulted
> key can only be used in AES-GCM?

The admin can restrict a specific key to a specific set of mechanisms - 
e.g. CKM_AES_GCM.  There are some problems with this approach which 
we're working through having to do with how the restrictions are set and 
how they're retained across derivations.

Mike


>
> Thanks
> Juraj
>