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

"Juraj Somorovsky" <juraj.somorovsky@rub.de> Thu, 19 September 2013 07:39 UTC

Return-Path: <juraj.somorovsky@rub.de>
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 825CF21F992B for <tls@ietfa.amsl.com>; Thu, 19 Sep 2013 00:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 RsNIx4x06KqD for <tls@ietfa.amsl.com>; Thu, 19 Sep 2013 00:39:00 -0700 (PDT)
Received: from mx4.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.53]) by ietfa.amsl.com (Postfix) with SMTP id CAE3C21F97C7 for <tls@ietf.org>; Thu, 19 Sep 2013 00:38:59 -0700 (PDT)
X-Queued: (qmail 23066 invoked by alias); 19 Sep 2013 07:38:58 -0000
X-RUB-Notes: Internal
X-Queued: (qmail 22984 invoked by uid 109); 19 Sep 2013 07:38:56 -0000
X-Qmailscanner: from 134.147.42.227 by mx4.rz.ruhr-uni-bochum.de (envelope-from <juraj.somorovsky@rub.de>, uid 103) with qmail-scanner-2.01 (sophie: 3.05/3.42/4.88. Clear:RC:1(134.147.42.227):. Processed in 0.05432 secs); 19 Sep 2013 07:38:56 -0000
Received: from mail1.mail.ruhr-uni-bochum.de (134.147.42.227) by mx4.rz.ruhr-uni-bochum.de with SMTP; 19 Sep 2013 07:38:56 -0000
X-Queued: (qmail 889 invoked by uid 992); 19 Sep 2013 07:38:56 -0000
X-Qmailscanner: from 178.201.6.234 (7Cil8M2CiUwoiuklz5GN4w==@178.201.6.234) by mail1.mail.ruhr-uni-bochum.de (envelope-from <juraj.somorovsky@rub.de>, uid 0) with qmail-scanner-2.01 (sophie: 3.06/3.45.0/4.91. Clear:RC:1(178.201.6.234):. Processed in 0.022493 secs); 19 Sep 2013 07:38:56 -0000
Received: from ip-178-201-6-234.unitymediagroup.de (HELO ?192.168.0.103?) (7Cil8M2CiUwoiuklz5GN4w==@178.201.6.234) by mail1.mail.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 19 Sep 2013 07:38:55 -0000
Date: 19 Sep 2013 09:38:54 +0200
Message-ID: <523AAA0E.2020105@rub.de>
From: "Juraj Somorovsky" <juraj.somorovsky@rub.de>
To: "Michael StJohns" <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
References: <522955BC.8000407@nthpermutation.com> <52378A67.9010903@rub.de> <52379643.7070705@nthpermutation.com>
In-Reply-To: <52379643.7070705@nthpermutation.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
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: Thu, 19 Sep 2013 07:39:06 -0000

On 09/17/2013 01:37 AM, Michael StJohns wrote:
> On 9/16/2013 6:47 PM, Juraj Somorovsky wrote:
>> Just a quick questions:
>> I do not know if I understand this scenario correctly...but how can this
>> be achieved in TLS?
>> New key/IV material is always generated from client's as well as
>> server's random. The attacker can choose the same client random, but he
>> cannot influence the server random... thus always new key/IV material is
>> generated.
> 
> This isn't about influencing the new key, but being able to extract the
> old key.  Assume the attacker a) has use of the master key (either
> because he's running as hacked code, or because he managed to capture
> the PKCS11 pin and has access to the PKCS11 module), b) has captured all
> the necessary public data (e.g. has the previous random values from
> listening to the TLS exchange).   He then calls PKCS11 with the master
> key, the random data, but specifies that he needs smaller (e.g. no) mac
> and encryption keys.  The part of the key stream previously assigned to
> the mac and encryption keys (and safely protected inside the PKCS11
> module) is now assigned to the IV part of the structure and is now
> accessible to the attacker/caller of the module.   That attacker then
> takes that data and sends it off to someone who can intercept the
> traffic somewhere in the middle. There are a number of sub-scenarios
> which are dependent on where the PKCS11 module is, and where the
> attacker is and where the data is intercepted.

Thanks for the explanation, I understand it now. If this is how PKCS11
modules could be used in SSL, I admit this is a threat and agree with
your changes.

>> I would propose to make it more concrete for PKCS11 and generate the
>> keys depending on the algorithms they are used in. For example, if you
>> have a master_secret used to generate keys for AES_GCM and AES_CBC, you
>> would use:
>> k_GCM = PRF(master_secret, "AES_GCM", [further params])
>> k_CBC = PRF(master_secret, "AES_CBC", [further params])
> 
> As long as you can control the length of the encryption and mac key in
> the call to PKCS11, you have an issue if you can produce IV material
> from the same key stream you use to produce encryption or mac keys.   
> If you're suggesting using the above for generating IV material, it's
> doable, but maybe a bit of overkill.  I'd rather generate the IV from
> the public information only (e.g. only use the random data as the PRF
> seed).
Let me please extend your scenario:
o Consider  an application that needs to produce 2 128 bit AES keys.
o Consider that an attacker (or a hacked program that's being used to
extract keys) re-runs the derivation using the same master key and same
random data, this time specifying 64 bits of DES keys.
o Consider that the attacker can "break" DES (can get key from
plaintext-ciphertext pairs), but cannot break AES.

The part of the key stream previously used for AES is now assigned to
the DES keys. If the PKCS11 module now produces some
plaintext-ciphertext pairs, the attacker can break DES and thus gets
part of the key stream previously assigned to AES.

I admit I am not that familiar with PKCS11 modules used in
TLS...However, would this be a valid scenario?

My previous point was to extend your algorithm to force different keys
for different security algorithms.

Thanks
Juraj