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

[Michael StJohns <[e-mail]>]

On 9/24/2013 5:21 PM, Juraj Somorovsky wrote:
> On 09/23/2013 10:30 PM, Michael StJohns wrote:
>>> TL;DR: you can recover low entropy GCM plaintexts if the same key is used
>>> in a mode like CBC.
>> Right.  But you can't recover the key.
>>
>> Let me reiterate the threat model:
>>
>> 1) All keys are kept in an HSM (not supposed to be extracted - but TLS
>> KDF trivially allows this)
>> 2) Attacker has access to use the keys (e.g. either has HSM credentials,
>> or has hacked the program using the HSM that has HSM credentials - the
>> TLS stack for example).
> You are right, the attacks do not apply to your scenario since they do
> not recover the key.
>
> ...Sorry, my last one attack scenario :) ...assuming you are going to
> use your KDF taking as input the key length. This would mean you would
> generate the same key for AES-128 and RC4? (both have the key lengths of
> 16 bytes)
>
> If the user would use AES-128, the attacker could force the HSM to
> regenerate a new key for RC4 (in this case the same key as for AES-128
> would be generated) and generate the RC4 keystream. Afterwards, he could
> run one of the attacks against RC4 to learn the original RC4 key (and
> thus also the AES key).
>
> Does it make sense?

Yes.  But preventing that requires a different/additional set of policy 
protections to be built into PKCS11.  I'm working on them in the PKCS11 
group.  The general idea is provide a way to specify mandatory policies 
(e.g. key types) for keys derived from other keys.  That problem is 
broader than just the KDFs used for TLS.

In some ways, the right answer to the above threat is to prevent the 
module from actually providing RC4 based keys and mechanisms.  Ah well....

Mike



> Thanks
> Juraj
>
>