Re: [TLS] HSM-friendly Key Computation

[Eric Rescorla <[e-mail]>]

On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns <[e-mail]>
wrote:

>  On 4/22/2015 1:37 PM, Eric Rescorla wrote:
>
> If we're using HKDF-Extract, can we just key off different labels?
>
>  -Ekr
>
>
Sorry, read that as "HKD-Expand".

-Ekr


> Basically, no.
>
> The Extract function is really not designed to be used standalone but as a
> way of concentrating entropy for input to the expansion phase.  Its
> dangerous to talk of these functions as separately callable.  They are
> steps not separate functions.
>
>  The extract step's only non-key input - salt - is not the same as the
> "info" input used in the expand phase - 'salt' is supposed to be missing or
> random,  not a fixed string like a label.
>
> "info" is where the various labels go and that's only present in the
> expand phase.
>
>
> What you want to do is specify as part of the mixins (e.g. 'info' - e.g.
> the collection of label and context)  a set of fields that describe 1) how
> the key stream is going to be broken up (eg. lengths of the sub keys), 2)
> what algorithms will use each of the parts of the key stream, and 3)
> whether or not those parts are allowed to be exported/extracted.
>
> A software module will basically ignore these because - really - its all
> the same memory although it should really make sure the key lengths and
> types matc.  An HSM will look at these and be able to make policy decisions
> for protection of the segments (e.g. preventing export of material that was
> created to be non-exportable).
>
> Having all of these in the mixins means that the key stream expansion
> completely changes if ANY of these mixins change which in turn means  that
> the various ways you can use to extract truly secret key material (as
> differentiated from exportable material) from an HSM using the currently
> defined mechanism can be eliminated.  (I can explain my reasoning if
> necessary).
>
>
> Mike
>
>
>
>
> On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara <
> [e-mail]> wrote:
>
>> On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote:
>> > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
>> > >
>> > >There are other places in TLS that fundamentally need to (indirectly)
>> derive
>> > >public data out of secret key material.
>> > That's not a a problem. The problem is using the same mechanism to
>> derive
>> > the public data that we use to derive the keys.
>> > It's even OK to use the same secret key for both (from an HSM POV).
>> >
>> > What Michael is saying is that there are existing functions for both KDF
>> > (secret material -> key) and Mac (secret material-> unique public data).
>> > He's requesting that TLS not have it's own versions of these functions.
>>
>> So would using two different PRF functions, one for parts that don't
>> downgrade and another for parts that do downgrade (e.g. IV derivation,
>> unique / finished calculations, exporter calculations, etc..) solve the
>> issue?
>>
>> (Of course, the two functions should be closely related, so not to
>> annoy software implementations too much)...
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
>
> _______________________________________________
> TLS mailing [e-mail]://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>