Re: [TLS] HSM-friendly Key Computation

[Watson Ladd <[e-mail]>]

On Apr 24, 2015 10:13 AM, "Joseph Salowey" <[e-mail]> wrote:
>
>
>
> On Thu, Apr 23, 2015 at 12:01 PM, Michael StJohns <[e-mail]>
wrote:
>>
>> 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.
>>
>
> [Joe] I've having trouble understanding what exactly you are designing
here, is it the interface to a specific HSM or is it the TLS 1.3 key
derivation or is it something else? I think we need to make sure that we
have the requirements defined for the TLS 1.3 key derivation.
>
> Its not clear to me what the problem is with just including the context
label, session hash and possibly length.   The context label would
differentiate between derived key material for different purposes.  For
example, public and private data would use different context labels.  One
would also probably want to include the cipher suite ID in the context
label for keys derived for encryption.

The issue is the hardware has to enforce the usage of the derived keys. I
think this will restrict our encoding significantly,  perhaps turning it
into some bitfields. Asking hardware to understand context labels is going
to make it not hardware anymore.

Of course, there are other approaches that offer most of the gains without
these costs like separate fixed function terminators, or keeping only a few
keys secret.

Sincerely,
Watson Ladd

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