Re: [TLS] HSM-friendly Key Computation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 17 April 2015 20:00 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 C9EEE1B3021 for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 13:00:05 -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_32=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 1L32pGrG05qX for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 13:00:04 -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 C02EA1B3019 for <tls@ietf.org>; Fri, 17 Apr 2015 13:00:03 -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 116D19008F; Fri, 17 Apr 2015 23:00:00 +0300 (EEST)
Date: Fri, 17 Apr 2015 23:00:00 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Russ Housley <housley@vigilsec.com>
Message-ID: <20150417200000.GA6274@LK-Perkele-VII>
References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.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/AKCIg5tl4fUmOk0-tegEpTN__NE>
Cc: IETF TLS <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: Fri, 17 Apr 2015 20:00:06 -0000

On Fri, Apr 17, 2015 at 02:59:30PM -0400, Russ Housley wrote:
> Section 6.3 of draft-ietf-tls-tls13-05 describes the key calculation from the current master secret (MS).  First a key block is computed:
> 
>       key_block = PRF(MS,
>                       "key expansion",
>                       SecurityParameters.server_random +
>                       SecurityParameters.client_random);
> 
> Then, the key block is divided into keys and IVs:
> 
>       client_write_key[SecurityParameters.enc_key_length]
>       server_write_key[SecurityParameters.enc_key_length]
>       client_write_IV[SecurityParameters.fixed_iv_length]
>       server_write_IV[SecurityParameters.fixed_iv_length]
> 
> If one wants to implement the cryptographic functions in a Hardware
> Security Module (HSM), this structure is far from ideal.  In general
> I would expect the client_write_key and server_write_key to stay
> inside the protected boundary of the HSM, but the client_write_IV
> and server_write_IV do not need this protection.  Both of these
> coming from the same key_block makes this separation very difficult
> to implement.

While if the encryption algorithm is strong, there is no real
difference between public and private nonces (if algorithm is not
strong, then all bets are off), having untrusted parts pick nonces
with non-MR AE (especially something so hair trigger as AES-GCM)
seems like asking for trouble.

> Can we get these values from different invocations of the PRF?
> I'd like to see one invocation for values that are expected to
> remain secret and a separate invocation for values that do not
> need to remain secret.

That would certainly work. Note that to implement full TLS, one
already needs to derive "public" values out of "private" ones.


On another thought, TLS library authors might not appreciate
key expansion being changed (nor KDF changes)...


-Ilari