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

Michael StJohns <> Sat, 21 September 2013 19:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F71011E8180 for <>; Sat, 21 Sep 2013 12:09:37 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jU+eYgu8QHbw for <>; Sat, 21 Sep 2013 12:09:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4F29E21F9B10 for <>; Sat, 21 Sep 2013 12:09:11 -0700 (PDT)
Received: by with SMTP id c3so1079857qcv.18 for <>; Sat, 21 Sep 2013 12:09:10 -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=mPVXnhLh+lID9l5iLN6CEAgGgy/57co8PviWH9wamZg=; b=nGVRZTgmM+JSCP2lAbTb6uVV+xKOOoBgTURs04pFZID/bCK9M+GlhlaQDiJm7f0mQB II0rZOzyXNHDt/8ouFTMzdOlwHVIUYJF088Da3wK+JEIwjaY0VeowxeWdR3zVp4c+dYa 3usov03XYwpmTxXTNL4BNHfNr86KkoJQsgQaCYij5xPXW9hZfiKdpdpcwnbmI9D6V/Qp g1j67vH18s92TeC20eVQpV8Na2DTaDIu/l1WDQ12GYAcFixoUbnpH6rwKIn7ciIXH6MQ liow3Qt17kDQbzuiX/eJh2Q7pnOPO9QF4MQlJ2jVZ2loOj5w06292dcIyvIlbSjhs79V z01w==
X-Gm-Message-State: ALoCoQmhJ4wdKR/zsF//qFwOGWZWaOImEHYFDipDNK/dwTLN+jO+DB8Du7jBKgnlvnHp6qBYttwO
X-Received: by with SMTP id n5mr12080365qel.31.1379790550793; Sat, 21 Sep 2013 12:09:10 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id d3sm29688457qad.2.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 12:09:10 -0700 (PDT)
Message-ID: <>
Date: Sat, 21 Sep 2013 15:09:10 -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: Sat, 21 Sep 2013 19:09:37 -0000

On 9/19/2013 3:38 AM, Juraj Somorovsky wrote:
> Let me please extend your scenario:
> o Consider  an application that needs to produce 2 128 bit AES keys.
> 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 64 bits of DES keys.
> o Consider that the attacker can "break" DES (can get key from
> plaintext-ciphertext pairs), but cannot break AES.
> The part of the key stream previously used for AES is now assigned to
> the DES keys. If the PKCS11 module now produces some
> plaintext-ciphertext pairs, the attacker can break DES and thus gets
> part of the key stream previously assigned to AES.
> I admit I am not that familiar with PKCS11 modules used in
> TLS...However, would this be a valid scenario?

Yes and yes.

Yes - PKCS11 doesn't actually get any information on the specific TLS 
suite, so it doesn't know what keys are required or their length.   And 
the suites are all over the place in required keys and lengths - the 
null encryption suites don't require encryption keys, and the AEAD 
suites don't require MAC keys, so PKCS11 can't really enforce minimum 
lengths there.

Yes - yuck - I didn't even consider this.  Even if you don't leak out 
into the IV, there are crypto algorithms still in use with way too short 
key lengths.  You could do exactly what you said and use this to brute 
force the DES 56 bit keys (plus 8 parity) and then concatenate the 
individual results to get the AES keys.

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'll write it up.