Estimating the number of DRM licenses
How should I go about estimating the number of DRM licenses that will be created? This is a question that most users who just start using DRM technology ask.
In most cases the answer can be quickly calculated but it is important to consider several parameters to arrive at a reasonable estimate for the number of DRM licenses that will be issued. These parameters include:
- Number of videos streamed
- Use of persistent licenses
- License renewals and real-time expiration
- Use of multi-key vs. single-key content protection
- Use of unique encryption keys per asset vs. sharing keys across assets
- Key rotation.
Remember, your choices will not only influence the number of DRM licenses issued but also the overall security of your solution. Good recommendations you can find in the OTT Streaming Security Checklist published by SVTA (Streaming Video Technology Alliance). Some of them are referred below.
Simple case​
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.
Persistent licenses​
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:
"allow_persistence": true
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.
You can configure the validity period of persistent licenses. For example: if you configure a persistent license to be valid for 30 days, and an end user watches the same DRM protected video 5 times within this timeframe, then only one DRM license is generated, and the subsequent 4 playbacks do not trigger a license request. However, if the end user wants to watch the same video again, after the persistent license has expired, then a new (persistent) license will be requested from the server.
SVTA recommends to always set the license expiry time for persistent licenses (control 6.5.8)
According to our experience, some content owners do not allow licensees to use persistent licenses. If you license the content from other parties, check your licensing agreements before using persistent licenses.
License renewals and real-time expiration​
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.
Use of multi-key vs. single-key content protection​
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 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.
SVTA’s security checklist has a critical control 6.3.2 "Use unique content encryption keys for each video profile within an asset (SD, HD, UHD). These are sometimes referred to as track keys."
Google recommends the following for Widevine:
Widevine recommendations (source: https://developers.google.com/widevine/drm/specification/best-practices?hl=en)
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:
- Android device supporting Widevine: 1 DRM request (3 keys in the DRM license response)
- Windows device supporting PlayReady: 1 DRM request (3 keys in the DRM license response)
- Apple device supporting FairPlay: 3 DRM requests (1 key in each DRM license response)
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).
Use of unique encryption keys per asset vs. sharing keys across assets​
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.
According to our experience, the above strategy is discouraged by most content owners. Content owners typically require licensees to not share encryption keys across assets.
SVTA’s security checklist defines a critical control 6.3.1 "Use unique content encryption keys for each asset."
Key rotation​
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.
SVTA recommends (control 6.3.7): "Use content encryption key rotation for live content. Use a new unique random content encryption key for every key rotation period."
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.
Conclusion​
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.