Determining robustness of content protection strategies.
Digital rights management (DRM) is known to protect and encrypt content in order to deliver it to the device. DRM’s main purpose is to close the gaps in content protection strategies and enable content consumption on different devices to be easily accessible. As DRM technologies have matured, it is expected that their security capabilities will follow.
The security measures implemented on the device determine the overall system level of protection as required by the license. Although the technological landscape has become more fragmented with different types offered, such as Widewine, Playready, Buy DRM, and ChinaDRM, the same themes and concepts are repeated on the security strategy level. More specifically, next to stealing keys and being able to decrypt any content on the network, the recording screen is a serious concern for the content providers.
In general, DRM has three levels of security with a strong trend toward increasing security levels. The security levels start with Software DRM, where keys are protected using white-box cryptography, obfuscation, anti-temper, anti-rooting, and anti-debug technologies in software. This solution has a relatively low level of security, which is usually supported by the frequent update of keys and protection technologies in a constant race with the attackers. With the advantages of ease of implementation, cost efficiency, and updating, this technology attracts interest from many market actors. However, Software DRM does not have control over the hardware, such as the screen, and therefore recording the screen is not prevented.
The next level of DRM protection is a hybrid of software and hardware protection enabled with a trusted execution environment (TEE). This hardware-based security provides more control over the resources and secure media path, but it has its issues with security robustness. The TEE separation is hardware-based; however, the Rich Execution Environment (REE) and TEE share the same hardware resources, which can lead to vulnerabilities that reduce the solution security robustness.
The most advanced security step for DRM is the use of a secure element (a processor with completely separated hardware and software that embodies a secure media path). This solution will additionally segment the implementations; however, it is the most secure approach available.
While all these solutions have increased the separation of the secure media path (SMP) from the potential hacker access, the question of overall security robustness is the main remaining piece of the puzzle. The publicly available DRM security requirements enable developers to perform self-assessments determining the solution compliance and incorrectly concluding about solution robustness. There is a large difference between security compliance and security robustness.
We can illustrate this with an example question for compliance: “Do I have a secure boot process?” The answer from the architectural level is: “Yes, I do.” This answer leads to the conclusion that the solution complies with the requirement but does not help with understanding how robust the secure boot is. The equivalent robustness questions would be: “Is the secure boot process strong enough against attackers?” Looking out of the box to find the answer to this question can lead to several ways the secure boot can be circumvented, and its existence comes to a question. Another example compliance question: “Do I decrypt video in a secure memory?” with the answer “Yes, I do decrypt in memory which I configured as secure” leads to a conclusion that the solution complies.
Fig. 1: Three levels of DRM technology protection.
Nevertheless, these questions and answers still do not shed light on the solution’s robustness. The equivalent robustness question would be: “Can the secure video path be used to attack TEE?” This robustness question sounds strange. Why do we need to protect TEE when TEE is there to protect SMP. If an attacker uses improperly configured SMP or vulnerabilities in SMP to attack TEE, much more valuable assets such as keys can be extracted.
It is very easy for a vendor to perform a self-assessment and come to a conclusion about the security level of the solution in terms of compliance. However, self-assessment is not the best path to take due to liability and security risks because robustness is a significantly different concept from compliance.
To recap, there are three different levels of security protection for DRM with increasing levels of security embedded in hardware: software DRM, DRM via Trusted Execution Environment, and protection via Secure Element. The overall tendency of the market is to seek hardware-based security. With increasing security requirements, what is frequently forgotten is the consideration of the device’s security robustness. The involvement of a third-party testing laboratory will significantly increase the security and robustness of solutions.
Are you looking to learn more about DRM security? Check out our on-demand webinar recording about DRM in PlayReady.
Leave a Reply