Historical key managament approaches leave it all in the care of the DRM vendor, leading to major lock-in and maintenance headaches that can require solution re-architecting when DRM vendors are changed or added. A modern solution architecture separates key management from DRM and enables flexible integration of solution components from different vendors.

The following important interactions take place in the key management domain:

1. The content processing pipeline needs access to keys in order to encrypt media samples.
2. The DRM server needs access to keys in order to embed them into licenses that are delivered to DRM clients.
3. Authorization decisions must be informed by which keys are assocaited with which movies (and even which particular track).
4. Usage of keys is constrained by policy configuration.

Key management practices and protocols are minimally standardized in the industry and large sections of the workflows remain implementation-specific. This article presents the key management architecture that the author believes provides the best capabilities in terms of flexible features and cross-vendor interoperability, though it is certainly not the only architecture in active use.

Keys are the technical mechanism that allows many parts of content usage policy to be associated with encrypted movie data. Therefore, a discussion of key management must by necessity also cover policy management. The two topics are presented here together.

KID is in the focus

Each key is identified by a unique KID (aka key ID). Keys are also logically associated with content, as each movie uses one or more keys (e.g. the SD video key, the HD video key and the audio key). Keys are not shared by different movies, though sometimes shared by several tracks of the same movie.

Different components involved in DRM workflows work either with the KIDs that identify individual keys or the content ID that identifies a movie, rarely both. When designing the solution architecture, it is important to understand where each type of identifier is appropriate. Needless mixing of different identifiers can lead to architectural creep and mixing of domain specific concepts that complicates future evolution of a solution.

Keep any content ID or “movie” concept out of DRM interactions. DRM is about keys and the policy that applies to the keys, so focus the domain language on keys and policy, with data sets associated by the KIDs.

Flow of policy

To determine the policy to apply to a key, there must exist some link between the key and the relevant policy. The policy that governs use of a key is associated with a specific movie.

Content providers typically define policy based on classes of content, with the policy being different for each content provider. A simplified example might be:

• For library content (old content already released on DVD)
  • Same key may be used for all tracks.
  • Any production-grade DRM client robustness level is acceptable.
• For early window content (still in cinemas)
  • Separate key must be used for HD tracks.
  • Only high-robustness DRM clients are acceptable.

An operator configures all the necessary policies in the CMS database for each content provider.

When a movie is submitted for ingest, it must be linked to the appropriate policy configuration. Based on the associated policy, the CMS needs to determine the key structure to use. The key and track associations are saved to the CMS database so that they can later be referenced to resolve the policy that applies to a specific key.

The policy to apply to a movie may change over time. Typically this is in the form of more relaxed constraints (e.g. when the content is no longer considered early window). Migrating content to use less strict policy is a simple database update that does not require re-processing of the content. Policy updates are published together with content catalog updates and take effect for any new playback authorizations granted by the authorization service.

The key-specific policy is assembled when publishing policy from the CMS database, combining the information on what keys are used by a movie with the content provider’s policy that applies to that movie, specialized for each key and enhanced by solution-specific business logic (e.g. rules like “must have ‘HD’ subscription to authorize use of HD key”).

One effect of this workflow is that only the CMS needs to know which movie uses which keys - any DRM specific data sets published by the CMS directly reference individual keys and the policy associated with those keys.

When playback authorization is requested by an app, the authorization service inspects the policy of the requested keys and makes an individual decision for each key. The policy also supplies constraints that must be enforced by the DRM client. The configuration for these constraints is embedded into the authorization token, from which the DRM server transfers it to the generated license.

The authorization token contains not only the proof of authorization but also the policy configuration that applies to each specific key. The main role of the DRM server is to translate part of the key usage policy into the constraints language of a specific DRM technology. Until the workflow reaches the DRM server, the policy enforcement logic is not tied to a specific DRM technology.

Creating and supplying keys

The key server is a database of keys and a set of APIs that can be used to access the keys. When keys are required by a component in the DRM workflows, they either request them from the key server or consume a key package previously exported from the key server.

CPIX¹ is the modern data format for key exchange. It defines a key package format that enables authenticated and confidential key delivery across the DRM ecosystem.

