Any comments on using something like the NIST key-derivation proposal?
Maybe HMAC with SHA-256?:
DeviceKey = HMAC-SHA-256(UserKey, OUI || Vendor-Specific Info)
Looks good to me. This option may be the easiest to get NIST certification
for.
The Option 1 for AES key transform potentially limits the amount of vendor
unique information to about 13 bytes (16 bytes - 3 byte OUI). It'd
be nice to have a bit more room than that.
If you want to have arbitrarily long vendor-specific information, you can
do something like
K2[0:127] = AES-CBC-MAC_k1(1 || OUI || Vendor-Specific Info)
K2[128:255] = AES-Enc_k1(2 || OUI || pad to 16 bytes)
Like anything CBC, you want the Vendor-Specific Info to be significantly
shorter than 2^64, but other than that it can be of any length. Also, if
you don't specify a fixed length for the Vendor-Specific Info then you
need to do some special processing on the last block (just like any other
CBC-MAC). Using the same k1 for K2[0:127] and K2[128:255] is not a problem
here.
But really, if you want a long Vendor-Specific Info then you are most
likely better off with the SHA256 solution.
And as fas as I understand, none of that will be in the normative part
of 1619.1 (since there surely will be applications that don't have this
problem, and 1619.1 has no inter-operability aspirations).
-- Shai
