verifytrustview

OutboundAuthenticationforProgrammableSecureCoprocessorsSeanW.
SmithDepartmentofComputerScience,DartmouthCollegeHanover,NewHampshireUSAhttp://www.
cs.
dartmouth.
edu/~sws/Abstract.
Aprogrammablesecurecoprocessorplatformcanhelpsolvemanysecurityproblemsindistributedcomputing.
However,thesesolu-tionsusuallyrequirethatcoprocessorapplicationsbeabletoparticipateasfull-edgedpartiesindistributedcryptographicprotocols.
Thus,tofullyenablethesesolutions,agenericplatformmustnotonlyprovideprogrammability,maintenance,andcongurationinthehostileeld—itmustalsoprovideoutboundauthenticationfortheentitiesthatresult.
AparticularapplicationonaparticularuntampereddevicemustbeabletoprovewhoitistoapartyontheothersideoftheInternet.
Thispaperoersourexperiencesinsolvingthisproblemforahigh-endsecurecoprocessorproduct.
Thisworkrequiredsynthesisofanumberoftechniques,sothatpartieswithdierentanddynamicviewsoftrustcandrawconsistentandcompleteconclusionsaboutremotecoproces-sorapplications.
Theseissuesmayberelevanttotheindustry'sgrowinginterestinrightsmanagementforgeneraldesktopmachines.
1IntroductionHowdoesonesecurecomputationthattakesplaceremotely—particularlywhensomeonewithdirectaccesstothatremotemachinemaybenetfromcompromis-ingthatcomputationThisissueliesattheheartofmanycurrente-commerce,rightsmanagement,andPKIissues.
Toaddressthisproblem,research(e.
g.
,[17,24,25])haslongexploredthepotentialofsecurecoprocessors:high-assurancehardwaredevicesthatcanbetrustedtocarryoutcomputationunmolestedbyanadversarywithdirectphys-icalaccess.
Forexample,suchanadversarycouldsubvertrightsmanagementonacomplexdatasetbyreceivingthedatasetandthennotfollowingthepolicy;securecoprocessorsenablesolutionsbyreceivingthedatasetencapsulatedwiththepolicy,andonlyrevealingdataitemsinaccordancewiththepolicy.
[13]ForApreliminaryversionofthispaperappearedasDartmouthCollegeTechnicalReportTR2001-401.
ThispaperreportsworktheauthordidwhilearesearchstamemberatIBMWatson.
SubsequentworkwassupportedinpartbytheMellonFoundation,AT&T/Internet2,andtheU.
S.
DepartmentofJustice(contract2000-DT-CX-K001).
Theviewsandconclusionsdonotnecessarilyreectthesponsors.
D.
Gollmannetal.
(Eds.
):ESORICS2002,LNCS2502,pp.
72–89,2002.
cSpringer-VerlagBerlinHeidelberg2002OutboundAuthenticationforProgrammableSecureCoprocessors73anotherexample,anadversarycouldsubvertdecentralizede-cashsimplybyin-creasingaregister.
However,securecoprocessorsenablesolutions:theregisterlivesinsideatrustedbox,whichmodiesthevalueonlyaspartofatransactionwithanothertrustedbox.
[24]Manyotherapplications—includingprivateinfor-mationretrieval[3,19],e-commerceco-servers[14],andmobileagents[26]—canalsobenetfromthehigh-assuranceneutralenvironmentthatsecurecoproces-sorscouldprovide.
Astheliterature(e.
g.
,[5,8])discusses,achievingthispotentialrequiressev-eralfactors,includingestablishingandmaintainingphysicalsecurity,enablingthedevicetoauthenticatecode-loadsandothercommandsthatcomefromtheoutsideworld,andbuildingapplicationswhosedesigndoesnotnegatethesecu-rityadvantagesoftheunderlyingplatform.
However,usingsecurecoprocessorstosecuredistributedcomputationalsorequiresoutboundauthentication(OA):theabilityofcoprocessorapplicationsbeabletoauthenticatethemselvestoremoteparties.
(Code-downloadinglosesmuchofitseectifonecannoteasilyauthenticatetheentitythatresults!
)Merelyconguringthecoprocessorplatformastheappropriateentity—arightsbox,awallet,anauctionmarketplace—doesnotsuceingeneral.
Asignedstate-mentaboutthecongurationalsodoesnotsuce.
Formaximaleectiveness,theplatformshouldenabletheentityitselftohaveauthenticatedkeypairsandengageinprotocolswithanypartyontheInternet:sothatonlythatparticu-lartrustedauctionmarketplace,followingthetrustedrules,isabletoreceivetheencryptedstrategyfromaremoteclient;sothatonlythatparticulartrustedrightsbox,followingthetrustedrules,isabletoreceivetheobjectandtherightspolicyitshouldenforce.
TheResearchProject.
Thesoftwarearchitectureforaprogrammablese-curecoprocessorplatformmustaddressthecomplexitiesofshipping,upgrades,maintenance,andhostilecode,foragenericplatformthatcanbeconguredandmaintainedinthehostileeld.
[18]Ourteamspentseveralyearsworkingondevelopingasuchadevice;otherreports[7,8,20]presentourexperiencesinbringingsuchadeviceintoexistenceasaCOTSproduct,theIBM4758.
Althoughourinitialsecurityarchitecture[20]sketchedadesignforoutboundauthentication,wedidnotfullyimplementit—norfullygraspthenatureoftheproblem—untiltheModel2devicereleasedin2000.
Asiscommoninproductdevelopment,wehadtoconcurrentlyundertaketasksonemightprefertotacklesequentially:identifyfundamentalproblems;reasonaboutsolutions;design,codeandtest;andensurethatitsatisedlegacyapplicationconcerns.
TheBasicProblem.
Arelyingpartyneedstoconcludethataparticularkeypairreallybelongstoaparticularsoftwareentitywithinaparticularuntam-peredcoprocessor.
Designandproductionconstraintsledtoanon-trivialsetofsoftwareentitiesinacoprocessoratanyonetime,andinanyonecoprocessorovertime.
Relyingpartiestrustsomeoftheseentitiesandnotothers;further-more,weneededtoaccommodateamultiplicityoftrustsets(dierentparties74SeanW.
Smithhavedierentviews),aswellasthedynamicnatureofanyoneparty'strustsetovertime.
Thisbackgroundsetsthestageforthebasicproblem:howshouldthedevicegenerate,certify,change,store,anddeleteprivatekeys,sothatrelyingpartiescandrawthoseconclusionsconsistentwiththeirtrustset,andonlythosecon-clusionsThisPaper.
Thispaperisapost-factoreportexpandingonthisresearchanddevelopmentexperience,whichmayhaverelevancebothtoothersecureco-processortechnology(e.
g.
,[23])aswellastothegrowingindustryinterestinremotelyauthenticatingwhat'sexecutingonadesktop(e.
g.
,[9,10,11,21]).
Section2discussestheevolutionoftheprobleminthecontextoftheun-derlyingtechnology.
Section3presentsthetheoreticalfoundations.
Section4presentsthedesign.
Section5suggestssomedirectionsforfuturestudy.
2EvolutionofProblem2.
1UnderlyingTechnologyWestartwithabriefoverviewofthesoftwarestructureofthe4758.
Thede-viceistamper-responding:withhighassurance,on-boardcircuitsdetecttamperattemptsanddestroythecontentsofvolatileRAMandnon-volatilebattery-backedRAM(BBRAM)beforeanadversarycanseethem.
Thedevicealsoisageneralpurposecomputingdevice;internalsoftwareisdividedintolayers,withlayerboundariescorrespondingtodivisionsinfunction,storageregion,andex-ternalcontrol.
Thecurrentfamilyofdeviceshasfourlayers:Layer0inROM,andLayer1throughLayer3inrewritableFLASH.
Thelayersequencealsocorrespondstothesequenceofexecutionphasesafterdeviceboot:initiallyLayer0runs,theninvokesLayer1,andsoon.
(Becauseourdeviceisanenclosedcontrolledsystem,wecanavoidthedicultiesofsecurebootthatariseinexposeddesktopsystems;weknowexecutionstartsinLayer0ROMinaknownstate,andhigher-levelrmwareischangedonlywhenthedeviceitselfpermitsit.
)Inthecurrentfamily,Layer2isintendedtobeaninternaloperatingsystem,leadingtotheconstraintthatitmustexecuteatmaximumCPUprivilege;itinvokesthesingleapplication(Layer3)butcontinuestorun,dependingonitsuseoftheCPUprivilegelevelstoprotectitself.
Weintendedthedevicetobeagenericplatformforsecurecoprocessorap-plications.
Theresearchteaminsistedonthegoalthatthirdparties(dierentfromIBM,andfromeachother)beabletodevelopandinstallcodefortheOSlayerandtheapplicationlayer.
Businessforcespressuredustohaveonlyoneshippableversionofthedevice,andtoensurethatanuntampereddevicewithnohardwaredamagecanalwaysberevived.
WeconvergedonadesignwhereLayer1containsthesecuritycongurationsoftwarewhichestablishesownersandpublickeysforthehigherlayers,andvalidatescodeinstallationandupdatecommandsforthoselayersfromthoseowners.
ThisdesigndecisionstemmedOutboundAuthenticationforProgrammableSecureCoprocessors75fromourvisionthatapplicationcodeandOScodemaycomefromdierententitieswhomaynotnecessarilytrusteachother'supdates;centralizationofloadingmadeiteasiertoenforcetheappropriatesecuritypolicies.
Layer1isupdatable,incasewewanttoupgradealgorithms,xbugs,orchangethepublickeyofthepartyauthorizedtoupdatethelayer.
However,wemirrorthislayer—updatesaremadetotheinactivecopy,whichisthenatomicallymadeactiveforthenextboot—sothatfailuresduringupdatewillnotleaveuswithanon-functioningcode-loadinglayer.
AuthenticationApproach.
Anotherbusinessconstraintwehadwasthattheonlyguaranteedcontactwewouldhavewithacardwasatmanufacturetime.
Inparticular,wecouldassumenoaudits,nordatabaseofcard-specicdata(secretorotherwise),norprovideanyon-lineservicestocardsoncetheyleft.
Thisconstraintnaturallysuggestedtheuseofpublic-keycryptographyforauthentication,bothinboundandoutbound.
Becauseofthelast-touch-at-manufacturingconstraint,we(themanufac-turer)canlastdosomethingcryptographicatthefactory.
2.
2UserandDeveloperScenariosDiscussionsaboutpotentialrelyingpartiesledtoadditionalrequirements.
Developerswerenotnecessarilygoingtotrusteachother.
Forexample,al-thoughanapplicationdevelopermusttrustthecontentsofthelowerlayerswhenhisapplicationisactuallyinstalled,heshouldbefreetorequirethathissecretsbedestroyedshouldalowerlayerbeupdatedinawayhedidnottrust.
Asaconsequence,weallowedeachcode-loadtoincludeapolicyspecifyingthecon-ditionsunderwhichthatlayer'ssecretsshouldbepreservedacrosschangestolowerlayers.
Anyotherscenariodestroyssecrets.
However,evenfull-preservationdevelopersreservedtherightto,post-facto,decidethatcertainversionsofcode—eventheirown—wereuntrusted,andbeabletoverifywhetheranuntrustedversionhadbeeninstalledduringthelifetimeoftheirsecrets.
Intheory,theOSlayershouldresistpenetrationbyamaliciousapplication;inpractice,operatingsystemshaveabadhistoryhere,soweonlyallowoneapplicationaboveit(andintendtheOSlayersolelytoassisttheapplicationdeveloper).
Furthermore,weneedtoallowthatsomerelyingpartieswillbelievethattheOSingeneral(orspecicversion)mayindeedbepenetrablebymaliciousapplications.
Smalldevelopersmaybeunabletoassurethepublicoftheintegrityandcorrectnessoftheirapplications(e.
g.
,throughcodeinspection,formalmodeling,etc).
Wherepossible,weshouldmaximizethecredibilityourarchitecturecanendowonsuchapplications.
76SeanW.
SmithEpoch1Epoch2Cong1,inEpoch1Cong2,inEpoch1Cong1,inEpoch2Secret-destroyingcode-loadSecret-destroyingcode-loadSecret-preservingcode-loadFig.
1.
Anepochstartswithcode-loadactionthatclearsalayer'ssecrets;withanepoch,eachsecret-preservingcode-loadstartsanewconguration2.
3On-CardEntitiesOneoftherstthingsweneedtodealwithisthenotionofwhatanon-cardentityis.
Let'sstartwithasimplecase:supposethecoprocessorhadexactlyoneplacetoholdsoftwareandthatitzeroizedallstatewitheachcode-load.
Inthisscenario,thenotionofentityisprettyclear:aparticularcode-loadC1executinginsideanuntampereddeviceD1.
ThesamecodeC1insideanotherdeviceD2wouldconstituteadierententity;aswouldare-installationofC1insideD1.
However,thissimplecaseraisesachallenges.
IfareloadreplacesC1withC2,andreloadsclearalltamper-protectedmemory,howdoestheresultingentity—C2onD1—authenticateitselftoapartyontheothersideofthenetThecarditselfwouldhavenosecretsleft,sincetheonlydatastoragehiddenfromphysicalattackwascleared.
Consequently,anyauthenticationsecretswouldhavetocomewithC2,andwewouldstartdownapathofsharedsecretsandpersonalizedcode-loads.
Shouldanapplicationentity"include"theOSunderneathitShoulditincludethecongurationcontrollayersthatranearlierinthisbootsequence,butarenolongeraroundSincewebuiltthe4758tosupportrealapplications,wegravitatedtowardapracticaldenition:anentityisaninstallationoftheapplicationsoftwareinatrustedplace,identiedbyallunderlyingsoftwareandhardware.
SecretRetention.
Asnoted,developersdemandedthatwesometimespermitsecretretentionacrossreload.
Withasecret-preservingload;theentitymaystaythesame,butthecodemaychange.
Theconictingconceptsthatdevelopershadaboutwhatexactlyhappenstotheiron-cardentitywhencodeupdateoccursleadustothinkmorecloselyaboutentitylifetimes.
Weintroducesomelanguagetoformalizethat.
Figure1sketchestheseconcepts.
Denition1(Conguration,Epoch).
ALayerNcongurationisthemax-imalperiodinwhichthatLayerisrunnable,withanunchangingsoftwareenvi-ronment.
ALayerNepochisthemaximalperiodinwhichtheLayercanrunandaccumulatestate.
IfEisanon-cardentityinLayerN,–Eisanepoch-entityifitslifetimeextendsforaLayernepoch.
OutboundAuthenticationforProgrammableSecureCoprocessors77–Eisaconguration-entityifitslifetimeextendsforaLayernconguration.
AnLayernepoch-entityconsistsofasequenceofLayernconguration-entities.
Thissequencemaybeunbounded—sinceanyparticularepochmightpersistindenitely,acrossarbitrarilymanycongurationchanges.
2.
4AuthenticationScenariosThisdesignleftuswithon-cardsoftwareentitiesmadeupofseveralcompo-nentswithdieringowners,lifetimes,andstate.
Anaturalwaytodooutboundauthenticationtogivethecardacertiedkeypair,whoseprivatekeylivesintamper-protectedmemory.
However,thecomplexityoftheentitystructurecre-atesnumerousproblems.
ApplicationCode.
SupposeentityCisthecodeC1residingintheapplicationLayer3inaparticulardevice.
Cmaychange:twopossiblechangesincludeasimplecodeupdatetakingthecurrentcodeC1toC2,oracompletere-installofadierentapplicationfromadierentowner,takingC1toC3.
IfarelyingpartyPtrustsC1,C2,andC3tobefreeofaws,vulnerabilities,andmalice,thenthenaturalapproachmightwork.
However,ifPdistrustssomeofthiscode,thenproblemsarise.
–IfPdoesnottrustC1,thenhowcanPdistinguishbetweenanentitywiththeC2patch,andanentitywithacorruptC1pretendingtohavetheC2patch–IfPdoesdoesnottrustC2,thenthenhowcanPdistinguishbetweentheanentitywiththehonestC1,andanentitywiththecorruptC2pretendingtobethehonestC1(Themereexistenceofasignedupdatecommandcompromisesallthecards.
)–IfPdoesnottrustC3,thenhowcanPdistinguishbetweenthehonestC1andamaliciousC3thatpretendstobeC1Code-LoadingCode.
EvenmoreseriousproblemsariseifacorruptedversionofthecongurationsoftwareinLayer1exists.
Ifanevilversionexistedthatal-lowedarbitrarybehavior,then(withoutfurthercountermeasures)apartyPcan-notdistinguishbetweenanyon-cardentityE1,andanE2consistingofarogueLayer1carryingoutsomeelaborateimpersonation.
OSCode.
ProblemscanalsoarisebecausetheOScodechanges.
Debugginganapplicationrequiresanoperatingsystemwithdebughooks;innaldevelopmentstages,areasonablescenarioistobeableto"update"back-and-forthbetweenaversionoftheOSwithdebughooksandaversionwithout.
Withnoadditionalcountermeasures,apartyPcannotdistinguishbetweentheapplicationrunningsecurelywiththerealOS,theapplicationwithdebughooksunderneathit,andtheapplicationwiththerealOSbutwithapolicythatpermitshot-updatetothedebugversion.
Theprivatekeywouldbethesameinallcases.
78SeanW.
SmithInternalCertication.
Theabovescenariossuggestthatperhapsasinglekeypair(forallentitiesinacardforthelifetimeofthecard)maynotsuce.
However,extendingtoschemeswhereoneon-cardentitygeneratesandcertieskeypairsforotheron-cardentitiesalsocreateschallenges.
Forexample,supposeLayer1generatesandcertieskeypairsfortheLayer2entity.
IfareloadreplacescorruptOSB1withanhonestB2,thenpartyPshouldbeabletodistinguishbetweenthecertiedkeypairforB2andthatforB1.
However,withoutfurthercountermeasures,ifsupervisor-levelcodecanseealldataonthecard,thenB1canforgemessagesfromB2—sinceitcouldhaveseentheLayer1privatekey.
Asimilarpenetrated-barrierissuearisesifweexpectanOSinLayer2tomaintainaprivatekeyseparatefromanapplicationLayer3,orifweenter-tainedalternativeschemeswheremutuallysuspiciousapplicationsexecutedcon-currently.
IfahostileapplicationmightintheorypenetratetheOSprotections,thenanexternalpartycannotdistinguishbetweenmessagesfromtheOS,mes-sagesfromthehonestapplication,andmessagesfromrogueapplications.
Thislineofthinkingledustothemoregeneralobservationthat,ifthecertieroutlivesthecertied,thentheintegrityofwhatthecertieddoeswiththeirkeypairdependsonthefuturebehaviorofthecertier.
Inthecaseofthecoprocessor,thisobservationhassubtleanddangerousimplications—forexample,oneofthereasonswecentralizedcongurationcontrolinLayer1wastoenabletheapplicationdevelopertodistrusttheOSdeveloperandrequestthattheapplication(anditssecrets)bedestroyed,iftheunderlyingOSundergoesanupdatetheapplicationdeveloperdoesnottrust.
WhatiftheuntrustedOShasaccesstoaprivatekeyusedincertifyingtheoriginalapplicationWerevisittheseissuesinSection4.
3.
3TheoryTheconstructionofthecardsuggeststhatweusecertiedkeypairsforoutboundauthentication.
However,aswejustsketched,thestraightforwardapproachofjustsendingthecardoutwithacertiedkeypairpermitstrouble.
Inthissection,wetrytoformalizetheprinciplesthatemergedwhileconsid-eringthisproblem.
Acardleavesthefactoryandundergoessomesequenceofcodeloadsandothercongurationchanges.
Arelyingpartyinteractswithanentityallegedlyrunninginsidethiscard.
Thecard'sOAschemeenablesthisapplicationtowieldaprivatekeyandtooeracollectionofcerticatespurportingtoauthenticateitskeyholder.
Itwouldbesimplestifthepartycoulduseastraightforwardvalidationalgo-rithmonthiscollection.
AsMaurer[15,16]formalized,arelyingparty'svalida-tionalgorithmneedstoconsiderwhichentitiesthatpartytrusts.
Ourexperienceshowedthatpartieshaveawidevarietyoftrustviewsthatchangedynamically.
Furthermore,wesawtheexistenceoftwospaces:theconclusionsthatapartywilldraw,givenanentity'scollectionofcerticatesandtheparty'strustview;andOutboundAuthenticationforProgrammableSecureCoprocessors79theconclusionsthatapartyshoulddraw,giventhehistoryofthosekeyholdersandtheparty'strustview.
Weneededtodesignaschemethatpermitsthesesetsofconclusionstomatch,forpartieswithawidevarietyoftrustviews.
3.
1WhattheEntitySaysRelyingpartyPwantstoauthenticateinteractionwithaparticularentityE.
Manyscenarioscouldexisthere;forsimplicity,ouranalysisreducesthesetothescenarioofEneedingtoprovetoPthatown(E,K):thatEhasexclusiveuseoftheprivateelementofkeypairK.
Weneedtobeabletotalkaboutwhathappenstoaparticularcoprocessor.
Denition2(History,Run,).
Letahistorybeanitesequenceofcom-putationforaparticulardevice.
Letarunbesomeunboundedsequenceofcom-putationforaparticulardevice.
WewriteHRwhenhistoryHisaprexofrunR.
InthecontextofOAforcoprocessorsthatcannotbeopenedorotherwiseexamined,andthatdisappearoncetheyleavethefactory,itseemedreasonabletoimposetherestrictionthaton-cardentitiescarrytheircerticates.
Forsimplicity,wealsoimposedtherestrictionthattheypresentthesamexedsetnomatterwhoasks.
Denition3.
WhenentityEwishestoproveitownsKafterhistoryH,letChain(E,K,H)denotethesetofcerticatesthatitpresents.
3.
2ValidationWillarelyingpartyPbelievethatEownsKFirst,weneedsomenotionoftrust.
ApartyPusuallyhassomeideasofwhichon-cardapplicationsitmighttrusttobehave"correctly"regardingkeysandsignedstatements,andofwhichonesitisunsure.
Denition4.
ForapartyP,letTrustSet(P)denotethesetofentitieswhosestatementsaboutcerticatesPtrusts.
LetrootbethefactoryCA:thetrustrootforthecard.
Alegitimatetrustsetisonethatcontainsroot.
InthecontextofOAforcoprocessors,itwasreasonabletoimposethere-strictionthattheexternalpartydecidesvaliditybasedonanentity'schainandtheparty'sownlistoftrustedentities.
(Thecommercialrestrictionthatwecannevercountonaccessingcardsaftertheyleavemaderevocationinfeasible.
)Weformalizethat:Denition5(Trust-setscheme).
Atrust-setcerticationschemeisonewheretherelyingparty'sValidatealgorithmisdeterministiconthevariablesChain(E,K,H)andTrustSet(P).
80SeanW.
SmithWethusneededtodesignatrust-setcerticationschemethataccommodatesanylegitimatetrustset,sincediscussionwithdevelopers(andexperiencesdoingsecurityconsulting)suggestedthatrelyingpartieswouldhaveawidedivergenceofopinionsaboutwhichversionsofwhichsoftwaretheytrust.
3.
3DependencyTheproblemscenariosinSection2.
4arosebecauseoneentityE2hadanun-expectedavenuetousetheprivatekeythatbelongedtoanotherentityE1.
Weneedlanguagetoexpressthesesituations,wheretheintegrityofE1'skeyactionsdependsonthecorrectbehaviorofE2.
Denition6(DependencyFunction).
LetEbethesetofentities.
Adepen-dencyfunctionisafunctionD:E→2Esuchthat,forallE1,E2:–E1∈D(E1)–ifE2∈D(E1)thenD(E2)D(E1)WhenadependencyfunctiondependsontherunR,wewriteDR.
WhatdependencyfunctionshallweuseforanalysisInourspecializedhard-ware,coderunsinasingle-sandboxcontrolledenvironmentwhich(ifthephysi-calsecurityworksasintended)isfreefromoutsideobservationorinterference.
Hence,inouranalysis,dependencefollowsreadandwrite:Denition7.
ForentitiesE1andE2inrunR,wewriteE2data→RE1whenE1hasread/writeaccesstothesecretsofE2(E2data→RE2trivially)andE2code→RE1whenE1haswriteaccesstothecodeofE2.
Let→Rbethetransitiveclosureoftheunionofthesetworelations.
ForanentityEinarunR,deneDepR(E)tobe{F:E→RF}.
Intermsofthecoprocessor,ifC1followsB1inthepost-bootsequence,thenwehaveC1data→RB1(sinceB1couldhavemanipulateddatabeforepassingcon-trol).
IfC2isasecret-preservingreplacementofC1,thenC1data→RC2(becauseC2stillcantouchthesecretsC1left).
IfAcanreburntheFLASHsegmentwhereBlives,thenBcode→RA(becauseAcaninsertmaliciouscodeintoB,thatwouldhaveaccesstoB'sprivatekeys).
3.
4ConsistencyandCompletenessShouldtherelyingpartydrawtheconclusionsitactuallywillInouranalysis,securitydependencedependsontherun;entityandtrustdonot.
Thisleadstoapotentialconundrum.
Suppose,inrunR,C→RBandC∈TrustSet(P),butB∈TrustSet(P).
ThenarelyingpartyPcannotreasonablyacceptanysignedstatementfromC,becauseBmayhaveforgedit.
Tocapturethisnotion,wedeneconsistencyforOA.
Theintentionofconsis-tencyisthatifthepartyconcludesthatanmessagecamefromanentity,thenitOutboundAuthenticationforProgrammableSecureCoprocessors81reallydidcomefromthatentity—modulotherelyingparty'strustview.
Thatis,inanyHRwherePconcludesown(E,K)fromChain(E,K,H),iftheentitiesinTrustSet(P)behavethemselves,thenEreallydoesownK.
Weformalizethisnotion:Denition8.
AnOAschemeisconsistentforadependencyfunctionDwhen,foranyentityE,arelyingpartyPwithanylegitimatetrustset,andhistoryandrunHR:Validate(P,Chain(E,K,H))=DR(E)TrustSet(P)Onemightalsoaskiftherelyingpartywilldrawtheconclusionsitactuallyshould.
Weconsiderthisquestionwiththetermcompleteness.
IfinanyrunwhereEproducesChain(E,K,H)andDR(E)istrustedbyP—soinP'sview,noonewhohadachancetosubvertEwouldhave—thenPshouldconcludethatEownsK.
Denition9.
AnOAschemeiscompleteforadependencyfunctionDwhen,foranyentityEclaimingkeyK,relyingpartyPwithanylegitimatetrustset,andhistoryandrunHR:DR(E)TrustSet(P)=Validate(P,Chain(E,K,H))Thesedenitionsequipustoformalizeafundamentalobservation:Theorem1.
Supposeatrust-setOAschemeisbothconsistentandcompleteforagivendependencyfunctionD.
SupposeentityEclaimsKinhistoriesH1R1andH2R2.
Then:DR1(E)=DR2(E)=Chain(E,K,H1)=Chain(E,K,H2)Proof.
SupposeDR1(E)=DR2(E)butChain(E,K,H1)=Chain(E,K,H2).
WecannothavebothDR1(E)DR2(E)andDR2(E)DR1(E),so,withoutlossofgenerality,letusassumeDR2(E)DR1(E).
TherethusexistsasetSwithDR1(E)SbutDR2(E)S.
Sincetheschemeisconsistentandcomplete,itmustworkforanylegitimatetrustset,includingS.
LetpartyPhaveS=TrustSet(P).
Sincethisisatrust-setcerticationschemeandEproducesthesamechainsinbothhistories,partyPmusteithervalidatethesechainsinbothscenarios,orrejecttheminbothsce-narios.
IfpartyPacceptsinrunR2,thentheschemecannotbeconsistentforD,sinceEdependsonanentitythatPdidnottrust.
ButifpartyPrejectsinrunR1,thentheschemecannotbecompleteforD,sincepartyPtrustsallentitiesonwhichEdepends.
3.
5DesignImplicationsWeconsidertheimplicationsofTheorem1forspecicwaysofconstructingchainsanddrawingconclusions,forspecicnotionsofdependency.
Forexam-ple,wecanexpressthestandardapproach—Pmakesitsconclusionbyrecur-sivelyverifyingsignaturesandapplyingabasicinferencerule—inaMaurer-stylecalculus[15].
SupposeCisasetofcerticates:statementsoftheform82SeanW.
SmithK1saysown(E2,K2).
SupposeSbeasetofentitiestrustedtospeakthetruthaboutcerticateownership:{E1:trust(E1,own(E2,K2))}.
ArelyingpartymaystartbybelievingC∪{own(root,Kroot)}.
Todescribewhatapartywillconclude,wecandeneViewwill(C,S)tobethesetofstatementsderivablefromthissetbyapplyingtheruleown(E1,K1),E1∈S,K1saysown(E2,K2)own(E2,K2)TheValidatealgorithmforpartyPthenreducestothedecisionofwhetherown(E,K)isinthisset.
Wecanalsoexpresswhatapartyshouldconcludeaboutanentity,intermsofthechaintheentitypresents,andtheviewsthatthepartyhasregardingtrustanddependency.
IfDisadependencyfunction,wecandeneViewshould(C,S,D)tobethesetofstatementsderivablebyapplyingthealternaterule:own(E1,K1),D(E1)S,K1saysown(E2,K2)own(E2,K2)Intermsofthiscalculus,weobtainconsistencybeensuringthatforanychainandlegitimatetrustset,andHR,thesetViewwill(Chain(E,K,H),S)iscontainedinthesetViewshould(Chain(E,K,H),S,DR).
TherelyingpartyshouldonlyuseacerticatetoreachaconclusionwhentheentiredependencysetofthesignerisinTrustSet(P).
4DesignForsimplicityofverication,wewouldlikeChain(E,K,H)tobealiteralchain:alinearsequenceofcerticatesgoingbacktoroot.
Toensureconsistencyandcompleteness,weneedtomakesurethat,ateachstepinthechain,thepartialsetofcertiersequalsthedependencysetofthatnode(forthedependencyfunctionweseerelyingpartiesusing).
Toachievethisgoal,theelementswecanmanipulateincludegenerationofthischain,aswellashowdependencyisestablishedinthedevice.
4.
1LayerSeparationBecauseofthepost-bootexecutionsequence,codethatexecutesearliercansubvertcodethatexecuteslater.
1IfB,CareLayeri,Layeri+1respectively,thenC→RBunavoidably.
However,theotherdirectionshouldbeavoidable,andweusedhardwaretoavoidit.
Toprovidehigh-assuranceseparation,wedevelopedratchetlocks:anindependentmicrocontrollertracksacounter,resettozeroatboottime.
ThemicrocontrollerwilladvancetheratchetatthemaincoprocessorCPU'srequest,butneverrollitback.
BeforeBinvokesthenextlayer,itrequestsanadvance.
1Withonlyonechancetogetthehardwareright,wedidnotfeelcomfortablewithattemptingtorestorethesystemtoamoretrustedstate,shortofreboot.
OutboundAuthenticationforProgrammableSecureCoprocessors83ToensureBdata→RC,wereservedaportionofBBRAMforB,andusedtheratchethardwaretoenforceaccesscontrol.
ToensureBcode→RC,wewrite-protecttheFLASHregionwhereBisstored.
Theratchethardwarerestrictswriteprivilegesonlytothedesignatedprexofthisexecutionsequence.
Tokeepcongurationentitiesfromneedlesslydependingontheepochen-tities,inourModel2device,wesubdividedthehigherBBRAMtogetfourregions,oneeachforepochandcongurationlifetimes,forLayer2andLayer3.
Theinitialclean-upcodeinLayer1(alreadyinthedependencyset)zeroizestheappropriateregionsontheappropriatetransition.
(FortransitionstoanewLayer1,theclean-upisenforcedbytheoldLayer1andthepermanentLayer0—toavoidincurringdependencyonthenewcode.
)4.
2TheCode-LoadingCodeAsdiscussedelsewhere,wefeltthatcentralizingcode-loadingandpolicyde-cisionsinoneplaceenabledcleanersolutionstothetrustissuesarisingwhendierentpartiescontroldierentlayersofcode.
ButthiscentralizationcreatessomeissuesforOA.
Supposethecode-loadingLayer1entityA1isreloadedwithA2.
BusinessconstraintsdictatedthatA1dothereloading,becausetheROMcodehadnopublic-keysupport.
It'sunavoidablethatA2code→RA1(be-causeA1couldhavecheated,andnotinstalledthecorrectcode).
However,toavoidA1data→RA2,wetakethesestepsasanatomicpartofthereload:A1generatesakeypairforitssuccessorA2;A1usesitscurrentkeypairtosignatransitioncerticateattestingtothischangeofversionsandkeypairs;andA1destroysitscurrentprivatekey.
Thistechnique—whichweimplementedandshippedwiththeModel1devicesin1997—diersfromthestandardconceptofforwardsecurity[1]inthatwechangekeyswitheachnewversionofsoftware,andensurethatthenameofthenewversionisspokenbytheoldversion.
Asaconsequence,asinglemaliciousversioncannothideitspresenceinthetrustchain;foracoalitionofmaliciousversions,thetrustchainwillnameatleastone.
(Section5considersforward-securesignaturesfurther.
)4.
3TheOAManagerSincewedonotknowaprioriwhatdeviceapplicationswillbedoing,wefeltthatapplicationkeypairsneededtobecreatedandusedattheapplication'sdiscretion.
Withinoursoftwarearchitecture,Layer2shoulddothiswork—sinceit'seasiertoprovidetheseservicesatrun-timeinsteadofreboot,andtheLayer1protectedmemoryislockedawaybeforeLayer2andLayer3run.
ThisOAManagercomponentinLayer2willwieldakeypairgeneratedandcertiedbyLayer1,andwillthengenerateandcertifykeypairsattherequestofLayer3.
Thesecerticatesindicatethatsaidkeypairbelongstoanapplication,andalsoincludeaeldchosenbytheapplication.
(Afullertreatmentofour84SeanW.
Smith(a)BCAC1B1B2updatedto(b)BCAC1C2replacedbypenetratesFig.
2.
HavingtheOScertifykeypairsfortheapplicationcreatesinterestinglifetimeissues.
In(a),iftheOSisupdatedwhilepreservingitskeypair,thentheapplicationdependsonbothversions;in(b),iftheOSoutlivestheappli-cationbutispotentiallypenetrable,thentheapplicationmaydependonfutureapplicationstrustcalculuswouldthusdistinguishbetweenowningandtrustingakeypairforcerticationpurposes,andowningandtrustingakeypairfortheapplication-speciedpurpose—thelastlink.
)Tokeepthechainlinear,wedecidedtohaveLayer1generateanddestroytheOAManagerkeypair(e.
g.
,insteadofaddingasecondhorizontalpathbetweensuccessiveversionsoftheOAManagerkeypairs).
ThequestionthenarisesofwhentheOAManagerkeypairshouldbecreatedanddestroyed.
Wediscusssomefalsestarts.
IftheOAManageroutlivedtheLayer2con-guration,thenourcerticationschemecannotbebothconsistentandcom-plete.
Foracounterexample(seeFigure2,(a))supposethatapplicationC1isaconguration-entityontopofOSB1;thatOSB1changescodetoOSB2butbotharepartofthesameentityBCA;andthatpartyPtrustsC1,B1butnotB2.
Fortheschemetobecomplete,PshouldacceptcerticatechainsfromC1—butthatmeansacceptingachainfromBCA,andBCA→RB2∈TrustSet(P).
ThiscounterexamplefailsbecausetheapplicationentityhasaCAwhosedependencysetislargerthantheapplication's.
LimitingtheCAtothecurrentLayer2congurationeliminatesthisissue,butstillfailstoaddresspenetrationrisk.
PartieswhocometobelievethataparticularOScanbepenetratedbyanapplicationcanendupwiththecurrentBCAdependingonfutureapplicationloads.
(SeeFigure2,(b).
)OurnaldesignavoidedtheseproblemsbyhavingtheLayer2OAManagerliveexactlyaslongastheLayer3conguration.
UsingtheprotectedBBRAMregions,weensurethatuponanychangetotheLayer3conguration,Layer1destroystheoldOAManagerprivatekey,generatesanewkeypair,andcertiesittobelongtothenewOAManagerforthenewLayer3conguration.
ThisapproachensuresthatthetrustchainnamesthedependencysetforLayer3congurations—evenifdependencyisextendedtoincludepenetrationoftheOS/applicationbarrier.
Sinceweneedtoaccommodatethenotionofbothepochandcongurationlife-times(aswellastoallowpartieswhochoosetheformertochangetheirminds),weidentifyentitiesbothbytheircurrentepoch,aswellasthecurrentcongura-OutboundAuthenticationforProgrammableSecureCoprocessors85tionwithinthatepoch.
Whenitrequestsakeypair,theLayer3applicationcanspecifywhichlifetimeitdesires;thecerticateincludesthisinformation.
PrivatekeysforacongurationlifetimearekeptintheLayer3congurationregioninBBRAM;privatekeysforanepochlifetimearekeptintheepochregion.
NotethataLayer3epochcerticate(say,forepochE)stillnamesthecong-uration(say,C1)inwhichitbeganexistence.
If,insomelatercongurationCkwithinthatsameepoch,therelyingpartydecidesthatitwantstoexaminetheindividualcongurationstodeterminethewhetheranuntrustedversionwaspresent,itcandothatbyexaminingthetrustchainforCkandthesequenceofOAManagercerticatesfromC1toCk.
AnuntrustedLayer1willberevealedintheLayer1partofthechain;otherwise,thesequenceofOAManagercerticateswillhavecorrectinformation,revealingthepresenceofanyuntrustedLayer2orLayer3version.
4.
4SummaryAsnotedearlier,thetrustchainforthecurrentLayer1versionstartswiththecerticatethefactoryrootsignedfortherstversionofLayer1inthecard,followedbythesequenceoftransitioncerticatesforeachsubsequentversionofLayer1installed.
ThetrustchainfortheOAManagerappendstheOAManagercerticate,signedbytheversionofLayer1activewhenthatLayer3congurationbegan,andprovidingfullidenticationforthecurrentLayer2andLayer3congurationsandepochs.
ThetrustchainforaLayer3keypairappendsthecerticatefromtheOAManagerwhocreatedit.
Ourdesignthusconstitutesatrust-setschemethatisconsistentandcompleteforthedependencyfunctionwefeltwasappropriate,foranylegitimatetrustset.
4.
5ImplementationFullsupportforOAshippedwithallModel2familydevicesandtheCP/Q++embeddedoperatingsystem.
(TheannouncedLinuxport[12]stillhastheLayer1OAhooks;extendingLinuxtohandlethatisanareaoffuturework.
)Implementationrequiredsomeadditionaldesigndecisions.
Toaccommodatesmalldevelopers(Section2.
2),wedecidedtohavetheOAManagerretainallLayer3privatekeysandwieldthemontheapplication'sbehalf;consequently,apartywhotruststhepenetration-resistanceofaparticularLayer2canthustrustthatthekeywasatleastusedwithinthatapplicationonanuntampereddevice.
Anotherdesigndecisionresultedfromtheinsistenceofanexperiencedapplicationarchitectthatusersanddeveloperswillnotpayattentiontodetailsofcerticatepaths;tomitigatethisrisk,wedonotprovidea"verifythischain"service—applicationsmustexplicitlywalkthechain—andwegavedierentfam-iliesofcardsdierentfactoryroots.
Afewaspectsoftheimplementationprovedsurprising.
OneaspectwasthefactthatthedesignrequiredtwoAPIs:onebetweenLayer1andLayer2,andanotherbetweenLayer2andtheapplication.
Anotheraspectwasndingplacestostorekeys.
WeextendedthelimitedareainBBRAMbystoringaMACkey86SeanW.
SmithandaTDESencryptionkeyineachprotectedregion,andstoringtheciphertextfornewmaterialwhereverwecould:duringacode-change,thatregion'sFLASHsegment;duringapplicationrun-time,intheLayer2-providedPPDdatastorageservice.
AnotherinterestingaspectwasthemultiplicityofkeysandidentitiesaddedwhenextendingtheLayer1transitionenginetoperformtheappropriategenerationsandcertications.
Forexample,ifLayer1decidestoacceptanewLayer1load,wenowalsoneedtogenerateanewOAManagerkeypair,andcertifyitwiththenewLayer1keypairasadditionalelementsofthisatomicchange.
Ourcodethusneededtwopassesbeforecommitment:onetodetermineeveryone'snamesshouldthechangesucceed,andanothertothenusethesenamesintheconstructionofnewcerticates.
Ashasbeennotedelsewhere[8],weregretthedesigndecisionstouseourowncerticateformat,andthefactthatthedevicehasnoformofsecuretime(e.
g.
,Layer3canalwayschangetheclock).
Namingthecongurationandepochentitieswaschallenging,particularlysincetheinitialarchitecturewasdesignedintermsofparameterssuchascodeversionandowner,andaprecisenotionof"entity"onlyemergedlater.
5ConclusionsOnemightcharacterizetheentireOAarchitectureprocess"tracingeachdepen-dency,andsecuringit.
"Ourexperiencehere,likeotheraspectsofthiswork,balancedthegoalsofenablingsecurecoprocessingapplicationswhilealsolivingwithinproductdeadlines.
OAenablesAlicetodesignandreleaseanapplica-tion;Bobtodownloaditintohiscoprocessor;andCharlietothenauthenticateremotelythathe'sworkingwiththisapplicationinanuntampereddevice.
Outboundauthenticationallowsthird-partydeveloperstonallydeploycoprocessorapplications,suchasWebservers[14]andrightsmanagementboxes[13],thatcanbyauthenticatedbyanyoneintheInternet,andpartici-pateinPKI-basedprotocols.
Wequicklyenumeratesomeavenuesforfutureresearchandreection.
AlternativeSoftwareStructureOurOAdesignfollowsthe4758architecture'ssequenceofincreasinglyless-trustedentitiesafterboot.
Somecurrentresearchexploresarchitecturesthatdispensewiththislimitingassumption,andalsodis-pensingwiththe4758assumptionsofonecentralloader/policyengine,andofaLayer2thatexistsonlytoserveaone-applicationLayer3.
Itwouldbeinter-estingtoexploreOAintheserealms.
Similarly,theanalysisanddesignpresentedinthispaperassumesthatanauthoritymakesastatementaboutanentityatthetimeakeypairiscreated.
Long-livedentitieswiththepotentialforrun-timecorruptionsuggestongoingintegrity-checkingtechniques.
ItwouldbeinterestingtoexamineOAinlightofsuchtechniques.
OutboundAuthenticationforProgrammableSecureCoprocessors87AlternatePlatformsSinceourwork,theTrustedComputingPlatformAl-liance[21]haspublishedideasonhowremotepartiesmightgainassuranceaboutthesoftwarecongurationofremotedesktopmachines;Microsoftisconsideringsimilarideas[9,10,11].
ItwouldbeinterestingtoexploretheinteractionofourOAworkwiththisincreasinglytimelytopic,aswellasthelongerhistoryofworkinsecurelybootingdesktops[2,6,22].
AlternateCryptographyWedevelopedourtransitioncerticateschemeforLayer1toensurethatnotallcorruptentitiescouldhidetheirpresenceinachain.
Entitiesaside,thisschemeisessentiallyabasicforward-securesignaturescheme(e.
g.
,[4],Sec.
3.
3).
Itwouldbeinterestinghowthebroaderspaceofforward-securesignatureschemesmightbeusedinthesesettings.
AlternateDependencyOurdependencyfunction—entityE1cansubvertE2whenitcanreadorwritesecrets,orwritecode,atanytime—emergedforthespecialcaseofourdevice.
Amorecarefulincorporationoftimewouldbeinter-esting,aswouldanexaminationoftheotheravenuesofmanipulationinmorecomplexsettings(e.
g.
,theopportunitiesforcovertchannelsincommondesktopoperatingsystems,orifthecoprocessorcryptopagestothehostlesystem).
FormalizingTrustSetsOnelinchpinofourdesignwasthedivergenceanddy-namicnatureofwhatrelyingpartiestendtotrust.
(Consequently,ouranalysisassumedthatpartiesmayhave"anylegitimatetrustset.
")Itwouldbeinter-estingtomeasureandformallycharacterizethetrustbehaviorthatoccurs(orshouldoccur)withreal-worldrelyingpartiesandsoftwareentities.
FormalizingPenetrationRecoveryMuchcomplicatedreasoningarosefromsce-nariossuchas"whatif,insixmonths,trustedsoftwarecomponentXturnsoutbeawed"Furtherexplorationofthedesignandimplementationofauthenti-cationschemesthatexplicitlyhandlesuchscenarioswouldbeinteresting.
AcknowledgmentsTheauthorgratefullyacknowledgesthecommentsandadviceofthegreaterIBM4758team;particularthanksgotoMarkLindemann,whoco-codedtheLayer2OAManager,andJonathanEdwards,whotestedtheAPIandtransformeddesignnotesintomanualsandcustomertrainingmaterial.
TheauthorisalsogratefulforthecommentsandadviceoftheInternet2PKILabsonnewresearchissueshere.
Finally,gratitudeisduetheanonymousreferees,whohavemadethisastrongerandclearerpaper.
References[1]R.
Anderson.
Invitedlecture,ACMCCS,1997.
Thedenitivewrit-tenrecordappearstobeTwoRemarksonPublicKeyCryptology,http://www.
ftp.
cl.
cam.
ac.
uk/ftp/users/rja14/forwardsecure.
pdf.
8388SeanW.
Smith[2]W.
A.
Arbaugh,D.
J.
Farber,J.
M.
Smith.
"ASecureandReliableBootstrapAr-chitecture.
"IEEEComputerSocietyConferenceonSecurityandPrivacy.
1997.
87[3]D.
AsonovandJ.
Freytag.
"AlmostOptimalPrivateInformationRetrieval.
"PrivacyEnhancingTechnology2002.
Springer-VerlagLNCS.
73[4]M.
BellareandS.
Miner.
"AForward-SecureDigitalSignatureScheme.
"Ex-tendedabstractappearsinCrypto99,Springer-VerlagLNCS.
Fullversionathttp://www-cse.
ucsd.
edu/~mihir/papers/fsig.
html.
87[5]M.
Bond,R.
Anderson.
"API-LevelAttacksonEmbeddedSystems.
"IEEECom-puter.
34:67-75.
October2001.
73[6]L.
ClarkandL.
J.
Homann.
"BITS:ASmartcardProtectedOperatingSystem.
"CommunicationsoftheACM.
37:66-70.
1994.
87[7]J.
Dyer,R.
Perez,S.
W.
Smith,M.
Lindemann.
"ApplicationSupportArchitec-tureforaHigh-Performance,ProgrammableSecureCoprocessor.
"22ndNationalInformationSystemsSecurityConference.
October1999.
73[8]J.
Dyer,M.
Lindemann,R.
Perez,R.
Sailer,S.
W.
Smith,L.
vanDoorn,S.
Wein-gart.
"BuildingtheIBM4758SecureCoprocessor.
"IEEEComputer,34:57-66.
October2001.
73,86[9]P.
England,J.
DeTrevilleandB.
Lampson.
DigitalRightsManagementOperatingSystem.
UnitedStatesPatent6,330,670.
December2001.
74,87[10]P.
England,J.
DeTrevilleandB.
Lampson.
LoadingandIdentifyingaDigitalRightsManagementOperatingSystem.
UnitedStatesPatent6,327,652.
Decem-ber2001.
74,87[11]P.
England,M.
Peinado.
"AuthenticatedOperationofOpenComputingDe-vices.
"7thAustralasianConferenceonInformationSecurityandPrivacy.
Springer-VerlagLNCS2384.
June2002.
74,87[12]"IBMResearchDemonstratesLinuxRunningonSecureCryptographicCopro-cessor.
"Pressrelease,August28,2001.
85[13]A.
Iliev,S.
W.
Smith.
"PrototypinganArmoredDataVault:RightsManagementforBigBrother'sComputer.
"PrivacyEnhancingTechnology2002.
Springer-VerlagLNCS.
72,86[14]S.
Jiang,S.
W.
Smith,K.
Minami.
"SecuringWebServersagainstInsiderAt-tack.
"ACSA/ACMAnnualComputerSecurityApplicationsConference.
Decem-ber2001.
73,86[15]R.
KohlasandU.
Maurer.
"ReasoningAboutPublic-KeyCertication:OnBind-ingsBetweenEntitiesandPublicKeys.
"JournalonSelectedAreasinCom-munications.
18:551-560.
2000.
(ApreliminaryversionappearedinFinancialCryptography99,Springer-Verlag.
).
78,81[16]U.
Maurer.
"ModellingaPublic-KeyInfrastructure.
"ESORICS1996.
Springer-VerlagLNCS.
78[17]S.
W.
Smith.
SecureCoprocessingApplicationsandResearchIssues.
LosAlamosUnclassiedReleaseLA-UR-96-2805,LosAlamosNationalLaboratory.
August1996.
72[18]S.
W.
Smith,E.
R.
Palmer,S.
H.
Weingart.
"UsingaHigh-Performance,Pro-grammableSecureCoprocessor.
"Proceedings,SecondInternationalConferenceonFinancialCryptography.
Springer-VerlagLNCS,1998.
73[19]S.
W.
Smith,D.
Saord.
"PracticalServerPrivacyUsingSecureCoprocessors.
"IBMSystemsJournal(specialissueonEnd-to-EndSecurity)40:683-695.
2001.
73OutboundAuthenticationforProgrammableSecureCoprocessors89[20]S.
W.
Smith,S.
H.
Weingart.
"BuildingaHigh-Performance,ProgrammableSe-cureCoprocessor.
"ComputerNetworks(SpecialIssueonComputerNetworkSecurity).
31:831-860.
April1999.
73[21]TrustedComputingPlatformAlliance.
TCPADesignPhilosophiesandCon-cepts,Version1.
0.
January,2001.
74,87[22]J.
D.
TygarandB.
S.
Yee.
"Dyad:ASystemforUsingPhysicallySecureCo-processors.
"ProceedingsoftheJointHarvard-MITWorkshoponTechnologicalStrategiesfortheProtectionofIntellectualPropertyintheNetworkMultimediaEnvironment.
April1993.
87[23]N.
vanSomeren.
"AccessControlforSecureExecution.
"RSAConference2001.
74[24]B.
S.
Yee.
UsingSecureCoprocessors.
Ph.
D.
thesis.
ComputerScienceTechnicalReportCMU-CS-94-149,CarnegieMellonUniversity.
May1994.
72,73[25]B.
S.
YeeandJ.
D.
Tygar.
"SecureCoprocessorsinElectronicCommerceAppli-cations.
"1stUSENIXElectronicCommerceWorkshop.
1996.
72[26]B.
S.
Yee.
ASanctuaryForMobileAgents.
ComputerScienceTechnicalReportCS97-537,UCSD,April1997.
(AnearlierversionofthispaperappearedattheDARPAWorkshoponFoundationsforSecureMobileCode.
).
73