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

["Juraj Somorovsky" <[e-mail]>]

On 09/17/2013 01:37 AM, Michael StJohns wrote:
> On 9/16/2013 6:47 PM, Juraj Somorovsky wrote:
>> 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.

Thanks for the explanation, I understand it now. If this is how PKCS11
modules could be used in SSL, I admit this is a threat and agree with
your changes.

>> 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).
Let me please extend your scenario:
o Consider  an application that needs to produce 2 128 bit AES keys.
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 64 bits of DES keys.
o Consider that the attacker can "break" DES (can get key from
plaintext-ciphertext pairs), but cannot break AES.

The part of the key stream previously used for AES is now assigned to
the DES keys. If the PKCS11 module now produces some
plaintext-ciphertext pairs, the attacker can break DES and thus gets
part of the key stream previously assigned to AES.

I admit I am not that familiar with PKCS11 modules used in
TLS...However, would this be a valid scenario?

My previous point was to extend your algorithm to force different keys
for different security algorithms.

Thanks
Juraj