Re: [TLS] HSM-friendly Key Computation

[Michael StJohns <[e-mail]>]

On 4/23/2015 4:42 AM, Ilari Liusvaara wrote:
> 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
>
> ?

Pretty much.
>
> 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. */
> };

I ended up with a bit larger set of key types:

Master Secret (can only be used with KDFs)
AES-CMAC
AES-AEAD
AES-ENCRYPT
HMAC-SHA1
HMAC-SHA2
GENERIC-DATA (different that PKCS11 generic secret - could be IV 
material for example).

as a starting point.

It turns out that you want to subdivide AES AEAD uses from non AEAD AES 
functions because you don't want to be able to use AES-CTR to get around 
the AES-CCM and GCM "don't let the data come out unless its been 
verified" policy.


>
> 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
>