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

[Michael StJohns <[e-mail]>]

Comments in line.  Previous text omitted.

On 9/23/2013 12:51 PM, Paterson, Kenny wrote:
> Comments in-line.
>
> On 23/09/2013 17:29, "Michael StJohns" <[e-mail]> wrote:
>
>>
>> I don't think this is as much of an issue.  The DES key issue was of
>> more interest because its substantially easier to brute force 2 keys of
>> length 64 than it is a single key of length 128.  This appears to be no
>> change in the attack surface to extract the key.
>>
> Agreed. But this is not the only attack of interest. See below.
>
>
>>
>> But mostly, I don't see this as a large threat  - how would this benefit
>> an attacker with access to the master key?
> Juraj was too polite to point out this paper from NDSS 2013:
>
> http://www.isg.rhul.ac.uk/~kp/BackwardsCompatibilityAttacks.pdf
>
>
> for an example of what can go wrong when the same key is used in two
> different modes one of which
> is subject to plaintext recovery attacks (full disclosure: Juraj and I are
> co-authors on this paper along
> with Tibor Jager).
>
> 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).

Because of (2), the attacker can directly decrypt the cipher text (or 
already has access to the plain text), so an attack where I can force 
the HSM to use multiple cipher modes for the same key is no worse than 
what's already happening.  I'm trying to prevent key recovery attacks 
with this change, NOT plaintext recovery attacks.

I agree that it would be useful to prevent (by HSM policy) a key from 
being used with both CBC and GCM, but the actual threat is a protocol 
one, rather than solely an HSM one assuming the attacker already has 
access to use the key in the HSM.  PKCS11 *does* have some of this, but 
it turns out that its difficult to employ on derived keys (e.g. by ECDH, 
DH or by KDFs) in a manner that prevents attacks based on re-derivation 
of the key.

In some respect,  the selection of IVs for GCM - e.g. no repeats - could 
be viewed as an HSM problem (rather than a protocol problem), but the 
HSM may not (and generally does not) have knowledge of each and every 
previously IV used with the key.  The current PKCS11 API doesn't 
actually provide for the ability to have the HSM link the IV state to 
the key used to the encryption mode - it's one of the things we're 
considering for 3.0 though.

Right now I'm trying to deal with the wide range of problems a piece at 
a time.  In this case, the TLS KDF mechanism has substantial challenges 
with being implemented securely in an HSM - unless the HSM is really a 
TLS accelerator and all the TLS negotiation  and encryption is done 
inside the HSM.  That's one implementation choice - but PKCS11 is 
defined for a more general model where it can be plugged in to support 
lots of different protocols.

>
>> The arguments against CBC tend to be with respect to attacks to recover
>> the plain text, not the key.  The question I would ask for the above is
>> whether being able to use the same AES key in multiple encryption modes
>> provides additional attack surface to recover the key?
> Not as far as we know. But if I can recover your AES-GCM plaintext,
> wouldn't you
> just be a little bit concerned?

See above.

>
>
>> If not, then
>> it's a don't care for PKCS11 I think.
> So, do you care now? :-)

Still no I think.

Mike

>
> Cheers,
>
> Kenny
>
>
>
>