Getting the Security You Deserve: Tips for a Robust Browser Video Player

Taking full advantage of all security features available for your streaming service, especially when protecting content rights involves more than just the high level integration of a DRM technology with your encoder/packager functions. Read on for details...

As a service provider, you want to be assured that the DRM always functions end-to-end at the highest level of security that can be configured. To ensure this is the case, it is important to be aware of configuration details up and down the delivery pipeline that have the potential to compromise aspects of your security envelope.
If a specific consumption device does not meet a required security baseline, then it may be necessary to block content playback, or only permit content playback at lower resolutions than the service supports. But if all devices are capable of meeting that required security baseline, then it’s important to assure that they are operating in that security mode.

A case in point:

Did you know that a PC/Mac browser/player may default to DRM playback options that can compromise content security? The HTML5 stream playback logic implemented for any given service has a requirement to test the video playback robustness rules available on the platform and make DRM license requests consistent with the highest level of security available.

For a Widevine Content Decryption Module (CDM) the possible security levels on a platform range from L1, using a hardware video decryption and display pipeline, to L3 which normally implies only a software security layer is used. Using a Chrome browser on an L1-capable device, it can be the case that, unless specifically configured, the player will default to an L3 security implementation even though that L1 path is available. One effect of this is failing to prevent screen capture, for example, even though the security feature that prevents this is fully available in the device hardware.

This process of “falling back” to a lower security regime is signaled within the browser CDM when the content license request is initiated. The slippery slope of this fall-back, in turn, should be defeated by ensuring that the playback process pre-evaluates the available security options (a robustness check) and initiates the license request with full knowledge of the most robust playback level that can be used.

We are working closely with Bitmovin and their Player solution, as well as other player vendors, to make our customers aware of the extra player security configuration that is advisable in a desktop video environment. To ensure the highest level of security can be achieved with Widevine on browsers, Bitmovin has created 3 dedicated APIs that enable streaming platforms to leverage Widevine L1.

The following configurations can be set to improve content security on browsers which support Widevine L1 with the Bitmovin Player:

1. videoRobustness - videoRobustness?: string
   
   Sets the robustness level for video. The robustness specifies the security level of the DRM key system. If a string specifies a higher security level than the system is able to support, playback will fail. The lowest security level is the empty string. The strings are specific to a key system, and currently only the values for Widevine are known based on the Chromium source code.
   

   For example on Android Chrome and Mac OS Chrome to enforce the highest video:
   videoRobustness=HW_SECURE_DECODE

   Windows has a better integration with Chrome for Output Protection an the below video level can be used:
   videoRobustness=HW_SECURE_ALL
   
   
2. audioRobustness - audioRobustness?: string
   Sets the robustness level for audio. The robustness specifies the security level of the DRM key system. If a string specifies a higher security level than the system is able to support playback will fail. The lowest security level is the empty string. The strings are specific to a key system and currently only the values for Widevine are known based on the Chromium source code. 
   For example on Android Chrome and Mac OS Chrome to enforce the audio security level:
   audioRobustness=HW_SECURE_DECODE (maps to L1 Widevine security level)
   
   
3. KeySystemPriority - keySystemPriority?: string[]
   This option allows to leverage alternative or experimental modes of CDMs. To improve security, a value of [“ com.widevine.alpha.experiment”] can be used, which enables Widevine L1 in some browsers, if the hardware supports it. The player will automatically fall back to the standard Widevine mode if the experimental one is not available.

For the full details on the robustness levels and specific player configuration issues please refer to the public documentation on https://developer.bitmovin.com/playback/docs/streaming-drm-protected-content-with-bitmovin-player-web-sdk under “Audio and video Robustness”

This kind of loophole is one example of the need to be vigilant about the leverage of all elements of the content preparation and delivery envelope when setting up and auditing service security. Working with security experts at your partner companies can help reveal some tricky issues.

The EZDRM team is always available to help with these tricky questions!