Trusted (Computing) Platforms: An Overview - Pearson · 4 Chapter 1 • Trusted (Computing)...

3

C H A P T E R 1

Trusted (Computing) Platforms:An Overview

platform is any computing device—a PC, server, mobile phone, orany appliance capable of computing and communicating electroni-

cally with other platforms. In this chapter, you’ll discover the reasons whyTrusted Platforms—also called Trusted Computing Platforms—are beingdeveloped and read a summary of the technology and its evolution. Thechapter is intended to provide a wide audience with a standalone sum-mary of Trusted Platforms and their context. The conceptual and politicalframework have been included in this chapter for your convenience.Boxes will be used to highlight important summaries.

This first chapter covers the following points:

• A brief overview of what Trusted Platforms provide • Consideration of what “trust” means in terms of technology, in order to explain how the

technology described in this book can be said to provide “trusted platforms”• Assessment of the need for Trusted Platforms and why such platforms are important in

a business context• A summary of the main features of Trusted Platforms, including the protection of

users’ privacy• A look ahead to a world in which Trusted Platforms are ubiquitous

Note that this chapter provides motivation and context for the book, so those readers whoare familiar with the background to TCPA technology may wish to move on to Chapter 2.

A

ch01.fm Page 3 Wednesday, June 12, 2002 1:31 PM

Prentice Hall PTR

This is a sample chapter of Trusted Computing Platforms: TCPA Technology in Context ISBN: 0-13-009220-7 For the full text, visit http://www.phptr.com ©2002 Pearson Education. All Rights Reserved.

4 Chapter 1 • Trusted (Computing) Platforms: An Overview

Summary of Trusted Platform Concepts

Before assessing the nature and value of Trusted Platforms in more detail, we summarize theneed for Trusted Platforms, how this relates to the Trusted Computing Alliance and its specifica-tions, and the basic concepts behind Trusted Platform technology.

Why Are Trusted Platforms Being Developed?

Computer platforms are ubiquitous; they are central to the growing reliance on electronic busi-ness and commerce, and the need for information protection is increasing, particularly on clientplatforms. Although businesses have deployed Secure Operating Systems on servers (for exam-ple, [HP 2001]) and have physically protected individual server platforms, no overall corre-sponding improvement in client platforms has occurred because of the ad hoc way in whichclient platforms develop, the sheer number of them, and the cost.

The flexibility and openness of the PC platform has enabled phenomenal business growth,and attempts to prohibit that flexibility and openness have been met with resistance. Most users,given a choice between convenience and security, opt for convenience. This makes improvingconfidence in client platforms, and in particular PCs, a big challenge.

No single company dictates the architecture of all platforms on the network or the plan ofthe network itself. Although other types of platforms are increasingly being used for Internetaccess, the diversity of software and hardware available for PCs continues to mean that the prin-cipal client platforms of the Internet are still PC-based. As conventional businesses increasinglydepend on PCs and the Internet for their success—even their very existence—the trustworthi-ness of platforms and PCs is an increasingly vital issue. The development of e-services and theconvenience of using the same computer platform for both personal and business use mean thatusers increasingly need to store and use sensitive data on their platforms. Of course, they natu-rally expect their data to be protected from misuse even when they are connected to the Internet.

However, the ability to protect a PC or other computing platform through software alonehas developed as far as it can and has inherent weaknesses. The degree of confidence in soft-ware-only security solutions depends on their correct installation and execution, which can beaffected by other software that has been executed on the same platform. Even the most robustand tightly controlled software cannot vouch for its own integrity. For example, if malicioussoftware has bypassed the security mechanisms of an operating system (OS) and managed tocorrupt that OS’s behavior, it is by definition impossible to expect that the OS will necessarily beaware of this security breach. It is often possible to find out whether software has been modifiedwhen one knows what modification to look for (e.g., looking for a known virus). However, cur-rent computing platform technology does not allow a local or remote user to easily test whethera platform is suitable to process and store sensitive information. For example, currently it is pos-sible to identify an employee accessing a corporate network through a virtual private network(VPN) gateway, but it is impossible to establish with confidence whether the computing plat-form used by the employee is a corporate machine and whether it runs only the required soft-ware and configurations.


Summary of Trusted Platform Concepts 5

Experts in information security conclude that some security problems cannot be solved bysoftware alone, for example, trusted hardware is needed as the basis for software security mech-anisms such as those described by [Lampson et al., 1992], and even conventional Secure Operat-ing Systems depend on hardware features to enforce separation of user and supervisor modes.Furthermore, privacy issues have arisen, such as the conflict of duty between providing confi-dence in a computing platform’s behavior to the owner of a company PC and providing confi-dence in the platform’s behavior to the individual user of that PC. Also, differences existbetween providing confidence in a platform’s behavior to a local user and providing that confi-dence to a remote entity across a network.

The Trusted Computing Platform Alliance and the TCPA Specification

These issues, coupled with emerging e-business opportunities that demand higher levels of con-fidence, have led to the Trusted Computing Platform Alliance (TCPA) designing a specificationfor computing platforms that creates a foundation of trust for software processes, based on asmall amount of hardware within such platforms. A brief history of the Trusted Computing Plat-form Alliance (the organization set up to develop and standardize Trusted Platform technology),including its organizational structure and objectives, can be found in Appendix A.

The TCPA specification is intended for use in the real world of electronic commerce, elec-tronic business, and corporate infrastructure security. The specification is a mixture of informa-tive comment and normative statements (that give a list of all the things that must be done); thisbook attempts to provide more explanation than is given in the specification.

What Is a Trusted Platform?

A Trusted Platform (TP) is a computing platform that has a trusted component, probably in theform of built-in hardware, and uses this to create a foundation of trust for software processes.The computing platforms specified in the TCPA specification are one such type of Trusted Plat-form; although different types of Trusted Platforms could be built, we concentrate in particularon the instantiation specified by the TCPA industry standard. (Note that terms like Trusted Plat-form are italicized in this chapter because we are using them in a specific way.)

In this book, we concentrate on the issue of converting a platform into a Trusted Platform.The conversion process involves extra hardware roughly equivalent to that of a smart card, withsome enhancements.

At the time of this writing, secure operating systems use different levels of hardware priv-ilege to logically isolate programs and provide robust platform operation, including securityfunctions.

Converting a platform into a Trusted Platform requires that TCPA roots of trust be embeddedin the platform, which enable the platform to be trusted by both local and remote users. In particu-lar, cost-effective security hardware acts as a root of trust in Trusted Platforms. This security hard-ware contains those security functions that must be trusted. The hardware is a root of trust in aprocess that measures the platform’s software environment. (In fact, it could also measure the hard-ware environment, but it is the software environment that is important because knowing what the



computing engine is doing is the primary issue.) If the software environment is found to be trust-worthy enough for some particular purpose, all other security functions (and ordinary software)can operate as normal processes. These roots of trust are core TCPA capabilities.

Adding the full set of TCPA capabilities to a normal (non-secure) platform gives it someproperties similar to that of a secure computer with roots of trust. The resultant platform hasrobust security capabilities and robust methods of determining the state of the platform. (Amongother things, it can prevent access to sensitive data [or secrets] if the platform is not operating asexpected.) Adding TCPA technology to a platform does not change other aspects of platformrobustness, so a non-secure platform that is enhanced in the way described above is not a con-ventional secure computer and probably not as robust as a secure platform that is enhanced inthis way. Nevertheless, we (the authors of this book) claim that the architectural changes pro-posed in the TCPA specification are the cheapest way to enhance security in an ordinary (non-secure) computing platform. (The architectural cost of converting a secure platform into aTrusted Platform is even less, because it requires fewer TCPA functions.) We further contrasttrust and security mechanisms in the “Trust Versus Security” section later in this chapter.

Any type of computing platform (for example, a PC, server, Personal Digital Assistant orPDA, printer, or mobile phone) can be a TP. A TP is particularly useful as a connected and/orphysically mobile platform, because the need for stronger trust and confidence in computer plat-forms increases with connectivity and physical mobility. Not only are there threats associatedwith connecting to the Internet, such as the downloading of viruses, but physical mobilityincreases the risk of unauthorized access to the platform (including physical theft). TP technol-ogy provides mechanisms that are useful in both of these circumstances.

The first Trusted Platforms containing the new hardware are expected to be desktop or lap-top PCs. They will provide protection of secrets (i.e., keys that encrypt files and messages, keysthat sign data, and keys that contain authorization data) using access codes, binding of secrets toa particular physical platform, digital signing using those secrets, plus mechanisms and proto-cols to ensure that a platform has loaded its software properly. Later, TPs will provide moreadvanced features such as protection of secrets depending on the software that is loaded (i.e.,preventing a secret from being accessed if unknown software has been loaded on the platform,such as hacker scripts) and attestation identities for e-services. The technology is certain toevolve over the coming years.

Trusted Platforms are an unfamiliar concept, even to security specialists, but since therelease of TCPA specification v1.0 in February 2001 and its backing by major industry players,they are set to become widespread. The adoption of Trusted Platforms is a building block toimproving confidence in conducting business over the Internet and broadening the scope of e-services. TCPA technology allows existing applications to benefit from enhanced security andencourages the development of new applications or services that require higher or more ubiqui-tous security levels than presently available. (Some examples are presented in Chapter 2.) Appli-cations and services that would benefit from using Trusted Platforms include electronic cash,email, hot-desking (allowing mobile users to share a pool of computers), platform management,


Summary of Trusted Platform Concepts 7

single sign-on (removing the need for the user to be asked to authenticate himself or herself

more than once when using different applications during the same work session), virtual private

networks, Web access and digital content delivery.

The functions of the security hardware are relatively benign as far as product export/

import regulations are concerned, and all export/import contentious security functions are imple-

mented as security software (and can be changed as required for individual markets). Another

important TP property is that the functions of the security hardware operate on small amounts of

data, permitting acceptable levels of performance even though the hardware is low cost. In con-

trast, the normal platform processor is used by a TP’s security software to manipulate large

amounts of data and, hence, to take advantage of the excellent price-to-performance ratio of nor-

mal computer platforms.

Determining the integrity of a platform (trusting a platform) is a critical feature of a

Trusted Platform. Security mechanisms (i.e., processes or features) are used to provide the infor-

mation needed to deduce the level of trust in a platform. The decision itself can be made only by

the user who desires to use the platform, and this decision will change according to the intended

use of the platform, even if the platform remains unchanged. The user needs to rely on state-

ments by trusted individuals or organizations about the proper behavior of a platform. It is this

aspect that ultimately differentiates a Trusted Platform from a conventional secure computer.

Basic Concepts in the Trusted Platform Model

Figure 1–1 The overall Trusted Computing Platform model

CRTM

TCPA Specification

TSSSoftware

