Re: [TLS] HSM-friendly Key Computation

Note also that this is a known issue.  Mike StJohns raised it previously.

https://github.com/tlswg/tls13-spec/issues/5

On 17 April 2015 at 12:40, Eric Rescorla <ekr@rtfm.com> wrote:
> 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
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>