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

"Paterson, Kenny" <> Mon, 23 September 2013 16:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F75921F9FEE for <>; Mon, 23 Sep 2013 09:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BN7F2sB1qfQi for <>; Mon, 23 Sep 2013 09:51:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4813F21F9E70 for <>; Mon, 23 Sep 2013 09:51:36 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Mon, 23 Sep 2013 16:51:35 +0000
Received: from mail160-va3 (localhost []) by (Postfix) with ESMTP id BEFBF4400B2; Mon, 23 Sep 2013 16:51:35 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -7
X-BigFish: PS-7(zzbb2dI98dI9371I1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah1de097h186068h5eeeK8275bhz2dh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(479174003)(199002)(189002)(24454002)(243025003)(19580395003)(83322001)(19580405001)(76176001)(36756003)(81542001)(83072001)(65816001)(80976001)(63696002)(56776001)(54316002)(83506001)(15975445006)(74482001)(47446002)(74662001)(74502001)(31966008)(15202345003)(81816001)(4396001)(47976001)(47736001)(49866001)(50986001)(56816003)(81686001)(69226001)(74876001)(77982001)(76786001)(76796001)(59766001)(76482001)(79102001)(80022001)(51856001)(66066001)(46102001)(81342001)(74706001)(74366001)(54356001)(53806001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR03MB277;; CLIP:; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail160-va3 (localhost.localdomain []) by mail160-va3 (MessageSwitch) id 1379955093597116_21162; Mon, 23 Sep 2013 16:51:33 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 78A933C0053; Mon, 23 Sep 2013 16:51:33 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 23 Sep 2013 16:51:33 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.16.359.1; Mon, 23 Sep 2013 16:51:32 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 23 Sep 2013 16:51:31 +0000
Received: from ([]) by ([]) with mapi id 15.00.0775.005; Mon, 23 Sep 2013 16:51:31 +0000
From: "Paterson, Kenny" <>
To: Michael StJohns <>, Juraj Somorovsky <>
Thread-Topic: [TLS] TLS and hardware security modules - some issues related to PKCS11
Thread-Index: AQHOsy7JUoLoDGnX60Kfyac6xLAxJ5nJBRiAgAOrHwCAA+WFAIACgDgAgAB31gCAACepgA==
Date: Mon, 23 Sep 2013 16:51:31 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-forefront-prvs: 09781D4C35
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
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 16:51:52 -0000

Comments in-line.

On 23/09/2013 17:29, "Michael StJohns" <> wrote:

>On 9/23/2013 5:20 AM, Juraj Somorovsky wrote:
>> On 09/21/2013 09:09 PM, Michael StJohns wrote:
>>> Thanks for this.  I think it can be fixed though and relatively simply,
>>> but will require changes to the key expansion step that are a bit more
>>> than I suggested:
>>> E.g. in addition to the master_key, label and random data being fed
>>> the KDF, also feed in - in order for each output key - 2 or 4 bytes
>>> that describe the length of the key.  And that's taken directly from
>>> inputs for the key lengths requested.
>>> That means that any time you vary the length of ANY key in the key
>>> expansion, the entire key stream changes.
>>> It also means that there isn't a need for a separate IV sub key for the
>>> key expansion stage (I think....)
>> I do not think this is enough to solve this problem. There are
>> algorithms that have the same key and IV lengths....e.g. an AES-128 key
>> has the same length as the IV used in AES-CBC. I think this would break
>> your key derivation???
>The general problem here is that pretty much all encryption modes are
>based on ECB - if you can do ECB, you can do the operations that make up
>the mode.
>I don't think this is as much of an issue.  The DES key issue was of
>more interest because its substantially easier to brute force 2 keys of
>length 64 than it is a single key of length 128.  This appears to be no
>change in the attack surface to extract the key.

Agreed. But this is not the only attack of interest. See below.

>> An additional problem is that the same key would be used for the same
>> block ciphers in different modes of operation, e.g. AES-CBC would use
>> the same key as AES-GCM.
>> As mentioned in my previous post, a solution would be to derive the
>> material based on the master secret and the encryption scheme / IV it is
>> used for. For example you could derive :
>> - a symmetric key for AES-GCM:
>> k_GCM = PRF(master_secret, "AES_GCM", [further params])
>> - a symmetric key for AES-CBC:
>> k_CBC = PRF(master_secret, "AES_CBC", [further params])
>> - initialization vector:
>> IV = PRF(master_secret, "IV", [further params])
>The issue with the above approach is that the KDF is currently pretty
>generic - a key plus some public data (e.g. the label, the random
>stuff.  I can't prevent a re-derivation using whatever label the
>attacker wants to use.  So it would be pretty easy to generate either
>k_GCM or k_CBC given the master secret and the random stuff.
>But mostly, I don't see this as a large threat  - how would this benefit
>an attacker with access to the master key?

Juraj was too polite to point out this paper from NDSS 2013:

for an example of what can go wrong when the same key is used in two
different modes one of which
is subject to plaintext recovery attacks (full disclosure: Juraj and I are
co-authors on this paper along
with Tibor Jager).

TL;DR: you can recover low entropy GCM plaintexts if the same key is used
in a mode like CBC.

>The arguments against CBC tend to be with respect to attacks to recover
>the plain text, not the key.  The question I would ask for the above is
>whether being able to use the same AES key in multiple encryption modes
>provides additional attack surface to recover the key?

Not as far as we know. But if I can recover your AES-GCM plaintext,
wouldn't you
just be a little bit concerned?

>If not, then 
>it's a don't care for PKCS11 I think.

So, do you care now? :-)