TrustedPlatform

(TP)

Specifies correctoperation

Certifies TP, TP Design,Identities, Components

CertificationAuthority

CA

Trusted Platform Subsystem =(Trusted Platform Module + Core Root of Trust for Measurement +

Trusted platform Support Service)

TPM



Figure 1-1 illustrates the general setup that we consider in this book. The Trusted Comput-ing Platform Alliance has published documents that specify how a Trusted Platform (TP) mustbe constructed. Within each Trusted Platform is a Trusted (Platform) Subsystem, which containsa Trusted Platform Module (TPM), a Core Root of Trust for Measurement (CRTM), and supportsoftware (the Trusted platform Support Service—TSS). The TPM is a hardware chip that is sep-arate from the main platform CPU(s). The CRTM is the first software to run during the boot pro-cess and is preferably physically located within the TPM, although this is not essential. The TSSperforms various functions, such as those necessary for communication with the rest of the plat-form and with other platforms. The TSS functions do not themselves need to be trustworthy, butthey are nevertheless required if the platform is to be trusted. In addition to the Trusted Sub-system in the physical Trusted Platform, Certification Authorities (CAs) are centrally involved inthe manufacture and usage of TPs in order to vouch that the TP is genuine.

Readers with a background in information security know that a Trusted Computing Base(TCB) is the set of functions that provide the security properties of a platform (in other words,that enforce the platform’s security policy). The TCB in a Trusted Platform is the combinationof the Trusted Subsystem (mainly dealing with secrets) and additional functions (mainly dealingwith the use of those secrets, such as bulk encryption). As such, the Trusted Subsystem is a sub-set of the functions of the TCB of conventional secure computers (which would normallyinclude both dealing with secrets and using secrets). Critically, however, the Trusted Subsystemcontains some functions not found in a conventional TCB. Conventional secure computers pro-vide formal evidence that a TCB in certain states actually can be trusted. This is done by meansof formal assessment and certification of the platform in a particular configuration. The accredi-tation shows that the platform can operate securely if it is operated in a particular way, but it issaid to be unusual for platforms to actually be operated in tested configurations! In contrast, theTrusted Subsystem provides a less formal means of showing that the TCB is both capable ofbeing trusted and actually can be trusted in a variety of configurations. The Trusted Subsystemfirst demonstrates that it can be trusted and then demonstrates that the remainder of the TCB ina Trusted Platform can also be trusted. This involves certification from trusted entities that areprepared to vouch for the platform in various configurations.

B a s i c D e f i n i t i o n s

PlatformA computing device, usually one that communicates with other such devicesTrusted Computing Platform Alliance (TCPA)The organization that has specified how to produce Trusted PlatformsTrusted (Computing) Platform (TP)A platform that creates a foundation of trust for software processesTrusted Platform Module (TPM)The hardware root of trust of a TP Trusted Platform Subsystem A set of capabilities inside a platform that are defined by TCPACertification Authority (CA)An organization that vouches for an entity (e.g., for a cryptographic key, hardware orsoftware component, platform, or organization)


Why Are Trusted Platforms ‘Trusted’? 9

Why Are Trusted Platforms ‘Trusted’?

This section attempts to give a succinct analysis of trust, including consideration of both behav-ioral and social components. (Further discussion of the nature of trust may be found in AppendixB.) This provides important context for explaining the sense in which TCPA provides trustmechanisms.

Trust: A Complex Notion

Pinning down the meanings of many words can be difficult. Trust is particularly tricky because itis not a simple notion. Typically, we think in terms of Entity A trusting Entity B for something,which is complex for the following reasons (among others):

Not always transitive: If A trusts B and B vouches for C, does A trust C in this case? Inother words, is trust a transitive notion? The answer is “not always,” although it can be underspecific circumstances.

Dynamic: Trust is dynamic rather than static; there can be differing phases in a relation-ship such as building trust, ongoing trust (a stable relationship), and declining trust. Trust can belost quickly, as noted by Nielsen: “[Trust] is hard to build and easy to lose: a single violation oftrust can destroy years of slowly accumulated credibility” [Nielsen 1999].

Varying degree and scope: Trust levels differ both in the sense of varying degree andscope of trust: Entities typically trust—or do not trust—each other to fulfill selected obligationsor for a particular purpose, rather than for everything. On the other hand, trust in certain areascan transfer to trust more generally, as shown by major brands having an advantage when mov-ing into new areas of business.

However, it is useful to have a succinct definition of trust if at all possible, particularly ifyou are claiming to provide an increased level of trust in something. Most dictionaries define (atleast one use of the word) trust in wording similar to the following: “a firm belief in the reliabil-ity or truth or strength, etc., of a person or thing.” However, this is not the end of the story. Todate, we have no universally accepted scholarly definition of trust, although “confident expecta-tions” and “a willingness to be vulnerable” are usually viewed as critical components. Evidencefrom a contemporary, cross-disciplinary collection of scholarly writing suggests that a widelyheld definition of trust is as follows: “Trust is a psychological state comprising the intention toaccept vulnerability based upon positive expectations of the intentions or behavior of another”[Rousseau et al. 1998]. Yet this definition does not fully capture the dynamic and varied subtle-ties considered above.

In general, we can conclude that it is difficult to define trust because there are differentfacets of trust. When “trust” is applied in an online business context, these facets include the fol-lowing:

• A technological basis that is mainly the concern of this book

• A contractual side that includes both laws and underwriting or contracts



• Customers’ image that is built up via previous interactions with a company, brandimage, publicity, etc.

In Appendix B, some of the major attempts to provide social theories of trust are consid-ered, as well as how such reasoning has been applied to the e-commerce domain. Such back-ground analysis supports further consideration in this section of the extent to which trust isincreased by using TCPA technology.

Different Approaches to Trust: Behavioral vs. Social Components

As noted, there are different aspects to trust. The TCPA definition of trust is that something istrusted “if it always behaves in the expected manner for the intended purpose.” A similarapproach is adopted in the third part of ISO/IEC 15408 standard: “A trusted component, opera-tion, or process is one whose behavior is predictable under almost any operating condition andwhich is highly resistant to subversion by application software, viruses, and a given level ofphysical interference” [ISO/IEC 15408].

We believe that categorizing trust in terms of behavioral (dynamic) and social (static)components helps in understanding how Trusted Platforms enhance trust.

• The special processes in a Trusted Platform dynamically collect evidence of behaviorand provide evidence of behavior. This information provides the means of knowingwhether a platform can be trusted.

• The social definition of trust concentrates on what it is to be trustable—capable ofbehaving properly, i.e., trustworthy in a social sense, when people agree that the trustedthing is good and fair and will do the right things. Social trust in a Trusted Platform isan expression of confidence in behavioral trust, because it is an assurance about theimplementation and operation of that Trusted Platform. Trusted Platforms use socialtrust to provide confidence in the mechanisms that collect and provide evidence ofbehavior; they also use social trust to provide confidence that particular values ofevidence represent a platform that is in a “good” state. This information thus providesthe means of knowing whether a platform should be trusted.

Clearly, both aspects of trust are necessary. Processes in a Trusted Platform provide informa-tion about the behavior of a platform, but that information cannot be trusted unless someonevouches for the method of providing the information and for the expected value of the information.

The Trust Mechanism Provided by TCPA

Trusted Platforms meet the need for increased confidence in platforms. This (social) confidencecomes from declarations by trusted third parties that the platform can be trusted for the intendedpurpose. These third parties are prepared to endorse a platform because they have assessed theplatform and are willing to state that if measurements of the integrity of that platform are such-


Why Are Trusted Platforms ‘Trusted’? 11

and-such, it can be trusted for such-and-such purposes. The local user and remote entities trustthe judgment of the third parties, so if the platform proves its identity and the measurementsmatch the expected measurements, they trust that the platform will behave in a trustworthy andpredictable manner.

For an entity to decide whether a computing platform can be trusted, TCPA specifies ameasurement method and a way for the measurement method to show itself to be trustworthy.The first Trusted Platforms have two roots of trust. One root of trust starts the measurement pro-cess and is called the Root of Trust for Measurement (RTM). The RTM is very much platform-dependent and can vary by type of platform. The other root of trust stores the results of the mea-surement processes as they happen, in such a way that measurements cannot be “undone.” Itcryptographically reports the current measured values and prevents the release of a secret if thecurrent measured values do not match the values stored with that secret. This root of trust is theRoot of Trust for Reporting (RTR), but the term is rarely used because the RTR is independent ofplatform type, and it is implemented as the Trusted Platform Module (TPM). We argue that theRTM and the TPM are the minimal roots of trust that you need. When any platform starts, youneed to form measurements about the way the platform is operating. It is necessary to have acore element that you absolutely trust and that you cannot avoid trusting. The Root of Trust forMeasurement must be a computing engine, in order to be able to make measurements and dosomething with those measurements. In a PC, the RTM is the entire computing platform itself. Itconsists of some code (inside the BIOS or the BIOS Boot Block in PCs) that starts a series ofmeasurements involving the processor, wiring that is laid down in the printed circuit board, andother components that form part of the computing engine. This code is both critical and essen-tial. The RTM makes the measurements and stores the answers in the TPM. Typically, this isinstantiated as a single tamper-resistant chip. What goes on inside the chip cannot be tamperedwith by the platform, by the user themselves, or by a third party. The TPM is something that istrusted by everyone: Everyone agrees to believe that if something says it comes from a TPM,then what it says can be believed.

Trusted and Trustable

How do we trust that these elements are operating in the correct manner—for example, that thecode is doing what it should? As far as the TPM is concerned, a so-called endorsement key isembedded into the TPM. This key is signed by the manufacturer and published in the form of adigital certificate. The manufacturer puts its brand name behind guaranteeing that the chip thatcontains this particular key (to be more specific, that contains a certain asymmetric key pair) is agenuine TPM that will operate as intended. Thereafter, whenever the TPM uses the endorsementkey, you know that the resultant data came from a genuine TPM. This is the only way of recog-nizing a specific genuine TPM, and it uses social trust (“trustable”) as discussed in the precedingsubsection. In other words, the reason you trust a specific TPM is that you can inspect the certif-icate, which is a trustable assertion by the company that made it. Other elements of a TrustedPlatform also have certificates. These vouch for the design of a Trusted Platform—that a specific



TPM was incorporated into a TP, that the design of the RTM and TPM meet the TCPA specifica-tion, and so on. Any trust in a security system at the end of the day comes back to trust in theindividuals, trust in companies, trust in brand names that vouch for the system, and so on.

Clearly, it is necessary to use both aspects of trust (i.e., trusted and trustable). Protocolsand services should be designed in such a way that everyone agrees that no gaping holes exist inthem and that bad things will not happen when those protocols are used. At the same time, evenif someone tells you that a service is trustable, you want to know that it is executed properly. Youknow this by making measurements and checking the results of these measurements against val-ues that have been created and signed by someone that you trust.

