Trusted Platform on demand (TPod)

Hiroshi Maruyama Frank Seliger Nataraj Nagaratnam Tim EbringerSeiji Munetoh Sachiko Yoshihama Taiga Nakamura

February 1, 2004

Abstract

In service-centric, “on demand” computing, estab-lishing stronger trust on networked platforms is akey requirement because these remote platforms areoften owned and managed by separate entities. Theresearch described in this paper is an architectureand implementation called Trusted Platform on De-mand (TPod), which increases the trustworthinessof networked platforms by combining dedicated se-curity hardware, a secure operating system kerneland an open security protocol, to provide a securesoftware platform that may host a diverse rangeof distributed applications. Especially significant isthe fact that the applications are better protectedeven if there are vulnerabilities in the applicationsoftware or in the system software, or the systemadministrator is not completely trustworthy.

The proposed architecture is widely applicable toscenarios ranging from grid computing to the securehosting of third-party applications on devices suchas mobile-phones or smart-cards.

Keywords: tcg, trusted platform, attestation.

1 Introduction

When many computers need to work as an inte-grated application system across corporate bound-aries, the platforms participating in the computa-tion are often managed by different entities underdifferent security policies. If the entire system isto be trustworthy, each participating platform mustbehave as expected, or else be protected against fail-ures emanating from the other platforms. In “ondemand” computing, these platforms are often serv-

ing multiple independent applications that must notinterfere with each other. In addition, these plat-forms must be accessible using an open protocoleven though they are diverse in their architecture,capabilities, and security mechanisms. These arethe goals of the research presented in this paper.

From the security point of view, we are particularlyconcerned with software vulnerability and the at-tacks that exploit such vulnerabilities. We knowthat any software with non-trivial complexity hassecurity bugs. Therefore our architecture should beable to respond to the discovery of a new securityvulnerability. We also consider improper configura-tion of software as a software vulnerability.

The work described in this paper is an architecturecalled Trusted Platform on Demand (TPod) thataddresses the above challenges. The architectureenables an application owner to verify that a re-mote platform conforms to necessary security andintegrity expectations. Although the architecture isgeneric and can be implemented in many differenttechnologies, in this paper we present one concreteimplementation using tcg, SELinux, osgi and theprotocols based on WS-Security.

In the next section, we discuss our distributed com-puting model and the threat model. Section 3 givesa brief overview of the architecture. The architec-ture consists of three layers each of which is de-scribed in turn in the following sections; the trustlayer in Section 4, the protection layer in Section 6,and the interoperability layer in Section 7. We con-clude the paper in Section 8 by presenting some dis-cussions on security tradeoffs and related works.

1

2 Threat model and functional re-quirements

The TPod architecture is best represented via a dis-tributed application model (see Figure 2). An appli-cation A has several components A = {a0, . . . , ai}running on different hosts H0, . . . ,Hi, each of whichmay be hosting other applications. Each host hasan owner OHj

. An application A belongs to its ap-plication owner OA, and defines an access-controlpolicy PA over its objects. This access-control pol-icy may deny the host owner access to applicationobjects, and expect this restriction to be enforced.

The host measurement MHjrepresents a detailed

hardware and software components and their re-spective configurations, which the host uses to ex-ecute application components. This measurementmust not be forgeable, and must truly represent theconfiguration the host uses to execute applications.Of course, some of the components of the platformmay contain faults (intended or accidental), so wedistinguish between the measured configuration andthe intended configuration such that

intended configuration + faults = measuredconfiguration.

From a security perspective, the goals of the appli-cation owner are:

(a1) OA can verify that the host measurementshows that host to be capable and willing toenforce the application’s access control policy,prior to the application being deployed.

(a2) OA can discover and decide whether the faultsthat exist in the host, if any, will render thehost unsuitable for the application.

Furthermore, the goals of this paper are to

(b1) Devise a suitable verification algorithmverA(MHj ) which can be used by the applica-tion owner OA to verify whether her securitygoals (a1–a2) will be met by the host platformHj .

(b2) Develop a suitable host architecture which willsupport the above model and verification algo-rithm — using open standards — which may

Inter-operability Layer

Trust Layer

Protection Layer

• Open protocols to communicate with TPod platforms• Security policy of the application

