Where DRM comes into play
Any basic description of what a DRM actually is isn’t that much forthcoming without an associated diagram, as the following.
In order for a DRM to actually come into play, the user needs to use the VOD application, usually going through a very high level set of steps (1) :
- User authenticates itself on the application, usually by providing a login and password, or for the most advanced applications, using a seamless method, such as using the devices identity. Although not common for most over top applications, such as Netflix, telcos can take advantage of owning the pipe and/or the trusted device, using this for authentication purposes. This significantly improves the user experience.
- As soon as the authentication is performed, a properly designed application will present the user with the most recommended assets from the catalog, or so the application designer hopes. Regarless of the success of the applications recommendations, the user ends up navigating through the application’s catalog.
- Hopefully, a content is selected for purchase and or consumption. It’s kind of strange, but from a content management and DRM perspective, it makes absolutely no diference if the user needs to purchase the individual content, or if it makes part of an already purchased subscription. The outcome of this step is aways the same: a token authorising the user to consume the selected content. This token is often composed of the following pieces of data, although implementations vary a lot on this aspect:
- Content Identification
- Account Identification
- Usage rules
- Signature
- The application obtains the content URL and associated metadata, including the list of available DRMs and DRM endpoints. After selecting any of the device compatible DRMs, which most often is only one, the application forwards the token obtained on the previous step to the DRM library on the device.
- Finally the DRM comes into play! Receiving some user data (the user’s token) and the content’s metadata (particularly the content identifier) is what triggers the DRM into action. The DRM library now packages the user’s and the content’s data in a secured and proprietary fashion and forwards it to the DRM server or back end, usually including some additional data on the device itself.
- On the DRM backend, the user’s data is checked for authorization for the content identified on the request, and if successful, the DRM triggers the DRM license generation process:
- Obtain the key used for decrypting the content from the key vault, based on the content identifier
- Obtain the DRM specific metadata associated to the content
- Verify that the devices characteristics exceed those defined on the content’s security requirement (more on this later), and finally…
- Package all that data, encrypt it using AES and a DRM specific key, and return it to the requesting application, or more correctly, to the DRM library used by the application. This package is what is known as DRM License.
- When the DRM library receives this license, unpackages and extracts the information contained on it. Then, verifies again that the device complies with the security requirements needed for the content, such as HDCP 2.2 or CGMS-A, and if that’s the case, extract the actual key needed to decipher the content. A most important innovation on modern DRMs, is that the decryption key never leaves DRM library security context. Implementations vary, but at the end of the day, it means that an attacker, even if controlling the device’s OS, cannot extract the key from the library, and in some cases, not even to the decrypted content.
- Finally the user gets to watch the authorised content, if the device matches the security requirements, which was not that often some years ago due to HDCP 1.4, a problem which seems to be reappearing with HDCP 2.2 on 4K content, but that’s for another day. Either way, the journey ends here, although it may loop on more complex scenarios.