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

[Michael StJohns <[e-mail]>]

On 9/23/2013 2:18 PM, Michael D'Errico wrote:
> I've been trying to follow this discussion and it appears to me that the
> goal is to have a HSM that protects the master secret and session keys
> internally, yet also allows for extractors to ask the HSM to run the PRF
> for them.  The problem is that a naive HSM might be tricked into 
> revealing
> the session keys.
>
> Couldn't this be dealt with by having the HSM simply refuse to compute 
> the
> PRF given a label of "key expansion"?  Any other label should cause the
> output to differ wildly from the session keys, right?
>
> Mike
>
>

Nope.  Even if you restrict this, you still have the problem in that the 
mac and encryption keys can be caused to "leak" into the part of the key 
stream used for IVs.

I think TLS should have been spec'd with a KDF  and a MAC as distinct 
functions rather than as simple composites of the PRF function.  Also 
using the master secret both as the secret to the KDF  (key expansion) 
and to the MAC (finish message integrity tag) has some issues as well 
(not cryptographically, but in getting a PKCS11 module to enforce use 
separation on the key).

The actual way we dealt with your comment above in PKCS11 v2.40 was to 
deprecate the PRF function from direct use, create a TLS KDF function 
(which could be used with any label and random and produced only keys - 
and the IVs) and create a TLS MAC function (which internally used only 
the two server and client finish message labels and didn't allow any 
others) which produces the public integrity tag.

Because of the IV leaking problem and because the AEAD ciphers still 
require the production of an IV through the TLS PRF, we created a second 
KDF function which *doesn't* produce IV material.  That at least allowed 
a specific key to be marked so that it wasn't subject to the key 
extraction through the IV attack.

Mike