Using DRM with Multiple Keys

Introduction

DRM with multiple keys allows you to encrypt different tracks in a stream with different keys, instead of using one key to encrypt all audio and video tracks. For example:

  • Encrypt audio with a different key than video

  • Encrypt some audio or video tracks, but not all of them

  • Encrypt premium features with a different key than standard features

  • Encrypt all tracks with separate keys for complete flexibility

One reason to encrypt your content with multiple keys is to support a setup where different tracks are associated with DRM licenses that have different requirements. Such a setup is possible using only one encryption key, but becomes more secure when using multiple keys, so that each key is only associated with a particular license. The latter approach is recommended by all major DRM systems.

Requirement: Content Protection Information eXchange (CPIX)

To use DRM with multiple keys with Origin it is required to define your content protection configuration using a separate XML-file called a CPIX document; see CPIX encryption options and Introduction to CPIX. CPIX is not required to use Encryption & DRM with Multiple Keys.

Workflow with multiple keys for Unified Origin

  • Define business logic for content protection

  • Acquire keys, Protection System Specific Header (PSSH) data and playout format specific signaling

  • Provide a CPIX document

    • Ideally: supplied by the DRM system as part of the previous step (key acquisition)

    • Otherwise: create the CPIX document yourself

  • Use the CPIX document as input to generate a stream protected with multiple keys, by using one of the CPIX encryption options to specify the location of the CPIX document when creating the server manifest.

Note

Using DRM with multiple keys is not possible when you have configured Origin to output a multiplexed stream (i.e., --hls.no_multiplex must be used when configuring Origin to use multiple keys to encrypt your stream if you want to stream HLS).

Defining business logic for content protection

The business logic of your content protection is dependent on the business model of your streaming service, on requirements put forward by the copyright holders of the content that you are streaming, and on the options supported by the individual components of your video streaming setup, such as Unified Origin, the DRM provider that you use, and the playout devices that you want to offer your streaming service on.

In short, the question comes down to which tracks of your content you want to protect using different DRM licenses, as these licenses define the different contexts in which playout of the specified content is allowed.

For example, if you want to require a premium subscription for playout of your content's highest quality tracks, you will need to define this requirement in the DRM license that is associated with the tracks that represent the highest quality (e.g., 4K resolution and HDR color). The same goes for a requirement that will only allow playout of the highest quality if 'hardware DRM' is supported on the playout device.

When you have defined which tracks of your content need to be protected by a different license, a straightforward rule is to use separate encryption keys for tracks protected by different licenses.

Acquiring keys and protection information

How you acquire your content encryption keys and the PSSH data as well as other protection information, like the DRM related signaling for a playout format, is dependent on the DRM system and DRM provider that you use.

Providing a CPIX document

As noted earlier, a CPIX document would ideally be returned by your DRM provider in response to your request for content protection keys.

If this is not the case, you will have to create a CPIX document yourself; see CPIX document structure.

Defining filters

If a CPIX document only contains the minimum info necessary (i.e., it only has one <ContentKey> element, as in the Minimal CPIX example), Unified Origin will add encryption and protection to all the content's tracks.

To specify that only certain tracks must be encrypted and protected (e.g., the audio and video tracks, but not the text tracks), the applicability of a content key must be limited by filter elements contained in a <ContentKeyUsageRule> element. A list of usage rules is also required if you are working with more than one <ContentKey> element, because of the need to specify that certain tracks must be encrypted with one encryption key, while other tracks must be encrypted by another (a (part of a) track must never be associated with more than one encryption key). For details, see the CPIX 2.2 specification.

The <VideoFilter> element type

A video filter can be used to associate video tracks with a specific <ContentKey>. A video filter without any XML attributes applies to all video tracks. Attributes are defined for filtering video tracks based on the number of pixels (minPixels, maxPixels) or the number of frames per second (minFps, maxFps).

Note

Filtering on whether or not the content is High Dynamic Range (HDR) or Wide Color Gamut (WCG) is currently not supported.

The <AudioFilter> element type

Similar to a video filter, an audio filter can be used to associate audio tracks with a specific <ContentKey>, and an audio filter without any XML attributes applies to all audio tracks. Attributes are defined for filtering audio tracks based on the number of audio channels (minChannels, maxChannels).

The <BitrateFilter> element type

A bitrate filter can be used to filter tracks according to bitrate. In contrast to the video and audio filters, this filter must always be parameterized: you can filter tracks according to their nominal bitrate in Mb/s based on a minimum bitrate (the minBitrate attribute), a maximum bitrate (the maxBitrate attribute), or both.

Creating a stream protected with multiple keys

For Origin, creating a stream protected with multiple keys is very straightforward once you have a CPIX document in which all of the DRM protection information is specified. You simply add the document to the command-line that you use to create a server manifest, like so:

