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

"Juraj Somorovsky" <> Mon, 23 September 2013 09:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 218FA21F9946 for <>; Mon, 23 Sep 2013 02:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.249
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pg+CZMRlBaAW for <>; Mon, 23 Sep 2013 02:24:36 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 9E47411E81AF for <>; 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 by (envelope-from <>, uid 102) with qmail-scanner-2.01 (sophie: 3.05/3.42/4.88. Clear:RC:1( Processed in 0.057764 secs); 23 Sep 2013 09:20:39 -0000
Received: from ( by 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 (7Cil8M2CiUwAdij50vwJ6A==@ by (envelope-from <>, uid 0) with qmail-scanner-2.01 (sophie: 3.06/3.45.0/4.91. Clear:RC:1( Processed in 0.0229 secs); 23 Sep 2013 09:20:38 -0000
Received: from (HELO ? (7Cil8M2CiUwAdij50vwJ6A==@ by with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 23 Sep 2013 09:20:38 -0000
Date: 23 Sep 2013 11:20:36 +0200
Message-ID: <>
From: "Juraj Somorovsky" <>
To: "Michael StJohns" <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?