Using DRM with Key Rotation

Introduction 

New in version 1.15.19.

DRM with key rotation allows you to rotate the key(s) that content is encrypted with over time.

There are two primary drivers for implementing key rotation:

Enhanced Content Security

Rotating at set intervals: changing keys frequently (e.g., every few minutes) makes unauthorized access much more difficult. For this reason, it can also be a contract obligation enforced by content right owners to the content providers.

Limiting Breach Impact: if an encryption key is compromised, it only grants access to a small segment of the stream; subsequent periods remain protected by new keys.

Granular Content Protection

Program-Based Requirements: you can associate different programs within a single stream with different DRM licenses.

Tiered Access: for example, you might allow decryption of a sports event only for "Premium" members, while the rest of the stream requires only a standard subscription.

Lead-in Flexibility: key rotation allows you to leave a "lead-in" segment in the clear (unencrypted) to attract viewers before requiring a license for the main content.

Choice of a Key Rotation business logic 

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.

Whatever the use case, it is important to understand that an encryption key change can be a technically challenging and potentially expensive operation for a content provider. Every time a key change is required, each active viewer will request a new license, and the DRM provider will need to generate and provide it. If this happens when a very high number of viewers are watching the stream, this can lead to significant challenges in terms of scalability (the DRM provider servers may just not be ready for such a surge of contemporary requests) and cost (DRM providers generally charge based on the number of licenses that they provide). People often refer to this kind of scenarios as "The thundering herd problem". On the other hand, if keys are rotated less frequently, e.g. once per day at off-peak hours, the impact is likely very limited.

It is therefore important to carefully consider the frequency of key changes in your stream, and points in time when that happen in a way suitable for your use case, keeping in mind the goal of striking a good balance between the level of security that you want to achieve and the cost and scalability implications of key changes.

The DRM ecosystem 

Although the concept of Key Rotation sounds simple enough at a first glance, its implementation involves a few moving parts that must be kept in mind. In order to understand these aspects and how Unified Origin can help you to implement key rotation in your workflow, let's review all the basic components involved and how they interact with each other.

a CPIX document that defines the content protection information, such as the keys that are used for encryption and the time spans for which these keys are valid
an origin that can use the content protection information provided via CPIX to create a stream encrypted with keys that can change over time
a player that can identify the DRM system used to protect the stream and can acquire the necessary license to decrypt it, not just once but all the times the key change makes it necessary
a DRM provider that can provide at anytime Unified Origin with the necessary content protection information via CPIX, as well as the players with the necessary licenses to decrypt the stream

Content Protection Information eXchange (CPIX)

To use DRM with key rotation it is required to define your content protection configuration using a separate XML-file called a CPIX document; see CPIX encryption options, Introduction to CPIX and CPIX Document Requirements.

CPIX documents for key rotation use cases contain one or more <ContentKeyPeriod> element [1] that defines the time period for which a specific content key is valid, e.g.

<ContentKeyPeriodList>
  <ContentKeyPeriod id="177383280" start="2026-03-18T00:00:00Z" end="2026-03-19T00:00:00Z"/>
  <ContentKeyPeriod id="177383281" start="2026-03-19T00:00:00Z" end="2026-03-20T00:00:00Z"/>
</ContentKeyPeriodList>

At anytime, Unified Origin needs to have access to the CPIX document specified at VOD or Live server manifest creation time. This document contains the content protection information for the time span of the stream that is being requested by the player. Such document can either be a local file or a remote document that is provided by the DRM provider via HTTP (i.e. by a CPIX origin). See CPIX encryption options on how to specify a CPIX source when creating a server manifest.

If Unified Origin cannot find a valid key for the required time period in the CPIX document, by default to avoid unintentional playout in the clear it will generate an FMP4_500 No matching content key found HTTP response and corresponding error log. You can force Unified Origin to keep serving an unencrypted stream in this case, by setting the allow_unencrypted option when creating the server manifest; see CPIX encryption options for more details.

For the reasons above, we recommend that the CPIX document always covers a time span equal or longer than your Live archive length [6]. This is to make sure that the stream is always protected by a valid key, including the case of viewers scrolling back in time within the DVR window or using catch-up/restart URLs.