mp4split -o tears-of-steel-multikey-cenc.ism \
  --cpix=multiple-keys-cenc.cpix \
  tears-of-steel-aac-64k.mp4 \
  tears-of-steel-avc1-400k.mp4 \
  tears-of-steel-avc1-750k.mp4 \
  tears-of-steel-avc1-1500k.mp4

Example CPIX document for DRM with multiple keys

Below, you find an example of a CPIX document that includes 5 Key ID's (KIDs) that are associated with 5 Content Encryption Keys (CEKs). It also includes a PSSH for one DRM system and filters that define which keys are associated with which of the content's audio and video tracks.

For more information on the contents and the structure of a CPIX document, have a look at CPIX document structure.

Basically, there are:

  • A <ContentKeyList> that lists KID and CEK pairs, with each of those pairs being contained in a ContentKey element and each KID serving as the representation of the ContentKey in which it is stored

  • A <DRMSystemList> that lists KID and DRM system pairs, with each of those pairs being contained in a <DRMSystem> element that must contain a PSSH and can contain additional format specific signaling

  • A <ContentKeyUsageRuleList> that lists the different KIDs, with each KID being associated with certain audio, video and bitrate filters in a <ContentKeyUsageRule> element

Thus, a CPIX document can be used to associate a <ContentKey> with a <DRMSystem> (or more), and to associate a <ContentKey> and <DRMSystem> pair with tracks that are filtered out by a <ContentKeyUsageRule>.

 1<?xml version='1.0' encoding='UTF-8'?>
 2<CPIX xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:dashif:org:cpix" xsi:schemaLocation="urn:dashif:org:cpix cpix.xsd">
 3  <ContentKeyList>
 4    <ContentKey kid="e82f184c-3aaa-57b4-ace8-606b5e3febad">
 5      <Data>
 6        <pskc:Secret>
 7          <pskc:PlainValue>...</pskc:PlainValue>
 8        </pskc:Secret>
 9      </Data>
10    </ContentKey>
11    <ContentKey kid="087bcfc6-f7a5-5716-b840-6aa6eba3369e">
12      <Data>
13        <pskc:Secret>
14          <pskc:PlainValue>...</pskc:PlainValue>
15        </pskc:Secret>
16      </Data>
17    </ContentKey>
18    <ContentKey kid="0d6b4023-8da1-5e75-af68-75c514c59b63">
19      <Data>
20        <pskc:Secret>
21          <pskc:PlainValue>...</pskc:PlainValue>
22        </pskc:Secret>
23      </Data>
24    </ContentKey>
25  </ContentKeyList>
26  <DRMSystemList>
27    <!-- Widevine -->
28    <DRMSystem kid="e82f184c-3aaa-57b4-ace8-606b5e3febad" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
29      <PSSH>...</PSSH>
30      <ContentProtectionData />
31    </DRMSystem>
32    <!-- PlayReady -->
33    <DRMSystem kid="e82f184c-3aaa-57b4-ace8-606b5e3febad" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
34      <PSSH>...</PSSH>
35      <ContentProtectionData />
36    </DRMSystem>
37    <!-- Widevine -->
38    <DRMSystem kid="087bcfc6-f7a5-5716-b840-6aa6eba3369e" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
39      <PSSH>...</PSSH>
40      <ContentProtectionData />
41    </DRMSystem>
42    <!-- PlayReady -->
43    <DRMSystem kid="087bcfc6-f7a5-5716-b840-6aa6eba3369e" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
44      <PSSH>...</PSSH>
45      <ContentProtectionData />
46    </DRMSystem>
47    <!-- Widevine -->
48    <DRMSystem kid="0d6b4023-8da1-5e75-af68-75c514c59b63" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
49      <PSSH>...</PSSH>
50      <ContentProtectionData />
51    </DRMSystem>
52    <!-- PlayReady -->
53    <DRMSystem kid="0d6b4023-8da1-5e75-af68-75c514c59b63" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
54      <PSSH>...</PSSH>
55      <ContentProtectionData />
56    </DRMSystem>
57  </DRMSystemList>
58  <ContentKeyUsageRuleList>
59    <ContentKeyUsageRule kid="e82f184c-3aaa-57b4-ace8-606b5e3febad">
60      <VideoFilter maxPixels="589824"/>
61    </ContentKeyUsageRule>
62    <ContentKeyUsageRule kid="087bcfc6-f7a5-5716-b840-6aa6eba3369e">
63      <VideoFilter minPixels="589825" maxPixels="2073600"/>
64    </ContentKeyUsageRule>
65    <ContentKeyUsageRule kid="0d6b4023-8da1-5e75-af68-75c514c59b63">
66      <AudioFilter/>
67    </ContentKeyUsageRule>
68  </ContentKeyUsageRuleList>
69</CPIX>

The example CPIX document shown above uses the video filter to associate different content keys with video tracks according to their resolution. Furthermore, it uses an audio filter to simply associate all audio tracks with a specific content key.