AMD Platform for Trustworthy Computing
Abstract
This paper provides information about AMD’s Platform for Trustworthy Computing, and the evolution of the PC platform to support for trustworthy computing. This evolution affects the platform hardware components, platform software and firmware and also affects the operating system (OS). OS Changes in support of trustworthy computing are outside the scope of this paper, but the interaction of the platform with external systems is discussed. The paper provides a call to action to component vendors, OEMs, integrators and infrastructure providers.
Contents
Introduction ..................................................................................................................................................... 3 Motivation and Constraints ............................................................................................................................ 3 Privacy ...................................................................................................................................................... 3 Protecting Personal Data .................................................................................................................... 3 Protecting Platform Identity ................................................................................................................ 4 Security ..................................................................................................................................................... 4 Security Improvement Clearly Needed .............................................................................................. 4 The Open Nature of the PC Platform ................................................................................................. 5 Backwards Compatibility..................................................................................................................... 5 Balanced Cost vs. Benefit................................................................................................................... 5 Ownerships ............................................................................................................................................... 5 Commerce Depends on Rights Protection......................................................................................... 5 Lack of Third Party Trust .................................................................................................................... 5 Benefits of Increased Trust................................................................................................................. 6 The Stand-Alone SEM Platform .................................................................................................................... 7 Design Constraints ................................................................................................................................... 8 Threat Model ....................................................................................................................................... 8 Legacy Support ................................................................................................................................... 8 Open Architecture ............................................................................................................................... 8 Cost ..................................................................................................................................................... 9 Key Architectural Concepts ...................................................................................................................... 9 Memory Partitioning ............................................................................................................................ 9 Sealed Storage ................................................................................................................................... 9 Secure Initialization ........................................................................................................................... 10 Microprocessor Changes ....................................................................................................................... 11 SEM is a Hybrid Hardware and Software Solution .......................................................................... 11 Protected Applications ...................................................................................................................... 11 Security Kernel .................................................................................................................................. 11 Trusted Execution Mode ................................................................................................................... 11 Memory Partitioning .......................................................................................................................... 13 Other Protections .............................................................................................................................. 15 Interrupt Handling ............................................................................................................................. 15 Secure Initialization ........................................................................................................................... 17 TPM ......................................................................................................................................................... 18 The Networked SEM Platform ..................................................................................................................... 18 Issues Particular to Networked Trustworthy Processing....................................................................... 19 Determining the Trust Characteristics of Remote Systems ............................................................ 19 Privacy Protection and Machine Identification ................................................................................. 20 Liability Allocation ............................................................................................................................. 20 Call to Action and Resources ...................................................................................................................... 21
AMD Platform for Trustworthy Computing - 2
Windows Hardware Engineering Conference Author's Disclaimer and Copyright: © 2003 Advanced Micro Devices, Inc. All rights reserved. The contents of this document are provided in connection with Advanced Micro Devices, Inc. (“AMD”) products and technology. AMD makes no representations or warranties with respect to the accuracy or completeness of the contents of this publication and reserves the right to make changes to specifications and product and technology descriptions at any time without notice. No license, whether express, implied, arising by estoppel or otherwise, to any intellectual property rights is granted by this publication. AMD assumes no liability whatsoever, and disclaims any express or implied warranty, relating to its products including, but not limited to, the implied warranty of merchantability, fitness for a particular purpose, or infringement of any intellectual property right. WinHEC Sponsors’ Disclaimer: The contents of this document have not been authored or confirmed by Microsoft or the WinHEC conference co-sponsors (hereinafter “WinHEC Sponsors”). Accordingly, the information contained in this document does not necessarily represent the views of the WinHEC Sponsors and the WinHEC Sponsors cannot make any representation concerning its accuracy. THE WinHEC SPONSORS MAKE NO WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THIS INFORMATION. Microsoft, Windows, and Windows NT are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 3
Introduction
This paper provides information about AMD’s Platform for Trustworthy Computing, and the evolution of the PC platform to support for trustworthy computing. This evolution affects the platform hardware components, platform software and firmware and also affects the operating system (OS). OS changes in support of trustworthy computing are outside the scope of this paper, but the interaction of the platform with external systems is discussed. The paper provides a call to action to component vendors, OEMs, integrators, and infrastructure providers.
Motivation and Constraints
AMD sees three interrelated areas of end-user benefit as the driving force for evolving the PC platform toward increased trustworthiness: Privacy, Security, and Ownership. As a set they are referred to as PSO. Each of these areas is discussed in greater detail below. Addressing all of these areas results in an improved PC platform that delivers more value to users of the platform and that can host a broader set of applications.
Privacy
Privacy protection in the context of PC platforms and applications is a complex area with differing views as to exactly what is meant by this term. In this paper the term is used narrowly to cover two specific areas: the protection of personally identifiable information (PII) stored within the PC, and the protection of data that would identify the PC platform itself.
Protecting Personal Data
Security is a Prerequisite for Privacy
Data protection of any kind is not possible without adequate security. This applies equally to a file cabinet full of paper files and a hard disk full of electronic files. In both cases, the privacy of the data is dependant on the security system protecting the container. In the real world we use locks, cameras, and such to provide physical data protection. For the computer files, we use the electronic analogs of these physical security tools. Security is the most basic privacy protection and computer security the most basic PC platform privacy technology. A key goal of Trustworthy Computing is to increase privacy protections and thus the first goal is increased security.
Existing Systems are Vulnerable
The current PC Platform and mainstream operating systems provide limited security and remain vulnerable to a whole range of attacks (and thus expose users to the loss of their PII). Increasing the protections defending PII against common attacks is necessary.
Privacy and Security are in Tension
The best security systems depend on clearly identifying the individual granted access to whatever is being protected. The need of a security system to identify accurately individuals granted access creates a tension between security and privacy. At its root this tension is the availability of PII to the security system.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 4
Increased Security without compromising Privacy
Protecting personal data thus requires both increased security and a security system that is designed to minimize or eliminate the PII used by the security system. Where the security system does utilize PII, it must be protected against improper disclosure.
Protecting Platform Identity
The Connected Trustworthy PC
A PC Platform is rarely used in a stand-alone environment. Most PCs are connected either continually or occasionally to a network. The increased trustworthiness of the PC is of particular value in a connected environment. The greatest end-user benefit from trustworthy computing arises when remote content and service providers can determine the characteristics and capabilities of a trustworthy PC.
Secure Remote Attestation
Determining with high confidence, integrity, and confidentiality, the characteristics of remote systems requires using cryptographic techniques. (The constraints on this process will be discussed later in this paper.)
Hardware Protection for Platform-Specific Data
It is an essential privacy requirement that any digital certificate, cryptographic key, or other platform-specific data used for secure remote attestation be protected at the hardware level.
The Platform Owner Controls Platform Specific Data
The platform owner must remain in complete control of any platform-specific data. The owner must be able to determine with whom, and under what circumstances, any such data is used. The platform owner must be empowered to completely block the use of such data. Such absolute on/off control, while required, may not be optimal, and the platform should provide a means for the platform owner to exert more “fine grained” control over the use of platform-specific data. This control should include the ability to delegate control to software processes trusted by the owner to manage the use of the platform-specific data in a manner consistent with policies set by the owner.
Security
Increasing the security of the PC platform enhances the value of the platform and expands the number of applications for which the PC is suited. Increasing platform security provides an improved execution environment for critical applications and is also the primary means to improve the PC’s ability to protect PII.
Security Improvement Clearly Needed
Security experts agree that existing systems are far too vulnerable to attacks. The popular and trade press are continually filled with articles that describe new vulnerabilities and attacks. No operating system or application suite is immune to such attacks. The losses incurred by PC users as a consequence of the current state of PC platform security are significant and growing.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 5
Responding to the need for increased security, many providers of PC platform technology have increased their spending on security-related technology. Notable among these is Microsoft Corporation, whose Trustworthy Computing Initiative has been well publicized. The architectural advances described below complement this and other similar efforts.
The Open Nature of the PC Platform
The open nature of the PC platform allows anyone to develop applications or hardware for the PC. Historically, this openness contributed directly to the success of the PC platform. While clearly of benefit, this very openness greatly complicates efforts to increase the security of the PC platform. Securing closed systems is relatively straightforward. Increasing the security of the PC without closing the platform was a constraint that influenced the architectural evolution described in this paper.
Backwards Compatibility
In addition to maintaining the openness of the PC platform an essential constraint that influenced the architecture described below was the need to preserve the industry investment in hardware and software. A great deal of the value of the PC platform comes from the availability of compatible hardware and software. The architectural evolution described here remains fully compatible with existing hardware and software and at the same time provides the opportunity for new applications and hardware to be developed that leverage the enhanced capabilities of the platform.
Balanced Cost vs. Benefit
Cost constraints govern all engineering activities. Evolving the PC to increase the trustworthiness of the platform and at the same time minimizing any cost increase was a key goal and requirement. The architectural changes described below enable a significant increase in platform security while keeping cost increases to a minimum.
Ownerships
A more trustworthy PC platform provides increased security and data protection for the platform owner. It can also provide this increased level of data protection for third parties who provide applications and data to the enhanced platform, and who use the PC platform as a vehicle for delivery of digital goods and services.
Commerce Depends on Rights Protection
In any market place a respect for property rights is essential. Without basic protections for both the buyer and seller, commerce comes to a halt. Moving the discussion to an e-commerce market place with digital goods and services does not change basic economic truths.
Lack of Third Party Trust
Historically the PC platform has not provided an environment friendly to commerce. PC platforms have generally not been “trusted” by remote parties to protect their interests, and in general have not been effective at providing basic protections. Markets are fluid and dynamic and react to the environment. In the case of PCs the market has reacted from the beginning to the PC’s lack of basic protections for remote third parties in a number of ways:
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 6
Refusal to Sell
Some content and services providers have simply refused to offer their goods for sale on or through the PC platform. This has resulted in a decrease in the value of the PC and a market opportunity for other more trustworthy platforms.
Hardware and Software Add-ons
Some content and service providers have developed software and hardware add-on solutions to overcome the inherent lack of trust in the in the PC platform. Some of these solutions have proven adequate from a security perspective, and others, most notably the DVD Copy protection system, have not. These add-on solutions are proprietary, closed systems, and they have not enabled open, multi-vendor, trustworthy commerce on the PC Platform.
Relocation of the Market to Servers
The vast majority of e-commerce that takes place involves purchasing physical goods from Internet providers. The actual transactions generally take place either on the web servers that support this market, or on proprietary back-end financial services networks. The PC’s role in most e-commerce is not significantly different from that of a dumb terminal.
Adjustment of Sales Price for Piracy
Where the goods purchased on the Internet are digital and instant delivery is available the sales price reflects the typically high rates of piracy that occur postsale. This same adjustment applies to many other digital goods purchased through all channels where the piracy rates are pre-factored into the sales price.
Benefits of Increased Trust
Increasing the trustworthiness of the PC platform will yield a number of benefits and expand the range of applications that can be reasonably run on the PC. In specific regard to e-commerce, the benefits will include:
Expanded Availability of Content
As the PC evolves into a trustworthy platform for e-commerce, the extent and quality of services and content delivered through the PC will grow. This will translate into increased value for the PC platform.
Lower Cost Content
The current market for digital goods and services that are delivered to the PC has been distorted by the lack of trust inherent in the existing PC platform. The sales price of many digital goods is inflated to compensate the seller for the high rates of piracy. Consequently, those individuals and businesses that acquire legitimate licenses for these products end up paying for those that acquire the products illegally. The same market distortion applies in other commerce systems such as the credit card system where the legitimate participants pay in aggregate for the fraud that occurs. In the arena of digital goods the piracy rates are higher and thus the price distortions are greater.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 7
As the market becomes more distorted, the incentive for individuals to behave in an ethical and legal manner is decreased, leading to a further increase in fraud or piracy. An evolved PC platform that provides the technical foundation for e-commerce systems that respect third party property rights will lead to a reduction in the “market distortion factor” and this will translate to lower costs for legitimate purchasers. Some individuals and companies that have become accustomed to a free ride will resist this change. Such resistance should be anticipated and addressed (at least in part by fair pricing), but since it is based on a false premise that users have a “right to steal”, this resistance should be confronted and overcome.
New Opportunities for Peer to Peer Transactions
Beyond the improvements in availability of high quality content and the reduction in the cost of digital goods, trustworthy computing should also enable a new level of peer-to-peer interaction that is based on mutual trustworthiness. Predicting how this will develop on the other side of the “inflection point” is difficult, but some speculation is warranted. Consider the following possibilities: A commerce environment where peer-to-peer payments can occur directly from one PC to another over the Internet without the need for a trusted third party. Secure gaming.
WEB Services Security Support
WEB services standards and the broad use of XML-based data exchange enables a whole range of new services for end users. Many of these new services will involve transactions between a service provider and a person’s (or company’s) persistent on-line digital data. The existence of this on-line data raises significant new security and privacy concerns at both the server and client endpoints. At the server endpoint, data will be vulnerable unless adequately protected. Servers employing trusted capabilities are better suited to provide this protection. At the client endpoint, and at the interface between the client and server, increased confidence in the user-authentication process is required. As more personal and company data is maintained on-line, the accurate determination of who is actually in control of the data becomes a gating issue for deployment of the services. Trustworthy platforms have the potential to play a critical role in strengthening this authentication process.
The Stand-Alone SEM Platform
This section begins the detailed description of the SEM Platform architecture. This description begins with the description of the architecture as it applies to a standalone platform. The next section addresses the issues of how trustworthy processing and network (particularly Internet) connectivity is addressed.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 8
Design Constraints
All architectures are the result of compromises between what the designers would like to accomplish and the real world constraints that can’t be avoided. The SEM platform architecture has been significantly affected by the constraints discussed in this section.
Threat Model
Any security solution must be developed with some form of threat model in mind. The SEM architecture was developed with a primary requirement to overcome software-based attacks, including software attacks mounted by the local operator of the system and those mounted via the network. Additionally, the architecture was developed with the objective that no reliance on “security through obscurity” would be needed. This constraint enables open disclosure of the architecture (as is being done here) without comprising the security of the solution. The SEM architecture has a secondary goal (as opposed to a requirement) to maintain its protections in the face of low-cost unsophisticated hardware attacks. Developing a solution that meets the certification criteria for “Tamper Resistant” trusted hardware is explicitly not a goal. AMD recognizes the value of such certifications, but to achieve this as a goal is not possible given the cost constraints on the architecture. The SEM architecture did not attempt by itself to address Denial of Service attacks. Such attacks are still capable of preventing execution of applications or the OS. These attacks, however, will not result in incorrect operation of protected applications, or in the exposure of protected data.
Legacy Support
The SEM architecture has been developed with a hard requirement to preserve the investment of the industry in OS and application software. While this constraint made achieving security goals more difficult, it is clearly an essential element in a viable architecture. The SEM architecture enables existing applications and all but the most OS poorly written device drivers to execute without modification. The architecture preserves investments in Operating System design. The architecture does require the development of new OS components. System performance will benefit from a base operating system that is modified to be SEM aware, but this is not an architectural requirement.
Open Architecture
Open Software Development Model
The SEM architecture is also constrained by the requirement to support an open application development model. There are no architectural reasons that preclude any developer from producing applications that can take advantage of the SEM platform capabilities. Such applications are not more privileged than existing applications, and thus require no third party (or even self) security certifications.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 9
Open Hardware Development Model
Under the SEM architecture, the PC platform remains open to third party add-in hardware from all vendors. The architecture does require changes to some platform components and the addition of a new component. Aside from the components that implement parts of the SEM architecture, all other add-in components will continue to be useable in a SEM-enhanced platform.
Cost
Without question, cost has been an overriding constraint on the architecture.
Key Architectural Concepts
Memory Partitioning
At the core of the SEM architecture is the concept of memory partitioning. The primary objective of the architecture is to enable a new class of applications that can execute in a memory space that is protected against software attack by other applications, device drivers, worms, viruses, Trojans, and the main OS. Protected Applications are not themselves “Trusted”, but because they execute in a protected memory partition, they can be expected to execute as designed in the face of software-based attacks. Protected Applications are not more privileged than other applications and thus from an architectural perspective need no pre-certification. The platform makes no determination as to which applications are “trustworthy”, rather the SEM architecture enables the platform users or application authors to have more confidence that such applications execute as intended by the author.
Sealed Storage
Sealed storage is new capability of the PC platforms that was first published and specified in specifications adopted by the Trusted Computing Group. Sealed Storage has value independent of the platform’s SEM capabilities, but when combined with SEM-enabled protected processing, secure storage adds significant value and is essential to full utilization of the Protected Applications. The Sealed Storage capability allows data to be bound to a particular processing environment. The processing environment is reflected in Platform Configuration Registers. When the specific environment is in effect or active, the data bound or “sealed” to that environment can be retrieved. When the environment to which the data is sealed is not active, the data remains sealed and can not be retrieved. An example is useful: Consider an enhanced personal banking application that makes use of a cryptographic key to authenticate transactions. This key can be sealed to a Platform Configuration that is judged (by the bank) to be the correct environment for the operation of the application. The banking application itself could be executed in a number of different environments, but the key would only be accessible to the application when the actual environment matches that chosen by the bank. The use of the sealed storage facility in tandem with a protected partitioned memory space for execution adds greatly to the overall value of the SEM architecture. Together, the capabilities allow for applications to execute in a more reliable manner and to protect their state-data (including secrets) when the protected environment is not in place.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 10
Secure Initialization
All trusted environments suffer from a “chicken and egg” initialization problem. Once a trusted environment is set up it can protect itself against attacks, but the same protections cannot be relied on to protect the setup process. This initialization problem has been solved in a variety of ways in previous architectures:
Secure Facility Pre-Load
One solution depends on the use of secure, audited facilities where initial setup is performed. This setup is then “locked down” so that it cannot be changed. Smart Cards, for example, are often initialized in such facilities, and are distributed to users pre-configured with fixed, factory setup applications and keys already installed.
Fixed Secure Loader
A variation on this theme used by some devices is to install in such a facility a small “secure loader” that is locked down. This loader is generally provided with factory installed cryptographic keys that allow it to validate external code before loading. This approach has more flexibility than complete pre-loading, but also creates logistical and policy problems. For example, in such a system, which party controls the keys used to authenticate valid modules for later loading? This post-sale control of the devices is acceptable in many markets where the “ownership” of the device remains with the issuing authority. This post-sale control is more problematic in the PC space where the consumer purchases the device.
Secure Log
Another design for secure initialization was incorporated into the Trusted Processing Module (TPM) specification. This specification describes the concept of using a “Root of Trust for Measurement” and a “secure log” to capture all events that affect security from the Power On Reset (POR) forward. This approach allows any software to be loaded (trusted or otherwise) and to execute, but enables an interested party to examine the log of what was actually loaded, validate this log, and thus determine if all the desired software was loaded, and that no undesirable software was loaded. This approach offered a great deal of flexibility, but it suffers from some weaknesses: The “Root of Trust for Measurement”, and thus the basis for trusting the log must still be reliably pre-installed. In the TCG specifications, this root of trust is the BIOS software, and thus the scheme is vulnerable to attacks that change BIOS contents. The actual log produced during the start-up process can become long. It may be difficult for an interested party to arrive at security conclusions about the system simply by knowing what software has been executed, when such software may not have been evaluated for its security properties. The logging operation can be considered to be a chain of connected measurements. Each link in the chain records the characteristics of the next link in the chain. If any link in the chain fails to check the following link, the state of the platform can no longer be determined by examining the log.
SEM Hardware-Assisted Secure Initialization
The SEM Architecture builds on the Secure Log approach, and adds hardware support to eliminate the limitations of that approach.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 11
The SEM platform’s hardware assist also provides the means to enable transition to and from normal operation into operation with increased trustworthiness at any time after system startup. The details of this hardware support and the SEM-enabled secure initialization process are described below.
Microprocessor Changes
Central to the SEM Architecture are a number of extensions to the x86 microprocessor micro-architecture and instruction set. Collectively, these extensions to the x86 architecture enable a new application class, Protected Applications, and a new Operating System object, the Security Kernel.
SEM is a Hybrid Hardware and Software Solution
The SEM architecture relies on both the hardware micro-architecture changes and on the correct operation of the Security Kernel to provide the protected environment for applications.
Protected Applications
Protected applications execute in a partitioned memory space that is isolated from the legacy application memory space and the legacy OS memory space.
Security Kernel
A new OS object, the Security Kernel (SK) also operates in the partitioned memory. The SK administers Protected Applications, and is responsible for defining and maintaining the partition between both the legacy applications and OS on one side of the partition, and the Protected Applications and SK on the other side of the partition. The size, complexity, function, and behavior of any specific SK are outside the scope of this document, but some constraints applicable to all SKs are worth noting:
Security Evaluation
While any SK may be functional, only those SKs that have been subject to some form of security evaluation are of real interest. Protected Application developers will look to such evaluations as they decide if the new protected application environment delivers an adequate level of security for their particular needs.
Size and Complexity
The size and complexity of a given SK will directly impact the level of effort needed to perform a security evaluation of the SK, and will also directly effect the ability of software engineers to provide an SK free from bugs that could also be security vulnerabilities. Small, simple SKs will be relatively easy to design, fully test, debug, and evaluate. Large and complex SKs may be impossible to fully test, debug, and evaluate given constrained resources.
Trusted Execution Mode
SEM provides a new CPU state bit (TX Mode bit) that discriminates between operation in the legacy memory partition (TX=0), and operation in the new protected memory partition (TX=1). The TX Mode bit operates orthogonally to the existing x86
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 12
protection mechanisms, and operates alongside these mechanisms. Most commercial operating systems in use today utilize only the user/supervisor (ring3/ring-0) protections, and thus separate all code into two classes. The addition of the TX mode bit provides an additional parallel operating mode that also supports both User and Supervisor modes. This is illustrated in the following diagram.
TX=0
TX=1
Ring-3 User-Mode
Legacy Applications
Protected Applications
Ring-0 SupervisorMode
Device Drivers OS Kernel
Security Kernel
SEM Memory Partition The TX mode bit is set or cleared as the processor executes restricted control transfers between the memory partitions.
SMCALL Transition
A new transfer instruction (SMCALL) is the only explicit instruction that allows transition between the memory partitions. The SMCALL instruction behavior is analogous to the behavior of the SYSCALL instruction: The SMCALL target is taken from internal protected CPU Registers. The target of the instruction will be a Security Kernel entry point defined by the Security Kernel. The SMCALL instruction is privileged and can only be executed by ring-0 (supervisor mode) code. There is no mechanism provided for explicit transition to the Security Kernel from ring-3 (user mode) code. The SMCALL instruction automatically switches from the legacy memory partition to the protected memory partition. The SMCALL instruction switches the TX mode bit from TX=0 to TX=1. The SMCALL instruction also clears the new Global Interrupt Flag (described later).
SMRET Transition
A new transfer instruction (SMRET) reverses the actions of the SMCALL instruction described above. This mechanism is the only means for switching from TX=1 to TX=0.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 13
Security Exception Transition
In addition to the above SMCALL/SMRET programmed transitions, the SEM architecture includes a new Security Exception mechanism. The Security Exception mechanism uses the same SK entry point as the SMCALL instruction. An error code indicates the cause of the Security Exception and allows the exception to be discriminated from the SMCALL. The SMRET instruction is used for return from either an SMCALL or from a Security Exception. The importance of the Security Exception in the SEM architecture cannot be overstated. The Security Exception is triggered whenever code executing with TX=0 attempts to perform any operation that could possibly compromise SEM protections. This forced transition to the SK enables the SK to intercept all such actions. The SK can then determine if the action poses a security risk and the appropriate action to be taken.
Memory Partitioning
The SEM architecture provides hardware support that works in concert with the SK to establish and maintain a partition between the memory space accessible to the legacy applications and OS (TX=0), and the memory space accessible to protected applications and the SK (TX=1).
Paged Virtual Memory
The SEM architecture extends the existing x86 hardware support for paged virtual memory to provide a mechanism for memory partitioning. Existing hardware provides support for multiple separate virtual address spaces. Much of the code in existing Operating Systems is devoted to managing the data structures that define these virtual address spaces. The Basic Premise for SEM The basic premise of the SEM architecture is that the software that controls the data structures that define virtual memory translations, controls what memory is accessible to applications. SK Control of Page Tables In the SEM architecture, the SK is given the ultimate control over the virtual memory translation data structures (page tables, and page directories.) This control enables the SK to determine what physical memory is accessible to the legacy OS and applications and what physical memory is accessible to the SK and Protected Applications. CR3 Load Trapping In the x86 architecture Control Register 3 (CR3) contains the address of the root virtual memory translation tables. By changing only the contents of CR3, operating systems switch rapidly from one set of virtual to physical translations to another set of translations. In the SEM architecture, changes to the content of CR3 will result in a Security Exception if TX=0, unless the specific value loaded has been “pre-approved” by the SK. This mechanism prevents TX=0 code from changing the contents of CR3 to unapproved values.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 14
The process the SK uses to “approve” a particular set of virtual to physical mappings is beyond the scope of this paper, but at a minimum, such “approved” translation maps must not contain any translations that would allow access to memory reserved for TX=1 operation. CR4 and MSR Protections In the processor, there are a number of architectural, and model specific registers that influence the operation of the virtual to physical translations. An example of this class of registers is Control Register 4 (CR4). CR4 contains various bits that enable virtual memory operation and determine the layout of the data structures that are used in the translation. In the SEM architecture, changes to CR4 or any other control, or model specific registers that affect the virtual to physical transition by code executing with TX=0 will trigger a Security Exception. This prevents TX=0 code from making changes to the processor configuration that would allow a bypass of the memory partition. Page Table Write Trapping The page table data structures that make up a particular virtual address map must be protected against unauthorized modification. Without protection, TX=0 code could change the contents of the tables and establish new mappings, including mappings that target memory reserved for TX=1 applications or the SK. For proper operation, these data structures must be readable by code executing at TX=0. The SEM architecture allows for the page structures to be readable to the TX=0 code, but writes to these page tables result in a Security Exception that invokes the Security Kernel. This prevents code executing at TX=0 from establishing new virtual to physical mappings not permitted by the SK.
Non-Paged Memory
During normal OS operation, there are events that cause paging to be disabled. The most common such event is the System Management Interrupt (SMI), which causes the processor to transition into System Management Mode (SMM). This transition can be triggered by a number of external or internal system events. With paging disabled, the memory partition mechanism using the virtual memory system is not operational, and thus the potential for a compromise of the memory partition arises. The straightforward solution to this problem would be to disallow SMI and SMM operation when the SEM protections are in effect. This would have a negative effect on OEMs and others that rely on SMM to perform platform specific functions. The SEM architecture fully enables SMM operation without compromising the memory partition by providing an alternate memory protection mechanism during non-paged operation. The SEM architecture uses a new hardware visible data structure called the Device Exclusion Vector (DEV) to identify pages of memory that are not accessible to TX=0 code when operating in non-paged mode.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 15
Other Protections
Protection Against Bus-Masters
The SEM architecture also protects memory regions defined by the SK against modification by other bus-mastering devices in the system. The SK defines the list of pages to be protected via entries made in the Device Exclusion Vector (DEV). The DEV is also used during non-paged operation as described above. Memory cycles originating from bus-master devices that target protected memory are blocked.
I/O Protection
The SEM architecture also provides a means for the SK to gate access by any code executing at TX=0 to specific I/O ports. The SK defines the list of I/O ports to be protected via entries made in the Global IO Protection Bitmap, a new hardwarevisible data structure. Attempts to access protected I/O ports by code with TX=0 trigger a Security Exception. The SK can then determine the correct response to the I/O request. This mechanism provides the SK with the hardware support needed to virtualize accesses to any I/O device by TX=0 code.
MSR Protection
Later generation complex microprocessors utilize a number of Model Specific Registers (MSR). These registers provide a means for control of micro-architectural features of the processor, and improper settings in these registers could compromise SEM protections. The SEM architecture provides a mechanism to prevent unauthorized modification of the MSRs by TX=0 code. The SK defines which MSRs are protected via entries made in a new MSR protection data structure. Attempts to access protected MSRs by TX=0 code trigger a Security Exception.
Miscellaneous Protections
The SEM architecture also contains a variety of miscellaneous protections. These protections address specific identified vulnerabilities and common attacks.
Interrupt Handling
Interrupt handling under the SEM architecture remains largely unaffected by the addition of the TX mode flag, but there are some minor differences.
Separate IDTs
Code on each side of the memory partition must maintain its own set of Interrupt Descriptor Tables. Interrupts that occur when TX=0 operate normally, and use the TX=0 IDT, which will vector to a TX=0 Interrupt service routine (ISR). Normal interrupts that occur during TX=1 operation use the TX=1 IDT and vector to a TX=1 ISR.
No Automatic TX Mode Transition
Since the TX=0 code and the TX=1 code utilize different virtual address maps interrupts that occur in TX=1 code must be handled by a TX=1 Interrupt Service Routine. Similarly, interrupts that occur in TX=0 code must use a TX=0 ISR.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 16
Interrupts (except notably the Security Exception) do not perform automatic transition between TX modes.
Interrupts and Mode Transition
The SMCALL instruction and the Security Exception do not automatically perform all steps necessary to completely setup the CPU state for TX=1 operation. The control transfers perform the minimum number of steps needed to effect the actual mode transition and to enable “transition” code to be invoked. This transition code is responsible for ensuring that all needed CPU state is setup for operation in TX=1. To enable interrupts, the transition code must swap from the TX=0 IDT to the TX=1 IDT by switching the contents of the IDTR. The transition code must execute as an atomic sequence of instructions. To ensure that no interruptions of this code occur, a new Global Interrupt Flag is provided in the SEM architecture. Global Interrupt Flag The x86 architecture provides an Interrupt Flag that masks most (but not all) interrupts. NMI, SMI, and Machine Check are examples of interrupts not masked by the Interrupt flag, and exceptions are not masked. To ensure the transition code can operate atomically the Global Interrupt Flag (GIF) is provided. When set, the GIF blocks ALL interrupts and ALL exceptions. Two new instructions (STGI, and CLGI) are provided to enable software control over the GIF. The SMCALL instruction and the Security Exception both set the GIF. The transition code must reset the GIF as it concludes to enable interrupt processing by TX=1 code. TX=1 to TX = 0 Transition Transitions back to TX=0 code following a SMCALL or Security Exception must also use transition code. This code reverses the actions performed on entry to the TX=1 code. The GIF must be set using the STGI instruction to ensure this transition code executes atomically. The SMRET instruction will clear the GIF as it executes, enabling normal interrupt operation to resume.
Special TX=1 Interrupt Handing
While operating in TX=1, uncontrolled transitions to TX=0 code must be prevented. To ensure that such a transition does not occur, the normal processor behavior of the System Management Interrupt is modified if TX=1. System Management Interrupt When the TX=0, the SMI interrupt response is the same as on existing systems. While the GIF is set, the SMI is masked, but held pending and will be recognized once the GIF is cleared. When TX=1 the SMI interrupt generates a normal interrupt with a pre-defined interrupt number. The SMI is held pending. When signaled via this interrupt that an SMI is pending, the expectation is that TX=1 code will safely transition back to TX=0. As soon as the processor changes stated back to TX=0, the SMI is recognized and normal SMI actions will take place.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 17
Secure Initialization
The SEM architecture provides direct hardware support for the secure initialization process.
SKINIT Instruction
The cornerstone of the SEM extensions to support secure initialization is a new instruction SKINIT. This instruction performs a series of operations and data transfers that cannot otherwise be duplicated using normal code, and cannot be emulated in software. The SKINIT instruction begins its operation in a software environment that does not include an operational Security Kernel. The SKINIT instruction is designed to operate reliably in the face of software attacks that attempt to subvert the Secure Initialization Process. The SKINIT instruction is the root of trust for subsequent operation. SKINIT Security Objective The security objective of the SKINIT instruction is to establish a starting point for trusted operation. More specifically, the SKINIT establishes a known execution environment, and then executes within this environment a known software object. These two conditions establish the root of trust for the protected application environment enabled by the SEM architecture. In actual operation, no attempt is made by the hardware to determine a priority if the software object to be executed in the known environment is indeed a “known” or “trusted” software object. Instead, the SKINIT allows this evaluation to take place after the fact, securely, regardless of the characteristics of the actual software object. The SKINIT instruction could be used to load an untrustworthy software object, but the object will not be able to masquerade as a known and “trustworthy software object”. The “Sealed Storage” capability described above will ensure that no “secrets” intended for use only in a trusted environment are available if the trustworthy environment is not properly setup. The “after the fact” analysis is key to ensuring that the platform remains completely open, and prevents the need for installation of “trusted software” in the a secure manufacturing faculty. The SKINIT instruction does not depend on any software installed pre-installed in the platform (including BIOS) to ensure correct operation. SKINIT Operation The basic functions of the SKINIT instruction operate atomically are described below. Establish Known Execution Environment The SKINIT operation begins by performing a series of internal steps to restore the processor to a “clean” state. These steps are a modified version of the steps performed during an “INIT” operation. This phase includes specific steps designed to ensure the integrity of the SKNIT instruction in the face of attack. Securely Record Software Characteristics The next step performed is to securely record the characteristics of the software that will be executed at the end of the SKINIT instruction.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 18
During this step, the processor securely transfers the image of the software object to the TPM component. The TPM component will record in internal storage the cryptographic HASH of the software object. That the transfer operation is protected by hardware means that this phase of the SKINIT cannot be emulated in software. Jump to Software The final step in the operation of the instruction is to begin execution within the software object.
Initial Software Object Functions
A detailed discussion of the behavior of the software object that will be executed by the SKINIT instruction is out of scope for this document. The basic tasks of this object, though, are obvious and include performing additional setup steps that lead to the establishment of the partitioned-memory operating environment with an initialized and functional Security Kernel.
SKINIT and Platform Configuration
The software object executed by the SKINIT instruction is the first software object in a short chain of trust. The cryptographic HASH of this object resides in the TPM as a consequence of the actions of the SKINIT instruction. The Security Kernel is the final object in this chain. The cryptographic HASH of all software objects in the chain leading from this first object up to and including the Security Kernel must also be recorded in the TPM. These HASH values recorded in the TPM provide the platform configuration data needed to enable the use of TPM provided Sealed Storage functions. This same platform configuration data is used as the bases of the remote attestation process described in the section on the networked SEM platform.
TPM
A key architectural element in the SEM platform is the inclusion of an enhanced Trusted Processing Module (TPM). The detailed behavior of first generation TPM devices is defined in the TPM Specification V1.1 adopted by the Trusted Computing Group (TCG). AMD is a member and promoter of the Trusted Computing Group. The TCG is currently developing the next revision of this specification. AMD anticipates that this revision will define the characteristics and behavior of TPM modules used in the AMD SEM Platform. TCG rules prevent public disclosure of draft specifications; consequently further details of the interaction between the SEM architecture and the enhanced TPM cannot be provided at this time. Parties interested in gaining access to draft specifications of the Trusted Computing Group, or in contributing to the development of such specifications, are encouraged to become members of the Trusted Computing Group.
The Networked SEM Platform
This section addresses the issues and challenges faced in using trustworthy processing in a connected environment, and (in some cases) describes how the
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 19
SEM platform addresses these issues. The focus of this section will be on using trustworthy computing in the more challenging Internet environment as opposed to the corporate environment for the following reasons: In the corporate environment there are external constraints on computer user behavior that are not present in the Internet. For example, a corporate user who attempts to break the security of trustworthy systems will typically be subject to termination. This is a serious deterrent. Corporations as opposed to users generally own the computer hardware. Privacy expectations are reduced in the corporate environment (at least in the United States). Consequently, the privacy issues that face trustworthy computing within the corporation are less of an issue than in the Internet environment. Corporations are in a position to impose a proprietary, closed, trust-infrastructure inside the enterprise to enable trusted computing. Internet infrastructure solutions must generally meet criteria not applicable inside the enterprise. Corporate users are less likely to engage in wide-open commerce using trustworthy computing. Corporations tend to do business with a relatively fixed and often pre-qualified vendor base. Solutions that address the more stringent requirements of the Internet can often be utilized in the enterprise; the reverse is often not true.
Issues Particular to Networked Trustworthy Processing
Determining the Trust Characteristics of Remote Systems
The first problem that must be solved before the trustworthy processing capabilities of a remote system can be used is determining what trustworthy capabilities actually exist within the system at the far end of the wire. The now famous cartoon of a dog at a computer with the caption “On the Internet, no one knows you are a dog” illustrates the problem. Solving this problem in the face of deliberate attempts by attackers to spoof the trusting party is not trivial. Cryptographic techniques can be used to solve this problem, and are used in the SEM platform for this purpose. Unfortunately, relying on cryptographic techniques to address the problem leads to a whole range of side effects and additional problems that must be solved.
Personalization
The schemes used for solving the remote attestation problem typically utilize public key cryptography. For lots of good reasons that are beyond the scope of this paper, the keys used in the remote attestation process should be unique. In other words, each platform should have its own unique key-pair. These keys are only useful if a platform specific endorsement certificate attesting to the validity of the keys is also provided. This requirement leads directly to the need to personalize the platform. In this context, personalization involves: installing the keys and generating the endorsement certificate. The issues and design choices associated with the personalization process are quite similar to the problem of secure initialization discussed above.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 20
The most common means to deal with personalization is to perform this step in a secure facility. This process leads to a logistical issue relating to how the certificate is transferred, as well as the potentially significant costs to PC OEMs. In the SEM platform architecture the TPM device is the only device that is personalized. These components can be personalized during manufacture before they are joined to the rest of the platform. Certificates can either be embedded into the TPM device, or they can be delivered via the Internet further eliminating the logistical impact that would follow if media containing the certificate needed to accompany the TPM through manufacture.
Privacy Protection and Machine Identification
The existence of unique keys and certificates within the TPM raises concerns that these unique values could be used as a form of platform identifier. The SEM platform includes specific hardware based protections to address these concerns: The first level of protection provided by the hardware is the ability to completely disable the TPM. The next level of protection is fine-grained control over the use of TPM commands that utilize data that could be used to identify the platform. The authentication and attestation protocols provide an additional level of protection. Data exchanges with remote parties use cryptographic techniques to obscure platform-specific data. Protection against the misuse of the authentication process as a means to identify platforms should be an integral design and operational requirement of the trustinfrastructure developed to support open networked trustworthy systems.
Liability Allocation
The problem of liability allocation is not strictly an issue for the networked use of trustworthy systems, but network usage more directly depends on a solution to this problem. Liability allocation addresses failures in the security model for a trustworthy system that leads to some form of financial loss. Liability allocation determines “who is left holding the bag”. Trustworthy systems will be compromised as a result of attacks that exceed the designed threat model, and possibly as a result of errors in design or implementation. Security systems are never perfect. The SEM Platform Architecture represents a quantum leap forward over the security of existing systems, but vulnerabilities remain, and will be exploited. Parties that rely on the security of SEM platforms must do so with the full knowledge that some platforms will be compromised. OS vendors, silicon providers, motherboard vendors, and OEMs cannot assume significant liability for the consequences of security failures. A system must be developed to ensure that consequential liability for security failures does not attach to suppliers of the trustworthy platforms. The trust-infrastructure provides a possible means to clearly allocate the consequential liability to the service or content provider. Such providers must make use of information about the platform in making content and service delivery decisions. The trust-infrastructure could be designed to obtain an indemnification
WinHEC 2003 Microsoft Windows Hardware Engineering Conference
AMD Platform for Trustworthy Computing - 21
against loss before providing information about a platform’s capabilities to a content or service provider. Other solutions to the problem of liability allocation are possible.
Call to Action and Resources
Call to Action:
For system manufacturers: Develop plans for how to market more Trustworthy Computing platforms, engage with AMD and others developing standards and solutions. For device manufacturers: Work with AMD and others to determine the specific impact of Trustworthy computing on the devices or components that you manufacture. For infrastructure providers: Engage now with AMD and others involved in defining the trust infrastructure that will be needed to support the networked use of Trustworthy computing.
Feedback:
To provide feedback about this document, and to begin working with AMD on trustworthy computing, please send e-mail to geoffrey.strongin@amd.com.
WinHEC 2003 Microsoft Windows Hardware Engineering Conference