• Domain separation / access control enforcement

Trust anchors — platform measurement• Integrity assertions• Trusted (3rd party) security assertions• Hardware rooted trust

Figure 1: TPod layers

also be used as an example of a suitable in-tended configuration.

The specific security threats we will address are asfollows:

(c1) The host measurement does not represent afaithful and current account of the host’s con-figuration (timeliness and correctness of themeasurement).

(c2) That the faults in the host’s configuration,which the host owner may or may not be awareof, render the host insecure.

(c3) That an application component running on thehost can make an unauthorized access to theresources of another application component.

3 TPod host architecture

To achieve these requirements, the TPod host archi-tecture is layered as in Figure 1. The first challengeis to allow creation of a measurement representingthe hardware and software components, as well asimportant configuration parameters of these com-ponents. This is achieved by the trust layer of theTPod architecture. The trust layer enables the hostto prove its security properties to a remote verifier.In our implementation, the trust layer is realized us-ing tcg technology, which provides hardware-based

Host H₀Host

MeasurementM₀

app.

com

p. a

₀

Host H₁Host

MeasurementM₁

app.

com

p. a

₁Host H

HostMeasurement

M

app.

com

p. a

ii

i

. . .

Application AAccess

ControlPolicyPA

Figure 2: On-demand Application Model

root-of-trust. The protection layer prevents appli-cations from interfering with one another, and limitstheir behavior according to a mandatory access con-trol policy defined for the system (c3). Finally, theinteroperability layer provides an open set of proto-cols, utilizing web services, for TPod’s to communi-cate.

The TPod architecture can be implemented in anumber of different ways. The implementationshown in this paper uses existing technologies suchas ThinkPad with a tcg chip, Security EnhancedLinux, osgi, and Web Services security.

4 Trust layer

4.1 Integrity measurement

The purpose of the trust layer is to prove the in-tegrity of the environment. This may translate toproving a platform’s security property (for exam-ple, “the current configuration has no known vul-nerability.”). In order to achieve this goal, the plat-form must have a trusted entity which can measurethe integrity of the platform and deduce the secu-rity property of the platform. Such an entity canbe characterized to be a “trust provider” and thatprovider(s) should be part of the platform’s tcb(Trusted Computing Base). Given the tcb reflectsthe entities that need to be trusted, the smaller the

set of vulnerabilities to which they are exposed, thebetter. i.e., trust anchors themselves should be less(ideally, not) vulnerable to attacks. In that con-text, hardware entities are generally considered tobe less vulnerable. Which provider one chooses toensure integrity of the platform will be based on var-ious factors including cost, performance and busi-ness policies. Therefore, the architecture should notmandate a particular provider.

A trust provider that helps to prove the platform’sintegrity can be:

1. A software based provider which validatesthe integrity by inspecting the platform state,which in turn may need access to keys, reg-istry, etc which can be part of that provider’stcb. This is a viable case when the platformis known to be running the expected tcb —for example, when the platform resides in thesame security domain and the verifier can beconfident that the platform’s trust anchors (andhence, the tcb) are not compromised.

2. A hardware based provider that takes ad-vantage of hardware-rooted trust where thatprovider’s tcb may contain the hardware pieces(so, hardware becomes the trust anchor). Thislater part of this paper discusses an implemen-tation of the trust layer based on tcg technol-ogy.

3. A provider that deduces the integrity of the sys-tem based on assertions done by trusted par-ties like an administrator. For instance, the

fact that a system is within a tightly monitorednetwork environment and reasonably “lockeddown”, some may consider those platforms tomaintain integrity.

4. A hybrid of such providers.

4.2 Attestation protocol

Integrity attestation allows the integrity of the plat-form and constituent software stack of the platformto be verified. This section discusses what we pro-pose as a protocol. In the later sections, we describehow this attestation protocol can manifest them-selves so that different systems can participate sothat the message exchange is interoperable.

4.2.1 Message with originator integrityguarantee

The basic form of attestation is done through ex-changing a Message with Originator Integrity Guar-antee (moig). Assume that platform P wants toprove that it has configuration properties CP . CP

