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

Nico Williams <> Mon, 23 September 2013 23:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D18A21F9E62 for <>; Mon, 23 Sep 2013 16:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.82
X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2FPzis+Kh362 for <>; Mon, 23 Sep 2013 16:01:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DED1D21F9E50 for <>; Mon, 23 Sep 2013 16:01:12 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 1579D200D300C; Mon, 23 Sep 2013 16:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=idrjtbPLQ0a2xd 7vA4wGHOppSio=; b=YbVT5RO7N30wT6sJEtJs/m6HXFRUivKEFIVLLKT69W5Xvk cLBXdJ1NxgK9rqepKriTEg9tfL/G/GJQIKJUa5nVCb09iAw12XzWF06/3NdQGMbx FM7Y9NG5NbarQpM7e3Xqpv8NdZBe49gLPdTWEn/hMQJ28SD3/I9FTg2Ds4tbk=
Received: from (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 004FF200D3005; Mon, 23 Sep 2013 16:01:04 -0700 (PDT)
Date: Mon, 23 Sep 2013 18:00:58 -0500
From: Nico Williams <>
To: Michael StJohns <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 23:01:18 -0000

On Mon, Sep 23, 2013 at 04:47:44PM -0400, Michael StJohns wrote:
> On 9/23/2013 4:00 PM, Nico Williams wrote:
> >On Tue, Sep 17, 2013 at 10:45 AM, Michael StJohns
> ><> wrote:
> >
> >But evidently you must care about the application plaintext.  Why not
> >move the application into the HSM as well then?
> >
> >That deserves a tongue-in-cheek smiley, of course :^)
> There are SSL/TLS accelerators that move a whole bunch more of the
> crypto stuff inside the HSM, but PKCS11 is designed to be useful for
> more than just TLS.

That's not responsive though.  The fundamental question is: why should
anyone treat session keys as more valuable than the plaintext they are
used to protect?

I think there is an acceptable answer, namely: where the TLS (or
whatever) channel carries some data that is not trusted and where you
want privilege separation, and where you really just don't trust the
hardware furnishing the plaintext.  But you kinda have to say that
that's what you're after, and then consider other issues that come up as
a result.  For example, you might actually need a significant part of
your application to live in the HSM.

> Consider a specific field of use - 10s of Millions of smart grid
> capable electric power meters.  Consider that I have a back office
> system that talks to each and every one of them securely.  Consider
> that I'm worried about insider threats with respect to reading and
> controlling (e.g. remote disconnection of the meters) these devices.
> Consider that I never ever ever want a control key to be present
> outside of an HSM in plaintext form.  Consider that some smart grid
> technologies are using TLS as the sole credential layer for
> controlling substantial amounts of power.

I've considered these things.  See above.

> TLS should be designed so this is possible.  I believe it currently
> has a limitation that makes this goal difficult or impossible to
> achieve.

Or you could design a better HSM.  Why isn't that an answer?  PKCS#11
may not be the hammer that you're looking for.