What is Digital Rights Management (DRM)?
Digital rights management uses encryption, licensing, authentication, and playback policies to control access to digital content. DRM systems can restrict how protected software, video, audio, or other works are used and distributed.
How Digital Rights Management (DRM) works
For streaming video, DRM has three cooperating parts. A packager encrypts the encoded media with a content key and writes signaling that identifies the key by its key ID. A license service, run by or for the content provider, decides whether a particular client may receive that key and under which conditions, such as an expiry time, a minimum client security level, or required output protection. A content decryption module (CDM) supplied by the browser or device platform obtains the license, decrypts the media, and enforces those conditions. In a browser, the Encrypted Media Extensions (EME) API connects the parts: the page passes messages between the CDM and the license service. Deciding whether a viewer is entitled is not something the DRM system does by itself. The EME specification leaves authentication and authorization to the application, and Widevine’s documentation describes a provider-operated proxy that validates each license request and adds business rules before the license service answers. DRM also answers a different question from transport encryption: in the words of the DASH-IF guidelines, HTTPS only protects the transport link and does not replace a DRM.
Key facts
- 1Can one DRM system reach every device? No. EME is a common API for discovering and talking to a protection system; it defines no DRM system or license protocol, and the only system every implementation must include is Clear Key. Which commercial system is present depends on the platform: Shaka Player’s support matrix lists Widevine in Chrome and Firefox, Widevine and PlayReady in Chromium-based Edge, and only FairPlay in Safari. Microsoft states that Edge supports PlayReady only on Windows 10 and later, and Widevine’s own platform table marks desktop Safari and Apple TV as unsupported. By that matrix, Widevine and FairPlay between them are present in all four of those browsers, and PlayReady is a second option in Edge on Windows. On phones, Widevine’s table lists Android as supported, and Shaka Player’s HLS feature list limits FairPlay to Safari on macOS and iOS. A service that must play in all major browsers therefore needs licenses from more than one system for the same content, commonly called multi-DRM.
- 2Is HLS AES-128 or Clear Key encryption DRM? Not in the sense a content license usually requires. With HLS
METHOD=AES-128and the defaultidentitykey format, the playlist names a URI from which the player downloads the key as a raw 16-byte file, so every client that can fetch that URI holds the key itself, and protection rests entirely on controlling access to the key URL. EME’s Clear Key system likewise uses unencrypted keys, and the Shaka Player project describes it as a debugging tool that provides no actual content security. Neither comes with a hardened client that keeps the key away from the application or enforces playback conditions. - 3Why does protected video play on one device but fail, or play only at low resolution, on another? Because a license can demand more than the device offers. PlayReady, for example, distinguishes software-protected SL2000 clients from SL3000 clients that keep keys and decrypted video inside a hardware trusted execution environment; a license server can give the two different resolutions, and a client refuses a license whose minimum security level it does not meet. A license can also require output protection: Microsoft’s example is a set-top box that will not play content over HDMI to a television without HDCP, and EME reports this situation as the key status
output-restricted. Packaging can be the obstacle too, since EME notes that different encryption schemes are generally incompatible with one another. Test on the weakest device class you intend to support and offer a rendition whose requirements that class can meet. - 4What happens when a license can no longer be obtained? Playback fails once the device holds no usable license, even though the files are intact, because the key arrives only inside a license. EME requires support only for temporary sessions, whose license and keys are never stored and are destroyed when the session closes, so starting again after that means a new request to the license service. Persistent licenses are different: the license is stored and the session can be loaded again later, which is what offline playback builds on. Content licensed this way can keep playing while the stored license remains on the device and its terms still allow it. EME makes persistent licenses optional, and the Shaka Player project notes that storing licenses depends on browser support. A key whose expiry time has passed is reported as
expiredand can no longer decrypt. Keeping the encrypted files is therefore not enough by itself: long-term access depends on either the license service staying available or a stored license that still permits playback.
When Digital Rights Management (DRM) matters
Add DRM when distributing content under contractual access or playback restrictions. Device support, license availability, and entitlement errors can prevent authorized users from playing otherwise valid media.
Sources
- W3C Encrypted Media Extensions (scope, Clear Key, robustness, key statuses, session types)
- Shaka Player README: DRM support matrix by browser and platform
- Google Widevine DRM overview (supported platforms, license proxy)
- Apple FairPlay Streaming
- Microsoft PlayReady: Security Level (SL2000 and SL3000 clients)
- Microsoft PlayReady: Output Protection Levels
- Microsoft Edge: User data and privacy, PlayReady DRM (supported only on Windows 10 and later)
- RFC 8216 (HTTP Live Streaming), Section 5.1: Structure of Key Files (EXT-X-KEY and KEYFORMAT are defined in Section 4.3.2.4)
- DASH-IF Interoperability Points v4.3, Chapter 7: Content Protection and Security