Estimating the number of DRM licenses

Whenever a user wants to watch a piece of DRM protected content their device needs a DRM license. The DRM license contains the key needed for decrypting and playing the content.

In many cases, estimating the number of DRM licenses is quite straight-forward: if you encrypt your content with just one key per asset, don’t use real-time expiration, and don’t use persistent licenses then the number of DRM licenses issued in a month will be very close to the total number of videos streamed to your audience.

Now let’s look at how the above-mentioned parameters can influence the number of licenses issued.

Axinom DRM lets you make use of "persistent licenses". These are licenses that are allowed to be stored on the client device. By default, this is not allowed, and it needs to be explicitly configured in the Entitlement Message. Use the following setting:

When persistent licenses are used, a client device will request a DRM license only when it first tries to play a DRM protected video. If the same client wants to play the same video later again, then the persisted DRM license will be reused.

With Axinom DRM you can configure DRM licenses to expire in real-time. This feature is often used during live events when customers want to have granular control over the streaming experience and be able to interrupt active streams in case of abusive behavior.

Axinom DRM lets you configure an arbitrary timeframe after which licenses expire. A typical timeframe for this scenario is 3-5 minutes. Let’s make an example: we assume that a client device receives a DRM license which is configured to expire after three minutes. This means that the client device must send new license requests every three minutes to renew the license. This must continue as long as the end user keeps watching the stream. Considering a stream of 90 minutes, this translates to 30 license requests being sent by that single user.

As you can see, license renewal configuration and associated timeframes can have a significant impact on the number of DRM licenses issued.

Today it is recommended to encrypt adaptive bitrate (ABR) assets with several encryption keys. For a long time, most streaming services just used one encryption key to encrypt all parts of an ABR asset. All audio tracks, video resolutions, and even subtitle tracks used to get encrypted with a single encryption key. But this is not the recommended best practice today.

One reason behind this is that different channels may enjoy different levels of protection on the client device. For example, while the video portion of a stream may be protected by specialized hardware on a device, the audio track may be decrypted and played without this level of protection. For an attacker it may be easier to discover the decryption key of the audio track than the key for the video. However, if just one key is used to protect all parts of an ABR asset, then there is nothing that prevents the attacker from using the key that they extracted from the audio portion and use it to decrypt all video and subtitle tracks as well.

That’s one of the reasons why it is a best practice to use different keys for different tracks.

Google recommends the following for Widevine:

More encryption keys can result in more license requests, but calculating this requires some additional knowledge.

As of this writing, the DRM technologies vary in terms of support for delivering multiple keys within a single license request. While Widevine and PlayReady can return more than one key as a response to a license request, FairPlay always only returns one key in a DRM license. This means, the number if DRM licenses issued will vary, based on the client device’s supported DRM technology.

Let’s make an example: we assume that there is an ABR asset that is encrypted with three different keys. One for HD video tracks, one for SD video tracks, and one for audio tracks. Depending on the DRM technology, this can lead to different numbers of DRM license requests:

Note that the details may vary. For example, if an Apple device would have a bad internet connection it might never have enough bandwidth to switch to the HD stream which in turn may result in just 2 license requests being sent (one for audio, one for the SD video stream).

Technically, it is possible to do pretty much the opposite of what was described on the previous paragraph. There is nothing that prevents one from sharing encryption keys across assets. Such a strategy may reduce the number of DRM licenses if it is combined with persistent licenses.

Example: we assume a streaming service has two "packages" of movies. Each "package" contains 100 movies. The service only uses two encryption keys to protect its movie library. All movies in one package get encrypted using the same encryption key.

Now, if an end user tries to watch a movie for the very first time, then a DRM license request will be created. Let’s further assume that the DRM license is allowed to be stored on the client device. Then, when the end user tries to watch the next movie from the same "package" the DRM client on the device will detect that it already has the key that is needed to decrypt the new movie and thus won’t send a DRM license request. A new DRM license request will only be sent after the persistent license expires, or if the end user tries to watch the first movie from the other "package", or if the end user uses a new device.

Key rotation is another factor that can have a substantial influence on the number of DRM licenses issued. Streaming services employ this method to enhance stream protection. Key rotation involves periodically changing the encryption keys used to protect content during streaming.

Typically, key rotation is employed for live streaming events or live linear streaming, but sometimes it is used with VoD assets too.

We have seen anything from rotating keys every few minutes to changing them every 48 hours. The shorter the key rotation period the higher the number of additional DRM licenses requested.

There is a variety of reasons for key rotation: some services rotate keys to switch between encrypted and clear content, others use key rotation to separate programs within a linear channel.

No matter what’s your reason for rotating keys there is another aspect to keep in mind: if done naively, key rotation can cause extreme peaks on the side of the license service.

Let’s look at an example: we assume there is a live stream of a popular sports event with an audience of 4 million concurrent viewers. If in such a scenario the packager simply switches the encryption key and signals the new key in the respective segment, then all clients receive this information roughly at the same time and will all turn to the license service for a new license. This can cause peaks of several hundred thousand requests reaching the license service every second which in turn can overwhelm the service and lead to service disruption, in the worst case. A simple way of mitigating this problem with Axinom DRM is just purchasing enough Guaranteed Capacity upfront. A more elaborate custom solution, that uses temporal distribution of license requests, may be more cost-effective, though.

There are multiple parameters influencing the number of DRM licenses issued. The choices you make may impact not only the total number of licenses requested, but also the security of the solution.