Re: [TLS] HSM-friendly Key Computation

[Michael StJohns <[e-mail]>]

On 4/23/2015 1:52 PM, Ilari Liusvaara wrote:
> On Thu, Apr 23, 2015 at 01:34:53PM -0400, Michael StJohns wrote:
>> On 4/23/2015 4:42 AM, Ilari Liusvaara wrote:
>>> On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote:
>>>
>>> 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)
> Right.
>
>> AES-CMAC
> Not used anywhere (insufficient security).

For this and the comment below..... I'm not just thinking about TLS.  
And I am thinking about how to retrofit this to TLS1.2 which doesn't 
require this to be an AEAD function.  And then there's the composed AEAD 
suites (e.g. AES-CBC with AES-CMAC wrapped as an AEAD function).   So 
while they may not be used by TLS directly, I want to get code points 
for all the possibilities.
>
>> AES-AEAD
> Is there ment to be XXX-AEAD for different encryption algorithms?
> Do AES-CCM and AES-GCM share a key type? What about AES-CCM8?

Generally yes for xxx-aead having different types per algorithm. Because 
you don't want to (for example) be able to use material for both AES and 
say GOST.   For modes, AEAD modes are mostly supersets or combinations 
of non-AEAD modes and there's an attempt to enforce "releasability only 
after verification" type policies on the CCM and GCM modes.   It would 
be good to have different codes for CCM and GCM (or even other modes), 
but I don't know that adds markedly to security.
>
>> AES-ENCRYPT
> Not used. Encryption always pairs with authentication (AEAD).

See above - one of the questions is how does a composed AEAD suite 
derive subkeys.  Generically it seems to be "split the stream wherever 
you want" and as noted, that has a few problems.
>
>> HMAC-SHA1
> A NULL cipher key? That one wouldn't be directly used for anything else.

For TLS1.2 and before, being able to tag that you're deriving an 
integrity key...  ditto for below.
>
>> HMAC-SHA2
> NULL cipher keys are per algorithm?
>
>> GENERIC-DATA (different that PKCS11 generic secret - could be IV material
>> for example).
> This is "octet string" above (except IVs are "AEAD IV").

Not quite. (<begin pedantic mode>  :-) )

One of the problems we have is a lack of common language.  And IV is one 
of those that's very slippery.

TLS - incorrectly - called what's being produced by the master secret 
expansion an "IV".   What it actually was was the "first IV" of the 
session for cipher suites that included  CBC as a mode and a "session 
nonce" for suites with counter based ciphers.

An IV is the common data injected by both sender and receiver to ensure 
that the same data doesn't encrypt the same way if identical data 
happens to occur in the plaintext stream multiple times.  For counter 
based ciphers, the IV is used with the block counter to form the block 
nonce(s) that (is/are) encrypted to form the XOR key stream.

An counter-based IV  (e.g. for CTR, CCM and GCM) is generally composed 
of the concatenation of the session nonce (or as we've been discussing a 
fixed length of zeros) plus a per-message value (and we've been 
discussing always using the message sequence number as that per-message 
value).

Due to the way TLS is constructed, what comes out of the master secret 
expansion can only be a "first IV" or a session nonce.  It would be 
possible to change this so an expansion is done with each message (e.g. 
same master secret, different mixins such as the sequence number) to 
generate a true per-message IV, but that's expensive and provides little 
security benefit.

</pedantic mode>

>
>> as a starting point.
> Depending on view, you also need special type for exporter secret, since
> it behaves somewhat unlike others.

I think the easiest way to accomplish this is to use a flag saying 
whether or not its exportable (generally removable from an HSM) that 
gets mixed in.  That way you have the common language of what you want 
to generate and then only have to decide on handling criteria.


>
>> 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.
> As said, encryption always pairs with authentication.
>
>
>
> -Ilari
>
>