Re: [TLS] TLS and hardware security modules - some issues related to PKCS11

Michael StJohns <> Mon, 23 September 2013 21:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0592A21F9E8B for <>; Mon, 23 Sep 2013 14:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cPfmF9GlQBA1 for <>; Mon, 23 Sep 2013 14:00:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0A47621F9E5A for <>; Mon, 23 Sep 2013 14:00:03 -0700 (PDT)
Received: by with SMTP id hu16so1913672qab.14 for <>; Mon, 23 Sep 2013 14:00:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=UXxceapIXvsfmMCFdttkJih/8S/sGVGZLvR67LpH53g=; b=XlM2Dl/kNNpSmmOxWH5+6wWMZdccy+7d3C30ODKGsvWdSSueaDAvs1912Fyh//uYnu XM5E3D2onF8KRR837v+M3jqQ76aCiVK2Wjd0ogsDbzYOym3L6jYHbjkVs8mOwZHmlhKC BCi8V0ma6zwHUjLmVmFsCIx/ey8s8nFY5CcFTB6GvYopAYwRPg+ZMAjCkQdcPQmiOW+8 fR+DFzV1mJDftsbkO01gSYmpE8hBk/2CaYM/wp3OAuj1MLGcbPhihFDEa91/lxBTsORl 0fQ+uYVFzpjFlGZ02Jl+8r61mOYKJvsDIe9v4q4a7qbZSYfkseDlMi+Pyc64bkNc44RY J+Lw==
X-Gm-Message-State: ALoCoQlrwAYU1aP+97T++SdyfA9k2Z8QeCWyC2XZOsHrh5q8rvie8vxtx336EZRSD8UxrReIm5/o
X-Received: by with SMTP id r8mr26317089qan.26.1379969997812; Mon, 23 Sep 2013 13:59:57 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id y9sm47262064qaj.9.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 13:59:57 -0700 (PDT)
Message-ID: <>
Date: Mon, 23 Sep 2013 16:59:57 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Michael D'Errico <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Sep 2013 21:00:10 -0000

On 9/23/2013 2:18 PM, Michael D'Errico wrote:
> I've been trying to follow this discussion and it appears to me that the
> goal is to have a HSM that protects the master secret and session keys
> internally, yet also allows for extractors to ask the HSM to run the PRF
> for them.  The problem is that a naive HSM might be tricked into 
> revealing
> the session keys.
> Couldn't this be dealt with by having the HSM simply refuse to compute 
> the
> PRF given a label of "key expansion"?  Any other label should cause the
> output to differ wildly from the session keys, right?
> Mike

Nope.  Even if you restrict this, you still have the problem in that the 
mac and encryption keys can be caused to "leak" into the part of the key 
stream used for IVs.

I think TLS should have been spec'd with a KDF  and a MAC as distinct 
functions rather than as simple composites of the PRF function.  Also 
using the master secret both as the secret to the KDF  (key expansion) 
and to the MAC (finish message integrity tag) has some issues as well 
(not cryptographically, but in getting a PKCS11 module to enforce use 
separation on the key).

The actual way we dealt with your comment above in PKCS11 v2.40 was to 
deprecate the PRF function from direct use, create a TLS KDF function 
(which could be used with any label and random and produced only keys - 
and the IVs) and create a TLS MAC function (which internally used only 
the two server and client finish message labels and didn't allow any 
others) which produces the public integrity tag.

Because of the IV leaking problem and because the AEAD ciphers still 
require the production of an IV through the TLS PRF, we created a second 
KDF function which *doesn't* produce IV material.  That at least allowed 
a specific key to be marked so that it wasn't subject to the key 
extraction through the IV attack.