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

Michael StJohns <> Mon, 23 September 2013 20:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3563721F9D56 for <>; Mon, 23 Sep 2013 13:31:16 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mRy8GJ+JTKRK for <>; Mon, 23 Sep 2013 13:31:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E797A21F9D3B for <>; Mon, 23 Sep 2013 13:31:10 -0700 (PDT)
Received: by with SMTP id l109so1575965yhq.20 for <>; Mon, 23 Sep 2013 13:31:10 -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=P2+EHEk4H6Mz6bKmGUhUCxi4HNVFW2t3nFC7IAz1gPs=; b=S/zpl6Z3MuBrn0ElZuOwsJqozY2IyyvTB+9XazB1AoI7hMREjA+855jWBwmA2gy0j4 XxWjQ1tgtgkobf9Lz7Gs71KOu+b9n2AXksGtMxkNh2491uiTmvqYSM7yFXUTZJicuFeS KSD6zfmLwiBa9Y63dVKHwgHNxq28y/hann30vIjOMuJ5B+2AXcNuQr9SWITa9q9Az7c3 H5q4UaTTSwIhZkivG17VBfKM394cZn9QiYFcoSaVFqUYqoSJDyrpvMEUYAh2Sa9nDOfH D59YhCWxEXBKSIrdMaEP3I0HzNMfRftcsOlL5chhfmEWq6+lzAuaY1Vwo7/V+WT+B2T2 zteQ==
X-Gm-Message-State: ALoCoQnD5NiIWq0XBc64dRxZKGc7wttGWJSyslZw5q3dO8nkhqthRaEYbpZMGU8D5p0brckn4Gpa
X-Received: by with SMTP id n48mr2009492yho.99.1379968249425; Mon, 23 Sep 2013 13:30:49 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id 9sm38816753yhd.19.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 13:30:48 -0700 (PDT)
Message-ID: <>
Date: Mon, 23 Sep 2013 16:30:49 -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: "Paterson, Kenny" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 20:31:16 -0000

Comments in line.  Previous text omitted.

On 9/23/2013 12:51 PM, Paterson, Kenny wrote:
> Comments in-line.
> On 23/09/2013 17:29, "Michael StJohns" <> wrote:
>> 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.
>> 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.

Right.  But you can't recover the key.

Let me reiterate the threat model:

1) All keys are kept in an HSM (not supposed to be extracted - but TLS 
KDF trivially allows this)
2) Attacker has access to use the keys (e.g. either has HSM credentials, 
or has hacked the program using the HSM that has HSM credentials - the 
TLS stack for example).

Because of (2), the attacker can directly decrypt the cipher text (or 
already has access to the plain text), so an attack where I can force 
the HSM to use multiple cipher modes for the same key is no worse than 
what's already happening.  I'm trying to prevent key recovery attacks 
with this change, NOT plaintext recovery attacks.

I agree that it would be useful to prevent (by HSM policy) a key from 
being used with both CBC and GCM, but the actual threat is a protocol 
one, rather than solely an HSM one assuming the attacker already has 
access to use the key in the HSM.  PKCS11 *does* have some of this, but 
it turns out that its difficult to employ on derived keys (e.g. by ECDH, 
DH or by KDFs) in a manner that prevents attacks based on re-derivation 
of the key.

In some respect,  the selection of IVs for GCM - e.g. no repeats - could 
be viewed as an HSM problem (rather than a protocol problem), but the 
HSM may not (and generally does not) have knowledge of each and every 
previously IV used with the key.  The current PKCS11 API doesn't 
actually provide for the ability to have the HSM link the IV state to 
the key used to the encryption mode - it's one of the things we're 
considering for 3.0 though.

Right now I'm trying to deal with the wide range of problems a piece at 
a time.  In this case, the TLS KDF mechanism has substantial challenges 
with being implemented securely in an HSM - unless the HSM is really a 
TLS accelerator and all the TLS negotiation  and encryption is done 
inside the HSM.  That's one implementation choice - but PKCS11 is 
defined for a more general model where it can be plugged in to support 
lots of different protocols.

>> 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?

See above.

>> If not, then
>> it's a don't care for PKCS11 I think.
> So, do you care now? :-)

Still no I think.


> Cheers,
> Kenny