Horst-Görtz-Institute for IT-Security Ruhr-University Bochum

Play it once again, Sam -

Enforcing Stateful Licenses on Open Platforms

Ahmad-Reza Sadeghi

Horst-Görtz-Institute for IT-Security Ruhr-University Bochum

sadeghi@crypto.rub.de

Michael Scheibel

Sirrix AG Security Technologies Bochum, Germany m.scheibel@sirrix.com

Christian Stüble

Horst-Görtz-Institute for IT-Security Ruhr-University Bochum

stueble@acm.org

Marko Wolf

Horst-Görtz-Institute for IT-Security Ruhr-University Bochum

mwolf@crypto.rub.de

ABSTRACT

Various appliations and business models for distributing

digital ontent overopen networks demand for lienses to

ontrol usage of the ontent and restrit aess to it by

authorized entities only. Of partiular interest are state-

fulliensesthatallowusageforaxedtimeperiodorxed

numberoftimes.

However, existing solutions using stateful lienses are vul-

nerabletovariousattaks,partiularlyonopenomputing

platforms that are under onsumers' ontrol who an run

exploitsaswellasreonguretheunderlyingoperatingsys-

tem. Inthisontextreplayattaksplayanimportantrole,

sinethestateofommonstorage(e.g.,hard-disksandash

memory)aneasily be reset tosome priorstate bypassing

aess ontrol mehanismsor breaking ryptographi pro-

tools thatkeepstate. Heneontentproviderstendtoin-

exiblestatiliensesandlosed DRMsystemsthatmainly

provideunilateral seurity,i.e.,protettheneedsofontent

providersandnotofonsumers.

In this paper we present a seurity arhiteture that en-

ablestheseuredeploymentandtransferofstatefullienses

onopenomputingplatformswhile protetingtheseurity

objetives of both users and providers. We show how to

implementthisseurity arhitetureeientlybymeansof

virtualizationtehnology,aseuritykernel,trustedomput-

ingfuntionality, andalegay operating system(urrently

Linux). Moreover, our system extends the TCG hain of

trustonepttoarbitraryomposed(trusted)domains,i.e.,

ourarhiteturemeasuresand reportsthe ongurationof

onlythosesoftwareomponentsthatareseurity-ritialfor

aertainoperationatertaintime.

Keywords

DigitalRightsManagement,statefullienses, freshness,se-

urityarhitetures,trustedomputing

1. MOTIVATION

E-ommereappliationsfortradingdigitalgoodsoveropen

networksarebeominginreasinglyappealing. Inthison-

texttehniques forseure distributionandusageof digital

goods,wherealiensedenestheowner'srightstoonsume

A partiular liense type are stateful lienses whih allow

theuseofrightsforaxedtimeperiod,e.g.,for

n

^days,or

foraxedquantity,e.g.,for

n

^times.

A fewe-business appliationsalreadyemploysuh(mostly

proprietary)statefullienestosellertaindigitalgoodsfor

limiteduse. Importantreferenesarevideo-on-demandser-