The Value of Trusted Platforms

Now that we have described the philosophy behind Trusted Platforms, let’s consider why suchplatforms are so valuable in cyberspace.

With the demand for commercial advantage and the pace of software development, it isimportant to evolve the information infrastructure to meet new challenges. Despite real andincreasing security threats, security technology in cyberspace is in its infancy. The virtual worldlacks the mature methods of physical security that have taken many years to evolve. Criticaltechnology infrastructure such as public key infrastructure and intrusion detection systems areonly at early stages of deployment. Legislation in cyberspace is lagging, and fundamentalnotions such as the “electronic signature” have only just been introduced. The often cross-bordernature of cyber activities adds difficulty to the task of ensuring secure interactions. The generalpublic has only limited understanding of cyberspace, and individuals and businesses are oftenignorant of the measures they should take to protect their interests. This is why the National Planfor Information Systems Protection in the United States [White House 2000] covers education as

Tr u s t a n d Tr u s t e d P l a t f o r m s

Trust involves myriad issues, all of which are important for business. TCPA hastaken the approach of addressing the issue of trust (confidence) for businesses ratherthan just trying to improve the level of information security per se, although securityimprovements do form part of the solution. Trust is the fundamental concept in thebusiness world, and information security is an important (even vital) enabler.

A genuine Trusted (Computing) Platform is a platform that is trusted by localusers and remote entities, including users, software, web sites, and all third parties.To enable a user to trust a computing platform, a trusted relationship must be builtbetween the user and the computing platform that can tell the user that an expectedboot process, a selected operating system, and a set of selected security functions inthe computing platform have been properly installed and operate correctly. The userthen makes his or her own judgment whether or not he or she trusts the boot process-ing, operating system, and security functions.


The Value of Trusted Platforms 13

well as legislation and technology aspects. In summary, threats against information security arereal and growing, yet the current computing infrastructure lacks a cheap or ubiquitous method ofdefense.

In this section, we show how Trusted Platforms can form part of the solution by enhancingtrust and confidence in computer platforms. Let’s take a look at the following:

• Security threats

• The limitations of existing security technology

• Why Trusted Platforms are needed

• The benefits of using Trusted Platforms

Security Threats and the Need to Evolve the Current Infrastructure

Figure 1-2 depicts some different types of threats in a typical networked environment. These aresome of the more important security threats, for different entities both inside and outside a cor-porate network:

• Virus and worm introduction, or planting of capabilities to perpetrate or facilitate futureattacks (e.g., Trojan horses)

• Software tampering and piracy

• Theft of data, software, and hardware

• Insider threats (reportedly both the most common and most damaging)

• Repudiation (i.e., false denial that previous transactions have occurred)

Figure 1–2 Security threats

Intranet

CommunicationsGateway

Partners

Remote User

DatabaseServers

Enterprise Clients

Other Sites

Virus

Denial ofService

Eavesdropping

Internet



• Authorization violation (i.e., inappropriate access by partners and unauthorized log-ins)• Denial of service attack, either intentional or unintentional

Safeguards (often called security services) can be put in place to prevent or deter threatsfrom being realized, or to reduce their impact. Such services include authentication, access con-trol, confidentiality, data integrity, and non-repudiation. However, use of such services will notgive total protection. Later in the book, we will show that Trusted Platforms can strengthenexisting security services, albeit at the expense of additional Denial Of Service (DOS) attacks.(TPs provide no additional defense against DOS attacks, and because they introduce more com-plex mechanisms, they actually invite more DOS attacks.)

Security threats are real and growing, as shown in Figure 1-3. Figure 1-4 shows that theacknowledged cost of cyber attacks (as reported in [FBI/CSI 2001]) for 1998, 1999, and 2000averaged $250 million and is increasing. The cost is probably significantly higher than indicatedby the respondents to this survey, because most losses caused by security breaches are consid-ered “company confidential” and are never publicly identified.

Figure 1–3 Unauthorized usage of computer systems

Has there been unauthorized use ofcomputer systems within the last 12 months?

Data source: Computer Security Institute/FBI “2001* Computer Crime and Security Survey”

0

10

20

30

40

50

60

70

80

90

1996 1997 1998 1999 2000 2001

yesnodon't know

perc

enta

ge



The Limitations of Existing Security Technology

Trusted Platform technology is not the only approach that aims to enhance confidence in com-puting platforms.

This section discusses current methods and introduces the need for additional technology.Existing security infrastructure consists primarily of the following:

• Firewalls for “boundary protection” [Cheswick & Bellovin 1994]• Security software, e.g., virus-checking software • Cryptographic accelerators/co-processors [Smith et al. 1998]• Security protocols, e.g., the Secure Sockets Layer (SSL) (now called TLS) for

confidential communication

We mention briefly each type of existing security technology in the following sections.

Firewalls

Security “firewalls” provide boundary protection for computer networks, but these can become abottleneck. Furthermore, to enable new functionalities and services, it has become commonpractice to increase the number of “holes” through firewalls through which dynamic content andprograms are “punched” (for outbound or inbound traffic). Thus, an organization is faced witheither restricting such new traffic (often an unpopular move) or evolving the firewall to deal withthe new situation.

Software Security Programs

A plethora of software programs is available to provide security functionality. These programsmight run inside a cryptographic co-processor or on the main platform processor (sometimesembedded in the operating system in the main platform environment) and provide a range of

Figure 1–4 The cost of cyber attacks

Data source: Computer Security Institute/FBI “2001 Computer Crime and Security Survey”

050

100150200250300350400

1998 1999 2000

Cos

t $m



functions from straightforward encryption to desktop firewalls. Software that runs on the mainprocessor implicitly assumes that it is running in a safe environment, so maximum confidence isactually delivered only if the software is installed and executing properly. Even then, secrets arestored as normal data, or perhaps in protected files or partitions on the hard disk. When a programexecutes on the main processor, its secrets are potentially exposed and may be vulnerable toeavesdropping by rogue programs. Data stored on disks may also be vulnerable to eavesdropping.

Software is vulnerable to attack by viruses, of which thousands of varieties exist. The“Nimda” and “Code Red” worms created problems in corporate infrastructures in autumn of2001, and new strains of viruses are being continually developed and released into the comput-ing and Internet environments. Viruses can attack even security software. Several proprietaryapplications are available for detecting viruses, preventing their entry and cleaning up if anattack does take place: Symantec’s Norton antivirus toolkit program is one such application.However, virus strains are developing continually, and although parts of the antivirus softwareare frequently updated, it does not provide reliable protection against unknown viruses.

Cryptographic Co-processors

Another type of existing security product is the cryptographic co-processor, or accelerator (e.g.,those provided by Eracom, IBM, Lockheed, nCipher, Thales, Rainbow, and HP). Acceleratorssuch as the IBM4758 are highly credible, self-contained high performance computing engines.These contain specialist hardware and firmware to provide security functions, often faster thancan be provided by a general-purpose platform processor. They provide a protected environmentfor secrets and can include mechanisms that detect attempts to gain access to the secrets. If suchan attempt is found, the accelerator can often erase its secrets and disable its functions. A crypto-graphic accelerator might provide a bulk (symmetric) encryption service, plus generation ofkeys from a genuinely random source. Prices can be hundreds of U.S. dollars.

IBM currently has PC products with a security chip incorporated on the motherboard.These don’t have “roots of trust” but do have some security functions (primarily “protection ofsecrets”) provided by a Trusted Platform.

The manner in which Trusted Platform hardware differs from cryptographic co-processorsis in both function and integration into the platform architecture. Trusted Platforms require twoseparate additional functions, one (called a “CRTM”) built into the boot process and the other(called a “TPM”) that communicates with the CRTM and the host platform’s processor: SeeChapter 3 for a better introduction to these functions and their technical details.

Carrying out sensitive processing inside a cryptographic co-processor is an entirelyacceptable solution to the problem of creating a trusted environment. Moreover, cryptographicco-processors may be preferred over a Trusted Platform in some circumstances, because theco-processor can do bulk encryption in a physically protected environment. However, suchspecialized hardware is too expensive to be automatically included in all platforms, so it is notpossible for ubiquitous platform security to be based on conventional crypto co-processors.The Trusted Platform should be seen as an alternative to the crypto co-processor with its ownbenefits, including lower cost.



Other Specific Technologies

A number of techniques have been used to enhance levels of confidence in computing platforms:These include compartmentalized mode workstations, embedded software, Boot Integrity Ser-vices (Intel), Microsoft security services in their current versions of operating systems(Microsoft Windows 2000) [Microsoft], and the Java “sand box.”

In addition, a great number of security protocols and mechanisms might be implementedin either hardware or software. For example, the Internet Engineering Task Force (IETF) stan-dards include the Transport Layer Security (TLS) and Internet Protocol Security Protocol(IPSEC). Such standards, together with others like Secure Multi-Purpose Internet Mail Exten-sions (S-MIME), Internet Key Encryption (IKE), and virtual private network (VPN), have beendesigned to provide different security features, such as user authentication, access control, andconfidentiality. [Kohl & Neuman 1993] and [Wobber et al 1994] give some examples of possiblesolutions. Other technologies that either use or support platform security include digital signa-tures, watermarking, smart cards, public key infrastructure (PKI), and biometrics. Any of thesetechniques that involve software executing on the main CPU necessarily rely upon the correctoperation of the host computing platform.

Why Do We Need Trusted Platforms?

The increase in online business transactions has created new needs. One of these needs is forcost-effective security hardware that does not fall foul of product export and import regulations.Trusted Platforms can supply this.

The lack of a cheap enabler has been a restraint on the development of solutions/servicesthat could rely on platform security. And the lack of solutions/services that rely on platformsecurity has been a restraint on the development of the platforms themselves.

In this section, we consider why we provide user confidence using trust mechanisms ratherthan security mechanisms (albeit that the trust mechanisms are provided by security mecha-nisms) and why an increased need for Trusted Platforms exists. We also look at the main prob-lems that Trusted Platforms are designed to overcome and the advantages that are obtained overa more conventional security approach.

Trust Versus Security

The trust mechanisms in a Trusted Platform reliably generate, store, and report measurementsabout the software environment in a platform. A user who wants to trust that platform (for someparticular purpose) gets the measurements (called “integrity metrics”) about the platform and com-pares them with expected values. If the measured values are the same as the expected values, theuser will interact with the platform (for that particular purpose). Otherwise, he or she should not.(Strictly speaking, only the actual user knows the level of confidence that he requires in order totrust a platform to do a particular job and hence the expected measurement values.) “Social trust” isdirectly involved because the user trusts other organizations or individuals to say “these particular



