Re: [TLS] HSM-friendly Key Computation

[Michael StJohns <[e-mail]>]

On 4/22/2015 1:37 PM, Eric Rescorla wrote:
> If we're using HKDF-Extract, can we just key off different labels?
>
> -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]
> https://www.ietf.org/mailman/listinfo/tls