The key server creates and stores new keys on demand. Once created, they may be exported for use by other services. This is typically done by the CMS, which passes the exported key packages on to other components during DRM workflow execution.

It is important to keep the funcionality of the key server simple and constrained, as it is a highly security-sensitive component that has full access to the keys. All duties that do not require access to keys should be moved out of the key server and into the CMS (which does not have access to keys).

The key server knows nothing about movies or whether a key is to be used for audio or video. Only very basic relations exist in the key server, largely for the purpose of supporting certain live streaming scenarios.

Securing keys in transit

Keys exported from the key server are asymmetrically encrypted to ensure that only the intended final recipient (i.e. the content packager or DRM server) can unlock the key package.

It is common for the CMS requesting the key package to be unable to access the keys within because it is only an intermediary that coordinates the workflows and applies policy decisions. That is, the rights “can create and export keys” and “can decrypt keys” do not necessarily overlap among solution components.

A public key infrastructure must be in place for the access control mechanisms built into the CPIX document format to be usable.

Encrypting media samples

The key server can export a set of keys but that is not enough to encrypt media samples. There must also be a mapping of which keys to use for what type of content. The typical rule is “use a different key for SD video, HD video, UHD video and audio” but content provider policies can add additional complexity to this logic. This mapping can be described by the CPIX document format using simple rules such as:

• This key is to be used for video tracks.
• This key is to be used for above 480p and up to 1080p resolution (HD).
• This key is to be used for 5.1 channel audio tracks.

Knowledge of what key is mapped to what tracks does not belong in the key server, however. This is the domain of the business logic, policy enforcement and workflow orchestration mechanisms in a solution typically embodied in the CMS. It knows which content provider a movie is from and knows the policies of that content provider. The CMS often also coordinates the activities of different solution components, giving them jobs and configuration. Therefore, it is the duty of the CMS to take a CPIX document exported from the key server and extend it with policy-based data.

For more details on how the acquired keys are used to encrypt content, refer back to the article on content processing.

Encryption interactions can be further complicated in live streaming scenarios where the keys and DRM metadata can change over time. This is explored in detail in the next article.

Providing keys to DRM clients

As described in the article on secure playback, DRM clients request keys from DRM servers. Before that can happen, the key management workflows in a solution must deliver the keys to the one or more DRM servers.

A large solution may involve using multiple DRM servers from different vendors in parallel, for various legacy/contractual/policy/availability reasons. There is no universal architecture that can be assumed, beyond the need to be flexible.

DRM servers from some vendors require all keys to be inserted into a DRM server specific key database before the DRM server will use the keys in licenses. Indeed, there may be a separate DRM server database for each DRM server used in a solution.

The mechanisms for providing keys to DRM servers are not standardized, although the CPIX protocol is designed to facilitate this exchange. Still, it is only a data format and does not define an API, so a proprietary mechanism must be used with each involved DRM server to invoke the import.

Not every DRM server requires the keys to be imported in advance (or at all). A more flexible architecture is to provide the keys to the DRM server as part of the license request sent by a player. This architecture uses the player as an intermediary to carry (encrypted) keys to a license server. Typically, the keys are requested on-demand and cached by the authorization service that resolves business logic and policy constraints when a player requests playback authorization.

Note that the authorization service only ever sees keys in encrypted form. Only the DRM server holds the private key required to decrypt the movie keys.

By providing the keys together with the license request, the role of the DRM server is largely reduced to translating the policy attached to business logic authorization decisions into a DRM technology specific policy language. This enables the DRM server to be largely stateless, greatly reducing its complexity. As DRM servers often must be developed using idiosyncratic DRM technology SDKs, any simplification in the structure of and reduction in the role of DRM servers greatly improves solution maintainability. Prefer stateless workflows that use token-embedded keys instead of importing keys into a DRM server.

Standardized key export protocols like CPIX are imperfectly suitable for the embedded key architecture because CPIX documents are relatively large. This is a problem because authorization tokens are typically embedded into (size-limited) HTTP request headers. For this reason, a custom size-optimized data format is typically used for stateless DRM server workflows that use embedded keys.