values indicate that the platform can safely be used for such-and-such purpose.” The actualrequired values could differ according to the particular intended use of the platform.

Why are Trusted Platforms preferable to secure platforms? There are several reasons.Technologically, existing secure computers have no way of proving that they are operating asexpected. This is a weakness in a world in which platforms are exposed to attack, data is increas-ingly mobile, and connections are increasingly dynamic. Commercially, trade in informationsecurity equipment is still subject to government scrutiny (although perhaps not to the samedegree as in the past). The most important answer, however, is that although modern commercewould benefit from a higher level of confidence in platforms, conventional secure platforms aretoo expensive and too painful to use (untrained users are not sympathetic to the fact that thesecurity is visible to the user!), or perhaps just unnecessary. Secure computers have existed fordecades and still are not ubiquitous. Trusted Platforms attempt a different approach.

When people think of information security, they think of secure data. Confidence in securedata relies on confidence in ownership of secrets: The recipient of data trusts it because therecipient knows who owns the underlying secret. It follows that trust in cryptography relies on“social” trust—the statement by some trusted person or organization that such-and-such keybelongs to such-and-such entity.

Trusted Platforms may be considered as an attempt to go back to basics, in that they pro-vide confidence by directly exposing the “social trust” that underpins all information security.The distinguishing feature of a Trusted Platform is that it enables someone to vouch for a plat-form and its integrity. As it turns out, this requires the use of conventional security techniques,but these are simply enablers. The provider of an electronic service, for example, can use aTrusted Platform to prove that a service is the proper service and that the service is operating asthe provider expects. This provides greater confidence to both the provider and the user of theservice. This is not the whole story, of course. Trusted Platforms must be economically pricedand designed to minimize the impact of government regulations on trade in information securityequipment. Therefore, TCPA Trusted Platforms include functionality that duplicates the best ofcurrently available similar equipment (confidentiality of data on the platform), functionality thataddresses a known problem to which no current solution exists (preventing access to secrets bysome types of “bad” code, such as hacker scripts), and functionality that exposes the social trustin a Trusted Platform. This range of functions is intended to convince customers that TrustedPlatforms provide useful benefits now and in the future.

Information Integrity and Platform Integrity

The problem of platform integrity is heightened by a changing business environment with agreater reliance on the use of networked computers and an increasing use of PCs. Enhanced trustin the proper operation of local or remote computing platforms is needed if critical businessdeals are to be carried out online. Such deals would greatly simplify current procedures thatmust be done offline or “out of band” by other, more trusted, traditional mechanisms.



A computer platform has integrity if the applications running on it execute without inter-ference. Existing security solutions assume the integrity of the platforms on which they operate.In particular, they assume that secrets can be safely stored and used on a computing platform.The owner of a platform may feel satisfied with the integrity of their own platform because theowner is in control of the software environment and history (previous behavior including inter-actions, physical modification, and software execution) of their platform. However, platformsare increasingly connected and exposed to threats from the Internet. This means that such confi-dence may be misplaced. A third party is in an entirely different situation to an owner, becausethe third party usually knows nothing about the environment and history of a remote platform. Athird party, therefore, has no explicit confidence in the integrity of a remote platform.

Therefore, if a platform is required to reliably prove its integrity, it follows that there is aneed to report integrity measurements and a need for proof that a platform can reliably reportintegrity measurements. How Trusted Platforms provide such a measurement is explained in thegray section later in this chapter, and in more detail in Chapter 3.

Finally, Trusted Platforms fulfill the need for protected storage for secrets (i.e., protectionfor cryptographic keys and platform authorization data, for example, that must remain confiden-tial). Trusted Platforms provide a mechanism for encrypting secrets securely using the new hard-ware in a Trusted Platform (i.e., the TPM). Further, they provide a mechanism for associatingencrypted secrets with a physical platform and ensuring that such data is only accessible on thatsame platform. When such secrets are encrypted, constraints can also be specified about the soft-ware environment that must exist in order for the secrets to be released. This last mechanism isnot available from existing security solutions.

Using Trust to Simplify Security

A Trusted Platform can provide an alternative solution to using complex conventional securityprotocols. By way of example, look at the case in which certain security protocols are used toprevent divulgence of sensitive information among parties. These parties must provide sensitiveinformation in order to cooperate, but they do not trust each other with sensitive information. Forbest confidence, those protocols should operate in trustworthy platform environments. But ifthese protocols operate in trustworthy environments, why not use a simpler protocol with theknowledge that the platforms can simply be trusted not to reveal the sensitive information toother parties? In particular, a Trusted Platform would be able to provide just as good a solutionby ensuring that secrets from multiple parties are not revealed to a platform unless the platformboth executes software that performs the desired operation and also does not reveal to any partya secret belonging to another party.

Main Problems: Hardware Cost and Exportability

The main problems that had to be addressed by TCPA were the cost of hardware cryptographicco-processors and the fact that different co-processors could be required for different market-places because of product export/import regulations. Governments can (and do) impose restric-



tions on the use of security equipment, so a co-processor that is legal in one country may not bein another. These restrictions apply mainly to strong confidentiality for bulk data (messaging andfiling). Countries such as the United States, France and Britain have relaxed their import/exportrules in recent years, but it is always possible that those rules will be strengthened again and thatother marketplaces have their own security restrictions.

These problems are serious obstacles to the ubiquitous inclusion of security in computerplatforms. TCPA hopes to succeed by using simple, low-cost, security hardware with functional-ity that avoids the import/export trap. TCPA can be regarded, in one sense, as an experiment totest the international marketplace for ubiquitous platform hardware security. To do so, the TCPAsets an industry standard for platform security features and interfaces.

We have already mentioned that ordinary crypto co-processors are too expensive to be fit-ted “as standard” in the intensely competitive and price-sensitive computer market. Substantialreductions in co-processor cost can be achieved by minimizing the size, functionality, and per-formance of the co-processor (greater production volumes also decrease cost, but sufficientmotivation for this must exist). The problem is that cheap hardware executes symmetric “bulk”encryption (the most common form of encryption used to provide confidentiality for files andmessaging) much slower than can be done on a modern central processing unit (CPU). Higherperformance specialist hardware is capable of symmetric encryption at the same rate as the mainCPU (or even better than the main CPU), but it is unlikely to be as cost-effective because theCPU (obviously) can be used for multiple purposes and because of the numbers in which CPUsare manufactured. If ubiquitous security software existed that relied on hardware protection, it ispossible that high performance hardware could be manufactured in such quantities to be cost-effective. However, no such ubiquitous security software exists because no ubiquitous securityhardware exists, and no such ubiquitous security hardware exists because no ubiquitous securitysoftware exists. This results in deadlock.

TCPA cuts this Gordian knot by inserting simple hardware into a platform, to act as a rootof trust for that platform. While a conventional crypto co-processor provides hardware protec-tion for its security processes, a hardware root of trust in an otherwise normal platform providessoftware protection for the platform’s software processes, at the same time that it maintains allthe advantages of a normal, open computing platform. The root of trust enables gathering andreporting of evidence about the trustworthiness of the platform’s main processing environment.The simple TP hardware contains all the functions that must be trustworthy if the evidence is tobe trusted. After it is proven to be trustworthy, the platform’s processing environment can beused for bulk encryption. Serendipitously, it transpires that all the functions that must be trustedare functions that operate on small amounts of data, so the performance of low-cost hardware isacceptable. Furthermore, it transpires that the functions that must be trusted are relatively non-contentious as far as product import and export are concerned. Thus, the hardware can be low-cost, and different versions of hardware for different marketplaces are not required.

TCPA calls “all the things that must be trusted” the Trusted Platform Module (TPM). Tobe precise, TCPA does not mandate that the TPM be implemented in hardware; it merely speci-fies the TPM’s properties. Thus, it is possible for an entire computer platform to act as its own



TPM, provided that the platform has the necessary properties. In reality, most TPMs will behardware devices that are built into a platform. It can be argued that a Trusted Platform is thecheapest way to enhance security in a non-secure platform, because a TPM includes just theminimum functions that must be trusted. This residual hardware cost cannot be eliminatedbecause, as already mentioned, it is axiomatic that the integrity of a platform cannot be provenusing software only.

We have already introduced the (logical) concepts of root of trust for measurement and rootof trust for reporting. Originally, it was intended that the TPM would be the single physical root oftrust in a platform and provide both logical roots of trust. In the first PC implementation specifi-cation [TCPA 2001c], however, two physical roots of trust exist because it was considered to betoo commercially risky and expensive to integrate the CRTM into a TPM. The CRTM itself iscurrently specified to be a (physical) root of trust in a memory device that protects it against unau-thorized alteration. The TPM is the other root of trust, with more extensive protection mecha-nisms than the CRTM. Eventually, it is desirable that the CRTM instructions are migrated to theTPM, because the TPM can provide much better control over those instructions. The roots of trustcooperate to enable a process by which integrity metrics can be obtained. Integrity metrics aremeasurements about the platform and are used to prove that the host platform is in a state inwhich it can be used to process sensitive data. As will be seen later, integrity metrics can be usedto prove to a local user or a third party that a platform is operating as expected and to prevent therelease of secrets unless a platform is executing particular software. This feature is new to TrustedPlatforms.

In summary, the requirement on enhancing trust and confidence in e-business must satisfya number of criteria, such as low cost and exportability; otherwise, such security mechanismswill never become ubiquitous. So it is necessary to identify the absolute minimum set of func-tionality that must be trustworthy if the overall platform is to be trusted, protect those things, andleave the rest “as is.” Trusted Platform functionality is designed to provide the base capabilitiesessential to the implementation of security solutions, in a low-cost hardware device. The devel-opment of software that exploits these capabilities will allow for the strengthening of existingapplication security and for the development of new applications relying on platform integrity.The potential for ubiquitous availability of TCPA could provide the environment for the devel-opment of new security solution architectures (in other words, architectures within which soft-ware is trusted to perform operations involving sensitive data).

The Benefits of Using Trusted Computing Technology

You will see that both companies and consumers receive commercial benefits from Trusted Plat-forms. In this section, we briefly discuss the following:

• The benefits of using Trusted Platforms that will emerge in the short, medium, and longterm

• How Trusted Platforms encourage greater customer confidence• How Trusted Platforms encourage e-business and enhanced e-services

Some of this confidence can be transferred to trust in companies themselves; Appendix Bincludes a section highlighting reasons why this would benefit companies.



Benefits to the User

Probably the most important aspect for users is that Trusted Platforms provide a low-cost way totrust a software environment for some particular purpose.

A Trusted Platform allows users to answer the following questions (see Figure 1-5):

• Am I appropriately authorized? (platform authentication)

• How can I have confidence that my computing platform will behave in the way Iexpect? (integrity)

