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

Michael StJohns <msj@nthpermutation.com> Tue, 17 September 2013 16:26 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 1188B11E8526 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 09:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ2ys35MN+lz for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 09:26:23 -0700 (PDT)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id D484611E8522 for <tls@ietf.org>; Tue, 17 Sep 2013 09:26:11 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id hv10so1937371vcb.8 for <tls@ietf.org>; Tue, 17 Sep 2013 09:26:11 -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=rhstycX4wp+r76reXnoTbnEZ3UMbnI/bFTv+CGRNFJU=; b=GBorsOTLhrP/khLyEerMOvK21pcHG4CxD8atwrXa2rvCiREtDK244ufBjnMYpKVVg9 550QAZStXzl+I8ooWIW5HOPp6x/5a94UIQyJ/MndFtkUTc2JVp2/KLnhPmI0B0U2C1aA rdGxHPb9EJ7vslOv++pheO4UHfYX/QW1Kkvm1UtaMS+JJMgBR7KpK3gbqyvzwa1DiBOg y6b3NThGhEks4R9dcoqffAVGQzhupe2xTob5WmIpVvtdqEsPBe0OQHdo5n+bPBwqb2GN DOOeFONaJ3Y2FnpNFsB93UwyDueN3jviQv/iBaL80O03cORIyxhBIo1AoM0E0rrhb9Em WB6Q==
X-Gm-Message-State: ALoCoQnTXpVOKBu3saW21PJYepzLZtoVCsPhkA7hkVwMEBWjk6pMsgtHrX28wzc72GIplaNo683/
X-Received: by 10.58.74.38 with SMTP id q6mr17181229vev.9.1379435171117; Tue, 17 Sep 2013 09:26:11 -0700 (PDT)
Received: from [10.151.100.170] ([148.87.13.6]) by mx.google.com with ESMTPSA id p5sm24663216vek.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 09:26:10 -0700 (PDT)
Message-ID: <523882B0.1020308@nthpermutation.com>
Date: Tue, 17 Sep 2013 12:26:24 -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: "Salz, Rich" <rsalz@akamai.com>
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C711D4594339@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711D4594339@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=ISO-8859-1; 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: Tue, 17 Sep 2013 16:26:31 -0000

On 9/17/2013 12:00 PM, 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.

What?  No.

TLS is pretty much a two stage beast:

1) Figure out the keys. (TLS handshaking, data gathering, key transport 
and/key derivation).
2) use the crypto suite and the keys from (1) to encrypt and decrypt the 
messages.

Both of these are general purpose crypto operations.  How you get there 
is wrapped in TLS protocols, but the HSM doesn't actually need to know 
anything about TLS except its defined cryptographic operations (e.g., 
PKCS11 implements all of the various cipher and mac modes, implements 
signature creation and verification, and in addition, implements the TLS 
specific KDF (the TLS PRF in its various uses)).


>
> Have you seen a market need for this kind of thing?  Have you got an API designed?  I'd be curious about both.
>
> 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.

Small amounts of data (e.g. recovered keys) might be missed.  Harder to 
miss pretty much a doubling in traffic (e.g. a complete copy of the 
decrypted stream now being sent to the adversary).

Mike


>
> 	/r$
>   
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA
>
>