The Ideal Secure Execution Zone
There has been considerable research into creating an SEZ for executing software agents in a secure manner on a PC.
The ideal SEZ is a measurable, tamper-resistant environment that executes code and returns the result to entities outside the SEZ, together with a proof that the result was actually generated inside the SEZ. The fundamental trade-offs for an SEZ are these:
- Threat models and spectrum of addressed use cases
- Size of the TCB -- the enforcement entity
- Complexity of implementation, validation, deployment, and support
SEZs can be divided into three main categories: in-band, out-of-band executing on the host, and those executing at a remote site.
In-band Secure Execution Zone
An in-band SEZ on a PC is created within the confines of the host OS. The SEZ is essentially a compartment that runs inside the linear address space of the OS processes. The SEZ selectively uses OS services but it is immune to interference from agents running at the OS privilege levels or the user privilege levels. The SEZ is enforced by entities on the platform that run at a higher privilege level than the OS itself. These enforcement entities may be CPU subsystems that have the privilege to access CPU resources that are not directly available to the OS (for example, CPU subsystems have access to internal CPU states that are not accessible to the OS) or software entities that run at higher (than OS) privilege modes as provided by the CPU (for example, a micro-vmm in VMX-root mode). Figure 3 shows a typical SEZ in an open execution environment.
The SEZ runs within the confines of the OS; that is, the SEZ is in the linear address space of the OS (or its processes) and is scheduled by the OS. Since the SEZ generally sends a signal to its enforcement entity when the computation is completed, a DoS attack can be detected (but cannot be prevented) in most cases.
Out-of-band Secure Execution Zone
An out-of-band SEZ is a zone that is created in parallel with the OS. It may execute on the main CPU or on a processor adjacent to the main CPU. The IBM 4758 Cryptographic Coprocessor  is an example of such an out-of-band SEZ. It may run at the same privilege level as the OS, but it enjoys higher trustworthiness than the main OS by virtue of its limited usage and its tightly access-controlled agents that run inside these SEZs. Some of these SEZs also include enhanced hardware protection. In other words, since this kind of SEZ executes only trusted code in a controlled fashion, it enjoys higher trustworthiness than the OS. Like an in-band SEZ, an out-of-band SEZ is also created by an entity running at a higher privilege level than the host OS. Figure 4 shows a typical out-of-band SEZ.
One advantage of an out-of-band SEZ is that it is less susceptible to DoS attacks than an in-band SEZ, since the out-of-band SEZ does not have to depend on the host OS for any of its functionality. In addition, since this kind of SEZ runs on bare metal hardware or over an entity that emulates bare metal hardware, it runs its own OS, and as a result, is not dependent on the host OS. Running an OS inside an SEZ also has its pros and cons. In its favor, the OS can be suitably modified for the needs of the agents inside the SEZ and can be stripped down to a bare minimum, as a result enabling the agents to trust the OS services. Running against it, however, is the fact that any OS is likely to be greater than 10K lines of code, and as such, will have a larger attack surface than an in-band SEZ running over an untrusted OS. The out-of-band SEZ can still be functional when the host OS is not running.
An out-of-band SEZ can also be hardened against hardware attacks to whatever extent is deemed necessary to protect valuable data, such as keying material. This can be done without the expense of hardening the entire system.
The disadvantage of an out-of-band SEZ is that it is restricted to the limited performance and functionality offered in the SEZ environment. Most out-of-band SEZs do not provide a general environment for third-party applications to run their code.
Out-of-band Remote Site SEZ
With the advent of cloud computing, out-of-band, remote-site SEZs are likely to come to the fore. These kinds of SEZs follow a client-server model, wherein the client packages code and initialization data for computation to a remote entity in the cloud (after mutual authentication) and receives the result of the computation with a proof that the computation was done in an SEZ in the cloud with the attributes of an SEZ. Since this SEZ is off the platform, a mutual trust relationship has to exist between the client and the cloud that can subsequently be enforced by using various cryptographic mechanisms. A remote site-based SEZ also has advantages and disadvantages.
The advantage is that clients do not need additional hardware or system software for creating SEZs; the SEZ does not eat into the client's resources, and the client can access the latest resources (for example, fixed function blocks, algorithms, and so forth) available in the cloud but not available in the client hardware.
The disadvantages of a remote site-based SEZ are that the underlying trust relationships are hard to create and even harder to enforce. These kinds of SEZs can be a liability when something does not end up as expected. A sub-problem of remote site-based SEZ trust relationships is privacy protection: the client, the user, or both might be identifiable with certain provable attributes. It is often hard to protect the remote SEZ without a local SEZ. Without protected authentication and data transfer, the remote SEZ is subject to attacks from client software. Further, performance limitations may preclude some applications due to the bandwidth limitations.
Secure Execution Zone Interfaces. All SEZs need a bidirectional set of interfaces to interact with the entities outside the SEZ in order to receive workloads, deliver results, and use services that are not available inside the SEZ. The design of these interfaces is one of the most challenging aspects of SEZ design. An SEZ has to provide a proof of execution to the requestor. Ideally an SEZ will communicate directly with some other trusted entity such as another SEZ or a trusted hardware device. If the requestor runs in an unprotected environment, generally in the host OS, then the ability of the requestor to validate the proof of execution before trusting the results of the execution is very limited.
Therefore, each SEZ needs an off-platform entity to be able to validate the proof of execution provided by the SEZ. Since servers running in data centers are considered to be more trustworthy by virtue of strict physical and digital access control, they offer the appropriate environment needed for this verification. Consequently, the platform has to be provisioned with a secret that is only usable by an SEZ and possession of which can be validated by a remote entity (attestation). Alternatively, an SEZ can control the resources on a platform, and the ability of an agent to access a certain resource on the platform is proof of the fact that it is running inside an SEZ. For example, if the SEZ controls a network interface device (NID) and a remote entity receives a packet from the NID, the remote entity automatically assumes that the packet has been either sent by an agent running in the SEZ or by its delegate.
Provisioning and Attestation
As shown in Figure 5, an SEZ needs a mechanism for provisioning a secret into the SEZ and a mechanism for proving the possession of a secret to an off-platform verifier (attestation). Provisioning and attestation  are two tightly-bound problems. Remote provisioning needs a platform to report its identity to its membership in a group before it can receive a secret. As a result, the platform has to be provisioned with a root secret during the time of manufacture, assembly, or by a trusted entity that has physical possession of the platform.
The root secret provisioned in the platform is likely to get compromised in the field. The compromised root secret of one instance of a platform should not reveal the root secret of another instance: it should not lead to a break once run anywhere (BORE) attack.
SEZs protect critical applications from various attacks. The selection of an SEZ is dependent on a number of factors including the threat protection requirement, the type of execution environment, and the resources available to the application.
 B. Lampson, M. Abadi, M. Burrows and E. Wobber. "Authentication in Distributed Systems: Theory and Practice." ACM Transactions on Computer Systems, page 6, 1992.
 "Unified Extensible Firmware Interface (UEFI)." At http://www.uefi.org/home
 Ravi Sahita and Uday Savagaonkar. "Towards Virtualization-based Framework for Information Traceability." In Insider Attack and Cyber Security: Beyond the Hacker. Springer Book Company, USA, pages 113-132, August 2008.
 Ravi Sahita, Uday Savagaonkar, Prashant Dewan, and David Durham. "Mitigating Lying Endpoint Problem in Virtualized Network Access Frameworks." Lecture Notes in Computer Science: Managing Virtualization of Networks and Services, Volume 4785/2007, Springer Book Company, Berlin, Germany, pages 135-146, September 2007.
 Ravi Sahita, Ulhas Warrier, and Prashant Dewan. "Protecting Critical Applications on Mobile Platforms." Intel Technology Journal, Volume 13, Issue 1, 2009.
 David Grawrock. "Dynamics Of A Trusted Platform: A Building Block Approach."
 At http://www-03.ibm.com/
 US Patent 6990579. "Platform and method for remote attestation of a platform." Inventors: Howard C. Herbert, David W. Grawrock, Carl M. Ellison, Roger A. Golliver, Derrick C. Lin, Francis X. McKeen, Gilbert Neiger, Ken Reneris, James A. Sutton, Shreekant S. Thakkar, and Millind Mittal. Assignee: Intel Corporation.
The authors thank Joe Cihula and David Grawrock for their feedback and input in preparing this article.
This article and more on similar subjects may be found in the Intel Technology Journal, June 2009 Edition, "Advances in Internet Security".