Foreword: Copyrighted content needs protection from source through playback in digital delivery systems, meaning that embedded devices will need to implement digital rights management (DRM). In this whitepaper, Tony Walters of Certicom explains the importance of — and issues relating to — implementing DRM in embedded systems and devices.

---

Enabling DRM in Embedded Devices

by Tony Walters

Digital rights management (DRM) is of critical importance for content providers — their businesses depend on the ability to control and charge for access to their content. Their urgent need to control content delivery registers throughout the entire value chain, right down to the playback device. Manufacturers and carriers both stand to lose content-providers — and even be held financially liable — if frailties in their systems allow content to be hijacked, pirated or misused. But the device that accesses the content isn't really secure unless it is built on a trusted platform that provides security from the boot process upward.

While upper-layer security protocols can be used to secure application data and transactions, content is still at risk when it arrives at its destination. If a playback device's boot process and critical information are not highly secure, the digital content can be extracted in its clear form. This implies that playback platforms must be equipped with mechanisms for cryptographically validating the hardware environment and code signatures of downloaded software — including potentially modifiable boot code and configuration files. Content providers need to be able to trust that their content cannot be stolen and distributed.

The Trusted Computing Group (TCG) has developed a comprehensive model for how such trusted devices should function. The Group has produced specifications for an architecture as well as a set of software functions and programming interfaces that can work for a wide range of computing platforms. According to the TCG, trust is “…the expectation that a device will behave in a particular manner for a specific purpose.”

To qualify as a trusted platform, a system should provide at least three basic features: protected capabilities, integrity measurement and integrity reporting. If a mobile phone is to be protected from misuse — for example, from being reconfigured illegally to make calls without connecting to a service provider's billing system — it has to be able to securely store credentials and keys that can be used to authenticate the device and confirm the integrity of the code it's running.

These same three features are fundamental to digital rights management (DRM) in an embedded system. For maximum security, the functions should be performed as part of the boot process — because it is during boot-up that rogue software can most readily hijack control and compromise system integrity. In embedded devices that receive content over a network, such malicious software could be masked as a firmware upgrade, downloaded from any number of sources and installed, then take over the next time the system boots.

Systems Need Self-Check

To prevent such hijacking, devices should be built with the capability to self-check new software coming into the system. The device needs to verify that software originates with a known, secure source, bears an authentic certificate, and has a valid digital signature. In addition to this real-time download check, every time the device powers on a secure boot process should reconfirm the integrity of all new software. Functionally, this confirmation process begins with protected ROM, which is known to be secure (Figure 1). The process then incrementally validates each flash firmware image using their digital signatures. Once the confirmation is done and all is clear, the operating system loader can engage and the boot process proceed as normal.

Figure 1 — Implementing digital rights management in an embedded system effectively requires that the device be protected against malicious boot code that may try to compromise security. This demands secure boot memory and a means for verifying the integrity of add-on code.

Implementing this process requires a combination of hardware and software. On-chip, tamper-proof secure storage holds all crypto keys needed in the validation process, following the model of the TCG's Trusted Platform Module (TPM). Unfortunately, the TPM as presently defined is not ideal for embedded systems with their constraints on size, power, and processing capability. For embedded devices, an optimized Trusted Platform Module (TPM) derivative is ideal, providing the same functionality as a conventional TPM but embedded in silicon, eliminating board real estate consumption, reducing power, and providing a higher level of security because it is embedded and hidden in hardware. Such optimized modules are available from companies like Intel, which offers the Intel Wireless Trusted Platform, supported with software from companies like Certicom, which offers its Security Architecture code.

How the verification software behaves in an embedded TPM varies with the type of operating system in use. In a complex but not fully open embedded device (e.g. a real-time operating system, RTOS) an Authentication Entity or Trust Agent application that is stored with the secure boot code manages firmware verification and software updates. In an open application environment such as Windows CE, Symbian, or Linux, the authenticator may need to be part of the kernel, helping manage restricted access to kernel resources that are typically controlled by user privilege levels. The optimum implementation for a given module ultimately depends on the level of security desired and the magnitude of the threat faced.

Establishing the integrity of a firmware update package and its runtime code often requires the use of digital signatures, while encryption protects the firmware package itself to prevent hijacking and code theft. Boot code resides in on-chip ROM, with additional software components in reprogrammable memory such as flash, with sensitive data encrypted. The system must authenticate code signatures both at download and during boot-up. If its signature cannot be authenticated, the system will deem code to be untrustworthy. System designers can choose what to do in that case and how the device should respond, such as by shutting down or limiting functionality.

