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