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

Michael StJohns <msj@nthpermutation.com> Wed, 25 September 2013 03:09 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD3311E81A4 for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 20:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.567
X-Spam-Level:
X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9YR+PlwAmdR for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 20:09:04 -0700 (PDT)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id CFA2411E8106 for <tls@ietf.org>; Tue, 24 Sep 2013 20:08:51 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id c9so3812272qcz.28 for <tls@ietf.org>; Tue, 24 Sep 2013 20:08:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=jgvjnjenvmN0YGb7CRUquCzfj4qQ6LFHD+qWVJZL8mE=; b=mq2tCJqLpTYm8wJDlllMGAYqDYELUa0YU2LqA0TpIC8riDwTyMfA4Wc0ozk9gDrxM6 foXSL5iTtgEl4SjX9GBi1uOW+i3epPFFcOrVIRCxpPul3xDoDIVVvDd4PhNPxyGjb7un niKn+/8km+hT6WcsLZjAU0HHv8q+Bdlcgs/UCoE1eAf3FvQdwpk/5lBN0L9eBzh43q2H VYkTIeRlUo+KXz1KxyZgpHPYzBLxMevNxal/QfFXAV8M+qGTQFiWEYCDThUMvuLOYUNu nLx1uNqtx1rjMduVS47U7TJI/keoc4ucFjUs5d0AzzzylQQtHESJ100nmcsXgNz7GICo LP1Q==
X-Gm-Message-State: ALoCoQkYcRljY94FMUx1U4dRFxLJHFxJFf5jnBo5+uP5X3B1iVwZX50mFRv/Gl62rb1uVutXKcfj
X-Received: by 10.229.30.7 with SMTP id s7mr41645527qcc.7.1380078529241; Tue, 24 Sep 2013 20:08:49 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id u8sm58483279qef.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 20:08:48 -0700 (PDT)
Message-ID: <524253C1.7090509@nthpermutation.com>
Date: Tue, 24 Sep 2013 23:08:49 -0400
From: Michael StJohns <msj@nthpermutation.com>
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 <juraj.somorovsky@rub.de>
References: <CE662EA4.B66B%kenny.paterson@rhul.ac.uk> <5240A4F9.2020308@nthpermutation.com> <5242026B.1000303@rub.de>
In-Reply-To: <5242026B.1000303@rub.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2013 03:09:10 -0000

On 9/24/2013 5:21 PM, Juraj Somorovsky wrote:
> On 09/23/2013 10:30 PM, Michael StJohns wrote:
>>> TL;DR: you can recover low entropy GCM plaintexts if the same key is used
>>> in a mode like CBC.
>> Right.  But you can't recover the key.
>>
>> Let me reiterate the threat model:
>>
>> 1) All keys are kept in an HSM (not supposed to be extracted - but TLS
>> KDF trivially allows this)
>> 2) Attacker has access to use the keys (e.g. either has HSM credentials,
>> or has hacked the program using the HSM that has HSM credentials - the
>> TLS stack for example).
> You are right, the attacks do not apply to your scenario since they do
> not recover the key.
>
> ...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.

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

Mike



> Thanks
> Juraj
>
>