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

Michael StJohns <> Mon, 23 September 2013 16:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22F7121F9FBF for <>; Mon, 23 Sep 2013 09:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wQd3dhrD7WRq for <>; Mon, 23 Sep 2013 09:29:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C864E11E80ED for <>; Mon, 23 Sep 2013 09:29:32 -0700 (PDT)
Received: by with SMTP id a11so2287701qen.9 for <>; Mon, 23 Sep 2013 09:29:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RGU+SrUQQBMAxeZC5yZPg4WDkrIVwNt+97fgKZ95mj4=; b=lyJUuP0hpAqFkbKJfAkOfpGlnHRXjEBA+2xwXGP/zDSlnlvtqXdSw3LPjGnDDLr86m LszO17FalZC8ZUiBdX2fD56pe6mF/j4Ya+ygnwpzGh4J8LLFDXP0fs/4w5rDuTdbhtD4 GxXls0zKWt9DXsmkj7zPP9vp45EDVVatZNDFjY65u0Vp6blzhS1Bj/mJGAe4lmuUKTrn vBgVERwzjsgR7M8an2ZX1mIkFwGUTmPcxtqfW6/p/KTKLGosg4GLN9gary9T0Qm+ZNlK xEhTvw/4Tv0o1DntbziiOjvKXbi3UgQW39g1elCTkbESWWTIo2pN9zgalzav/O7DnHsr NklQ==
X-Gm-Message-State: ALoCoQlyQKjK+Cd10bMPY9CvCN2hSiq2HYl7BNW50W3C+Ey4ARbyCQE1iXPmHeSGoVawyqrmM7eh
X-Received: by with SMTP id c1mr3297248qam.100.1379953771289; Mon, 23 Sep 2013 09:29:31 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id x1sm45269353qai.6.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 09:29:30 -0700 (PDT)
Message-ID: <>
Date: Mon, 23 Sep 2013 12:29:30 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Juraj Somorovsky <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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 16:29:45 -0000

On 9/23/2013 5:20 AM, Juraj Somorovsky wrote:
> 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???

The general problem here is that pretty much all encryption modes are 
based on ECB - if you can do ECB, you can do the operations that make up 
the mode.

I don't think this is as much of an issue.  The DES key issue was of 
more interest because its substantially easier to brute force 2 keys of 
length 64 than it is a single key of length 128.  This appears to be no 
change in the attack surface to extract the key.

> 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])

The issue with the above approach is that the KDF is currently pretty 
generic - a key plus some public data (e.g. the label, the random 
stuff.  I can't prevent a re-derivation using whatever label the 
attacker wants to use.  So it would be pretty easy to generate either 
k_GCM or k_CBC given the master secret and the random stuff.

But mostly, I don't see this as a large threat  - how would this benefit 
an attacker with access to the master key?

The arguments against CBC tend to be with respect to attacks to recover 
the plain text, not the key.  The question I would ask for the above is 
whether being able to use the same AES key in multiple encryption modes 
provides additional attack surface to recover the key?  If not, then 
it's a don't care for PKCS11 I think.

> 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?

The admin can restrict a specific key to a specific set of mechanisms - 
e.g. CKM_AES_GCM.  There are some problems with this approach which 
we're working through having to do with how the restrictions are set and 
how they're retained across derivations.


> Thanks
> Juraj