• How can I trust a remote system that is not under my control? (integrity)

In addition, a Trusted Platform supports any means of user authentication. Therefore, itcan support the continuing personalization of web sites and user mobility, e.g., VPN and hot-desking. A Trusted Client can take part in riskier transactions than might otherwise be possible.For further details, see Chapter 2, which looks at applications of Trusted Platform technology.

The Trusted Platform architecture is designed to provide immediate, medium-term, andlong-term benefits to users. Longer-term benefits are predicated on software improvements: AllTPM chips support all TCPA functions, but existing software applications are not designed totake advantage of them. When TCPA platforms are more common, it is anticipated that custom-ers and Internet Service Vendors (ISVs) will start developing applications that use these moreadvanced functions. The most advanced functions require a public key infrastructure (PKI) andare designed for use by e-services.

Figure 1–5 Questions addressed by Trusted Platforms

TrustedPlatforms

Will you behave as Iexpect?

Can I trustwhat you

claim to betrue?

Checkingremotecomputer

Are you a TrustedPlatform?



Short-term (immediate) benefitsIn the short-term, benefits of Trusted Platforms are likely to be based on "Protected Stor-

age" functions. Customers can use Protected Storage to protect the confidentiality of data ontheir hard disks in a way that is fundamentally more secure than pure software solutions. You'llneed a basic TCPA implementation with a TPM chip embedded within a platform and associatedsoftware provided by the TCPA chip manufacturer.

In providing Protected Storage, the TPM does the following:

• Acts as a portal to encrypted data

• Provides an option (which does not have to be used) such that encrypted data canthen be decrypted only on the same platform that encrypted it

• Provides for digital signature keys to be protected and used by the TPM

Medium-term (intermediate) benefitsIn the medium-term, benefits of Trusted Platforms will probably also involve the measure-

ment of integrity metrics relating to the software environment on the platform, for use by theplatform. This scenario is the same as the short-term solution, but it requires additional software.Customers can then protect their sensitive data against hacker scripts by automatically prevent-ing access to data if unauthorized programs are executed.

The specific mechanism has the following properties:

• It uses the TPM chip.

• It acts as a portal to encrypted data, such that this data can be decrypted only if theplatform has a given set of software environment integrity metrics. If a hacker loads ascript, the presence of that script changes the state of the software environment and theTPM denies access to any secrets that were linked to that previous softwareenvironment. The script still executes, but it cannot access any such secrets and cannotinterpret any information protected by such secrets.

This feature can be exploited through software at different levels in the software stack,ranging from standalone applications to a fully TCPA-aware operating system (OS).

Long-term benefitsLonger-term benefits of Trusted Platforms involve the reporting of integrity metrics relat-

ing to the software environment on the platform, for use by third parties. This benefits e-busi-ness. The scenario requires additional public key infrastructure support, whether restricted to acorporation or extended across organizational boundaries.

Users and their partners, suppliers, or customers can connect their IT systems together andexpose only the data that is intended to be exposed.

The specific mechanism has this feature:



• TCPA provides reporting of integrity metrics of the software environment on a specificplatform. This allows a remote party to verify the software environment in a TCPAplatform before sending data to that platform. This provides confidence in the softwarestate and identity of a remote party, enabling higher levels of trust when interactingwith this party.

Both trusted clients and trusted servers can use this feature.

How Trusted Platforms Create Better Customer Confidence

Trusted Platforms can help create better customer confidence in several ways, including the fol-lowing:

• Enhanced security using hardware

• Feedback about trust to the user

• A technological foundation for privacy

• Trustworthy digital signature

Hardware-based securityProcesses that execute in specialist security hardware are better protected than processes thatexecute on ordinary computing engines. These protected functions are much more resistant tointerference and snooping from logical or physical attack, so there is greater confidence in thoseprocesses than in processes that execute on an ordinary computing engine.

In a conventional platform with a conventional crypto co-processor, the co-processor pro-tects all its functions from logical and physical attack but does not protect processing on theordinary CPU. A Trusted Platform provides logical and physical protection for secrets and logi-cal protection for the data protected by those secrets (which is processed on one of the mainCPUs). The TPM acts as a conventional co-processor for secrets, and the integrity mechanismsprevent the release of secrets to inappropriate processing environments and permit a local orremote user (or computer) to verify the trustworthiness of a platform before interacting with thatplatform. So a Trusted Platform protects a larger number of processes than a conventional plat-form with a conventional crypto co-processor: A critical few processes (dealing with secrets) areprotected by a minimalist crypto co-processor. Other processes (on data that uses secrets) areless protected than they would be inside a crypto co-processor (because no physical protectionexists, for example, against deletion), but are better protected than ordinary processes outside acrypto co-processor (because the confidentiality and integrity of the data is protected).

Specifically, a Trusted Platform provides hardware protection for keys and other secrets,which would normally be used to encrypt files or gain access to servers or other networks. TheTPM prevents the release of secrets until presentation of an authorization value and/or the pres-ence of a particular TPM and/or the presence of a particular software state in the platform. TheTPM prevents inappropriate access to encrypted files and network resources by snooping around



a hard disk, or moving a hard disk to another platform, or loading software to snoop on otherprocesses, for example.

Provision of feedback about trust to the userBy interacting with Trusted Platforms using smart cards or handheld computers, a user candecide whether to trust a computer or computing infrastructure.

A smart card or other handheld computer can be programmed to interrogate a TrustedPlatform (local or remote), retrieve identity information and integrity metrics, and compare theidentity and integrity metrics with expected values. If they are different, the smart card or hand-held computer user can refuse to interact with the Trusted Platform because it is the wrong com-puter or because it is in an inappropriate software state and not to be trusted for the intendedpurpose.

This enables a user to access an arbitrary computer platform in an organization or publicarea or an arbitrary server, and to determine whether it can be trusted to work on private infor-mation and not reveal the private information without authorization from the user.

Provision of a technological foundation for privacyBoth businesses and individuals are increasingly concerned with the privacy of their confidentialand personal information, particularly when their computer platforms are connected to networks.

In the computing context, privacy provides a way to prevent others from gaining access toinformation without the informed consent of its owners. Cell phones, telephone caller ID,credit cards, and the Internet provide people with a dramatic new level of freedoms that canenhance business processes and personal lives, but these innovations come with privacy con-cerns. All of these systems are capable of providing information, including financial and per-sonal data that most users assume to be private. The TCPA believes that the ability to ensuresuch privacy is an essential prerequisite of a trusted system. This privacy needs to be as robustas any other aspect of the trust in the system. [TCPA 2000b]

Privacy controls should determine whether it is permissible to reveal that the informationexists and the circumstances in which the information can be disclosed or used. A credit cardnumber is not secret, for example, but it is private. Only the owner of a credit card has the rightto use the credit card number. Others, who have been given the credit card number, should notdisclose, distribute, or use the number in a manner that is not approved by the card owner. It fol-lows, therefore, that data is rendered private if the owner of the data can control distribution ofinformation about the data, even knowledge of the existence of that data. Whether particular datashould be treated as private data depends on the nature of the data and the opinion of the ownerof that data. Some people are not concerned about privacy, and others are. One person may con-sider that a particular type of data must be private, while another may not.

Any data (even secret data) can have a privacy attribute. Some data associated withTrusted Platforms do not require security protection but could be considered privacy sensitive bysome users. The best such examples are public asymmetric keys (such as the public endorsementkey) and X.509 certificates (such as the endorsement certificate and identity certificates). To



maintain the privacy of such data, the TCPA specification requires that access to some such datais under the control of the owner of that data. An owner who is not concerned about privacy canstill distribute the data, or publish its existence, to his heart’s content. An owner who is con-cerned about privacy should use whatever mechanisms are provided to prevent others fromaccessing the data or learning about the data.

TCPA provides a novel form of privacy protection by preventing the revelation of secretsunless the software state of a platform is in an approved state. If secrets are kept on a server builton a Trusted Platform, a user can verify that the server is the expected platform and is operatingas expected even before sending private information to the server. After a user’s private informa-tion is on a server, the user can be reassured that data in the server will become unavailable if thesoftware environment on the server changes (during a hacker attack, for example). Thus, thesecret should never be used in unapproved circumstances.

Some aspects of privacy are expressed in Trusted Platforms via explicit commands or spe-cial features of commands or protocols. These commands or enhancements enable the TPMowner to dictate some aspect of a TPM’s behavior, such as whether it will do “real work” andwhether it will accept an owner. For example, the entire notion of TPM identities exists only toprovide privacy when a TPM owner uses a signing key that identifies his platform. A user hasmultiple trusted attestation identities that are associated with a TPM, which is particularly usefulin e-business because different identities can be associated with different types of tasks. Thetechnology prevents someone from building up a profile of the user by combining behavior asso-ciated with different identities. A user can use one identity when dealing with a bank, anotheridentity when buying goods, and yet another identity when posting opinions to a newsgroup. Anidentity can have any arbitrary name or label (even the user’s real name, if he or she wishes), yeteach identity can prove that it corresponds to a Trusted Platform. A third party can still track theconsistency of a user’s behavior and benefit from being able to inspect the environment on theassociated platform to see if it is trustworthy, but the third party cannot correlate activities per-formed using different identities. (Or, at least, the correlation cannot be done by exploitingTCPA mechanisms.)

TCPA also respects the privacy of a user of a Trusted Platform. TCPA differentiatesbetween the user of a Trusted Platform and the owner of a Trusted Platform. The owner has cer-tain privileges over a Trusted Platform, but a user’s data is private; even the owner of the platformcannot access that data without permission from the user. Hence, a platform could be owned andused by a single owner or user (in the case of a consumer or small business), or it could be ownedby one entity and used by another entity. This would be the case in a corporate environment,where the IT department is the owner, and the user is the individual to whom the platform hasbeen issued.

This issue of privacy is discussed in a more technological context later in this chapter.

Provision of trustworthy digital signaturesDigital signatures will become more important as they gain greater legal status, and TrustedPlatforms can support and enhance the use of digital signatures. You’ll realize these benefits:



• A Trusted Platform protects signature keys using the TPM, never reveals those keysoutside the TPM, and uses such keys to digitally sign data submitted to the TPM.

• A Trusted Platform can enhance digital signatures by incorporating integrity metricsthat indicate the software state of the platform when data is signed.

• Depending on the implementation of the TPM, a Trusted Platform can further enhancesignatures to guarantee that what is signed corresponds to what was seen by the signer.(This issue is considered further in Chapter 14.)

Support for security services and improved e-services

