All content protection technologies have one thing in common: media encryption. In most modern DRM systems, media content is typically encrypted once, stored on an origin server, and streamed or downloaded to client devices and applications over an open network. A DRM (Digital Rights Management) license server is used to deliver, ahead of time or on demand, the key or keys needed to decrypt and play the media.
Regardless of the encryption standard used (typically AES-128), or media format (often MPEG DASH with MP4 fragments or HLS), the element that ties the content encryption and the content management together is the key(s) used to encrypt the content.
This is where things often become unnecessarily scary or opaque. It’s really much simpler than it seems. First, an encryption key, like the ones used with the AES encryption algorithm, is just a random number – Nothing more, nothing less. For AES-128, that’s 128 random bits (16 bytes/octets).
All that’s needed to create one is to have a good cryptographically secure source of random numbers. All modern operating systems offer very good built-in random number generators, so that’s not an issue. Some DRM systems needlessly impose rigid constraints on how the content keys are created and managed. But that’s only ever due to poor or suboptimal design. Content encryptors (sometimes called “scramblers” or “packagers”) should always have the option to choose the keys they want for a given media asset, and should have the option to choose how these keys are stored and managed. Having this freedom is crucially important in multi-DRM environments, where content needs to be encrypted once, and the same key(s) delivered through multiple DRM systems; if one of the DRM systems imposes its choice for the keys, that forces the other DRM systems to deal with that rigidity. But having the freedom to choose one’s own encryption keys shouldn’t mean that one should, as a consequence, bear all the responsibility for inventing one’s own key storage and management. In the world of broadcast systems based on DVB, like traditional cable, satellite and IPTV networks, the DVB standard offers a standardized multi-DRM or multi-CAS (CAS stands for Conditional Access System) interface called DVB Simulcrypt. DVB Simulcrypt includes a KMS (Key Management System) function that offers a way for scramblers and content protection systems to exchange information about encryption keys.
In the brave new world of OTT, no such standard exists. As a consequence, every OTT packager or on-demand scrambler must define its own KMS interface (and expect the DRM implementations to make themselves compatible with it), or adapt (through a plugin or with built-in functionality) to interfaces defined by DRM implementations. This is a serious impediment to the ease of deployment of OTT delivery systems that need to integrate one or more DRM technologies. This is why rather than wait for the industry to eventually, slowly, agree on a common, published, open interface for key management, the ExpressPlay service decided last year to offer a very simple, yet, complete, open interface for key storage and management. This open standard, called the SKM (Simple Key Management) API, comes with a specification, documentation and an open source reference implementation. We encourage all suppliers of components that implement either content encryption functions (DRM packagers, streaming servers, scramblers etc.) or DRM functions (license servers) to become compatible with this interface. This would remove the pain points associated with the current state of fragmentation of the OTT industry when it comes to this piece of the puzzle. With a simple REST interface, the SKM API offers a trivial-to-use and simple-to-implement way of dealing with key storage, key retrieval, and key management, in a secure way. The ExpressPlay cloud service fully supports that interface, which means that you can instruct the ExpressPlay DRM license service to obtain the keys that it delivers from an SKM-compatible storage. We also made the Bento4 packaging tools compatible with this interface so that you can encrypt/package content by pointing the packager to a secure online key store, and have the keys either obtained from storage (if they have been configured ahead of time), locally generated and pushed to storage, or automatically created on-demand by the key server.
So, whether you’re a supplier or customer of content packagers, scrambler, or DRM server, I’m sure you can benefit from taking a look at the documentationand open source reference implementation for this interface. Please get in touch with us for questions, comments, or if you would like to know more about ExpressPlay’s end-to-end content protection services at [email protected]