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

Michael StJohns <msj@nthpermutation.com> Sat, 21 September 2013 18:50 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 47A4A21F9CAD for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 11:50:01 -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 V5Lfa6cOS8cu for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 11:49:55 -0700 (PDT)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4152E21F9CA5 for <tls@ietf.org>; Sat, 21 Sep 2013 11:49:55 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id x12so1066412qcv.22 for <tls@ietf.org>; Sat, 21 Sep 2013 11:49:53 -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=PanvOF8/rlCcrDRYlWKX9uhKzHSeLCoKy4q0X8+A3dM=; b=NvXpe7+KHeAAG6A1kP7hsVhMOjAKhWSw2u5GK+sP2IZY9wWCsLU7/bvEBQ34OboH3H S2IH6vO949E5p5rye7QpltqMNLjqcaHCMC8nIq+pxbQUAxRDwjFwp9QhtqPBKYpishQL mNnpUSJSWOf8ZjxTTaF45iBH0zbUXnSYq1TVm/N9KeRDaov3j3j3huKV6djY20b32cyz Q5u46rUnFeZnM+a0yEhSGCz8lXdrBI9yX6ye4ackWPYrWG4z1l1kWbWcy5rUUHYZZvGO r0iMwnFVyvzrByu7seVr/yNCzSAnx8pMIQ1iLcvtTJMsC/WcF2ARWotrivr3MHBOq86o 0hNg==
X-Gm-Message-State: ALoCoQndQOs+Z3y/sDllmQaxw5xCp6/zDhAQ4ZwU+OX14wwmu4b0QKjep2K80b8hKbHcUiPlhdOV
X-Received: by 10.229.229.70 with SMTP id jh6mr19746363qcb.12.1379789393625; Sat, 21 Sep 2013 11:49:53 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id d3sm29542468qad.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 11:49:53 -0700 (PDT)
Message-ID: <523DEA51.9050701@nthpermutation.com>
Date: Sat, 21 Sep 2013 14:49:53 -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: Nikos Mavrogiannopoulos <nmav@gnutls.org>
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com> <CAJU7zaJChK5VyqFmsLsPxKJEBXCnMZuouQ1_=UGnRftTUxsmGA@mail.gmail.com>
In-Reply-To: <CAJU7zaJChK5VyqFmsLsPxKJEBXCnMZuouQ1_=UGnRftTUxsmGA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; 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: Sat, 21 Sep 2013 18:50:01 -0000

I'm going to top post - this is a general response to three messages 
with the gist "why do you want to protect the session keys inside the HSM"?

The threat model I'm trying to protect against is an authorized user of 
the HSM (hardware security module) keys who is none the less illegitimate:

  o someone who stole the PIN or credential to access the HSM
  o a hacked program that is doing everything the original program was 
designed to do, but is also extracting and relaying data to a third party.

In both of these cases, assume that the design of the TLS protocol (or 
the HSM module) is such that the session keys can be extracted (either 
by design, or as a side effect of things like how the key expansion 
stage was defined).

Assume that an attacker can extract the session keys and send them to a 
third party.

Assume that the sending of a few key blobs (containing the extracted 
session keys) is less detectable than sending the entire stream of a TLS 
connection.

Assume that the third party can capture the TLS  packet stream at some 
point between the originator and destination.

Given these assumptions: an attacker can use the combination of key 
extraction and packet interception to do virtually undetectable 
interception of the decrypted stream.  Worse, it may be able to change 
the bits actually received in an undetectable manner.

Continuing on this - a smart attacker can decouple the key capture in 
time from the delivery of the key to an attacker.  E.g. batches up the 
capture of 50-100 key states and sends it to the third party maybe once 
a day.  Or publishes it as a steno on on the web server that was hacked. 
or... you get the idea.   As long as the attacker has a copy of the 
encrypted stream of data, he can do the decryption any time after he 
retrieves the key.


I'm of the opinion that it makes sense to make things harder on an 
attacker, and that means doing virtually all of the cryptographic 
operations within a cryptographic boundary.     There are times where 
this is neither necessary nor desirable, but for TLS, I would say that 
this should apply to most communications where there is real-world value 
involved, especially at the server side.

With respect to the specific TLS protocols and my suggestions about the 
key expansion stages, I'm hoping to get it to the point where the 
trivial key extraction attacks enabled by the current key expansion 
mechanism no longer exist.

Mike



On 9/17/2013 1:05 PM, Nikos Mavrogiannopoulos wrote:
> 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
>
>