The secure boot process is beneficial in both open and RTOS environments. In particular, many of today's open devices have various modules, code images, and configuration files that must be loaded separately. To project trust from the hardware trusted platform upwards through the boot process requires a chain of hardware and software authentication for each of these components. This demands fairly complex boot logic. Software needs to access protected memory, then analyze firmware stored in flash with respect to code-signature locations and the actions to take when code fails the integrity check.

Authentication can be straight forward, involving the simple execution of callable routines with access to the underlying trusted platform primitives and crypto engine, or it can be more elaborate — involving an authentication agent or authenticator module. Too often, however, DRM functionality, SSL, IPSec and other protocols will all have their own crypto providers. This diversity quickly becomes inefficient and difficult to scale. Ideally, from a design point of view, once the secure boot process has been built, its architecture should be reusable-applicable to code-signing, validation, key management, and other functions at all levels. Adding a hardware abstraction layer, for instance, allows the code to become more portable, permitting developers to use the same code across different versions of chipsets to meet varying market requirements.

DRM Builds On Trust

The Intel Wireless Trusted Platform with the Certicom Security Architecture software is an example of an embedded TPM derivative that allows such reuse. The TPM is built directly into mobile processors. Combining TPM functionality with secure boot on certain models of the Intel PXA27x product line of network processors, the combination provides a protected execution environment that supports the processing of secrets. It further provides secure key storage and protection, and hardware acceleration that complement the trusted boot process. The combination is also modular, allowing developers to plug in additional functionality that utilizes the same core security architecture for security services such as SSL, IPSec, PKI, DRM, and more.

The Certicom Security Architecture is a modular security firmware platform that allows developers to add security to their devices, and allows ISVs to embed security in software that will leverage the trusted platform. The software supports the Intel Wireless Trusted Platform and permits evolution from legacy crypto such as RSA to ECC (elliptic curve cryptography), which is increasingly cited in standards and specifications as the preferred algorithm for public-key (asymmetric) cryptography. The hardware and software work together to enable DRM in embedded devices. Once the secure boot process authenticates the hardware platform and the Security Architecture authentication module, the module can run applications such as DRM, allowing users to request rights-managed content.

Using the Security Architecture, a DRM agent seals the encryption key of the Rights Object (the rules for the content use) and binds it to the platform's hardware root of trust. The AES key passes into the silicon through the Intel Wireless Trusted Platform, which wraps and returns the key. (Figure 2) After the wrapped key returns, the system can decrypt and use content, but only on that device. There is no need to lock the encrypted content to the device, because without access to the Rights Object, another user cannot play the content. This mechanism allows users to share content files through use of high speed Bluetooth, WiFi or wired Internet, but still requires them to connect to the content server to purchase access to the content.

Figure 2 — Once a system has booted, accessing content requires the decoding of a key using information stored in secure hardware, then using the key to decrypt the content. Content files may be shared, but keys are bound to specific pieces of hardware.

An Embedded Trust Services (ETS) module in the Security Architecture provides authorization, secure storage of certificates, keys and BLOBs (binary large objects), as well as access to hardware security functions such as hardware key-ring and key-wrapping services. The ETS API includes software emulation of hardware facilities so that an application engineer can code to one interface then reuse that work as often as needed.

The built-in hardware crypto acceleration and key management features of this architecture facilitate the building of a trusted hardware platform. Secure boot support and support for cryptographic functions create the trusted runtime environment, on top of which sits the cryptographic functions. The software makes use of a common API that takes advantage of Intel silicon and performance primitives. Once developers know the API they can use it across all models of the chipset family.

Developers facing the challenge of securing embedded devices — to provide the most comprehensive and robust digital rights management services possible — will find it essential to start from a trusted platform. Ultimately, if code at the most fundamental level is vulnerable to attack then the entire device is vulnerable to attack. This vulnerability risks everything from financial losses to personal or even public safety, depending on the applications involved. While it is possible for developers to create their own custom trusted platforms, such effort is time-consuming and costly — especially when there are off-the-shelf solutions that offer full security, reliability and ease of maintenance. The value of off-the-shelf options is particularly great for manufacturers who don't have public-key and security expertise as core in-house strengths.

---

About the author: Tony Walters is a director at Certicom Corp., a developer of security software for embedded systems.

---

Please note: This article was originally published in the Summer Issue of Embedded Intel® Solutions and on www.embeddedintel.com, and has been reproduced with permission by LinuxDevices.com.

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.