Re: [TLS] HSM-friendly Key Computation

Michael StJohns <msj@nthpermutation.com> Thu, 23 April 2015 17:35 UTC

Return-Path: <msj@nthpermutation.com>
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 13FEE1ACDFD for <tls@ietfa.amsl.com>; Thu, 23 Apr 2015 10:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 jZTrMK3r9ypg for <tls@ietfa.amsl.com>; Thu, 23 Apr 2015 10:35:49 -0700 (PDT)
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8171B30DF for <tls@ietf.org>; Thu, 23 Apr 2015 10:34:43 -0700 (PDT)
Received: by pacyx8 with SMTP id yx8so23771052pac.1 for <tls@ietf.org>; Thu, 23 Apr 2015 10:34:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FfZaBI7MsxbJ3CN9a+FnTaqpYLd2zDA/jumr6zx26EU=; b=A4yTa0ioECF4wfEK7SM461zqDf5Jx+vYQkTaT3xKz1mfzlrGUYrsyELgtmJv5tWW86 JqGiNOdEt0b2ftc3T5YB7soaUsTeAwzy/eLywTp0piqmOOsb6a7IZxdw0kJwjH44REoR VoYGvSM6jshDTUCrgNvf4GAp4Fyjc+xUt4cvYXDdl+KgC1z4JnbeWmAk/wVP1oyS//B2 qSq+BEQzafL3/PUxAmvEbbUEYPSo5NIkhxbxxyhF3RkoxO0+/JsUqHmKpYiaDPmkHvwq uq23mFs0zN70TwQ8JFF4WA8u/oMEjaJ+U8KQcuPCzCpTI1HfaVAftfcFtsZPbU+lba8s GXgA==
X-Gm-Message-State: ALoCoQleBoHks02QP6OqtxD5OzOvlc0PSrALYETeJ5X7X01E0DBrKnIbUdaa7oc7v7c9sGk7fJO7
X-Received: by 10.70.41.165 with SMTP id g5mr7228537pdl.143.1429810483382; Thu, 23 Apr 2015 10:34:43 -0700 (PDT)
Received: from [10.90.197.114] (edge-gw-rwc.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id gj9sm5169189pbc.77.2015.04.23.10.34.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 10:34:42 -0700 (PDT)
Message-ID: <55392D3D.1020101@nthpermutation.com>
Date: Thu, 23 Apr 2015 13:34:53 -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: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
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> <20150423084201.GA21246@LK-Perkele-VII>
In-Reply-To: <20150423084201.GA21246@LK-Perkele-VII>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/b2tLcgArjD0PLg33VlPXW6NPA1Y>
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 17:35:51 -0000

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
>