Re: [TLS] HSM-friendly Key Computation

[Michael StJohns <[e-mail]>]

On 4/22/2015 7:03 PM, Eric Rescorla wrote:
>
>
> On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns 
> <[e-mail] <mailto:[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".
Actually, use HKDF as the term with no expand or extract suffix.

Mike



>
> -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]
>>     <mailto:[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] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/tls
>>
>>
>>
>>
>>     _______________________________________________
>>     TLS mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/tls
>
>
>     _______________________________________________
>     TLS mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tls
>
>