could be a configuration itself, or more abstractproperty of the platform configuration, such as “theplatform configuration does not have any known se-curity vulnerability.” The platform P measures itsintegrity and obtains its integrity measurement M .Then P signs the message m plus M by the attes-tation key K. A moig message consists of a mes-sage body B, an attestation signature S, a platformidentity token Tp and an attestation token Ta (seeFigure 3).

The attestation signature S cryptographically bindsthe message body B, measurement M , and the keyK. The platform identity token Tp (a public keycertificate) binds K to the platform identity P . TheAttestation Token Ta asserts that the property CP

holds for the measurement M . Together, this moigmessage proves that the message body B originatesplatform P when P has the configuration propertyCP .

A receiving party should verify the attestation sig-nature so that it is in fact a signature by K on themessage body B and the measurement M . Thenit verifies that K is owned by the platform P byexamining the identity token Tp. Finally, it verifies

Prover P Verifier V

Attestation Token TA

Platform ID Token Tp

Attestation Signature S

Message Body M

SOAP Envelope

Figure 3: Message with Originator Integrity Guar-antee (moig)

the attestation token to see if the measurement Mimplies the desired configuration property CP .

4.2.2 Validation scenarios

An attestation token asserts that the measurementM represents the configuration property CP . Thereare several types of attestation token depending onhow the receiving party (validator) of a moig mes-sage computes this binding.

• Static trust. In this case, the validatorknows that certain measurement values can betrusted. These values could be a priori storedin the validator’s database. The attestation to-ken only carries the measurement M . It is thevalidator’s responsibility to deduce the config-uration property CP from M .

• Dynamic trust. In this case, the sender sendsdetailed information how the measurement isderived from each component. In our applica-tion it is a tpm event log, embedded with an at-testation token. The validator needs to recon-struct the measurement from the event log andmake sure that it equals to M that is used inthe attestation signature. Then, the validatorcan deduce the necessary configuration prop-erty CP from the event log.

• Third party trust. In this case, the attes-tation token has both the CP and M , signedby a trusted third party. The third party as-sures that M in fact represents the configura-tion property CP .

IdentityCA

Validationentity

TPodplatform

TPodplatformAttestation

Identitycertificate

Validation

certificate

Identityvalidationrequest Integrity

validationrequest

Figure 4: TPod Infrastructure

4.2.3 Trust infrastructure

In the third party trust scenario, we need a set oftrusted third parties as an infrastructure. Sincewe have two types of token, platform identity to-kens and attestation tokens, we need two types oftrusted third party (Figure 6). They are identity caand validation entity. An identity ca issues a plat-form identity token, which asserts that the key Kis owned by the platform P . This can be a normalX.509 certificate.

The validation entity issues attestation tokens. Anattestation token asserts that the measurement Mrepresents the configuration property CP . Thereforea validation entity should have enough knowledge onvarious configurations and the status of these con-figurations. In a typical intranet setting, the ciooffice defines a small set of “supported” configura-tions — the hardware, bios, os, etc. They shouldalso monitor the security updates of each compo-nent and refresh the database appropriately. Sincesecurity patches are released often, the expirationperiod of an attestation token should be relativelyshort (e.g., a day or a week) depending on policy.

5 Trust provider based on TCG

This section discusses how a tcg based trustprovider can be used to achieve the TPod archi-tecture proposed in this paper. This leverageshardware-rooted trust.

5.1 Trusted bootstrap

The tcg technology offers hardware-based root-of-trust by measuring the software integrity during abootstrap sequence. The tcg specification definesan embedded chip (called Trusted Platform Moduleor tpm) that holds cryptographic keys as well asregisters to keep track of software integrity (calledPlatform Configuration Registers, or pcrs). ibm’sThinkPad T30, X30, R32 and successor models arecompliant with the tcg 1.1b specification [3, 2].

In our TPod implementation, the tpm chip is usedas hardware-based root-of-trust of the trust layer,and enables the platform to prove the software in-tegrity. The tpm chip defines 16 pcr registers whichhold cryptographic hash values representing thehashed images of software components. The valuesheld in these registers represents the trusted mea-surement of the platform software integrity since thehost owner cannot arbitrarily change these valueswithout breaking the tamper-resistance of the tpmchip. These registers are cleared when the platformrestarts, and the only operation allowed to them isto “extend” their values1. Since these are one-wayhash operations the final values are considered to beunique to the specific sequence of the extend oper-ations.

