Message-ID: <553D4FF7.8080700@nthpermutation.com>
Date: Sun, 26 Apr 2015 16:52:07 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com>
 <551DDD4E.5070509@nthpermutation.com>
 <F7F3EB83-FEA2-477C-8810-38C49B71C977@ieca.com>
 <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com>
 <CACsn0cm5A50dP4JDKq9R0XdB83hyzPPLQHAMnUcXFb+DCSwV7g@mail.gmail.com>
 <55392B08.6020304@nthpermutation.com>
 <CADi0yUPTixoesXkgd=HYe_+ua_+=_UfcDBSndCgdh1usTzNpzQ@mail.gmail.com>
 <553D3572.6040408@nthpermutation.com>
 <CADi0yUOnsD0Sasq7dRTbRpUm9jTg-uf+vjkkpMCxxsKXH0kqMw@mail.gmail.com>
In-Reply-To: <CADi0yUOnsD0Sasq7dRTbRpUm9jTg-uf+vjkkpMCxxsKXH0kqMw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------090500020809070600000109"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/MELshYXdPFbHLfGaywFrCP_itPM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS]
 =?utf-8?q?confirming_the_room=E2=80=99s_consensus=3A_adopt_?=
 =?utf-8?q?HKDF_PRF_for_TLS_1=2E3?=
Precedence: list

This is a multi-part message in MIME format.
--------------090500020809070600000109
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I'm going to slice this up a bit and answer in pieces.  Sorry - the 
messages are getting too long.

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
> ​I am completely lost on this length issue. Can you give me a concrete 
> example where TLS 1.3 derives different keys with same label and 
> context but with different output lengths? As said, in TLS 1.3 each 
> label and context is used exactly once. I must be missing something in 
> your argument but I just can't figure what's that.

Hi Hugo -

This isn't about TLS specifically, but about how an HSM makes sure an 
attacker can't extract TLS keys.

Assume that you implement your function in an HSM as you've defined in 
the RFC - without the length term.

Consider that the HSM keys may be USED by the attacker but the HSM is 
set up to prevent extraction - the keys can't be directly extracted . 
(See below for a discussion of how this might happen). And note that for 
a generic KDF interface, you can't ensure that the attacker doesn't use 
the same label and context in his call to use the master key as we 
define for TLS.

Consider that the derivation of the master secret from the pre-master 
secret can be done by both the user and the attacker, but that the 
attacker can request a key length of 1, but with the same label and 
context terms using the same pre-master secret.  Consider that the 
attacker designates this Length 1 key as an HMAC key.

The attacker now uses his version of the derived key as an HMAC key and 
uses it to generate an HMAC tag over a fixed value.  He then compares 
this to 256 generated HMACs over the same fixed value but using the 256 
different possible values of the derived key from above.  When he finds 
a match between one of his 256 HMACs and the HMAC using the derived key, 
he now knows that the value of that derived key.

Consider that _without the length term, a key of length 1 has as its key 
value the same first byte of any key stream of longer length generated 
from the same master key with the same label and context_.

By repeating the steps above, you can extract the master secret in O(1).

If the L term is mixed in by internal mechanism, there is no user 
accessible mechanism to accomplish this.  I.e. using the same secret 
with identical labels and contexts with differing requested output 
lengths produce cryptographically disjoint key material.    If you only 
pass this in as user specified material you don't get this protection.

If you ask me how an attacker can "use" the keys of someone else, 
consider that most versions of PKCS11 support only a PIN based 
authentication, or authentication is done because the HSM is embedded in 
the system.  The thing I'm trying to get to is a model where I can 
demonstrate that key material may not be extracted from an HSM by an 
attacker, even if the attacker has credentials to "use" the keys.

Mike


--------------090500020809070600000109
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">I'm going to slice this up a bit and
      answer in pieces.  Sorry - the messages are getting too long.<br>
      <br>
      On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:<br>
    </div>
    <blockquote
cite="mid:CADi0yUOnsD0Sasq7dRTbRpUm9jTg-uf+vjkkpMCxxsKXH0kqMw@mail.gmail.com"
      type="cite">​I am completely lost on this length issue. Can you
      give me a concrete example where TLS 1.3 derives different keys
      with same label and context but with different output lengths? As
      said, in TLS 1.3 each label and context is used exactly once. I
      must be missing something in your argument but I just can't figure
      what's that.</blockquote>
    <br>
    Hi Hugo - <br>
    <br>
    This isn't about TLS specifically, but about how an HSM makes sure
    an attacker can't extract TLS keys.  <br>
    <br>
    Assume that you implement your function in an HSM as you've defined
    in the RFC - without the length term.<br>
    <br>
    Consider that the HSM keys may be USED by the attacker but the HSM
    is set up to prevent extraction - the keys can't be directly
    extracted . (See below for a discussion of how this might happen). 
    And note that for a generic KDF interface, you can't ensure that the
    attacker doesn't use the same label and context in his call to use
    the master key as we define for TLS.  <br>
    <br>
    Consider that the derivation of the master secret from the
    pre-master secret can be done by both the user and the attacker, but
    that the attacker can request a key length of 1, but with the same
    label and context terms using the same pre-master secret.  Consider
    that the attacker designates this Length 1 key as an HMAC key.<br>
    <br>
    The attacker now uses his version of the derived key as an HMAC key
    and uses it to generate an HMAC tag over a fixed value.  He then
    compares this to 256 generated HMACs over the same fixed value but
    using the 256 different possible values of the derived key from
    above.  When he finds a match between one of his 256 HMACs and the
    HMAC using the derived key, he now knows that the value of that
    derived key.<br>
    <br>
    Consider that <u>without the length term, a key of length 1 has as
      its key value the same first byte of any key stream of longer
      length generated from the same master key with the same label and
      context</u>.<br>
    <br>
    By repeating the steps above, you can extract the master secret in
    O(1).<br>
    <br>
    If the L term is mixed in by internal mechanism, there is no user
    accessible mechanism to accomplish this.  I.e. using the same secret
    with identical labels and contexts with differing requested output
    lengths produce cryptographically disjoint key material.    If you
    only pass this in as user specified material you don't get this
    protection.<br>
    <br>
    If you ask me how an attacker can "use" the keys of someone else,
    consider that most versions of PKCS11 support only a PIN based
    authentication, or authentication is done because the HSM is
    embedded in the system.  The thing I'm trying to get to is a model
    where I can demonstrate that key material may not be extracted from
    an HSM by an attacker, even if the attacker has credentials to "use"
    the keys.<br>
    <br>
    Mike<br>
    <br>
  </body>
</html>

--------------090500020809070600000109--