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

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Tue, 17 September 2013 16:13 UTC

Return-Path: <prvs=29725b1cf4=uri@ll.mit.edu>
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 1FA5D11E82A5 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 09:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.308
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDsw+U1G0Rbx for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 09:13:39 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id DB45B11E80EA for <tls@ietf.org>; Tue, 17 Sep 2013 09:13:35 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8HFQ28S015574; Tue, 17 Sep 2013 12:13:31 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: "Salz, Rich" <rsalz@akamai.com>, Michael StJohns <msj@nthpermutation.com>
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: <CE5DF560.113EC%uri@ll.mit.edu>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711D4594339@USMBX1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.7.130812
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: "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: Tue, 17 Sep 2013 16:13:44 -0000

On 9/17/13 12:00 , "Salz, Rich" <rsalz@akamai.com> 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?

http://en.wikipedia.org/wiki/High_Assurance_Internet_Protocol_Encryptor



>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).