Re: [TLS] HSM-friendly Key Computation

Michael StJohns <msj@nthpermutation.com> Sun, 19 April 2015 18:49 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620331A8F39 for <tls@ietfa.amsl.com>; Sun, 19 Apr 2015 11:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtQLzrItgB-c for <tls@ietfa.amsl.com>; Sun, 19 Apr 2015 11:49:53 -0700 (PDT)
Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2F61A8F33 for <tls@ietf.org>; Sun, 19 Apr 2015 11:49:53 -0700 (PDT)
Received: by qgfi89 with SMTP id i89so43576542qgf.1 for <tls@ietf.org>; Sun, 19 Apr 2015 11:49:52 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bawt2J2DbpIKSmA3iecHmVNx1k7LNjQ/sNFs+B0ZMS8=; b=j9Mfcpmzhz5B7KsqaQ3srJGFnsM5pypmy/C+KLNFBkLRAt6RTHkG/HgtNaJWt5xHwR Pwkc4+4+ZYXluTFpaWTHH4KFf0LvaxyLMXge5jtWnjpWEOsp/7fOFq5MgiAtAxrBei6f ReLK087aU4KZ6iuape1jdUfw1tIobB7YkffeBx8UqWJ4aTtSzCmu7u8GztEYtQ3WfkXb wh/kEMSMdlutAn/eN27Q/4H9RykSfcGOlVuQsVAiGcoSCqiuxiroUeUiWBQTtn9kqUci wxFDOs6l7Y4/EDY1aHTgt9GdcyxoYOzEu0zZu3xmWEieT9LAsMR4tUSS+65F+ecEmlpY TWug==
X-Gm-Message-State: ALoCoQkJw/lXHi2Uu8HuPz5/az+PhlYEC+ydZXBRmhNNboZgH2NA+jJeknGx36FtoBDVqlcNixqC
X-Received: by 10.55.25.34 with SMTP id k34mr22871227qkh.12.1429469392694; Sun, 19 Apr 2015 11:49:52 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:a9e1:16a3:552:1db4? ([2601:a:2a00:84:a9e1:16a3:552:1db4]) by mx.google.com with ESMTPSA id z14sm10313735qge.7.2015.04.19.11.49.51 for <tls@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 11:49:52 -0700 (PDT)
Message-ID: <5533F8D6.9070500@nthpermutation.com>
Date: Sun, 19 Apr 2015 14:49:58 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: tls@ietf.org
References: <0694C3DB-FB87-42A2-BCC4-CC0F761E9A03@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB000B0C@uxcn10-tdc05.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/UCXLfJ1pDNsSjQFktW_5O0XEMn8>
Subject: Re: [TLS] HSM-friendly Key Computation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 19 Apr 2015 18:49:55 -0000

On 4/19/2015 12:22 AM, Peter Gutmann wrote:
> Russ Housley <housley@vigilsec.com> writes:
>
>> If one wants to implement the cryptographic functions in a Hardware Security
>> Module (HSM), this structure is far from ideal.
> Weelll... it's far from ideal if you want to use traditional/historic PKCS #11
> mechanisms, but since a new PRF will need updated HSM support anyway

And that's where we differ I think.
> it
> shouldn't be any problem to accommodate it, and now that PKCS #11 is being
> managed by OASIS rather than RSADSI/EMC and things have got moving again in
> advancing the spec, it shouldn't be that big a deal.  If you look at how
> CKM_TLS_PRF works, it's a significant change from how C_DeriveKey() normally
> functions that was made in order to accommodate how TLS wants to do things.
> For the TLS 2.0 (a.k.a. 1.3) PRF the PKCS #11 folks can make the same
> accommodation.  It's an issue for the HSM vendors to adapt, not the TLS spec
> to adapt.

It's not exactly that.   If you go back and look at PKCS11 2.20 , you'll 
note that they just placed the TLS/SSL  functionality in by rote - 
mainly by hacking the PKCS11 mechanism construct to provide a way of 
outputting multiple keys.

There are actually SSL mechanisms:

CKM_SSL3_MASTER_KEY_DERIVE
CKM_SSL3_KEY_AND_MAC_DERIVE
CKM_SSL3_PRE_MASTER_KEY_GEN
CKM_SSL3_MASTER_KEY_DERIVE_DK

And TLS mechanisms

CKM_TLS_PRE_MASTER_KEY_GEN
CKM_TLS_MASTER_KEY_DERIVE
CKM_TLS_KEY_AND_MAC_DERIVE
CKM_TLS_MASTER_KEY_DERIVE_DH


They also handily provided the CKM_TLS_PRF  mechanism which basically 
allowed you to extract ANY key stream material from a given master 
secret (since all the bytes from a call using this mechanism were 
provided nicely packaged in the place specified in the mechanism 
structure).  But that was as was requested by TLS implementers and 
probably didn't get enough vetting by the security deep thinkers.

CKM_SSL_KEY_AND_MAC_DERIVE, CKM_TLS_KEY_AND_MAC_DERIVE and CKM_TLS_PRF 
are insecure in that they allow trivial extraction of material from a 
derived key stream.   That is an artifact of multiple things:  how the 
TLS KDF function is currently defined, the use of key exporters with out 
a model for cryptographic separation; the use of TLS specific functions.


PKCS11 tries to fix the worst of these in the new version when it added 
support for TLS1.2: 2.40 deprecates CKM_TLS_PRF, adds a CKM_TLS_MAC 
function for signing the finished messages, deprecates 
CKM_TLS_KEY_AND_MAC_DERIVE in favor of CKM_TL12_KEY_SAFE_DERIVE. There 
is a CKM_TLS12_KEY_AND_MAC_DERIVE, but it comes with a black box 
warning.  Its there only because the current AEAD suites require a 
source of session nonce information and they get it from the IV production.


What I would love to see for TLS1.3 is NO TLS specific mechanisms being 
added to PKCS11.    That if we still sign the finished message, we use a 
true MAC function.  That if we derive keys, we use a bog standard KDF.  
That we stomp on every TLS specific twist unless there is a specific 
security need to keep TLS secure.

At this point the set of KDFs in PKCS11 is very protocol specific and 
constitute a good part of the non-common mechanisms.  Most of the rest 
seem to relate to one family or another (e.g. suite b, GOST, etc).  It 
would be great if we could pick a standardized KDF of family of KDFs for 
the IETF and not go through this again.

Mike

>
> Peter.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls