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

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

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.

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])

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