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