MHj = (

tpm attestation︷ ︸︸ ︷sig aikj

(composite pcr hash, c),

tpm event log) (1)

The bootstrap process is outlined in Figure 5. Whenthe platform is bootstrapped, the non-updatableportion of bios (bios Boot Block, or bbb) “mea-sures” the integrity (sha1 hash) of the bios imageand stores the value into one of the pcrs. The biosthen measures the os loader, before execution istransferred. In this way, a chain of trust is estab-lished from the bbb onwards.

Once the os loader is reached, it must measure theos kernel and critical accompanying structures. Wemodified the open source grub loader to managethe measurements. grub is particularly convenientsince it can natively understand various filesystems,

1The extension operation is the typical way used to in-corporate some new data x into an old hash value, i.e.,hnew = H(hold||H(x)).

CRTM

GRUBStage

1(MBR)

PCR01-07

BIOS

ROT

Bootloader

PCR04,05TPM

Operating System (Runtime)

GRUBStage

2

PCR08-14

conf

: 1. Measurement: 2. TPM_Extend: 3. Transition

POR

data

POST

GRUBStage

1.5

NativeApplicationNative

ApplicationSignedNative

Application

JavaApplicationJava

ApplicationSigned JavaApplication

SELinuxKernel

MACPolicy

JavaRuntime

Measurement of allexecutable content

FigureX. Trusted Boot and Runtime Integrity MeasurementFigure 5: Trusted boot procedure

Component Language loc changedStage 1 Assembler 150

Stage 1.5, first sector Assembler 150Stage 1.5, the rest C 50

Stage 2 C 650

Table 1: Size of grub modification

which allows measurements to be specified in thegrub.conf file, rather than requiring geometricalknowledge of how files reside on the disk.

grub is used to measure the SELinux kernel, theSELinux mac policy, /etc/init and related scripts,whilst the log of these measurements is stored inthe bios. Once the operating system loads, the/etc/init script starts a daemon process known asthe tcg Software Stack (tss) which then assumesmeasurement and logging responsibilities. The tssalso includes api calls to retrieve a list of the pcrvalues, signed by the tpm chip. This operation isknown as attestation in the tcg specification, andis used as part of the platform measurement (seeEquation 1).

In our implementation, one specific challenge was tomodify the first stage of the grub loader that fitsin the master boot record (mbr) of the bootstrapdrive. Since the mbr is only 512 bytes long, mostof which is already used, we removed support forsome legacy devices to free up space. This allowedthe inclusion of code necessary for the Stage 1 ofthe grub loader to measure the next stage of thebootstrap sequence. Table 1 summarizes the sizeof the modifications made to grub, while Listing 1shows an example configuration script.

Once the platform is bootstrapped, the configura-tion of the measured platform must not change.Otherwise, the integrity value would not representthe currently effective policy of the platform. Forthis reason, the platform must be protected fromlater modification of the measured components. Inparticular, adding and removing of kernel modulesis prohibited2.

At the application level, there are additional secu-rity properties that are represented by the daemons,libraries, shell scripts, middleware (such as appli-

2Loading kernel modules can be allowed if their integritycan be assured. Kroah-Hartman recently proposed a way toallow kernel modules to be digitally signed and verified bythe kernel before loading [5].

cation servers and database servers), and applica-tion programs and data. These properties also needto be proved or verified. For this purpose, we em-ploy runtime integrity checkers such as Linux signedexecutable [8], aide, and Tripwire. The measuredkernel must have a mandatory policy so that theseapplication-level integrity checker cannot be sub-verted.

5.2 Verification of host measurement

The measurement of the host integrity must be re-ported to a remote entity so that the verifier can ver-ify the platform’s integrity. In tcg, this can be doneby pcr“quote” operation. This quotation is digi-tally signed by an Attestation Identity Key (aik)that is securely stored in the tpm chip. The veri-fier retrieves this along with the host’s Event Log,which together comprise the host measurement (seeEquation 1). The verifier then performs the follow-ing steps:

1. The verifier checks that the host mea-surement is well-formed. The verifierchecks the aik signature, then follows the hashchain described in the Event Log and verifiesthat the final values are the same as thosesigned by the aik. If this fails, the platformcannot be verified as trustworthy.