vies or online video rentals [8, 47, 29℄ that use stateful

lienes to enable exiblepay-per-view senarios. Various

digital musi stores[3℄ use stateful lienes to ontrol the

maximum number of analogue opies allowed. Moreover,

some software vendors already employ stateful lienses to

oer trial versionsthatallow userstotest asoftware for a

limitedtimeorallowalimitednumberofexeutions[25,59℄.

Statefullienesenablenewpromisingpay-per-usesoftware

businessmodels.

Inaddition,oneanthinkofotherinteresting appliations

usingstatefullienes toenforepoliies: Forinstanesen-

sitive user data suh as email orrespondene or identity

informationis beingstoredonremoteserverstoday. Often

theusersarenotfullyawareofthedatatraestheyleaveon

remoteservers. Inother asesusers have to provide some

personal information in order to use a servie. However,

users musthavethe right and be able to deide andlimit

the usageofthis information byanythirdparty (e.g.,ser-

vie provider). Another appliation is whendigital musi

storesallowtheirustomersforinstanetohearatraktwo

timesfor freebeforeoeringtheaquisitionofaliensefor

unlimitedaess. Statefullienesanalsoenforeone-time

aessto sensitivedata. Thus,forinstaneaompanyan

preventtheiremployeesfrommakingunauthorizedopiesor

forwarding ofsensitiveontent thatouldleak information

toitsompetitors.

Another important issue beside the seure usage of state-

ful lienses is the seure transfer of lienses among dier-

ent platforms. This inludes also seure lendingor selling

(sub-)liensestootherindividualswithoutrequiringthein-

teration of the liensor. In this ontext the liense itself

desribestheonditionsunderwhihatransferofthe on-

tent, it is attahedto, is authorized. For example, the li-

enseewouldnotbeallowedtofreelyopy theontent,but

wouldinsteadbeallowedtomoveittoertaindevieswith-

out Internet onnetivity. Suh resaleand sub-liensing is

transation,usuallyrequiresinterationwiththeliensor.

However, managingandenforingstatefullienses onopen

platformsispartiularly vulnerableto variousthreats suh

as unauthorized aess, misuse, and illegal redistribution

of the ontent to be proteted [24, 49, 50℄. Open plat-

formsareundertheontroloftheirowners,whoanattak

and irumvent even sophistiated protetion mehanisms

byrunningexploits andreonguring theunderlyingoper-

atingsystem. Partiularly replay attaks set the platform

state(e.g.,hard-disksandashmemory)andthusastateful

liensetoapriorstateandirumventseuritymehanisms.

Thisan be done for instane by ordinary bakup meha-

nismsorbyapplyingsoftware tools[11℄thatlogallstorage

modiationstoeasily revokethesemodiations for reuse

ofaliense 1

.

Consequently,ontentprovidersusetamper-resistanthard-

ware devieslikedongles [30℄ orsmartards [4℄ toseurely

storeasmallamountofdatatoprotettheirassets. Theuse

ofexternaldevies,however,annotguaranteetheintegrity

ofthe operating system and aproper behavior of applia-

tions sine debugging utilities and other manipulations of

theoperatingsystemorappliations frequentlyallowusers

tobypassseuritymehanisms.

2

Thus, ontent providers urrentlytend to inexible stati

liensesandlosed DRMsystems. Theproblemwithlosed

DRMsystems,suhas[16,28℄,isthattheymainlyprovide

unilateralseurityprotetingtheneedsofontentproviders

andusually notonsumers 3

Moreover, ommonDRM sys-

tems do not provide adequate stateful lienses and thus

heavilyrestritusers'rights,e.g., bypreventingthemfrom

transferringlienses(thatinludesliensemoving,resaleor

renting).

1.1 Main Contribution & Outline

Inthispaperwepresentaseurityarhiteturethatenables

seureenforement of stateful lienses onopen omputing

platformsandseureliensetransfersamongplatformswhile

protetingtheseurityobjetivesofusersandproviders. To

thebestofourknowledgethereurrentlyexistsnosolution

that is apable of enforingstateful lienses onopen plat-

formswhileprovidingseurityfuntionalitiesallowingtoes-

tablishmultilateralseurity.Weshowhowourarhiteture

aneientlybeimplementedusing existingvirtualization

and trustedomputingtehnology. In ontrast to existing

solutions,oursystemarhiteturemeasuresandreportsthe

onguration of only those software omponents that are

seurity-ritialforaertainoperation,insteadofreporting

theonguration ofall urrentlyrunningsoftware ompo-

nentsthatlearlyaetuser'sprivay.

1

Cryptographimeasureslikedigitalsignatures,enryption

and evenryptographi le systems[7, 57℄ annotprotet

stateful lienses, sine a omplete bakup an still be re-

played.

2

Inpartiular,donglesturnedouttobeimpratialforthe

mass marketbeause of missingonsumerfriendliness and

highosts[2℄.

3

Thisisonformtothelegislativetrend(see[31℄)ofputting

morerestritionsononsumers'rightsonusingdigitalon-

marize related work. We thendene inSetion2 anideal

system model for distributed ontent aess that satises

ourstatedseurityobjetivesoftheinvolvedparties. Going

towards the real worldwe replae the ideal model inSe-

tion3byseverallogial omponentsthatare implemented

byrealsoftware omponentsofarstprototypeimplemen-

tationbasedonasmallseuritykernel,virtualizationteh-

nologyandtrustedomputingtehnology(Setion4).

1.2 Related Work

ShapiroandVingralek[45,56℄identiedthereplayproblem

inlientplatformsthatareompletelyundertheontrol of

theuser. Theauthorsproposedtomanagepersistentstates

usingexternallokerserviesorassumedasmallamountof

seure memory(i.e.,that annotbe reador writtenbyan

attaker) andseureone-wayounters realizedbybattery-

bakedSRAMorspeialon-hipEEPROM/ROMfuntions.

Tygar and Yee [55℄ elaborateonappliations ofphysially

seureoproessors,inludingenforementofstatianddy-

namilienses withoutentralizedservers. Theyshowhow

toprotetand attesttheintegrityoftheir systemwiththe

helpofaseureoproessorandaseurebootstrapproess.

Inaddition,protoolsforsealingofdatatoaloalplatform

and binding of data to a remote platform are presented.

Theyidentifythereplayproblemintheontextofeletroni

urrenyandpropose"two-phase"ommitstoensureatomi

transferstoremoteplatforms. Theproposedarhiteurere-

liesonamirokernelwhihisrunninginaphysialseurity

partitionprovidedbytheseureoproessor. Thisisdier-

enttoourapproahwhihisbasedonavirtualizationlayer

oeringlogialseuritypartitions("ompartments").

Marhesinietal. [22℄useOShardeningtoreate"software

ompartments"whihareisolatedfromeahotherandan-

notbeaessedbya"rootspy".Basedthereon,theirdesign

provides "ompartmentalized attestation", i.e. attestation

ofandbindingdatatosingleompartments.Ourapproah

doesnotemployOShardeningtehniquestoseureaom-

plexmonolithilegayOS.InsteadweputthelegayOSin

aompartmentwhihisthenrunontopofavirtualization

layer. Theperformane loss is negligible, butthe inrease

inseurityisnot,sinethevirtualizationlayerismuhless

omplexthanamonolithiOSkernel.

Baek and Smith [6℄ build on this work and implement a

prototypeforenforingQoSpoliiesonopenplatforms.

PublilyavailabledoumentationonbothDRMimplemen-

tations ofMirosoftWindows RightsManagementServies

[27℄ and AuthentiaAtiveRights Management [5℄ donot

mentionhowtheyresistreplayattaks. Onealientappli-

ationisauthorizedtoaessadoument,itanbakupand

restoreitsstateto entirelyaessall doumentsat bakup

time.

ThesameholdsforommonDRMimplementationsfordig-

ital ontents (audio, video, ebooks, software), e.g., Miro-

soft'sWindowsMediaRightsManagement[26℄,Apple'sFair-

Play[3℄ andReal Network'sHelixDRM [36℄,all providing

annotbe veriedfor inherent seurity aws. Some aet

the entire host seurity [24℄ or violate user privay [46℄.

Many ould be ontinuously broken [50, 49℄, and provide

liensetransfersonlytosomeseleteddeviesownedbythe

user. This pointlearly ontraditsthe rstsale dotrine:

Theliensorshould beallowedtotransfer legallyobtained

digital ontent withoutpermission or interation ofthe li-

ensee.

Anotherapproahusessmall-valueorshort-termsub-lienses

basedonasinglesoureliensetotransferrights.Examples

aretransientlienses[35℄,rehargeabletokens[17℄,ortrak-

ingles [20℄. Sine usersof thesesystemsalwayshavefull

ontrol over the platform storage, they an easily bakup

their(sub-)liensesandrestorethemafterexpiration.

In[42,44℄,theauthorsproposeanoperatingsystemexten-

sionthatattestsanintegritymeasurement(aSHA-1digest

overallexeutedontent)basedonaryptographi opro-

essor. Theproposedarhitetureallowsaontentprovider

to remotely verify the integrity of software and data of a

lient platform. Sinethis approahmeasuresall exeuted

ontent, i.e., also all non-seurity-ritial and private on-

tent,this proedure givesa ontent provider user's overall

platformonguration. Sinedeliveringtheompleteplat-

formongurationrevealsalotofadditionalinformationnot

requiredfor liense enforement this wouldlearly onit

withtheleastprivilegeseurityproperty,thusaetingusers

privay. Ontheotherhand,theontentprovideranattest

alwaysonlythelastplatformongurationgivenandisnot

abletopreditfutureonguration. Todetetpotentialre-

playattakstheontentproviderwouldfurthermorehaveto

requestand storelient measurement logsrepeatedly. Be-

sides the neessary online onnetivity, a lient ould still

applyreplayattaksbetweentwomeasurements.

TheEnforer projet aliasThe Bear [21,23℄ tried toreal-

izefreshness using the(non-volatile)dataintegrity register

(DIR)oftheTCGspeiationversion1.1b[54℄. Writingto

aDIRrequiresownerauthorization,readinganbedoneby

anyone. However,this approahannotbeusedto enfore

stateful lienses sine the platform owner anstill bakup

andrestoretheDIRstorage.

NewproessorarhitetureslikeAEGIS[48℄andXOM[18℄

provideseurein-proessor storagethatannotbereset by

unauthorized entities. Although it seems possible to use

these proessor arhitetures as abasis for proteting the

freshness of information, we hose another solutionwhih

buildson(heaper)ommerial-of-the-shelfomponents.

2. SYSTEM MODEL AND OBJECTIVES

Westart ouronsiderationwithanideal systemmodelfor

distributed ontent aess 4

. It represents the desired en-

vironment in whih the seurity objetives of all involved

partiesaresatisedbydenition. Inlatersetionswegoto-

wardsrealworldbyreplaingthisidealsysteminSetion3

4

Wedonotonsiderpaymenthannelsorontentdistribu-

tiondetailssuhas ontent provisionor liensegeneration

here. System models for omplete DRM systems an be

oftheseomponentsbysoftwareomponentsinSetion4.

2.1 Terms and Definitions

We dene aompartment as asoftware omponent that is

logiallyisolatedfromothersoftwareomponents. Theon-

guration of a ompartment unambiguously desribes the

ompartment's I/O behavior based on its initial state

S 0

anditssetofstatetransationsthatonveyaompartment

fromstate

S i

^tostate

S i+1

^.Moreover,wedistinguishseure, trusted, and plain ommuniation hannels between om-

partments. Plainhannels transfer datawithoutproviding

any seurityproperty. Seure hannels ensureondential-

ity and integrity of the ommuniated dataas wellas the

authentiity 5

of theendpointompartment. Trusted han-

nels are seurehannelsthat additionallyvalidatethe on-

guration of the endpoint ompartment. Finally, integrity

of informationobtained fromahannelor ompartment is

provided,ifanymodiationisatleastdetetable.

2.2 Ideal System Model

Themainpartiesinvolvedareproviders(liensors)andusers

(liensees). We onsider a provider as the representative

party for rights-holders whereas the user represents on-

sumersofdigitalontent. AsdepitedinFigure1thepro-

viderdistributesdigital ontent(e.g.,software, mediales,

et.) andtheorrespondingliense. Theliensedenesthe

usage-rights (e.g.,opy,play, print,et.) appliable to the

ontent. liense representsaertiateissuedbyanautho-

rized instane (liensor) onrming non-repudiability that

ertainusage-rightsonertainontentsaregrantedtosome

party 6

. Here, a liense desribes the usage-rights that its

ownerholdsandtheprerequisitestoonsume(aess,use)

the ontentslinked tothis liense. Theuseronsumes the

ontent aording to theliense where the onsumption is

managedbytheunderlyingplatformasshownbythedashed

linesinFigure1. Intheidealmodeltheplatformisanab-

stratblak box whihistrustedbyall otherparties. The

usage-rights an be dened in rights expression languages

suhas XrML 7

or ODRL 8

and are digitally signed by the

liensor. Wedistinguishtwotypesoflienses,statilienses

and statefullienses. Whilethestateofastatiliense re-

mainsunmodiedwhenused,thatofastatefulliensemay

hangeduringitsutilization.

Theinvolvedpartieshaveonlylimited trustineahother.

Inour ideal system model theplatform isfully trustedby

bothuserandprovidertoatorretly.

In Figure 1 we also made the next step by replaing the

abstratplatformbytwologialompartmentstheTrusted

Poliy Enforer and the Trusted Storage Provider instead

of the platform as an abstrat. These ompartments are

strongly isolated from eah other and ommuniate over

trustedhannels.

5

Aompartment'sauthentiityouldbeanaliasoratem-

poraryompartmentidentier.

6

Aformaltreatment ofrights,liensesandtransationson

rightsanbefound,e.g.,in[1℄.

7

www.xrml.org

8

User

request[usage-right]

render[content]

Trusted Policy Enforcer

store[object]

load[object]

Trusted Storage Provider

Platform Interface

distribute[content, license] Provider

Figure1: Theidealsystemmodel.

TheTrustedPoliyEnforer (

TPE

⁾inorporatestheusage- rights management and ontent rendering. The provider

usesthetrustedhannel

distribute[]

^{totransfer ontentand}

lienses to

TPE

^{. On request of the user via}

request[]

^{, a}

usage-rightisretrievedandtheontentisrendered aord-

ing tothis right usingthe trustedoutput hannel

render[]

^.

TPE

^{orretlymaintainsitsstateusingthetrustedhannels}

store[]

^and

load[]

^{providedbythetrustedstorage.}

TheTrustedStorageProvider (

TSP

^{)providestheinterfaes}

store[]

^and

load[]

^{tostoreandloaddataobjets}persistently ensuringondentiality, integrity, availability and partiu-

larlyfreshness. Note,userandprovidertrust

TSP

^onlyin-

diretly,i.e.,byestablishingatrustedhannelto

TPE

^.

TPE

willonlybetrustedifit hasveried

TSP

^{to betrusted by}

establishingatrustedhannelto

TSP

^.9

2.3 Security Objectives

In the following we dene the overall seurity objetives

ofusers and providersthat our systemarhiteture hasto

ahieveforourdistributedontentaess.

(O1) Liense integrity: Unauthorized alteration of li-

ensesmustbeinfeasible. Bothuserandproviderre-

quire this, sine a liense denesa ontrat between

user and provider that must not be altered without

mutualapproval.

(O2) Lienses unforgeability: Unauthorized issuane

ofliensesmustbeinfeasible. Onlyauthorizedparties

(rights-holder)are allowed to issue new usage-rights.

Thispreventsreationofillegal,unauthorizedlienses.

(O3) Liense enforement: The liense must be en-

foreduponaeptane. Thisisrequiredbythelien-

sorthatthe useranaessand usetheontent only

aording touser-rightsprovidedbytheliense. Oth-

erwise, usersouldviolateaontratwithaprovider.

However, aliense should beenfored onlywhenthe

userasaeptedit.

(O4)Lienseavailability: Legallyobtainedliensesan

be usedatany time. Thisespeiallyrequires preau-

tionswithregardtophysialand/orlogialfailures,as

aresultofthepoorexperieneswithhithertoexisting

dongles andsmartardssolutions.

(O5) Privay: Usage of lienses must not violate pri-

vaypoliies. Theuser'sprivaypoliy mustbepro-

tetedwhenperformingtransationsonlienses. This

9

Sine

TPE

^{ommuniateswith}

TSP

^{overatrustedhannel,}

itanbeentralordistributed,e.g.,loatedatuser-side,at

provider-side,orrealizedbyatrustedthirdparty

TTP

^.

inludes that the overall system enfores least privi-

lege suh that omponents not under full ontrol of

theuser,ollet,store,andredistributeuser'sprivate

informationonlytotheextentrequiredforlienseen-

forementandwithuser'sonsent.

(O6) Freshness: Any information obtained should be

new,i.e., reeivedor retrievedinformationis thelast

onesentorstored.

2.4 Required Security Properties

Inordertofullltheoverallseurityobjetivesweonsider

inthefollowing theessentialproperties whihareassumed

to be given intheideal system model(inSetion 2.2). In

Setion 3and Setion 4 we show howone anprovide re-

spetivelyimplementtheseproperties.

(R1) Trusted hannels: Theunderlying platformpro-

vides trusted hannels between ompartmentsto en-

able a party to verifya ompartment'songuration

inorderto determinetheompartment'strustworthi-

ness.

(R2)Strongisolation: Theunderlyingplatformensures

that ompartmentsareisolated from eahother, i.e.,

ompartmentsannotaessthe statesof otherom-

partments.

(R3) Trusted storage: Atrustedstorageprovider

TSP

provides ondentiality,integrity,freshnessand avail-

abilityofdatapersistentlystored.

2.5 Usage and Transfer of Licenses

Basedonouridealsystemmodelandtheassumptions,this

setion desribes the general funtionality of our arhite-

ture with regard to obtaining, usage and transferring of

stateful lienses. The mainplatform omponentsinvolved

inthesetransationsareillustrated inFigure1.

Obtaining lienses: Therstshemedesribeshowa li-

ense

l

(andtheorrespondingontent)is obtainedby the platform omponent

TPE

responsible for enforingit. We assumethattheliensenegotiation phasehasalreadybeen

ompleted(outsideourmodel).

1. Theuserrequeststheproviderthe(negotiated)liense

l

fromtheproviderandtherespetiveontent(ifnees- sary,i.e.,iftheuserdoesnotalreadyhastheproteted

ontent).

2. Theproviderestablishes aremotetrusted hannel to

TPE

^{(toverify that the ongurationof}

TPE

^{is on-}

form to his seurity poliy.). Then the provider dis-

tributes

l

andtherespetiveontent(if neessary)to

TPE

^.

3.

TPE

^stores

l

and the orresponding ontent on

TSP

usingaloaltrustedhannel(thusverifyingtrustwor-

thinessof

TSP

^.).

Using stateful lienses: The following shemeis anab-

stratdesriptionofhowtheontentandtheorresponding

lienseareseurelymanagedby

TPE

^.

1. Theuserrequests

TPE

^forausage-rightonaontent.

2.

TPE

^{loads from}

TSP

^{a liense}

l

that overs the re- questedusage-right.

3. If allonditions fortheorrespondingusage-right are

fullled,

TPE

^updatestheorrespondingsubsetofstate variables within

l

, stores the hanged

l

using

TSP

again,andinvokestheontentrendering.

Transferring lienses: Wedesribeaseuretransferpro-

toolofaliense(andtheorrespondingontent)betweena

soureplatform(transferor)

TPE ^s

^toadestinationplatform (transferee)

TPE d

.

1. Theuserrequests

TPE s

^{totransferaliense}

l

to

TPE d

^.

2.

TPE ^s

establishesatrusted hannelto

TPE ^d

^{to verify}

thattheongurationof

TPE d

isonformtotheseu- ritypoliyof

l

neededfor atransfertoorretlytake plae. Notethat

TPE ^d

^{doesnot needthis veriation}

for

TPE s

sinetheoverallseurityarhiteturewould not allow a platform to use a liense if it does not

providethetrustpropertiesrequiredbytheliensor.

3. Afteratrustedhannelisestablishedto

TPE d

,

TPE s

sends

l

(andtheorrespondingontent)to

TPE d

using thepreviouslyestablishedtrustedhannel.

4. Afteranapprovedtransfer proessbasedonarypto-

graphi reeipt,

TPE s

updatesor invalidates

l

, while

TPE d

^{stores the new liense (and ontent) synhro-}

nizedwith

TPE ^s

^{. Inordertohandle}transmissionfail- ures,

TPE s

allows arbitrary retransmissions requests to

TPE d

^{while the}orrespondingusage-rightremains invalidated.

Theproeduretoloanalienseissimilartotheliensetrans-

fer: Inasethelienseofallows theusertogeneratesubli-

enses

TPE s

generatesasubliense

l d

ofthemasterliense

l

for

TPE d

^andinvalidatesthe respetiveusage-rightsinthe orresponding masterliense

l

loally, i.e, disables the re- spetive usage-rights for the loan period or dereases the

respetivestatevariables.

Aseure implementationof theseprotools is desribedin

Setion3.5.

3. SYSTEM DESIGN

Inthis setion we desribethe high-leveldesignof ourar-

hiteture. TheidealsystemmodelinSetion2.2isdeom-

posedintoseveralsmallerompartments.Wedesribehow

trusted hannels, strongisolation, and trusted storage are

realized. Finally,weonsiderinmoredetailhowanapplia-

tion,i.e., theDRMontroller,anobtain,use andtransfer

astatefulliensebasedonthesefeatures.

3.1 Architectural Overview

Figure2givesanoverviewoftheompartmentsintowhih

ouridealsystemmodelpresentedinSetion2.2anbede-

omposed. Theresultingarhitetureonsistsofthetrusted

Manager, a Storage Manager, and a Compartment Man-

ager. Anotherompartment, the DRM Controller, is the

example appliation that uses the TCB to realize the use

ases disussed above. Note sine all ompartments om-

muniatewitheahotherusingtrustedhannels, thereare

norequirementsontheiratualphysialloation.

Compartment Trusted Channel Storage

Manager

Trust Manager User Manager

Compartment Manager

Secure I/O

DRM Controller

current user content,

license

content

compartment configuration compartment

configuration

TPE Interface

TSP Interface

Secure Channel Remote

Compartment

state

Figure 2: Compartments ofthe systemmodel.

User Manager: The User Manager (

UM

^{) mapsbetween}

realusernamesandsystem-internaluseridentiers. More-

over,itperformsuserauthentiationand managesaseret

attahedto eahusers, e.g., toallow theStorage Manager

to binddatatoauser. Theprogramminginterfaeoered

bytheUserManagerhidestheonreteusermodel. Thus,

itispossibletouseaUNIX-likeusermodel,orarole-based

modelwithoutmodiationsofothersystemomponents.

Storage Manager: TheStorage Manager (

SM

^{) provides}

persistent storage for the other ompartments while pre-

serving integrity, ondentiality, availability and freshness

ofthestoreddata. Moreoveritenforesstrongisolationby

binding the stored datato the ompartment onguration

and/or userserets 10

. TheStorageManager hasaess to

the ongurationofitslients,sineit ommuniateswith

themovertrustedhannels. Foramoredetaileddesription

oftheimplementation,seeSetion3.3andSetion3.4.

Compartment Manager: The Compartment Manager

(

CM

^{) manages reation, update, and deletionof ompart-}

ments. It ontrols whihompartments are allowed to be

installedandenforesthemandatoryseuritypoliy. During

installation ofompartments,itderivesitsongurationto

beabletooeramappingbetweentemporaryompartment

identiers 11

andpersistentompartmentongurations.

Trust Manager: The Trust Manager (

TM

^{) oers fun-}

tions that an be used by appliation-level ompartments

to establishing trusted hannels betweenremote and loal

ompartments.

Seure I/O: TheSeureI/O(

SO

^{) renders(e.g.,displays,}

plays, prints, et.) ontent while preventing unauthorized

information ow. Thus

SO

inorporates all ompartments 10

Sine

SM

^{does notprovidesharingof databetween om-}

partments,itdoesnotrealizearegularlesystem.

11

Aompartmentidentierunambiguouslyidentiesaom-

trustedGUI,et.).

DRMController: TheDRMontroller(

DC

^)isanapplia-

tionthatenforesthe poliyaording tothegivenliense

attahed to digital ontent.

DC

^{enfores seurity poliies}

loally, e.g., it uses trusted hannels to deide whether a

ertain

SO

^{istrustedforrenderingtheontent,i.e.,whether}

itmathestheongurationdesribedintheliense. More

detailsoftheimplementationoftheDRMontrolleranbe

foundinSetion3.5.

Withthearhiteturaloverviewinmind,weexplain inthe

following setions how this arhiteture is used to provide

theneessaryseurityproperties,i.e.,privay,trustedhan-

nels,seurestorage,andfreshstorage.

3.2 Trusted Channels

AordingtothedenitioninSetion2.1,trustedhannels

allowthe involvedommuniationend-pointstodetermine

theirongurationandthustoderivetheirtrustworthiness.

Other integrity measurement arhitetures, however, [42,

44℄, report the integrity of the whole platform ongura-

tion inluding all urrently running ompartments to re-

moteparties, and thusviolating userprivay. Inontrast,

ourarhiteturesupportsto establish trustedhannelsbe-

tweensingleompartments,andnotonlybetweenplatforms

wholeplatforms. Thishasthefollowingadvantages:

•

^{Privay: Aremotepartynowonlyneedstoknowthe}

ongurationoftheappropriateompartmentinlud-

ingitstrustedomputingbase,andnottheongura-

tionofthewholeplatform.

•

Salability: Remotepartiesdonothave toderivethe trustworthinessof all ompartmentsexeutedontop

of the platform, to determine the trustworthiness of

theappropriateompartment.

•

^{Usability: Sinea}ompartment'strustworthinessan bedeterminedindependentofotherompartmentsrun-

ninginparallel,thederivedtrustworthinesskeepsvalid

even if the user installs or modies other ompart-

ments.

Trustedhannelsanbeestablishedusing thefuntionsof-

fered by the Trust Manager and the Compartment Man-

ager,whiletheCompartmentManager,whihisresponsible

forinstallationandmanipulationofompartments,provides

the mapping from ompartment identiers into ongura-

tions. Thus, trustedhannels anbeestablished assuming

thattheTCBinludingtheCompartmentManagerandthe

TrustManageristrustworthy. InSetion4,wewillexplain

howremotepartiesandeterminethetrustworthinessofthe

TCB,butnowweontinuedesribingthe establishmentof

trustedhannelsonthisdesignlevel.

Wedistinguishbetweentrustedhannelsbetweenompart-

mentsrunningonthesameplatform(loaltrustedhannels)

andtrustedhannelsbetweenaremoteandaloalompart-

reeiverare exeutedontopof thesame TCB, anexpliit

veriation of the TCB's trustworthiness does not make

sense in this ase. Therefore, trusted hannels an easily

beestablishedusingseurehannelsoeredbytheunderly-

ing TCB,andthe funtionsprovidedby theCompartment

Manager: Thesendingompartmentrstrequeststheon-

guration of the destination ompartment from the Com-

partmentManager. Onsuessfulvalidationthat the des-

tination onguration onforms to its seurity poliy, the

soureompartmentestablishesaseurehanneltothedes-

tinationompartment.

RemoteTrustedChannels: Therequiredstepstoestab-

lisha remotetrustedhannel froma remoteompartment

totheloalompartmentareasfollows (mp. Figure3):

Trusted Channel Secure Channel (1) request-trusted-channel[]

(6) trusted-channel-response (7) data (2) request-trusted-

channel[] (5) trusted-channel-response

(3) comp-id LC

(4) comp-conf LC

Plain Channel

Figure3: Aremotetrustedhanneldependsonloal

and remoteseurehannels.

Ifaloalompartmentreeivesarequest(1)fromaremote

ompartment,theloalompartmentrequeststheTrustMan-

ager (2)to reeive a redential inluding its own ongu-

ration. Then the Trust Manager generates the redential

basedonboth theompartmentonguration providedby

theCompartmentManager(4)andtheongurationofthe

platform'sTCB.Theresultingredentialisreturnedtothe

invokingloalompartment(5)thatforwards it(6)to the

remoteompartment. Thatannowverifythetrustworthi-

ness of the loal ompartment and, on suess, using the

redentialtoopenatrustedhannel.

Setion4.2 desribestherealizationof theTCBredential

andSetion4.3desribestheproposedprotoolinmorede-

tail. Moreover,itshowshowtorealizetheredentialsbased

onX.509ertiates.

3.3 Strong Isolation

Inordertostronglyisolateompartmentsfromeahother,

isolationatruntimeaswellasisolationinpersistentstorage

isrequired. Onthisdesignlevel,weassumethatruntimeiso-

lationisprovidedbytheunderlyinglayer(seeSetion4.1.2).

Isolationofthepersistentstatesofompartments,however,

isprovidedbytheStorageManager(

SM

^).

TheStorage Manager binds all ofthe ompartment'sdata

totheorrespondingompartmentongurationwhilepre-

serving integrity and ondentiality. In this ontext, bind

meansthataesstobounddataisonlypossibleunderthe

termsdenedonstorage,e.g., aertain ompartment on-

over trusted hannels, it an be loated at user-side, at

provider-side, or realized by a trusted third party.

12

Our

seurity arhiteture uses aloal Storage Manager for the

followingreasons: First,aesstothestorageisneededev-

erytimeastateful lienseis used. Usingaremotestorage

requires an instant online aess and limits the frequeny

of possible state updates. Seond, maintaining a trusted

hanneltoanexternalstoragelearlyinreasesoverallom-

plexity and failure probability of thesystem. An external

storageisasinglepointoffailure. Adenialofservie(DoS)

attak,forinstane,violatestheavailabilityrequirementof

allstatefullienses.

Untrusted Plain Channel

Trusted Untrusted

Storage Compartment

Manager User Manager

Compartment

Storage Manager

user id state

protected state compartment

configuration

Trusted Channel Secure Channel

Figure 4: The Storage Manager enfores strongof-

ineisolation.

Figure4depitstheinvolvedompartmentsanddependen-

iesto realize oineisolation of ompartments. TheStor-

age Manager uses the Compartment Manager to retrieve

theoriginompartmentonguration,theUserManagerto

bindompartment'sdatatoaertainuser(ifrequested)and

anuntrustedstorageompartmenttopersistentlywriteand

readplaindata 13

. Internally,StorageManagerusesrypto-

graphifuntionstopreserveondentialityandintegrityof

databeforeitisommittedtountrustedstorage.

3.4 Trusted Storage

Thefollowingsetiondesribeshowthetrustedstoragepro-

vider

TSP

^{anberealized. Providingaompletelytamper-}

resistant trusted storage ompartment would learly raise

ostsandlimitexibility.Hene,welookforamoreeient

approah. Tokeepthe high-level arhitetureindependent

ofaonreteinstantiationoftheunderlyinghardwareplat-

form,thedesigndeisionistoprovidealogialserviethat

protetsthefreshnessofarbitrarydata.Moreonretely,we

extended

SM

^{that alreadyprovides isolated seurestorage}

(seeSetion3.3)bya freshnessproperty. Inorder toreal-

izefreshness detetion,

SM

^{has exlusive aess toa small}

12

Mirosoft's Media Rights Manager [26℄, for instane, ap-

pliestheprovider-sideapproahwherealoalstoragelient

regularly onnets toanexternal ontent protetion server

toenforefreshness.

13

Fortherealizationofavailabilitywesuggestommonsolu-

tionsbasedonhighredundany,i.e., utilizationofmultiple

distributedstorageloations(e.g.,USBstiksoronlinesites)

assistedbyanappropriateRAIDsystem. Inaseoffailure

ofapartiularstorage devie,itis stillpossible toretrieve

3.5 DRM Controller

TheDRMontroller

DC

^{onsistsofaliense}interpreterand aontentaessarbitration. Itistheoreomponentforthe

seureusageandtransferoflienses(seeSetion2.5)where

lienses are denedby anXrML liense le. All available

ontents and lienses are internally indexedto provide all

neessary information about the available ontentsand li-

enses tothe user. Theindex itself, the ontents,and the

lienses are persistentlystored usingthe Storage Manager

(f. Setion3.3)that enforesthestorageseurityrequire-

mentsofbothuserandprovider(f. Setion2.4).

Theprerequisitesforusageandtransferofliensesisaproper

initialization ofthe platform andthe DRM Controller. In

thefollowing,weassumethat(i)theTCBhasbeenloaded

properly, (ii) the Trust Manager ontains the appropriate

redential,(iii)theDRMControllerhasbeenmeasuredand

startedbytheCompartmentManager,and(iv)theompo-

nentsformandatoryseuritypoliythatrelatetotheDRM

Controller are part of its onguration. On startup, the

DRMControllerloadsitsatualontent/lienseindexfrom

theStorageManageroveraloaltrustedhannel.

Toobtainliensestheproviderestablishesaremotetrusted

hanneltothe DRMController,and ifsuessful,the on-

tent and the lienseare sent to the DRM Controller om-

partmentoverthishannel. TheDRM Controller updates

itsindex. Onshutdown,itstoresthelienseandtheorre-

spondingontentusingtheStorageManager. Sinetheom-

muniationis performedoveratrusted hannel, theDRM

ControlleranverifywhethertheStorageManageristrust-

worthyfortothegivenliense.

For usingstatefullienses the userinvokesthe DRM Con-

troller. Anexampleimplementationwouldbetouseaom-

muniationlientthatenablesrequestsfromthelegayLinux

totheDRMController. TheDRMontrollerloadstheor-

respondinglienseandheksifallonditionsfortheorre-

spondingusage-rightsarefullled.Itthenveriesthetrust-

worthiness ofan appliable outputdevie, e.g., the seure

userinterfae,byopeningatrustedhanneltoit. Onasu-

essful liense overage, the DRM Controller updates the

orresponding subsetof state variables within the liense,

synhronizesitsinternalstatewiththatstoredbytheStor-

ageManager,loadstheorrespondingontent,andinvokes

theoutputdevietoseurelyrenderthegivenontent.

Forthetransferofstatefullienses,againtheuserinvokesa

loallyrunningDRMControllertotransferaertainliense

to a remote DRM Controller onthe destination platform.

ThesoureplatformusestheTrustManagerto establisha

remotetrustedhanneltothedestinationplatformtosend

theliense(andtheorrespondingontent)toit. Inasethis

is suessful the soureplatform updatesresp. invalidates

itsindexandsynhronizesitsinternalstatewiththeStorage

Manager. Thedestination platformstores thenew liense

(andontent)usingitsownstorageManager.

Theseurityof therealizationdisussed abovedependson

ertainassumptions,i.e.,aseurehannelbetweenompart-

ourarhitetureprovidesthem.

4. IMPLEMENTATION

In this setion we desribe details of our implementation.

Werstgiveanoverviewtodesribethe operationalbasis

providing theseurity propertiesdemandedinSetion2.4.

Furtheron,webrieyexplaineahthelayersourimplemen-

tation,theinitializationproessaswellas theimplementa-

tionof theore omponents,namelythe Storage Manager

andtheDRMController.

4.1 Implementation Overview

Ourimplementationprimarilyreliesonasmallseurityker-

nel,virtualizationtehnology,andTrustedComputingteh-

nology. Theseuritykernel,loatedasaontrolinstanebe-

tween the hardware and the appliationlayer, implements

elementaryseuritypropertiesliketrustedhannelsandiso-

lationbetweenproesses. Virtualizationtehnologyenables

reutilization of legay operating systems and present ap-

pliationswhereasTrustedComputingtehnologyservesas

rootoftrust.

OurabstratdenitionsfromSetion2.1anbemappedto

real world implementation. Thus a ompartment mapsto

anappliationproess, whilea ompartmentonguration

mapsto asoftware binaryinluding the initialstate of all

variablesandtheinstrutionset.

Themoredetailedarhitetureofourrealizationisdepited

in Figure 5. The bottom layer is onventional hardware

withadditional Trusted Computing(TC)support. Above

thehardware layerresidesourseurity kernelonsistingof

avirtualizationlayerandatrustedsoftwarelayerproviding

sharingof hardware resouresand realizing elementaryse-

urity andmanagementservies that are independent and

protetedfromalegayOS.Ontopoftheseuritykernel,a

para-virtualizedlegayoperating system (urrentlyLinux)

inludinglegayappliations,theDRM ontroller,andthe

SeureI/Oareexeutedinstronglyisolatedompartments

runninginparallelasuserproesses.

Trusted Software Layer

Virtualization Layer

Hardware Layer Application Layer

Conventional Hardware

DRM Controller Application

TPM 1.2 IPC, Hardware Sharing, Memory Management, Scheduling...

Legacy Operating System Application Application

Untrusted Storage

Trust Manager Storage

Manager

User Manager

Compartment Manager

S e c u ri ty K e rn e l

Figure 5: The PERSEUS seurity arhiteture.

Inthefollowing,webrieydesribeeahimplementedlayer

inmoredetail.

4.1.1 Hardware Layer

Thehardwarelayeronsistsofommerialo-the-shelfPC

hardwarewithadditionalTrustedComputingtehnologyas

ule(TPM). TheTPMisonsideredtobeatamper-evident

hardwaredeviesimilartoasmart-ardandisassumedtobe

seurelyboundtoaomputingplatform. Itisprimarilyused

asarootoftrustforplatform'sintegritymeasurementand

reporting. Duringsystemstartup,ahainoftrustisestab-

lishedby ryptographiallyhashing eahbootstagebefore

exeution. The measurement results are stored proteted

inPlatformCongurationRegisters (PCRs). Basedonthis

PCR onguration, two basi funtions an be provided:

Remote Attestation allows a TCGenabled platformto at-

testtheurrentmeasurementandSealing resp. Binding to

loallyresp. remotelybinddatatoaertain platformon-

guration. Ourimplementationusessuha TCGTrusted

PlatformModuleinthepresentversion1.2[53℄sineprevi-

ous TPMversionsannotbe usedto provide freshstorage

aswewill elaborateoninSetion4.4).

4.1.2 Virtualization Layer

Themaintaskofthevirtualizationlayeristoprovideanab-

strationoftheunderlyinghardware,e.g.,CPU,interrupts,

devies, andtooer anappropriatemanagementinterfae.

Moreover,thislayerenforesanaessontrolpoliybased

onthis resoures. Theurrent implementationisbasedon

mirokernels 14

oftheL4-family[15,19℄. Itimplementshard-

wareabstrationssuhasthreadsandlogialaddressspaes

as well as an inter-proess ommuniation (IPC). Devie

drivers andotheressentialoperating system servies,suh

as proess management and memory management, runin

isolated user-mode proesses. In our implementation, we

kept the interfaes between the layers generi to support

also other virtualization tehnologies. Thus, the interfae

oeredbythevirtualizationlayerissimilartothoseoered

by virtual mahine monitors resp. hypervisors like sHype

and Xen[33,43, 10℄. However,weatuallydeidedto em-

ploy aL4-mirokernel that easily allows isolation between

singleproesseswithoutreatinganewfull OSinstanein

eahase suhaswhenusingXen.

4.1.3 Trusted Software Layer

Thetrustedsoftwarelayer,basedonthePERSEUSseurity

arhiteture[32,39,41℄,usesthefuntionalityoeredbythe

virtualization layerto provideseurityfuntionalities ona

moreabstratlevel. Itprovideselementaryseurityproper-

tiesliketrustedhannelsandstrongompartmentisolation

as well as several elementary management ompartments

(e.g.,I/Oaessontrolpoliy)thatrealizeseurityritial

servies independent and protetedfrom ompartments of

theappliationlayer. Themainserviesofthetrustedsoft-

ware layer to enable stateful lienses and liense transfers

are,asdesribedinSetion3.1,theTrustManager(f. Se-

tion 4.3), the User Manager, Compartment Manager, and

partiularlytheStorageManager(f. Setion4.4).

4.1.4 Application Layer

Ontopoftheseuritykernel,severalinstanesofthelegay

operatingsystemaswellasseurity-ritialappliationsin

ourasetheDRMontrollerandSeureI/Oareexeuted

in stronglyisolated ompartmentssuh that unauthorized

14

Amirokernelisanoperatingsystemkernelthatminimizes

theamountofoderunninginprivileged(ring0)proessor

aess isprevented.

15

Theproposed arhitetureoers an

eientmigrationofexistinglegayoperatingsystems.We

are urrently running a para-virtualized Linux [14℄. The

legayoperating system provides all operating system ser-

viesthat are not seurity-ritial and oersusers a om-

monenvironmentandalargesetofexistingappliations. If

amandatoryseurity poliyrequires isolation betweenap-

pliationsofthelegayOS,theyanbeexeutedbyparallel

instanesofthelegayoperatingsystem.

4.2 Secure Initialization

The seurity of the whole arhiteture relies on a seure

bootstrapping of the trusted omputing base. A TPM-

enabled BIOS, the Core Root of Trust for Measurement,

measurestheintegrity oftheMaster BootReord (MBR),

before passing ontrol to it. A seure hain of measure-

mentsisthenestablished: Before programodeisexeuted

itismeasuredbyapreviouslymeasuredandexeutedom-

ponent. For this purpose, we have modied the GRUB

bootloader 16

tomeasure theintegrityof theore ompart-

ments, i.e., the virtualization layer, all ompartments in-

teratingdiretlywiththe TPMCompartmentManager,

TrustManagerandStorageManager aswellastheTPM

deviedriver. Themeasurementresultsareseurelystored

inthePCRsofthe TPM.Allotherompartments(inlud-

ingthe legayOS)aresubsequentlybeingloaded, veried,

and exeuted by the Compartment Manager aording to

theeetualplatformseuritypoliy.

Uponompletionoftheseureinitialization, anauthorized

ompartment(suhastheTrustManager)aninstrutthe

TPM to generate a redentialfor the Trusted Computing

Base. Thisredentialonsists of all PCRvaluesreeting

theongurationoftheTCBandakeypairwhihisbound

to thesePCR values. Together withan I/Oaess poliy

managementserviethatisofoursealsopartoftheTCB,

theprivatekeyanonlybeusedbyompartmentsthatare

bothpartoftheTCBandareauthorizedtoaesstheTPM.

4.3 Trust Manager

Ourimplementationof theTrustManager is basedonthe

open-soure TCGSoftware Stak TrouSerS [51℄. In order

toprovideremotetrustedhannels,theTrustManagerre-

ates on requestof a loal ompartment a private binding

keywhoseusageisboundtotherequestingompartment's

ongurationand theonguration ofthe platform's TCB

(inludingtheTrustManageritself). Theappropriateer-

tiate of the publibinding keyhas to be extended suh

thatremotepartiesanverifybothongurations. Toaess

ontentthatis remotelyderyptedwiththepublibinding

key,theTrustManagerhekswhethertheongurationof

theompartmentthatwanttousetheorrespondingprivate

bindingkeymathes theongurationoftheompartment

that has initiated the reation of that binding key. Note

that,byextendingthis'math'funtion,oneaneasilypro-

videproperty-basedattestation/sealing [40, 34, 13℄ ontop

oftheTrustManager.

AordingtoFigure 6,inthefollowing, wegivea detailed

15

However,overthannelsarestillfeasible.

16

hannel. Theprotoolanbedeomposedintothreemajor

steps,namelyertiategeneration,enryption ofasession

key,andderyptionofthesession key.

Certiate Generation: Therequestoftheremoteom-

partment

RC

^{for a trusted hannel to the loal ompart-}

ment

LC

^reahes

TM

^via

LC

^{. After the mapping of}

LC

^'s

ompartment identier to his atual ompartment ong-

uration

comp

^-

conf LC

^using

CM

^,

TM

^{invokes the TPM to}

reateaasymmetribindingkeyboundtotheatualTCB

onguration.

17

TheTPMthenreturnsthepublibinding

key

P K BI N D

andtheenryptedseretpart

SK BI N D ^′

^using

TPM'sstoragerootkey(SRK).Then

TM

^{invokestheTPM}

tosignovertheatualTCBonguration,thebindingkey,

andtheongurationof

LC

^usinganattestationidentitykey (AIK).

18

Finally,

TM

^{embeds thereeivedTPM ertiate}

within an X.509ertiate for use inthe TLS handshake,

whihwillbesenttogetherwith

P K ^{BI N D}

^to

RC

^.

TCBonguration

T CB

^-

conf

Publibindingkey

P K BI N D

Loalompartmentonguration

comp

^-

conf LC

TPMSignature=

sign AI K

⁽

T CB

^-

conf

^,

P K BI N D

^,

comp

^-

conf LC

⁾

Table 1: Struture oftheTPMertiate

cert ^{BI N D}

^.

Enryption of Session Key:

RC

^{veries the ertiate}

signature and validates the two embedded ongurations

T CB

^-

conf

^and

comp

^-

conf LC

^{by omparing themwithref-}

erenevaluesknowntobetrustworthy. Onsuess,

RC

^en-

rypts asymmetrisessionkeyto

esk

^using

P K BI N D

and aknowledgestheTLShandshakewith

esk

^,thatanbeun-

bound by

LC

^{only if it provides the stated ompartment}

andTCBonguration.

Deryption of Session Key: Upon reeipt of the en-

ryptedsessionkey

esk

^,

LC

^requests

TM

^{tounbindtheses-}

sionkey.Therefore,

TM

^againmaps

LC

^{'sompartmentiden-}

tier tohisatualompartmentonguration

comp

^-

conf LC

using

CM

^{,tovalidatetheompartmentongurationstated}

in the ertiate with the one requesting the unbindpro-

ess. Onsuess,

TM

^{invokesthe TPMto unbindtheses-}

sionkeyusingtheenryptedprivatepartofthebindingkey

SK BI N D ^′

^{. TheTPMrstomparestheatualPCRvalues}

with ones

SK ^{BI N D}

^{is bound to, before returning the de-}

ryptedsessionkeyto

TM

^.

TM

^{nally,passesthederypted}

sessionkeybakto

LC

^{whihusesitfortheompletionofthe}

TLShandshaketoestablisha(one-way)SSL-basedtrusted

hannelfromompartment

RC

^to

LC

^.

PerformaneMeasurements: Wehaveimplementedthe

desribedprotoolandrunitonTPMsofdierentvendors.

The measurement results with maximum asymmetri key

lengths (2048 bits)are shownbelow. Note that the TPM

17

The atual TCB onguration

T CB

^-

conf

^{was measured}

duringseureinitialization(f. Setion4.2).

18

Theattestationidentitykey(AIK)isanon-migratablekey

that has been attested by a privay-CA to ome from a

TCGonformplatform. AnAIK(inontrasttothegeneral

signaturekey)anbeusedonlytosignotherTPMkeysor

Trust Manager

TM TPM

Compartment Manager CM

Local Compartment LC

(2) request-trusted- channel[]

(5) cert _BIND , PK _BIND , SK ' BIND

Remote Compartment RC

(1) request-trusted- channel[]

(6) PK _BIND , cert _BIND

(3) comp-id LC

(4) comp-conf LC

create-binding-key[TCB-conf]

PK BIND , SK ' BIND

sign AIK [PK _BIND , SK ' BIND , comp-conf LC ] cert BIND

verify[PK BIND , cert BIND ] esk := encrypt PK BIND [session-key]

(7) esk unbind[cert BIND , esk, SK ' BIND ]

unbind[esk, SK ' BIND ] verify[cert _BIND , comp-conf LC ]

verify[TCB-conf ] decrypt SRK [SK ' BIND ]

decrypt _SK BIND [esk ] session-key

comp-id LC

comp-conf LC

session-key

SSL Session

TCB Local Platform Remote Platform

SK ' BIND := encrypt SRK [SK BIND ]

Figure 6: Protool for establishing aremote trusted hannel. The numbers (X) onthe arrows referto the

protool steps ofFigure3.

alulationsdominatetheoverallomputationandnetwork

transfertimes.

Atmel1.1b NSC1.1b

Certiategeneration 3080s 5255s

Sessionkeyenryption(w/oTPM) <1s <1s

Sessionkeyderyption 23s 2324s

Table 2: Trust Manager performane measurement

results.

4.4 Storage Manager

The following setion desribes the implementation of the

StorageManager

SM

^{, that enablesother}ompartmentsto persistentlyboundtheir loalstatesto theiratualong-

urationwhilepreservingintegrity,ondentialityandfresh-

realizationofseurestoragethatwillbeextendedbyanad-

ditional freshnesslayertoprovidealsotrusted storage. At

theendofthissetion, we brieydesribethe protools to

init

SM

^{as wellas for storing to and loadingfrom trusted}

storageusing

SM

^.

Overview: TheStorage Manager is invokedby aompart-

menttostoreadataobjetpersistentlypreservingonden-

tiality and integrity optionalwith additional restritions

rest

^{(e.g.,freshness,ertain userid).}

SM

^{invokestheCom-}

partment Manager to retrieve the atual onguration of

therespetiveompartmenttobindthedataobjettothat

origin ompartmentonguration

cmp

^-

conf

^{. Asshownin}

Figure7,

SM

reates/updatesametadataentryfortheor- respondingdataobjet

data

^{withthedataobjetidentier}

data I D

^{,itsfreshnessdetetion}information

f

^{,i.e.,theatual}

ryptographihashvalue,andallrelevantaessrestritions

rest

^{19 within itsindex}

index SM

^.

SM

^{extendsthe dataob-}

jetwithanintegrityveriationinformation,synhronizes

itsmonotoniounter

cnt SM

^{,enryptsthe dataobjetand}

theupdatedindexandwritesitonuntrustedpersistentstor-

ageusing

key SM

^{. Sine}

index SM

^{is the base ofseurity for}

SM

^,

index SM

^{issealed to}

SM

^{'songurationvia thesealed}

key SM

^{. Thusonlythesame,trusted StorageManager on-}

gurationisabletounsealandusethekeyagain. Onaload

request,

SM

^againusestheCompartmentManagertoom- paretheinvokingompartmentongurationwiththe one

thatafore storedtherespetivedataobjet. Onasuess-

fulveriation,

SM

^{readsandderyptsthedataobjetfrom}

the untrusted persistent storage and veries its integrity.

Beforethedataobjetisommittedtotherequestingom-

partment,

SM

^{also veriespossibly existing additional re-}

stritionssuhasfreshnessoraertainuserid.

TCG TPM 1.2

Compartment

data := load[data ID ] data ID := store[data, , rest ]

Compartment Manager

Storage Manager

cmp-conf data ID f rest

CP_0 ID_325 0x29... fresh CP_1 ID_563 0x10... UID = 2

cnt SM key SM index SM

Figure7:

SM

^{'smetadata index.}

Integrity

Confidentiality

Untrusted Trusted Channel

Trusted

key SM

e := encrypt[data ||i]

data := load[data ID ] data ID := store[data, rest ]

e := read[data ID ] data ID :=write[e]

Plain Channel data ||i := decrypt[e]

i := hash[data ] Hash A/R := verify[data, i]

Hardware Protected Untrusted Storage

Figure8: Compartmentviewof

SM

^{'sseurestorage}

implementation.

Seure Storage: Figure8depits ourseurestorage imple-

mentation. Thus,ourseurestorageompartmentbasially

oerstwo trusted hannels namely

load[]

^and

store[]

^while

itselfusestwountrusted hannels namely

read[]

^and

write[]

fromanuntrustedstorageompartmenttopersistentlywrite

respetivelyreaddatawhileprovidingatleastavailability.

20

If

SM

^{reeivesa data objet}

data

via

store[ data , rest ]

^,

SM

19

Furtheraessrestritionsanbeaertain userid, group

idordateofexpiry.

20

Fortherealizationofavailabilitywesuggestsolutionsbased

onhigh redundany,i.e., bytheutilization ofmultipledis-

tributedstorageloations (e.g.,USBstiksoronline sites)

assistedbyanappropriateRAIDsystem. Inaseoffailure

ofapartiularstorage devie,itis stillpossible toretrieve

internallyreatesorupdatesobjet'smetadata 21

andalu-

latesitshashvalue

i

toverifyintegrity. Then

data

together with

i

is enrypted with the internal ryptographi seret

key SM

^{using the funtion}

e := encrypt[ data || i ]

^(toprovide

ondentiality). The enrypteddata

e

will afterwards be written on untrusted storage using

data _ID := write[ e ]

^that

returnstheobjetidentier

data _ID

. Conversely,if

e

isread from theuntrusted storagevia

e := read[ data _ID ]

^{it will be}

derypted to

data

and

i

via

decrypt[ e ]

^{using the internal}

ryptographiseret

key SM

^{. Beforereturning}

data

to

load[]

^,

SM

^{veriestheintegrityof}

data

andfurtheraessrestri- tions (e.g., a ertain user id) based on the orresponding

metadatain

SM

^{'sindexusingthefuntion}

verify[ data , i]

^.

TrustedStorage: Inordertoprovidetrustedstorage,ween-

hane

SM

^{byanadditional layerfor managingfreshness of}

data objets. Figure 9 depits

SM

^{'s extension where the}

(urrentlyabstrat) funtion

f := memorize[ data ]

^updates

theinternaldatastruture

FRESH

withthefreshnessvalue

f

^. Afterwards,

data

willbestoredpersistentlyensuringon- dentialityandintegrityusingseurestorage. Onloadfrom

seure storage, the funtion

verify[ data , f]

^{additional veri-}

esthatthereeiveddataobjet

data

isthelastonebeing stored.

Freshness

data := load[data ID ] data ID := store[data, rest ]

f := memorize[data ] A/R := verify[data, f]

Secure Storage

Trusted channel

Trusted Untrusted channel

Hardware Protected

Figure9: Compartmentviewof

SM

^{'strustedstorage}

implementation.

Toprovidesuhfreshnessdetetion,

SM

^{usesanadditional}

metadataeld(f. Figure7)tostoretheryptographihash

value

Hash( data )

^{thatdenesthelaststoredversionof}

data

. Onload,

SM

^alulates

Hash( data )

^{again and heksif it}

mathes the hash value on last store. In order to ensure

freshnessofthesemetadata,theindexof

SM

^{itselfhastobe}

storedfresh.

WethereforeanalyzedtowhatextendTPMsofversion1.1b

and1.2anbeusedtorealizeafreshindexfor

SM

^.

•

DI-Register: TPMs version 1.1b provide a Data In- tegrity Register (DIR) that an persistently store a

160 bit value [21, 23℄. Unfortunately, aess to this

register isonlyauthorizedbytheTPM-Ownerseret

implyingthattheTPM-Owneranalwaysperformre-

playattaks.Theonlysolutionwouldbetodistribute

platforms with anativated TPM and an owner au-

thorization seretthat is unknowntothe user. This

solution does not onform to the TCG speiation

thatdemandsthatTCG-enabledplatformshavetobe

shippedwithnoownerinstalled(see[54℄,page139).

•

^{SRKRereation: An}alternativewaytopreventreplay attaksbasedonTPMsversion1.1bwouldbetoreate

21

a newStorage Root Key (SRK)beforethesystem is

shutdown. RereationoftheSRKwouldpreventthat

previouslyreatedTPMenryptionkeysanbeused

anymore. Unfortunately,aSRKanonlyberenewed

bythe

TakeOwnership

^{funtionwhihitselfrequiresa}

previously

OwnerClear

^{that itself disables the TPM.}

Therefore, anonline-rereation of the SRKseems to

beimpossible.

•

^{NV-RAM:TPMsversion1.2providealimitedamount}

ofnon-volatile(NV-)RAMtowhihaessisrestrited

toauthorizedentities. So-alledNV-Attributesdene

whihentitiesare authorizedtowritetoand/or read

from the NV-RAM.Thus,data integrity anbepre-

servedbystoringahashvalueofthedataintotheNV-

RAMandensuringthatonlytheStorageManageran

aesstheauthorizationseret.

•

^{Seure Counter: ATPMversion1.2supportsatleast}

fourmonotoniounters. Basedonthisfuntionality,

thefreshnessofdataanbedetetedbyseurelyon-

atenatingitwiththeatualountervalue.

A result of our previous analysis we showed that TPMs

version1.1b annotbeusedto providefreshstorage asre-

quiredtoenforestatefulliensesand/ortotransferlienses.

Thereforewedeidedtorealizetrustedstoragebasedonthe

monotoniounterfuntionalityofTPMs version1.2.

Amonotonihardware ounterallowsusto seurelymain-

tainversioningofanarbitrarydataomponent,bykeeping

asoftware ountersynhronized with one(of four guaran-

teed)hardware ounters of the TPM. As depited inFig-

ure7,

SM

^{managesaninternalsoftwareounterthat,every}

time

SM

^{updates its index, is inremented} synhronously withthemonotonihardwareounter. Ifbothmismathat

anytime,aoutdateddataisdeteted,thatwillbehandled

aordingtotheatualseuritypoliy.

However,inordertoemployTPM'smonotoniounters,

SM

hasto be initializedorretly. Figure10 depitsthe steps

neededfor the rstinitialization of

SM

^{onanew platform}

togetherwiththeinitializationneessaryfor instaneafter

rebooting the platform. Onthe initial setup

SM

^usesthe

TPM to reate its internal ryptographi key

key SM

^that

thenwillbesealedtotheatualplatformonguration. To

enablefreshnessdetetionandthustrustedstorage,

SM

^re-

atesamonotoniounter

cntid

^withaauthentiation

auth

^,

e.g., aseretpassword. Theinitial setup nisheswiththe

reation of

SM

^{'s internal metadataindex}

index SM

^{and the}

savingof the sealed keyblob and the enryptedindex on

untrustedstorage.

Aftera platform reboot,

SM

^{reads the key blob from the}

untrustedstorageand asksthe TPMto unsealitsinternal

key.TheTPMisabletounseal

key SM

^{iftheplatformhasthe}

sameongurationasitwasatthesealingproess,thuspre-

ventingamodied

SM

^toaess

key SM

^{. Then}

SM

^uses

key SM

toderyptitsmetadataindexreadfromtheuntrustedstor-

age. Finally,

SM

^{veriesfreshness of}

index SM

^byomparing

the deryptedounter of

index SM

^{with the atualounter}

valueoftheorrespondingTPMounter

cntid

^.

Untrusted Storage Trusted Platform Module

TPM

write[keyblob SM ] Storage Manager

SM

request-random[]

key SM

read-counter[cntid]

rnd

seal[key SM ] keyblob SM

read[keyblob SM ] unseal[keyblob SM ]

decrypt[key SM , read[index SM ]]

create-counter[cntid, auth]

cnt

write[encrypt[key SM , index SM ]]

cnt key SM := derive[rnd]

verify[index SM , cnt]

index SM := create[cnt]

Figure 10: Protool viewof

SM

^'sinitialization.

Figure11depitstheprotoolstepsrequiredtobindaom-

partment'sdataobjetpersistentlytoitsatualongura-

tion. Afterthe mapping of ompartment identier to the

atual ompartment onguration using

CM

^,

SM

^updates

index SM

^withtheorrespondingmetadataaswellasthein- rementedsoftwareountertoenablefreshnessdetetionfor

index SM

^. Afterwards,

SM

^{writesboth,thedataobjetsand}

theupdatedindex,enryptedonthe untrustedstorageus-

ing

key SM

^{. Finally,}

SM

synhronizes its software ounter with the TPM's monotoni hardware ounterand returns

thedataobjetidentier.

Comp. Manager CM Storage Manager

SM store[data, rest]

Compartment X

comp-id X

comp-conf x

Untrusted Storage

increment-counter[cntid, auth]

TPM data ID := write[encrypt[key SM , data]]

write[encrypt[key SM , index SM ]]

data _ID

update-index[comp-conf x , data, rest]

increment-counter[index SM ]

Figure11: Protool viewof

SM

^'sstoreimplementa- tion.

We omplete thesenario withFigure 12 that depits the

protoolstepsrequiredtoloadaompartment'sdataobjet

again. Afterthemappingofrequestingompartmentiden-

tier to the atual ompartment onguration using

CM

^,