[TLS] HSM-friendly Key Computation

Russ Housley <housley@vigilsec.com> Fri, 17 April 2015 19:00 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3F3F01B2FCE for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 12:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.3
X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IA3YJAA530ZP for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 12:00:17 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net []) by ietfa.amsl.com (Postfix) with ESMTP id 457391B2F84 for <tls@ietf.org>; Fri, 17 Apr 2015 12:00:13 -0700 (PDT)
Received: from localhost (unknown []) by odin.smetech.net (Postfix) with ESMTP id F2F44F240E9 for <tls@ietf.org>; Fri, 17 Apr 2015 15:00:02 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([]) by localhost (ronin.smeinc.net []) (amavisd-new, port 10024) with ESMTP id ko0wavxbu9Ta for <tls@ietf.org>; Fri, 17 Apr 2015 14:59:41 -0400 (EDT)
Received: from [] (pool-96-255-133-185.washdc.fios.verizon.net []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 226B7F240E6 for <tls@ietf.org>; Fri, 17 Apr 2015 14:59:42 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Apr 2015 14:59:30 -0400
Message-Id: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com>
To: IETF TLS <tls@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/I6YsJxLE1FE8a_LlNwJSzCuCBas>
Subject: [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 19:00:18 -0000

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 +

Then, the key block is divided into keys and IVs:


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.

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.