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

"Juraj Somorovsky" <> Mon, 16 September 2013 22:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B4D711E8105 for <>; Mon, 16 Sep 2013 15:47:36 -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 DeqzRByPHcUg for <>; Mon, 16 Sep 2013 15:47:30 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 4A36711E8106 for <>; Mon, 16 Sep 2013 15:47:29 -0700 (PDT)
X-Queued: (qmail 20846 invoked by alias); 16 Sep 2013 22:47:28 -0000
X-RUB-Notes: Internal
X-Queued: (qmail 20779 invoked by uid 108); 16 Sep 2013 22:47:27 -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.060924 secs); 16 Sep 2013 22:47:27 -0000
Received: from ( by with SMTP; 16 Sep 2013 22:47:27 -0000
X-Queued: (qmail 30565 invoked by uid 992); 16 Sep 2013 22:47:27 -0000
X-Qmailscanner: from (7Cil8M2CiUx4WqKSFE7Ynw==@ by (envelope-from <>, uid 0) with qmail-scanner-2.01 (sophie: 3.06/3.45.0/4.91. Clear:RC:1( Processed in 0.033144 secs); 16 Sep 2013 22:47:27 -0000
Received: from (HELO ? (7Cil8M2CiUx4WqKSFE7Ynw==@ by with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 16 Sep 2013 22:47:27 -0000
Date: 17 Sep 2013 00:47:03 +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, 16 Sep 2013 22:47:36 -0000

Hi Mike,

On 09/06/2013 06:10 AM, Michael StJohns wrote:
> That still leaves a second problem.  The "key expansion" stage produces
> both private (key material) and public (iv data) by producing a key
> stream and then splitting up (based on the sizes of keys needed) into
> the 4 keys and 2 IVs.
> o Consider  an application that needs to produce 2 128 bit AES keys and
> 2 IVs (for say GCM).
> o Consider that an attacker (or a hacked program that's being used to
> extract keys) re-runs the derivation using the same master key and same
> random data, this time specifying zero length keys (or 64 bits of keys
> etc), but still asks for the IV material.
Just a quick questions:
I do not know if I understand this scenario correctly...but how can this
be achieved in TLS?
New key/IV material is always generated from client's as well as
server's random. The attacker can choose the same client random, but he
cannot influence the server random... thus always new key/IV material is

Maybe in a PKCS11 scenario this is different?
> The part of the key stream previously assigned to the encryption keys is
> now assigned to the IV material.  Since IVs by their nature are public,
> the attacker now has direct access to the key material previously used
> for encryption.
> Fortunately, TLS1.1 changed the way IVs were calculated making it
> possible to prohibit that leaking.  Unfortunately, the CCM and GCM
> mechanisms for TLS1.2 decided to use the IV values making impossible to
> prohibit the leaking.
> For the current PKCS11 draft, we finessed it by creating two mechanisms
> - one that created only key material, and one that created key material
> and IVs.  PKCS11 allows a specific key to be constrained to a specific
> mechanism so that permits some security for the non-AEAD suites.  It's
> not ideal, but its a beginning
I would propose to make it more concrete for PKCS11 and generate the
keys depending on the algorithms they are used in. For example, if you
have a master_secret used to generate keys for AES_GCM and AES_CBC, you
would use:
k_GCM = PRF(master_secret, "AES_GCM", [further params])
k_CBC = PRF(master_secret, "AES_CBC", [further params])

This ensures that the attacker cannot enforce the same key is used for
two different algorithms, which could lead to some specific attacks (for
more information see our paper on Backwards compatibility attacks:

Best Regards