with open operating systems, creating a wider array of attack vectors. The prevalent approach to mitigate
this threat is based on hardware isolation of an execution environment for sensitive information, ensuring
data privacy for end users and services.

Mobile devices and associated security standards and protocols have been around for many years. It is common practice to secure inbound and outbound communications and to protect the permanent data stored on a device. Standards and technologies that address these requirements are well-defined and have been widely adopted – for example, standards defined by the Internet Engineering Task Force such as Internet Protocol security (IPsec) and Transport Layer Security (TLS) or persistent storage encryption technologies for disk or flash such as BitLocker for Windows and dm-crypt for Linux. However, as lifestyles have become increasingly digital and smart devices have become an inseparable part of our daily activities, the need for security has increased significantly.

As technology has evolved and enabled additional use cases, more sensitive assets are finding their way onto devices such as commerce- and entertainment-related credentials. This development has increased the circle of potential hackers and created a wider array of attack vectors trying to exploit the vulnerabilities of modern embedded systems.

A recent prominent class of threats has resulted from the proliferation of “rich and open” Operating Systems (OSs) such as Android. While Android’s intentional openness – manifested as code and documentation availability, as well as a built-in debug tool – leads to ground-breaking innovations by a massive developer community, it comes at the price of innovative attack vectors. These vectors typically lead to a state where a black hat has managed to gain privileged execution rights and full access to all assets available to the Android OS at runtime.

The following discussion describes the prevalent approach to mitigate this threat or at least limit the scope of assets compromised and minimize the associated cost of such control loss on the rich OS. This approach, which is based on hardware isolation of an execution environment for sensitive information, is critical to ensure data privacy for end users and services, particularly in the case of video on demand, commerce, and banking services.

It is important to note that the phenomenon of devices exposing an ever-growing attack surface is not limited to the mobile consumer electronic space. Other embedded systems that were justly classified as “closed” in the past, such as automotive control units or industrial systems, are becoming vulnerable to a similar type of attack. The main code execution entities in these devices are no longer safe due to OS openness, along with a multitude of external connections.

An isolated execution environment

The key to this security approach is the introduction of a Trusted Execution Environment (TEE), as it is termed by the GlobalPlatform. This environment, depicted in Figure 1, is isolated from the feature-rich, performance-based Rich Execution Environment (REE). In a nutshell, the TEE is used to protect sensitive, software-based security services from the REE. Modern Systems-on-Chips (SoCs) typically base this isolation on one of the following hardware measures:

• A hardware-separated execution mode in the main SoC processor: This approach is evident in TrustZone technology developed by ARM and available on all members of the Cortex-A processor series. Note that in this approach, a CPU core is either executing code belonging to the TEE or the REE (typically switching back and forth between the two domains).
• A physically separated processing entity (a stand-alone CPU) dedicated to security tasks: This approach, which is more intuitively understood, though not necessarily better (as always, the devil – aka the black hat – is in the details), has been around for a longer period of time and is still used in many devices. Note that in this approach, the dedicated security CPU core is only executing TEE-related code.

 

 

A comparison of the two approaches is tightly coupled with specific implementation details, and the right method can differ from system to system. Another approach to achieve such isolation that is currently less prevalent in the embedded space is based on a hypervisor or Virtual Machine Monitor (VMM). With this method, execution environments or virtual machines are separated by a software layer (the hypervisor) that is running at a higher privilege level. Assuming a robust, mathematically proven implementation of the hypervisor, this software-based approach can be very effective.

An interesting term-related distinction in this context is parallel to the difference between a Trusted EE and a Secure EE. The term Trusted alludes to the basic assumption behind the usage model: Code that is placed in the TEE is trusted to be nonmalicious and bug-free. There is nothing inherent in the TEE that prevents ill-formed TEE code from revealing sensitive assets to the world outside the TEE’s “walled garden.” This trust implies the need for an exhaustive review and verification of code placed in the TEE, especially if this code is serving multiple unrelated security services running within the TEE.

TEE implementation

The TEE typically offers generic security services known as Secure OS, which includes handling secure boot, communications, persistent data storage, cryptography, secure platform management, and more. In addition, specific Trusted Applications (TAs) run in the TEE using these services. A TA is typically a component of an application of wider scope that runs in the REE and interfaces with the user and other parts of the OS.

An example of a usage scenario is one where the user tries to consume high-value content such as HD video obtained through a subscription service. The user interface and multimedia framework interface are performed in the rich OS while portions of the Digital Rights Management (DRM) scheme such as usage policy enforcement, content key extraction, and secure video path enforcement are handled in the TEE by a dedicated TA. This separation is required to comply with robustness rules published by the DRM scheme owner in an open environment.

A single-usage scenario can involve several TAs. Along the lines of the HD content consumption example, a user might want to send video from a handheld device to a remote and perhaps larger display using a standard such as the Wi-Fi Alliance’s Miracast. To comply with Miracast security-related requirements on an open system, the Miracast software stack must be located on the REE, communicating with a TA in the TEE implementing the High-bandwidth Digital Content Protection (HDCP) 2.x specification as required by the Miracast specification.

Careful attention must be given to the task of breaking down a use case into the parts benefiting from execution in the REE versus those mandated to be ported into the TEE (see Figure 2):

• Excessive code pushed into the TEE could lead to performance degradation (throughput and power consumption), as well as potential security issues. As stated earlier, the trust in the TEE code originates from a careful review of what is placed there, a task favoring minimal code.
• Not having all the parts needed in the TEE could increase the risk of potential security breaches, resulting in a greater probability of financial sanctions. Licensees of most, if not all, content protection schemes accept liabilities in the multimillion-dollar range. It is a common misconception that only the cryptographic parts of a security-related protocol must be well secured, while leaving the logic that connects the crypto outside of the TEE. In fact, tweaking the “harmless” glue logic completely circumvents the security scheme.

 

 

The complexity level rises significantly when multiple TAs are needed in the TEE. The basic requirement is for mutual distrust between those TAs (assuring that a compromised TA cannot compromise others). Mutual distrust is typically handled by the Secure OS security services layer. Nevertheless, there are scenarios where different TAs must collaborate and exchange information securely, such as the aforementioned content protection scenario employing DRM and HDCP link protection.

The road ahead

Notwithstanding its accompanying security benefit, the task of distributed embedded software development using TEE and REE is not trivial, and compared to traditional development actually hinders the development cycle. Being a relatively nascent technology, this finding is not surprising. The phenomenon could change once design teams become better acquainted with the concepts, related tools, and development environments. TEE usage adoption rates will be accelerated if service providers’ requirements mandate it.

One concern service providers have is the scalability of their systems due to the fragmentation of devices and their security capabilities. No one wants to redo an application repeatedly. This concern is currently being addressed by the GlobalPlatform standards organization. The GlobalPlatform plans to publish a formal process for TEEs entailing certification by accredited labs.

The openness of modern devices, along with the extended connectivity introduced by new use cases, calls for higher levels of security in the embedded space. Distributed software execution using an REE alongside a hardware-based TEE has the potential to form a robust security solution, meeting stringent requirements without compromising the user experience.

As with other technologies, the key for adoption is defragmentation through standardization, an ongoing process in which the concept of a TEE is gaining support. Stay tuned for more progress in TEE embedded software development.

Asaf Shen is VP of marketing and IP products at Discretix.

Discretix [email protected] www.discretix.com

Follow: Twitter Blog Facebook Linkedin