Re: [TLS] HSM-friendly Key Computation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Thu, 23 April 2015 08:42 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B851A8951 for <tls@ietfa.amsl.com>; Thu, 23 Apr 2015 01:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eFqZpZNFiDZ for <tls@ietfa.amsl.com>; Thu, 23 Apr 2015 01:42:09 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB131A894F for <tls@ietf.org>; Thu, 23 Apr 2015 01:42:04 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 17CE19005C; Thu, 23 Apr 2015 11:42:01 +0300 (EEST)
Date: Thu, 23 Apr 2015 11:42:01 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Michael StJohns <msj@nthpermutation.com>
Message-ID: <20150423084201.GA21246@LK-Perkele-VII>
References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz> <5533F8D6.9070500@nthpermutation.com> <20150420064243.GA7322@LK-Perkele-VII> <CANeU+ZAL6oT6tP7OcL_8j6kp4oZB9V89R-0PrCdv-N27qVb0HQ@mail.gmail.com> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <CABcZeBPN33DM_C0sAmCTFCTdNrcQ7y7eEBcZgPe+2f1EaxtXzA@mail.gmail.com> <55381302.5030307@nthpermutation.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <55381302.5030307@nthpermutation.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3ljJLi9IToN02iN1yu-kqdAmSNs>
Cc: tls@ietf.org
Subject: Re: [TLS] HSM-friendly Key Computation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2015 08:42:11 -0000

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