2. The verifier checks for faults in the host.The verifier compares component hashvalues against a database of known vul-nerabilities. Our implementation is an ldapdirectory that associates hash values with cvereferences3. This allows the verifier to ascer-tain whether there are any known faults in thesystem. Even if vulnerabilities are found, theverifier may decide that the faults identified arenot relevant to their application, or that theyrepresent an acceptable risk.

3. The verifier checks that the intended con-figuration is acceptable for hosting theirapplication. The components should describea system which, at the least, provides a pro-tection layer and an interoperability layer (de-scribed in sections 6 and 7, respectively).

3cve is a dictionary of Common Vulnerabilities and Ex-posures maintained by the mitre Corporation. See http:

//www.cve.mitre.org/.

t i t l e Measured SELinux root ( hd0 , 0 )measure ( hd0 , 1 ) / e t c / s e c u r i t y / po l i c y . 1 2 8measure ( hd0 , 1 ) / opt/ jdk / j r e / l i b / s e c u r i t y / java . p o l i c y 10measure ( hd0 , 1 ) / opt/ jdk / j r e / l i b / s e c u r i t y / java . s e c u r i t y 10## add i t i ona l measurements not shown/vmlinuz−2.4.20− s e l i nux . ro root=/dev/dha1 en f o r c i ng=1

Listing 1: Example grub.conf configuration script

Such an arrangement of the trust later allows flex-ible trust relationships regarding the platform in-tegrity. For example, suppose that security vulner-ability was found and corrected in the platform op-erating system of a mobile device. An applicationowner who wants to use its application componentcan make an intelligent decision whether the targetplatform can be trusted from a number of differentaspects:

1. Trustworthiness of the reported measurement.If the measurement based on hardware root-of-trust and the platform is well protected fromphysical attacks, the measurement could bemore trusted.

2. The properties implied by the measurement.If the measurement represents that the plat-form has a configuration with no known secu-rity vulnerabilities, the platform could be moretrusted.

3. The level of security required for the applica-tion. If the application is a bank application, ahigher trust may be necessary. Otherwise, theapplication may choose to trust the platformeven if the platform has some minor securityvulnerabilities.

This flexibility stems from the fact that its applica-tion, not the platform or a third party, who makesthe decision based on the reported measurement val-ues.

6 Protection Layer

The purpose of the protection layer is to providemulti-lateral security (requirement c3) and the pro-vision of runtime platform integrity following theinitial measurements. The requirement (c3) is sat-isfied by insisting that each application run in a

protected execution environment, or domain, onthe platform. Each domain belongs to its domainowner, which may be distinct from the platformowner. The security policy of the domain may bedetermined by its domain owner.

6.1 Domains

On a TPod platform, every non-system programruns in a domain. A domain protects data and ex-ecution from other domains. In the TPod domainmodel, there are two levels of access control policy:

1. A mandatory access control (mac) policy thatis enforced system-wide across all the domainson the platform; and

2. A discretionary access control (dac) policythat can be controlled by each domain owner.

The mac policy dominates the dac policy, so thatany discretionary access extended via the dac policymust also be permitted by the mac policy.

If a domain owner decides that the domain will shareparticular resources with other domains or systems,it can do so by allowing such action in the domain’sdiscretionary access control policy (so long as suchaction is not constrained by the mac policy).

The mandatory policy is intended to provide strongprotection of critical resources (such as crypto-graphic keys) even if applications running in thedomain have security vulnerabilities. The discre-tionary policy then allows flexible data exchangeamong applications if so desired.

6.1.1 SELinux

In our TPod implementation, domains are realizedin two ways; as SELinux roles where the access con-

General Hardware

SELinux Kernel

Java VM

OSGi

Trip

wire

/ A

IDE

Plat

ofrm

Adm

inis

trato

r She

ll

Optional H/W TrustO

SGi D

omai

nA

dmin

istra

tion

ePas

spor

t

Plat

form

Use

r

eTic

ket

Dia

ry

OSG

i Pol

icy

(DA

C /

MA

C)

SELi

nux

Polic

y (M

AC

)

enforces

enforces

Figure 6: TPod domain model

