Re: [TLS] HSM-friendly Key Computation

We should defer this issue until we know whether we are generating an IV
at all.

-Ekr

On Fri, Apr 17, 2015 at 11:59 AM, Russ Housley <housley@vigilsec.com> 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.
>
> 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.
>
> Russ
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>