Secure implementations of DRM content protection schemes
Companies such as Netflix are driving requirements for highly secure DRM implementations on mobile platforms. Recently, Netflix wrote a blog entry explaining that they cannot support Android-based platforms at this time because of insufficient security mechanisms for these platforms.
The need for secure DRM implementations is real, and it is happening now. Secure and robust DRM implementation, as defined by content owners, is mandatory in order to enable premium content licensing by the service provider. Such robust implementation requires an in-depth understanding of the security vulnerabilities of today’s connected devices. This article explains what is required to build a secure DRM solution. The first part of the article develops a DRM threat model. The second part of the article presents some approaches to a secure DRM solution.
DRM threat model
In order to develop a DRM threat model, we start by reviewing a typical DRM flow. From this, we identify the assets in a DRM system. Finally, we define against what attacks the DRM assets should be protected.
Figure 1 illustrates a typical DRM Flow
The DRM flow described above illustrates the elements of the system that must be protected in a secure DRM system, i.e. the DRM assets.
The first set of assets that must be protected is all DRM private keys and license files that are permanently stored on the device storage. One example is that of a DRM scheme that includes system-wide keys which must be stored securely on the device. A second example is a private key that uniquely identifies the device in a DRM scheme ecosystem.
The second set of DRM assets is temporary keys. The most common example of temporary keys is CEKs that are extracted from license files during run-time.
The third set of DRM assets is the decrypted compressed content data that is passed from the DRM client to the codec. This is actually the “native” form of the content.
Note that DRM-protected content files are not included in the list of DRM assets. They are protected by means of the encryption as defined by the DRM scheme.
The threat model defines what kinds of attacks are considered relevant and which should be defeated or at least hindered by the protection mechanisms employed in a solution. Thus, the threat model defines the attacks that are considered in the scope of the solution. In general, the threat model will exclude attacks that are more expensive to mount than the value of the assets that may be obtained, while also considering potential attack scalability. There may be other reasons to exclude specific attacks from the threat model. In a DRM system, there are two types of attacks that are considered in the scope of the threat model.
Software attacks: This encompasses all attacks mounted by software techniques, including attacks mounted by an attacker that has root privileges in the system. Hardware attacks: This includes attacks mounted by monitoring the device hardware ports. In some cases, this may also include probing inter-chip signals on the device PCB.
Protection of assets
Having defined the list of DRM assets that must be protected and the list of attacks against which they must be protected, we can summarize the mechanisms used to protect the assets. The following table summarizes the protection mechanisms used to protect the assets.
Although decrypted, compressed content must be protected, its protection has normally been considered out of scope for DRM requirements, or at most, has been considered a “soft” requirement. However, as noted above in the introduction, we have recently seen a push for high-security DRM implementations. The meaning of high security is exactly the added focus to protect decrypted, compressed content as a strict requirement.
It is important to understand some details of the protection mechanisms listed in the table.
Secure storage. This is an encrypted, integrity-protected database that is stored in the device permanent storage. Access to database items is controlled by some form of authentication, which in the case of DRM is the authentication of the calling application.
Protected execution. This is an execution environment that is protected from the main OS running on the device, i.e. programs running on the main OS cannot access the code and data memory spaces of the protected execution environment.
Secure content path. This is a data path from the DRM client to the codec that cannot be accessed by the main OS.
Each of these mechanisms can be implemented using software or hardware techniques. The implementation details are described in the remainder of this article.
Software-based DRM solution
Figure 2 presents a diagram of a high-security, software-based DRM solution. The DRM client and Video codec are compiled together into one monolithic DRM-codec object. In addition, the DRM-codec object includes software cryptographic engines and software-based secure storage.
Figure 2: Software-based DRM solution
A number of software techniques are employed to protect the DRM-codec object from reverse engineering and other software attacks. The internal program flow and data objects of the DRM-codec object cannot be accessed by any processes running in the OS, including malware with root privileges. Before we examine the details of the software protection techniques, we can see how this solution addresses the DRM requirements.
All DRM keys and license files are stored in the secure storage data base. They can only be accessed by the DRM client. When the DRM keys and license files are loaded by the DRM client into its internal memory space, they are protected from eavesdropping by any other processes. The DRM client extracts CEKs from the license file to decrypt the DRM content. The CEKs are located in the system memory space but they are unreadable by other processes because of their obfuscated format (see the following section, Software Protection Techniques).
The decryption of the DRM content is done by the software crypto engines that are integrated with the DRM-codec object. The decrypted, compressed content is sent from the DRM client to the codec using obfuscated means that are difficult to reverse-engineer. The resulting solution protects all of the DRM assets according to the requirements of a high-security solution.
Software protection techniques
A number of techniques must be used in order to make a robust software-only solution.
The first technique is software obfuscation. Software obfuscation is a method by which the control flow of a module and the data handled by the module are scrambled. First, some operations in the source code are replaced by obfuscated routines. After the module is compiled, the binary code is further scrambled. The first step is called source code obfuscation and the second step is called binary obfuscation.
By its nature, software obfuscation adds significant complexity to the module’s operations in order to hide the original program flow and the plain data. This complexity results in a much larger binary image as well as slower execution. Some analysis is needed to identify the security-sensitive parts of the module and apply obfuscation only to those parts. This is important in order to limit the effects of obfuscation on code size and performance.
The second software technique is variability. Variability means that the functionality of a software module is modified according to an initial configuration setup. A software module is configured to function differently in different devices or even in the same device from power-on to power-on. This makes it difficult for an attacker to generate repeatable exploit code that is scalable, i.e. that can be made widely available to others.
The third software technique is renewability. The module is designed so that the core security operations can easily be replaced with an over-the-air update. If the core security functionality of the module is compromised by an attack, an update is released to change this core functionality to another method.
Putting it all together
The above described techniques are employed together to provide a robust, software-only DRM solution. First, the DRM Client and the Video codec are compiled together as one monolithic object. This object is secured using source-code and binary obfuscation. The resulting DRM-codec object provides a secure environment that protects the DRM assets.
The secure storage data base is encrypted and integrity-protected by keys that are difficult to obtain from outside the DRM-codec object. The DRM keys, license files and CEKs are opened only by the DRM-codec object. Content decryption is done by an obfuscated cryptographic routine. The decrypted, compressed content is passed from the DRM client to the Video codec within the DRM-codec object.
In addition to software obfuscation, the robust DRM solution must also employ Variability and Renewability techniques in order to “future proof” the solution, and protect it against the generation of exploits. Variability makes it difficult for an attacker to reverse-engineer a software implementation in a way that produces a repeatable result. This makes a specific implementation more robust. If a specific implementation is hacked, a new scheme is introduced by using the Renewability feature of the solution. Now the attacker must start all over again in attempting to hack the solution.
Hardware-based DRM solution
Figure 3 presents a diagram of a high-security, hardware-based DRM solution. The hardware-based solution is based on a Trusted Execution Environment (TEE). The TEE is separated from the main OS by hardware. This ensures that the main OS, and malicious applications running over it, cannot read from the secure memory which is dedicated to the TEE and cannot observe the program flow of the TEE CPU. Some examples of hardware-based TEEs are Discretix CryptoCell and TI M-Shield Mobile Security.
The DRM client is partitioned into security-critical and non-critical parts. The security-critical part of the DRM client is executed in the TEE and the non-critical part is executed by the main OS.
For premium content that requires high bandwidth, a hardware codec is normally used in the solution. The hardware data engine of the codec is secured by placing it in the TEE. The codec control code may run over the main OS.
Figure 3: Hardware-based DRM solution
This solution addresses all of the DRM requirements. All DRM keys and license files are stored in the secure storage data base. The data base is encrypted and integrity-protected with hardware keys that are only accessible from within the TEE. When the DRM keys and license files are loaded by the DRM client into the TEE secure memory space, they are protected from being read by any processes running on the main OS. CEKs are extracted from the license file and only exist in the clear in the TEE secure memory space. The decryption of the DRM content is done by hardware crypto engines that are located in the TEE. The CEK is loaded by the DRM client directly from the TEE secure memory space into the crypto engine and cannot be read from the main OS.
The decrypted, compressed content is sent from the hardware crypto engines in the TEE to the codec data engine in the TEE. This data transfer is protected from the main OS by the TEE hardware protection. A hardware-based solution is generally considered to be more secure than a software-based solution. As such, it is easier to get a hardware-based solution certified as a robust DRM implementation for premium content.
The world of content is experiencing exciting new developments with the availability of premium content on multiple, high-performance devices. In order to enjoy this premium content, there is a strong requirement from the content owners for high-security implementations of DRM schemes on these devices.
This article develops the threat model for a DRM solution. We presented two approaches to high-security DRM implementations: software-based and hardware-based. Each of these solutions addresses the high-security DRM threat model. Finally, we pointed out that hardware-based solutions are generally considered to be more secure than software-based solutions.
David Deitcher is Chief Technology Officer at Discretix – www.discretix.com