trol is enforced by SELinux, and as osgi servicebundles where the access control is enforced by theosgi access control model (see Figure 6).

The use of SELinux is essential to maintain platformintegrity after a trusted bootstrap. All accesses tothe kernel that affect the kernel integrity, such as us-ing /sbin/insmod and accessing /dev/kmem, mustbe prohibited. Therefore, the only way to makechanges in the os kernel (due to a newly issued se-curity patch, for example) is to make the changesin the file system and the reboot the system for thechanges to take effect. All the running applicationsmust be terminated because the platform policy isgoing to change and thus application owners mustreevaluate the new platform policy according to theapplication policy.

6.1.2 OSGi

In addition to the os native domains, our implemen-tation has an additional level of domains for Javaprograms because we expect that many distributedapplications are written in Java and usually Javaprograms are running in a single Java virtual ma-chine, which in turn runs in a single os-native do-main. For this purpose, our implementation usesthe osgi framework [7]. osgi specifies a frameworkdesigned for providing an environment for indepen-

dent Java services. It offers function for provision-ing, administration and life cycle management ofsuch services. Most importantly, it provides domainseparation between “bundles,” which can be consid-ered as domains in our TPod architecture4. Servicesfor user management and for programmatic accesscontrol are available as well.

Typically, a platform contains a single Java VirtualMachine instance, in which a single osgi Frame-work instance executes, and runs all the services.Each Service Bundle has its own classloader, whichis to avoid interference between bundle classes. osgibuilds on top of the standard Java 2 security mecha-nisms. When started with a SecurityManager, theframework will assign each bundle the permissionsestablished via the Permission Admin service.

The osgi User Admin Service persistently storesuser information including properties and creden-tials. Users may be assigned to groups and groupsmay also be assigned to groups.

An Authorization object may be derived for a userand can be later interrogated to determine if theuser has a particular authorization. This offers alightweight model for user authorization in an osgidevice, which is different from jaas for the sake of

4An osgi bundle is a self-contained package of code whichconforms to the osgi interface.

being significantly more lightweight.

6.1.3 Domain instantiation

An application’s life cycle must be able to be man-aged securely, we therefore allow application com-ponents to be encrypted. The management of thisencryption key is critical to providing security, andagain leverages tcg technology (see Figure 7).

When an application domain is first created by theosgi framework, it generates a new encryption keywithin the tpm. All keys created within the tpmmust be children of an existing key, and secret “au-thorization data” for the parent key must be pro-vided to generate a child key. However, the tcgspecification also includes a protocol for handingover authorization data to a second entity, such thatthe first entity does not know the new authoriza-tion data. This protocol is called the AsymmetricAuthorization Change Protocol (aacp, see [3] fordetails).

The framework generates a 256-bit symmetric key— which we call the domain secret — and encryptsthis key using the previously generated keypair5.Once complete, the framework uses the aacp pro-tocol to transfer authorization data for using thekeypair to the application owner. The tpm will notsubsequently allow decryption of the domain secretunless ownership of this new authorization data canbe proven6.

Whilst the osgi framework is running, access to ob-jects in the domain (especially the domain secret)are restricted by the domain’s mac policy, which theapplication owner can reasonably expect to be en-forced, since they verified earlier that the platformwas running an enforcement mechanism they trust.

When the osgi framework is shutdown keys arepurged from memory persistent data encrypted todisk (see Section §6.1.4). When the system comesup again, the domain owner must again verify theplatform’s measurement (Section §5.2) before pro-

5Note that the tcg specification does not mandate thatthe tpm include symmetric cryptographic operations, due toconcerns about cryptographic export restrictions. It is in-tended that the tpm be used as a portal to external bulkencryption facilities.

6The protocol for authorizing actions is called the ObjectIndependent Authorization Protocol (oiap) in tcg terminol-ogy [3].

viding authorization data needed to decrypt the do-main secret.

6.1.4 Persistent storage

Persistent storage is made available as a sub-function of the administration domain. Once thedomain secret is available to the osgi framework,it is used to expose methods which act as a simpleencrypting filesystem (no directories, no symlinks).

The osgi’s UserAdmin bundle and mac policy man-ages the mapping between domains and their do-main secret. Additionally, the domain secret neverleaves the Admin domain; it is only accessed indi-rectly through methods it exposes to other domains.

