Re: [TLS] HSM-friendly Key Computation

[Ilari Liusvaara <[e-mail]>]

On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns 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
> >
> 
> Basically, no.
> 
> 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.

In TLS 1.2 P_hash (which underlies TLS PRF), the corresponding field is seed,
right?

So inside that (or whatever the equivalent), serialize:
- Label
- Lengths, types and exportable flags of subkeys
- Context

?

Properly serializing that would avoid the well-known TLS 1.2 screwup in
PRF defintion (which got copied to "dh based key exchange" draft).


One possible structure in TLS notation:

struct prf_output
{
     /*
     0x0000 => For key derivation
     0x0001 => For AEAD keying
     0x8002 => For AEAD IV
     0x8003 => For octet string (exporters, unique)
     */
     uint16 type;
     uint16 length;  /* In bytes. */
};

struct prf_seed
{
     opaque label<0..65535>
     prf_output outputs<4..65532>
     opaque context<0..65535>
};

Fixed expansion is 6 bytes and each subkey is 4 bytes.

The key expansion for AES-256-GCM a'la TLS 1.2 would look like:

00 0d 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e
00 10 00 01 00 20 00 01 00 20 80 02 00 04 80 02 00 04
00 40 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

Where XX is the random data. One can see this extracts total of 72
bytes. 

TLS 1.2 extended master secret with SHA-256 prf-hash looks like:

00 16 65 78 74 65 6e 64 65 64 20 6d 61 73 74 65 72 20 73 65 63 72 65 74
00 04 00 00 00 30
00 20 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

Where XX is the session hash up to that point. Output size can be seen
to be 48 bytes.



Also, it occurs to me that if PRF has salt input (like HKDF), one should
stick something non-secret but variable there (e.g. client random, or
suitable handshake hash, or something). Some outputs share a (key,salt)
pair. Keys should be combined by serialization.


-Ilari