Migrating DRM Solution Provider for a Large OTT Service

DRM is an essential part of the OTT ecosystem. OTT service providers/broadcasters pay millions of dollars to buy rights for content and then process and serve that content to their subscribers.

It is of paramount importance that the content can be guarded against unauthorised viewing. DRM plays an important role in this regard.

At Zee5, we encrypt all the Movies/Originals/TV Shows with the following DRM encryption parameters

ABR Protocol and Container	Encryption Algorithm	DRM System
DASH fMp4	AES CTR	Widevine and Playready
HLS CMAF	AES CBCS	Fairplay

From March 2023, the DRM key and license provider used by Zee5’s OTT solution have been changed.

This was a hugely challenging migration, as it means not only all newly encrypted content but millions plus existing content on the Zee5 platform (encrypted using keys from existing key providers or some older solution) shall be played back seamlessly on all the client devices without any inconvenience (seamless user experience is of paramount importance).

It was likened to changing the engine of a car while running it on the highway at 200 Kmph, and the expectation is that these changes will be transparent to passengers!

Commercial requirements meant that 28th February 2023 was the last day when we could use the existing (at that time) DRM key/license solution provider to get a license for playback (and get keys for encryption post-ABR packaging). So the entire change on end-to-end software and required deployments had to be completed well before that.

We effectively had only 1.5 months to complete this entire migration (at the same time we were OTT live broadcast of Zee5’s first sports event). The entire Zee5 Tech team came together to ensure that we overcame this monumental challenge and we indeed came out with flying colours!

The following sections delve into more technical details about how this migration works.

Content Encryption and Viewing Flow

Even before we jump into the solution, let’s understand how Encryption and Decryption work for OTT Content.

Encrypting OTT Content

On OTT content processing flow encryption comes into the picture typically post packaging. Following are the high-level steps

• After the packager generates the HLS and DASH packaged segments, it requests the DRM key provider to provide a key for encrypting this Asset. Typically as part of the request, the packager provides information like the following
  • Required DRM System for which Metadata required (Widevine, Playready, Fairplay et al)
  • Resource/Asset Id (unique identifier for the asset for which key is requested).
  • DRM Key Id.
• The request shall conform to CPIX spec (typically XML defined by CPIX shall be passed as request body).
• DRM Key provider upon receiving the request would create a key for encryption and store the troika of <resource Id, DRM key ID and Key> and store in its DB and respond to requests with CPIX-compliant XML.
• Packager parses the returned XML and gets things like DRM system-specific encryption metadata and key. This DRM system-specific metadata (cenc:pssh for Widevine, mspr:pro for Playready, skd/IV et al for Fairplay) is embedded into relevant manifests by Packager.
• The packager uses an Encryption key to encrypt the segments with the appropriate algorithm.
• Encryption is completed!

Fetching DRM License during OTT Content Playback

On the OTT content decryption flow, the steps are as follows:-

• The player needs to download the Manifest first and get the encryption-specific metadata from the manifest.
• Post that Player chooses the preferred DRM system (for DASH) or only one available (for HLS) and then prepares an appropriate DRM license request for the system, and sends it to the DRM proxy.
• DRM proxy basically enables better control of requests to DRM license providers.
• DRM proxy forwards license requests to the DRM license provider and forwards the response from the license provider to the Player.
• The license received is supposed to be parsable and the fetching key is only supported on the compliant device.
• Once the license is received and processed, the player is armed with everything required to decrypt segments!

Migrating to a New DRM Key Provider

From a POC with the incoming DRM Key/License solution provider done earlier last year, we understood that the Fairplay license request body format required by the incoming solution provider’s license server is quite different from what we pass to the existing DRM license server. 

However, for Widevine and Playready the same payload format (for license requests) works for both key servers.

Also, another critical thing that we figured out is that while requesting a license from DRM proxy to the incoming solution provider’s license server, a token needs to be passed as a header, and this needs to be generated based on a new field called drmResourceId (which effectively has the same value as the identifier called contentId/resourceId passed to get the key during the encryption key request). 

This token and drmResourceId were not required to request a license from the existing DRM license server.

The following sections depict changes on the Client and on the OTT content generation/backend side to make this migration successful.

One of the key things to remember in these migration activities is that there is no switch to flip, which would then ensure that everything will transition to the new system. There will be a phase, where the DRM proxy needs to go to both servers for a license based on content. 

Server-Side Changes

We decided to break the required activities into multiple steps and execute them. The steps we undertook are as follows in terms of chronological order –

• A background script kept populating incoming key/license provider DB with keys and DRM Key IDs of all the existing encrypted content (some of the content was created and encrypted in 2018 or earlier!).
• Update transcoding DB to add a new field called, drmResourceId, which has the same value as resourceId /contentId for each encrypted content.
• For all new content that is getting transcoded, get the key from the existing key server, but store the triplet to the incoming key/license provider DB. So for all new content, the required details are being stored on both key servers’ DB.
• A huge task awaited here for us here, how do we pass on the resourceId (which would be of the same value as the drmResourceId field and will be the ingredient to generate a token, which will be part of the license request) to DRM proxy?
  • The DB/cache from which the relevant backend component (DRM proxy) gets details of the asset did not have an entry.
  • From transcoding DB to carrying this information to input DB for DRM proxy, there were four DBs working as a source to the next downstream DB, and the DBs are a mix of SQL and non-SQL!
  • This was a great achievement in itself to sync all these DBs with this new field for millions of content!
  • This mechanism was applicable for existing content (already encrypted content with an existing license server or older solution). We called this field drmResourceId in DB to avoid conflicts with any other field already named resourceId and specify that this needs to be used only for DRM token generations.
• As drmResourceId propagation started, and at this point, we started using the incoming key/license provider as a key source during packaging. This ensured that we are no longer using the existing solution provider’s key server to generate (and store) new keys, and new keys are only populated to incoming key/license provider DB. We have changed the sync mechanism between the aforementioned DBs to allow this new field (drmResourceId) to be carried to input DB to DRM proxy for newly generated/published content.
• As the aforementioned sync of pre-existing content happened over a period of time, the DRM proxy started querying the incoming key/license provider server for licenses for contents (for whom we could generate tokens).
• Eventually, once the 100% population of drmResourceId was completed, for all license requests DRM proxy started going to the incoming key/license provider’s server.
• Finally, at the end of February, we started to fetch licenses for all encrypted content played on all Zee5 applications on client devices from the incoming solution provider’s license server.

Client-Side Changes

• For devices consuming Fairplay-encrypted content (iOS devices, Apple TV and Safari browser), the license request body generated by the player to get a license from the incoming solution provider’s license server needed to be different vis-a-vis the license request body required for the existing license server. It mostly had to do with request format (binary vs. ASCII). 
• So, as part of the migration, a forced upgrade of the software version enabled support to generate both types of license body formats based on signalling from the backend. 

End User Experience During Transition

It is a matter of great pride that we almost had zero user playback failures reported due to this migration during the aforementioned cutover phase. We continued to test the playback of contents from our library and found for certain old content, we missed the propagation of drmResourceId to DB, and we proactively corrected this.

The icing on the cake was that we completed this migration on time, which helped from a commercial perspective too!