TCPA embeds trust and security functionality into computing platforms to properly anchorexisting security services; it also provides a basis for improved security services and servicesthat use security. Trusted Platforms are deliberately designed to support existing security tech-niques, even though the TP may lead to the development of improved security techniques thateventually supplant existing techniques. Trusted Platforms are even deliberately designed to useexisting security techniques to provide the functions of a Trusted Platform, and TCPA inventsnew processes only when necessary. This is critical, and not just a matter of preference: The bestsecurity techniques are those that have been subject to study for a long time, yet are still consid-ered to be secure.

The TCPA limits itself to the specification (rather than supply) of Trusted Platforms andservices derived from Trusted Platforms. TCPA Trusted Platforms provide the base for softwareand services at all levels to meet new e-business expectations, whether that base is for platformmanufacturers’ products and services or their customers’ own products and services built with/on such platforms.

The importance of trust for e-commerceConsumers’ lack of trust is a major inhibitor to e-commerce, although the expected boom in theuse of e-commerce has yet to materialize. There are many contributing factors including brandfamiliarity, web-site navigation, fulfillment of transactions (i.e., delivery of goods), the lack ofsociability of using the Internet to shop, the inability to touch and try goods, and the non-immedi-acy of receipt of goods. However, according to most surveys on the subject, it appears that con-sumers’ lack of trust in the Internet is a major reason for not buying online ([Cheskin 1999],[GVU], and [AT&T 1999]). Fears about security are an important aspect of this lack of trust. Forexample, in order to access an e-service in electronic commerce, you may have to communicatewith a platform with which you have had no previous contact. In this case, how can you believethat you are contacting the correct business entity and that the behavior of that entity’s platform isappropriate? How can you even ensure that your local personal computer remains trustworthy,because it may be accessed by remote software during the service?

For e-commerce to be effective, each of the components that combine to make up the sys-tem must be trustworthy. Any breach of security at any one of the levels will add to the feeling ofdistrust that users have toward shopping online. Indeed, it seems that the media’s dramatizationof security breaches has already made a substantial contribution toward users’ inherent lack ofconfidence.



It is not surprising that consumers are worried about the vulnerabilities in the system. OnSeptember 13, 1999, British Prime Minister Tony Blair succinctly captured the worries that peo-ple have when he said that the biggest barrier to the spread of e-commerce is a cultural one.Companies are worried that they won’t get paid. Customers are concerned that their personaldetails will be misused. Copyright holders fear piracy, and so on.

On March 20, 1999, former President Clinton expressed the deep concern of consumers insecurity and privacy, saying that he wanted to work with industry to find ways to give consumersthe same protection in the virtual mall that they now have at the shopping mall, and to enhancethe security and privacy of financial transactions on the Internet, which he believed to be anincreasingly deep concern of citizens everywhere.

Note that neither of them talks about perfect security; instead the goal is to be “as safe as”something else. In the case of Prime Minister Blair, the goal is to be as safe as any country in theworld—presumably that implies the U.S. In the case of former President Clinton, the goal is tomake the virtual mall as safe as the shopping mall.

The usefulness of Trusted Platforms also extends beyond services traditionally consideredas comprising e-commerce. Using TPs, both customers and service providers can have moreconfidence in business transactions. This has implications in the office environment for hot-desking, in the home environment, in remote management, and in teleworking. Other benefits,such as software distribution, apply to both the home and office environment, albeit with aslightly different focus.

As a result, many business opportunities are expected to be available in providing trust-enhancing services built on top of Trusted Platform technology. For example, the transactionalsecurity service market is expected to increase at a compound annual growth rate of 92 percent,from $128 million in 1999 to $3.3 billion in 2004 [IDC 2001].

Corporate responsibilities addressed by Trusted Platform technology Finally, organizations that use computer platforms will find it easier to maintain good practice ifthey use Trusted Platforms. Trusted Platforms can maintain confidentiality of the organization’sinformation. This is currently a major problem.

Attacks occur in these and other ways:

• Information corruption caused by viruses• Online theft of information (e.g., corporate data being at risk of loss or misuse if an

office platform is used at home over a personal Internet connection)• Offline theft of information (e.g., from a home system used over a personal Internet

connection, or information extracted offline from a stolen home or office system)

Information damage has several undesirable effects, including these possibilities:

• Direct financial loss resulting from fraudulent use of secrets• Loss of business opportunity through disruption of service• Loss of customer confidence or respect (e.g., via web pages being hacked)• Costs resulting from uncertainties, e.g., system failures leading to paralyzed

transactions leading to dispute resolution


The Main Features of Trusted Platforms 29

Legislation for digital signatures imposes requirements for trustworthy systems and safe-guarding of private keys. Companies could be more comfortable using Trusted Platforms fordigital signatures because of the ability to predicate signatures on the software state of the plat-form, either by checking the state before signing or by incorporating the state into the signature.

The Main Features of Trusted Platforms

This section summarizes the capabilities in a Trusted Platform that enhances end-users’ confi-dence in Trusted Platforms.

T h e Va l u e o f Tr u s t e d P l a t f o r m s

New business practices drive the need for protected information processing and com-munication systems.

With increasing and widespread usage of open networks, the need for ubiquitousinformation protection in computer platforms grows. One solution is the widespreadadoption of conventional security techniques but what businesses really want andneed is commercial confidence rather than security per se. The approach described inthis book is that of Trusted Platforms. Trusted Platforms are a low-cost method ofproviding confidence in the protection and processing of information. The trustmechanisms in Trusted Platforms use selected security mechanisms, but they areultimately based upon signed statements of “social trust” made by individuals andorganizations.

The higher levels of trust that are enabled by Trusted Platforms are valuable tobusinesses for the following reasons:

• Companies gain by being trustworthy• Brand image suffers if there is a breach of trust or privacy• Better trust enables more powerful management services• Consumers’ trust is a major business enabler• Improved trust and security is necessary to the delivery of business-critical

e-services

D e s i g n F e a t u r e s o f t h e T C PA Tr u s t e d P l a t f o r m

Most cryptographic primitives: But not bulk encryption.Privacy: Fully “opt-in,” with no identity correlation.No global secrets: If a TPM is cracked, it reveals information relating to the associ-ated platform and nothing further.Low-cost protected environment outside a crypto co-processor: It is uneconomicto do bulk processing in a co-processor. Ubiquitous security: Available at the lowest cost and without significant productexport/import problems.



A Trusted Platform is a normal open computer platform that has been modified to main-tain privacy. It does this by providing the following basic functionalities:

• Protection against theft and misuse of secrets held on the platform• A mechanism for the platform to prove that it is a Trusted Platform while maintaining

anonymity (if required)• A mechanism for a platform to show that it is executing the expected software

For further discussion of these capabilities, see Chapter 3.As stated above, Trusted Platforms use the following definition of trust: An entity can be

trusted if it always operates as expected for the intended purpose [TCPA 2000a]. A platformcannot itself decide whether it is trusted because trust depends on the intended use of that plat-form. Only a user can decide whether the platform is trusted for the purpose intended by thatuser. So the platform reports information to the user to enable that decision to be made. For fur-ther details, see Chapter 12.

An inherent capability of a Trusted Platform is the export of security primitives (exceptsymmetric cryptography) for use by the platform. Trusted Platform Modules (TPMs) exportnon-deterministic numbers (for keys) together with signing functions, a hash function, andasymmetric encryption. (Readers who are unfamiliar with such cryptographic terms may wish toconsult Appendix C for further explanation.) Bulk (symmetric) encryption is not exported by theTPM because of the TCPA’s intent to encourage use of the main CPU for such encryption (forfile storage and messaging). Symmetric encryption provided by software on the main CPU isboth faster than can be provided by low-cost hardware and easier to tailor for individual markets,thus avoiding the worst of the product import/export regulations.

A Trusted Platform can be used to securely store secrets for conventional security pro-cesses operating on the main platform. A Trusted Platform makes no attempt to make secretsdifficult to find. Instead, they are rendered unintelligible unless the correct access information ispresented and the correct programs are running. A thief can find a secret but cannot reveal itunless the access code is known. Ultimately, the technology could be developed so that a thiefcan load programs to snoop for secrets that have been revealed by genuine users, but the merepresence of snooping programs prevents the revelation of those secrets. Again, further discus-sion of this protection capability is provided in Chapter 3.

We now give a summary of the features that Trusted Platform technology provides beforemoving on to consider privacy issues, the architecture of Trusted Platforms, and some of theirmain features in more detail.



Privacy

Information protection systems require privacy controls to allow the computer owner to havecontrol over the identity (ID) of the platform and activation of the TPM. Users should have con-trol over the information that they store in the platform.

The owner has complete control over activation of the TCPA Subsystem and generation ofattestation identities for the Subsystem. Owner control is preferably expressed by the use ofproperly authorized commands, but some owner controls must be expressed using physical pres-ence, in which some physical action must be carried out on an actual platform. Physical pres-ence may seem a poor substitute for cryptographically authorized commands, but it isunavoidable in situations such as when the platform is incapable of processing authorized com-mands, or when the owner has lost his authorization information, or before the owner has hadthe opportunity to introduce his authorization information to the platform.

The manufacturer, the owner, and the users can all “turn off” a TPM if they so desire.There are mechanisms to disable and deactivate a TPM and prevent a TPM from accepting anowner. Judicious selection of options can enable a virgin platform from the manufacturer to beready for remote activation as a Trusted Platform or fully blocked from operating as a TrustedPlatform, with a range of options in between. After an owner has taken control of a Trusted Plat-form, he can prevent the TPM from operating until further notice. Users can prevent operation ofa TPM until the next boot cycle.

Attestation identities can prove that they correspond to a Trusted Platform, and a specificidentity always identifies the same platform. But the origin of a specific identity cannot betracked further, except by the Certification Authority (CA) that issues a certificate for that attes-tation identity. So appropriate selection of CAs enables the owner to control traceability from anattestation's identity to the certificates that attest to a specific TPM and a specific platform. Iden-tities can only be correlated with other identities by the CA that certifies these identities, and theowner has sole choice of that CA. So the owner can choose a CA whose policy is not to correlate

W h a t Tr u s t e d P l a t f o r m Te c h n o l o g y P r o v i d e s

Trusted Platform technology is technology that provides evidence about the integrityof a platform to both the platform’s owner and to arbitrary third parties.

A public key infrastructure (PKI) is required to take full advantage of Trusted Plat-form properties. Nevertheless, certain properties (such as improved protection ofdata on a platform) are available without the need for a PKI.

Trusted Platform technology can reliably measure and report on the configurationof the platform. It can also reliably store secrets. A Trusted Platform also provides amechanism to associate a platform with multiple, uniquely provable identities. Thisconverts a platform into a high-integrity computing environment that can interactusing an unlimited number of high-integrity identities.

Trusted Platform technology as specified by the TCPA enables a low-cost adapta-tion of existing PC platform architecture to provide this new security functionality.