Changing keys in live streams

It is typical to change the keys in live streams on a regular interval. The purpose of this is to force re-authorization of the viewer²: a new key requires a new authorization token and license, which enables the solution components to ensure that the viewer still has a valid subscription for the content. A typical interval is 24 hours between key changes.

An alternative approach is to simply make the licenses (and authorization tokens) expire on an equivalent interval. While this can provide a roughly similar experience, there are many legacy DRM clients still deployed that do not possess a tamper-resistant clock and therefore cannot securely enforce time-based constraints. Changing the keys ensures that even such clients are forced to re-authenticate.

Because the key will change at the same time for all viewers of a live stream it is important to deliver licenses containing the keys in advance of the actual key change and spread the license requests out across time to avoid overloading the DRM servers. Unfortunately, there are no industry-standard mechanisms for announcing upcoming keys, which means that the mechanism for preloading keys for upcoming key periods must be implemented using custom logic in each app.

Given that new keys must anyway be pushed to DRM clients ahead of time, which requires a timing/coordinating workflow in the CMS, the same workflow should be harnessed to also provide updated keys to the content packager.

The mechanism for providing new keys in live stream scenarios is not standardized and is different for each content packager and key server implementation. Many different integration possibilities exist, depending on the exact set of products used in the solution. Some implementations may even use a “pull” model, where the content packager contacts an external service when it wants new keys.

Key removal

Content is often licensed from content providers for a certain time span. For example, you may obtain rights to show certain movies for a 6-month period, after which you need to remove the content from your solution.

You can offer content providers a high level of confidence that this is done by ensuring that your key management workflows include key expiration and automatic expired key removal and unpublishing (with relevant audit logs).

Key seeds

Occasionally one encounters key management architectures where keys are not individually managed but instead are mathematically derived from a key seed based on the key ID, using the (conceptual) equation key = key seed + key ID.

In terms of cryptographic security there is nothing wrong with this - key seeds are a perfectly fine way to create keys. However, on a key management and solution architecture level this has various drawbacks:

1. Even if you use key seeds to generate keys, you still need to track the usage policy associated with each key, largely defeating the simplicity in all but the simplest solutions that apply the same policy to all keys.
2. Integration is complicated between systems using key seeds and those that do not, potentially requiring intermediate databases to be developed/maintained/secured.
3. Different systems may use different key seed algorithms.
4. Key removal becomes difficult to enforce - by knowing the key seed and key ID you can recreate any key that was derived from the key seed. To securely remove keys from a solution, you need to remove the key seed itself as well as the keys.
5. Instead of tracking just a key ID in various places, you now find yourself tracking a key ID and a key seed ID, increasting complexity and creating additional opportunities for accidental data mismatch that can be very hard to discover.
6. The security model implications are different; assumptions made when securing invididual keys might not hold when securing key seeds.

The above are only the most obvious complications - the more systems a solution integrates, the greater the compatibility and maintenance cost of a single factor and the greater the possible amount of surprises that can come up.

The primary advantage of a key seed approach is that you do not need to deliver new keys to the DRM server - as long as it knows the key seed, it can generate any key on its own. This may be an important feature in some rare scenarios.

Avoid using key seeds. If you are forced to use key seeds (e.g. due to legacy reasons), limit their use to the key server and have every other component deal with individual keys. Using key seeds offers some tradeoffs in rare situations but often end up making the key life cycle in a solution more difficult to understand. As DRM is already a fairly challenging topic, it is valuable to keep things as straightforward as possible.

Key security

Keys must be secured against misused at all times. On the viewer’s device, the DRM client cares for this. In all other components, the solution architecture must include required security measures to prevent key disclosure. When working with high-value content you must also protect against insider threats by the solution’s own operators - just because someone has administrator access to the servers does not mean they should have access to keys!

Security is a huge topic that depends greatly on solution specific details. Consult an expert to develop a scenario-appropriate key security model for you.

Coming up next

DRM signaling is data embedded into movie manifest files. It informs players on how to activate DRM clients. In the next article we take a look at how it travels through the content workflows of a solution and how it should be handled.

View all articles in the series.