Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
"Juraj Somorovsky" <juraj.somorovsky@rub.de> Mon, 23 September 2013 09:24 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 218FA21F9946 for <tls@ietfa.amsl.com>;
Mon, 23 Sep 2013 02:24:43 -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 Pg+CZMRlBaAW for
<tls@ietfa.amsl.com>; Mon, 23 Sep 2013 02:24:36 -0700 (PDT)
Received: from mx6.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de
[134.147.64.30]) by ietfa.amsl.com (Postfix) with SMTP id 9E47411E81AF for
<tls@ietf.org>; Mon, 23 Sep 2013 02:23:15 -0700 (PDT)
X-Queued: (qmail 13638 invoked by alias); 23 Sep 2013 09:21:48 -0000
X-RUB-Notes: Internal
X-Queued: (qmail 10111 invoked by uid 108); 23 Sep 2013 09:20:39 -0000
X-Qmailscanner: from 134.147.42.227 by mx6.rz.ruhr-uni-bochum.de
(envelope-from <juraj.somorovsky@rub.de>, uid 102) with qmail-scanner-2.01
(sophie: 3.05/3.42/4.88. Clear:RC:1(134.147.42.227):. Processed in 0.057764
secs); 23 Sep 2013 09:20:39 -0000
Received: from mail1.mail.ruhr-uni-bochum.de (134.147.42.227) by
mx6.rz.ruhr-uni-bochum.de with SMTP; 23 Sep 2013 09:20:39 -0000
X-Queued: (qmail 22253 invoked by uid 992); 23 Sep 2013 09:20:38 -0000
X-Qmailscanner: from 134.147.40.78 (7Cil8M2CiUwAdij50vwJ6A==@134.147.40.78) 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(134.147.40.78):. Processed in 0.0229 secs);
23 Sep 2013 09:20:38 -0000
Received: from jontop.nds.ruhr-uni-bochum.de (HELO ?134.147.40.78?)
(7Cil8M2CiUwAdij50vwJ6A==@134.147.40.78) by mail1.mail.ruhr-uni-bochum.de
with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 23 Sep 2013 09:20:38 -0000
Date: 23 Sep 2013 11:20:36 +0200
Message-ID: <524007E4.5080303@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> <523AAA0E.2020105@rub.de>
<523DEED6.1060501@nthpermutation.com>
In-Reply-To: <523DEED6.1060501@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: Mon, 23 Sep 2013 09:24:45 -0000
On 09/21/2013 09:09 PM, Michael StJohns wrote: > Thanks for this. I think it can be fixed though and relatively simply, > but will require changes to the key expansion step that are a bit more > than I suggested: > > E.g. in addition to the master_key, label and random data being fed into > the KDF, also feed in - in order for each output key - 2 or 4 bytes each > that describe the length of the key. And that's taken directly from the > inputs for the key lengths requested. > > That means that any time you vary the length of ANY key in the key > expansion, the entire key stream changes. > > It also means that there isn't a need for a separate IV sub key for the > key expansion stage (I think....) I do not think this is enough to solve this problem. There are algorithms that have the same key and IV lengths....e.g. an AES-128 key has the same length as the IV used in AES-CBC. I think this would break your key derivation??? An additional problem is that the same key would be used for the same block ciphers in different modes of operation, e.g. AES-CBC would use the same key as AES-GCM. As mentioned in my previous post, a solution would be to derive the material based on the master secret and the encryption scheme / IV it is used for. For example you could derive : - a symmetric key for AES-GCM: k_GCM = PRF(master_secret, "AES_GCM", [further params]) - a symmetric key for AES-CBC: k_CBC = PRF(master_secret, "AES_CBC", [further params]) - initialization vector: IV = PRF(master_secret, "IV", [further params]) This solution however assumes that if k_GCM is generated, the attacker cannot enforce the PKCS11 module to use it for the AES-CBC computation. Again, I am not that familiar with PKCS11...can this be achieved in a typical PKCS11 module? In other words: can a PKCS11 module admin/user enforce that if a specific material is derived with a "AES-GCM" parameter, the resulted key can only be used in AES-GCM? Thanks Juraj
- [TLS] TLS and hardware security modules - some is… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Juraj Somorovsky
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Martin Rex
- Re: [TLS] TLS and hardware security modules - som… Pascal Urien
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Salz, Rich
- Re: [TLS] TLS and hardware security modules - som… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] TLS and hardware security modules - som… Martin Rex
- Re: [TLS] TLS and hardware security modules - som… Salz, Rich
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Nikos Mavrogiannopoulos
- Re: [TLS] TLS and hardware security modules - som… Bill Frantz
- Re: [TLS] TLS and hardware security modules - som… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] TLS and hardware security modules - som… Juraj Somorovsky
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Juraj Somorovsky
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Paterson, Kenny
- Re: [TLS] TLS and hardware security modules - som… Michael D'Errico
- Re: [TLS] TLS and hardware security modules - som… Nico Williams
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Nico Williams
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Juraj Somorovsky
- Re: [TLS] TLS and hardware security modules - som… Michael StJohns
- Re: [TLS] TLS and hardware security modules - som… Juraj Somorovsky