Implementation: VOD versus Live 

Key rotation with VOD

When applying key rotation to VOD streams, a static CPIX document suffices to specify the content protection information. In fact, the VOD duration is known beforehand, so a CPIX document that covers the entire presentation can be easily created.

In this case, the ContentKeyPeriodList timing information is expressed in absolute time, where the beginning of the presentation is at 1970-01-01T00:00:00Z.

The following example represents a key rotation setup for a VOD presentation where the CPIX document is static and stored on disk.

#!/bin/bash

mp4split -o tears-of-steel.ism \
  --cpix=keyrotation.cpix \
  tears-of-steel-aac-128k.mp4 \
  tears-of-steel-avc1-750k.mp4 \
  tears-of-steel-avc1-1500k.mp4

You can download vod-keyrotation-example.cpix for an example CPIX document for a 13 minute VOD presentation with AES-128 DRM rotating keys every minute.

Note

For VOD cases, it makes sense that the CPIX document is static and stored on disk. However, this is not a requirement and a CPIX origin can be used as well.

Key rotation with Live

When adding key rotation to a Live workflow, it is impossible for the CPIX document to cover the entire presentation, as its duration is not known beforehand. Notice also that, at any time, the <ContentKeyPeriodList> must cover the entire Live archive [6] of the stream, as this is the available window the player can request. In such cases, the CPIX document must be updated over time to reflect the keys that may be required for encryption.

In practice, this can be accomplished in two ways:

using a local CPIX file and updating it at regular intervals. This means creating a new document by means of a manual or automated process that periodically acquires keys, Protection System Specific Header (PSSH) data and playout format specific signaling from the DRM provider.
having the DRM provider provide an API that allows Unified Origin to request a CPIX document for a specific time span (i.e. provide a CPIX origin).

Both approaches are valid, but depending on your use case, one may be more suitable than the other. In general, having a CPIX origin is more flexible and scalable but requires a higher initial integration effort, as it may require some level of integration or adaptation with regards to the API made available by the chosen DRM provider.

For simpler use cases where key rotation (and thus CPIX updates) is required more sporadically (e.g. once a day), the first approach may be more immediate.

Using a CPIX file with Live

A CPIX static file can be used with Live, but it needs to be updated at regular intervals to make sure it always cover your entire Live archive. The update must be done before the live edge falls out of the time span covered by the CPIX file.

Typically, a CPIX file update will include adding information for at least the next Encryption period, and removing all elements related to key periods that have fallen out of the Live archive. Removing old key periods is not strictly required, but it is recommended to keep the CPIX document as clean and lean as possible and avoid performance degradation when Unified Origin needs to parse it.

An example of how a CPIX file may look like, for a live stream with 24h key rotation happening at midnight, is available for download as an example at key-rotation-file-live.cpix.

The example illustrates how the CPIX file may look like at any time during January 2nd, 2026. The file contains three key periods, one for the current day (January 2nd), one for the previous day (January 1st) to cover the Live archive (assuming it is shorter than 24h) and one for the future.

<ContentKeyPeriodList>
  <ContentKeyPeriod id="period_0" start="2026-01-01T00:00:00Z" end="2026-01-02T00:00:00Z"/>
  <ContentKeyPeriod id="period_1" start="2026-01-02T00:00:00Z" end="2026-01-03T00:00:00Z"/>
  <ContentKeyPeriod id="period_2" start="2026-01-03T00:00:00Z" end="2026-01-09T00:00:00Z"/>
</ContentKeyPeriodList>

If you are targeting 24h key rotation, at some point on January 3rd, this file will need to be updated. What typically would happen is that the new file will look like the following, where:

the oldest key period has been removed
the current key period has been updated with the actual key expiration time
new encryption information and key(s), plus a new key period starting on midnight, January 4th has been added

<ContentKeyPeriodList>
  <ContentKeyPeriod id="period_1" start="2026-01-02T00:00:00Z" end="2026-01-03T00:00:00Z"/>
  <ContentKeyPeriod id="period_2" start="2026-01-03T00:00:00Z" end="2026-01-04T00:00:00Z"/>
  <ContentKeyPeriod id="period_3" start="2026-01-04T00:00:00Z" end="2026-01-10T00:00:00Z"/>
