<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Sorry - I've been on travel for the
last few days... comments below.<br>
<br>
On 11/17/2017 10:48 AM, Adam Petcher wrote:<br>
</div>
<blockquote type="cite"
cite="mid:268fd139-6405-db93-49a4-59e19c91b44d@oracle.com">On
11/17/2017 10:10 AM, Michael StJohns wrote:
<br>
<br>
<blockquote type="cite">On 11/16/2017 1:29 PM, Adam Petcher wrote:
<br>
<blockquote type="cite">On 11/8/2017 6:50 PM, Michael StJohns
wrote:
<br>
<br>
What is the motivation behind this constructor that takes a
byte array? It seems like this constructor wouldn't actually
help in a hardware implementation. Would it be better to leave
the construction of this object to the implementation?
<br>
</blockquote>
<br>
This is a reasonable point, but misses a few things. If you're
calling the hardware implementation from software, you need to
be able to pass data from the software domain to hardware
domain. If the KDF and the Object are both in hardware, then
the provider implementation doesn't actually externalize the
byte array from the KDF - it just returns the final pointer to
the object.
<br>
<br>
The hardware/software boundary has some unique challenges -
mostly these are handled OK in the JCA. For this particular
model, you need to be able to move bits from software to
hardware which is the point of the constructor as specified.
For hardware to hardware it happens under the hood. For
hardware to software it may be prohibited (e.g. you can't
actually externalize the bits of the key stream), but if its
permitted then you need a simple way of translating key stream
bytes into an object.
<br>
</blockquote>
<br>
That behavior all sounds reasonable, I just have doubts that this
belongs in the spec. Are you expecting KeyDerivation to contain
the logic in your last paragraph? Something like this:
<br>
<br>
class KeyDerivation{
<br>
Object deriveObject() {
<br>
try {
<br>
return spi.deriveObject();
<br>
} catch (...) {
<br>
Class clazz = // get the class from the parameters
<br>
return clazz.newInstance(deriveData(), length); // shorthand
for getting the right ctor and calling it
<br>
}
<br>
}
<br>
}
<br>
<br>
I would expect something like that to happen in the
KeyDerivationSpi implementation instead, in which case it could
construct the object any way it wants. So the spec would not need
to place any requirements on the class of objects returned by
deriveObject.
<br>
<br>
</blockquote>
<p><br>
</p>
<p>KDFs are somewhat problematic in that <b><u>they may not
necessarily be producing objects from their own provider</u></b>.
This unfortunately isn't obvious, but let me try and explain.</p>
<p>A KDF is basically a keyed pseudo-random number generator. From
the input key (and mixin context and label stuff) it produces a
stream of bits. Once that's done, the stream of bits is assigned
to various output objects - secret keys, private keys, a byte
array[] or a cryptographic object of some sort (cf TLS exporters
for an example of this). The current draft has an implicit
assumption that the Key based objects will be formed from the
current provider. The byte array output is a providerless
java.lang object. The last type provides a model to allow for the
production of objects not within the current provider. You
*could* just punt on this and assume that you take the output of
the deriveData() call and feed it to a factory of the other
provider, but that means that the derivation production will
necessarily be in the clear because the stream data will pass
through the JVM.</p>
<p>Here's where it gets even trickier:</p>
<p>A given provider has a given security domain. E.g. most software
providers share the JVM memory domain. HSM providers have a
security domain representing pointers to objects within the HSM
secure perimeter. Mostly now, HSM providers do not share the same
domains - but there are some cases where this might be possible
and desirable (different providers leveraged on top the same HSM
implementation, two SMs with a trusted path between them - TPMs
and TEEPs for example). I'd *really* like it if there is some way
to keep data from two different providers sharing the same or
compatible security domains from having to pass their key stream
data through the unsecure JVM memory domain.</p>
<p>Maybe there's a different way to do this - perhaps by changing
the DeriviationParameterSpec to include the output provider? But
then you still need a way of generating non-key secure
cryptographic objects I think....</p>
<p>Mike</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>