identities or whose policy is to correlate identities, according to the wishes of the owner. Differ-ent identities are used for different purposes, and separate identities would usually be given todifferent users of the Trusted Platform. As a result, the mechanisms of the TCPA Subsystem donot worsen the issue of platform privacy (which already exists because of identification of plat-forms from MAC and IP addresses, for example).

Authorization data is needed in order to gain access to data stored via the TPM. Eachuser’s data can be kept private, and even the platform owner cannot access that data without thenecessary access data. (There is no “superuser.”) Hence, a platform could be owned and used bya single person (which would often happen in the case of consumers or small businesses), or itcould be owned by one entity and used by another entity. This would be typical in a corporateenvironment, where the IT department is the owner, and the user is the individual to whom theplatform is issued.

We now move on to look at various aspects of Trusted Platforms in more detail, includingproof that a Trusted Platform conforms to the TCPA specification, the platform architecture(including changes to the OS), and the key features that a Trusted Platform provides: hardware-based cryptographic capabilities, integrity measurement and reporting, creation of Trusted Plat-form identities, and protected storage functionality.

Meeting the Specification

A Trusted Platform comes with various “documents” that prove it meets the TCPA specification.

Some “documents” are digitally signed statements by manufacturers that a particular chipis a genuine TPM and that a particular genuine TPM is properly incorporated in a genuineTrusted Platform. Other “documents” are in the form of certificates from an authorized testhouse to attest that the design of the TPM and platform satisfy the TCPA security requirements.The security requirements are specified in documents called a “Protection Profile” (PP). Theparticular PPs were written by TCPA in the style required by the International Standard ISO/IEC15408 “Evaluation criteria for IT security”; the ISO bulletin for June 2000 says that this is also“more commonly known for historical and continuity purposes as ‘Common Criteria’ (CC)”[ISO/IEC 15408]. Another document, called a “Security Target (ST),” is written by the manufac-turer and is a statement of how specific equipment satisfies the PP. Each type of TPM must havea Security Target that meets the Protection Profile for TPMs. Each type of platform must have aSecurity Target that meets the Protection Profile for the CRTM and the connection of the TPM tothe platform.

Most customers will buy a standard Trusted Platform and will not concern themselveswith these proofs, simply trusting the vendor to sell them a proper Trusted Platform. All STs (ortheir references) must, however, be provided with a Trusted Platform, in the form of a digitalcredential that can be checked by a machine, because a CA requires that information in order toissue an attestation identity for a platform. This is because the CA checks that each Trusted Plat-form meets the TCPA security requirements before attesting to an identity.



To those who are interested in whether a Trusted Platform meets the specifications, themost obvious security aspect of a Trusted Platform is its degree of physical protection. The onlyparts of a Trusted Platform that needs physical protection are the TPM and the RTM (or CRTMin a PC). These would ideally be physically tamper-proof, but absolute resistance to physicalattacks is impossible. The best that is possible is tamper-resistance. The amount of tamper-resis-tance will depend on the level of trust that is required from the platform, which in turn affects theprice of the platform. Tamper-resistance can vary from that of an ordinary epoxy-coated chip tothat of a sophisticated module with protection against voltage attacks, timing attacks, X-rays,temperature attacks, and so on. Most TPMs will probably have a reasonably sophisticated levelof tamper-resistance, equivalent to that of the chips in smart cards. Most CRTMs have a level oftamper-resistance equivalent to at least that of a normal chip. It is currently unclear whether theywill be tamper-evident (i.e., reveal that they have been tampered with).

Architectural Summary

Existing security mechanisms can be incrementally fitted to existing platforms, but Trusted Plat-form functions require a fundamental change to the platform architecture plus attestation bytrusted third parties that the platform meets the TCPA specification. This makes it impractical toretrofit existing platforms and convert them into Trusted Platforms.

One part of converting a platform into a Trusted Platform is adding a root of trust forreporting to a platform. This requires the addition of a TPM chip to a platform, but it is poten-tially more complicated than might be thought. The obvious way is to solder a TPM chip to amotherboard, but this requires motherboards that are specifically designed to be suitable forTrusted Platforms. It may be more cost-effective to use standard motherboards with a “good”connection between the platform and a TPM, in order that the measurements received by theTPM are trustworthy. One way is to use cryptographic techniques to prove to a TPM that incom-ing measurements originated on a specific platform, but this itself begs the question of safelyinstalling the necessary cryptographic secrets in the motherboard and in the TPM. Another wayis to use a socket or connector so that a TPM can be added to standard motherboards when aTrusted Platform is manufactured. However, the connection must be resistant to physical tam-pering (so it might be necessary to permanently bond the joint), and it must be possible to seewhether physical tampering has occurred (so it might be necessary to cover the joint with specialseals).

A second part of converting a platform into a Trusted Platform is reliably measuring integ-rity information. This requires a fundamental alteration to many parts of the software stack,starting with a “Root of Trust for Measurement” (RTM) and probably a chain of subsequentmeasurement agents. The basic principle is that the RTM does some tasks, measures certainaspects of a platform (including the first measurement agent), and records those measurementsin the TPM. Then the RTM passes control to the first measurement agent (which does othertasks), measures certain aspects of the platform (including the second measurement agent), andrecords those measurements in the TPM. Then the first measurement agent passes control to the



second measurement agent and so on until all software has been measured and loaded. After allsoftware has been loaded, the final measurement agent continues to make measurements of newsoftware and stores them in the TPM before executing that new software. Because all software ismeasured before it is executed and recordings in the TPM cannot be tampered with, the TPMalways contains an accurate summary of the software state of the platform. If, at some point,rogue software is loaded, it cannot hide its presence in the platform, but (of course) all subse-quent measurements cannot be trusted.

On a PC, the RTM is the entire platform controlled by the Bios Boot Block (BBB), or bythe BIOS itself, provided that nothing untoward can execute before the instructions that com-prise the RTM and that acceptable mechanisms are present to prevent unauthorized replacementof the BIOS. The memory device holding the RTM instructions is given a special name—theCore Root of Trust for Measurement (CRTM)—by TCPA because this is the part of the RTMthat requires special attention and is subject to constraints described in the TCPA specification.Subsequent measurement agents are the entire platform controlled by some previously measuredsoftware. So the OS loader code and the OS must be modified to act as measurement agents.

A third part of converting a platform into a Trusted Platform is storing signed values ofpredicted integrity measurements, or pointers to those values. Predicted values of a componentare values that are made available by the manufacturer of the component so that a comparisoncan be made between these standard, expected values and those that are actually measured whenthe platform is being used. Option ROMs might include such information, or such informationmight be on the hard disk drive (in a PC, for example). This information is needed for a chal-lenger to decide whether he can trust a platform. The challenger must get the actual measuredvalues and compare them with signed predicted values, which is easiest if the predicted valuesare provided by the challenged platform. If they are the same and the challenger trusts the orga-nization or individual that signed the predicted values, the challenger can then decide to trust theplatform for some particular interaction or purpose.

A fourth part of converting a platform into a Trusted Platform does not even involve theplatform. Trusted Platforms require a support infrastructure, to provide attestation that the plat-form is genuine, to provide predicted values of integrity information, and to attest to attestationidentities that belong to the platform. In particular, a PKI is required.

The TPM: A Separate Processing Engine Distinct from the Main CPU(s)

The purpose of the TCPA Trusted Subsystem is to detect software attacks on the platform. Forboth local and remote users to trust the Subsystem, it is necessary to protect the Subsystemagainst software attacks. The reasoning is obvious: The Subsystem cannot reliably detect soft-ware attacks if its software can be subverted. For a remote user to trust the Subsystem, however,protection against hardware attacks is also necessary. This is because a remote user cannot besure that a local user has not physically tampered with a platform. Preferably, platforms wouldbe protected against a variety of hardware attacks, but that unfortunately dramatically increases



cost. So the Subsystem must resist all software attacks and a given number of hardware attacks.A sense of proportion—cost against threat—is necessary.

In practical terms, a Subsystem needs to protect some secrets and a certain number ofcapabilities that must be trustworthy. If those capabilities and secrets cannot be trusted, therecan be no trust in the Trusted Subsystem. The trusted capabilities and secrets need to be isolatedfrom the rest of the platform to prevent subversion of those capabilities and to prevent eaves-dropping and subversion of secrets. The specification does not mandate the embodiment of thetrusted capabilities, but does specify the interrelated properties of protected capabilities andshielded locations that any TPM embodiment must satisfy. Having said that, a convenient imple-mentation of the trusted capabilities and secrets takes the form of a single chip. The chip is aself-contained processing engine with specialist capabilities such as generation of non-determin-istic numbers, asymmetric key generation, asymmetric encryption, and hashing. Naturally, italso needs communications with the computing engine instantiated by the platform.

A TCPA Trusted Subsystem requires other functions, apart from those in the TPM, butdoes not need them to be trustworthy. The TCPA mechanisms and protocols are such that ifthese support functions are broken, they will at worst cause an inconsistency in information thatcan be detected by another computing platform. Hence, they are implemented as ordinary soft-ware executing on one of the main CPUs. The separation is made explicit in the TCPA specifica-tions, in order to minimize the amount of capabilities that must be protected and, hence,minimize the amount of extra hardware that is likely to be required in a TPM. This is vital tominimize costs.

The Operating System

The software that is running after the Trusted Platform has booted, which we will assume is theoperating system (OS), still has a vital role to play in a Trusted Platform. The TCPA Subsystemstill provides the means to record and report integrity information. The OS, however, must con-tain a measurement agent that detects execution of software that changes the level of trust in theplatform. Like all such measurement agents, this agent detects that software is about to be exe-cuted and stores a summary of the software in the TPM and updates a measurement log. Thesummary is a digest (see Appendix C for an explanation of this term) of the information in thelog, and the log is a textual and numeric description of the software. A challenger can retrievethe summary from the TPM and test it as described previously against predicted values. Alterna-tively, the challenger can retrieve the summary from the TPM and step through the log, deducingand checking the steps taken by the platform.

For an operating system to be TCPA-compatible, the OS needs the following features:

1. It must be able to detect that security-critical changes are being made. 2. It needs a means to decide which events should be recorded and which should not.

Theoretically, all changes to the platform that affect the security state could be recorded,but this makes the measurement log long and more difficult to interpret. It is probably better for



the OS to use a policy to decide which events to record and which not to record. For example, itmay check the signature on a new driver or application against an approved list and record theevent only if the signature does not appear on the approved list.

Note that code, applets, or drivers used on a TCPA system do not necessarily need to besigned to run. The use of signed components depends on the operating system environment inwhich the Subsystem operates.

Cryptographic capabilities

A TPM has the following cryptographic capabilities:

• Hashing (SHA-1)• Random number generation (RNG) • Asymmetric key generation (RSA)• Asymmetric encryption/decryption (RSA)

