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

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

On 09/25/2013 05:08 AM, Michael StJohns wrote:
>> ...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.
I understand that it is not that easy...

Are these policies going to restrict the key usage based on the KDF input?
If yes, what speaks against to use a derivation concept that takes as
input algorithm name the key is used for?

The key derivation based on the algorithm name (+ its key length) brings
the same security as yours. In addition, once your PKCS11 policy concept
is ready and implemented in HSMs, one could define new policies based on
the input of the KDF and restrict the usage of the derived keys.
> 
> 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....
Yes, it would be possible to define only a set of secure ciphers (and
thus remove RC4)...however, what happens if one of these secure ciphers
is broken and thus affects security of a different one, which
accidentally uses the same key length?

Best
Juraj