</ContentKeyPeriodList>

Having a last key period much longer than the typical key rotation interval is not strictly required but it is a common practice to avoid service disruption, in case for some reason the CPIX file update process fails for a few days. Should that happen, the stream will still be protected by a valid key, even if the key rotation will not happen as expected.

Using a CPIX origin with Live

When using a CPIX origin, it is important to understand how the interaction between the Unified Origin and the CPIX origin works, and how the time span of the CPIX document request is defined.

CPIX Origin API

The Unified Origin will perform HTTP requests to the CPIX Origin, expecting a specific API to be implemented.

The following workflow example illustrates the interaction between the Unified Origin and the CPIX origin when a player is playing back HLS or DASH with key rotation. The player will start with a Main Playlist or DASH manifest request, followed in the case of HLS by a Media Playlist request, and then by media segment requests.

Requests for Master Playlist / MPD / Init Segment

For these kind of requests the Unified Origin will not need to generate any DRM signalling that is specific to a particular time span. For this reason, the request may look like:

http://cpix-origin/keyrotation.cpix

Player	Unified Origin	CPIX Origin
GET <main playlist/MPD/init segment>
	GET 'keyrotation.cpix'
		Create 'keyrotation.cpix'
Create <main playlist/MPD/init segment>

Unified Origin does not append start & end time span for the Master Playlist, for the DASH manifest or for init segment requests.

In this case, the CPIX origin may return a CPIX document with minimal information, just the bare minimum necessary to add DRM signalling to the Master Playlist, DASH manifest and init segment, such as the KID of the first key that will be used for encryption.

The rest of the content protection information can be left empty, as it will not be used for encryption until the player starts requesting media segments or HLS Media Playlists.

An example CPIX document that can be returned by the CPIX origin in this case is available for download at key-rotation-live-http.cpix.

Request for Media Playlist or media segment

When a player requests a Media Playlist or a media segment the sequence looks as follows, Unified Origin creates a time span for the CPIX document request. The time span that Unified Origin adds to the request is denoted by the URL query arguments start and end, which are in ISO 8601 time format.

The request from the Unified Origin to the CPIX origin may look like:

http://cpix-origin/keyrotation.cpix?start=1970-01-01T00:00:00Z&end=1970-01-01T00:01:00Z

Player	Unified Origin	CPIX Origin
GET <media playlist/media segment>
	GET 'keyrotation.cpix?start&end'
		Create 'keyrotation.cpix'
Create <main playlist/MPD/init segment>

In this case, the CPIX origin needs to return a CPIX document that contains the content protection information for the time span defined by the start and end query parameters. This means that the CPIX document needs to contain key periods that cover the entire time span defined by the request, and the corresponding content keys and PSSH data for those key periods.

An example CPIX document that can be returned by the CPIX origin in this case is available for download at key-rotation-live-http-start-end.cpix. The example illustrates a 10-seconds key rotation setup, where the Unified Origin request uses a time span of 1 minute from start="2026-01-01T00:00:00Z" to end="2026-01-01T00:01:00Z". Notice that this is a Multiple-keys CPIX document, where different keys are used for different content (see [2]), for both Widevine and FairPlay DRM systems.

Aligning keys to segments 

The following example shows how keys and segments may overlap with time spans:

                                              time
|------------------------------------------------------------------------------------------->

       segment 1             segment 2             segment 3             segment 4
|---------------------|---------------------|---------------------|---------------------|--->

                  key 1                                     key 2
|----------------------------------------|----------------------------------------|--------->

In the above example, 2 keys are associated with the time span of segment 2. In such a case (where multiple keys match the timespan of a segment), the first key is used to encrypt the entire segment.

Note

Aligning keys to the start of a segment is not strictly required, it is however important that there are no gaps of keys.

Key rotation with Live 24/7 example 

