<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/28/2017 1:04 AM, Jamil Nimeh
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Hi Mike, I know I said you made arguments in favor of specifying
the keys up front in init, but I'm still really uncomfortable with
this. It's been bothering me all day. Comments below:<br>
</blockquote>
<br>
Before I get to those:<br>
<br>
1) Do you know of any protocol using a KDF where the key production
information is not known before you'd need to call the .init()?<br>
2) If you do, couldn't you simply provide an empty or null list of
key derivation spec's to .init()?<br>
3) If you're doing a multiobject production from a single call to
.init() do you expect in all cases to NOT include the production
data as mixins?<br>
<br>
My problem is that I have use cases where ALL of my key production
information is used as mixins to the key stream. Now I could
provide a List<DerivationParameterSpec> as part of the KDF
init algorithm parameter spec (kdfParams), but that means that I
have to provide a different APS for each different key schedule
(consider TLS1.3s various calls). If you take out the
List<DerivationParameterSpec> out of the .init() I'll end up
having to do that and probably having to accept null values for the
deriveKey calls.<br>
<br>
More in line.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com"> <br>
<div class="moz-cite-prefix">On 11/27/2017 10:09 AM, Michael
StJohns wrote:<br>
</div>
<blockquote type="cite"
cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<div class="moz-cite-prefix">On 11/27/2017 1:03 AM, Jamil Nimeh
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com"> <br>
</blockquote>
<br>
HKDF and SP800-108 only deal with the creation of the key stream
and ignore the issues with assigning the key stream to
cryptographic objects. In the TLS version of HDKF, the L value
is mandatory and only a single object is assigned per init/call
to the KDF. An HSM can look at the HKDF label information and
set the appropriate policies for the assigned cryptographic
object (because if any of the label data changes, the entire key
stream changes). That's not the case for the raw HKDF nor for
any KDF that allows for multiple objects to be extracted out of
a single key stream. Hence the per-component length values.</blockquote>
So enforce a no-zero-length key policy in your provider code. You
probably can't affect the internals of the HSM, but you should be
able to prevent it in the provider code. I can't get away from
the feeling that this could be dealt with in other ways besides
specifying all this up-front.<br>
</blockquote>
<br>
The best way to understand this is to look at the PKCS11 TLS1.2 and
before KDF stuff. The key production schedule was for an encryption
key, an integrity key and two IVs, all from the same key stream. It
turns out that NOTHING the HSM could do could prevent the extraction
of key material because changing the boundaries between each object
did not change the key stream. In the TLS case (and IPSec for that
matter), it's a simple matter to move confidential key material into
non-confidential IVs. However, even if you limit the production to
only confidential items, you still have a problem in that using the
same key material for different algorithms (e.g. using part of an
AES key as a single DES key) can lead to vulnerabilities.<br>
<br>
TLS 1.3 fixed this problem by only doing single key productions for
each call to the KDF (and by adding the length of the production to
the mixins). Because of this, an HSM can look at the mixin data and
"do the right thing" with respect to policy. If TLS1.3 had kept the
multiple object production model, they would have included the
per-object lengths in the KDF mixin data.<br>
<br>
The HSM can do the right thing because the bits it can depend upon
(in the TLS 1.3 case the label and the length) are included in the
mixin and not simply as part of the added on key creation stuff.
Without this, there is nothing an HSM can do for enforcement because
changing these inputs wouldn't change the key stream.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
<blockquote type="cite"
cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net"> <br>
<br>
Ideally, there should be a complete object spec for each object
to be generated that is part of the mixins (label and context)
for any KDF. That allows an HSM to rely upon the object spec
when setting policy controls for each generated object - and
incidentally allows for a KDF to generate both public and
non-public data in a secure way.<br>
</blockquote>
Between different generations of keystreams do you expect to have
different sets of policy controls? The KDF API has no way for you
to set those things so I would assume those would be pretty
static, or at least controlled outside the KDF API. If so, why is
the KDF API concerning itself with how some HSM sets its policy on
objects it makes?<br>
</blockquote>
<br>
If I call a KDF with the same key but with different key
productions, I *want* the key stream to be different. If I call it
with the same key but with same key productions, I *want* it to be
the same. Say I call the KDF to produce two objects - an AES key
of length 16 bytes and a HMAC-SHA256 key of also length 16 bytes.
If I then call the same kdf with the same key to produce two AES
keys of length 16 bytes (same overall length of the key stream, but
different objects), I would *really* like it if the second object
did not have the same key bytes as the HMAC-SHA256 key of the first
call. The only way I can ensure this is to provide mixins that
cause the entire key stream to change if anything changes in the key
production data.<br>
<br>
If the mixins include policy hints (key type, key length, label,
etc) then the HSM can rely upon those and set policy accordingly for
the objects. <br>
<br>
<blockquote type="cite"
cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
<blockquote type="cite"
cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net"> <br>
So as long as you allow for the specification of all of the
production objects as part of the .init() I'm good. A given
KDF might not require this - but I can't see any way of fixing
the current KDFs to work in HSMs without something like this.<br>
<br>
<blockquote type="cite"
cite="mid:7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com">As
far as your (5) scenario goes, I can see how you can twiddle
the lengths to get the keystream output with zero-length keys
and large IV buffers. But that scenario really glosses over
what should be a big hurdle and a major access control issue
that stands outside the KDF API: That the attacker shouldn't
have access to the input keying material in the first place.
Protect the input keying material properly and their attack
cannot be done. <br>
</blockquote>
<br>
Let me give you an example. I'm running an embedded HSM - to
protect TLS keys and to do all of the crypto. An attacker
compromises the TLS server and now has access to the HSM. No
problem - I'm going to notice if the attacker starts extraditing
large amounts of data from the server (e.g. copies of the TLS in
the clear but possibly reencrypted data stream) so this isn't a
threat or is it? Smart attacker does an extraction attack on
the TLS 1.2 and before KDF and turns all of the key stream
material into IV material and exports it from the HSM. The
attacker now has the much smaller key material so he can send a
few messages with those keys and allow for the passive external
interception of the traffic and decryption thereof without the
risk of detection of all that traffic being sent. Alternately,
I can place the key material in a picture via steganography and
publish it as part of the server data.<br>
</blockquote>
"If the attacker compromises a TLS server" is the part that gets
me...we're using external software bugs/security holes as a
justification to make the KDF API in ways that I think are less
clear to the consumer, to cover one class of providers (HSMs).<br>
</blockquote>
<br>
This isn't a bug in the HSM - its a bug in thinking about how KDFs
work/should work. There are three parts to a KDF - extraction of
entropy from the master secret, expansion of that entropy into a key
stream and finally, assignment of that key stream to cryptographic
objects. HKDF and SP800-108 talk about the first two, but don't
consider the implications of the third. Because of this, neither
TLS1.2 nor IPSec provide a KDF with secure key production.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
<blockquote type="cite"
cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net"> <br>
The idea is to protect extraction of the key material from an
HSM <u><b>even from authorized users of that key material</b></u>.
<br>
</blockquote>
That may well be a goal for the HSM, to be solved by the HSM or
the provider that front-ends it. I do not see that as something
to be solved by the KDF API.<br>
</blockquote>
<br>
It has to be solved by the KDF API because the only way this works
is if the mixin data for all the productions is included prior to
producing the first object.<br>
<br>
<blockquote type="cite"
cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
<blockquote type="cite"
cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net"> <br>
KDFs don't currently do this well. Adding the overall length
and per component length stuff as well as a per component spec
to the data used to derive the key stream means that 1) changes
to any of those change the entire key stream, 2) the per
component spec data may be used by the security module policy
engine to enforce restrictions and 3) because of (1) and (2)
calling the KDF a second time gets me exactly the same objects
rather than just the same key stream. The last isn't very
important in a software based security domain, but turns out to
have real implications for policy enforcing security modules.<br>
</blockquote>
But there aren't KDFs that take individual component lengths as
inputs, so alterations to individual key component lengths don't
change the keystream (unless someone decides to write a KDF that
does, but none that I've seen do). With the way the KDF API is
taking shape, there's no enforcement that you get the same objects
- none of that is locked to the instance. It can change between
inits. If you reinitialize with the same key and KDF parameters,
whether you specify all objects up front or one at a time in
derive calls you can still ask for a different set of output
objects. And changing lengths on various objects won't matter
because HKDF, Counter-mode KDF, Feedback-mode KDF...none of those
care a whit about individual component lengths. All they care
about is the total length of the keystream (and HKDF only cares
about that to make sure it's not more than 255 * Hmac length).<br>
</blockquote>
Yes but.<br>
<br>
TLS1.3 will be NOT be an HKDF KDF instantiation, it will be a TLS1.3
KDF instantiation (which uses the HDKF function internally) that
will limit production to a single object per init and with a known
set of labels and using L as a mixin. Because that's how TLS13
dealt with the problem.<br>
<br>
AND - there are KDFs that take individual components lengths as
inputs - in at least two proprietary protocols that I know of.
Mostly though, with the trend to AEAD algorithms most of the
protocols are tending to move to a single production per init.
(since they don't need both an integrity and confidentiality key nor
an IV per se)<br>
<br>
<br>
<blockquote type="cite"
cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
<blockquote type="cite"
cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net"> <br>
This gets worse when you realize that the KDF key is under it
all either a HASH HMAC or CMAC key and all of those algorithms
produce public data. Ideally you need a way of preventing a
KDF key from calling the raw HASH/HMAC/CMAC functions directly
(and vice versa).<br>
</blockquote>
I don't see how we'd prevent this in software. If I've got a key
as input to a KDF (a SecretKey) there's no way to prevent it being
used by anything else that takes a SecretKey. If you need to
prevent that in hardware then that seems like a concern for your
provider or the HSM itself.<br>
</blockquote>
<br>
If I tag a key as MasterSecret (where MasterSecret is not a
subinterface of SecretKey, but is of Key) and use MasterSecret
instead of Key in .init().....<br>
<br>
The HSM (and the JVM) would both identify functions that can be used
with that key and keep others away.<br>
<br>
This is what I was talking about with cryptographic type safety in
my last email - the idea that the Key objects be as strongly typed
as possible to prevent them from being used inappropriately or in
ways that mathematically bypass security. Take a KDF with a PRF of
CMAC-AES-128. The KDF is meant to produce secret data (a key stream
for the production of keys), but a CMAC-AES-128 is meant to produce
public data (an integrity tag over a set of data). Given that KDF
algorithm is simply a wrapper to the PRF to allow for the production
of multiple blocks of data, then its trivial - if you have access to
*use* the KDF key - to use it with the CMAC function to extract the
key stream.<br>
<br>
In the HSM I can *somewhat* combat this by (in PKCS11) attributing
the key, but how do get those attributes on the key in the first
place if I'm using a Java front end?<br>
<br>
In software this isn't a big thing as the confidential key material
and the public CMAC integrity tag are both in the same software
domain. But over the years we've tried to do the right thing (see
javax.security.auth.Destroyable for example) by thinking about
security past the limitations of what we can get in software.<br>
<br>
For KDFs I'd add a jaxa.crypto.MasterSecret interface extending
Key,Destroyable (and pretty much a clone of SecretKey) a
javax.crypto.spec.MasterSecretSpec implementing KeySpec and
MasterSecret (and a clone of SecretKeySpec) to tag these secret keys
as for use only with a KDF.<br>
<br>
Mike<br>
<br>
<br>
<br>
<br>
<br>
<p><br>
</p>
</body>
</html>