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

"Juraj Somorovsky" <> Wed, 25 September 2013 07:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B275C21F9F34 for <>; Wed, 25 Sep 2013 00:33:46 -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 1VHp5-00C0VK for <>; Wed, 25 Sep 2013 00:33:40 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 130AC21F9F26 for <>; Wed, 25 Sep 2013 00:33:39 -0700 (PDT)
X-Queued: (qmail 1864 invoked by alias); 25 Sep 2013 07:33:38 -0000
X-RUB-Notes: Internal
X-Queued: (qmail 1611 invoked by uid 109); 25 Sep 2013 07:33:37 -0000
X-Qmailscanner: from by (envelope-from <>, uid 103) with qmail-scanner-2.01 (sophie: 3.05/3.42/4.88. Clear:RC:1( Processed in 0.055952 secs); 25 Sep 2013 07:33:37 -0000
Received: from ( by with SMTP; 25 Sep 2013 07:33:36 -0000
X-Queued: (qmail 21827 invoked by uid 992); 25 Sep 2013 07:33:36 -0000
X-Qmailscanner: from (7Cil8M2CiUxgePeMW6VfJQ==@ by (envelope-from <>, uid 0) with qmail-scanner-2.01 (sophie: 3.06/3.45.0/4.91. Clear:RC:1( Processed in 0.025836 secs); 25 Sep 2013 07:33:36 -0000
Received: from (HELO ? (7Cil8M2CiUxgePeMW6VfJQ==@ by with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 25 Sep 2013 07:33:35 -0000
Date: 25 Sep 2013 09:33:35 +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
Cc: "" <>
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: Wed, 25 Sep 2013 07:33:46 -0000

On 09/25/2013 05:08 AM, Michael StJohns wrote:
>> ...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?
> Yes.  But preventing that requires a different/additional set of policy
> protections to be built into PKCS11.  I'm working on them in the PKCS11
> group.  The general idea is provide a way to specify mandatory policies
> (e.g. key types) for keys derived from other keys.  That problem is
> broader than just the KDFs used for TLS.
I understand that it is not that easy...

Are these policies going to restrict the key usage based on the KDF input?
If yes, what speaks against to use a derivation concept that takes as
input algorithm name the key is used for?

The key derivation based on the algorithm name (+ its key length) brings
the same security as yours. In addition, once your PKCS11 policy concept
is ready and implemented in HSMs, one could define new policies based on
the input of the KDF and restrict the usage of the derived keys.
> In some ways, the right answer to the above threat is to prevent the
> module from actually providing RC4 based keys and mechanisms.  Ah well....
Yes, it would be possible to define only a set of secure ciphers (and
thus remove RC4)...however, what happens if one of these secure ciphers
is broken and thus affects security of a different one, which
accidentally uses the same key length?