The following example represents a setup for a 24/7 Live presentation with a DVR window of 60 seconds. This means in this presentation, when the player requests content, the time span requests to the CPIX Origin will cover a period not larger than 1 minute (see [3]).

#!/bin/bash

mp4split -o live.isml \
  --cpix=http://cpix-origin/contentid/keyrotation.cpix \
  --dvr_window_length=60

The cpix [4] URL points to the CPIX origin.

CPIX Proxy and caching 

When working with DRM providers, it's very likely that the API that allows to retrieve the CPIX document does not match the expected API of a CPIX origin, and that some adaptation is required. In such cases, a CPIX proxy can be used to adapt the third-party API. In such cases, it is recommended that the CPIX proxy also implements CPIX caching, to avoid unnecessary requests to the DRM provider and to improve the overall performance of the system.

Key Rotation and streaming formats 

While HLS-TS Key Rotation has been possible with Unified Origin for a long time, there has never been a true standardized method for how key rotation signaling should be implemented in DASH and mp4 media segments.

More recently, discussions within the industry have led the DASH-IF CPS group to identify in-band key rotation, as defined in the DASH-IF IOP Guidelines (Part 6, v5.0.0, Chapter 9.3) [5], as the best strategy to implement key rotation in DASH.

With in-band key rotation, instead of relying on the default_KID value in the initialization segment or in the DASH manifest (which would require a new DASH period for each key change), every DASH media segment carries a KID value in the moof/traf/sgpd box and one PSSH box per DRM system. The advantage of this model is that MPD manifests stay lean, less verbose and single period. Players can handle these manifests more easily and still realize that a new license must be acquired when a KID with no associated content key is encountered.

Note

Unified Origin will still signal a default_KID value in the DASH manifest and in the init segment, using the first KID found in the CPIX document. This seems the best approach at the moment, considering that discussions on how to handle the default_KID value are still ongoing in the SVTA security group. When Key Rotation is enabled, this value should just be ignored by the player. In the worse case this will generate one unnecessary license acquisition at the beginning of the stream.

Solving the thundering herd problem 

In-band key rotation allows for a more seamless key change, but does not address the thundering herd problem that can arise when a key change happens and a large number of viewers are watching the stream at the same time, as all of them will request a new license at the same time. To mitigate this problem, Unified Origin also includes a key pre-announcement mechanism, which allows the player to pre-fetch the necessary licenses for the next key before the key change actually happens. This is done by signalling the upcoming key change ahead of time in the media segments themselves, by including additional PSSH boxes with the KID of the next key and the corresponding content protection information.

If you plan to rotate keys very frequently (e.g. every minute), or during peak traffic hours, you must make sure that your player supports this key pre-announcement mechanism, or your experience may be negatively impacted by the thundering herd problem.

In particular, players should randomize the timing of their license requests in the time window between the key pre-announcement and the actual key change, to avoid a surge of contemporary requests to the DRM provider when the key change happens.

A reference implementation of this behaviour has been developed by Castlabs and is available in Castlabs PrestoPlayer. As the picture below shows, with a correct randomization of the license requests, the expected peaks (in blue) are significantly mitigated, and the player requests to the DRM provider (in red) are more balanced over time, even when keys are rotated every few seconds.

../../_images/castlabs-player-randomization.png

For HLS, key preannouncement also include the use of the EXT-X-PRELOAD-HINT tag carrying information on the DATE-FIRST-USE of the next key. This information can be used by the player to pre-fetch the necessary license key. Support for such mechanism has been validated by Apple.

Unified Origin license requirements 

The following table illustrates the minimum version of | origin | required for Key Rotation support, across all available streaming formats:

Streaming Format	Minimum Version	Keys pre-announcement	License flag required
DASH	1.15.19	✔	Yes
HLS-fMP4	1.15.19	✔	Yes
HLS-TS	1.9.3	✖	Yes from 1.15.19 onwards

Notice how a new license flag is required, from version 1.15.19 onwards, to enable key rotation in Unified Origin, for all streaming formats, including HLS-TS.

Warning

If you are using HLS-TS Key Rotation and are planning to upgrade for the first time to version 1.15.19 or newer, please contact support to get an updated license file.

Footnotes