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

"Blumenthal, Uri - 0558 - MITLL" <> Tue, 17 September 2013 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FA5D11E82A5 for <>; Tue, 17 Sep 2013 09:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.308
X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UDsw+U1G0Rbx for <>; Tue, 17 Sep 2013 09:13:39 -0700 (PDT)
Received: from (MX2.LL.MIT.EDU []) by (Postfix) with ESMTP id DB45B11E80EA for <>; Tue, 17 Sep 2013 09:13:35 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id r8HFQ28S015574; Tue, 17 Sep 2013 12:13:31 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <>
To: "Salz, Rich" <>, Michael StJohns <>
Date: Tue, 17 Sep 2013 12:13:09 -0400
Thread-Topic: [TLS] TLS and hardware security modules - some issues related to PKCS11
Thread-Index: Ac6zwM9byrP1+FwtQumO+QuhQ3/qlg==
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3462264789_36040718"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-17_06:2013-09-17, 2013-09-17, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309170066
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: Tue, 17 Sep 2013 16:13:44 -0000

On 9/17/13 12:00 , "Salz, Rich" <> wrote:

>>I want to protect inside of the HSM all of the following:
>>a) the private keys related to the server or client identity
>>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.
>The programming model for such a beast is probably more like an I/O
>processor than an HSM.  You need input and output "local plaintext" data
>streams, and the same for "to/from the network crypto streams."  And ways
>to signal "I can't give you more plaintext until you write this on the
>network and get more data back from the other side."  And so on.
>Have you seen a market need for this kind of thing?  Have you got an API
>designed?  I'd be curious about both.

Doesn't HAIPE do something like that?

>I also don't understand why you do not trust the host software with the
>ability to decrypt its own data (i.e,. session) when you don't have
>control over what it does with the plaintext, like copy it over to an
>adversary directly.

I guess this is more about protecting the cryptographic keys and
infrastructure rather than protecting plaintext of a given session (which
belongs to the application who is free to do with it whatever it wishes).