Common Encryption, UltraViolet, and PlayReady Key IDs

Artikel
09/19/2014

Key IDs and PlayReady

A key identifier (KID) is the public identifier for a secret content encryption key.

The PlayReady Server managed APIs use GUIDs to pass in KIDs when creating licenses. The server directly copies the memory layout of the GUID (DWORD, WORD, WORD, 8-BYTE array) into a byte array when constructing the PlayReady KID. This operation is machine architecture dependent because the endianness of the processor determines how a value, such as the first DWORD, will sit in memory and therefore how it will sit in a byte array.

The PlayReady license server only runs on little-endian architectures. PlayReady clients may run on various architectures, but only use byte arrays or base64 encodings of byte arrays to store and transmit KIDs. Consequently, the KID in a PlayReady ecosystem is a little-endian representation of the originally input GUID on the license server.

For example, given an initial string representation of “01020304-0506-0708-090A-AABBCCDDEEFF” when constructing a GUID on the server, the binary representation used inside PlayReady will be the byte array { 0x04, 0x03, 0x02, 0x01, 0x06, 0x05, 0x08, 0x07, 0x09, 0x0A, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF }.

Common Encryption and UltraViolet

Common Encryption (CENC) provides a standardized method to encrypt media files to enable interoperability with multiple DRM systems.

CENC declares KIDs as following the UUID specification. This means that given an initial string representation (for example, “01020304-0506-0708-090A-AABBCCDDEEFF”), the binary representation is simply a byte array of the hexadecimal values in the same order (0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF). This also corresponds to using the GUID structure (DWORD, WORD, WORD, 8-BYTE array), but stored in strictly big-endian form.

This means that all CENC KID fields, such as in track encryption boxes (‘tenc’), sample group description boxes (‘sgpd’), and MPEG-DASH manifest files, store the big-endian binary representation of the KID.

The same is true for the use of KIDs within the UltraViolet ecosystem, such as in the Key Set Delivery File.

Problem

As a result of this discrepancy between PlayReady and CENC/UltraViolet KIDs, data must be converted when crossing the boundary between the systems.

Solution

Client media pipelines should convert KIDs found in CENC fields from big-endian into little-endian order before passing to PlayReady APIs as a byte array or base64 string.

Clients should leave PlayReady-specific KID fields, such as in WRMHeader data, in their existing little-endian form.

License servers should continue passing unmodified GUID strings and structures to the PlayReady Server API, so that the PlayReady server continues using the little-endian form internally. This ensures that KIDs in licenses sent to clients match the little-endian KIDs stored locally by those clients.

License servers should be careful to associate the correct key data with each KID, so that the content key sent to clients is the same as was used for content encryption.

Platform Support

The Silverlight Smooth Streaming Media Element (SSME), PlayReady iOS, and PlayReady Android media players all perform this conversion automatically.

The PlayReady Device Porting Kit (Device PK) does not perform this endian conversion. Media platforms built on top of the Device PK should ensure KIDs passed to PlayReady are in little-endian order.

Converting KID Endianness

For client media pipelines that need to convert from big-endian CENC KIDs to little-endian PlayReady KIDs, the following algorithm is necessary. This will reverse the endianness of the DWORD-WORD-WORD fields.

void ConvertUidEndianness(byte[] uid)
{
  Swap(ref uid, 0, 3);
  Swap(ref uid, 1, 2);
  Swap(ref uid, 4, 5);
  Swap(ref uid, 6, 7);
}

void Swap(ref byte[] bytes, int pos1, int pos2)
{
  byte temp = bytes[pos1];
  bytes[pos1] = bytes[pos2];
  bytes[pos2] = temp;
}

Freigeben über