The application owner may also request, at anytime, that their domain secret be purged from thememory of the Admin domain. In this case, the Ad-min domain will make sure that all streams for thatdomain are closed and encrypted to disk, then purgethe key. If the application owner wants to again ac-cess their encrypted data, they must again initiatean oiap negotiation to allow the tpm to release thedomain secret.

6.1.5 Updating the trusted computing base

The platform owner is ordinarily prevented from in-terfering with the trusted computing base (tcb) bythe SELinux mac policy. Alterations to the policyrequire a reboot, putting the system into a “main-tenance mode” where the policy is not enforced.The platform measurement shows application own-ers that the platform is not enforcing its policy, sothey would refuse to release their domain secrets.

Once the system has been changed, it can be re-booted again and its measurement examined by anyapplication owners for changes. They can then de-cide whether to continue to use the platform in itsnew configuration.

7 Interoperability layer

TPod platforms are intended to be used in heteroge-neous network environments. Each TPod platform

TPoD platform verifiermutual authentication

challenge

host measurement

authorisation to use secret(OIAP)

TPoD platform verifiermutual authentication

challenge

host measurement

domain creation request

Generates newkeypair and

initializes domainstructures

authorisation data exchange(AACP)

authorisation to use secret(OIAP)

Verifier nowhas authorisationdata for keypair(and TPod platformdoes not)

Figure 7: Domain creation protocol (left) and domain secret authorization protocol (right)

may have a different architecture, a different oper-ating system, and a different level of trust. Still theremote applications must be able to interact seam-lessly with different platform. As the foundation ofthis interoperability layer, we selected Web ServicesSecurity [1] because Web Services are gaining im-portance as the most interoperable protocol for dis-tributed programming and its security model is veryflexible to allow extensions necessary to support theTPod-unique features. These extensions are (a) at-testation protocols. and (b) domain instantiationprotocols.

The basic form of attestation protocol is describedin earlier section. Such a message exchange can bedone through a soap Message with Originator In-tegrity Guarantee (moig).

Note that moig messages are usually usedonly when establishing a session context. Asignature-based key exchange protocol in WS-SecureConversation is used for this purpose. A ses-sion key does not live across multiple bootstrap, sowe can assume that the the session key is bound tothe platform configuration that are verified duringthe key exchange.

When a remote application wants to use a TPod

platform, first it must trust the platform. For atrust relationship that is interoperable, the platformmust be capable of exchanging messages based on atrust relationship. The TPod interoperability layerprovides an interoperable trust framework. This isachieved by building protocols that are based onopen standards. This way (1) we should ensure thatany vendor can develop TPod compliant platformsand applications and (2) applications may need tointeract with both TPod platforms and non-TPodplatforms. Web Service Security Protocols [1] andogsa’s security protocols [6] are candidates of suchopen protocols. A TPod realization should enhancethese open protocols to enable platform integrityverification and remote instantiation of TPod do-mains.

8 Discussions

8.1 Covert channels

It is very difficult to eliminate covert channels froma system. The usual mitigation technique is to es-timate and limit the bandwidth of such channels.

We did not perform such an analysis, and the covertchannels that exist on our TPod implementation aretypical of those that exist in SELinux, and an osgiimplementation.

8.2 Resistance to physical attacks

The TPod architecture itself is not intended to pro-vide robust protections against hardware attacks.In fact, it is very hard to design a tamper-resistanthardware that can withstand determined, attack-ers. TPod has different levels of protection profilesfor hardware attacks. The lowest level protectionprofile prevents attackers with basic hardware skills(such as removing and soldering IC chips from/to acircuit board) from bypassing the integrity measure-ment capability. A higher level protection profilewould require that the tpm and the bbb be em-bedded in the processor chip, which would makehardware attacks much harder (but still not impos-sible). A tcg platform certificate contains a link tothe protection profile of the platform so the servicescan make informed decisions on the tamper resis-tance strength of the platform when dealing withhigh-value transactions. In any case, the philosophybehind TPod is the assumption that any securitysystem could be broken someday by somebody. Thedesign goal here is to minimize the damage when asystem is broken.

