Hi Everyone,
Here is a proposal for a method to transform a 256-bit key using the
3-byte IEEE OUI (universal vendor ID) for the 1619.1 spec. This is
based on "Option 2" from the "Re: p1619.1 document (tape), draft
version 0.4" thread, and was originally proposed by Jim Hughes.
Please let me know if you have any questions or comments! If this
looks like a good approach, I'd like to propose we add this to the
1619.1 standard.
IEEE 1619.1 AES Key Transform
-----------------------------
Each 1619.1-compliant device shall transform the 256-bit User Key
(provided by the host) into a 256-bit Device Key, which shall be
used by the device for the GCM or CCM algorithm. Here is the
key transform algorithm:
DeviceKey[255:128] = AES-Enc_TransformKey1(UserKey[255:128])
DeviceKey[127:0] = AES-Enc_TransformKey2(UserKey[127:0])
TransformKey1[255:248] = 0x01
TransformKey1[247:224] = Unique IEEE OUI code (see below)
TransformKey1[223:0] = Vendor Unique Information
TransformKey2[255:248] = 0x02
TransformKey2[247:224] = Unique IEEE OUI code (see below)
TransformKey2[223:0] = Vendor Unique Information
All numbers within brackets indicate bit positions, with bit 255
on the left and bit 0 on the right. All numbers shall follow the
Big-Endian convention, in which the most-significant bit (bit 255)
corresponds to the lowest address.
In general, this algorithm uses the AES (Advanced Encryption
Standard) block cipher, along with two "Transform Keys", to
generate a "Device Key" from the host's "User Key". This requires
two AES operations because the block size of AES is 128 bits, but
the Device Key is 256-bits long.
Each vendor or format technology shall use a unique 3-byte IEEE
OUI code. See <http://standards.ieee.org/regauth/oui/index.shtml>
for information on creating a new OUI code.
In addition to a unique OUI code, each vendor may provide up to 24
bytes of "Vendor Unique Information" that can be further used to
differentiate product lines or individual pieces of media. Any
unused bytes shall be set to zero. If a media ID is included within
the "Vendor Unique Information", it is recommended that the device
also write this information to the media in plaintext.
If a particular format or technology is part of a greater consortium,
then the consortium should either pick a particular vendor as a
sponsor of the technology, or create a new IEEE OUI code that
describes the technology or format.
Discussion of the IEEE 1619.1 AES Key Transform
-----------------------------------------------
Goals for the transform:
1) Provide a random permutation of the User Key to mitigate the risk
of the same key being used in two different 1619.1 compliant devices
manufactured by two different vendors. Otherwise, it is not possible
to ensure that the two vendors use a different Initialization Vector
(IV) (a.k.a. nonce).
2) Reduce the probability of creating weak keys
3) Maintain full entropy of the original 256-bit User Key.
The proposed transform meets these goals for the following reason:
1) By using a unique vendor ID (3-byte IEEE OUI), the result Device Key
only has about a 1 in 2^256 chance of matching that of a Device Key
created using a different vendor ID. This is sufficient for the chosen
security level.
2) Because the output of the AES block cipher is indistinguishable from
a random number, the probability of accidentally creating a weak key is
no greater N in 2^256, where N is the number of weak keys in the AES
cipher (currently, there are no known weak keys in AES).
3) Since the AES cipher is a random permutation, there is exactly one
output for each input. For this reason, there is no entropy loss.
There are two different transform keys so that if UserKey[255:128] ==
UserKey[127:0], then the DriveKey[255:128] will not generally equal
DriveKey[127:0].
-Matt
