Re: [TLS] HSM-friendly Key Computation

Michael StJohns <> Wed, 22 April 2015 21:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C0EF71B2A1A for <>; Wed, 22 Apr 2015 14:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HkTBts1YCW87 for <>; Wed, 22 Apr 2015 14:30:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C5131B2A1B for <>; Wed, 22 Apr 2015 14:30:55 -0700 (PDT)
Received: by pdbqa5 with SMTP id qa5so284943303pdb.1 for <>; Wed, 22 Apr 2015 14:30:54 -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 :subject:references:in-reply-to:content-type; bh=IAah5Q3F34eI9SVJZAYfUn2YMv98B+HV5PBmRlb8K2Y=; b=hzpNiwtn7oFgxE3J1L8B4vig6FqDvQVtHwPYf1FI4Ua0hpAd4lbIqPQvI35egJ5Pmi WPBm2XUv11DXI22nfzS+LVHEfnA+QaNI/VaqnNpHp091OWfDkIQ9Sd91TItRnVmmcXBT mNjh42OKan0V5kiqN4VIqF8bjSsr+aMYsDTHICzRqu8QsOgjwkEFPc1ZvPmxan7vcWc4 NghQapfRjlm/OSyO4eZyhm4edPr2Hs436ir1V6+KGGmA37IH1Kvt2ou8avl8ziQ9H3/y uLagibaNHyMBWR7ofX+bY3wuxn/qQlsTSpcpfRffuKWKByxVgWmZKe7Pph8QAAwamXzd 7D9Q==
X-Gm-Message-State: ALoCoQks8RpJioS0U8j/1qlr1dhgZUM5CVU8b0JTUDIciS6bQLicItWDI46mf3e6zrORL0bkFOFC
X-Received: by with SMTP id a16mr46674592pbu.49.1429738254847; Wed, 22 Apr 2015 14:30:54 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id rd7sm5991851pdb.64.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 14:30:54 -0700 (PDT)
Message-ID: <>
Date: Wed, 22 Apr 2015 17:30:42 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
References: <> <> <> <20150420064243.GA7322@LK-Perkele-VII> <> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070108020204020306080602"
Archived-At: <>
Subject: Re: [TLS] HSM-friendly Key Computation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Apr 2015 21:30:58 -0000

On 4/22/2015 1:37 PM, Eric Rescorla wrote:
> If we're using HKDF-Extract, can we just key off different labels?
> -Ekr

Basically, no.

The Extract function is really not designed to be used standalone but as 
a way of concentrating entropy for input to the expansion phase.  Its 
dangerous to talk of these functions as separately callable.  They are 
steps not separate functions.

  The extract step's only non-key input - salt - is not the same as the 
"info" input used in the expand phase - 'salt' is supposed to be missing 
or random,  not a fixed string like a label.

"info" is where the various labels go and that's only present in the 
expand phase.

What you want to do is specify as part of the mixins (e.g. 'info' - e.g. 
the collection of label and context)  a set of fields that describe 1) 
how the key stream is going to be broken up (eg. lengths of the sub 
keys), 2) what algorithms will use each of the parts of the key stream, 
and 3) whether or not those parts are allowed to be exported/extracted.

A software module will basically ignore these because - really - its all 
the same memory although it should really make sure the key lengths and 
types matc.  An HSM will look at these and be able to make policy 
decisions for protection of the segments (e.g. preventing export of 
material that was created to be non-exportable).

Having all of these in the mixins means that the key stream expansion 
completely changes if ANY of these mixins change which in turn means  
that the various ways you can use to extract truly secret key material 
(as differentiated from exportable material) from an HSM using the 
currently defined mechanism can be eliminated.  (I can explain my 
reasoning if necessary).


> On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara 
> < <>> wrote:
>     On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote:
>     > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
>     > >
>     > >There are other places in TLS that fundamentally need to (indirectly) derive
>     > >public data out of secret key material.
>     > That's not a a problem. The problem is using the same mechanism
>     to derive
>     > the public data that we use to derive the keys.
>     > It's even OK to use the same secret key for both (from an HSM POV).
>     >
>     > What Michael is saying is that there are existing functions for
>     both KDF
>     > (secret material -> key) and Mac (secret material-> unique
>     public data).
>     > He's requesting that TLS not have it's own versions of these
>     functions.
>     So would using two different PRF functions, one for parts that don't
>     downgrade and another for parts that do downgrade (e.g. IV derivation,
>     unique / finished calculations, exporter calculations, etc..)
>     solve the
>     issue?
>     (Of course, the two functions should be closely related, so not to
>     annoy software implementations too much)...
>     -Ilari
>     _______________________________________________
>     TLS mailing list
> <>
> _______________________________________________
> TLS mailing list