Based on their “reusability” we can categorizeattacks into two groups: Break-Once-Run-Once(boro) attacks and Break-Once-Run-Everywhere(bore) attacks. A boro attack will break the trustonly a single device. A bore attack will cause a sin-gle breach to break the whole security system. Theglobal secret stored in the XBox game console thatwas revealed by mit researchers is a good exampleof a bore attack [4]. On the other hand, the secu-rity of TPod does not rely on any global secret, so abreach on one platform instance should be containedwithin this instance. If a TPod platform is compro-mised, the certificate (certifying that the platformis a genuine TPod platform) will be revoked. Nofurther damage will be caused by this breach.

A similar argument holds for os vulnerabilities.Since TPod relies on the integrity of a non-trivialoperating system kernel (Linux kernel), it is veryhard to assure that this software is bug free. If aserious security flaw is found in the Linux kernel,all the TPod platforms running the same os ver-

sion can be a target of attacks. So this may appearto be a bore attack problem. However, once sucha security flaw is found in the kernel, all the ap-plication owners can quickly update their trustedpcr databases and then these vulnerable devicesare no longer trusted; that is, the security breachcan be kept to the minimum. For this reason, weconsider exploits of os vulnerabilities also boro at-tacks, when the TPod protection mechanisms areused.

8.3 Comparisons with Next-GenerationSecure Computing Base

Microsoft’s ngscb, scheduled for the next edition ofWindows, can be regarded as an architecture thatsupports a TPod platform, albeit with a differentlydesigned trust layer, and a potentially weaker pro-tection layer. ngscb also takes advantage of thetpm chip, though it does not use an architecturewhere it is booted from a core root of trust; insteadit is started by the ordinary Windows operating sys-tem. Since Windows is not trustworthy, extensivehardware alterations to the traditional cpu, ramand motherboard design are required to prevent ma-licious Windows process from interfering with thengscb load process. However, the advantage gainedby this late load is that non security critical func-tions can be passed to the ordinary Windows os.This keeps the tcb small, and easier to verify.

Although there are mechanisms in place to segre-gate ordinary Windows processes from ngscb pro-cesses, it is unclear from publicly available docu-mentation what multilateral security restrictions ex-ist between ngscb processes. ngscb ties applica-tion secrets to a set of pcr registers (called sealedstorage), whereas our TPod architecture ties thesesecrets to authorization data held remotely by theapplication owner.

It appears that an ngscb-based platform could beconfigured to conform to the architecture we havepresented, though it would lack flexibility. An ap-plication owner would have to “take-it-or-leave-it”,as there is little scope for a host owner to adjusttheir platform to suit different applications whichdemanded different levels of security in their pro-tection layer.

9 Summary

In this paper, we proposed the framework to buildthe trusted computing environment that consist ofheterogeneous platforms with dynamic bindings andthe supporting infrastructures communicating usinginteroperable protocols.

References

[1] OASIS TC draft. Web services secu-rity core. http://www.oasis-open.org/committees/wss/, December 2002.

[2] Trusted Computing Group. TCG PCspecific implementation specification v1.1.https://www.trustedcomputinggroup.org/downloads/TCG_PCSpecificSpecification_v1_1.pdf, September 2001.

[3] Trusted Computing Group. TCG mainspecification v.1.1b. https://www.trustedcomputinggroup.org/downloads/tcg_spec_1_1b.zip, February 2002.

[4] Andrew Huang. Keeping secrets in hardware:The microsoft xbox case study. In CryptographicHardware and Embedded Systems, volume 2523of Lecture Notes in Computer Science, pages213–227. Springer-Verlag, Heidelberg, 2002.

[5] Greg Kroah-Hartman. Signed kernel mod-ules. Linux Journal, 117:48–53, Jan 2004.Available at http://www.linuxjournal.com/article.php?sid=7130.

[6] Open grid services architecture. http://www.globus.org/ogsa/.

[7] Open services gateway initiative (OSGi). http://www.osgi.org/.

[8] L. Van Doorn, G. Ballintijn, and W. A.Arbaugh. Signed executables for linux.Technical Report UMD CS-TR-4259, Uni-versity of Maryland, June 2001. Avail-able at http://www.ece.cmu.edu/~leendert/publications/SignedExec.pdf.