A modern DRM system is most often composed of two major components, which sometimes are paired with a third, namely:
- Licensing Server – the backend component, which issues DRM licenses to the user’s device, if the user was already authorised by the business rules and systems. On some setups, this component is hidden behind a CMS layer, but it still there nonetheless, a practice Google decided to end, as Google’s Widevine licensing server is always hosted and managed by Goole.
- A DRM library – present on the user’s devices (or on darker ages, on the applications themselves), which was originally a software only based solution, but has recently been evolved into being embedded into the hardware. The goal of the DRM Library was originally only intended to extract the content key from the DRM certificate, in a way that it isn’t possible for an attacker to also access to that key. Nowadays, things have gone further. A modern DRM Library is now able to verify if the underlying platform complies with the usage rules embedded in the license, before making the key
availableusable (intended typo), decrypting the content.
- An hardware security context. This is the last big innovation on DRMs. It simply describes that the DRM library runs on a cryptographically secured and signed environment (TEE) and/or the deciphered content is never accessible by the device’s operative system (SVP or SMP, depending the on vendor), no matter how high are the user’s permissions. The only way to achieve this goal is to ensure that DRMs solutions are actually embedded into the devices hardware, either by burning device unique data into tamper-proof persistent memory, or even on the device’s CPU. This is the case with ARM’s TrustZone or Intel’s Trusted Platform Module, and is what allows for the ultimate DRM security levels, such as Widevine Level 1 or Playready 3 security level 3000.