The TCPA specification also requires the use of symmetric encryption/decryption (3DES)during the acquisition of pseudonymous identities, but the TPM does not export that functional-ity to the platform. Individual TPM manufacturers may, of course, export symmetric encryptionfrom the TPM if they wish, albeit with the risk that such TPMs may cause increased productexport/import difficulties.

The Advanced Encryption Standard (AES) [AES]—3DES’s replacement—is not requiredin v1.1 of the specification, but it may be required in future versions of the specification. Thesecryptographic capabilities are explained in Appendix C, which provides background to crypto-graphic concepts for those who are unfamiliar with this material.

Integrity Measurement and Reporting

A Trusted Platform, starting from a root of trust in hardware, performs a series of measurementsthat record summaries of software that has executed (or is executing) on a platform. This processis illustrated in Figure 1-6. Starting with the CRTM, there is a boot-strapping process by which aseries of Trusted Subsystem components measure the next component in the chain (and/or othersoftware components) and record the value in the TPM. By these means, each set of softwareinstructions (binary code) is measured and recorded before it is executed. Rogue software cannothide its presence in a platform because, after it is recorded, the recording cannot be undone untilthe platform is rebooted. (This issue is considered in much more detail in Chapters 3 and 6.) Theplatform uses cryptographic techniques to communicate the measurements to an interestedparty, so the recorded values cannot be changed in transit.



Creation of Trusted Identities

It remains, therefore, to prove that the measurements were made reliably. This is the same asproving that a platform is a genuine Trusted Platform. That proof is provided by cryptographicattestation identities, and the process is illustrated in Figure 1-7. Each identity is created on theindividual Trusted Platform, with attestation from a PKI Certification Authority (CA). Eachidentity has a randomly generated asymmetric cryptographic key and an arbitrary textual stringused as an identifier for the pseudonym (chosen by the owner of the platform). To obtain attesta-tion from a CA, the platform’s owner sends the CA information that proves that the identity wascreated by a genuine Trusted Platform. This process uses signed certificates from the manufac-turer of the platform and uses a secret installed in the new (in the sense of unique) hardware in aTrusted Platform (i.e., the Trusted Platform Module (TPM)). That secret is known only to theTrusted Platform and is used only under control of the owner of the platform. That secret neverneeds to be divulged to arbitrary third parties; the cryptographic attestation identities are usedfor such purposes.

Figure 1–6 The measurement process for a Trusted Platform

SoftwareComponent

Measures

Other SoftwareComponent

Sends Value

Measures

Measures

Measures

Measures

Sends ValueSends Value

Sends Value

Trusted Platform Components

SoftwareComponent

SoftwareComponent

Other SoftwareComponents



Execution OrderBuilding Chain of Trust



Protected Storage

A TPM is a secure portal to potentially unlimited amounts of protected storage, although thetime to store and retrieve particular information could eventually become large. The portal isintended for keys that encrypt files and messages, keys that sign data and for authorizationsecrets. A CPU can obtain a symmetric key from a TPM and use it for bulk encryption, or a CPUcan present data to a TPM and request the TPM to sign that data, for example. The portal oper-ates as a series of separate operations on individual secrets. Together, these operations make atree (hierarchy) of TPM protected objects (also referred to in the TCPA specification as “blobsof opaque information,” which could either be “key blobs” or “data blobs”), each of which con-tains a secret encrypted (“wrapped”) by the key above it in the hierarchy. The TPM, however,knows nothing of this hierarchy. It is simply presented with a series of commands from untrustedsoftware that manages the hierarchy. An example of such a hierarchy is illustrated in Figure 1-8.

An important feature that is peculiar to Trusted Platforms is that a TPM protected objectcan be “sealed" to a particular software state in a platform. When the TPM protected object iscreated, the creator states the software state that must exist if the secret is to be revealed. When aTPM unwraps the TPM protected object (within the TPM and hidden from view), the TPMchecks that the current software state matches the stated software state. If they do, the TPM per-mits access to the secret. If they do not match, the TPM denies access to the secret.

Figure 1–7 Obtaining proof that a platform is a Trusted Platform

Certificates

Under Owner’s control for Privacy

IdentityCertificate

Identity-binding

Identity

Certification Authority

Owner

CA

ABC


When All Platforms Are Trusted Platforms 39

When All Platforms Are Trusted Platforms

This section aims to emphasize how Trusted Platform technology is appropriate for all comput-ing platforms. After a brief discussion of laptops, PDAs, and servers, it introduces how an ITinfrastructure where all platforms are Trusted Platforms would deliver the full vision of trustedplatform technology.

It is very likely that different types of Trusted Platform—and not just Trusted PCs—wouldform part of a future global computing infrastructure.

Different Types of Trusted Platforms

As discussed already, the generic TCPA specification applies to a wide range of computing plat-forms including servers, appliances, and cell phones. In particular, the identity creation andusage, reporting mechanisms, etc., can be applied in an analogous way to different types of plat-forms, although the details for the integrity measurement have not yet been considered for thesetypes of platforms.

Potentially, there can be different types of Trusted Platforms, for which different types ofservices would be more appropriate. The following are some examples.

PC

A PC would be connected to the network 24 hours a day. It could be connected either to thehome network, the Internet, or the intranet in the office. The short-, middle-, and long-term func-

Figure 1–8 A storage hierarchy

Storage Keys

TPM

Protects (Stored Internally)

Protects (Using encryption)

Storage Root Key (Asymmetric key)

Signaturekey

Protects (using encryption)

Protects (using encryption)

Storage key

Symmetric key

Asymmetrickey

(signs data)

Authorizationsecret

SecretData

SecretData

Asymmetric Keys

Arbitrary dataTPM Protected Objects



tionalities of Trusted Platforms are targeted at PC deployment. The first target environmentwould most likely be a corporate one, with provision for protection of sensitive data, identifica-tion of corporate platforms, and verification of corporate system configurations.

Server

A server is likely to be running in a corporate environment 24 hours a day. A trusted server couldhave the benefits of protection of sensitive data, greater trustworthiness for those wishing to usethe server, and an enhanced relationship with individual client platforms (for example, with bet-ter authentication, verification of their configurations, remote management services, etc.). Whilethe initial focus of TCPA has been on the PC/client, the potential for such technology whenapplied to servers is huge. Because servers are generally the hubs of business-critical servers, theneed for such enhanced security mechanisms is probably greater than for the PC.

Laptop

A laptop could be standalone, with the potential of being connected to one or more intranets andpossibly also to the Internet. Even in the standalone case, a trusted laptop platform would pro-vide better built-in protection of data on the platform, which would be particularly useful due tothe pervasive risk of theft of the laptop.

For connected laptops, a secure dial-in service could be provided, by which the physicalplatform identity would be checked and there would be the possibility to check that this was inthe approved corporate (or governmental) software configuration. This would help prevent soft-ware hackers from dialing in to a company from unauthorized hardware running hacking soft-ware and penetrating the company’s intranet.

PDAs

Personal digital assistants (PDAs) are small, lightweight, portable PCs with restricted function-ality. They were traditionally standalone but are increasingly being connected to intranets andthe Internet. To enable PDAs to become the ultimate personal portal to a connected environment,they must be able to connect to a corporate network and to the Internet. There is no differencetoday between a corporate PDA and a home-user PDA.

Ubiquitous Trusted Computers

Trusted Platforms could become fundamental to a global computing infrastructure for the fol-lowing reasons:

• As already considered, a low-cost approach is necessary for ubiquity and this is whatTPs provide. Furthermore, ubiquity and standardization are necessary for a globalinfrastructure.

• Total security is impossible or not necessarily practical over a wide range of situations.Instead, it is necessary to solve a less serious problem, which is that of providing


Summary 41

technology to enhance trust so that users will use services without fear ofconsequences.

• Trusted Platform technology can be applied to mobile and changing environments. TheTCPA specification brings new functionality to client platforms such as PCs, mobilephones, and PDAs. The potential of TCPA will be released in phases, because somefeatures require more supporting software and infrastructure than others.

• Companies improve their performance by stronger collaboration with their customers,suppliers, or partners. This requires dynamic IT relationships between organizations.Sharing data and IT resources in this way is dangerous, yet it is likely that future trustedinteractions will increasingly need to be established “on the fly” with a high level ofassurance that the risk involved is limited. Such a vision requires platforms with built-in security capabilities; a critical foundation of those security capabilities are theTrusted Platform functionalities of data protection, platform integrity, and platformidentity, which are discussed in Chapter 3.

• Finally, the long-term benefits of Trusted Platforms discussed above involve adistributed infrastructure.

Summary

Trusted Platforms get their name from the fact that they enable either a local user or a remotelycommunicating user to trust a platform for some particular purpose. A behavioral definition oftrust has been adopted: An entity can be trusted if it always behaves in the expected manner forthe intended purpose.

The TCPA is an industry alliance formed in October 1999 that focuses on developing andspecifying Trusted Platform technology. The TCPA specification, released in February 2001, isdesigned to be independent of the type of platform (e.g., PC, server, PDA, printer, mobile phone,etc.). A single hardware chip (costing about the same as a smart card) will typically perform theTCPA-defined trusted functions. All other functions will be performed by normal software. TheTCPA architecture is designed to provide immediate, intermediate, and long-term benefits tousers. Some features will be available immediately, while other features require further softwaredevelopment (expected shortly). The most advanced features require a public key infrastructureand are designed for use by e-services.

A TCPA-enabled system offers a low-cost standardized means of embedding securityfunctionality in a platform. As a result, improved levels of security can become ubiquitous. Thecapabilities provided by a TCPA-compliant platform benefit both consumers and businesses andhave been defined to be independent of a specific market focus. In particular, a TP allows usersto have confidence that their computing platform will behave in the way they expect and also totrust remote systems that are not under their control.

This technology is promoted by major companies such as HP, IBM, Intel, and Microsoft.Trusted Platforms are likely to appear on the market from 2002 onward. These computers can beused as a foundation for many different types of trusted e-services. For example, there could be



TCPA-compliant PCs in public places that would enable people to authenticate themselves to thenetwork, attest to the trust level of the PC, and then conduct their business in security beforeleaving. Trusted Platforms can potentially enhance application areas as diverse as manageability,storage, VPNs, and intrusion detection. Therefore, this specification is starting to excite a greatdeal of interest as security experts and users appreciate its potential and the necessity of thistechnology for the expansion of e-commerce.

The TCPA home page (www.trustedcomputing.org) is a source of useful information.


Date post:	09-Jun-2018
Category:	Documents
Upload:	phungnga
View:	216 times
Download:	0 times

Trusted (Computing) Platforms: An Overview - Pearson · 4 Chapter 1 • Trusted (Computing)...

Documents