Re: [TLS] HSM-friendly Key Computation

[Ilari Liusvaara <[e-mail]>]

On Fri, Apr 17, 2015 at 02:59:30PM -0400, Russ Housley wrote:
> Section 6.3 of draft-ietf-tls-tls13-05 describes the key calculation from the current master secret (MS).  First a key block is computed:
> 
>       key_block = PRF(MS,
>                       "key expansion",
>                       SecurityParameters.server_random +
>                       SecurityParameters.client_random);
> 
> Then, the key block is divided into keys and IVs:
> 
>       client_write_key[SecurityParameters.enc_key_length]
>       server_write_key[SecurityParameters.enc_key_length]
>       client_write_IV[SecurityParameters.fixed_iv_length]
>       server_write_IV[SecurityParameters.fixed_iv_length]
> 
> If one wants to implement the cryptographic functions in a Hardware
> Security Module (HSM), this structure is far from ideal.  In general
> I would expect the client_write_key and server_write_key to stay
> inside the protected boundary of the HSM, but the client_write_IV
> and server_write_IV do not need this protection.  Both of these
> coming from the same key_block makes this separation very difficult
> to implement.

While if the encryption algorithm is strong, there is no real
difference between public and private nonces (if algorithm is not
strong, then all bets are off), having untrusted parts pick nonces
with non-MR AE (especially something so hair trigger as AES-GCM)
seems like asking for trouble.

> Can we get these values from different invocations of the PRF?
> I'd like to see one invocation for values that are expected to
> remain secret and a separate invocation for values that do not
> need to remain secret.

That would certainly work. Note that to implement full TLS, one
already needs to derive "public" values out of "private" ones.


On another thought, TLS library authors might not appreciate
key expansion being changed (nor KDF changes)...


-Ilari