Draft design for Key Derivation API

Adam Petcher adam.petcher at oracle.com
Fri Nov 17 15:48:16 UTC 2017


On 11/17/2017 10:10 AM, Michael StJohns wrote:

> On 11/16/2017 1:29 PM, Adam Petcher wrote:
>> On 11/8/2017 6:50 PM, Michael StJohns wrote:
>>
>> 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?
>
> 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.
>
> 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.

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:

class KeyDerivation{
   Object deriveObject() {
     try {
       return spi.deriveObject();
     } catch (...) {
       Class clazz = // get the class from the parameters
       return clazz.newInstance(deriveData(), length); // shorthand for 
getting the right ctor and calling it
     }
   }
}

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.




More information about the security-dev mailing list