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

[Michael StJohns <[e-mail]>]

On 9/16/2013 6:47 PM, Juraj Somorovsky wrote:
> Hi Mike,
>
> On 09/06/2013 06:10 AM, Michael StJohns wrote:
>> That still leaves a second problem.  The "key expansion" stage produces
>> both private (key material) and public (iv data) by producing a key
>> stream and then splitting up (based on the sizes of keys needed) into
>> the 4 keys and 2 IVs.
>>
>> o Consider  an application that needs to produce 2 128 bit AES keys and
>> 2 IVs (for say GCM).
>> o Consider that an attacker (or a hacked program that's being used to
>> extract keys) re-runs the derivation using the same master key and same
>> random data, this time specifying zero length keys (or 64 bits of keys
>> etc), but still asks for the IV material.
>>
> Just a quick questions:
> I do not know if I understand this scenario correctly...but how can this
> be achieved in TLS?
> New key/IV material is always generated from client's as well as
> server's random. The attacker can choose the same client random, but he
> cannot influence the server random... thus always new key/IV material is
> generated.

This isn't about influencing the new key, but being able to extract the 
old key.  Assume the attacker a) has use of the master key (either 
because he's running as hacked code, or because he managed to capture 
the PKCS11 pin and has access to the PKCS11 module), b) has captured all 
the necessary public data (e.g. has the previous random values from 
listening to the TLS exchange).   He then calls PKCS11 with the master 
key, the random data, but specifies that he needs smaller (e.g. no) mac 
and encryption keys.  The part of the key stream previously assigned to 
the mac and encryption keys (and safely protected inside the PKCS11 
module) is now assigned to the IV part of the structure and is now 
accessible to the attacker/caller of the module.   That attacker then 
takes that data and sends it off to someone who can intercept the 
traffic somewhere in the middle. There are a number of sub-scenarios 
which are dependent on where the PKCS11 module is, and where the 
attacker is and where the data is intercepted.

>
> Maybe in a PKCS11 scenario this is different?
>> The part of the key stream previously assigned to the encryption keys is
>> now assigned to the IV material.  Since IVs by their nature are public,
>> the attacker now has direct access to the key material previously used
>> for encryption.
>>
>> Fortunately, TLS1.1 changed the way IVs were calculated making it
>> possible to prohibit that leaking.  Unfortunately, the CCM and GCM
>> mechanisms for TLS1.2 decided to use the IV values making impossible to
>> prohibit the leaking.
>>
>> For the current PKCS11 draft, we finessed it by creating two mechanisms
>> - one that created only key material, and one that created key material
>> and IVs.  PKCS11 allows a specific key to be constrained to a specific
>> mechanism so that permits some security for the non-AEAD suites.  It's
>> not ideal, but its a beginning
> I would propose to make it more concrete for PKCS11 and generate the
> keys depending on the algorithms they are used in. For example, if you
> have a master_secret used to generate keys for AES_GCM and AES_CBC, you
> would use:
> k_GCM = PRF(master_secret, "AES_GCM", [further params])
> k_CBC = PRF(master_secret, "AES_CBC", [further params])

As long as you can control the length of the encryption and mac key in 
the call to PKCS11, you have an issue if you can produce IV material 
from the same key stream you use to produce encryption or mac keys.    
If you're suggesting using the above for generating IV material, it's 
doable, but maybe a bit of overkill.  I'd rather generate the IV from 
the public information only (e.g. only use the random data as the PRF seed).

Mike


>
> This ensures that the attacker cannot enforce the same key is used for
> two different algorithms, which could lead to some specific attacks (for
> more information see our paper on Backwards compatibility attacks:
> http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/)
>
> Best Regards
> Juraj
>
>