Draft design for Key Derivation API

Michael StJohns mstjohns at comcast.net
Fri Nov 17 15:10:10 UTC 2017


On 11/16/2017 1:29 PM, Adam Petcher wrote:
> On 11/8/2017 6:50 PM, Michael StJohns wrote:
>
>>>> On 11/3/2017 4:59 PM, Jamil Nimeh wrote:
>>>>> Add a .deriveData() with a return class of byte[].   This gets a 
>>>>> portion of the derived data stream in the clear. E.g. an IV.
>>>>>
>>>>> Add a .deriveObject() with a return class of Object.  The returned 
>>>>> object may not be an instance of java.security.Key.  This takes 
>>>>> the derived data stream and converts it into the object type 
>>>>> specified by the derivation parameter.  In a hardware security 
>>>>> module, this might be a reference to a secured set of data or even 
>>>>> an confidential IV.
>>>> Again, just want to make sure I understand fully: So in a case 
>>>> where I want a given output to be an Object, I would provide a 
>>>> DerivationParameterSpec with an alg of..."Object" (?), a byte 
>>>> length, and Object-specific parameters provided through the 
>>>> "params" argument to the DPS?
>>
>> Working this through, but it should be a Class  being specified with 
>> a constructor of a byte array plus a length.
>
> 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.

Mike





More information about the security-dev mailing list