How AES-128 Encryption for video compares to DRM systems

In this blog we will be looking to illustrate the distinction between AES-128, secure key exchange protocols and DRM systems. Popular Streaming protocols that use secure key exchange are HLS Encryption and RTMP Encryption. Widevine and FairPlay are the major Digital Rights Management (DRM) systems that are necessary for the best content protection.

At VdoCipher we are committed to streaming DRM-protected premium content for our customers across all devices. Our video hosting for business enables our customers to stream premium videos on Android Phones, iPhones, iPad, Macs, PCs and Smart TVs.

In this blog we seek to explain how AES-128 alone is inadequate for protecting premium content. Each step of security, from AES-128 to HLS Encryption to DRM, adds an extra layer of protection when it is used for streaming premium videos.

AES-128 Encryption is actually pretty strong (Just not for streaming videos)

Advanced Encryption Standard using block size of 128 bits (abbreviated as AES-128), is a strong encryption standard for protecting premium content. AES-128 is the only publicly available encryption algorithm that is recommended by the NSA. The National Security Agency has recommended AES-128  for use as part of the cryptographic module for top secret communications.

All video content protection technologies, from basic AES-128 to HLS and RTMP Encryption, to Digital Rights Management Systems such as Widevine and FairPlay use AES-128 as the algorithm for encrypting their content. Content protection mechanisms differ in how they handle the key that is used for decrypting the content.

If AES-128 is so darn strong that it cannot be broken, why is it still not sufficient?

While AES-128 is indeed one of the most secure methods of encrypting information, for video streaming just the presence of AES-128 does not guarantee complete security.

Some streaming services market AES-128 security as being effective for protecting premium content. The truth around which this little lie is built is that it is near impossible for any hacker, even one with a supercomputer at their disposal, to decrypt the information without the key.

The emphasis on “without the key” is important. An unbreakable lock protects you only when the key itself cannot be accessed by unauthorized elements.

Without a secure way in which the content keys are exchanged, AES-128 is pathetically insufficient for content protection. This is because when the key itself is revealed to the hacker, AES-128 encryption is of no use. AES-128 has to be supported by a secure key exchange protocol.

If a streaming service are ONLY offering AES 128 security, chances are that even a rookie who knows basic web development can retrieve the key. Content Protection using just AES-128 is the programmatic equivalent of buying a state-of-the-art locker for yourself, only to leave the password key written on a slip left under the doormat.

The next layer of protection – Secure Key Exchange – Authentication Tokens and signed URLs (used by HLS Encryption and RTMPE)

With Secure Key Exchange technologies, you are hiding the content keys and making them accessible to authorized users only. Authorized users in this context are users that have logged in to your site and for whom your website user management system has authorized access to premium content.

Authentication tokens and Signed URLs are means of obfuscating the source from where the key is delivered. Only authorized users can access the key. HLS Encryption and RTMP Encryption are two major streaming protocols that use this form of security.

Going back to our secure locker analogy, a secure key exchange protocol would ensure that only authorized users get the key to the locker itself. However once an authorized user has the key, there is nothing stopping them from sharing the key with non-authorized users. You can choose to automate the locker so that the key is changed every 15 minutes (called key-rotation). However even then chances are that 15 uninterrupted minutes (or even less) are enough to breach the security of your content.

The security in Secure Key Exchange protocols then lies in two facts:

  1. The key is only accessible to authorized user. An unauthorized user has to first get the keys from an authorized user. That is scant content protection for streaming content on the web. When selling premium content you are not likely to have much control over the actual users signing up for your content.
  2. The keys are somewhat hard to find – they may be hidden deep within the manifest file (as part of metadata sent as part of the video file). That however is just playing a cat and mouse game, one where you for the protection of your premium content you are relying on hackers giving up before they dig deep enough to find the keys. This is called Security by Obscurity.

How DRM is a step-up over Secure Key exchange mechanisms

The next level of content protection involves using Digital Rights Management systems (DRMs). In DRM-based streaming the content keys are at no time directly exposed to any user. Instead the header file accompanying the video file contains metadata about the encryption mechanism used. This metadata is used by a piece of software in the browser/ device, called Content Decryption Module (CDM).

The CDM uses the header metadata to create a license request, which is sent to the remote license server. The license server returns a detailed license containing the content keys. These content keys are then used by the CDM to decrypt the content. The video content is then available to the user for playback. The license request and license information are not accessible to the user, and are handled securely by Encrypted Media Extensions API.

During the time of playback then, there are three elements that come into the picture. The CDM, the License Server and EME API collectively make sure that the content decryption process is completely secure.

  1. Device/ Browser Content Decryption Module – This is the system which receives the header data from the video file. On the basis of the header data the CDM creates a license request. The CDM is a proprietary software, and its source code and algorithms are completely private. This adds to cryptographic security in the content.
  2. Widevine License Server receives the request for information and returns the license containing content keys
  3. Encrypted Media Extensions API – This API plays the role of middleman, enabling communication between the device CDM and the remote license server. At no point does the EME expose the request for license or the license itself to the user.

Examining how this is different from secure key exchange mechanisms, a separate step is created. The header data is a proxy for the key, which is then validated by the browser CDM and the license server collectively. This adds an extra step for providing content protection.

You may also like...