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

Nico Williams <nico@cryptonector.com> Mon, 23 September 2013 20:27 UTC

Return-Path: <nico@cryptonector.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 350AA21F9D2E for <tls@ietfa.amsl.com>; Mon, 23 Sep 2013 13:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 CLX9U6GPswNu for <tls@ietfa.amsl.com>; Mon, 23 Sep 2013 13:27:22 -0700 (PDT)
Received: from homiemail-a84.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 618C121F9D3B for <tls@ietf.org>; Mon, 23 Sep 2013 13:27:22 -0700 (PDT)
Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id B0FF11DE155 for <tls@ietf.org>; Mon, 23 Sep 2013 13:23:29 -0700 (PDT)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 510F11DE192 for <tls@ietf.org>; Mon, 23 Sep 2013 13:00:36 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id tp5so7325075ieb.14 for <tls@ietf.org>; Mon, 23 Sep 2013 13:00:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e48CPQ4SirGJ8sw8mlgfClM7wcs/+dNdupIZamoLdcE=; b=Bapktvn3f/AXnZblNYkn05ewxuZFp5+M/YLHJ1g+7WEtcgdhQdfYDlfMweaL7qH2Zw Bt6ueH1B2pWiIcztVnl0b0cDT7/AivDwokcftwV6bGlqtnxl/A+gR4bMk42QxS4DGSs4 JCGeUalw5lsbynXTcl4cHzwSFE+OF7K6Y1Frkbvg3ysy7mOs9XKbo2Ln4CefloR1grrH V1k2QIM/WamV2s4IU9XT4Kj9CMvjvj/RtWDBAatD4ezZxHdXksfiRlnbxzdmQYffgdqj Z/q/WHI7pMFAJNfuDbkZjo8+XBRot4ZKFzFuS8RYGoTlT4DS9APVAF3BJinLiRTMGJNz jugQ==
MIME-Version: 1.0
X-Received: by 10.42.250.201 with SMTP id mp9mr15172827icb.0.1379966435436; Mon, 23 Sep 2013 13:00:35 -0700 (PDT)
Received: by 10.64.128.225 with HTTP; Mon, 23 Sep 2013 13:00:35 -0700 (PDT)
In-Reply-To: <52387927.4030007@nthpermutation.com>
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com>
Date: Mon, 23 Sep 2013 15:00:35 -0500
Message-ID: <CAK3OfOjeDm=shFqjHwJP6AW-0+keKc-px+jwkUVUqWeVmkyqBA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
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: Mon, 23 Sep 2013 20:27:28 -0000

On Tue, Sep 17, 2013 at 10:45 AM, Michael StJohns
<msj@nthpermutation.com> wrote:
> 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.

But evidently you must care about the application plaintext.  Why not
move the application into the HSM as well then?

That deserves a tongue-in-cheek smiley, of course :^)

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

Sure.

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

Why?  The HSM will become a cryptographic decelerator if you do that,
unless it's a fantastically expensive HSM anyways, and even then there
will be latency costs.  Meanwhile the session keys are of little or no
additional value to the application plaintext, and you're leaving the
application outside the HSM (of course, for obvious reasons).

So why do this?  The one answer that comes to mind is: to make sure
you get the crypto right, without possibility of screwups/backdoors in
various OS components (e.g., RNG).  But the performance cost more than
outweighs that answer in most of the use cases I can think of.

Nico
--