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

"Juraj Somorovsky" <juraj.somorovsky@rub.de> Tue, 24 September 2013 21:22 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 E343811E8165 for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 14:22:07 -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 wujWRJvCMs8l for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 14:22:01 -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 00DE421F9CC5 for <tls@ietf.org>; Tue, 24 Sep 2013 14:21:53 -0700 (PDT)
X-Queued: (qmail 12462 invoked by alias); 24 Sep 2013 21:21:50 -0000
X-RUB-Notes: Internal
X-Queued: (qmail 12399 invoked by uid 109); 24 Sep 2013 21:21:49 -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.055776 secs); 24 Sep 2013 21:21:49 -0000
Received: from mail1.mail.ruhr-uni-bochum.de (134.147.42.227) by mx4.rz.ruhr-uni-bochum.de with SMTP; 24 Sep 2013 21:21:49 -0000
X-Queued: (qmail 8398 invoked by uid 992); 24 Sep 2013 21:21:49 -0000
X-Qmailscanner: from 178.201.6.234 (7Cil8M2CiUy55WCzq+DQ4w==@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.023142 secs); 24 Sep 2013 21:21:49 -0000
Received: from ip-178-201-6-234.unitymediagroup.de (HELO ?192.168.0.103?) (7Cil8M2CiUy55WCzq+DQ4w==@178.201.6.234) by mail1.mail.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 24 Sep 2013 21:21:49 -0000
Date: 24 Sep 2013 23:21:47 +0200
Message-ID: <5242026B.1000303@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: <CE662EA4.B66B%kenny.paterson@rhul.ac.uk> <5240A4F9.2020308@nthpermutation.com>
In-Reply-To: <5240A4F9.2020308@nthpermutation.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
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: Tue, 24 Sep 2013 21:22:08 -0000

On 09/23/2013 10:30 PM, Michael StJohns wrote:
>> TL;DR: you can recover low entropy GCM plaintexts if the same key is used
>> in a mode like CBC.
> 
> Right.  But you can't recover the key.
> 
> Let me reiterate the threat model:
> 
> 1) All keys are kept in an HSM (not supposed to be extracted - but TLS
> KDF trivially allows this)
> 2) Attacker has access to use the keys (e.g. either has HSM credentials,
> or has hacked the program using the HSM that has HSM credentials - the
> TLS stack for example).
You are right, the attacks do not apply to your scenario since they do
not recover the key.

...Sorry, my last one attack scenario :) ...assuming you are going to
use your KDF taking as input the key length. This would mean you would
generate the same key for AES-128 and RC4? (both have the key lengths of
16 bytes)

If the user would use AES-128, the attacker could force the HSM to
regenerate a new key for RC4 (in this case the same key as for AES-128
would be generated) and generate the RC4 keystream. Afterwards, he could
run one of the attacks against RC4 to learn the original RC4 key (and
thus also the AES key).

Does it make sense?
Thanks
Juraj