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

Michael StJohns <msj@nthpermutation.com> Mon, 23 September 2013 20:47 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3810F21F9E69 for <tls@ietfa.amsl.com>; Mon, 23 Sep 2013 13:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.441
X-Spam-Level:
X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V093RUS-eS5f for <tls@ietfa.amsl.com>; Mon, 23 Sep 2013 13:47:45 -0700 (PDT)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 343AB21F9D74 for <tls@ietf.org>; Mon, 23 Sep 2013 13:47:44 -0700 (PDT)
Received: by mail-qa0-f46.google.com with SMTP id j7so1884975qaq.12 for <tls@ietf.org>; Mon, 23 Sep 2013 13:47:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=TH+vrfloit1EihkDhlEBaIqBDbi4bi4yaMj1Ydr7Ir4=; b=EVJGSnJmSNQt/ih3lAg9b9ie/WCSe64oYmTkkIp2nad18XRCwt7xHuoVJxsIOsWgSS uX3us+XywX5hFo1PMoCQy4U4OEpafqKm+Jio0VxiPbcC0GKvM6AfDwtB0hcXBbica/Wz YKjWv0WkwDRuTZXHbAViz0Y+DvzewdpxSZNFZB6yDFg24fTVfa15ERpsrh+6cbVnBL+f 4n3sVbbO72u88MlH5pFL0SOS7dVCgoria4MdnRs9BGU9QA1bE74Stc6cmBpxswhwGOvs Hsxbm/X57Uia6ucTWr/LE571jwlVwz+UGT5yn3tpJyDUJW3aYaYR4XPn5KNaz2hBaP+P n5Ag==
X-Gm-Message-State: ALoCoQmQd0wbmsrNV0Q8tIVRwT2OXGzk0SNy4oqG5KE8izb7qFAiCx98a9x3jgK1ThU3/hPPN5Qq
X-Received: by 10.224.157.14 with SMTP id z14mr4546959qaw.90.1379969264442; Mon, 23 Sep 2013 13:47:44 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id i4sm47208902qan.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 13:47:44 -0700 (PDT)
Message-ID: <5240A8F0.2020001@nthpermutation.com>
Date: Mon, 23 Sep 2013 16:47:44 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com> <CAK3OfOjeDm=shFqjHwJP6AW-0+keKc-px+jwkUVUqWeVmkyqBA@mail.gmail.com>
In-Reply-To: <CAK3OfOjeDm=shFqjHwJP6AW-0+keKc-px+jwkUVUqWeVmkyqBA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
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." <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: Mon, 23 Sep 2013 20:47:51 -0000

On 9/23/2013 4:00 PM, Nico Williams wrote:
> On Tue, Sep 17, 2013 at 10:45 AM, Michael StJohns
> <msj@nthpermutation.com> wrote:
>> On 9/17/2013 8:49 AM, Martin Rex wrote:
>>> I fail to understand what you're trying to protect.
>>>
>>> The master secret of a session is never a secret that is hidding
>>> within the hardware module, instead, it is something known to the
>>> calling TLS protocol stack and part of the TLS session cache.
>>
>> Um.  No, not if you designed things properly.  It should be possible for any
>> protocol the IETF designs to do all the crypto operation inside a hardware
>> module and not depend on the weak security of a general purpose computer.
> 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.

>
>> I want to protect inside of the HSM all of the following:
>>
>> a) the private keys related to the server or client identity
> Sure.
>
>> b) the pre-master key
>> c) the master key
>> d) the session keys.
>>
>> I want to be able to do all the cryptographic processing inside that module
>> and only allow out true plain text.
> Why?  The HSM will become a cryptographic decelerator if you do that,
> unless it's a fantastically expensive HSM anyways, and even then there
> will be latency costs.  Meanwhile the session keys are of little or no
> additional value to the application plaintext, and you're leaving the
> application outside the HSM (of course, for obvious reasons).
>
> So why do this?  The one answer that comes to mind is: to make sure
> you get the crypto right, without possibility of screwups/backdoors in
> various OS components (e.g., RNG).  But the performance cost more than
> outweighs that answer in most of the use cases I can think of.

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.

For TLS, I agree with you about performance, BUT, security is always a 
tradeoff with performance.  I may not always want to keep the session 
keys inside the HSM, but there are some times that prudence and good 
practice require this.

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


Mike

>
> Nico
> --
>
>