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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Tue, 17 September 2013 17:05 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 9A95211E8540 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 10:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 kBMvZs9KZwtq for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 10:05:33 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A4F8611E853F for <tls@ietf.org>; Tue, 17 Sep 2013 10:05:28 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id ev20so4487478lab.25 for <tls@ietf.org>; Tue, 17 Sep 2013 10:05:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GXLT9e30FRDGlPaRQWhbcv+T00p/nmof5xfUbMWK4KY=; b=DzceU6FsygT10I87gL7H5QqLQk5HjwDvODuOwtoPdSg7vqfQiDLqabgs3dmWfx4KDB 2oagq4KU5+i75S9AQbPQJvjWNsaAsd5is0SQamAMl5YKfrrDS111hgkPMLutQ2Lt4wrk qqui1NsyYzBV6o0HzPEksEpq8Ycf0juFjSEAR2LyIUfuAQxFRN0Eshhsr7UGgby7miSs HQlqejB0yYQxMPXa4BrBGA+ATZXU+oVaosDz8ULEhdz98UY2f3msZ4qetVupjPg2vj52 OYDKkbAAznVXfZqTeDz6FjK9UEvPuAkTbz/vKFkzYvsk+VsTpRYxacihcJ8c4pK71rLs TMhg==
MIME-Version: 1.0
X-Received: by 10.112.14.3 with SMTP id l3mr7352052lbc.27.1379437527570; Tue, 17 Sep 2013 10:05:27 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.133.196 with HTTP; Tue, 17 Sep 2013 10:05:27 -0700 (PDT)
In-Reply-To: <52387927.4030007@nthpermutation.com>
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com>
Date: Tue, 17 Sep 2013 19:05:27 +0200
X-Google-Sender-Auth: csSIneBcgKQ7Opn-CoN_lIgOPd8
Message-ID: <CAJU7zaJChK5VyqFmsLsPxKJEBXCnMZuouQ1_=UGnRftTUxsmGA@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: text/plain; charset=UTF-8
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 17:05:35 -0000

On Tue, Sep 17, 2013 at 5:45 PM, Michael StJohns <msj@nthpermutation.com> wrote:

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

What you care is protection of the long term keys by the security
module. Are you really sure you want to protect the temporal session
keys (i.e. TLS master key) as well? What do you gain if you do that?
If you want to protect the key from a software vulnerability that
gives access to the system to an adversary, then you have succeeded
your goal to protect the key but failed on the goal to protect the
data the key is encrypting/decrypting. Thus making the effort to
protect the session key pretty futile, as it is as important as the
data it protects.

> I want to protect inside of the HSM all of the following:
> a) the private keys related to the server or client identity

This makes sense because a private key is used more than one sessions
and can be used to attack future (and in some cases past sessions).

> b) the pre-master key
> c) the master key
> d) the session keys.

All of these are session-specific keys and protect the data that are
exchanged in that particular session. IMO there is no much sense
trying to isolate them from the software handling the data.

regards,
Nikos