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

Michael StJohns <msj@nthpermutation.com> Tue, 17 September 2013 15:45 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 F14F911E8110 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 08:45:37 -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=[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 j8eJ3jM7xhU4 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 08:45:31 -0700 (PDT)
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8163011E8297 for <tls@ietf.org>; Tue, 17 Sep 2013 08:45:31 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id hz10so6982620pad.30 for <tls@ietf.org>; Tue, 17 Sep 2013 08:45:29 -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=TR/abPq18wo9l+GLYVVHepI3Q0D1FxL61SZ1fnyaoRk=; b=VH1GExkML4mV6uyMzv58X8SDLiUGTxe2StwC08zDW9e3hnwR0WjMSktoqLlvWjpyVx DUyPmVhp6P3X3imVdjpu5wNqNw6jF1zs/TsI8BXoEj2p5qEv+zlsuvHEB1JGoFcmHjPX 2KulUUcuHqkH4GqlYUltd3cblA11jmZcsR6+4KFJSNQgPPSKV4QU+gXwksnXtCxa3L94 klrI5Yjy0gWdXjwNFgEE+olMiyLi+Gj6YY3C3bSdfrN4WHhBz38qfo0N4HQRcov/tdEn Akxv+sQXqnvNxCqqLgtcs907a9v2Ny28QDIPoWcpxZYh02ACeFDmu1P01Fv5dw4MZCpH IsCw==
X-Gm-Message-State: ALoCoQmXJJD5ZNmx64R7zlsYCV/OcGWOrCMQRcAz8zoRXKHBaHVvYp3Fzb+t9AMWEN9qYM9fC7gA
X-Received: by 10.68.164.228 with SMTP id yt4mr35036634pbb.77.1379432729544; Tue, 17 Sep 2013 08:45:29 -0700 (PDT)
Received: from [10.151.100.170] ([148.87.13.6]) by mx.google.com with ESMTPSA id ab4sm25054453pbc.43.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 08:45:28 -0700 (PDT)
Message-ID: <52387927.4030007@nthpermutation.com>
Date: Tue, 17 Sep 2013 11:45:43 -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: mrex@sap.com
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp>
In-Reply-To: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 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 15:45:38 -0000

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.

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.

> For vanilla RSA cipher suites, it is deterministically derived
> from randomness generated by the client and conveyed under
> RSA encryption, deterministically combined with data known
> in plain to the TLS protocol stack.

I think you're talking about the pre-master secret?  If so, yes, but 
so?  The encrypted pre-master secret goes to the HSM where it's 
decrypted, run through a KDF and used to produce the master secret. 
Ideally, that master secret may be retained within the HSM and protected 
from disclosure.

Later, Mike

>
> -Martin