Lecture Notes in Computer Science 5471 - tiera.ru

Liqun Chen Chris J. MitchellAndrew Martin (Eds.)Trusted ComputingSecond International Conference, Trust 2009Oxford, UK, April 6-8, 2009Proceedings13

Volume EditorsLiqun ChenHewlett-Packard LaboratoriesFilton Road, Stoke Gifford, Bristol BS34 8QZ, UKE-mail: liqun.chen@hp.comChris J. MitchellRoyal Holloway, University of LondonInformation Security GroupEgham, Surrey TW20 0EX,UKE-mail: c.mitchell@rhul.ac.ukAndrew MartinOxford UniversityComputing LaboratoryWolfson Building, Parks Road, Oxford OX1 3QD, UKE-mail: andrew.martin@comlab.ox.ac.ukLibrary of Congress Control Number: 2009921804CR Subject Classification (1998): D.4.6, K.6.5, E.3, C.2, C.3, D.2, H.4, H.5, K.4LNCS Sublibrary: SL 4 – Security and CryptologyISSN 0302-9743ISBN-10 3-642-00586-1 Springer Berlin Heidelberg New YorkISBN-13 978-3-642-00586-2 Springer Berlin Heidelberg New YorkThis work is subject to copyright. All rights are reserved, whether the whole or part of the material isconcerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting,reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publicationor parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965,in its current version, and permission for use must always be obtained from Springer. Violations are liableto prosecution under the German Copyright Law.springer.com© Springer-Verlag Berlin Heidelberg 2009Printed in GermanyTypesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, IndiaPrinted on acid-free paper SPIN: 12634439 06/3180 543210

PrefaceThis volume contains the 15 papers presented in the technical strand of the Trust2009 conference, held in Oxford, UK in April 2009. Trust 2009 was the secondinternational conference devoted to the technical and socio-economic aspectsof trusted computing. The conference had two main strands, one devoted totechnical aspects of trusted computing (addressed by these proceedings), andthe other devoted to socio-economic aspects.Trust 2009 built on the successful Trust 2008 conference, held in Villach,Austria in March 2008. The proceedings of Trust 2008, containing 14 papers,were published in volume 4968 of the Lecture Notes in Computer Science series.The technical strand of Trust 2009 contained 15 original papers on the designand application of trusted computing. For these proceedings the papers havebeen divided into four main categories, namely:– Implementation of trusted computing– Attestation– PKI for trusted computing– Applications of trusted computingThe 15 papers included here were selected from a total of 33 submissions.The refereeing process was rigorous, involving at least three (and mostly more)independent reports being prepared for each submission. We are very gratefulto our hard-working and distinguished Program Committee for doing such anexcellent job in a timely fashion. We believe that the result is a high-qualityset of papers, some of which have been significantly improved as a result of therefereeing process.We would also like to thank all the authors who submitted their papers tothe technical strand of the Trust 2009 conference, all external referees, and allthe attendees of the conference.It is intended that this conference is the second in an annual series of conferencesdevoted to trusted computing, and we look forward to Trust 2010.January 2009Liqun ChenChris Mitchell

OrganizationTrust 2009The Second International Conference on Trusted Computing(Technical Strand) was held at St. Hugh’s College, Oxford, UK duringApril 6–8, 2009General ChairAndrew MartinUniversity of Oxford, UKProgram ChairsLiqun ChenChris MitchellHewlett-Packard Laboratories, UKRoyal Holloway, University of London, UKProgram CommitteeEndre BangerterDavid ChallenerJames DavenportRobert DengLoïc DuflotPaul EnglandSigrid GuergensDirk KuhlmannPeter LippJavier LopezAndrew MartinYi MuDavid NaccacheHeike NeumannElisabeth OswaldKenny PatersonRaphael PhanBart PreneelGraeme ProudlerSihan QingCarsten RudolphMark RyanAhmad-Reza SadeghiBern University of Applied Sciences, SwitzerlandLenovo, USAUniversity of Bath, UKSingapore Management University, SingaporeSGDN/DCSSI, FranceMicrosoft, USAFraunhofer, GermanyHP Laboratories, UKIAIK, TU Graz, AustriaUniversity of Malaga, SpainUniversity of Oxford, UKUniversity of Wollongong, AustraliaENS, FranceNXP Semiconductors, GermanyUniversity of Bristol, UKRHUL, UKUniversity of Loughborough, UKKU Leuven, BelgiumHP Laboratories, UKChinese Academy of Sciences, ChinaFraunhofer, GermanyUniversity of Birmingham, UKRuhr University Bochum, Germany

VIIIOrganizationJean-Pierre SeifertAri SingerSean SmithChristian StüebleLeendert van DoornVijay VaradharajanSamsung Research, USANTRU, USADartmouth College, USASirrix, GermanyAMD, USAMacquarie University, AustraliaSteering CommitteeBoris BalacheffIan BrownAndrew MartinChris MitchellAhmad-Reza SadeghiHewlett-Packard Laboratories, UKUniversity of Oxford, UKUniversity of Oxford, UKRoyal Holloway, University of London, UKRuhr University Bochum, GermanyExternal ReviewersTien Tuan Anh DinhKurt DietrichJim GrimmettXinyi HuangJun Ho HuhQingguang JiMarkulf KohlweissStephan KrennGaiCheng LiHans LöhrJohn LyleSandra MarcelloAybek MukhamedovAarthi NagarajanDan PageDries SchellekensQingni ShenNigel SmartBen SmythUdaya Kiran TupakulaBogdan WarinschiMarcel Winandy

Table of ContentsImplementation of Trusted ComputingTowards a Programmable TPM .................................... 1Paul England and Talha TariqACPI: Design Principles and Concerns .............................. 14Loïc Duflot, Olivier Levillain, and Benjamin MorinImplementation Aspects of Mobile and Embedded TrustedComputing ...................................................... 29Kurt Dietrich and Johannes WinterModeling Trusted Computing Support in a Protection Profile for HighAssurance Security Kernels ........................................ 45Hans Löhr, Ahmad-Reza Sadeghi, Christian Stüble,Marion Weber, and Marcel WinandyAttestationRemote Attestation of Attribute Updates and Information Flows in aUCON System ................................................... 63Mohammad Nauman, Masoom Alam, Xinwen Zhang, andTamleek AliMeasuring Semantic Integrity for Remote Attestation ................. 81Fabrizio Baiardi, Diego Cilea, Daniele Sgandurra, andFrancesco CeccarelliPKI for Trusted ComputingA PrivacyCA for Anonymity and Trust ............................. 101Martin Pirker, Ronald Toegl, Daniel Hein, and Peter DannerRevocation of TPM Keys ......................................... 120Stefan Katzenbeisser, Klaus Kursawe, and Frederic StumpfApplications ISecuring the Dissemination of Emergency Response Data with anIntegrated Hardware-Software Architecture .......................... 133Timothy E. Levin, Jeffrey S. Dwoskin, Ganesha Bhaskara,Thuy D. Nguyen, Paul C. Clark, Ruby B. Lee,Cynthia E. Irvine, and Terry V. Benzel

XTable of ContentsTrustable Remote Verification of Web Services ....................... 153John LyleTrustworthy Log Reconciliation for Distributed VirtualOrganisations ................................................... 169Jun Ho Huh and John LyleAttacking the BitLocker Boot Process .............................. 183Sven Türpe, Andreas Poller, Jan Steffan, Jan-Peter Stotz, andJan TrukenmüllerApplications IISecure VPNs for Trusted Computing Environments .................. 197Steffen Schulz and Ahmad-Reza SadeghiMerx: Secure and Privacy Preserving Delegated Payments ............. 217Christopher Soghoian and Imad AadA Property-Dependent Agent Transfer Protocol ...................... 240Eimear Gallery, Aarthi Nagarajan, and Vijay VaradharajanAuthor Index .................................................. 265

2 P. England and T. TariqUsing the TPM to bootstrap trust into an execution environment like a platformhypervisor or operating system is adequate for many purposes, however data andapplication programs running on the main processors are much less protected fromphysical attack than programs and data held inside the TPM. This problem is evidentfrom the recent hardware attacks on applications utilizing TPMs [3], [4], [5]. Theproblems of software robustness are even more challenging: mainstream operatingsystems have an ill-defined Trusted Computing Base (TCB) that is generally not secureenough for attestation to be meaningful [6].Guest OS (a) Guest OS (b)ApplicationApplicationHypervisorPrimary OS /Domain 0Smart cardDevicedriverTPMApplicationCrypto ChannelEndpointHypervisorSmart CardTPM-CoreProgrammable TPMTPM CoreFig. 1. (a) Schematic illustration of a programmable TPM and its use in a hypervisor setting.We assume that the TPM can load and run applications and the services implemented can beexposed to the hypervisor and guest operating systems. (b) Schematic of one instantiation ofour coupled TPM smart card architecture: The TCB and TPM are coupled to the smart cardusing an out-of-band cryptographic marrying step. The cryptographic channels (thick lines)represent authenticated and secure connections from the smart card to the TPM and the smartcard to the channel end-point.If the host-platform-based secure environment is not secure enough, we might considerbuilding a secure execution environment inside a TPM such as that illustrated inFig 1(a). Such a system should provide much better robustness to hardware and softwareattack than that offered by platform macrocode. And indeed, such devices havebeen studied by researchers, but unfortunately they do not yet exist [7].In this paper we propose an alternative architecture for providing high-assuranceextended TPM services. Instead of making changes to the TPM hardware design, wedescribe and evaluate an architecture in which we couple a programmable smart cardto a TPM to provide programmable services that are not possible with either alone.See Fig. 1 (b). This architecture has many interesting characteristics: First it is a practicalway of providing enhanced security functionality for existing TPMs. Second, itprovides a way of prototyping new TPM functions to assess their usefulness beforecommitting them to silicon, and finally it allows us to explore the design and assessthe usefulness of a true “programmable TPM.”We have built several advanced security services to help us understand this architectureand demonstrate its capabilities. The services described in this paper are:

Towards a Programmable TPM 3Count-Limited Objects: An implementation of TPM keys that can only be used toperform cryptographic operations a preset number of times. This capability is designedto simplify some aspects of key revocation and support rights-management.Flexible Seal and Unseal: An implementation of the Seal, Unseal, and Unbind primitivesthat allow more complex policy expressions than the simple Platform ConfigurationRegister (PCR) equality checks supported by the current TPM specifications 1 . Onepolicy expression allows sealing to a software publisher or other authority identified bya public key. In this case the publisher may later authorize any PCR configuration usinga certificate signed using the associated private key. Another policy expression allowsmore complex logical expressions of authorized configurations (e.g. PCR configuration1 or PCR configuration 2). Both of these enhancements are designed to make softwareupdates and grouping of equivalent programs easier to manage.Attestation Translation: A smart card service that provides attestation using cryptographyand signature formats unavailable within a TPM. This is a proof of conceptof attestation translation: a more sophisticated implementation could provide platformattestation in more widely used signature and certificate formats like X.509. Thisfacility should simplify the deployment of attestation because existing servers andprotocols can be used.The paper is organized as follows. In section 2 we describe the coupling architecture.In section 3 we describe the security primitives that we have prototyped, and insections 4 and 5 we describe the limitations of the coupling architecture and possiblefurther work.2 TPM to Smart Card CouplingWe seek to approximate a field-programmable TPM in which the secure executionenvironment for user extensible application programs is part of the host platformTPM. However when emulating a programmable TPM using a conventional fixedfunctionTPM and an external smart card, the secure execution environment is externalto the TPM, is independent of the host state, and can be freely roamed betweenmachines. This creates several challenges that we need to address: First, the executionenvironments provided by the host system and a smart card are relatively independent.For example, smart card applications can still run if the smart card is movedbetween different host machines. Second, TPM-to-host-TCB communications arerelatively well protected (for example TPM communications are on a motherboardinternal bus) whereas in coupling with an external smart card, the smart card bus isexposed, and communications are sometimes managed by drivers running outside theTCB (Fig. 1(b)).2.1 Coupling Security RequirementsIf the smart card is to provide TPM-enhanced platform services we need to couple thesmart card and the host platform more tightly.1 At the time of this writing the current TPM specifications is version 1.2.

Towards a Programmable TPM 5Export AIK public keyLoad TPMs Key inSmartCardGenerate RSAIdentity keyExport Card Public KeyGenerate AIKSeal smart cardpublic keySmartCardPlatform + TPMFig 2. Cryptographic Binding of the TPM and Smart Cardproof-of-password-possession protocols. Finally, the count-limited key functionuses the TPM capability for remote creation and encryption of keys using the TPMkey-storage hierarchy.In our implementation two more smart card keys are created as part of the marryingstep. A symmetric AES key is created for off-card storage of smart card createdsealed data blobs, and an RSA signing key is created for the attestation translationfunction. If a new binding is performed all previous bound data becomes inaccessibleand the quote translation key is destroyed (just like installing a new owner in a TPM).We also need integrity protected host storage for the host TCB to store the marriedsmart card public key. Since the security model for trusted computing does not generallyassume storage is trustworthy unless protected by cryptography, we use the hostTPM_Seal primitive to integrity protect the married smart card public key. The smartcard has genuine access-protected storage so no cryptographic measures are needed.Our current implementation assumes that the smart card applications are loadedprior to the marrying step. A more sophisticated version would provide a useraccessiblesmart card execution environment and services that let the smart card applicationsauthenticate themselves (see section 5).Our architecture is generic and independent of the nature of host software: it can beapplied to systems that employ a hypervisor, an operating system without a hypervisor,or applications running directly on the computer hardware. From our perspectiveall that differs is the nature of the TCB and the PCRs that are used to identify theplatform state. Of course the choice of trusted computing base has practical implicationsfor the comprehensibility and relevance of host PCR values [6].3 Smart Card Enhanced TPM Security PrimitivesIn this section we describe the implementation of three security primitives that demonstratethe possibilities of the TPM to smart card coupling architecture. 2 Note thatthe smart card functions appear somewhat hard to use. This is because we generallyfavor performing only essential security functions in the smart card (which is slow2 These experiments used a Dell Optiplex 745 running Vista SP1 and containing an Atmel TPMversion 1.2 with firmware version 13.9. The smart card was a Gemalto.NET v2 card with80Kbyte of memory for code and data.

8 P. England and T. Tariqperforms this check in the same way that any other remote entity would determine theplatform configuration: i.e. the smart card demands that host software provide evidencefor the current state by means of the output of a Quote operation using the marriedAIK and a smart card provided nonce (to prevent replay). If host software canrespond with evidence of an authorized configuration, the smart card will release thesealed data to the TCB.We describe the smart card operations that support the Seal and Unseal implementations;Unbind is similar to Unseal.Sealing to a List of PCR ConfigurationsThe following smart card functions support sealing to a list of configurations. Seal-ToConfigurationList is the smart card function that protects the data. The sealer needonly specify the hash of the list of authorized configurations at this stage. Unseal-ConfigurationList is the corresponding unseal function. Here the caller must specifythe whole configuration list (which the smart card will hash to ensure it matches thespecified policy) and the policy element number that the smart card should attempt tosatisfy. The smart card must also be given proof of the current platform configurationby means of the output of a TPM_Quote operation over the relevant PCRs. Replayresistance for the quoted configuration is provided by a smart card provided nonce,which must be obtained using the smart card GetNonce function.In more detail, the pseudo-code for the commands follows:SealToConfigurationListInput:A secret s,the hash of a list of authorized configurations lOutput:A sealed encrypted blobActions:Integrity-protect and encrypt the concatenation of s, and lGetNonceInput:NoneOutput:A 20 byte random nonceActions:Create and return a random nonceUnsealConfigurationListInputs:A sealed blob, bThe expected configuration list, lThe list element number that we expect to satisfy, iThe output of a TPM Quote on the current configuration, qOutputs:The previously sealed data or an error

Towards a Programmable TPM 9Actions:1) Decrypt the sealed blob b returning the secret s and the policylist hash h2) Check that the hash of l matches the policy hash h3) Check that the TPM signature q is formed signature using themarried AIK over the l[i] (the configuration element that weexpect to match) and the previously supplied nonce4) Return the secret data s if all of the above checks succeed, elsereturn an errorSealing to a Configuration Authorized by a Public KeyThe following smart card functions support sealing to PCR configurations authorizedby a public key. SealToPublicKey encrypts a secret and the public key of an entitytrusted to authorize future platform configurations. UnsealPublicKey is the correspondingunseal function. UnsealPublicKey must be provided with the originalsealed blob and a signed statement from policy key holder authorizing a PCR configuration.The caller must also provide the result of a TPM_Quote operation that provescompliance with the specified configuration. If policy compliance is proven thesealed data is released. As before, the caller must obtain a fresh nonce from the smartcard and have it incorporated into the Quoted data structure.In pseudo code:SealToPublicKeyInput:A secret s,A public key kOutput:An encrypted blobActions:Integrity-protect and encrypt the concatenation of s, and kGetNonceSee aboveUnsealPublicKeyInputs:A bound blob b,An authorized PCR configuration from the server c,A signature over the authorized PCR configuration from the server S,The output of a TPM Quote operation qOutputs:The sealed data or an errorActions:1) Decrypt the sealed blob b returning the secret s and the public key k2) Validate that the signature S is valid for the configuration c usingthe public key k

10 P. England and T. Tariq3) Validate that q is a TPM signature over the configuration c using themarried TPM AIK and the expected nonce4) Return the secret s if the above checks succeed, else return an errorOne detail is omitted from the description above. The TPM implementation of Sealrecords PCR values at the time of sealing for the purposes of source platform andconfiguration authentication. Our implementation of Seal also takes the output of aQuote operation over a smart card provided nonce to provide similar capabilities.All data communicated between the TCB and the smart card is passed over the securechannel described in section 2. The channel endpoints are authenticated usingthe married TPM and smart card keys.3.3 Enhanced QuotesThe TPM_Quote operation creates a signature using an AIK over a data structure thatincludes TPM internal state as reflected in PCR values, and externally provided data(for freshness, or to associate the configuration with some other cryptographic object).This building block is designed to be used in cryptographic protocols that proveknowledge of the AIK and prove the current platform state. Unfortunately the TPMsignature format is non-standard, and this is one of the things that has made it difficultto adopt TPM attestation technology.We have prototyped a smart card function that translates the platform configurationprovided by the TPM into another format. Our proof of concept also uses nonstandarddata structures, but a more sophisticated implementation would use a certificateformat like X.509. Such certificates could be used for network access control, orin an email or document signing scenario to prove the machine and machine configurationwhen the document was signed [11],[12].Our configuration rewriting function is called TranslateQuote. It must be calledwith fresh evidence of the current configuration by means of the output of theTPM_Quote operation over a smart card nonce. TranslateQuote checks the quotesignature is properly formed and is issued by the married AIK. If both conditionshold, the smart card generates a signature over the TPM-specified state, and an externalnonce.In pseudo code:GetNonceSee aboveTranslateQuoteInputs:The data structure supplied to the TPM_Quote operation q,The TPM-quoted signature s over this data structure and the previouslyobtained nonce,External data to sign dOutputs:A smart card created signature or an error

Towards a Programmable TPM 11Actions:1) Check that s is a valid signature over the data q and the nonce usingthe married AIK2) If the check succeeds return a smart card signature over a translationof q and the external data d, else return an error4 Programmable TPMsOur coupling architecture strikes a useful balance between flexibility and deployabilityusing today’s generally available commodity hardware since it requires no modificationto the current specifications of the TPM 3 and uses general purposeprogrammable smart cards, but it is interesting to speculate on the design and improvedfunctionality of a future programmable TPM.There are many possible models for a programmable TPM. Useful starting placesinclude multi-application programmable Java or .Net smart cards, or the Trusted ExecutionModel (TEM) described by Costan et al. [13]. Perhaps the simplest conceptualdesign for a programmable TPM is to replicate the security model for code executingoutside the TPM but applied to user-code running inside the TPM. The TPM alreadyhas a model for authenticating security modules executing outside, which is the notionof locality coupled with the DRTM launch procedure [14]. This secure late-launchprocedure has been used by the Oslo project [15] and Flicker [16]. Applying this ideato an execution environment inside the TPM would involve the definition of a newlocality for access by TPM applications, and new PCR-registers dedicated to theirmeasurements. See Fig. 3. However, beyond privileges associated with access locality,internal TPM applications would have the same access to other TPM functionsand keys as applications running outside the TPM.OtherHostSoftwareOther Host SoftwareDRTM-Launched SecurityKernelTPMLocality-Locked PCRDRTM-LaunchedSecurity KernelT-RTM-LaunchedSecurity ApplicationTPM-CoreLocality-Locked PCRFig. 3. Left: A TPM supporting a DRTM-launched security kernel. The DRTM procedure andplatform hardware and firmware ensures that a special PCR contains a reliable measurement ofthe external security kernel, and that the TPM can authenticate commands originating from thesecurity kernel. Right: Applying this model to a programmable TPM would define a new localityand associated “TPM-Root-of-Trust-of-Measurement” (T-RTM) to hold measurement of theTPM internal programmable security functions.3 As of this writing the current version of TPM Specifications is 1.2.

12 P. England and T. TariqUnfortunately there are limits to the types of functions that can be supported usingthis sort of programmable TPM because TPM protected data is not accessible tothe user applications. So while it would be possible to create a new class of storagekey with sophisticated migration features with this design, it would not be possibleto provide this migration capability to the storage root key (SRK) because the SRKprivate data is inaccessible. Allowing third party code access to TPM private keysand other protected data changes the TPM security model profoundly, so we generallyprefer designs that supplement existing functionality rather than replacing ormodifying it.5 Conclusions and Future WorkWe currently only support applications that are pre-loaded onto the card prior to TPMcard marrying. This is probably adequate for most enterprise use (the enterprise willload line-of-business applications onto the smart card prior to issuance) but does notexercise the full potential of the coupling architecture.To go beyond pre-loaded applications we must provide an isolated execution environmentfor applications in the smart card, and provide a means for these applicationsto authenticate themselves to the host computer. The isolation and authenticationprimitives are necessary because we can no longer necessarily trust the applicationsrunning on the card. This seems most straightforwardly solved by re-applying theprinciples of authenticated operation but within the smart card. In particular wewould need to modify the smart card application loader to measure and record theapplication digest (or other authentication data) and provide the smart card applicationwith sealing and attestation services. Smart card applications could use these primitivesto prove to the platform TCB that it is communicating with a trustworthy cardand card application.Delivering the promise of Trusted Computing has been delayed by a number ofproblems. These include the relative unavailability of mainstream operating systemsand hypervisors with useful security properties, problems balancing the high levels ofsecurity provided by the TPM and ease of management, and problems using the TPMto enhance existing security applications and scenarios. Our work demonstrates thatlogic and cryptographic operations running on a smart card coupled with the hostplatform and TPM can mitigate all of these issues, and is also an interesting prototypingenvironment for experimenting with new functionality that could be incorporatedinto future TPM designs.The three applications we implemented were chosen to exercise local- and remote-trustverification, and to mitigate some of the problems that the authors haveexperienced in trying to apply trusted computing to real problems. Other candidateapplications included keys with more sophisticated key management and migrationfunctions, a software-TPM on the smart card, a “roaming-TPM” for use in an enterprise,and general experimentation on the correct definition of security primitivesfor future TPM designs.

Towards a Programmable TPM 13References1. Trusted Computing Group TPM Specification Version 1.2 Revision 103 (2007),https://www.trustedcomputinggroup.org/specs/TPM/2. England, P., Peinado, M.: Authenticated operation of open computing devices. In: Batten,L.M., Seberry, J. (eds.) ACISP 2002. LNCS, vol. 2384, pp. 346–361. Springer, Heidelberg(2002)3. Sparks, E.R.: A Security Assesment of Trusted Platform Modules. Dartmouth College,Technical Report. TR2007-5974. Halderman, J.A., et al.: Lest We Remember: Cold Boot Attacks on Encryption Keys. In:Proc. 2008 USENIX Security Symposium (2008)5. Bruschi, D., et al.: Attacking a Trusted Computing Platform. Improving the Security of theTCG Specification. Technical Report. Università degli Studi di Milano. Milan (2005)6. England, P.: Practical Techniques for Operating System Attestation. Proceedings of Trust(2008)7. Costan, V., et al.: The Trusted Execution Module: Commodity General-Purpose TrustedComputing. In: Eighth Smart Card Research and Advanced Application Conference8. Offline dictionary attack on TCG TPM weak authorisation data, and solution. In: Chen, L.,Ryan, M.D., Grawrock, D., Reimer, H., Sadeghi, A., Vishik, C. (eds.): Future of Trust inComputing, Vieweg & Teubner, 2008 (2008)9. Sarmenta, L.F., et al.: Virtual Monotonic Counters and Count-Limited Objects using aTPM without a Trusted OS (Extended Version), Mit Technical Report MIT-CSAIL-TR-2006-064 (2006)10. George, P.: User Authentication with Smart Cards in Trusted Computing. In: Arabnia,H.R., Aissi, S., Mun, Y. (eds.) Security and Management, SAM 2004, pp. 25–31. CSREAPress, Las Vegas (2004)11. Balacheff, B., et al.: A trusted process to digitally sign a document. In: Proceedings of the2001 workshop on New security paradigms. pp. 79–86 (2001) 1-58113-457-612. Giraud, J.-L., Rousseau, L.: Trust Relations in a Digital Signature System Based on aSmart Card. In: Proceedings of 23rd National Information Systems Security Conference,Baltimore13. Costan, V.: The Trusted Execution Module Commodity General-Purpose Trusted Computing.In: The Eighth Smart Card Research and Advanced Application Conference14. Grawrock, D.: The Intel Safer Computing Initiative: Building Blocks for Trusted Computing,1st edn. Intel Press (2006) 097648326215. Kauer, B.: OSLO: Improving the Security of Trusted Computing. In: Proceedings of the16th Usenix Security Symposium (2001)16. McCune, J.M., et al.: Flicker: An Execution Infrastructure for TCB Minimization. In: Proceedingsof the ACM European Conference on Computer Systems (EuroSys 2008) held inGlasgow (2008)

ACPI: Design Principles and ConcernsLoïc Duflot, Olivier Levillain, and Benjamin MorinDCSSI 51 bd. de la Tour Maubourg 75700 Paris Cedex 07 FranceAbstract. ACPI (Advanced Configuration Power Interface) allows operatingsystems to efficiently configure the hardware platform they arerunning on and deal with power management tasks. These tasks used tobe achieved by the BIOS because it was the only platform componentto know which specific chipset or device registers dealt with power management.In this paper, we illustrate how this shift in the global powermanagement model introduces additional threats, especially for trustedplatforms, by showing how rootkits can use ACPI to conceal some oftheir functions. We also study the relationship between trusted computingblocks and ACPI.Keywords: ACPI, trusted platforms, rootkits.1 IntroductionACPI (Advanced Configuration and Power Interface) [8] was specified by Intel R ,Hewlett-Packard, Microsoft R ,Phoenix R and Toshiba to establish common interfacesfor platform-independent configuration and power management. In theACPI model, the OSPM (Operating System-directed configuration and PowerManagement) is the specific operating system component in charge of powermanagement tasks. ACPI has been widely accepted as a de-facto standard toreplace the former APM [16] (Advanced Power Management) approach, wherepower management was mostly performed by the BIOS. Pushing power managementat the operating system level allows more flexibility and more complexpower management schemes. However, operating systems are generic objects bynature, so the hardware platform must provide the operating system with somemeans of understanding how power management should be achieved on thisspecific platform. This is the purpose of the ACPI tables.On a trusted platform, the trusted computing base is generally in charge ofpower management. If the trusted computing base is to run on several platforms,then it must make use of the ACPI tables provided by the BIOS. In this paper,we try to determine whether the trusted computing base can trust the ACPItables, or if there is a way for an attacker to modify those tables as a means forprivilege escalation on a platform, and what would be the impact of a bug inone of the ACPI tables.It is well understood in the industrial world that ACPI is one of the most complexcomponents to deal with from a security perspective on a trusted platform(along with System Management Mode for instance). During the 2006 BlackhatL. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 14–28, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

ACPI: Design Principles and Concerns 15forum, John Heasman [6] presented how it is possible to design an ACPI-basedrootkit. However, to our best knowledge, our paper is one of the first attempt tostudy the initial design flaws and to present a comprehensive proof-of-conceptof an ACPI rootkit-like function that can be triggered by external hardwareevents (laptop lid opening, power adapter plugged and removed twice in a rowfor instance).In section 2, we present the way ACPI works on a traditional computer andshow how ACPI is handled on a Linux system. Section 3 gives a description ofthe flaws in the ACPI model that make it possible for an attacker to use ACPIto conceal rootkit functions. In section 4, we present an actual proof-of-conceptof an ACPI rogue code that allows an attacker to install a remanent backdoor ona Linux-based laptop that will be triggered when the power adapter is pluggedand unplugged twice in a row. In section 5, we describe how the problem can behandled on so-called trusted platforms. Section 6 concludes the paper.2 ACPI Design PrinciplesFor the sake of simplicity, we only consider in this paper traditional x86 andBIOS-based computer platforms.2.1 Traditional PC ArchitectureFigure 1 shows a traditional PC architecture. User code (trusted computingbases, operating systems, applications) run on the CPU [10]. The chipset componentis in charge of hardware devices management. The northbridge [9] partof the chipset is connected to main system memory (RAM) and to the graphicadapter. The southbridge [14] part of the chipset is connected to other devices(network interface controller, sound device, USB devices) through various communicationbuses. Power management of a device is achieved at the hardwarelevel by modifying the content of configuration registers hosted by the chipset(northbridge, southbridge or both depending on the device) and in the deviceitself. Those registers can be accessed from the CPU using several different mechanisms[13]:– some registers are mapped by the chipset into the main system memoryspace. Those so-called Memory-Mapped I/O registers can thus be accessedby the CPU in the same way as RAM is, but at different addresses;– some registers are mapped into a separate 16-bit bus. These registers arecalled Programmed I/O (PIO) registers. They are given an address in thePIO space and can be accessed from the CPU using “in” [11] and “out” [12]assembly langage instructions;– the chipset can also choose to map configuration registers into the PCI configurationspace [17]. One way to access those registers is to use two dedicatedPIO registers, 0xcf8 and 0xcfc, by specifying the PCI address of the register(composed of a bus number, a device number, a function index and an offset)

16 L. Duflot, O. Levillain, and B. MorinPCI Express busCPUChipsetGraphicadapterNorthbridgeRAMPCI devices SouthbridgePCI busUSB busUSB devices IDE, SATATPMLPC busFig. 1. Traditional PC architecture (example Pentium R 4-based architecture)in the 0xcf8 register and reading (resp. writing to) the 0xcfc register to read(resp. write) the content of the PCI register.2.2 ACPI ComponentsIn the model, the chipset itself does not attempt to configure power managementregisters. Configuration is actually initiated by software components running onthe CPU. At boot time, the BIOS is likely to configure the hardware, while operatingsystems or trusted computing bases are in charge of power managementonce the boot process is over.In the ACPI model, the platform provides an ACPI BIOS, several ACPIregisters that are accessed for power management purpose (they can be eitherMemory Mapped registers, Programmed I/O registers or PCI configuration registers),and ACPI tables that basically specify how ACPI registers should beaccessed.ACPI tables have different types and purposes:– the Root System Description Table (RSDT) contains a set of pointers tothe other tables. The address of the RSDT is provided by the Root SystemDescription Pointer (RSDP), which must be stored in the Extended BIOSData Area (EBDA), or in the BIOS read-only memory space. The OSPMwill only locate the RSDP by searching for a particular magic number (theRSDP signature) that the RSDP is required to begin with;– the Differentiated System Description Table (DSDT), the address of whichcan be determined thanks to the pointer provided by the RSDT, containsthose methods that should be used by the component in charge of powermanagement and specifies how the power characteristics of the devices shallbe modified. The ACPI specification only defines the methods that are availablefor each device and their meaning. Actions defined in the methods are

ACPI: Design Principles and Concerns 17machine-specific. The DSDT is written in AML (ACPI Machine Langage)[8], which can be disassembled into a more comprehensible language, calledASL (ACPI Specification Langage)[1];– many other tables are also provided, but for the sake of simplicity, we willnot give details on them.ACPI does not standardise power management at the software level, but operatingsystems are advised to include the following components to perform powermanagement tasks:– an Operating System-directed configuration and Power Management component(OSPM) running at the kernel level should be in charge of the overallpower management strategy;– an ACPI driver and AML interpreter should be used by the OSPM to executethe contents of the methods specified in the DSDT;– device drivers should optionally make use of the AML interpreter to performpower management independently of the OSPM.ACPI components and their relationships with the kernel are summarized inFigure 2.2.3 DSDT Basic StructureThe DSDT describes those devices that support power management. Devicesare organized in packages in a tree-like structure. Several standardized packagesare located under the root (labelled \) of the tree, such as the \_PR Processortree package, which stores all CPU related objects and the \_SB System Bustree package, which stores all bus-related resources. PCI resources (e.g., PCI0,PCI1)arelocatedinthe\_SB package. In turn, devices can be defined in otherdevices’ subtrees. For instance, IDE or USB controllers can be accessed in thetree below the PCI0 device; the path to the USB0 host controller on the DSDTtree is thus \_SB.PCI0.USB0. Power management-related methods are the leavesof the tree. For example, the method that allows the USB0 controller to transitto the S5 power state is \_SB.PCI0.USB0._S5. Most method names are definedin the ACPI standard, so that the OSPM knows which method to call. Exampleof such standard methods are given in [8].Power management basically works as follows: in response to some hardwaretriggeredevent, or based on its own policy, the OSPM can initiate a powermanagement-related action by executing the corresponding AML method in theDSDT. For instance, in order to put one of the USB controller in the S5 powerstate, the OSPM simply has to run the \_SB.PCI0.USB0._S5 method.2.4 ACPI Machine Language and ACPI Source LanguageAML-written tables can be disassembled in ACPI source language (ASL) usingfor instance the ACPIca tools [1]. The ASL language provides basic constructs in

18 L. Duflot, O. Levillain, and B. MorinSoftware. Outside of the scopeof ACPI specificationsApplicationsKernelOSPMDevicedriversAMLinterpreterACPI BIOSACPIRegistersACPIProvided by the platformACPITablesHardware devicesFig. 2. ACPI architectureorder to define ACPI registers and methods. Logical and arithmetic operationson registers, branching instructions and loops are available. Special commandsare also available, like the Notify() command, which can be used by the OSPMto send messages to other parts of the operating system. Section 2.5 shows howNotify events are handled under Linux.The ACPI registers are defined by the ASL OperationRegion() command.Memory, PCI configuration and PIO spaces can be mapped as ACPI registers.Different fields of each ACPI register can be given a name using the Field()command (see 2.5).2.5 Use of ACPI in Practice: Linux ExampleIn this section, we study how ACPI is handled by an ACPI-compliant Linuxsystem. This will be useful as most of the examples we give in the next sectionswill be related to Linux systems.ACPI software in Linux is mostly composed of two different parts:– a kernel service which includes an AML interpreter, ACPI drivers for differentdevices (e.g, fan, CPU, batteries) and part of the OSPM. The modular

ACPI: Design Principles and Concerns 19structure of the Linux kernel allows for a selection of devices that are handledby the kernel using ACPI;– a userland service called acpid (ACPI daemon) that is functionally part ofthe OSPM. acpid is configured through a set of configuration files storedin the /etc/acpi directory, each of which specifying the expected systembehavior when an ACPI “Notify” event for a particular device is received.For instance, the /etc/acpi/power file can be used to configure acpid sothat whenever a power button event is received, the shutdown command isexecuted.The Linux kernel also allows the user to define an alternate DSDT file, differentfrom the one specified by the BIOS. This function is quite convenient as itallows the DSDT to be modified, e.g. for debug purposes.The easiest way to force the kernel to use a custom DSDT is through the useof an “initial RAM disk” (initrd). An initrd is usually used by the bootloader ofa Linux system to load kernel modules that are required to access the root filesystem (SATA or IDE drivers, file system-related modules for instance) whenthey are not shipped with the kernel. But the initrd can also be used to providea custom DSDT to the kernel. For the kernel to use a custom DSDT, all we haveto do is create an initrd file with the following command 1 and provide the initrdto the bootloader.mkinitrd --dsdt=dsdt.aml initrd.img 2.6.17The DSDT used by the system is accessible via the /proc/acpi pseudo-file.It is then possible to disassemble the DSDT of the system and then reassemblethe output ASL file without modifications. On some computers, this simpleoperation fails. On the example below, we disassemble the DSDT file (called“dsdt”) of an actual desktop system through the iasl -d dsdt command. TheASL file corresponding to the DSDT is written in the dsdt.dsl file. Next, wecompile the dsdt.dsl file into AML. Ideally, the output file should be identicalto “dsdt” . However, the compiler shows unexpected compilation errors. This issymptomatic of ACPI tables that do not comply to the standard, despite beingwritteninAML.#iasl -d dsdtLoading Acpi table from file dsdt[...]Disassembly completed, written to "dsdt.dsl"#iasl dsdt.dsldsdt.dsl 286: Method (\_WAK, 1, NotSerialized)Warning 1079 - ^ Reserved method must return a value (_WAK)dsdt.dsl 319: Store (Local0, Local0)Error 4049 - ^ Method local variable is not initialized (Local0)dsdt.dsl 324: Store (Local0, Local0)Error 4049 - ^ Method local variable is not initialized (Local0)1 The code that is presented below has been tested for a Linux 2.6.17 kernel.

20 L. Duflot, O. Levillain, and B. MorinASL Input: dsdt.dsl - 4350 lines, 144392 bytes, 1678 keywordsCompilation complete. 2 Errors, 1 Warnings, 0 Remarks, 382 OptimizationsIt is also possible to copy the system DSDT and change the definition of ACPIregisters. If we map kernel structures such as system calls to ACPI registers, ordefine new ACPI registers, compiling the modified DSDT does not cause anywarning. It is then possible to update the initrd of the system in order for themodified DSDT to be used by the system after the next reboot. The followingcode describes how to define such new ACPI registers. The first OperationRegion()command defines an ACPI register called LIN corresponding to a bytewidePCI configuration register. The second OperationRegion command definesa system memory 12-byte wide ACPI register called SAC composed of three4-byte registers defined through the following Field() command called SAC1,SAC2 and SAC3./* PCI configuration register : *//* Bus 0 Dev 0 Fun 0 Offset 0x62 is mapped to LIN */Name(_ADR, 0x00000000)OperationRegion(LIN, PCI_Config, 0x62, 0x01)Field(LIN, ByteAcc, Nolock, Preserve) { INF,8 }/* System Memory at address 0x00175c96 *//* (Setuid() syscall) is mapped to SAC */OperationRegion (SAC, SystemMemory, 0x00175c96, 0x000c)Field (SAC, AnyAcc, NoLock, Preserve){ SAC1,32, SAC2,32, SAC3,32 }3 Security Issues with ACPIIn this section we study different security issues related to ACPI. The ACPImodel seems to be the most important security flaw. Indeed, the OSPM musttrust the content of the ACPI tables supplied by the BIOS in order to run ACPIcode. Actually, the OSPM has no particular way to determine whether ACPItables are genuine or not. Also, the OSPM has no means to properly identifywhat the ACPI registers are. As ACPI does not provide any ACPI registeridentification scheme, the OSPM cannot ensure that the methods defined in theDSDT actually manipulate only ACPI registers, so the OSPM can merely trustthose methods.One could argue that OSPMs have the possibility to correctly identify ACPIregisters. If the OSPM knows that a particular network adapter is plugged in forinstance, it should be able to know which specific configurations of the deviceare related to power management and which are not. If the OSPM was ableto differentiate ACPI registers from regular chipset or device registers then theOSPM could enforce a simple access control policy and would refuse to reador modify the content of any non-ACPI register even if instructed to do so byone of the methods of the DSDT. However, as stated in introduction, ACPIhas been precisely introduced to define common interfaces and make sure that

ACPI: Design Principles and Concerns 21platform- specific information (for instance the location of ACPI registers) ispushed in ACPI tables for the operating system to configure the platform withoutan in-depth understanding of the semantics of the chipset or devices registers. Inother words, ACPI would be useless if the OSPM knew enough of the platformdetails to identify the ACPI registers.One could also argue that the OSPM not being able to identify ACPI registersis not a security issue, as computer programs have to trust higher-privilege orto some extent previously booted components. What we wanted to stress outhere is the fact that ACPI could have been designed differently at the hardwareor platform level to allow OSPMs to differentiate ACPI registers from otherregisters. What’s more, the paradigm forcing OSes to trust previously bootedsoftware tends to be challenged by new technologies using hot reboot (this matteris discussed in section 5).We now look at the problem from the chipset point of view. The chipset isable to know the location and the purpose of most ACPI registers, but it doesnot know when the OSPM is running on the CPU, nor can it distinguish ACPIrelatedaccess to the registers from non-ACPI-related accesses. From the chipsetperspective, a userspace code attempting to modify a register is not differentfrom the OSPM, so there is no way for the chipset to enforce that the OSPMbe the only component to access ACPI-related registers and that OSPM cannotaccess non-ACPI-related registers.At this point, one could argue that it is not the job of the hardware to makesecurity-related decisions. Here again our point is that the fact that neither theOSPM nor the chipset can serve as a policy enforcement point seems a majordesign problem. Additionally, it seems fair to note that the chipset is alreadyused as a policy enforcement point to restrict access to security-critical memoryareas such as the SMRAM [3], so using the chipset to make the platform moresecure would not really be that innovative.As a summary, neither the chipset nor the OSPM can decide whether anaction is legitimate or not: the OSPM is not able to determine if the registers itis accessing are indeed ACPI because it blindly trusts the content of the DSDT,and the chipset cannot know what software component is trying to access aparticular resource because all software components running in protected modelook the same to the chipset.The lack of policy enforcement point makes it impossible to detect misbehaviorsof the ACPI sub-system:– it is impossible to detect a bug in the DSDT that would incorrectly define anACPI register (remember that disassembling the DSDT and reassembling iton some computers reveals AML errors);– it is impossible to detect live modifications of the DSDT image the OSPMis using.Other security issues exist even if they can probably be considered of lesserimportance. First, device drivers are allowed to access the content of the DSDTand perform ACPI-related tasks. The fact that the OSPM and the device drivers

22 L. Duflot, O. Levillain, and B. Morincould be independently accessing the same registers could lead to inconsistenciesand to incorrect system behavior. For instance, the OSPM could consider thatsome device is in a particular state when the device driver itself has configuredthe device differently. Also, the fact that the OSPM has to actually look for theRoot System Description Pointer signature to be able to locate the structure isquite debatable from a security point of view. OSPMs probably do not look formultiple RSDP structures, so an OSPM is likely to use the first RSDP matchingthe signature. The fact that the OSPM is indeed able to identify the actualRSDP relies on the assumption that there is no way for an attacker to insert arogue RSDP with a correct signature in memory before the genuine RSDP. Thisassumption actually does not prove easy to guaranty.4 Design of a Rootkit FunctionThe overall principle of an ACPI rootkit has been presented by John Heasman[6]. According to the author, designing an ACPI rootkit triggered by externalhardware events (e.g., lid closing, power adapter plugging or removing)was still an open problem. In this paper, we present a proof-of-concept code thatallows a rogue rootkit-like function to run whenever the power adapter is pulledand replugged twice in a row. We also study the limits of the ACPI model andconclude that ACPI rootkits detection is a complex problem.4.1 ACPI Rootkit MotivationsAn attacker controlling the content of the DSDT could:– add devices in the DSDT, create new ACPI registers corresponding to anymemory zone, or PIO register;– modify existing methods behavior, create additional methods.This attack assumes that the attacker has enough privileges to modify theDSDT used by the OSPM. For instance, the attacker can attempt a live modificationof the DSDT the OSPM is using or, alternatively, interfere with theDSDT load process (for instance by flashing the BIOS or modifying the bootloader) in order for the OSPM to load the tainted DSDT. On most operatingsystems, an attacker will only be allowed to do so if she is granted maximumprivileges (ring 0). Therefore, this attack shall not be useful in a privilege escalationscheme; on the other hand, modifications of the DSDT can be useful tokernel- level rootkits.Kernel-level rootkits are malwares which try hard to ensure both their stealthinessand resilience. Indeed, an attacker needs her rootkit to hide its presencefrom the user and the operating system and also remain in memory, even if partof the rootkit is removed by some antivirus software. It has been shown in [4]that rootkits could hide functions inside of the SMI handler. SMI handler is acomponent running in the CPU System Management Mode [3] and that is virtuallyinaccessible from operating systems. Another possibility for the rootkit is

ACPI: Design Principles and Concerns 23to modify one of the methods of the DSDT to make sure that each time thismethod is launched by the OSPM, functions of the rootkit get executed.4.2 Sample ACPI Rootkit Rogue FunctionAs a proof-of-concept of what is described above, we show how it is possible foran attacker to design an ACPI rogue code for a Toshiba Portégé M400 laptopusing a Linux Mandriva 2008 [15] system. This rogue code is intended to triggera backdoor every time the power adapter plug is pulled and replugged twice ina row; the backdoor grants superuser privileges to subsequent user logins, nomatter what the user id is.In order to do so, the attacker can create a new device TEST and define a newACPI register called INF corresponding to an otherwise unused chipset register 2 .This chipset register is a PCI configuration register (bus 0, device 0, function 0,offset 0x62). It is byte-wide, readable and writable and is not used by any othersoftware component (including BIOS). Such a device can be defined as below 3 :Scope(\_SB.PCI0){Device(TEST){Name(_ADR, 0x00000000)OperationRegion(LIN, PCI_Config, 0x62, 0x01)Field(LIN, ByteAcc, Nolock, Preserve){ INF,8 }Method(_S1D,0, NotSerialized){ Return(One)}Method(_S3D,0, NotSerialized){ Return(One)}[...]}}On Linux-operated laptops, the STA (Status Request) function of the BAT1device is used by the OSPM to check the status of the main battery, so it issupposed to be executed quite frequently (experiments have shown that it isinvoked around once every 10 seconds).The _PSR (Power Source) function of the ADP1 device is called when the poweradapter is unplugged or plugged in. This function is used by the system todetermine what the current power sources are. The attacker can use the newlycreated INF ACPI to keep track of the number of times the _PSR function hasbeen executed in a row without the BAT1._STA function being called. This canbe achieved by means of the following modifications. The BAT1._STA function ismodified to ensure that each time BAT1._STA is executed, the INF ACPI registeris set to 1. This can be done by using the Store() ASL command. Of course,2 The attacker could alternatively have used an unused memory space, as for examplethe BIOS keyboard buffer, located at physical addresses 0x41a to 0x43e.3 The device presented does not only contain the INF register, but also some standardmethods, defined for every ACPI device. Even if these methods may not be necessaryfor the TEST device to be defined in the DSDT, they make it resemble real devices.

24 L. Duflot, O. Levillain, and B. Morinit is possible to modify other functions 4 inthesamewayasBAT1._STA to makesure that the INF ACPI register is set to 1 as often as possible.Device(BAT1){[...]Method (_STA, 1, NotSerialized){Store(0x1 , \_SB.PCI0.TEST.INF)[...]}}The attacker also has to modify different functions and registers of the ADP1device. A new ACPI register is created, which corresponds to the memory locationwhere the setuid() syscall is stored (more precisely to the part of thesetuid() syscall where the effective user id is set).Device (ADP1){ [...]/* Map setuid() syscall. 0x00175c96 is the physical address *//* of the part of setuid() to be modified by the backdoor */OperationRegion (SAC, SystemMemory, 0x00175c96, 0x000c)Field (SAC, AnyAcc, NoLock, Preserve){SAC1, 32,SAC2, 32,SAC3, 32}[...]The ADP1. PSR function is also modified to increment INF.[...] /* In ADP1 device */Method (_PSR, 0, NotSerialized){ /* if INF = 4 then modify setuid() */If (LEqual (\_SB.PCI0.TEST.INF, 0x4)){Store(0x90900000, SAC3)Store(0x0, SAC2)Store(0x014c80c7, SAC1)}/* increment INF */Increment (\_SB.PCI0.TEST.INF)Return (\_SB.MEM.AACS)}[...] /* ADP1 device continues */4 Determining experimentally which functions are called often requires modificationof the DSDT to make sure that each function of the DSDT writes a different value tothe INF register when called, and tracking accesses to the INF registers (modificationof the ACPI driver).

ACPI: Design Principles and Concerns 25If the INF ACPI register reaches the value 4, meaning that ADP1._PSR hasbeen called four times in a row (unplugged and plugged again in twice in a row)without the BAT1._STA function being called in the meantime, the backdoor getsexecuted. The backdoor modifies the setuid() system call (which is called bythe authentication process every time a user logs on the system) in such a waythat any user obtains the superuser identity instead of her own identity (i.e.is granted maximum privileges) if authentication succeeds. This is achieved bymodifying 12 bytes of setuid() code at physical address 0x175c96 (mapped inthe SAC1, SAC2, SAC3 ACPI registers) to make sure that the effective identity ofthe user is set to root. The values to be written depend on the version of thekernel, here the assembly language instruction movl $0, 0x14c(%eax) (where0x14c(%eax) corresponds to the memory location of the effective user id for thisversion of the kernel) are to be added, followed by two nop operations for opcodealignment purposes./* Without backdoor activation */ /* After backdoor activation */Mandriva Linux Release 2008.0 Mandriva Linux Release 2008.0Kernel 2.6 on an i686 / tty1 Kernel 2.6 on an i686 / tty1Login: userLogin: userPassword:Password:$iduid=500(user) [...] euid=500(user)$whoamiuser#iduid=500(user) [...] euid=0(root)#whoamiroot4.3 Limitations and CountermeasuresIn the previous sections, we have shown that creating an ACPI rootkit-like functionis possible. However, there are a couple of important limitations:– an ACPI rootkit is machine-specific. It requires modification of the DSDT,the content of which is strongly related to the machine hardware;– an ACPI rootkit most likely needs to be operating system-specific. The abilityto create a generic and operational ACPI rootkit on a platform independentlyof the operating system type still needs to be verified. The ACPI _OSobject or the ACPI _OSI command can help identify OSes but of course itis possible for the operating system to lie about its version;– after a reboot, the OSPM reloads the DSDT from the one provided by theplatform, unless the rootkit ensures that a modified one is loaded instead.ACPI rootkit functions will thus require knowledge of relatively importantparts of the operating system or of the BIOS;– modifications to ACPI tables that survive reboots are likely to be detectedif TPM-based [18] schemes or analyzers that look for an obviously wrongbehavior (mapping between an ACPI register and a system call for instance)are used. Static or dynamic code analysis tools can indeed be used to detectanomalous behaviors in the methods defined in ACPI tables, look for the

26 L. Duflot, O. Levillain, and B. Morindefinition of ACPI registers that are not legitimate and recover ACPI tablesused by the system. Of course, the efficiency of such a tool would depend onits knowledge of the operating system and the underlying hardware platform.Unfortunately, dynamic analyzers will not be efficient against kernel-levelmalicious codes, which would deactivate them before modifying ACPI tables.Overall, static analyzers seem by far the best countermeasures to detect modificationsof ACPI tables that survive reboots. Static analyzers can also be usedto detect bugs in BIOS-provided ACPI tables. Such tools should be run aftereach BIOS update. Alternatively, one could also propose that the BIOS vendorscryptographically sign the ACPI tables. The signature would be verified at boottime by the BIOS itself to make sure that ACPI tables have not been modified.Such a scheme would probably not be really efficient as an attacker that wouldmanage to modify ACPI tables would also probably have enough privileges todeactivate the signature verification function unless this function is immutable.Signature schemes will also not provide any protection against bugs in BIOSprovidedACPI tables. Detecting live modifications of the DSDT will be almostimpossible as long as the content of the DSDT will be executed by the OSPMwith the highest privilege level as it is the case for most classical operating systems.Possible means to protect trusted platforms against malicious functionshidden inside of the DSDT are described in the next section.5 ImpactonaTrustedPlatformThe principle of a trusted platform is to identify a set of hardware and softwarecomponents called “trusted computing base” (TCB). The model is that trustin the trusted computing base is sufficient to gain trust in the whole platform.On the contrary, if the trusted computing base was not working according toits specification, there would be no way to trust the platform. The trusted computingbase include at minimum the Trusted Platform Module (TPM) [18], theCPU and the chipset of the platform and the software component of highestprivilege (in most cases a small virtual machine monitor running different guestoperating systems with reduced privileges in parallel). Different initiatives aimat limiting the size of the trusted computing base [7]. For the time being, eventhe BIOS itself can be put outside of the trusted computing base (using TxT [5]and Presidio technologies [2] for instance).The ACPI specification advises the OSPM to be part of the software componentwith the highest privilege level. On a so-called trusted platform, the trustedcomputing base is thus generally the component in charge of power management.In order to do so and to remain generic, the trusted computing base will haveto make use of ACPI tables which means that ACPI tables such as the DSDTwill be included in the trusted computing base. Of course, if TPM and CRTMare used, ACPI tables can be measured at boottime.Butmeasurementscannotensure that tables will not be modified in the future by a rootkit. Measurementswill ensure table integrity but will not give a way to trust their content.

ACPI: Design Principles and Concerns 27But how can the trusted computing base determine that there is no bug orrogue function in the ACPI table provided by the platform that will modify thebehavior of the platform? ACPI static analysis tools can be used but they willnot help against live modification of the ACPI tables. Dynamic tools may alsobe used inside of the trusted computing base but could also be deactivated by arootkit beforehand.The best solution so far for a trusted platform would be to move to a newparadigm where the component in charge of power management is not the trustedcomputing base but a non privileged operating system running on top of thetrusted computing base. This way, the OSPM running methods described inACPI tables will not have enough privileges to modify security critical structuressuch as the ones inside of the trusted computing base. Any such attempt willgive the hand back to the trusted computing base that can for instance shutdown the power management domain and report the security breach.6 ConclusionIn this paper, we showed how it is possible in practice for an attacker to concealfunctions in the ACPI DSDT table. We have provided a proof-of-conceptimplementation of such a function that allows an attacker to get to maximumprivileges on a laptop when she pulls the power adapter twice in a row. Moreimportantly, we have shown that the flaw was in the ACPI model that by designlacks a correct security policy enforcement point. Neither the chipset, nor theCPU will be able to detect any DSDT-based attack scheme. Possible countermeasuresinclude static and dynamic analysis of the ACPI tables that wouldhelp detecting modifications of the DSDT by a rootkit.The impact is even more important on trusted computing base that have tomake use of ACPI tables. Correctly tackling the problem would require trustedplatforms to move to a paradigm where the component in charge of power managementwould not be part of the trusted computing base but in a separateenvironment with reduced privileges. This way, any attempt to modify securitycritical structures by the component in charge of power management would givethe hand back to the trusted computing base.References1. ACPI Component Architecture. Unix format test suite (2008),http://www.acpica.org/downloads2. Devices, A.M.: Amd64 virtualization: Secure virtual machine architecture referencemanual (2005)3. Duflot, L., Etiemble, D., Grumelard, O.: Security Issues Related to Pentium SystemManagement Mode. In: CanSecWest Security Conference Core 2006 (2006)4. Embleton, S., Sparks, S.: The System Management Mode (SMM) Rootkit. In: BlackHat Briefings (2008)5. Grawrock, D.: The intel safer computing initiative (2007)

28 L. Duflot, O. Levillain, and B. Morin6. Heasman, J.: Implementing and detecting an acpi bios rootkit. In: Blackhat federal2006 (2006),www.blackhat.com/presentations/bh-federal-06/BH-Fed-06-Heasman.pdf7. Heiser, G., Elphinstone, K., Kuz, I., Klein, G., Petters, S.: Towards trustworthycomputing systems: taking microkernel to the next level. In: ACM operating systemsreview (2007)8. Hewlett-Packard: Intel, Microsoft, Phoenix, and Toshiba. The acpi specification:revision 3.0b (2008), http://www.acpi.info/spec.htm9. Intel Corp. Intel 82845 Memory Controller Hub (MCH) Datasheet (2002)10. Intel Corp. Intel 64 and IA 32 Architectures Software Developer’s Manual Volume1: Basic architecture (2007)11. Intel Corp. Intel 64 and ia 32 architectures software developer’s manual volume 2a:instruction set reference, a-m (2007),http://www.intel.com/design/processor/manuals/253666.pdf12. Intel Corp. Intel 64 and IA 32 Architectures Software Developer’s Manual Volume2B: Instruction Set Reference, N-Z (2007)13. Intel Corp. Intel 64 and IA 32 Architectures Software Developer’s Manual Volume3A: System Programming Guide Part 1 (2007)14. Intel Corp. Intel I/O Controller Hub 9 (ICH9) Family Datasheet (2008)15. Mandriva. Mandriva linux one (2008),http://www.mandriva.com/en/product/mandriva-linux-one16. Microsoft and Intel. Advanced power management v1.2 specification (1996),www.microsoft.com/whdc/archive/amp_12.mspx17. PCI-SIG. Pci local bus specification, revision 2.1. (1995)18. Trusted Computing Group. Tpm specification version 1.2: Design principles (2008),https://www.trustedcomputinggroup.org/specs/TPM/MainP1DPrev103.zip

Implementation Aspects of Mobile andEmbedded Trusted ComputingKurt Dietrich and Johannes WinterInstitute for Applied Information Processing and CommunicationsInffeldgasse 16a, 8010 Graz, Austria{Kurt.Dietrich,Johannes.Winter}@iaik.tugraz.atAbstract. Nowadays, trusted platform modules (TPMs) are usually deployedtogether with desktop PCs and notebooks. However, these platformsare not the only ones that can host TPMs. Mobile and embeddedplatforms like cell phones can also host TPMs but may have differentrequirements and different use-case scenarios. In contrast to commonTPMs, TPMs for mobile platforms do not need to be implemented asmicro controllers, leading to different security assumptions. In order tofind these differences, we have designed and implemented two approachesfor mobile TPMs that are analyzed in detail in the context of this paper.Keywords: Mobile Trusted Computing, MTMs, ARM TrustZone, SecureElement, JavaCard.1 IntroductionToday, trusted platform modules (TPMs) are available for nearly every PC platform,ranging from desktop machines to notebooks. These TPMs provide thebasic building blocks for different security services like storing integrity measurementsof the installed and loaded software during boot (aka authenticatedboot in the language of the TCG), authenticated reporting of these stored valuesto remote verifiers (aka remote attestation) or binding certain data like keys tocertain platform configurations (aka sealing, binding). All of these services providethe basic building blocks for Trusted Computing (TC) enabled platforms.Common desktop TPMs are produced in high numbers which allows TPMmanufactureres to keep the prices low. However, these common TPMs are deprecatedfor mobile and embedded applications From a certain point of view, itseems simple to put a micro controller based TPM like the ones used on desktopmachines on a mobile platform. However, each new chip on a phone’s motherboard increases the cost of this device, not to mention the additional powerconsumption of the extra chip. Consequently, it is reasonable to search for alternatives- alternatives, for example that are primarily based on features andmechanisms that embedded devices already carry as part of their base configuration.Moreover, to keep the costs for mobile TPMs at a low price, the TPMsmight also be implemented only in software, raising questions about the securityL. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 29–44, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

30 K. Dietrich and J. Winterassumptions for these mobile-trusted-modules (MTM)s and the platforms theyare used with.The Trusted Computing Group (TCG) has published a specification that defineshow mobile TPMs could be designed and which features they could provide[6]. Intentionally, this specification is written in a rather relaxed style which allowsmanufacturer to implement their mobile TPMs in different ways. This specificationalso forms the basis for the design of our prototypes and our ongoinginvestigations.In this paper, we discuss our two designs for providing TC building blockson embedded devices. Both building blocks rely on security mechanisms alreadyhosted by the embedded devices. The first approach focuses on a software emulatedmobile TPM that uses processor extensions to achieve protection fromaccess by arbitrary applications.One interesting fact that should be mentioned at this point is that in the senseof the TCG, MTMs might also be implemented as software security modules.The TCG sees the mobile TPM more like a service than a fixed micro chip.Moreover, in order to achieve more flexible and cheap implementations, MTMsare not constrained to be implemented as micro controller, but might also beimplemented in software. Consequently, the question arises which level of securitya pure software implementation can provide. Is it possible to achieve the samelevel as with microcontroller based TPMs?Or which level is necessary for certain use-cases? Without having clear definitionsabout conformance and compliance of mobile TPMs,these questions are hardto answer. Details about our TrustZone based TPM can be found in Section 4.1.The second approach (see Section 4.2), makes use of onboard smart cards.Many new mobile phones are equipped with an additional smart card (besidesthe SIM card) which can hold secret data like keys or certificates. These smartcards, or secure elements (SE) in the sense of the TCG, can be addressed bythe mobile phone as well as from external devices via nearfield communicationwhich offers new perspectives of secure device communication.In both of our approaches, we try to be as close to the TCG’s publishedspecification as possible. As a result of our investigations of these two designs,we give a discussion about the pros and cons of both approaches and provide acomparison of them.This article is organized into 6 sections. In section 3 we give an overviewand explain the differences of the two kinds of mobile TPMs i.e. mobile-remoteowner-trusted-modules(MRTMs) and mobile-local-owner-trusted-modules (MLTM). In section 4, wediscuss our two approaches in detail. A comparison of the approaches is given inSection 5 and finally, Section 6 briefly concludes the contribution.2 Related WorkDifferent approaches how to implement MTMs are pursued by various researchgroups. The most important ones are introduced in the following paragraphs.

Implementation Aspects of Mobile and Embedded Trusted Computing 31In [20], an idea to extend a SELinux based kernel in order to provide a genericdomain isolation at the kernel level is proposed by Xinwen Zhang, Onur Aciicmezand Jean-Pierre Seifert. That way, the research group provides a strong andconvenient mechanism to satisfy the security requirements of trusted mobilephones on isolation of engines and integrity assurance.One of the leading mobile phone manufacturers - NOKIA - also does researchon implementation aspects of MTMs. Jan-Erik Ekberg and Markku Kylänpääpublished a paper [10] that provides an introduction into the concept of MTMsfrom the device manufacturer’s point of view. Furthermore, their work presentsan implementation of an MTM that is based on the well-known TPM emulatorfrom Mario Strasser [16].In alternative approaches, hardware provided by mobile devices itself is usedto provide MTM functionality. Such hardware is the SIM card every mobile isequipped with. The work discussed in [3] uses a JavaCard applet loaded on a SIMcard or on-board smart card. The Applet emulates MTM features and makesuse of the hardware support of smart cards. Furthermore, this approach benefitsfrom the smart cards design as they provide shielded locations and protectedcapabilities per se. This MTM supports MRTM as well as MLTM functionality.And finally, in [18] a design for a software emulated mobile-trusted-module,based on the ARM TrustZone processor extension is discussed. This approach isone of the starting points used for this article.3 Mobile Trusted ModulesOne important building block of every trusted platform is the trusted platformmodule (TPM). Among other components like the CPU or the BIOS,the TPM has to be trusted a priori in order to create a chain of trust [7].On mobile and embedded platforms, TPMs are called mobile-trusted-modules(MTMs). Although MTMs have similar features to TPMs, some differences betweenTPMs and Trusted Computing used on desktop machines and MTMs andMobile Trusted Computing exist. In addition to the services discussed in theintroduction section, mobile trusted computing defines another service calledsecure boot. In contrast to an authenticated boot, a secure boot aborts executionof the software - or more restrictive: the boot of the device - if the integritycheck on the software that is currently being loaded fails. This fact implies thata remote party can assume that a certain software configuration is running onthat device. Which software is running on the device is of special interest formobile equipment vendors and network providers, as we will see in the followingparagraphs.In contrast to the TPM specification where we have one dedicated specificationof the TPM and its features, the Mobile-Trusted-Module specification [6]defines two types of MTMs: the Mobile Remote-owner-Trusted-Module (MRTM)and the Mobile-Local-owner-Trusted-Module (MLTM), addressing different owners’needs. The difference between these two types of MTMs is that the MRTMmust support mobile-specific commands as well as a subset of the TPM v1.2

32 K. Dietrich and J. Wintercommands. In contrast, the MLTM is only required to support a subset ofthe TPM 1.2 commands [8]. Usually, phone manufacturers and network serviceproviders are the owner of MRTMs.On the one hand, manufacturers and providers want to get secure remote accessto the mobile phone by using features of the MRTM. On the other hand,the phone’s user or owner, who has physical access to the device and its applications,uses the MLTM . The different parties, called stakeholders, have differentsecurity requirements on MTMs. Depending on the stakeholder, the MTMs areapplied in areas such as platform integrity, device authentication, mobile ticketing,SIMLock/device personalization, secure software download, secure accessto the UICC and payment services as well as user data protection and privacy.A mobile platform may host more than one MTM, depending on different stakeholdersand their requirements.Precise definitions of how MTMs have to be implemented are not defined bythe TCG. Therefore, we propose two solutions with different security requirements.4 Trusted Building BlocksIn the TCG mobile trusted computing architecture [5], MTMs are the fundamentalbuilding blocks for bringing trust into the platform. Any TCG-style trustprovisioning relies on a complete chain of trust, which ultimately roots in a mobiletrusted module. As part of our research in mobile trusted computing, wehave investigated a variety of different approaches to realize such mobile trustedmodules, ranging from pure software solutions in the style of [10] to dedicatedhardware solutions in the style of PC TPMs. In this paper we want to brieflydescribe two of the most promising approaches we are currently working on.4.1 ARM TrustZoneIn [1] and [2] ARM introduced a set of hardware-based security extensions toARM processor cores and AMBA on-chip components.The key foundation of ARM TrustZone is the introduction of a “secure world”and a “non-secure world” operating mode into TrustZone enabled processorcores. This secure world and non-secure world mode split is an orthogonal conceptto the privileged/unprivileged mode split already found on pre-TrustZoneARM cores. On an ARM TrustZone core, secure world and non-secure worldversions of all privileged and unprivileged processor modes and control registercoexist. Security critical processor core status bits and control registers aretypically restricted to secure-world-only access. For the purpose of interfacingbetween secure and non-secure world a special Secure Monitor Mode togetherwith a Secure Monitor Call instruction exists. Interrupts can be handled in asecure deterministic way on TrustZone cores. Apart from the extensions to theprocessor core itself, the SoC busses in TrustZone enabled systems carry extrasignals to indicate the originating world for any bus cycles. Whenever a bus

Implementation Aspects of Mobile and Embedded Trusted Computing 33Fig. 1. Software architecture for an ARM TrustZone based trusted mobile platformcycle is started by the core, the secure/non-secure world state is recorded andencoded into these extra signals. SoC peripherals can interpret the TrustZoneextra signals to implement a low-level access control based on the secure/nonsecureworld distinction.In [18], we outlined how ARM TrustZone can be used as an enabling technologyto implement trusted computing building blocks on embedded platforms.The intrinsic split of the platform into a secure and non-secure partition can beefficiently leveraged to provide the isolation properties required for the protectedcapabilities and shielded locations of a mobile trusted module. As shown in [18],it is possible to accomplish that goal by solely relying on well known open sourcesoftware projects, like the Linux kernel, as fundamental building blocks.Figure 1 gives an overview of a simplified version of the envisioned softwarearchitecture for a mobile trusted platform. The prototype design utilizes theTrustZone secure/non-secure world boundary to create two separate domains,each running its own modified version of the Linux kernel. On the secure worldside, a specialized stripped down Linux kernel is used to provide the necessaryruntime environment for software based mobile trusted modules and for thecomponents required to handle the non-secure world side. The secure worldenvironment can be stripped down to the bare minimum of software components.The MTMs, which execute as software processes within this tightly controlledsecure world environment, can rely on the process isolation and access controlfeatures of the secure world kernel to provide the required isolation propertieswith respect to other secure world components.

34 K. Dietrich and J. WinterThe hardware supported boundary to the non-secure world environment isused to provide a sufficient protective shielding against any potentially maliciouspiece of code running on the non-secure side. There is no direct way for nonsecureworld code to access secure world data or code memory without explicitpermissions. This is guaranteed by the TrustZone hardware extensions even forplatform features like DMA, which normally cause a lot of issues on platformswithout TrustZone.Trusted Engines and the ARM TrustZone approach. A logical extension to ourprototype software design, which is not shown in figure 1, is to include a restrictedexecution environment for secure bytecode or script computation withinthe secure world partition of the system. The TCG reference architecture formobile trusted platforms mentions the existence of “trusted engines”, withoutbeing precise on the exact nature and implementation details of these buildingblocks. These trusted engines are capable of performing trustworthy computationson behalf of a remote stakeholder on the local mobile platform. In the TCGarchitecture, trust provisioning for these engines is done on the basis of mobileremote owner trusted modules (MRTMs).The trusted engine concept can be seen as partitioning of the platform intodifferent trust domains for the stakeholders of the platform. Since various stakeholdersof a mobile platform can not be expected to ultimately trust each other,mechanisms are required to support a sufficient level of isolation and separationamongst them. Our ARM TrustZone based approach intrinsically provides twolevels of separation through the TrustZone secure/non-secure world boundary.These two levels of isolation can be expected to be insufficient if a mobile trustedplatform has more than two different stakeholders. Even in the case of only twostakeholders, for example a “device manufacturer” and a “device user”, it isarguable whether two trust domains are sufficient.By relying on existing software isolation technologies within the two trustdomains intrinsic to ARM TrustZone, it is possible to split them into an arbitrarynumber of smaller trust domains.Secure user-space process based approach. One approach to implementing trustedengines can be the combination of secure boot concepts with strong software isolation.In this scenario, trusted engines would be implemented as secure-worlduser space processes, with embedded certificates. In order to guarantee thatonly trusted code is executed within secure world, the secure world operatingsystem has to enforce mandatory validation of these certificates before allowingany secure user-space processes to run. Depending on the availability of cryptographicand trusted computing primitives within the secure world operatingsystem, these certificates can range from simple asymmetric signatures over theexecutable images to RIM certificates as proposed in the TCG mobile referencearchitecture.An obvious and very simple mechanism for splitting secure user-space intosmaller trust domains, is to leverage the access control mechanisms offered bystandard Linux users and groups. However, depending on the complexity and

Implementation Aspects of Mobile and Embedded Trusted Computing 35nature of the task being performed by a trusted engine it can be desirable tohave a more fine grained approach to access control. As an example, a trustedengine might be comprised of a set of collaborating user-space processes, whichrun at different privilege levels.To support fine grained access control together with strong software isolation,frameworks like SELinux can be used. The authors of [20] propose a SELinuxbased system, to implement different trust domains with mandatory access controlon basis of a normal Linux platform. Their approach can be mapped to thesecure and non-secure world environments of our TrustZone prototype design,in order to provide fine-grained trust domains and software isolation boundarieswithin the two worlds.Comparison to software MTM solutions on general purpose processors. TheTrustZone based approach to a mobile trusted module implementation discussedin the preceding section is a hybrid solution somewhere in the middle betweena pure software MTM implementation and dedicated MTM hardware. A puresoftware MTM implementation running on a general purpose processor 1 has tosolely rely on the process isolation features provided by the operating systemkernel or hypervisor. In such an implementation we can expect all MTMs torun under the same kernel or hypervisor as any potentially malicious user applications.In current hypervisors like Xen [19] or microkernels like L4 [11], compartmentisolation is achieved by using standard virtual memory managementmechanisms available on the general purpose processor they run on. Usually,only the small hypervisor or microkernel runs in a privileged processor mode,while the compartments run in unprivileged processor modes.In the proposed ARM TrustZone based design, the situation is slightly differentdue to the dual nature of the processor core. Since TrustZone effectively turnsa single physical processor core into two separate virtual processors, we havethe possibility to strongly separate the MTMs from any potentially untrusteduser applications. The prototype design explicitly reserves the secure world environmentfor MTMs and tightly controlled trusted processes. Within the secureworld environment, the same techniques as known from general purpose processorswithout TrustZone are applied to provide process isolation among theMTM processes and other trusted processes. When considering the secure worldenvironment alone, we can give precisely the same process isolation guaranteesfor all secure world processes as we could on a general purpose processor onlyexecuting trusted processes.Similarly, we can use the techniques known from general purpose processorsand apply them to the non-secure world environment of the TrustZone baseddesign. If we consider the non-secure world alone, we can achieve the same guaranteesas we could on a general purpose system without TrustZone, where isolationamong trusted and untrusted processes running on the general purposeprocessor core is provided by an OS kernel, hypervisor or microkernel.1 In this context we understand “general purpose processor” as a processor withoutdedicated security extensions or hardware virtualisation extensions.

36 K. Dietrich and J. WinterThe actual strengths of the TrustZone based design is the ability to createan isolated memory area. TrustZone memory isolation features guarantee thatno non-secure world process, regardless of whether it is running in privilegedor unprivileged mode, can ever access secure world memory. If there is need toperform data exchange between secure and non-secure world, only non-securememory can be used for that purpose. Furthermore control transfer betweensecure and non-secure world is only possible through a strictly limited interfaceat the full discretion of the secure-world environment.From a global point of view, the TrustZone design implements two independent,strongly isolated worlds with a well defined strictly controlled interfacebetween them. Global isolation between these two worlds is provided by the intrinsicprotection features of the TrustZone processor extensions. Within eachof these worlds, the design achieves strong local process isolation by resorting tomethods known from general purpose processors without TrustZone.The possible combinations of these mechanisms allow for great flexibility withrespect to the different trust domains on the platform. When secure-world isexclusively reserved for MTMs, with strong local isolation mechanisms in place,this design achieves protected capabilities and shielded locations, which couldget close to the ones found in dedicated hardware MTM modules.At the time of this writing it is a major part of our ongoing research toinvestigate the limitations of the TrustZone based design. We are currently tryingto research definitive statements about which properties of dedicated hardwareMTM modules can not be fulfilled with the TrustZone based design, solely relyingon a software MTM implementation.4.2 Smart CardsIn this section, the use of smart cards, or secure elements, for hosting trustedcomputing building blocks, is discussed. Smart cards are available on every mobilephone - either as an extra smart card or as the subscriber identity module(SIM) card. The SIM card is required for identifying the user (or better, the accountthat is charged for the call) to the communication network. More advanceddevices that support UMTS also support the use of universal-SIM (USIM) cardswhich are equipped with more sophisticated security algorithms. These two typesof smart cards seem to be a natural place where to host MTM functionality.However, developers are hardly allowed to install and execute arbitrary applicationson these cards. Therefore, we moved to alternatives. Other devices areequipped with on-board smart cards (e.g. Nokia 6131 NFC) which we used inour approach to host the MTM [3].At this point, it is important to notice the difference, between a secure elementand a SIM card. The secure element, is fixed on the platform - it cannot beremoved. In contrast to a SIM card that can be removed from the device. Alldata that is stored on the secure element, remains on the platform and cannotbe transferred to another device by just moving the card.

Implementation Aspects of Mobile and Embedded Trusted Computing 37TC enabled ApplicationOperating SystemMTM Abstraction LayerAPDUsSmart CardCard OSMRTM AppletMLTM AppletAPDU forwardingFig. 2. Software architecture for a Smart Card based trusted mobile platformThis fact has interesting consequences. On the one hand, all data that is boundto the removable card cannot be unbound unless the correct card is reinsertedagain. On the other hand, data that is stored inside a secure element can betransfered to the new device. Moreover, if the data is fixed to a certain platformconfiguration, the new device could be forced to have the same configuration inorder to get access to the stored data.JavaCards can host different applications, called applets [13]. Typical applicationsuse such applets to store and manage authorized access e.g. digital pursesor authentication credentials. However, the card can also be used to host appletswith MTM functionality.Figure 2 shows the basic design of our prototype. The smart card (or secureelement) hosts the MTM. The MTM itself is implemented as a Java Card appletthat supports the processing of TCG compatible commands [8]. CommonTPM functionality also includes cryptographic operations, e.g. the current MTMspecification defines RSA operations to be used for asymmetric cryptography.Typically, smart cards are equipped with hardware based cryptographic support.This hardware support enables smart card applications to perform fastcryptographic operations. Fortunately, this support is also available for JavaCard applets which enables them to support all required operations [6].The communication between the host application and the smart card is doneby TCG conformant commands that are split to fit into APDUs as defined in[9]. However, current available cards underlie strong restrictions from availablememory (EEPROM and RAM). The approximate free available space on ourreference prototype is about 76 kByte of nonvolatile memory and 8 kBytes ofRAM. Furthermore, the processing of Java byte code is rather slow, which demandsefficient command handling and parsing.

38 K. Dietrich and J. WinterMany cards can host more than one applet. This fact allows the installationof multiple MTM applets and therefore allows to install a MRTM and an MLTMon the same card, providing the functionalities of both kinds of MTMs.A major advantage when using smart cards for hosting MTM functionality isthat all security properties of a certain smart card can be reused when assessingthe security level of the smart card based TPM. Smart cards are well investigatedin the sense of security evaluations - various security evaluations and protectionprofiles [17] exists.5 Software-Based Versus Hardware-Based MobileTrusted ModulesIn this section, the different advantages and disadvantages of our approaches arediscussed. Both approaches are able to provide MTM features and functionalityas defined by the TCG mobile phone Specification [6] - all required commands,for MRTMs and MLTMs, can be provided.On the one hand, software-based MTMs are a very flexible solution and caneasily be adapted to certain use-case requirements. However, it is hard to determinewhether a pure software or TrustZone enhanced implementation canprovide shielded locations and protected capabilities that form the core requirementsofTPMsasrequiredbytheTCG[7].On the other hand, shielded locations are supported by secure elements perse. The design of current TPMs and MTMs originally stems from the designs ofsmart cards which makes it easy to prove that the requirement for shielded locationsand protected capabilities can be achieved by secure elements. Moreover,protected capabilities can be established by implementing the required commandand authorization handling services as software components on the card.5.1 Architectural ImplicationsA smart card based approach, where the execution of MTM specific operationsis separated between main CPU and a MTM specific processor, has other consequencesas the execution of such operations together with arbitrary applicationson a just one single CPU. The first approach provides an absolute separation ofthe MTM functionality.The second approach relies on specific platform features that can providehardware enforced separation and protection of processes or, in some cases, softwarebased isolation via the operating system or assumptions of the compillersystem. Examples therefore are the L4, micro kernel based architecture and theMicrosoft research operating system Singularity [15].Roots-of-Trust. Important base components of all trusted platforms are theroots-of-trust. Not all of these roots are provided by the MTM, they can beprovided by the BIOS or a piece of software that does verification operations,for example. Therefore, it is reasonable to investigate possible impacts on theseroots by our designs.

Implementation Aspects of Mobile and Embedded Trusted Computing 39It is obvious to see that the smart card approach provides a root-of-trust-forstorage(RTS) and root-of-trust-for-reporting (RTR) per se. All measurementvalues are stored inside a protected area and all required operations for reportingthis values (i.e. quote and identity operations) can be performed in the sameprotected area. Therefore, we can assume that the card provides RTR and RTS.However, can we put the same assumption on the TrustZone approach?When we take a closer look at the design (see Section 4.1) we realize that thesoftware based MTM itself relies on other roots of trust. In order to use this kindof MTM, we require a mechanism that guarantees the integrity and authenticityof the MTM implementation (i.e. Root-of-Trust-for-Enforcement (RTE)) [10].This can be achieved by requiring the device to perform a secure boot process[6] which again includes operations that rely on a Root-of-Trust-for-Verification(RTV) and a Root-of-Trust-for-Measurement (RTM). Consequently, we requireaRTVandaRTMtobepresentbeforetheMTMcanbesecurelystarted.An interesting design could be the combination of both approaches. Instead ofa protected place in the BIOS, the secure element could store long term secretslike the RVAI and could be used to check the integrity of the software MTM.Consequently, the RTV could then be the smart card itself. Nevertheless, a RTMis still required as the measurement process is done outside whatever MTM. Thisimplies that the BIOS must provide means to communicate with the smart card.Integrity Information. The integrity verification process involves RIM certificateswhich contain integrity information of certain software images and informationof expected integrity metrics [6]. The integrity of these certificatesthemselves are checked by using asymmetric cryptography which can be rathertime consuming and slow on mobile devices. In order to address this problem,the MPWG has introduced the concept of binding a RIM certificate to a certainMTM involving just symmetric cryptography with a key that is only known tothe MTM. Using secure elements could improve this process greatly. Instead ofbinding the certificate to the MTM, the certificate could be stored within theMTM. Assuming that only authorized entities can update or store certificateswithin the element, the certificate’s integrity can be seen as assured.The benefit of this approach could be that a verifier would only have to createa hash of the RIM certificate and of the image and send it to the secure element.The secure element could then simply compare the hash certificate with the hashof the stored certificate to verify its integrity.Moreover, the card could compare the corresponding PCR selection valuesstored in the certificate with the current content of the PCRs detecting aberrationsbetween the expected and the actual platform configuration before extendingthe PCR, as defined in [6].Separation. In the JavaCard MTM implementation, the processor executing theMTM code is a physically distinct entity to the processor running applicationcode. The interface between the MTM and the application is constrained by theISO7816 [9] smart-card interface of the secure element. Data exchange betweenthe MTM and the application is limited to an APDU based protocol, there is no

40 K. Dietrich and J. Wintermechanism for directly sharing memory between the MTM and the application.The nature of this smartcard interface automatically forces the MTM and anyother applets running inside the secure element into a passive role, with respectto the application processor.A different situation arises when considering the TrustZone based MTM implementation.In this design, the same physical processor is shared by the MTMcode and the application code. By using the TrustZone features of the physicalprocessor core, two isolated virtual cores for secure and non-secure world arecreated. These two virtual cores can not be considered as a multi-core or multiprocessorsystem with respect to parallelism. Secure and non-secure world aremutually exclusive. Whenever one of the worlds is active, the other world sleeps.Since it is undesirable to suspend all non-secure world application while an MTMrunning in secure world performs some longer operation, a time-sharing and preemptionmechanism is needed. The interface between the virtual core hostingthe MTM and the virtual core hosting the application is built around a systemcallstyle secure monitor call instruction. Data exchange between the virtualcores takes place using a combination of general purpose processor registers andshared memory.Platform Binding. The binding of the MTM to its platform is of essential interestespecially for software based MTMs. While the binding in case of secure elementsis given by design, the binding of software based MTMs is not. As all digitaldata, such as software-based MTMs, could easily be transferred or duplicatedby just copying the software, efficient mechanisms are needed to protect thestate of a software MTM. Apart from MTM cloning, it is necessary to providecountermeasures against MTM state rollback attacks. Furthermore, parts of theMTM state, like private or secret keys, have confidentiality requirements whichneed to be fulfilled.If the target platform of the software MTM provides shielded locations, likechip-internal non-volatile secure memory, all of these issues can be solved relativelyeasily. depending on the available size of that memory. Such non-volatilememory could be an EEPROM or a battery buffered internal static RAM, forexample.The amount of secure memory can be very small, since only a single secretkey K state needs to be placed within this memory. Providing confidentialityand platform binding is easily accomplished by using the secret K state key forencrypting the MTM state blob. By ensuring that no two platforms share thesame K state key, a binding between each platform and the MTM state blobsencrypted on that platform can be established.The described mechanism does not enforce any requirements on the updateabilityof the K state key and thus also works with platforms, which alreadycontain hardwired built-in keys. Unfortunately. this simple approach is not sufficientto prevent state rollback attacks. When the platform provides some intrinsicmechanism to support at least one monotonic counters with large capacity, staterollback issues can be mitigated, by using the value of this counter to track thecurrent revision of the MTM permanent state block.

Implementation Aspects of Mobile and Embedded Trusted Computing 41The need for a monotonic counter to do state revision tracking can be eliminatedif the secure location used to store K state is writeable. In that case, theMTM generates a new random K state key each time when an updated versionof the state blob needs to be stored. As a side effect, this enhanced mechanismallows the storage of monotonic counter values within the encrypted MTM stateblob, residing outside secure memory.5.2 The Role of Virtual MachinesVirtual machines play a key role to both of the designs discussed in this paper.In the secure element based design, the primitives provided by the JavaCardframework and the Java language are used to realize protected capabilities andshielded locations for the MTM applet. Within the context of the Java environmentrunning on the secure element, applet security and isolation is provided bythe design of the JavaCard framework [14].The JavaCard framework is designed to be usable in environments with extremeconstraints on resources like memory and computational power. Todays smartcardsare often based on very simple 8bit microcontrollers like 8051-derivates. Suchcontrollers mostly lack support for features like memory protection, virtual memoryor a distinction between privileged and unprivileged processor modes.Providing process isolation for applications running natively on such a limitedprocessor becomes next to impossible. The JavaCard VM provides a powerful yetsimple solution to remedy this undesirable situation. Instead of allowing appletwriters to use the potentially dangerous native instruction set of the smart cardprocessor, it provides a safe virtual machine instruction set. The virtual machineinstruction set of the JavaCard VM (cf. [14], [12]) is designed to not expose anydirect means for raw pointer or memory operations. In addition the Java virtualmachine specification enforces a number of restrictions on valid programs to allowbytecode verification. In the context of current JavaCards, bytecode verificationis mostly done outside the card. Since special keys are required to load appletsonto the card, it is still possible to guarantee that only verified applets areinstalled. Once the applets are installed, the card can be locked, disallowing anyfurther applet installations.Based on bytecode verification and the virtual machine instruction set designof the JavaCard VM, it is possible to overcome the limitations of the underlyingnative processor with respect to applet isolation. Under the assumption thatthe virtual machine implementation is correct and secure, JavaCard VMs allowpowerful software-isolation without the need for equally powerful underlyinghardware isolation.When discussing the TrustZone based prototype design, we already mentionedthe possibility of implementing trusted engines as user-space processes, runningin the secure world environment of the TrustZone based platform. The ARMprocessors used in the TrustZone based design do not suffer from the samelimitations with respect to memory protection and privileged instructions.Nevertheless, trusted engines implemented as native processes can pose a threatto the entire secure world environment, especially if they have to process input from

42 K. Dietrich and J. Winteruntrusted sources. Incorrectly implemented native trusted engines can give an adversarythe capability of directly executing code in secure world user-space. Whilethis does not necessarily lead to an immediate break of platform security, it can bea highly significant advantage to an adversary.A virtual machine based approach to trusted engines offers mechanisms totightly restrict the low-level operations which can be carried out by softwarerunning inside the trusted engine. For example, potentially unsafe low-level operationslike direct raw pointer manipulation can be ruled out by appropriatebytecode design. Depending on the tradeoff between performance and securityrequirements, virtual machines can implement a significant amount of runtimechecks and bytecode verification steps.Examples for candidate VMs include the Java VM (J2ME, JavaCard) or theLua VM. Especially the latter case of the Lua scripting language appears to bea quite attractive candidate due to the small size and high flexibility of the Luaprogramming language. It should be pointed out that Lua has already been usedin designs with a similar problem setting, as demonstrated in [4].6 Conclusion and Future WorkIn this paper, we discussed two approaches for building mobile trusted modulesbased on existing platform features. The ARM TrustZone approach, coveredin section 4.1, focuses on using special capabilities of the platform and itsmain processor for implementing trusted computing building blocks in software.Apart from the requirement for a sufficient processor core with ARM TrustZonesupport, this approach avoids dependencies on additional dedicated trusted computinghardware. In comparison to the second MTM implementation approachoutlined in this paper, the TrustZone approach can not rely on the same securityproperties inherited from a smart card environment. We give a comparisonof the TrustZone based approach to a pure software MTM solution on generalpurpose processors. Based on the additional memory and process isolationfeatures offered through TrustZone, we conclude that the TrustZone approachallows a finer-grained set of possible trust boundaries and domains. Moreover,we conclude that software MTMs running in a secure world environment andexclusively using secure world memory, can provide protected capabilities andshielded locations which are potentially stronger than their counterparts in thegeneral purpose processor without TrustZone features.Finally, we argue that the TrustZone based approach has the potential formatching the security properties of a dedicated hardware based MTM implementationcloser than a software MTM implementation on a general purposeprocessor can do.The second approach discussed in the paper is based on a dedicated secure elementfound on the platform. As mentioned at the beginning of section 4.2, suchsecure elements are already deployed in a number of mobile phone platforms.Again, this JavaCard oriented approach focuses on reusing the existing secureelement for hosting trusted computing building blocks, without creating the

Implementation Aspects of Mobile and Embedded Trusted Computing 43need for additional special purpose hardware. In this approach, mobile trustedmodule functionality is implemented in a dedicated smart card environment,sharing some similarity with the TPM modules available in many desktop PCsystems. This MTM implementation approach inherits the security propertiesestablished by the JavaCard framework and its smart card nature. We concludethat protected capabilities and shielded locations of the smart card basedMTM implementation approach closely match their counterparts found in existingTPM modules. We can not yet make a definitive and exhaustive statementon the difference between the security properties of the JavaCard MTM and theTrustZone-based software MTM. Properties of ARM TrustZone suggest that thesoftware MTM implementation can achieve characteristics close to the JavaCardMTM’s security properties at least for a subset of these properties. The preciselimits of the security properties of both approaches discussed in this paper arepart of ongoing and future research. It is an open question whether the MTMimplementations discussed in this paper are compliant and/or conformant to theTCG specifications. Since there is no publically available test suite for MTMsat the time of this writing, we can not yet decide if our implementations arecompliant to the TCG specifications.Unfortunately, there is no protection profile for MTMs available either, thusit is not possible to make any assertions about the conformance of our implementationsto the TCG specifications at the time of this writing.References1. Alves, T., Felton, D.: TrustZone: Integrated Hardware and Software Security -Enabling Trusted Computing in Embedded Systems (July 2004),http://www.arm.com/pdfs/TZ_Whitepaper.pdf2. ARM Ltd. TrustZone Technology Overview. Introduction,http://www.arm.com/products/esd/trustzone_home.html3. Dietrich, K.: An integrated architecture for trusted computing for java enabled embeddeddevices. In: STC 2007: Proceedings of the 2007 ACM workshop on Scalabletrusted computing, pp. 2–6. ACM, New York (2007)4. Ekberg, J.-E., Asokan, N., Kostiainen, K., Rantala, A.: Scheduling execution ofcredentials in constrained secure environments. In: STC 2008: Proceedings of the3rd ACM workshop on Scalable trusted computing, pp. 61–70. ACM, New York(2008)5. Trusted Computing Group Mobile Working Group. TCG Mobile ReferenceArchitecture Version 1.0 Revision 1. Specification (June 12, 2007),http://www.trustedcomputinggroup.org/specs/mobilephone/tcg-mobile-reference-architecture-1.0.pdf6. Trusted Computing Group Mobile Working Group. TCG Mobile Trusted ModuleSepecification Version 1 rev. 1.0. Specification (June 12, 2007),https://www.trustedcomputinggroup.org/specs/mobilephone/tcg-mobile-trusted-module-1.0.pdf7. Trusted Computing Group TPM Working Group. TPM Main Part 1 Design Principles.Specification, Specification version 1.2 Level 2 Revision 103 (July 9, 2007),https://www.trustedcomputinggroup.org/specs/TPM/mainP1DPrev103.zip

44 K. Dietrich and J. Winter8. Trusted Computing Group TPM Working Group. TPM Main Part 3 Commands.Specification, Specification version 1.2 Level 2 Revision 103 (July 9, 2007),https://www.trustedcomputinggroup.org/specs/TPM/mainP3Commandsrev103.zip9. International Organisation for Standardisation. ISO/IEC 7816-4, Part 4: Interindustrycommands for interchange (2005)10. Kylänpää, M., Ekberg, J.-E.: Mobile Trusted Module (MTM) - an introduction(November 14 (2007), http://research.nokia.com/files/NRCTR2007015.pdf11. Open Kernel Labs. OKL4 microkernel source code, release 1.5.2.,http://wiki.ok-labs.com/images/2/20/Okl4_release_1.5.2.tar.gz12. Lindholm, T., Yellin, F.: The Java Virtual Machine Specification. Second Edition,http://java.sun.com/docs/books/jvms/second edition/html/VMSpecTOC.doc.html13. Sun Microsystems. Java Card Technology. Overview,http://java.sun.com/products/javacard/14. SUN Microsystems. Java Card Platform Specification 2.2.2. Specification (March2006), http://java.sun.com/products/javacard/specs.html15. Microsoft Research. Singularity (2008)16. Strasser, M.: TPM Emulator. Software package,http://tpm-emulator.berlios.de/17. SUN. Javacard protection profile (May 2006)18. Winter, J.: Trusted computing building blocks for embedded linux-based arm trustzoneplatforms. In: STC 2008: Proceedings of the 3rd ACM workshop on Scalabletrusted computing, pp. 21–30. ACM, New York (2008)19. XEN Hypervisor, http://xen.org/20. Zhang, X., Aciicmez, O., Seifert, J.-P.: A trusted mobile phone reference architecturevia secure kernel. In: STC 2007: Proceedings of the 2007 ACM workshop onScalable trusted computing, pp. 7–14. ACM, New York (2007)

Modeling Trusted Computing Support in aProtection Profile for High Assurance SecurityKernelsHans Löhr 1 , Ahmad-Reza Sadeghi 1 , Christian Stüble 2 , Marion Weber 3 ,and Marcel Winandy 11 Horst Görtz Institute for IT-Security, Ruhr-University Bochum, Germany{hans.loehr,ahmad.sadeghi,marcel.winandy}@trust.rub.de2 Sirrix AG, Bochum, Germanystueble@sirrix.com3 Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn, Germanymarion.weber@bsi.bund.deAbstract. This paper presents a Common Criteria protection profilefor high assurance security kernels (HASK-PP) based on the results andexperiences of several (international) projects on design and implementationof trustworthy platforms. Our HASK-PP was motivated by the factthat currently no protection profile is available that appropriately coverstrusted computing features such as trusted boot, sealing, and trustedchannels (secure channels with inherent attestation).In particular, we show how trusted computing features are modeledin the HASK protection profile without depending on any concrete implementationfor these features. Instead, this is left to the definition ofthe security targets of a an IT product which claims conformance to theHASK-PP. Our HASK protection profile was evaluated and certified atevaluation assurance level five (EAL5) by the German Federal Office forInformation Security (BSI).1 IntroductionIndustrial and governmental IT applications pose a high degree of assurance onthe security of the deployed IT products. Consequently, appropriate evaluationmeans are desired to verify product claims. In this context, Common Criteriastandards [1] are established methodologies to provide assurance that the processof specification, implementation and evaluation of an IT security producthas been conducted in an appropriate, rigorous and standard manner. In particular,protection profiles (PP) define a set of requirements for a specific class ofproducts that must be fulfilled by any product that is certified as compliant tothe profile.For secure operating systems, a small number of protection profiles exist.However, until recently, the existing protection profiles either model only specificaspects such as access control models, or they define the operating systemL. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 45–62, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

46 H. Löhr et al.on a very low level. In particular, these protection profiles do not consider importantsecurity aspects that can be realized by the emerging trusted computingtechnology such as secure booting, trusted channels, or data binding.For example, the Trusted Computing Group (TCG), an industrial initiativeaiming at the realization of trusted computing, has specified security extensionsfor commodity computing platforms. The core TCG specification is theTrusted Platform Module (TPM) [2], currently implemented as cost-effective,tamper-evident hardware security module embedded in computer mainboards.It allows a platform to provide evidence of its integrity, cryptographically binddata to previously taken integrity measurements, and protect cryptographic keysin shielded hardware. Based on these functionalities, a secure operating systemcan realize more advanced protection for applications and more reliable evidenceof its trustworthiness to external entities like remote parties.Using a TPM to realize the mentioned security properties is only one option.Alternative solutions are possible based on other hardware security modules likesecure coprocessors [3, 4] or smartcards. Hence, to enable the certification of securesystems providing these security properties on an abstraction level allowingend-users to compare security products, a new protection profile incorporatingtrusted computing becomes necessary.Contribution. In this paper, we present a Common Criteria protection profilefor high assurance security kernels (HASK-PP) [5], based on experience establishedover several years during the design and development of security kernelsin projects such as EMSCB [6], OpenTC [7], and SINA [8]. Moreover, we discusscertain aspects of this protection profile and explain the background of decisionsmade during the development. The HASK-PP incorporates a number ofnovelties, compared to existing protection profiles:– Secure and authenticated boot abstraction (trusted boot) 1– User data binding (trusted storage)– Secure channels with evidence on integrity of endpoints (trusted channels)– Minimal core security requirements– High flexibility for implementationAlthough one important input to the PP development was trusted computingtechnology, a strong requirement of the PP development was to keep itimplementation-independent. Moreover, a key driver was to minimize the coresecurity requirements, particularly regarding user management and auditing.Only minimal requirements were defined in order to also allow products thatdo not have (multiple) users or do not need extensive auditing (e.g., embeddeddevices). The definition of additional security requirements is intentionally leftto the specification of security targets of concrete products. All together, thisallows a wide range of platforms such as servers, desktop systems, and embeddeddevices, which can be evaluated according to the HASK protection profile.1 We explain the differences between secure and authenticated boot in Section 4.1. Ingeneralweusethetermtrusted boot as an abstraction for both.

Modeling Trusted Computing Support in a Protection Profile for HASK 47The protection profile was evaluated and certified at evaluation assurancelevel five (EAL5) by the German Federal Office for Information Security (BSI).Outline. In Section 2, we introduce goals and design principles of the developmentof this protection profile and discuss related and previous work. Wealso briefly introduce the Common Criteria and relevant terminology. Section 3presents an overview of the high assurance security kernel protection profile(HASK-PP).WeshowinSection4howtrusted computing features are modeledin the protection profile, in particular trusted boot, trusted storage, and trustedchannels. Finally, we conclude the paper in Section 5 with a brief summary andan outlook on future work.2 Toward a Protection Profile for Security Kernels2.1 Goals and Design PrinciplesThe overall goal of the HASK protection profile was to define evaluation criteriafor security kernels that provide functions for the management and separationof compartments operating on top of the security kernel. Examples of producttypes that may implement these functions are– Microkernels,– Virtual machine monitors, and– Logical partitioning products.The protection profile was developed based on the experiences with differentsecurity kernels covering certain aspects to be considered by HASK:– Turaya [9]: A microkernel-based security kernel for desktop and mobile ITproducts based on COTS components. An open-source version of the Turayasecurity kernel has been developed in the EMSCB [6] project partly fundedby the German Ministry of Economics and Technology.– OpenTC [7]: A hypervisor-based security kernel for clients and servers, usingtrusted computing technology. OpenTC is a research project partly fundedby the European Union.– SINA [8]: A high-assurance “Secure Inter-Network Architecture” developedby the German Federal Office for Information Security (BSI).High-level abstraction of trusted computing featuressuchasremoteattestationand binding were among the results of these projects. We derived ourrequirements for a protection profile from these insights. In addition to the securityfunctionality of traditional security kernels (such as access control, audit,etc.), three important functions must exist in a product claiming compliancewith the HASK protection profile: (1) trusted channel, (2) trusted storage, and(3) trusted boot.The first function is the ability to “prove” a “trust status” to a remote trustedIT product and to verify the correctness of a status submitted by a remotetrusted IT product. This status shows that the product is authentic, has not

48 H. Löhr et al.been modified, and is “fresh” (i. e. the status information received has not beenreplayed from a previous status information potentially intercepted by an attacker).Based on this information, trusted channels between trusted IT productscan be established.The second function allows to bind user data to compartments resp. the securitykernel itself (trusted storage). This function can be used to prevent adversariesfrom bypassing security policies by modification of applications or theoperating system. It was deliberately not the goal to prescribe which method isused to implement these functions. However, a product compliant to the protectionprofile requires hardware, software, or firmware in its environment that isable to ensure the integrity of the security kernel and its data during start-up.Hence, the third function provides a trustworthy bootstrap mechanism(trusted boot), which supports the other two functions in providing evidencethat the product has started in the intended manner. Figure 1 shows the abstractview of a security kernel and our goals.Fig. 1. Abstract functionality of a high-assurance security kernel. “Core Security Functionality”includes separation and access control.Another important design principle of the HASK-PP was to keep it as minimalas possible to allow a wide range of different realizations, but prevent ’trivial’realizations that do not provide the intended security property from being ableto claiming compliance. In fact, the tightrope walk between minimalism andexclusion of trivial realizations was one of the most challenging tasks during thedevelopment of this protection profile.2.2 Common Criteria Basics and TerminologyThe Common Criteria (CC) are an international standard that aims at permittingcomparability between the results of independent security evaluations[1]. The CC provide requirements for security functionality of IT products andassurance measures for the security evaluation of these products. The CommonCriteria Recognition Agreement (CCRA) regulates international recognitionof certificates, and about two dozen countries – including the USA, Canada,UK, Germany, France, Japan, and many others – are currently members of theCCRA.

Modeling Trusted Computing Support in a Protection Profile for HASK 49During security assessment, a given product, the target of evaluation (TOE),isevaluated according to a set of assurance requirements with respect to a securitytarget (ST) that defines the security requirements for this TOE. An evaluationassurance level (EAL) is a pre-defined set of assurance requirements. The CCspecify seven levels (from EAL1 to EAL7), where levels with higher numbersinclude all requirements from the preceding levels. All hardware, software, andfirmware that is necessary for the security functionality of the TOE is called TOEsecurity functionality (TSF). The security requirements that have to be fulfilledby the TSF are called security functional requirements (SFRs). TheCCoffersa set of classes of pre-defined SFRs, from which designers of security targetscan choose. SFR classes are grouped according to security functionality like,e.g., data protection, security management, identification and authentication,auditing.A protection profile (PP) specifies implementation-independent security requirementsfor a class of TOEs (whereas an ST is implementation-dependent).An ST for a concrete TOE can claim compliance to a PP; in this case, the complianceto the PP is assessed during security evaluation. Protection profiles areparticularly important to compare different IT products, since they specify aminimum set of security requirements that must be fulfilled. Of course, the STfor each product can provide additional security features.2.3 Related WorkThe concept of security kernels was explored some decades ago [10–14]. The basicidea is to implement security-critical functionality, i.e., mediating the access toresources according to a security policy, (i) separated from other functionality,and (ii) in a ideally small kernel which allows for the verification of its correctness.The validation and formal verification of security kernels was analyzed andconducted by several works as well [15–18].Separation kernels can be seen as a subclass of security kernels. They haveonly limited functionality. Typically, a separation kernel divides the system intoseparated partitions running virtual machines. Several commercial companiesdevelop separation kernels, such as LynuxWorks [19], Green Hills Software [20],and Wind River Systems [21]. There is also prior work in formal specificationand verification of separation kernels [22, 23].Recently, a protection profile for separation kernels (SKPP) [24] has beenintroduced and certified in the US. This protection profile has been designedfor high robustness environments, i.e., it mainly addresses security evaluationsat EAL6 and EAL7. The protection profile itself does not claim conformanceto a specific evaluation assurance level, but specifies assurance requirementsboth from EAL6/EAL7, and explicitly defined requirements. Regarding securityfunctional requirements, on the one hand, the focus of SKPP is restricted tothe security functionality of separation kernels. In contrast to this, HASK-PPcovers a wider range of security functionality, and in particular includes trustedcomputing functionality. On the other hand, SKPP includes the hardware in theTOE and specifies very detailed security requirements. In contrast, the focus

50 H. Löhr et al.of HASK-PP is more restricted in this sense, since it excludes the hardwarefrom the TOE and leaves more flexibility for concrete implementations. For adiscussion of SKPP and its development, see e.g., [25, 26].Levin et al. [27] compare security kernel and separation kernel architectureswith regard to multi-level security. Moreover, they introduce least-privilege separationkernel as a third class of architecture, which supports the security requirementsof the SKPP.In the past, conventional operating systems like various Linux distributions,Unix variants, and versions of Microsoft Windows have been evaluated accordingtothetheControlledAccess Protection Profile (CAPP) [28], the LabeledSecurity Protection Profile (LSPP) [29] and the Role-Based Access Control ProtectionProfile (RBAC-PP) [30]. However, these protection profiles target lowerevaluation levels 2 and only address the limited aspect of access control models.3 Overview of HASK-PPIn this section we first describe the architecture and functionality of the TOE(Section 3.1). Then we present an overview of the main components of the protectionprofile, namely threats and assumptions (Section 3.2) as well as securityobjectives and security functional requirements (Section 3.3). Finally, we discussour decision for the evaluation assurance level (Section 3.4).3.1 Security Kernel Architecture and FunctionsThe HASK protection profile specifies the security functional and assurance requirementsfor a class of security kernels that allow executing multiple separatedcompartments on a single trusted system. Each compartment can behave likea single platform separated from each other with the TOE enforcing this separationand controlling the communication between compartments as well aswith external entities in accordance with a defined policy (an overview is shownin Fig. 2). Note that the notion of compartments in the protection profile is ageneric concept. A compartment is not necessarily a virtual machine, it can beany set of processes within a security domain. Any product claiming compliancewith this PP must provide the necessary security functionality with a highdegree of assurance to its users.To control the communication of external entities with compartments as wellas the communication between compartments, the TSF manages a set of communicationobjects that can be assigned to compartments. Communication objectsare (on hypervisor-based security kernels) an abstraction for virtual networkconnections between virtual machines or external networks, and (on microkernelbasedsecurity kernels) an abstraction for interprocess-communication betweencompartmentalized (groups of) processes. Those communication objects allow the2 While the PPs themselves are certified according to EAL2 and 3, recent evaluationsof operating systems according to these profiles achieved EAL4+. However, they arestill far from reaching EAL5.

Modeling Trusted Computing Support in a Protection Profile for HASK 51TSF to control which external entities and other compartments a compartmentcan communicate with and how this communication is protected. Protection ofcommunication is defined by security attributes assigned to communication objects.Those attributes can define characteristics of the communication link likethe set of external entities one can communicate with using this communicationobject, the kind of protection for the communicated data requested from the TSFwhen using the communication object (integrity protection, confidentiality protection,authentication of the communication peer).In addition to the communication objects, the TOE also manages storagecontainers of persistent or volatile storage. Those may be whole disks, diskpartitions, disk sectors, etc. where the technology to implement those containers(magnetic disks, flash disks, memory disks etc.) is not relevant for the protectionprofile.The security kernel has the following (abstract) set of functions:– Management of compartments (creation, deletion, starting, changing attributes)– Management of objects, which are at least containers and communication objects(creation, deletion, changing attributes, defining and managing accesscontrol policies)– Management of resources, which are at least processor time and memory(assignment to compartments, setting resource limits, controlling resourcelimits)– Generation and verification of information that reliably shows the integrityof the security kernel, a compartment managed by the security kernel, orspecific data. We call such information evidence of integrity.Fig. 2. TOE architecture. Dark gray colored parts implement the TSF.

52 H. Löhr et al.A security kernel that is compliant to the protection profile needs to implementboth mandatory and discretionary access control (MAC/DAC). The DAC policymust at least allow to specify “access” and “no access”, and the MAC policymust at least allow separating two compartments from each other such that noinformation flow between them is possible.The security kernel (based on hardware functionality required by assumptionsin the PP) must be able to protect its integrity, the integrity of compartments,and the integrity of storage containers during runtime. Integrity of the securitykernel is obviously required to guarantee the proper operation of the TSF.Integrity of compartments is required for trusted communication channels (seebelow). Integrity of storage containers is required to prevent unauthorized modificationof data when this container is mounted to a compartment.In a similar way, the system must be able to protect the confidentiality of thesecurity kernel, the confidentiality of compartments, and the confidentiality ofstorage containers.Furthermore, the security kernel must be able to provide trusted channelsbetween compartments or between compartments and external entities. For atrusted channel, the security kernel has to ensure that the communication linkprovides integrity and confidentiality protection of the data transferred over thechannel, and the identification and authentication of the communication partnersmust be ensured.3.2 Threats and AssumptionsThe main threats against the TOE include unauthorized access to objects orunauthorized information flow between subjects. Additionally, we consideredthreats that target to manipulate the TSF or TSF data, including replaying ofan older state, e.g., a backup, or influencing the TSF to generate false evidence ofthe integrity of the TSF or its data. This also includes threats against the TOEenvironment, e.g., manipulation by installing malicious devices drivers accessingcritical hardware functions, or external entities trying to access confidential TSFor user data by starting the TOE outside its intended operational environment.To address the threats, we stated corresponding security objectives for theTOE and its environment. The latter is important because a security kernel insoftware alone cannot guarantee or verify its integrity without the assistance ofsecurity hardware functionality. In order to be implementation-independent,we did not include security functional requirements for the hardware. Instead,we stated assumptions on the operational environment in being able to– support the TOE in producing evidence of the integrity of the TSF code anddata during the boot process (A.INTEGRITY SUPPORT);– allow the TOE to store information such that it cannot be accessed by theTOE where the configuration has been manipulated in an unauthorized way(A.BIND 3 );3 In TCG terminology, the TPM sealing function can provide such a feature. Otherimplementations may be based on, e.g., secure coprocessors [3].

Modeling Trusted Computing Support in a Protection Profile for HASK 53– provide a function the TOE trusts that is able to generate evidence of the integrityof a remote trusted IT product only if it is correct (A.REMOTE TRUST).The assumptions A.INTEGRITY SUPPORT and A.REMOTE TRUST are needed toshow the status of integrity at load-time of the TOE. Combined with the integrityprotection features of the TSF during runtime, one can derive the integritystatus of the running TOE and compartments executed on the TOE.Of course, for secure operation of the TOE, we assume the environment to– provide mechanisms for separation of the TSF and other subjects or functionality(A.SEPARATION SUPPORT);– not contain backdoors (A.HW OK);– not be able to start the TOE in an insecure way without this being detectable(A.NO TAMPER); and– not have subjects allowed to perform administrative functions and misusingtheir privileges (A.NO EVIL).3.3 Security Objectives and Security Functional RequirementsThe security objectives address protection of objects on the one hand (accesscontrol to user data, information flow control between compartments, securedata exchange, management of security attributes, resource limitation to avoiddenial of service), and protection of the TSF itself on the other hand (TSF andTSF data integrity and confidentiality). Moreover, the TOE must be able toaudit defined potentially security-critical events.To address the security objectives of the TOE, we defined security functionalrequirements, which can be assigned to four groups: (i) core security functionality(realizing access control, security management, audit, etc.), (ii) trusted storage,(iii) trusted boot, and (iv) trusted channels. See Figure 3 for an overview (notethat the SFRs in the groups overlap because some SFRs are addressing morethan one objective).The core security functionality can be divided into four subgroups 4 . (1) Accesscontrol and information flow control includes SFRs for data protection, useridentification and authentication, and consistency of TSF data when sharedbetween TSF and another trusted IT product. (2) Resource limitation: As aminimal requirement we include maximum quotas for memory and processortime in order to avoid excessive resource consumption. (3) Audit defines thatthe TOE must be able to audit the following events at minimum: start/stopof audit functions, modifications of security policy enforced by TOE, rejectedattempts to perform management operations, and integrity violations of TSF oruser data. We did not want to dictate a long list of audit events because someproducts may not have such strong audit requirement, but should be covered4 We introduce the subgroups only as orientation to reflect the objectives in thispaper. The reader can find the exact mapping of SFRs to security objectives in theprotection profile.

54 H. Löhr et al.Fig. 3. Overview of the HASK-PP with logical grouping of the security functionalrequirements and assumptions. See Appendix A for the complete list of SFRs withtheir names (such as “Basic Data Authentication” for FDP DAU.1).by the HASK-PP, too. The actual selection of events to be audited is up to thesecurity target of a concrete product (and can have even more audit events ifnecessary).Finally, (4) security management consists of management of security attributesfor subjects and objects, management of TSF data, and management of securityroles. The inclusion of these SFRs in the HASK-PP was originally not the focus(because we wanted to minimize the requirements), but they were a result of dependenciesbetween SFRs. For instance, FDP ACF.1 (security attribute based accesscontrol) requires FMT MSA.3 (static attribute initialization).We discuss the modeling of the objectives trusted storage, trusted boot, andtrusted channel in Section 4.3.4 Security AssuranceThe HASK-PP has been developed against the most recent version 3.1 Revision2 of the Common Criteria to ensure its usefulness in the future. It is fullyconformant to CC part 3 by selecting the EAL5 package of security assurancerequirements.

Modeling Trusted Computing Support in a Protection Profile for HASK 55EAL5waschosenasaminimum level of assurance for different reasons: Thearchitecture of the TOE in HASK-PP addresses systems with exposure to untrustworthyand unauthorized entities and with high value of the data storedand processed by the system. A sufficient level of assurance must be selected toprovide system users with appropriate assurance that the system will be able towithstand such threats. The TOEs claiming conformance to the HASK-PP areexpected to provide high assurance against the threats assumed in the PP. Robustand reliable separation of compartments requires a level of assurance thatincludes the evaluation of possible covert channels between unrelated compartments.In this context, testing and vulnerability analysis of the whole TSF isnecessary. The whole architecture of a security kernel managing compartmentsshould be implemented in a lean, modularized fashion as required by the EAL5assurance level. This means to have well-structured internals, a functional specificationwhich is at least semi-formal, and a development process that followsclear implementation standards and defines unambiguous use of developmenttools.EAL5 was also deemed appropriate because it shall provide a platform forother secure services implemented in compartments managed by the TOE. Sincesuch services may be certified at assurance levels above EAL4, the underlyingplatform must not provide weaker assurance.EAL5 was deemed to be sufficient as a minimum level because levels aboveEAL5 are usually achievable only with extremely high efforts and costs. Thisallows security kernels to be evaluated and certified according to HASK-PPfor commercial application scenarios that do not require the highest levels ofassurance. Of course, the security target for any specific product may specify ahigher evaluation level. However, the PP itself was only certified at EAL5.4 Trusted Computing Functionality in HASK-PP4.1 Modeling Trusted BootTo be able to provide the “trust status” of the product configuration as requiredby the HASK-PP, a trustworthy bootstrap architecture is required to convinceremote parties about this status. One basic concept towards the developmentof a trustworthy bootstrap architecture is the so-called chain of trust which hasbeen introduced by Arbaugh et al. [31]. The core idea is that every componentinvolved in the boot process measures the integrity of the succeeding one before ittransfers control to it. If the bootstrap process is started by a trusted component(a trusted root host), it is guaranteed that modifications of components involvedin the boot process can be detected by the preceding component. Since therelevant product configuration might not be limited to the security kernel itself,we include requirements for loading and starting compartments in the descriptionof the trusted boot process.In this context, it is possible to distinguish two types of trusted boot mechanismsthat mainly differ in the way how the measurement results are used:

56 H. Löhr et al.Definition 1 (Secure Boot). Secure Boot is a security property of a bootstraparchitecture ensuring that only configurations of a certain property can be loaded.If a modification is detected, the bootstrap process is interrupted.The term ’property’ used in this definition only identifies a set of configurations,e.g., a list or a signature key certifying allowed configurations. An example implementationof secure boot, as proposed by Arbaugh et al., is to verify theintegrity of a succeeding component according to a given reference value. If theverification fails, the boot process is halted or an error function is executed [32].Definition 2 (Authenticated Boot). Authenticated Boot is a security propertyof a bootstrap architecture ensuring that remote parties can verify propertiesof the booted configuration.We use the term trusted boot to refer to both secure and authenticated boot. Incontrast to secure boot, authenticated boot is not actively influencing the bootprocess. An example implementation of authenticated boot, e.g., as proposedby the TCG, is to securely store measurement results (i.e., hash values) of thecomponents involved in the boot chain within the Trusted Platform Module(TPM) and attest the values over an authentic channel. 5Although both concepts are very similar, they fulfill slightly different securityrequirements: Secure boot ensures that only valid configurations are loaded.Local users can therefore assume that the platform is in a trustworthy stateif the bootstrap process finished successfully. Remote parties, however, can ingeneral not make any assumptions about the loaded platform configuration.In contrast, authenticated boot allows remote parties to verify the platform’sconfiguration. But because any configuration can be loaded, local users can ingeneral not make any assumptions about the current platform configuration. Tosecurely verify the current platform configuration, further mechanisms such assecure hardware tokens or software mechanism are required.In general, such a trustworthy bootstrap architecture can be realized usingdifferent combinations of technologies and assumptions. Typical examples aresmartcards, the TPM, a tamper-evident device, or the assumption that adversariesdo not have physical access to the platform.Since such a bootstrap architecture cannot be realized without assumptionsregarding the IT-environment (i.e., hardware or environmental assumptions), theHASK-PP models it using the assumptions A.BIND and A.INTEGRITY SUPPORT.To allow a compliant product to implement authenticated boot, the assumptionA.INTEGRITY SUPPORT only requires that a manipulated security kernel is notable to generate false evidence of its own integrity. The assumption A.BINDrequires that there must be a possibility for the TSF to store data and code insuch a way that it can be loaded only if the integrity of the TSF is intact. Thisallows to implement secure boot.5 Note that neither authenticated boot, nor secure boot can protect the confidentialityof information under the assumptions that hold for common PC architectures,i.e., the adversary has access to the harddisk. The reason is that both bootstraparchitectures do not provide protected storage.

Modeling Trusted Computing Support in a Protection Profile for HASK 57In the protection profile, several security requirements are related to trustedboot. Existing security functional requirements (SFRs) from the CC have beenused to require validation of the security kernel and compartments during startup.This includes that only secure values for memory and CPU time assigned toa compartment are accepted, that the TSF runs a suite of self tests when loadinga compartment that requires integrity evidence, and that any modificationsbetween shut down and start-up of the system (e.g., due to manipulations of thehard disk when the system is shut off) can be detected.Most notably, one extended SFR, FDP DAU.3 EXP “controlled data authentication”,has been defined specifically for the HASK-PP. This requirement statesthat the TSF must provide the capability to generate evidence that can be usedas a guarantee of the integrity of objects. Moreover, it allows the security targetof a concrete product to specify conditions under which such evidence is generated,and subjects must be provided with the ability to verify such evidence.This extended SFR allows the security kernel to extend the “chain of trust”(which must be rooted either in hardware or in the operational environment, asexpressed by the assumptions mentioned above) up to individual compartmentsstarted by the security kernel. Furthermore, it is also relevant for other trustedcomputing features, such as trusted storage and trusted channels discussed inthe following sections.HASK-PP requires only that the IT-environment offers a mechanism to checkthe integrity of the security kernel either before (e.g., by a tamper-resistantcover) or during (e.g., with a TPM) loading it. Which alternative is used is leftfor the specific implementation to decide.4.2 Modeling Trusted StorageA security kernel claiming compliance to the HASK-PP must provide trustedstorage, according to the following definition:Definition 3. Trusted storage is storage where confidentiality, integrity, andfreshness (i.e., protection against replay attacks) of stored data is provided, andwhere the integrity of the TOE accessing the data is ensured (in order to preventother software, such as alternative or modified operating systems, from accessingthe data).To support trusted storage, a security kernel needs special support from theoperational environment, which is reflected in the PP as assumption A.BIND.This assumption requires that the security kernel can store information in sucha way that it cannot be accessed by a manipulated TOE (or by software with adifferent configuration). In concrete systems, A.BIND is usually fulfilled by specialhardware features.Moreover, the security kernel has to ensure that confidentiality and integrityof the data are protected both when the system is running, and when it is offline.Furthermore, it must be infeasible for an attacker to modify the system,or to obtain confidential information from the system in order to get access to

58 H. Löhr et al.the protected data. Additionally, the security kernel must provide a capabilityto authenticate storage containers, and to verify the integrity of the entity(e.g., compartment) accessing the data. These requirements are expressed bySFRs from the Common Criteria classes FDP (user data protection) and FPT(protection of the TSF), together with the requirement FDP DAU.3 EXP (cf. Section4.1).Several possibilities exist to implement trusted storage in real systems. Onesuch possibility is based on a TPM, however, other concepts for trusted computing,e.g., based on proprietary security modules that are not compliant to theTCG specifications, might use different approaches to realize trusted storage.Trusted storage with the TCG specifications. In the terminology of theTCG, sealing denotes the encryption of data with a key that can only be usedby a specific TPM under strictly defined conditions: During sealing, the user canspecify values for the evidence of integrity that has to be present inside protectedregisters of the TPM for decrypting (unsealing) the data. During unsealing,the TPM checks the content of these registers and refuses to decrypt if thecurrent evidence deviates from the required values. Sealing provides integrityand confidentiality of the data, as well as integrity of the TOE. To supportfreshness, monotonic counters, another feature of the TPM, can be used.4.3 Modeling Trusted ChannelsThe possibility to establish trusted channels has to be provided by any securitykernel claiming compliance to HASK-PP.Definition 4. A trusted channel is a channel between two entities that providesintegrity, confidentiality, andauthenticity of the transmitted data, and ensuresintegrity and authenticity of the end points.Hence, a trusted channel allows the communication partners to receive integrity(attestation) information from their peers. A trusted channel may either providemutual attestation (i.e., integrity measurements of both end points are transmitted),or only the integrity of one end point is verified. Several solutions fortrusted channels based on the TCG specifications have been proposed in theliterature [33–37].To keep the protection profile general and implementation-independent, weneed to formulate abstract requirements for the trusted channel, without excludingany specific realization.The hardware and environmental assumptions which are required for a trustedchannel are the availability of a mechanism for the TOE to produce evidence ofits own integrity (A.INTEGRITY SUPPORT) and the availability of a mechanism(that must be trusted by the TOE) providing a similar feature for the remoteentity (A.REMOTE TRUST).The mandatory functionality of the security kernel to support trusted channelsare required by SFRs from the CC for integrity and confidentiality of user dataand TSF data during transfer, security functional requirements from the CC for

Modeling Trusted Computing Support in a Protection Profile for HASK 59inter-TSF communication, and the component for controlled data authenticationthat has been introduced specifically for HASK-PP (FDP DAU.3 EXP).The distinctive feature of end point integrity provided by trusted channelsis expressed by requiring assured identification of the end points in the CCcomponent FTP ITC.1 (“Inter-TSF trusted channel”). Here, the term assuredidentification includes integrity verification.5 ConclusionIn this paper, we describe the first Common Criteria protection profile for asecure operating system with support for enhanced security features, as theyare provided by trusted computing technology. The protection profile is generaland abstract, thus covering a wide class of IT products without fixing specificmechanisms and leaving a maximum of flexibility and freedom for concrete implementations.We show how trusted computing features like trusted boot, trusted storage,and trusted channels can be expressed in a generic way by a protection profile,and we point out the relation to existing concepts like the TCG specifications.Moreover, we present and explain the motivation behind the protection profileand important design decisions.Since the protection profile has been certified, it can be used as a guideline forthe design of real systems by security architects. Proof-of-concept implementationsand other results from projects like EMSCB, OpenTC, and SINA provide astarting point for developing a security kernel that can be evaluated and certifiedaccording to the HASK-PP.AcknowledgmentThis work has been partially funded by the European Commission as part ofthe OpenTC project [7]. We would like to thank Helmut Kurth and GeraldKrummeck from atsec information security for their invaluable contribution inwriting the protection profile, and the anonymous reviewers for their thoughtfulcomments on this paper.References1. Common Criteria for Information Technology Security Evaluation,http://www.commoncriteriaportal.org/thecc.html2. Trusted Computing Group: TPM Main Specification Version 1.2 rev. 103 (July2007), https://www.trustedcomputinggroup.org3. Smith, S.W., Weingart, S.: Building a high-performance, programmable securecoprocessor. Computer Networks 31(8), 831–860 (1999)4. Yee, B.S.: Using Secure Coprocessors. PhD thesis, School of Computer Science,Carnegie Mellon University, CMU-CS-94-149 (May 1994)

60 H. Löhr et al.5. Kurth, H., Krummeck, G., Stüble, C., Weber, M., Winandy, M.: HASK-PP: Protectionprofile for a high assurance security kernel (2008),http://www.sirrix.com/media/downloads/54500.pdf6. European Multilaterally Secure Computing Base, http://www.emscb.de7. Open Trusted Computing, http://www.opentc.net8. Sichere Inter-Netzwerk Architektur (SINA),http://www.bsi.bund.de/fachthem/sina/index.htm9. Sadeghi, A.R., Stüble, C., Pohlmann, N.: European multilateral secure computingbase - open trusted computing for you and me. Datenschutz und DatensicherheitDuD 28(9), 548–554 (2004)10. Schroeder, M.D.: Engineering a security kernel for Multics. In: SOSP 1975: Proceedingsof the fifth ACM symposium on Operating systems principles, pp. 25–32.ACM, New York (1975)11. Walter, K.G., Schaen, S.I., Ogden, W.F., Rounds, W.C., Shumway, D.G., Schaeffer,D.D., Biba, K.J., Bradshaw, F.T., Ames, S.R., Gilligan, J.M.: Structuredspecification of a security kernel. In: Proceedings of the international conferenceon Reliable software, pp. 285–293. ACM, New York (1975)12. Chittenden, B., Higgins, P.J.: The security kernel approach to secure operatingsystems. In: ACM-SE 17: Proceedings of the 17th Annual Southeast Regional Conference,pp. 136–137. ACM, New York (1979)13. Ames Jr., S.R., Gasser, M., Schell, R.R.: Security kernel design and implementation:An introduction. Computer 16(7), 14–22 (1983)14. Karger, P.A., Zurko, M.E., Bonin, D.W., Mason, A.H., Kahn, C.E.: A retrospectiveon the VAX VMM security kernel. IEEE Transactions on Software Engineering17(11), 1147–1163 (1991)15. Kemmerer, R.A.: Formal verification of the UCLA security kernel: abstract model,mapping functions, theorem generation, and proofs. PhD thesis (1979)16. Millen, J.K.: Security kernel validation in practice. Commun. ACM 19(5), 243–250(1976)17. Rushby, J.: Design and verification of secure systems. In: SOSP 1981: Proceedingsof the 8th ACM Symposium on Operating Systems Principles, pp. 12–21. ACM,New York (1981)18. Silverman, J.M.: Reflections on the verification of the security of an operatingsystem kernel. In: SOSP 1983: Proceedings of the ninth ACM symposium on Operatingsystems principles, pp. 143–154. ACM, New York (1983)19. DeLong, R.J.: LynxSecure separation kernel – a high-assurance security RTOS.Technical report, LynuxWorks, San Jose, CA (May 2007)20. Green Hills Software Inc.: INTEGRITY PC Technology (November 2008),http://www.ghs.com/products/rtos/integritypc.html21. Wind River Systems Inc.: Wind River High-Assurance Solutions for Aerospace& Defense. Whitepaper (February 2008), http://www.windriver.com/products/product-verviews/PO_MILS_Solution_Feb2008.pdf22. Martin, W.B., White, P.D., Taylor, F.S.: Creating high confidence in a separationkernel. Automated Software Engineering. 9(3), 263–284 (2002)23. Heitmeyer, C.L., Archer, M., Leonard, E.I., McLean, J.: Formal specification andverification of data separation in a separation kernel for an embedded system. In:CCS 2006: Proceedings of the 13th ACM conference on Computer and communicationssecurity, pp. 346–355. ACM, New York (2006)24. Information Assurance Directorate: U.S. government protection profile for separationkernels in environments requiring high robustness (SKPP) (2007),http://www.niap-ccevs.org/cc-scheme/pp/pp.cfm/id/pp_skpp_hr_v1.03

Modeling Trusted Computing Support in a Protection Profile for HASK 6125. Nguyen, T., Levin, T., Irvine, C.: High robustness requirements in a common criteriaprotection profile. In: IEEE International Information Assurance Workshop(2006)26. DeLong, R.J., Nguyen, T., Irvine, C., Levin, T.: Toward a medium-robustnessseparation kernel protection profile. In: ACSAC 2007. IEEE Computer SocietyPress, Los Alamitos (2007)27. Levin, T.E., Irvine, C.E., Weissman, C., Nguyen, T.D.: Analysis of three multilevelsecurity architectures. In: CSAW 2007: Proceedings of the 2007 ACM workshop onComputer security architecture, pp. 37–46. ACM, New York (2007)28. National Security Agency: Controlled access protection profile (CAPP) (1999),http://www.niap-ccevs.org/cc-scheme/pp/id/PP_OS_CA_V1.d29. National Security Agency: Labeled security protection profile (LSPP) (1999),http://www.niap-ccevs.org/cc-scheme/pp/id/PP_OS_LS_V1.b30. Reynolds, J., Chandramouli, R.: Role-based access control protection profile(RBAC-PP), CygnaCom Solutions, Inc. and National Institute of Standards andTesting (1998), http://www.niap-ccevs.org/cc-scheme/pp/id/PP_RBAC_V1.031. Arbaugh, W.A., Farber, D.J., Smith, J.M.: A secure and reliable bootstrap architecture.In: Proceedings of the IEEE Symposium on Research in Security andPrivacy, Oakland, CA, pp. 65–71. IEEE Computer Society Press, Los Alamitos(1997)32. Arbaugh, W.A., Keromytis, A.D., Farber, D.J., Smith, J.M.: Automated recoveryin a secure bootstrap process. In: Proceedings of the Symposium on Network andDistributed Systems Security (NDSS 1998), San Diego, California, pp. 155–167(2008)33. Goldman, K., Perez, R., Sailer, R.: Linking remote attestation to secure tunnel endpoints.In: Proceedings of the 1st ACM Workshop on Scalable Trusted Computing(STC 2006), pp. 21–24. ACM, New York (2006)34. Stumpf, F., Tafreschi, O., Röder,P.,Eckert,C.:Arobust integrity reporting protocolfor remote attestation. In: Proceedings of the Second Workshop on Advancesin Trusted Computing (WATC 2006) (Fall 2006)35. Sadeghi, A.R., Wolf, M., Stüble, C., Asokan, N., Ekberg, J.E.: Enabling fairerdigital rights management with trusted computing. In: Garay, J.A., Lenstra, A.K.,Mambo, M., Peralta, R. (eds.) ISC 2007. LNCS, vol. 4779, pp. 53–70. Springer,Heidelberg (2007)36. Gasmi, Y., Sadeghi, A.-R., Stewin, P., Unger, M., Asokan, N.: Beyond secure channels.In: Proceedings of the 2nd ACM Workshop on Scalable Trusted Computing(STC 2007), pp. 30–40. ACM, New York (2007)37. Armknecht, F., Gasmi, Y., Sadeghi, A.R., Stewin, P., Unger, M., Ramunno, G.,Vernizzi, D.: An efficient implementation of trusted channels based on OpenSSL.In: Proceedings of the 3rd ACM Workshop on Scalable Trusted Computing (STC2008), pp. 41–50. ACM, New York (2008)ASecurity Functional RequirementsThe security functional requirements of the HASK-PP originate all from CommonCriteria V3.1 Release 2, part 2, with the exception of FDP DAU.3 EXP,which is an extended requirement defined in the protection profile. Table 1 summarizesthe security functional requirements of HASK-PP.

62 H. Löhr et al.Table 1. Security functional requirements in HASK-PPSFRFAU GEN.1FAU SEL.1FDP ACC.2FDP ACF.1FDP DAU.1FDP DAU.3 EXPFDP ETC.2FDP IFC.2FDP IFF.1FDP ITC.2FDP RIP.2FDP SDI.1FDP UCT.1FDP UIT.1FIA ATD.1FIA UAU.1FIA UID.1FIA UID.2FMT MOF.1FMT MSA.1FMT MSA.2FMT MSA.3FMT MTD.1(1)FMT MTD.1(2)FMT MTD.2FMT MTD.3FMT REV.1FMT SMF.1FMT SMR.1FPT ITI.1FPT ITT.1FPT ITT.3FPT STM.1FPT TDC.1FPT TST.1FRU RSA.1FTP ITC.1TitleAudit data generationSecurity audit event selectionComplete access controlSecurity attribute based access controlBasic data authenticationControlled data authenticationExport of user data with security attributesComplete information flow controlSimple security attributesImport of user data with security attributesFull residual information protectionStored data integrity monitoringBasic data exchange confidentialityData exchange integrityUser attribute definitionTiming of authenticationTiming of identificationUser identification before any actionManagement of security functions behaviorManagement of security attributesSecure security attributesStatic attribute initializationManagement of TSF dataManagement of TSF data for communication objectsManagement of limits on TSF dataSecure TSF dataRevocationSpecification of management functionsSecurity rolesInter-TSF detection of modificationBasic internal TSF data transferTSF data integrity monitoringReliable time stampsInter-TSF basic TSF data consistencyTSF testingMaximum quotasInter-TSF trusted channel

Remote Attestation of Attribute Updates andInformation Flows in a UCON SystemMohammad Nauman 1 ,MasoomAlam 1 , Xinwen Zhang 2 , and Tamleek Ali 11 Security Engineering Research Group,Institute of Management Sciences, Peshawar, Pakistan{nauman,masoom,tamleek}@imsciences.edu.pk2 Samsung Information Systems America, San José, USAxinwen.z@samsung.comAbstract. UCON is a highly flexible and expressive usage control modelwhich allows an object owner to specify detailed usage control policies tobe evaluated on a remote platform. Assurance of correct enforcement ismandatory for the establishment of trust on the remote platform claimingto implement UCON. Without such an assurance, there is no wayof knowing whether the policies attached to the objects will be enforcedas expected. Remote attestation, an important component of TrustedComputing, is highly suitable for establishing such an assurance. Existingapproaches towards remote attestation work at a very coarse-grainedlevel and mostly only measure binary hashes of the applications on theremote platform. Solutions at this level of abstraction cannot provideassurance to a challenger regarding behavior of a remote platform concerningenforcement of the owner’s policies. In this paper, we provide anew remote attestation technique which allows a challenger to verify twoimportant behaviors of a UCON system enforcing its policies. These twobehaviors are the attribute update behavior and information flow behavior.Measuring, storing and reporting these behaviors in a trusted manneris described in detail and a mechanism for the verification of these behaviorsagainst the original UCON policies is provided. The end resultis a flexible and scalable technique for establishing trust on attributeupdates and information flow behaviors of a remote UCON system.Keywords: Information flow, remote attestation, usage control,security.1 IntroductionUsage control deals with issues concerning usage of protected objects based onthe policies of the object owner. While traditional access control models dealwith authorization issues such as who may access an object, usage control modelsaddress issues concerning use of objects such as duration of each use, the numberof usages and ability to re-distribute etc.UCON [1] is a highly expressive usage control model which adds continuityof access decisions and mutability of attributes at the model level. Its majorL. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 63–80, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

64 M. Nauman et al.strength lies in the ability to specify elaborate usage control policies to be evaluatedon a remote platform. This strength of UCON to operate on a remoteplatform is also a source of concern. Since the owner of the object releases it to aremote platform, she has no way of ensuring that the policies attached to it willbe enforced as specified. Trusted computing [2] proposes an innovative approachfor establishing trust on a remote platform in such a scenario. This approach,called Remote Attestation, allows a challenger to verify that the behavior ofa target platform is trustworthy. Existing approaches towards remote attestationinclude low-level techniques of presenting binary hashes of executables tothe challenger [3,4], middle-level approaches of mapping system configurationsto generic properties by a trusted third party [5] and a high level mechanismof measuring individual components of a policy model for the establishment oftrust [6]. The low- and middle-level techniques allow a challenger to staticallydetermine the identity of the applications running on the client and propertiesof the system in general. They do not enable measurement of dynamic behaviorof a target application on the client. Moreover, it has been widely accepted thatbinary hashes of executables alone are insufficient for reasoning about trustworthinessof a platform [4,7]. Low-level binary hash based techniques are, therefore,not suitable for remote attestation of a UCON system.Consider for example, a UCON policy, which specifies that, “a media file canonly be played once by an individual in the public relations office for two minutesonly and that each usage has to be logged”. Clearly, it is impossible to deduce,from the hash of an executable alone, that this policy will be enforced correctlyby the application.For deducing such intricate details of an application’s behavior, Alam et al.have proposed Model-based Behavioral Attestation [6] i.e. attestation of a policymodel being followed by the target application for a specific purpose. Thistechnique proposes the decomposition of the behavior of a policy model into itsindividual components and measuring these individual behaviors. If the behaviorof each of the components can be attested by the challenger, the whole systemcan be deemed as trustworthy. Model-based Behavioral Attestation has specifiedthree behaviors of a UCON policy model – active subject/object behavior,attribute update behavior and state transition behavior. We note that the procedurefor the measurement of these behaviors is not a part of the Model-basedBehavioral Attestation framework.In this paper, we specify a technique for measurement, storage and reportingof the attribute update behavior and its verification against the challenger’spolicies. Attribute updates are an integral part of the UCON model and heavilyinfluence usage decisions [8]. Successful remote attestation of attribute updatebehavior would provide confidence to the challenger regarding the trustworthinessof a target platform.We also identify another UCON model behavior – information flow behavior– which captures the possible information flows between objects in a UCONsystem. Attesting the trustworthiness of information flow behavior would provideassurance that no illegal information flows occurred on the client end during

Remote Attestation of Attribute Updates and Information Flows 65the usage of the owner’s resources. Such assurance is critical in systems of adistributed nature [9]. Similar to the attribute update behavior, we provide adetailed mechanism for the measurement, storage, reporting and verification ofthe information flow behavior.Contributions: Our contributions in this paper are as follows: 1) We describea mechanism for recording arbitrary data structures in the TPM as opposedto binary hashes of executables only. 2) We detail a procedure for measuringthe behaviors of attribute updates and information flows in a UCON system.3) We provide a means of verifying the behavior tokens returned by the targetapplication on the challenger side against the original UCON policies.Outline: The rest of the paper is organized as follows: In Section 2, we providebackground about the UCON model and describe the formal model usedfor our attestation purposes. Behavioral Attestation is introduced in Section 3.Our UCON system attestation is described at length in Section 4 with attributeupdates and information flows covered in Sections 4.1 and 4.2 respectively. Previouswork related to this paper is mentioned in Section 5. Finally, we concludeour work and present future directions in Section 6.2 UCONUCON [1] is a Usage CONtrol model, which builds heavily on traditional accesscontrol models. It incorporates dynamic usage of protected objects and changesin decisions to allow further access to these objects as a result of usage. This extensionis achieved through the introduction of two novel features: access decisioncontinuity and attribute mutability.In a UCON system, the user initiates a request for an object protected by theUCON system. The access decision depends on the policies and constraints forthe particular subject, object and right combination, identified by (s, o, r). Therequest can either be granted or denied. Even if the request is initially granted,the usage session does not end. The coupling of attribute mutability and accessdecision continuity means that due to the usage of the protected object, theattributes of the subject and/or object may change. As a result of this change,the decision to allow access might also be reversed. The usage session remains atstate accessing as long as the constraints allow the continued use of the object.If the user ends the usage, the usage session moves to state end. If,however,theconstraints lead to a denial of access after some time, the state moves to revokedand the user is no longer allowed access to the object. Figure 1 shows the statesin the UCON usage session [1].Zhang et al. [10] have formally specified the UCON model at a very abstractlevel. However, this formalization is not suitable for the purpose of informationflow analysis and attestation of attribute updates. Instead, we use another formalizationof UCON by Zhang et al. [11] which has been formulated for safetyanalysis of the UCON model. Safety analysis of UCON is essential for our behaviorverification step. For the verification of behaviors collected on the target

66 M. Nauman et al.platform, we create a benchmark on the challenger side, which requires the safetyproblem of UCON to be decidable. However, Zhang et al. [11] have shown thatthe safety problem in general UCON is undecidable. They have defined the safetyproblem of a subset of UCON which includes only authorization predicates. Thissubset is termed as UCON A .AformalmodelofUCON A is defined in which aUCON system is composed of subjects, objects, rights, permissions primitive actionsand policies. Sets of subjects, objects and rights are denoted by S, O andR respectively and S ⊆ O. Apermission is a triple of (s, o, r) wheres ∈ S, o ∈ Oand r ∈ R. An attribute a of an object o is denoted by o.a. The set of attributesis shared by all objects and is denoted by AT T . Attributes are mapped to theirvalues using an assignment: o.a = v, wherev ∈ dom(a) ∪{null}.A UCON system state is a pair (O, σ) whereO is the set of objects andσ : O × AT T → dom(AT T ) ∪{null} is a function which maps each attribute ofeach object to a value or null. The initial UCON state is denoted by (O 0 ,σ 0 ).A primitive action changes the system state. The three primitive actions inUCON A are createObject, destroyObject and updateAttribute. On the applicationof any of these actions, the state of a system is said to change from t to t ′where t is the state before the application of the action and t ′ is the state afterthe action has been performed. In any given state t, the permission function ρ tmaps a pair (subject, object) to a set of rights according to their attribute valuesin state t.A UCON policy consists of a name, two parameter objects (usually a subjectand an object), an authorization rule and a sequence of primitive actions.policy name(s, o) :p 1 ∧ p 2 ∧ ...∧ p n → permit(s, o, r)act 1 ; act 2 ; ...; act kIf one of the primitive actions in a policy is a createObject action, the policy iscalled a creating policy. The set of policies in a system is denoted by C. Changesto a system state occur as a result of application of a policy. For two UCONsystem states, (O t ,σ t )and(O t ′,σ t ′), t ↠ c t ′ denotes that there exists a pair ofobjects (o 1 ,o 2 )whereo 1 ∈ O t such that policy c(o 1 ,o 2 ) can be applied to t andchanges the state to t ′ .Moreover,t ↠ C t ′ if ∃c ∈ C.t ↠ c t ′ and t C t ′ if therepreupdate onupdate postupdatetryAccess permitAccess endAccessInitial requesting accessing enddenyAccessdeniedrevokeAccessrevokedpreupdatepostupdateFig. 1. The UCON Model States

Remote Attestation of Attribute Updates and Information Flows 67exists a sequence of states t 1 ,t 2 ,...,t n such that t ↠ C t 1 ↠ C t 2 ...↠ C t n ↠ Ct ′ . t C t ′ or simply t t ′ is called the transition history from t to t ′ .Zhang et al. have proven that the safety problem in this general model ofUCON A is undecidable [11]. In order to render the safety problem decidable,Zhang et al. propose some restrictions on the system. Different structures havebeen defined in the form of ground policies, attribute update graph and attributecreation graph to formalize these restrictions.Asetofground policies generated from a UCON policy ‘c’ denotes all theevaluations of the policy c with possible attribute tuples of the object parameterswhich satisfy the predicates in the authorization rule of c. Assume AT T = {a}and dom(a) ={1, 2, 3} and the following UCON policy:c(s, o) :s.a > o.a → permit(s, o, r)updateAttribute o : o.a = o.a +1Grounding this policy generates the following three ground policies:c(s :(a =3),o:(a =2):true → permit(s, o, r)updateAttributeT uple o :(a =2)→ (a =3)c(s :(a =3),o:(a =1):true → permit(s, o, r)updateAttributeT uple o :(a =1)→ (a =2)c(s :(a =2),o:(a =1):true → permit(s, o, r)updateAttributeT uple o :(a =1)→ (a =2)Note that for attribute tuples for which the predicate is not true (e.g. s :(a =1),o:(a = 1)), no ground policy is generated.A create ground policy is a ground policy, which contains a createObjectaction in its body. In such a policy, the attribute tuple of the first parameterobject is termed as create-parent attribute tuple and that of the second is termedas create-child attribute tuple. AnAttribute Creation Graph (ACG) is a directedgraph with nodes all possible attribute tuples and an edge from create-parentattribute tuple to a create-child attribute tuple if there exists a correspondingground policy for these tuples.Similarly, in a ground policy which updates an attribute tuple, the old attributetuple is called the update-parent attribute tuple and the updated tuple iscalled the update-child attribute tuple. AnAttribute Update Graph (AUG) is adirected graph with nodes all possible attribute tuples and edges from updateparentattribute tuple to update-child attribute tuple if there exists a correspondingground policy for these tuples.

68 M. Nauman et al.Using these structures, Zhang et al. [11] have shown that a UCON A systemwith finite attribute domains is decidable if the ACG is acyclic, the AUG hasno cycles containing a create-parent attribute tuple and in each creating groundpolicy, the attribute tuples of both the parent and child are updated. Usefulnessof UCON A systems with these restrictions has been shown. For a detaileddiscussion and proofs of these statements, we refer the reader to [11].In the next sections, we describe how a UCON A system with these restrictionscan be remotely attested using dynamic behaviors of the system recorded duringenforcement of policies.3 Behavioral AttestationTraditional attestation techniques [3,4,5] rely solely on the binary hashes of applicationsrunning on the client. A chain of trust is established from the coreroot of trust (i.e. the Trusted Platform Module) to the application. However, allof these techniques measure the target application statically without consideringits inner working [6]. A recent technique, Model-based Behavioral Attestation(MBA) [6], proposes a high-level framework for measuring the internal workingof the target application based on the dynamic behaviors of the differentcomponents of the application. We note that the MBA framework relies on theexistence of a small monitor module in the target application as part of theTrusted Computing Base (TCB) 1 .The monitor, being a part of the TCB, can measure the dynamic behavior ofthe rest of the application in a trusted manner. During an attestation request, themonitor sends these measurements to the challenger where they can be verified.If the behavior depicted by these measurements is compliant with the objectowner’s policy, the challenger can be assured that the security policy is indeedbeing enforced as expected. For the dynamic behaviors reported by the monitorto be trusted, there are two requirements.1. The monitor module has to be verified for correctness using formal methods.While formal verification of large systems is a complex procedure and quicklybecomes infeasible [13], verification of small components is easier and canyield many benefits. The monitor is a relatively small component and itsformal verification adds significantly to the confidence in the correctness ofthe functionality and subsequently to its reported measurements.2. Its hash has to attested using traditional attestation techniques such asIMA [3] or PRIMA [4]. In other words, this dynamic attestation techniqueis not exclusive of traditional attestation mechanisms but supports themby providing an added level of confidence through attestation of internalworking of the application and its dynamic behavior.The rest of the paper describes details of implementation of this monitor ina target application enforcing UCON policies. We discuss the measurements to1 TCB is the collection of software and hardware components which are responsiblefor enforcing security policies on a platform [12].

Remote Attestation of Attribute Updates and Information Flows 69be made for the dynamic behavior of attribute updates and information flows inthe application and the mechanism for reporting these changes to the challengerin a trusted manner. We also describe how the reported behavior can be verifiedagainst the challenger’s policy to ensure that the information flows and attributeupdates in the target UCON application are occurring as expected.4 UCON System AttestationUCON is primarily concerned with usage of an object after it is released to aremote platform. The owner of the object may not have control over the usageoftheobject.Itisthereforeimperativethatshebeabletoestablishtrustonthe remote platform. Without the assurance of trustworthiness of the UCONsystem on the remote platform, there is no way of ensuring that the UCONpolicy attached to the object will indeed be enforced as expected [6].We focus on two aspects of a UCON system implementation in this contribution:1. Attributes play an important role in a UCON system. Attribute mutability isa core feature of UCON which lends the model its flexibility and expressivepower. The challenger needs to be able to verify remotely that attributeupdates occurring on the client are compliant with the policies.2. To ensure that no information leakage can occur, the challenger needs amechanism for remotely attesting possible information flows on the target.Information flows not allowed by the policies of the challenger may lead to aleakage of information to unauthorized parties. By having the client report allpossible information flow to the challenger in a trustworthy manner, possibleinformation leakage can be successfully detected. 2To formulate a framework for these two requirements, we define two behaviors.The first requirement is captured by the attribute update behavior (AU)and the second is captured by the information flow behavior (IF). Eachofthese behaviors is monitored by the Behavior Manager (BM) which is a part ofthe UCON engine on the client end (cf. Section 3). The BM captures dynamicbehavior of attribute updates and possible information flows and is capable ofcommunicating these behaviors to the challenger in a trustworthy manner.Figure 2 depicts the architecture of remote attestation of a UCON system.When a target application on the client requests an object, the server, uponsuccessful authorization of the client, attaches a UCON policy to the object andreleases the protected object to the client. The object is registered with the UCONdecision engine on the client. During the usage of the object, usage authorizationdecisions and any updates which need to be performed are communicatedto the Behavior Manager. The Attribute Update Manager records proofs forthe attribute update behavior AU and the Information Flow Manager recordsproofs for the information flow behavior IF. During an attestation challenge,2 In this contribution, we focus on explicit information flows. Implicit informationflows, such as those through covert channels, are not addressed.

70 M. Nauman et al.Fig. 2. Remote Attestation of a UCON Systemthe Behavior Manager collects these behavior proofs and reports them to thechallenger.Upon receipt of these two behaviors, the challenger performs two behaviorverification procedures. The attribute update verification module utilizes theoriginal UCON policies to generate ground policies (cf. Section 2) which are usedto verify the trustworthiness of the attribute update behavior (cf. Section 4.1).The same set of UCON policies are utilized by the information flow attestationmechanism to verify the information flow behavior using an information flowcheck algorithm (cf. Section 4.2).The details of storing and reporting the two behaviors in a trusted manner onthe target platform and the verification mechanisms utilized on the challengerside are described below.4.1 Attribute Update BehaviorFor capturing the attribute update behavior, the BM implements one or more AttributeUpdate Procedures (AUPs) which are responsible for updating attributeson the client end. The procedures take two inputs, either of which can be anattribute of an object or a constant.Individual calls to an attribute update procedure and subsequent attributeupdates are recorded through a graph structure called the attribute flow graph.This structure stores the relationship between updated attributes and the attributesused as inputs for this updation. Formally:

Remote Attestation of Attribute Updates and Information Flows 71(s1.a = 2) (o1.a = 1)(s1.a = 3) (o1.a = 1)s1.a(s1.a = 3) (o1.a = 2)o1.a(s2.a = 2) (o1.a = 2)s2.a(s1.a = 1) (o2.b = 0)(s2.a = 2) (o2.b = 0)(s2.a = 5)o2.bCONSTFig. 3. Attribute Flow Graph ExampleDefinition 1 (Attribute Flow Graph). The Attribute Flow Graph (AFG)is a directed multi-graph (G,V) where G is a set of nodes representing objectattributes or a constant and V is a set of edges representing attribute updates.An edge directed from o i .a to o j .b denotes an update of o i .a and is labeled with(o i .a = dom(AT T )), (o j .b = dom(AT T )). The label captures the values of o i .aand o j .b before the update takes place. The special node called CONST is usedto denote all constants.Figure 3 shows a graphical representation of the AFG. Note that there may bemore than one attribute updates involving the same set of object attributes butwith different values. An attribute update involving a constant is represented byan edge from the target attribute to the CONST node.To capture the AFG in a trustworthy manner, we employ the constructs ofTrusted Computing. The initial value of the the AFG (i.e. null) and any subsequentchanges to it are stored in an Attribute Update Log (AUL). At startup, theBM initializes the AUL with an initialization token INIT. It monitors all callsto the AUP s and whenever a call is received, it creates an entry in the AUL. Anychange to the AUL is stored in a Platform Configuration Register (PCR) of theTPM by taking a hash of the entry and extending the PCR through pcr extend(cf. Figure 4). The hash of the update procedure (AUP x ) responsible for performingthe specific update is also recorded in the PCR through pcr extend. Thenew value of the PCR after an update is calculated as:PCR AULɛ = SHA-1( SHA-1(PCR AULɛ−1 || SHA-1(AUL ɛ )) ||SHA-1(AUP x ))During an attestation challenge, the BM receives a nonce from the challengerand submits the nonce to the TPM through a Trusted Software Stack(TSS) [14,15,16]. It requests the TPM to perform a quote over the given PCRand nonce. The quoted value of the PCR is sent to the challenger along with theAUL for verification. 33 The interested reader may refer to [17] for a detailed description of the quote operationover a PCR.

72 M. Nauman et al.INITs1.a:o1.a:s1.a=2:o1.a=1::AUP1s1.a:o2.b:s1.a=1:o2.b=0::AUP2s1.a:o1.a:s1.a=3:o1.a=1::AUP1s2.a:CONST:s2.a=5::AUPYs1.a:o1.a:s1.a=2:o1.a=2::AUPXs2.a:o1.a:s2.a=2:o1.a=2::AUP2s2.a:o2.b:s2.a=2:o2.b=0::AUP1// initialize the AUL// update by AUP1 involving s1.a and o1.a// update by AUP2 involving s1.a and o2.b// ...// update by AUPY involving s2.a and a constant// ...// ...// ...Fig. 4. Sample Attribute Update LogCapturing the dynamic behavior of updates is a relatively simple task. Oncethe attribute update log is received by the challenger, it has to be verified againstthe policy to ensure that all attribute updates occurring on the client complywith the policies of the challenger. The challenger utilizes the grounding procedure,defined in Section 2, for this compliance checking.In order for the attribute updates occurring on the client to be consideredas trustworthy, the challenger needs to be able to verify that, for each update,there exists a ground policy (generated as a result of grounding of the policiessent to the client), which requires the update performed at the client end. Italso requires the hash of the update procedure responsible for performing theupdate to be trusted. The first step for the verification of attribute updatebehavior is the verification of the signature performed by the client’s TPM onthe PCR value. This ensures that the PCR values can be trusted to be signed bya genuine TPM and not by a software masquerading as a TPM. The second stepis to verify the Attribute Update Log (AUL) against the PCR value returned.This is a similar operation to the verification procedure used by the IntegrityMeasurement Architecture [3]. Hashes of entries in the AUL and those of theupdate procedures are concatenated in sequence to give the final value of thePCR. For each entry AUL ɛ in the AUL, the PCR value at AUL ɛ is given by:PCR AULɛ = SHA-1( SHA-1(PCR AULɛ−1 || SHA-1(AUL ɛ )) ||SHA-1(AUP x ))where AUP x is the procedure performing the update recorded in AUL ɛ .Ifthefinal value of the computation matches the value of the PCR returned by thetarget’s TPM, the challenger can be assured that the AUL has not been tamperedwith and can be used for verification of the target’s behavior.Thenextstepintheattributeupdatebehavior verification is to verify eachattribute update operation against the ground policies to ensure that no illegalattribute updates have occurred on the target platform and that the hash of theupdate procedure responsible for performing the updates is a known good one.For each attribute update, represented by edges in the AFG, there must exist aground policy which updates the target (object, attribute) pair using the source(object, attribute) pair in the AFG. Attribute updates involving constants mustbe verified against the CONST node against the values required by the groundpolicies. Formally:∀v ∈ V.∃c n ∈ C n .∃uo ∈ c n .target(uo) =target(v)∧∃s ∈ sources(uo).s = source(v)∧∀o.a ∈ v.value(o.a) =avalue(o.a, uo)

Remote Attestation of Attribute Updates and Information Flows 73where uo is an update operation in a ground policy c n , target(uo) is the outputof the update operation, sources(uo) are the inputs to the update operation uo,value(o.a) returns the value of the attribute a of object o during the update procedureand avalue(o.a, uo) returns the attribute value of o.a from the attributetuple of uo.If the above condition is satisfied by the complete AFG, the challenger canbe assured that all attribute update operations performed on the client havebeen in compliance with the UCON policies. We define the trustworthiness oftheattributeupdatebehaviorAU as:AU.behavior = trusted iff∀v ∈ V.∃c n ∈ C n .∃uo ∈ c n .target(uo) =target(v)∧∃s ∈ sources(uo).s = source(v)∧∀o.a ∈ v.value(o.a) =avalue(o.a, uo)∧∀a ∈AUP x . a.behavior = trustedIn essence, attribute update behavior is trusted if and only if 1) all attributeupdates taking place on the target machine are allowed by some ground policiesgenerated from the original usage policies of the challenger and 2) all theprocedures responsible for performing attribute updates on the target are alsotrusted.4.2 Information Flow BehaviorFor the measurement of the information flow behavior, the Behavior Managerutilizes an Information Flow Manager. This component of the UCON implementationis responsible for maintaining a structure called the Access Rights Graph(ARG). The ARG records information about which objects have been grantedaccess rights to other objects. Formally:Definition 2 (Access Rights Graph). An Access Rights Graph (ARG) is adirected graph (H, W) where H is a set of nodes representing the objects and Wis a set of edges representing rights. An edge from h 1 to h 2 labeled r denotes therights r assigned to h 1 on h 2 at some point in the usage history where h 1 ,h 2 ∈ H,r ∈ 2 R and R is the set of rights.Figure 5 shows a graphical depiction of the ARG. To store and later report thisstructure in a trusted manner, the BM utilizes a technique similar to that usedfor capturing the AFG. The initial (empty) value of the ARG is stored in aAccess Rights Log (ARL). The ARL is initialized as empty by setting it to thevalue INIT. Any decisions by the UCON decision module are captured by theARL. If an access is granted to a subject s on an object o for right r, nodessand o are added to the ARG, if they are not already present. An entry is madein the ARL for recording the addition of the nodes. An edge, directed from s

74 M. Nauman et al.{ delete }s 3{ print }s 1{ read, write }{ read, write, copy }{ copy, delete, append }o 1{ read, print }{ write }s 2o 3{ read }o 2Fig. 5. Access Rights Graph Exampleto o is added to the ARG and labeled {r} if such an edge doesn’t already exist.If the edge already exists, right r is added to the set of rights on the edge. Anentry is made in the ARL corresponding to the addition of the right for s on o.Figure 6 shows an example ARL created as a result of different usage decisions.Whenever an entry is appended to the ARL, its hash is calculated by theInformation Flow Manager and stored in the PCR through pcr extend. Duringan attestation challenge, the ARL and this PCR value is returned to thechallenger where verification of these structures against the challenger’s UCONpolicies takes place.For the verification of the ARL on the challenger side, we utilize an informationflow check algorithm which utilizes the same semantics as the UCONsafety check algorithm presented by Zhang et al. [10]. The first step, as in theverification of the ARL, is to verify the signature by the TPM to ensure thatthe PCR values returned are from a genuine TPM and that the ARL is trusted.Every entry ARL ɛ in the ARL is concatenated in sequence to give the final valueof the PCR as:PCR ARLɛ = SHA-1(PCR ARLɛ−1 || SHA-1(ARL ɛ ))Verification of the entries in the ARL provides assurance to the challenger thatthe ARL has not been tampered with. The individual entries in the ARL areINITADD|s1ADD|o3ASSIGN|s1:o3:deleteADD|o1ASSIGN|s1:o1:readADD|o2ASSIGN|s1:o2:append...// initialize the ARL// add a new subject s1// add a new object o3// assign right delete to s1 on o3// ...// ...// ...// ...Fig. 6. Sample Access Rights Log

Remote Attestation of Attribute Updates and Information Flows 75Discarded: Noinformation Flowo3o1o2Fig. 7. Information Flow Graph corresponding to ARG in Figure 5used to re-generate the ARG on the challenger side. After this re-generation, thechallenger creates an Information Flow Graph (IFG). The IFG depicts possibleinformation flows implied by the Access Rights Graph. Formally:Definition 3 (Information Flow Graph). An Information Flow Graph(IFG) is a directed graph (I,U) where I is a set of nodes representing the objectsand U is a set of edges representing possible information flow in the direction ofthe edge. An edge from i 1 to i 2 denotes that information may have flown fromi 1 to i 2 where i 1 ,i 2 ∈ I.To construct the IFG from the ARG, we first define all rights as read-like, writelike,read-write-like or no-impact [18]. No-impact operations are those whichcannot play a part in information flow (such as print) and are discarded immediately.Afterwards, all objects in the ARG are represented in the IFG. For eachsubject s in the ARG, an edge is created from o 1 to o 2 if a read-like (or readwrite-like)operation is granted to s on o 1 and a write-like (or read-write-like)operation is granted to s on o 2 . Afterwards, orphan nodes are removed from theIFG. Figure 7 shows an IFG corresponding to the ARG of Figure 5.For the verification of possible information flows as depicted by the IFG thefollowing procedure is adopted. For each edge on the IFG, Algorithm 1 is appliedto ensure that the information flow is compliant with the policies of the challenger.The algorithm takes an initial UCON state and a set of ground policiesas inputs. A finite automaton (FA) is created which maps changes to the UCONstate as a result of applying non-creating ground polices (line 2). For each statein the resulting FA, a few operations are performed. First, all subjects whichhave been assigned a read-like (or read-write-like) right on o 1 are added to theset reading (lines 4,6). If one of the subjects was previously granted a write-likeoperation on o 2 , the algorithm immediately returns true (line 7) as the subjectwould have been able to cause information to flow from o 1 to o 2 .A similar procedure is followed for write-like operations (line 9). All subjectswhich have been assigned a write-like operation (or read-write-like operation)on o 2 are added to the set writing (lines 9,11) and if one of them was previouslyassigned a read-like operation on o 1 , the algorithm returns true immediately(line 12). 4Finally, creating ground policies are applied (line 15) to extend the UCONsystem with new objects and InfoFlowCheck() algorithm is called recursively(line 20) to check for possible information flows in this expanded space.4 Note that the algorithm only checks for information flow from o 1 to o 2 and not inthe other direction.

76 M. Nauman et al.Algorithm 1. Information Flow Check AlgorithmInput: UCON A system with initial state t 0 =(O 0,σ 0), a finite set of ground policiesand two objects, o 1 and o 2Output: A boolean value which is true only if information can flow from o 1 to o 21) InfoFlowCheck(O 0,t 0)2) Construct a finite state automaton FA with objects O 0 and the set of non-creatingground policies as in [11]3) foreach t 0 t ∈FAdo4) collect ς = {x|r ∈ ρ t(x, o 1) ∧ r =‘read’}5) foreach s ∈ ς do6) reading := reading ∪{s}// maintain a set of subjects which have been allowed to read from o 17) if s ∈ writing return true;8) end for9) collect ς = {x|r ∈ ρ t(x, o 2) ∧ r =‘write’}10) foreach s ∈ ς do11) writing := writing ∪{s}// maintain a set of subjects which have been allowed to write to o 212) if s ∈ reading return true;13) end for14) foreach subject s in t do15) foreach creating ground policy c(s : τ s,o: τ o), where τ s(a) =σ s(o.a) do16) enforce c(s : τ s,o: τ o);17) create object o and update its attribute tuple to τ o;′18) update s’s attribute tuple to τ s;′19) the system state changes to t ′ with new object o and update attributes ofs and o ;20) InfoFlowCheck(O 0 ∪{o},t ′ )21) end for22) end for23) end forThe trustworthiness of the information flow behavior IF is defined as:IF.behavior = trusted iff ∀u ∈ U. InfoF lowCheck(u) =truewhere U is the set of edges in the IFG.Concisely, information flow behavior is trusted if and only if all possible pathsof information flow on the client comply with the challenger’s usage policies.5 Related WorkOne of the earliest and most significant works analyzing information flow modelsis by Denning [19] in which mechanisms for information flow are formalizedusing a lattice structure of labels and classes of objects. JFlow [20] is a securitytypedlanguage providing “mostly-static” information flow control by assigninglabels to objects within the source code and ensuring that information flows

Remote Attestation of Attribute Updates and Information Flows 77comply with the security policy of the programmer. JFlow relies on a specializedcompiler and information flow controlling virtual machine for enforcementof information flow control. Haldar et al. [21] have devised a mechanism for implementingmandatory access control (MAC) mechanisms in virtual machinesfor controlling information flows. They propose the use of run-time policy enforcementas opposed to the mostly-static compile time checks [20] for enforcingMAC policies. Nair et al. [22] have presented an information flow control systemwhich addresses the issue of implicit information flows. The resulting frameworkis capable of dynamically assigning labels to objects and propagating these labelsbased on information and control flow.All of these models and mechanisms address either information flow controlor audit but do not deal with remote attestation of information flows, the underlyingenvironment or the target application. However, as can be seen, someof them deal with implicit information flows as well as explicit ones and can,therefore, help in future extensions of this work.From the aspect of remote attestation, several works have been proposed.These include the Integrity Measurement Architecture [3], which allows a remoteparty to verify the trustworthiness of a target platform based on the load-timeintegrity of binaries on the target platform. Policy Reduced Integrity MeasurementArchitecture (PRIMA) [4] targets a specific application by analyzing theinformation flow to and from the target application but still does not addressinternal structures and semantics of the application. LKIM [7] is one of thefew approaches, which target the dynamic behavior of a system. It verifies theintegrity of a Linux kernel by measuring and reporting the target’s dynamicstate [23]. It has been shown to detect malicious code, which could not be detectedusing hashes of static code.Gu et al. [24] have described a new approach for measuring the behavior of anapplication using static analysis of the source code and verification of programexecution against this benchmark.The attestation technique described in our contribution is significantly differentfrom both these approaches in two respects. Firstly, we utilize the TPMhardware for trusted storage and reporting of measurements. Secondly, our approachutilizes the owner’s policies for the creation of a baseline. This allows forthe integrity verification of a specific application for a particular purpose, thusgreatly reducing the complexity of attestation.Semantic Remote Attestation [25] is closest to the approach described in thispaper. It proposes the use of a Trusted Virtual Machine, which is established astrusted and is then expected to enforce the policies at the VM level. However,trust on the correct enforcement of the policies is implied and no mechanismfor measuring the correctness of the enforcement is provided. Our techniquebuilds on this approach and describes a detailed architecture for using runtimemeasurements of the behavior in a trusted manner for dynamic behavioralattestation of a target application. To the best of our knowledge, no work hasbeen done for the attestation of attribute updates and information flows in aUCON system at this level of detail.

78 M. Nauman et al.6 Conclusion and Future WorkRemote attestation is an integral part of Trusted Computing. It allows a challengerto establish the trustworthiness of a remote platform depending on itsbehavior. Recent advances in remote attestation have led us to believe thatmeasuring the hashes of executables on the remote platform is insufficient forthe establishment of trust. It is necessary to verify the dynamic behavior andinternal functioning of a target application. In this paper, we have proposed amechanism for attesting the dynamic behavior of UCON – a highly expressiveusage control model. Two important aspects of UCON, attribute updates andinformation flow, have been described. We have presented details regarding measurement,storage and verification of these behaviors in a trustworthy manner.The model of UCON under consideration is UCON A with certain restrictions,which has previously been shown to be useful in practical scenarios. Establishmentof trust on a remote party implementing this model will provide confidenceto the challenger that her policies will indeed be enforced on the remote end asdictated.This paper has introduced the novel concept and semantics of using a small‘behavior manager’ component on the remote platform for collecting trust tokensused during attestation. This concept has been applied to collect and verifyattribute update behavior and information flow behavior. The same techniquecan, with slight modifications, be applied for collecting various other types oftrust tokens, such as information flows to and from other applications, systemcalls and input/output to storage devices, for an even more detailed inspectionof the dynamic behavior of the target application. These and other behaviorsare being considered for attestation of UCON and even generalized applicationsnot following the UCON model. These form the basis of ongoing work in thisresearch.AcknowledgementsThis research work has been supported by Grant No. ICTRDF/TR&D/2008/45from the National ICT R&D Fund, Pakistan to Security Engineering Research Group,Institute of Management Sciences, Peshawar.References1. Park, J., Sandhu, R.: Towards Usage Control Models: Beyond Traditional AccessControl. In: SACMAT 2002: Proceedings of the seventh ACM Symposium on AccessControl Models and Technologies, pp. 57–64. ACM Press, New York (2002)2. Trusted Computing Group, http://www.trustedcomputinggroup.org/3. Sailer, R., Zhang, X., Jaeger, T., van Doorn, L.: Design and Implementation ofa TCG-based Integrity Measurement Architecture. In: SSYM 2004: Proceedingsof the 13th conference on USENIX Security Symposium, Berkeley, CA, USA,USENIX Association (2004)

Remote Attestation of Attribute Updates and Information Flows 794. Jaeger, T., Sailer, R., Shankar, U.: PRIMA: Policy-Reduced Integrity MeasurementArchitecture. In: SACMAT 2006: Proceedings of the eleventh ACM Symposium onAccess Control Models and Technologies, pp. 19–28. ACM Press, New York (2006)5. Sadeghi, A.R., Stüble, C.: Property-based Attestation for Computing Platforms:Caring about Properties, not Mechanisms. In: NSPW 2004: Proceedings of the2004 Workshop on New Security Paradigms, pp. 67–77. ACM Press, New York(2004)6. Alam, M., Zhang, X., Nauman, M., Ali, T., Seifert, J.P.: Model-based BehavioralAttestation. In: SACMAT 2008: Proceedings of the thirteenth ACM symposiumon Access control models and technologies. ACM Press, New York (2008)7. Loscocco, P.A., Wilson, P.W., Pendergrass, J.A., McDonell, C.D.: Linux KernelIntegrity Measurement Using Contextual Inspection. In: STC 2007: Proceedings ofthe 2007 ACM Workshop on Scalable Trusted Computing, pp. 21–29. ACM, NewYork (2007)8. Zhang, X., Nakae, M., Covington, M.J., Sandhu, R.S.: Toward a Usage-Based SecurityFramework for Collaborative Computing Systems. ACM Trans. Inf. Syst.Secur. 11(1) (2008)9. Srivatsa, M., Balfe, S.: Trust Management For Secure Information Flows. In: CCS2008: Proceedings of the 15th ACM Conference on Computer and CommunicationsSecurity, pp. 175–187. ACM, New York (2008)10. Zhang, X., Parisi-Presicce, F., Sandhu, R., Park, J.: Formal Model and PolicySpecification of Usage Control. ACM Trans. Inf. Syst. Secur. 8(4), 351–387 (2005)11. Zhang, X., Sandhu, R., Parisi-Presicce, F.: Safety Analysis of Usage Control AuthorizationModels. In: ASIACCS 2006: Proceedings of the 2006 ACM Symposiumon Information, computer and communications security, pp. 243–254. ACM, NewYork (2006)12. Kanerva, P.: Anonymous Authorization in Networked Systems: An Implementationof Physical Access Control System. Masters Thesis. Helsinki University ofTechnology (March 2001)13. Bella, G., Paulson, L.C., Massacci, F.: The Verification of an Industrial PaymentProtocol: the SET Purchase Phase. In: CCS 2002: Proceedings of the 9th ACMConference on Computer and Communications Security, pp. 12–20. ACM, NewYork (2002)14. TCG Software Stack (TSS) Specifications,https://www.trustedcomputinggroup.org/specs/TSS/15. Trusted Computing for the Java(tm) Platform,http://trustedjava.sourceforge.net/16. Java Community Process. JSR321: Trusted Computing API for Java,http://jcp.org/en/jsr/detail?id=32117. Alam, M., Zhang, X., Nauman, M., Ali, T.: Behavioral Attestation for Web Services(BA4WS). In: SWS 2008: Proceedings of the ACM Workshop on Secure Web Services(SWS) located at 15th ACM Conference on Computer and CommunicationsSecurity (CCS-15). ACM Press, New York (2008)18. Guttman, J.: Verifying Information Flow Goals in Security-Enhanced Linux. Journalof Computer Security 13(1), 115–134 (2005)19. Denning, D.E., Denning, P.J.: Certification of programs for secure information flow.Commun. ACM 20(7), 504–513 (1977)20. Myers, A.C.: JFlow: Practical Mostly-static Information Flow Control. In: POPL1999: Proceedings of the 26th ACM SIGPLAN-SIGACT symposium on Principlesof programming languages, pp. 228–241. ACM, New York (1999)

80 M. Nauman et al.21. Haldar, V., Chandra, D., Franz, M.: Practical, Dynamic Information-flow for VirtualMachines, www.vivekhaldar.com/pubs/plid2005.pdf22. Nair, S., Simpson, P., Crispo, B., Tanenbaum, A.: A Virtual Machine Based InformationFlow Control System for Policy Enforcement. Electronic Notes in TheoreticalComputer Science 197(1), 3–16 (2008)23. Thober, M., Pendergrass, J.A., McDonell, C.D.: Improving Coherency of RuntimeIntegrity Measurement. In: STC 2008: Proceedings of the 2008 ACM Workshop onScalable Trusted Computing. ACM, New York (2008)24. Gu, L., Ding, X., Deng, R., Xie, B., Mei, H.: Remote Attestation on ProgramExecution. In: STC 2008: Proceedings of the 2008 ACM Workshop on ScalableTrusted Computing. ACM, New York (2008)25. Haldar, V., Chandra, D., Franz, M.: Semantic Remote Attestation – A VirtualMachine directed approach to Trusted Computing In. Proc. of the Third VirtualMacine Research and Technology Symposium USENIX (2004)

Measuring Semantic Integrity for RemoteAttestationFabrizio Baiardi 1 , Diego Cilea 2 , Daniele Sgandurra 2 , and Francesco Ceccarelli 31 Polo G. Marconi, La SpeziaUniversità di Pisa, Italybaiardi@di.unipi.it2 Dipartimento di InformaticaUniversità di Pisa, Italy{cilea,daniele}@di.unipi.it3 ENEL SpA, Italyfrancesco.ceccarelli@enel.itAbstract. We propose a framework for the attestation of the integrityof a remote system that considers not only the configuration of the systemto be attested but also its current behaviour. The resulting architecture,called Virtual machine Integrity Measurement System (VIMS), isbased upon virtualization technology and it runs two virtual machines ona system to be attested, i.e. the Client (C-VM) and the Assurance VM(A-VM). A generic remote server (REM-S) accepts incoming connectionsand cooperates with the A-VM to authenticate and attest the integrityof the C-VM and of the software it runs. The A-VM is a shadow machinethat exploits virtual machine introspection to apply a set of consistencychecks on the configuration of the C-VM and on the software it currentlyruns. The checks depend upon the security policies that the REM-S establishesin the initial connection handshake. The REM-S defines boththe complexity of checks to be applied and the frequency of their executionand it communicates the security policy to the A-VM througha control channel. Policies that can be applied range from the one thatsimply checks the integrity of the binaries loaded by the C-VM to thosethat continuously monitor the dynamic behaviour of applications to discoverattacks that alter their expected behaviour. The control channelalso transmits the results of the checks from the A-VM to the REM-S.As an example, remote attestation can be adopted when a client softwareon the C-VM tries to establish a secure channel to a REM-S on anIntranet.After describing the overall VIMS architecture, we present and discussthe implementation and the performance of a first prototype.1 IntroductionIntranet access has become a fundamental prerequisite for corporate users. Onthe other hand, network administrators cannot guarantee the confidentiality andL. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 81–100, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

82 F. Baiardi et al.the integrity of Intranet data that may be accessed by remote clients becauselittle assurance about the integrity of these clients can be established. In fact,an attacker may have compromised a client application to download or modifycorporate data through the remote access gained by the client. A solution to thisproblem requires a general notion of integrity that, first of all, should considerthat a client system can be trusted only if it executes applications in a predefinedset. Moreover, these applications should be continuously monitored to discoverif they have been attacked. In other words, since both these applications andthe underlying software can be attacked, the notion of integrity should also takeinto account run-time attacks against both applications and the OS rather thanmerely verifying that the proper binaries have been loaded.Virtual machine Integrity Measurement System (VIMS) is an architecturethat implements the proposed approach to integrity measurement and that canbe adopted to protect networks by auditing endpoint configurations. VIMS evaluatesthe integrity of a remote host and it imposes a security policy before theplatform can connect to an existing network to access some of the services itoffers. In more detail, VIMS can guarantee the integrity of a client system thatis trying to connect to the network, where the adopted notion of integrity includesnot only the correct configuration of the system and of the software itruns, but also that the client does not execute some malware that changes theoverall behaviour of its applications. To this purpose, VIMS exploits virtualizationtechnology to enable the client system to run two virtual machines (VMs)on top of a virtual machine monitor (VMM). The Client VM (C-VM) runs theclient software, such as a VPN client application to connect to a remote server(REM-S), while the Assurance VM (A-VM) is a shadow VM that applies a setof security checks on the memory of the C-VM. These checks measure, on behalfof the REM-S, the integrity of the software that the C-VM runs. The A-VMcan either apply consistency checks periodically or on demand when requestedby the REM-S. Furthermore, the complexity of the checks that it applies is afunction of the degree of the assurance that the REM-S requires. As soon asthe A-VM detects anomalous behaviour or some malware, for example a rootkitin the memory of the C-VM, it contacts the REM-S that can tear down theconnection with the C-VM.The rest of the paper is organised as follows. Section 2 introduces the mainconcepts underlying VIMS, such as trusted computing, virtualization, semanticattestation and discusses related works. Section 3 presents the overall architectureof VIMS. The current prototype implementation is discussed in Sect. 4.Section 5 presents a first set of performance results. Finally, Sect. 6 draws someconclusions and outlines future developments.2 BackgroundAfter discussing some related works, this section introduces the main conceptsunderlying VIMS.

2.1 Related WorksMeasuring Semantic Integrity for Remote Attestation 83Trusted Virtual Domains (TVDs) [1] [2] is an architecture where computing servicescan be offloaded into execution environments that demonstrably meet aset of security requirements. A TVD is an abstract union including by an initiatorand one or more responders. During the process of joining, all the partiesspecify and confirm the set of mutual requirements and each party is assuredof the identity and integrity of the computer system of the remote party. Theenforcement of the attestation is delegated to virtual environments. Terra [3] isa VM-based architecture for trusted computing that enables applications withdistinct security requirements to run simultaneously on commodity hardware.The software stack in each VM can be tailored to meet the security requirementsof its applications. [4] discusses the design and implementation of Integrity MeasurementArchitecture (IMA), which is a secure integrity measurement systemfor Linux. This architecture enables a system to prove that the integrity of a programon a remote system is sufficient. IMA uses the Trusted Platform Module(TPM) to detect subversion of the measurements system by comparing a hashvalue stored in the TPM against the one in the measurement system audit log.UCLinux [5] is a Linux Security Module that enables TPM-based usage controlsenforcement. It provides the attestation support, sealing support and protectionfrom administrative abuse required by a trustworthy usage control system, andit does so with existing hardware and limited changes to an existing OS. [6]introduces a formal integrity model to manage the integrity of arbitrary aspectsof a virtualized system. The authors describe the PEV architecture, which isbased upon a model that generalises the integrity management functions of theTPM to cover not only software binaries, but also VMs, virtual devices, anda wide range of security policies. PEV enables the verification of security complianceand the enforcement of security policies. [7] discusses an access controlarchitecture that enables corporations to verify the integrity of a remote clientand establish trust into its ability to enforce a security policy before allowingthe client to access corporate Intranet services. It also shows how to enforcethe policy on both remote clients and VPN servers. To this end, it discussesthe adoption of an integrity heart-beat that enables the VPN server to reactto changes in the security properties of the remote client by updating the securitypolicy. Pioneer [8] is a software-based platform addressing the problem ofverifiable code execution on legacy computing hosts without relying on secureco-processors or CPU virtualization extensions. Pioneer is based on a challengeresponseprotocol between an external trusted entity (the dispatcher) and anuntrusted computing platform. Property based attestation [9] [10] is a strategythat describes an aspect of the behaviour of the platform to be attested withrespect to security-related requirements. As an example, a property may statethat a platform has built-in measures to conform to the privacy laws, or that itstrictly separates processes from each other, or that it has built-in functionalitiesto provide Multi-Level Security. A protocol and architecture for propertyattestation is proposed in [11]. With property attestation, a verifier is securely assuredof security properties of the execution environment of the verified platform

84 F. Baiardi et al.without receiving detailed configuration data. This enhances privacy and scalabilitybecause the verifier needs to be aware of only a few security propertiesrather than of a huge number of acceptable configurations. Semantic integrity[12] is a measurement approach targeting the dynamic state of the software duringexecution and, therefore, providing fresh measurement results. Similar tothe adoption of language-based virtual machines for remote attestation of dynamicprogram properties [13], this approach can provide increased flexibility forthe challenger, because the integrity monitor can examine the current state of asystem to detect semantic integrity violations. This technique alone will not producecomplete results as it does not attempt to characterise the entire system.However, it does offer a way to measure the integrity of portions of the targetnot suitable for measurement by hashing. Prima [14], which is an extension ofthe Linux IMA system, measures information flow integrity that can be verifiedby remote parties.2.2 Trusted ComputingOne outstanding framework of integrity measurement is that endorsed by theTrusted Computing Group (TCG), an industry consortium that defines specificationsfor hardware and software components [15]. The standard TCG measurementis the computation of SHA-1 cryptographic hash of critical components asthey are loaded into the system. The TCG guidance for measurement includesthe Trusted Platform Module (TPM) as a hardware device to securely store andreport measurement values in the form of a SHA-1 hash. This architecture providesa good model for determining the integrity during software initialisation.Moreover, the TPM is becoming standard on several personal computing platforms.However, this framework does not address issues such as loss of platformintegrity due to run-time attacks against the system. If the system environmentcan be attacked through either its interfaces or the hardware and software environment,this issue requires not only to measure the integrity of an executablestored in a file, but also to periodically measure the integrity of the software runningin memory [16]. This approach poses new problems because, first of all, thewell-known execution environment initialised at boot time, and that provided asafe environment for the measurement, cannot be reproduced without rebootingthe system. Second, if the applications virtual memories are updated after theyhave been loaded, their hash value change as well. Finally, some run-time dataupdates cannot be correctly represented through hash values.TPM and vTPM. In systems equipped with a TPM chip [17] [18], the TPMacts as a root-of-trust in the process that builds and setup the software environmentsand it ensures that a system has loaded its software properly. Moreover, itprotects secrets such as asymmetric keys oritcanbeusedtoencryptsymmetrickeys. The TPM has a set of registers that it protects from the system softwareand it implements two operations on each register content: extend and quote.The former operation takes a value V as input and computes the SHA-1 hash of

Measuring Semantic Integrity for Remote Attestation 85the current register content appended to V. Instead, a quote operation generatesa message with the register contents and signs it with a key protected by theTPM.The vTPM [19] [20] extends the functionalities of the TPM in a virtualizedenvironment, where several VMs can run distinct OSes on the same platform.The vTPM is a virtual extension of the TPM that enables the VMM to emulatethe features of the TPM, by exporting to each VM a virtual implementation ofthe TPM having the same interface of the TPM.2.3 Virtualization and Semantic AttestationA Virtual Machine Monitor (VMM) is a thin software layer that runs on top ofa physical machine and that creates, manages and monitors Virtual Machines(VMs), i.e. execution environments. Each VM emulates, at software, the behaviourof the underlying physical machine. In this way, a VMM can run differentOSes in parallel.To apply consistency checks on the OS kernel of a system and on the processesit runs in a robust and transparent manner, several proposed solutions exploitvirtualization technologies [21]. Virtualization enhances the robustness of controlsand guarantees a transparent monitoring by running two VMs on the samephysical machine, e.g. a monitored VM and a privileged VM. The former runsthe system and the processes to be monitored, while the latter is a distinct VMthat can access the memory of the other VM to apply a set of security checkson any region in this memory, i.e. the privileged VM has full access to the memoryspace of any other VM to apply virtual machine introspection [22]. Thesechecks verify the integrity of the software that the monitored VM runs and theyimplement a form of semantic attestation because, first of all, they consider thecurrent status of the running processes. Furthermore, they can exploit any informationabout the expected behaviour of a component to discover anomalousbehaviour of the component itself.3 Overall ArchitectureVirtual machine Integrity Measurement System (VIMS) is a system that measuresthe integrity of a node as required by remote semantic attestation. VIMSintegrates a set of tools for static and dynamic analysis to protect the OS kerneland the running processes of a node against attacks trying to modify theirexpected behaviour. The various tools of VIMS analyse the current state ofthe critical data structures loaded by the kernel, the kernel itself, including themodules, and the running processes.Design Goals. VIMS is aimed at implementing a fairly general and reliablesystem to measure the integrity of a remote client, so that the server can beassured of the state of the remote host. The main goals of VIMS are:

86 F. Baiardi et al.1. granular checks on the integrity of the client: with respect to solutions thatonly exploit TPM-based functions, VIMS can apply more granular checksthrough a set of static and dynamic tools;2. support for dynamic policies: as long as the client is connected to a network,its run-time state should be continuously monitored, to detect whether ithas been infected by a malware after being successfully attacked. Moreover,the policy can be changed according to changes in the client configuration;3. mutual attestation: as an example, in a peer-to-peer environment, all theparties should be mutually assured of the integrity of any other peer;4. scalability: the overhead of an attestation should be negligible.Fig. 1. Overall ArchitectureVIMS Components Description. VIMS defines a set of components anda protocol that rules the information exchange among these components anddefine the format of the various messages. These components are (see Fig. 1):(i) the C-VM, i.e. the client virtual machine; (ii) the A-VM, i.e. the assurancevirtual machine, paired with the C-VM; (iii) the REM-S, which is a genericapplication server. VIMS also defines a protocol. In the more general case, aclient software running on the C-VM contacts the REM-S to open a connectionto access some services offered either by the REM-S of by a network that theREM-S interfaces. Before allowing the client to connect and access the service,the REM-S establishes an out-of-band control channel with the A-VM of thenode that runs C-VM. The IP address of the A-VM is statically known andpaired with that of the C-VM. As long as the C-VM and the REM-S interact,the REM-S and the A-VM periodically exchange information through the controlchannel about (i) the security policy to be applied and (ii) the results of theexecuted checks that are used to evaluate the C-VM integrity. The protocolexploits the out-of-band control channel also to inform the REM-S that the C-VM has been compromised either before or during the communications betweenthe C-VM and the REM-S.VIMS may exploit the TPM and vTPM to apply the consistency checks onthe C-VM starting from a valid root-of-trust, which is located in the hardware.With respect to systems that are based on TPM mechanisms only, VIMS can

Measuring Semantic Integrity for Remote Attestation 87implement a semantic attestation that applies consistency checks based upon thesemantic behaviour of the processes. In this case, a static tool is firstly appliedto analyse the source code of the program run by a process to be attested.Then, the A-VM uses the output of this tool to monitor the status of the C-VMmemory and the run-time system call sequence that a process produces. In thisway, VIMS can apply rigorous and granular semantic checks at run-time, whichare strictly more powerful that those based upon the hash of the running codeonly.The A-VM exploits virtual machine introspection (VMI) [22] to retrieve criticaldata structures in the memory of the C-VM and evaluate a set of assertionson these structures. Each assertion is an invariant for the original applicationthat constrains the values in the data structure and that is violated any timethe application has been attacked. By evaluating these assertions VIMS can:(i) guarantee the integrity of critical kernel data structures; (ii) assure that aprocess invokes only a predefined set of system calls.In this way, VIMS implements a semantic integrity attestation because byapplying rigorous and granular semantic checks that are more powerful thanthose based upon hashes of running code only. In fact, by monitoring the C-VM’s current behaviour, the A-VM monitors not only the binaries that havebeen loaded by the OS, but also their dynamic integrity.The A-VM can apply alternative security policies, which can be parametrisedaccording to: (i) the frequency of the execution of security checks; (ii) theirgranularity, i.e. which data structures and software code need to be checked forintegrity. VIMS exploits the features of the TPM to build a hash chain on theclient system. This hash chain is used to measure a predefined sequence of codeloads, such as the authenticated boot of the VMM and of the kernel of the A-VMfrom the BIOS and boot-loader. The TPM provides measurements that indicatethat the VMM is safely started, so that it can initialise the local A-VM to assureit is started in a safe state. The A-VM enables the REM-S to retrieve these hashvalues, which are called measurements. This list is protected by the A-VM andcannot be accessed by the C-VM. In this way, the REM-S can establish trust atfirst into the A-VM measurements and then into the run-time properties of theC-VM.After the A-VM has been safely initialised, it periodically applies virtual machineintrospection to check the integrity of the software run by the C-VM.The A-VM uses the message returned by the TPM quote operation to send anauthenticated hash chain to the REM-S to validate the integrity of the codecontained in the hash chain that belongs to the client.Threat Model. As far as concerns the definition of the threat model, the mostimportant feature is the availability of a TPM. If the TPM is not availableon the system that runs the C-VM and the A-VM, a transparent root-of-trustcannot be guaranteed. In this case, the reliability of integrity measurements canbe guaranteed if and only if:

88 F. Baiardi et al.– the VMM is trusted; this requires that no remote software interface is opento an adversary and its state cannot be altered by a physical access to thesystem;– the public and private keys of the A-VM cannot be tampered with or, incase of the private key, disclosed;– the REM-S is trusted: this is fairly reasonable, since we assume the serverruns in a controlled environment.On the other hand, if the client subsystem is equipped with a TPM, then themain assumptions to trust VIMS measurements are:– TPM and CPU are trusted;– the BIOS that initiates chain of measurements of the VMM and of the A-VMis trusted;– Memory cannot be hacked at run-time (e.g. via DMA).Obviously, in both cases, the C-VM is untrusted, so it may be infected bymalware, and so on. The A-VM and the REM-S initially establish trust basedon certificates signed by a trusted Certification Authority.Formal Model. We have defined a formal model to deduce which chains oftrust can be created and which components can be trusted according to thetrust relations among components, i.e. C-VMs, A-VMs and TPM in the system.The model defines a partially ordered set of tests, i.e. checks to be applied to acomponent, and of policies, where a policy is a pair including a set of tests anda frequency to apply such tests. Then, each component c can define:a) a set of trusted components trusted(c);b) a policy to be applied to trust a component that does not belong to trusted(c);c) the policy it can apply to each other component. An empty policy denotesthat c cannot test a component;d) invoke(c, p), which is a set of components that can use c to apply a policyp to other components, i.e. they can invoke the policy that c can apply toother components;e) a policy to be applied to a component that does not belong to invoke(c) butwant to use c.For each instance of the model, we can compute, for each component c, theset of components c trusts. This set is computed as the fixed point of a set ofequations that relates the set of components that c trusts and those that c caninvoke to apply a policy. In practice, the computation of the fixed point correspondsto that of the transitive closure of the two sets for all the components.Several versions of the model can be defined and the main difference is related tothe component that has to invoke a test. In one version, a component a invokea policy applied by b to be trusted by c. In another version, c invokes the policyapplied by b to check whether a may be trusted.A physical architecture and a mapping of the various components onto thisarchitecture defines an instance of the model because, as an example, a VM may

Measuring Semantic Integrity for Remote Attestation 89trust other VMs that run on a physical node only if this node includes a TPMcomponent or a VM can test another one, e.g. it can apply a non empty policy,only if both the VMs run on the same node. The formal model makes it possibleto prove in advance, given an architecture, a mapping and a version of the model,whether a chain of trust between two components exists. Furthermore, the proofis automatic because the computation of the fixed point of the set of equationscan be fully automated.A more general model may also consider the communication among componentsso that a component a trusts another component b only if there arec 1 ,...,c n components that a trusts and that can guarantee the confidentialityand/or the integrity of communications between a and b.3.1 C-VM MeasurementsWe describe now in more detail how VIMS measures the integrity of the C-VMand the corresponding interactions among the various VIMS components.To verify the integrity of the C-VM, VIMS implements the following steps:1. verification of the initial C-VM integrity by applying a set of measurementsto its configuration. These measurements consist of a set of hash computationsof the code of running processes and of the C-VM kernel, i.e. criticaldata structures, code and kernel modules. If the client system is equippedwith vTPM, VIMS can extend the root-of-trust to the physical platform;2. the A-VM communicates the results of the measurements to the REM-S;3. as soon as the REM-S has received the A-VM measurements, it can choosethe security policy to be applied. To determine an optimal compromise betweenthe attestation level and the corresponding overhead, the range ofpossible policies varies from the one that periodically computes the hasheson the running software to the one that monitors the sequences of OS invocationsby critical C-VM processes. Furthermore, the assurance level isdynamic, i.e. after receiving a set of measurements the REM-S can changethe assurance level to better satisfy its security requirements.The C-VM runs unmodified client software, and it does not need to be awareof being checked by a distinct VM so that the semantic attestation may befully transparent to the C-VM. To measure the integrity of the C-VM, startingwith the TPM, the following steps are required. Firstly, the TrustedBoot [23] isloaded and the TPM applies a set of measurements on the boot-loader, so thatfrom now on all the steps can be measured from boot to kernel loading and itsmodules. Attestation requires that the measurements of the C-VM are certifiedthrough the keys protected in the TPM and that the remote party can establishtrust on the client integrity based upon these measurements. By computingthe hash of the running software, signed by the private key of the TPM, theremote party can be assured of the trustworthiness of the data received. Inthis way, VIMS creates a chain-of-trust from the BIOS up to the VMs thatcertifies the integrity of the VMM and of the A-VM. Then, further controls can

90 F. Baiardi et al.be periodically applied through virtual machine introspection as requested bythe REM-S. The corresponding results are exchanged through the attestationprotocol between the A-VM client and the attestation module on the REM-S.3.2 A-VMThe A-VM should be something relatively self-contained and non-changing.Moreover, it should run a minimal kernel without any Internet service andthe functionalities it implements should not be directly accessed by any user.Moreover, a stable trusted A-VM may help in attesting to a variety of C-VMapplications. The REM-S must trust that the A-VM is not misbehaving.The A-VM directly accesses and examines the memory of the C-VM throughvirtual machine introspection to detect attacks or erroneous updates of clientapplications or of the underlying OS. After the A-VM has been safely initialisedby the VMM, it applies a set of introspection checks to the pages storing thekernel code, the system call dispatch table, the interrupt descriptor table, andother critical kernel data structures that should never be modified. Hence, theA-VM periodically computes their hashes to check they have not been changed.Moreover, the A-VM retrieves the list of the kernel modules and verifies boththeir integrity and that they are authorised kernel modules. These checks are alsoapplied to critical user-level applications on the C-VM, such as the VPN client,anti-virus software and the likes. If the current hash of a running applicationor of a kernel module differs from the stored values, the REM-S tears down theconnection. Furthermore, the A-VM can also evaluate a set of invariants on datastructures or on the sequence of invocations of an application to discover anomalousvalues due to an attack. Anytime the behaviour of a process differs fromthe one computed by a static analysis of the application source code, the currentC-VM behaviour is flagged as anomalous. VIMS static tools over-approximatethe process behaviour so that no false positives can occur. The A-VM managesa database that stores a set of distinct security policies that it applies on requestby the REM-S. Each policy defines the granularity level of the controls, that inturn determines the measurements to be applied, and their frequency.3.3 Attestation ProtocolThe very basic steps of the attestation protocol among the C-VM, the REM-Sand the A-VM are (see Fig. 1):1. the C-VM requires the REM-S to establish a connection to access someresources;2. the REM-S opens a control channel with the A-VM after the usual credentialschecks;3. the REM-S starts the attestation protocol with the A-VM and it transmitsa list with the initial parameters;4. the A-VM applies introspection to retrieve measurements on the objectsinside the list; afterwards, the A-VM verifies the correspondence among thehash of the code of the running processes and kernel structures;

Measuring Semantic Integrity for Remote Attestation 915. the A-VM returns to REM-S, on the control channel, the results of the hashthat have been computed;6. in case of successful results, the REM-S set on the A-VM the security policythat the A-VM should apply and connects grants the access to C-VM.Further features of the protocol are: (i) the control channel between the A-VMandtheREM-SexistsaslongastheC-VMandtheREM-Sareconnected;(ii) the A-VM can apply specific consistency checks on the C-VM on request bythe REM-S; (iii) the database of measurement configurations on the A-VM canbe extended at run-time through proper REM-S requests; (iv) the REM-S canrequest a specific action after a timeout has been elapsed.4 Current ImplementationXen [24] 3.1.0 is the adopted technology to create the virtual machines basedon Debian Etch 4.0 with Linux kernel 2.6.18. We adopted the tool described in[25] to define the semantic checks to be applied to the critical processes runningon the C-VM, and an introspection library [26] to compute the assertion on theC-VM memory.The following A-VM modules have been developed either to implement theattestation protocol or to apply the measurements:– assurance module: a client plugin, running on the A-VM, to manage theremote attestation protocol;– a vTPM module interface (if TPM is present);– a database for measurements and security policies;– an interface for the low-level introspection function.The following REM-S modules have been implemented:– an attestation module;– a database for measurements and policies;– an OpenVPN plugin [27];– a plugin for ghttpd web-server;– a vTPM module interface.The modules to execute the attestation protocol have been implemented inJava. The attestation library on the server-side is composed of 4 Java classesof about 1500 lines of code, whereas the assurance module on the client-side isabout 1000 lines of Java code, including a small wrapper to interface with theintrospection functions.The following sections discuss two test-cases we have implemented. In the firstone, the C-VM used a VPN client to access a remote Intranet through a VPNserver executing on the REM-S. The Intranet hosted critical SCADA devicesthat could be remotely accessed and monitored. We have modified the VPNserver to handle the remote attestation protocol and applied the static tool to aVPN client to define its profile that is used by the A-VM to monitor its run-time

92 F. Baiardi et al.Table 1. Example of Attestation Responsesuspicious89892345192.168.1.1timeout200004TPM-Boot7844e409c39fad83bb65f7dac4c8a53etrustedTPM.Measureboot07844e409c39fad83bb65f7dac4c8a53etrustedkernel.structidt_table.................780000e409c39fad83bb65f7dac4c8a53etrustedwrongprocessmodprobebehaviour. In the second case, a browser accessed a simple web-server which hasbeen extended to exploit the attestation module.Java SSL libraries and TPM/J [28] has been used to access the TPM values.Moreover, Java SSL libraries have been used to create the secure connectionsand to define the services of interest, i.e. the client interaction either to create aVPN connection or to send a HTTP request to REM-S. Finally, OpenVPN andthe web-server have been extended with plugins to enable remote attestation.4.1 Attestation ModuleThe attestation module on the REM-S is at the core of the attestation protocol,and it is used to initialise the protocol and to exchange messages between theREM-S and the A-VM. The protocol is triggered each time a C-VM requires theREM-S to open a connection, such as a VPN to the remote network or a HTTPrequest to a web-server in the considered examples. Before allowing the client to

Measuring Semantic Integrity for Remote Attestation 93connect, the REM-S exploits the attestation module, which is a daemon servicewaiting for input to start the handshaking phase. In the VPN connection, thismodule is an OpenVPN plugin that starts up the daemon as soon as it receives arequest through the function ConnectionRequest(IPClient). The attestationmodule, once activated, maps the IP address of the requesting C-VM into theIP address of the corresponding A-VM, and it opens a connection to it.The handshaking among the REM-S and the A-VM includes the mutual authenticationand the exchange of the initial protocol parameters. If the handshakeis successfully completed, the A-VM applies the initial set of measurementsto the C-VM and sends to the REM-S a message including the results of thechecks and the hashes computed by the TrustedBoot. The message is signed withthe private key of the A-VM to prevent manipulation of the results. To attestthe A-VM integrity and discover the current C-VM configuration, the attestationmodule on the REM-S compares the results against those in the database anddefines an initial security level. This level is communicated to the A-VM thatstores it in its database and it applies the monitoring according to the adoptedsecurity policy.The attestation module can apply one of two policies, based on a XMLencodedpolicy (see Tab. 1 for an example of an attestation response from theA-VM): (i) on-demand or (ii) timeout-based. In an on-demand policy, the REM-S can request specific measurements to the A-VM, such as semantic checks on arunning process, as long as the C-VM and the REM-S are connected. Instead, ina timeout-based policy, the A-VM periodically applies a set of checks and sendsto the REM-S the corresponding results.A-VM / REM-S Interactions. Currently, the protocol between the A-VMand the REM-S includes the following steps (see Fig. 2):1. ConnectionRequest(username, password):– open a connection from the C-VM to the REM-S;– check user’s credentials;2. ConnectionRequest(Username, IP); the Attestation module is activated;3. if in the previous step the client is authenticated, then the attestation moduleuses Retrieve(A-VM Information, C-VM IP) to query the database;4. the attestation module queries its database to retrieve the IP address ofA-VM though the Response(A-VM IP) function;5. OpenConnection(A-VM IP): the attestation module establishes a controlchannel with the A-VM;6. [sign A-VMKey] AttestationHandshake(Ip REM-S, nonce): the attestationmodule sends the handshake message with some parameters, signedwith the public key of the A-VM;7. [sign REM-SKey]AttestationResponse(ResultsChain({ProcIDs = results},{KernelStructures=results}, {TPM measures}), nonce): theA-VM computes hash values of the running applications and the A-VMcompares these results against those in its database. It sends the result toREM-S chained with the measurements of the underlying system done bythe TPM;

94 F. Baiardi et al.Fig. 2. Attestation Protocol Overview8. Check-Results: the attestation module compares each result sent by theA-VM against the expected one;9. the attestation module sends the current assurance policy and level to theA-VM;10. [sign A-VMKey]setAssurancePolicy(level, policy): the REM-S sendsto the A-VM an XML configuration file storing the security policy that the A-VM should apply, e.g.: (AssuranceLevel = 1, timeout). The parametersof this function are:– level: the required assurance level, i.e. an ID paired with a set of controlsstored in the A-VM database;– policy: The field policy can have the value timeout or on-demand,depending on whether the checks need to be applied for each elapsedtimeout or on-demand by the REM-S.11. Authorization(Message, [timeoutSession]): the REM-S opens or closesthe connection with C-VM and it may set a timeout session (the fieldmessage is the response, e.g. HTTP:403). In case of “on-demand” policy,the A-VM may cache the next requests to apply the same checks in future.Moreover, if the policy is “timeout”, the A-VM caches the timeout withthe paired assurance level. When the timeout is elapsed, it applies the set ofmeasurements associated to that level and it sends the results to the REM-S.

Measuring Semantic Integrity for Remote Attestation 95Fig. 3. C-VM: Transparent SolutionA-VM / C-VM Interactions. By exploiting the same introspection library,we have defined two distinct C-VM architectures whose names describe the kindof introspection applied on the monitored machine. In the “transparent” architecture(see Fig. 3), the monitoring is fully transparent to the C-VM and theinteractions between the components are those described in the previous section.In this case, the C-VM cannot run any software that VIMS can use to establishthe integrity of the C-VM. Instead, the “not-transparent” architecture (seeFig. 4), increases the amount of information that VIMS can access to measurethe integrity of the C-VM at the cost of transparency. This solution embedsfurther functions in the introspection library to verify the integrity of the C-VMand it increases the interactions between the A-VM and the C-VM. An exampleis the one where the C-VM runs a collector that retrieves information from localIDSes, firewall, anti-virus and sends alerts to a director on the A-VM. In thiscase, some steps of the protocol between A-VM and REM-S have been modified:– OpenConnection(A-VM IP): the REM-S requires the A-VM to open a controlchannel;– the assurance module accepts requests of:• remote attestation from the REM-S (if the security policy is “on-demand”);• alerts from the director.– the requests can be:• [sign A-VMKey]AttestationRequest(assuranceLevel, policy,nonce): remote attestation requests from the REM-S. This case is thesame that in the transparent solution;• Alert(alarmCode): it happens when director sends an alert;• ActivateMeasures(getMeasures(alarmCode)): the assurance module,according to the code sent by the director, requires the A-VM to applyfurther consistency checks;

96 F. Baiardi et al.• an elapsed timeout that triggers security checks on those componentslisted in the policy database: the A-VM applies the measurements correspondingto the adopted assurance level and it returns to the REM-Sthe hashes or semantic results for each measured object.– finally, REM-S closes the connection with the A-VM and the C-VM.Fig. 4. C-VM: Not Transparent Solution5 Performance ResultsThis section shows a preliminary performance evaluation of the current VIMSprototype. According to this preliminary evaluation, the overhead of the protocolfor remote attesting the C-VM is acceptable and almost negligible anytime theA-VM only compares the computed hashes against those in its database.Figure 5(a) shows the overhead of the IOzone [29] benchmark when the attestationrequires some introspection checks with respect to the case where thesechecks are not applied. Timeout is the length of interval in-between two consecutivemeasurements, i.e. two computations of the hashes of interest. The correspondingperformance degradation is fairly low.Figure 5(b) shows the overhead computed by IOzone on the REM-S when 3clients establish a VPN connection to the REM-S. As in the previous case, thelatency of the network masks the attestation protocol overhead.Figure 6(a) and 6(b) show the performance results of a set of tests on thesimple web-server handling a set of request to a login page using HTTP. In thesetests, the httperf benchmark tool [30] has been used to measure the web-serverperformance under stress when opening a number of HTTP connections rangingfrom 20 to 200, where each connection transmits 10 requests. The figures showthat the response time increases significantly when attestation is applied andthe REM-S load decades after about 1600 connection per sec.

Measuring Semantic Integrity for Remote Attestation 97(a)(b)Fig. 5. Average Client Attestation Overhead(a) and VPN Server Attestation Overhead(b)We also evaluated the overhead due to the semantic integrity checks enforcedby the A-VM on the kernel code and on the software running inside the C-VM.To this purpose, the C-VM ran the VPN client while the A-VM checked thememory pages that store kernel and application code by computing their hashesand comparing them against the values in the database. Furthermore, the A-VMalso monitors the system call sequence issued by the VPN client. The period oftime in-between two consecutive hash computations was set to 2 seconds. Therelative overhead was less than 15% in the worst case.6 Future Works and ConclusionsA secure handling of critical information requires the continuous monitoring ofthe integrity of the systems that try to access such information. This, in turn,requires that these systems are highly reliable and resilient against attacks byunauthorised remote users or by malware software. In some cases, a controlsystem can be delegated to apply integrity checks on another one, to verify thatit satisfies some predefined security requirements.In this paper we have described Virtual machine Integrity Measurement System(VIMS), an architecture to enable a network to evaluate and gain some

98 F. Baiardi et al.(a)(b)Fig. 6. Httperf Results with Attestation (a) and Without (b)assurance about the integrity of a remote party that is willing to join the network.As an example, this happens when remote nodes wish to access a corporateVPN or when a browser is requiring resources to a web-server using HTTP.To this purpose, VIMS exploits virtualization and introspection to verify theintegrity of the software components that the remote client is running and toattest it to the server that interfaces the network. Virtualization allows the clientsystem to run a shadow VM that applies the integrity checks in a transparentway to the VM that is trying to join the private network. The adoption of VIMSmay enable network administrators to protect private resources by remote systemsthat are trying to join the Intranet and that may be affected by spy-ware,rootkits that may infect critical resources.An area of future research considers the exploitation of an USB dongle asa secure root-of-trust of the VMM and the A-VM to increase the portabilityof this architecture to those contexts where the adoption of a TPM chip givesrise to privacy concerns. Finally, VIMS can be extended with the descriptionand implementation of a more granular user-based security policy to define theoperations that remote users can invoke.

Measuring Semantic Integrity for Remote Attestation 99References1. Cabuk, S., Dalton, C.I., Ramasamy, H., Schunter, M.: Towards automated provisioningof secure virtualized networks. In: CCS 2007: Proceedings of the 14thACM conference on Computer and communications security, pp. 235–245. ACM,New York (2007)2. Griffin, J., Jaeger, T., Perez, R., Sailer, R., van Doorn, L., Caceres, R.: Trusted VirtualDomains: Toward secure distributed services. In: Proc. of 1st IEEE Workshopon Hot Topics in System Dependability (HotDep) (2005)3. Garfinkel, T., Pfaff, B., Chow, J., Rosenblum, M., Boneh, D.: Terra: A virtualmachine-based platform for trusted computing. In: Proceedings of the 19th Symposiumon Operating System Principles(SOSP 2003) (October 2003)4. Sailer, R., Zhang, X., Jaeger, T.: Design and implementation of a TCG-basedintegrity measurement architecture. In: Proceedings of the 13th conference onUSENIX Security Symposium, pp. 223–238 (2004)5. Kyle, D., Brustoloni, J.C.: Uclinux: a linux security module for trusted-computingbasedusage controls enforcement. In: STC 2007: Proceedings of the 2007 ACMworkshop on Scalable trusted computing, pp. 63–70. ACM, New York (2007)6. Jansen, B., Ramasamy, H., Schunter, M.: Policy enforcement and compliance proofsfor Xen virtual machines. In: Proceedings of the fourth ACM SIGPLAN/SIGOPSinternational conference on Virtual execution environments, pp. 101–110 (2008)7. Sailer, R., Jaeger, T., Zhang, X., van Doorn, L.: Attestation-based policy enforcementfor remote access. In: CCS 2004: Proceedings of the 11th ACM conferenceon Computer and communications security, pp. 308–317. ACM, New York (2004)8. Seshadri, A., Luk, M., Shi, E., Perrig, A., van Doorn, L., Khosla, P.: Pioneer: verifyingcode integrity and enforcing untampered code execution on legacy systems. In:SOSP 2005: Proceedings of the twentieth ACM symposium on Operating systemsprinciples, pp. 1–16. ACM, New York (2005)9. Sadeghi, A.R., Stüble, C.: Property-based attestation for computing platforms:caring about properties, not mechanisms. In: NSPW 2004: Proceedings of the 2004workshop on New security paradigms, pp. 67–77. ACM, New York (2004)10. Chen, L., Landfermann, R., Löhr, H., Rohe, M., Sadeghi, A., Stüble, C.: A protocolfor property-based attestation. In: Proceedings of the first ACM workshop onScalable trusted computing, pp. 7–16. ACM, New York (2006)11. Poritz, J., Schunter, M., Van Herreweghen, E., Waidner, M.: Property attestation:scalable and privacy-friendly security assessment of peer computers. Research ReportRZ3548, IBM Corporation (May 2004)12. Petroni Jr., N., Fraser, T., Walters, A., Arbaugh, W.: An Architecture forSpecification-Based Detection of Semantic Integrity Violations in Kernel DynamicData. In: Proc. of the 15th USENIX Security Symposium (2006)13. Haldar, V., Chandra, D., Franz, M.: Semantic remote attestation: a virtual machinedirected approach to trusted computing. In: VM 2004: Proceedings of the 3rdconference on Virtual Machine Research And Technology Symposium, Berkeley,CA, USA, p. 3. USENIX Association (2004)14. Jaeger, T., Sailer, R., Shankar, U.: PRIMA: policy-reduced integrity measurementarchitecture. In: Proceedings of the eleventh ACM symposium on Access controlmodels and technologies, pp. 19–28. ACM, New York (2006)15. Pearson, S.: Trusted Computing Platforms, the Next Security Solution. Beaverton.Trusted Computing Group Administration, USA (2002)

100 F. Baiardi et al.16. Loscocco, P.A., Wilson, P.W., Pendergrass, J.A., McDonell, C.D.: Linux kernelintegrity measurement using contextual inspection. In: STC 2007: Proceedings ofthe 2007 ACM workshop on Scalable trusted computing, pp. 21–29. ACM, NewYork (2007)17. Bajikar, S.: Trusted Platform Module (TPM) based Security on Notebook PCs-White Paper. Mobile Platforms Group, Intel Corporation (June 20, 2002)18. Intel: Trusted Execution Technology,http://www.intel.com/technology/security19. Berger, S., Cáceres, R., Goldman, K.A., Perez, R., Sailer, R., van Doorn, L.:vtpm: virtualizing the trusted platform module. In: USENIX-SS’06: Proceedingsof the 15th conference on USENIX Security Symposium, Berkeley, CA, USA, p.21. USENIX Association (2006)20. England, P., Loeser, J.: Para-Virtualized TPM Sharing. In: Lipp, P., Sadeghi, A.-R., Koch, K.-M. (eds.) Trust 2008. LNCS, vol. 4968, pp. 119–132. Springer, Heidelberg(2008)21. Dunlap, G., King, S., Cinar, S., Basrai, M., Chen, P.: ReVirt: enabling intrusionanalysis through virtual-machine logging and replay. ACM SIGOPS OperatingSystems Review 36, 211–224 (2002)22. Garfinkel, T., Rosenblum, M.: A virtual machine introspection based architecturefor intrusion detection. In: Proc. Network and Distributed Systems Security Symposium(February 2003)23. SourceForge.net: Trusted Boot, http://sourceforge.net/projects/tboot24. Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Pratt, I., Warfield, A.,Barham, P., Neugebauer, R.: Xen and the art of virtualization. In: Proceedings ofthe ACM Symposium on Operating Systems Principles (October 2003)25. Sgandurra, D., Baiardi, F., Maggiari, D., Tamberi, F.: Transparent Process Monitoringin a Virtual Environment. In: Proceedings of the Third International Workshopon Views On Designing Complex Architectures (VODCA 2008), Bertinoro.ENTCS, Elsevier ScienceDirect (to appear) (2008)26. Tamberi, F., Maggiari, D., Sgandurra, D., Baiardi, F.: Semantics-Driven Introspectionin a Virtual Environment. In: Proceedings of the Fourth InternationalConference on Information Assurance and Security (IAS 2008), pp. 299–302 (2008)27. OpenVPN: An Open Source SSL VPN Solution, http://openvpn.net/28. TPM/J: Java-based API for the Trusted Platform Module (TPM),http://projects.csail.mit.edu/tc/tpmj/29. IOzone: Filesystem Benchmark, http://www.iozone.org/30. Mosberger, D., Jin, T.: httperf: a tool for measuring web server performance. ACMSIGMETRICS Performance Evaluation Review 26(3), 31–37 (1998)

A PrivacyCA for Anonymity and TrustMartin Pirker, Ronald Toegl, Daniel Hein, and Peter DannerInstitute for Applied Information Processing and Communications (IAIK),Graz University of Technology, Inffeldgasse 16a, A–8010 Graz, Austria{mpirker,rtoegl,dhein,pdanner}@iaik.tugraz.atAbstract. Trusted Computing (TC) as envisioned by the Trusted ComputingGroup promises a solution to the problem of establishing a trustrelationship between otherwise unrelated platforms. In order to achievethis goal the platform has to be equipped with a Trusted Platform Module(TPM), which is true for millions of contemporary personal computers.The TPM provides solutions for measuring the state of a platformand reporting it in an authentic way to another entity. The same cryptographicmeans that ensure the authenticity also allow unique identificationof the platform and therefore pose a privacy problem. To circumventthis problem the TCG proposed a trusted third party, the Privacy CertificationAuthority (PrivacyCA).Unfortunately, currently no PrivacyCA is generally available. In thispaper we introduce our freely available implementation of a PrivacyCA.In addition, our PrivacyCA is itself a trusted service. It is capable of reportingits state to clients. Furthermore, we use a novel way to minimizethe Trusted Computing Base of Java-based applications in conjunctionwith hardware-supported virtualization. We automatically generate theservice interface from a structural specification. Thus, to the best of ourknowledge, we were not only first to make this crucial service publiclyavailable, but now also provide a trustworthy service whose privacy policycan be attested to its users by employing TC mechanisms.Keywords: Trusted Computing, Privacy, PKI, Virtualization, Java,Trusted Computing Base.1 IntroductionToday’s computing landscape is plagued by a variety of software-based attacksand threats such as viruses, phishing attacks, and trojan horses. It is increasinglydifficult to find suitable countermeasures in this hostile environment. Therecent rise of the concept of Trusted Computing introduces a way to improve thesecurity of current computer systems. The Trusted Computing Group (TCG)specified the Trusted Platform Module (TPM), which allows to provide cryptographicallyqualified and tamper-resilient statements on the software configurationof a machine.However, the use of protected cryptographic mechanisms alone is not sufficientto convince remote machines or human users that a complex software service canL. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 101–119, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

102 M. Pirker et al.actually be trusted. To enable a decision based on the statements made by a TPMand the associated trust levels, keys need to be vouched for. This necessitatesa Public Key Infrastructure (PKI). The full potential of this approach becomesapparent on the Internet, as it allows a remote, independent party to decide onthe trustworthiness of a host or a particular service.A particular incarnation of the PKI concept is the PrivacyCA, whichservesto protect the privacy of the user in a trust-enabled networked environment. Itconfirms that keys are protected by a specification-compliant TPM implementationand thus may be trusted under certain conditions – but without revealingthe specific identity of the TPM and the user.It is an important aspect, that a PrivacyCA requires knowledge of private informationof a computer’s configuration. Therefore it must be trusted. However,until now, no architecture or implementation has considered this requirement.We describe the architecture of a PrivacyCA service, which is designed to betrusted. It not only provides privacy but is also able to attest its integrity andbehavioral policy. To overcome the complexity of deciding on the trustworthinesswe minimize the TCB of this Java-based service. Our approach allows forversatile application scenarios and also integrates well with other services on virtualizedplatforms. The reference implementations we present provide the firstactually operational instance of a PKI for Trusted Computing.Outline. The remainder of the paper is organized as follows: Section 2 gives ashort introduction to Trusted Computing mechanisms and motivates the need fora trusted third party PrivacyCA service in this environment. It also discussesa set of guidelines to follow so the trustworthiness of such a service can beachieved in practice. In Section 3 we outline the most important components andprocesses of a Trusted Computing supporting public key infrastructure. Puttingtheory to practice, Section 4 presents the practical implementation experienceof a PrivacyCA service and the optimizations employed. Section 5 discussespotential use cases. The paper considers related work in Section 6 and concludesin Section 7.2 Background2.1 Trusted Computing PlatformsThe Trusted Computing Group (TCG) [27] has defined a set of specifications toevolve current computer architectures into Trusted Platforms. The TCG does notclaim that a Trusted Platform guarantees perfect security under all conditionsand for all possible applications, but rather considers a system trustworthy if itbehaves in the expected manner for the intended purpose.To provide a hardware anchor for trust, the Trusted Computing Group hasspecified the Trusted Platform Module [31]. Similar to a Smart Card, the TPMfeatures cryptographic primitives, but is physically bound to a specific platform.A tamper-resilient casing contains hardware implementations of cryptographic

A PrivacyCA for Anonymity and Trust 103operations for public-key cryptography, key generation, hashing, and randomnumbergeneration. With these components the TPM is able to enforce securitypolicies on cryptographic keys, such as the Endorsement Key (EK) which providesit with a unique identity.The TCG not only specifies TPM hardware but also defines an accompanyingsoftware infrastructure called the TCG Software Stack (TSS) [30]. The stackconsists of different modules. Applications can access Trusted Computing functionalityby using the Trusted Service Provider (TSP) interface. The TrustedCore Services (TCS) are implemented as a single system service. Among themain functionalities implemented in the TCS are key management, key cachemanagement, TPM command generation and synchronisation. The TCS communicateswith the TPM via the TSS Device Driver Library (TDDL).A system configuration and therefore the system’s behavior is defined by thesoftware it executes. We consider the sum of all the software required by aspecific service to form its Trusted Computing Base (TCB). For a typical servicethis includes a hypervisor, an operating system, and possibly a language-basedvirtual machine that executes the service. On a trusted platform, this is reflectedin the chain-of-trust which is unique for each specific service. Here, each softwarecomponent is measured before it is given control to, starting with the CoreRoot-Of-Trust for Measurement (CRTM), typically the BIOS. This process alsocovers boot loader, kernel, libraries, binary and interpreted application code and,following the transitive trust model, leads to a continuous chain of evidence.To prevent tampering with the platform measurements the TPM stores themin a set of Platform Configuration Registers (PCRs). Thus, a report on the PCRstate reflects the exact state of a system. Presented with such a report an externalstakeholder can form an informed opinion about a system’s trustworthiness. Thiscentral concept of a TC-enabled platform is known as Remote Attestation. Theauthenticity and integrity of this report must be preserved even if the TCB iscompromised or the network channel is insecure. To this end, the TPM actsas Core Root-Of-Trust for Reporting (CRTR). Upon request, it performs theTPM Quote operation which signs the PCR state with a TPM hosted signingcapablekey.This specific keys are referred to as Attestation Identity Keys (AIKs). TheTCG specification guarantees that these keys never leave the protection of astandard-compliant TPM. To ensure that the signature on an attestation reportis actually made by a TPM-protected AIK, the used key must be vouched forwithin the framework of a PKI. Another use for AIKs is to certify the policiesof other key types.2.2 PrivacyCAThe TCG remote attestation architecture requires that an attestant sends a verydetailed description of its system state to an attester. This raises the questionof privacy protection. For one thing this information might be used to facilitateattacks. Another problem is that reusing the same key for all reporting operationsallows to trace the TPM and thus the platform. In some scenarios that might be

104 M. Pirker et al.Fig. 1. Overview of AIK creation, certification and usage with a PrivacyCA. Steps 5-9can take place at a later time and may be repeated.a desirable feature, but typical end users should value their privacy. Therefore itis of interest, that access of independent external services cannot be correlated(i.e. to create a behavioral or marketing profile of an user).Hence, the TCG specifications [28] define the PrivacyCA service to protectthe privacy of the users. Its task is to issue AIK certificates, which guarantee thata given AIK is owned and secured by a TPM that enforces the TCG-specifiedpolicies for AIKs. It is crucial that the issued AIK certificates do not containany kind of link to the identity of the specific TPM. By employing more thanone AIK per TPM it becomes possible to mask the identity of the users.A general overview of the life cycle of an AIK and its practical applicationin a remote attestation scenario is provided in Figure 1. At first, a RSA key isgenerated within the protection of the TPM. In order to obtain an AIK certificatefor it, the trusted platform and the PrivacyCA execute a cryptographicallysecured protocol. A request package describing the AIK and a set of platformspecific certificates is transmitted. The PrivacyCA checks the information. If therequest conforms to the CA policy, an AIK certificate is returned. It is encryptedso that only the TPM indicated in the request can extract it. Now the AIK keycan be used, whenever an attester requests the attestation of the trusted platform.Then the system state description, which is signed with the private part ofthe AIK and the AIK certificate are provided. The Attester can now verify thecorrectness of the signature after confirming the validity of the certificate withthe help of the PrivacyCA’s revocation service.The mode of operation of a specific PrivacyCA is regulated by its policy, whichdefines two important properties: Who is allowed to acquire an AIK and howmuch information about the AIK request and the issued certificates is retained?In a restricted deployment scenario for example, the PrivacyCA issues andvalidates AIK certificates only for well-known clients. This requires an initial registrationstep. In this case it might make sense to store all information acquired

A PrivacyCA for Anonymity and Trust 105during an AIK cycle. In open scenarios, where the PrivacyCA issues certificatesto a large set of customers that are not necessarily known beforehand a moreliberal policy might be required. The policy options for a PrivacyCA range from”record nothing” over ”know enough for the specific operation, forget detailsafter its completion” to ”store and log everything”. The choice of PrivacyCAand privacy policy and consequently the intended level of privacy should be leftto the end-user.In conclusion, a PrivacyCA takes the role of a trusted third party. It mustbe trusted by both parties in the remote attestation process. More specifically,the attestant must be ensured that his privacy is protected in accordance to aspecific policy, whereas the attester must be assured that a remote attestationreport is indeed issued by a TPM.2.3 Guidelines for Building a Trustworthy ServiceIn the Trusted Computing scenario envisioned by the TCG, services like a PrivacyCAtake the role of a trusted third party. Ideally such a service should beprovable secure. Of course, its trustworthiness not solely depends on its design,but also on its practical implementation as well. This includes the trustworthinessof the TCB it is executed on. Regrettably, the downright complexity of theoverall system renders a fully formally verified approach infeasible with today’stechnology.Still, by following a pragmatic combination of currently available technologiesand practices, a high level of trust can be achieved. We now summarizea comprehensive set of simple, heuristically determined and generally acceptedguidelines.Guideline 1. Apply Virtualization.Virtualization support allows the execution of several virtual machines in parallelon the same computer. A hypervisor or Virtual Machine Monitor (VMM)manages the compartments 1 and enforces their separation. The application ofvirtualization in a TC context is not a new notion [10]. It allows to isolatetrusted services in compartment of their own, which helps restricting a possiblesubversion to a small part of the overall system.Guideline 2. Restrict the Trusted Computing Base to a minimum.Today’s platforms are versatile. In regard to the trustworthiness of the platformthis is a drawback. Every service with an external interface provides a point ofattack. It is therefore sensible to deactivate every service and component thatis not strictly necessary for the execution of the trusted service. We proposean even stricter approach: Remove every superfluous component. The rational isthat even if a component does not provide a point of attack it may make securityanalysis and inspection of the overall system more complex.1 Note that such hardware-emulating compartments are often called “Virtual Machines”.In this paper we use the term exclusively for the language-based Java VirtualMachine.

106 M. Pirker et al.Guideline 3. Use formal methods to proof the security of the service interface.A formal verification of the security of the complete TCB would be desirable.However, the level of complexity of contemporary software architecturesis formidable. Yet, the main point of attack of a service is its network protocolinterface, which limits the scope. Thus, we suggest to use formal and automatedmechanisms for interface specification, analysis [16] and implementation.Guideline 4. Use a safe programming language.The programming language a service is written in has a paramount influenceon the security properties of the service. A language that allows direct memoryaccess through the use of pointers, or does not automatically perform rangechecking is inherently more unsafe than a language that does [9]. While it is possibleto create safe programs in a wide variety of languages, there is a noticeabledifference in the complexity and error-proneness to do so.Guideline 5. The source code of the service should be available to the publicfor inspection.Kerckhoff stated [14] that the security of a cryptographic system should solelyrely on the secrecy of the key. The rest of the system should be open for inspection.We propose to apply a similar principle to trusted computing. Publiclyavailable source code does not only increase the trust in a service, but in additionadds all the other advantages of public review and criticism to the development.For the same reason a trusted service should be deployed on a platform that iscomposed of other mature open source components.Guideline 6. Use Trusted Computing.Ensuring trustworthiness is a two-way process [23]. A client should be able totrust a service and vice versa. Trusted Computing helps to achieve this goal bymeasuring the platform and employing remote attestation. As mentioned abovea trustworthy service should use these tools and the TPM-based capabilitiesavailable on modern platforms.3 Trusted Computing PKI PrimitivesIn the following sections we outline the TCG specified components and proceduresthat facilitate the creation of a PKI service. We will discuss specific keys,certificates and protocols and their intended role. In this discussion, we onlyconsider the elements relevant to the PrivacyCA concept.Security credentials in general may be represented in different formats. Thecredential standard document of the TCG [33] describes credentials in the concreteinstantiation of either X.509 certificates [13] or attribute certificates [8].Additionally, some TPM functions produce binary blocks of data the internalstructures of which do not conform to any standard.

3.1 Endorsement Key and EK CertificateA PrivacyCA for Anonymity and Trust 107Every TPM hosts a unique Endorsement Key (EK). The asymmetric key pair isstored in non-volatile memory inside the TPM. It is impossible to retrieve theprivate part of the key. A corresponding TPM Endorsement certificate containsthe public part of the key pair. This certificate represents an assertion that acertain TPM conforms with the TCG specifications and that the private EndorsementKey is indeed protected by the TPM. The Endorsement certificate issigned by the entity which created and inserted the EK.As the Endorsement Key uniquely identifies a TPM and hence a specific platform,the privacy of the platform user or users might be at risk if the EK isemployed for remote attestation operations. As a consequence, the TCG rigorouslyrestricted the set of operations that can be performed with the EK. Forinstance it is used during the taking of ownership of the TPM by the user. Notablyit cannot be used to sign PCR values or arbitrary data. This policy isenforced by the TPM.3.2 Platform CertificateA system manufacturer vouches for the components of a platform (except theTPM) with a Platform Endorsement (PE) credential. It represents an assertionthat the specific platform incorporates a properly certified TPM and the necessarysupport components. A PE states that the platform architecture conforms toTCG specifications. A reference to the specific TPM on the platform is included.3.3 Conformance CertificateA platform Conformance Credential (CC) attests that the overall design of aplatform satisfies the TCG specifications. It asserts the proper design of theTrusted Computing subsystem and its correct integration into the platform. TheCC is described in [29], but was not updated in the newer [33] TCG specifications.The newer specification focuses on the EK, PE and AIK (see next section)credentials alone. Thus, for the scope of this paper, we consider its status obsoleteand do not consider it further.3.4 Attestation Identity Key and AIK CertificateAs an alternative to the unique and privacy sensitive EK, the TCG introducedAttestation Identity Keys (AIKs) and the associated AIK certificates. AIK certificatesdo not contain any information that links the certificates to the specificplatform hosting the AIKs. The AIK certificates assure that the identity keysare indeed TPM hosted.AIK protocol. In order to create an AIK certificate, the trusted client platformwith a TPM and the PrivacyCA service execute a cryptographic protocol.The TCG specified the TPM interaction and the PrivacyCA actions, but did

108 M. Pirker et al.not stipulate a transmission protocol for the exchange of the request and responsepackets. The flow of an AIK creation is illustrated in Figure 2. The stepsperformed are as follows 21. A client application, running on a machine equipped with a TPM, invokesthe Tspi TPM CollateIdentityRequest TSS function to initiate a new AIKcreation.2. The TSS invokes the TPM MakeIdentity TPM function to create a newattestation-identity RSA-key-pair (AIK). The TPM returns a structure containingthe public AIK, signed with the private AIK key.3. The TSS assembles the request to the PrivacyCA into a structure containing- amongst other information - the signed blob returned by the TPM and theEK and PE certificates of the platform. This request is encrypted with thepublic key of the PrivacyCA PCA Pub , which must be known to the clientbeforehand.4. The request is forwarded to the PrivacyCA. The PrivacyCA decrypts therequest and validates its content. In doing so, it also validates the certificatescontained by the request.5. On successful validation the PrivacyCA issues an AIK certificate, encryptedwith a symmetric key. The symmetric key along with a hash of the publicAIK is in turn encrypted with the public key of the EK of the TPM EK Pub(obtained from the EK certificate in the request). This assures that the resultpackage can only be decrypted by the intended recipient TPM. The resultis transported back to the client system.6. The client application calls the TSS Tspi TPM ActivateIdentity functionwith the response from the PrivacyCA. The TSS subsequently requests theplatforms TPM to decrypt the response package with the private part of theEK. If the referenced AIK is available on the TPM, the symmetric key isreturned.7. On successful completion of this protocol, the returned key is used to decryptthe response from the PCA containing the AIK certificate.An activated AIK is a pair of an TPM identity key and the associated certificateissued by a third party PrivacyCA service. The AIK certificate attests that thekey pair is bound to a TPM. It contains information fragments from both lowerlevel certificates, EK and PE, to identify the TPM and platform model, butdoes not contain enough unique information to allow pinpointing to the specificphysical hardware.Additionally, an AIK certificate contains a client chosen arbitrary label stringwhich allows for later recognition in a set of AIK certificates. Well defined labelstrings support the user of the platform in associating a key to a specific task,while they do not allow other parties to guess the identity of the platform andhence the user. This label is a specific TCG certificate extension and must notbe confused with standard certificate naming fields.2 Note that some details are omitted for clarity of presentation. For a complete descriptionplease refer to the TCG specifications [28], [30] and [31].

A PrivacyCA for Anonymity and Trust 109ClientCollate Identity Request⏐↓PrivacyCATSS: setup data structures⏐Make Identity ↓TPM: create new RSAidentity key pair, signpublic part with privateAIK Pub ,S AIKpriv (AIK Pub )⏐↓TSS: build request,encrypt with PCA Pub−−−−−−→ decrypt+validate request⏐↓ SuccessTSS: request TPM todecrypt response with TPMEK PrivActivate Identity⏐↓←−−−−−−issue AIK cert,encrypt with TPM EK PubTPM: check for AIKSymmetric key⏐↓TSS: decrypt remains,obtain AIK certificateFig. 2. Overview of the AIK certification procedure with a PrivacyCA4 ImplementationsWe implement the core components of a trusted PrivacyCA service followingthe considerations outlined in the previous sections. Our PrivacyCA allows thecreation and validation of EK and AIK certificates and also provides a simple,yet sufficient API for certificate retrieval and revocation.We eschew the creation of a special purpose platform from scratch, insteadwe start out using a well maintained off-the-shelf operating system and maturelibrary components. We based our implementation on Java running on Linux.This is a pragmatic approach which offers a good balance of prototyping speed,maturity, features, invested effort and security. We expect this concept to beversatile and trustworthy enough for all but the most security critical intendedpurposes. In the next sections we describe the implementation choices we madefor each of the components in greater detail.

110 M. Pirker et al.4.1 TCcertAs outlined in Section 3, the TCG’s specification of the EK, PE and AIK certificatesrequires the definition of new types of certificate extensions for X.509type certificates [33] and attribute certificates [8].General purpose PKI tools currently do not support these extensions and weare not aware of any publicly available library that does. We present a Javalibrary called TCcert which enables us to create these certificates. This allowsus to provide the basic building blocks for a Trusted Computing PKI. The followingcredentials are currently supported by TCcert for certificate creation andvalidation– TPM Endorsement Key (EK) credential,– Platform Endorsement (PE) credential and– Attestation Identity Key (AIK) credential.4.2 A PrivacyCA Based on XMLInteraction of distinct entities connected by a network requires a common protocolunderstood by all participants. Several protocols exist that are alreadyemployed in PKIs and for credential management. For trusted computing a protocolshould be able to support common PKI services as well as TC specificattributes, queries and data structures. The TCG considered this infrastructureproblem in [32]. The two candidates mentioned are the CMC protocol [17] forX.509 certificates and the XKMS protocol [18] for XML-based credentials. TheXKMS option initially appeared attractive because its ability to wrap legacyCA services designed for X.509 certificates and express certificate managementin XML.Our first PrivacyCA implementation whichusesanXKMSbasedprotocolwas released at [19] in the middle of 2007. It proofs that it is possible to usean unmodified XKMS schema to encode the messages required by a TC enabledPKI. However, not all TC associated operations map to XKMS operations in astraightforward way. The AIK cycle uses pure binary data blobs and this propertyconflicts with the intention of using plain text XML structures. Furthermore,the proof of possession expected by certain PKI commands is not always feasiblewith TC keys. The TPM policy does not allow e.g. identity keys to signarbitrary externally supplied data, as this would allow to fabricate fake truststatements. Finally, the application of this solution to a deployment scenariodemonstrated that XML introduces an implementation overhead and externaldependencies that significantly increase the binary size of the TCB. Therefore,we discontinued this approach.4.3 An Efficient PrivacyCA ProtocolA PrivacyCA which offers a high level of trustworthiness requires a communicationprotocol that offers a complete set of PKI operations, but at the same

create_aik_request ="CREATE_AIK_REQUEST" "\n""Blob: " base64 >clsbuf %save_blob "\n"".\n"@do_create_aik_request;create_aik_response ="CREATE_AIK_RESPONSE" "\n""Blob1: " base64 >clsbuf %save_blob1 "\n""Blob2: " base64 >clsbuf %save_blob2 "\n"".\n"@do_create_aik_response;A PrivacyCA for Anonymity and Trust 111Fig. 3. Example of formal specification for the autogenerated parsertime allows for a small-sized implementation. Keeping the guidelines discussedin Section 2.3 in mind we set out to design and build a PrivacyCA prototype byemploying state-of-the-art techniques and technologies.Communication Protocol. For a compact and robust communication protocolwe devised a simple ASCII-text based solution. The basic structure of mostcommands is simply a command identifier followed by the data. Data items areline based, each line terminated by a new line character. The data type identifierand the actual data are separated by a colon followed by a space. Binary datapayload is transmitted as Base64 encoded strings.This is a very basic approach and thus not very prone to implementationerrors. The server side parser is constructed using the Ragel state machine compiler3 , resulting in mostly automatically generated parsing code. Ragel generatesexecutable finite state machines from a regular-expression like, formal descriptionof the expected valid input data stream. Furthermore, it allows to generatecode for multiple target languages, not only for Java, and thus we hope thisencourages development of clients in alternative languages.The following short example (cf. Figure 3) illustrates the specification of therequest and response of the aik create command which is used to generate theimplementation.Command Set. We implement a sufficient set of commands that enables ourimplementation to serve as a foundation for a trusted computing PKI. Thisalso includes commands for creating and validating EK certificates, which arecurrently missing for the majority of shipping TPMs. Other commands allowbasic tasks such as creation and revocation of AIK certificates.Our prototype of a PrivacyCA supports the following operations to enablethe identity keys concept of the TCG.ekcert create. This command creates a TPM endorsement certificate for agiven public key. To our knowledge currently only one vendor, Infineon,3 A. Thurston, Ragel State Machine Compiler, http://www.complang.org/ragel/

112 M. Pirker et al.supplies an EK for its TPMs. In order to support TPMs from other vendorsit is necessary to supply those TPMs with EK certificates, otherwise it isunreasonable to provide them with AIK certificates.ekcert validate. This function validates a TPM endorsement certificate. OurPrivacyCA recognizes certificates issued by Infineon and certificates issuedby our own ekcert create command.aik create. implements the AIK certificate creation cycle as specified by theTCG (see section 3.4). By default, all AIK certificates issued are saved in alocal storage.aik validate. provides a function to validate the AIK certificates issued by ourPrivacyCA. The certificate to be checked is submitted by the client and thePrivacyCA returns whether the given certificate is valid.aik locate. offers a search function for retrieval of a specific AIK certificate.The AIK label serves as the search key.aik revoke. Provides the revocation of individual certificates. The copy in thelocal storage is removed. Thus, the certificate is no longer available foraik locate.tcb quote. asks the PrivacyCA to quote itself. The PrivacyCA uses the TPMto perform a quote of the system state and returns it to the attester.Furthermore, a trusted-third-party service like our PrivacyCA should use anend-to-end secure connection for communication with its clients. The currentimplementation uses unprotected communication channels, however the servicecan be easily upgraded with Transport Layer Security (TLS). To establish anencrypted TLS-session, we propose to use a session key derived from the sameknown public PrivacyCA key, which is already necessary for the aik create command.4.4 A Reduced Compartment ImageTo facilitate the functional assessment and the security analysis of the serviceand its TCB, the code base should be as small as possible. Therefore, it shouldonly include components that are crucial for its operation. This extends to evenremoving unnecessary parts of said components. It would be tempting to intuitivelyargue that fewer Lines-of-Code generally equals less defects. However, wecaution that the vulnerability density is not always linear to size. Still, we believethat the overall reduction of code base complexity aids the goal of detecting andunderstanding security issues and furthers the goal of a trustworthy service andis thus worth exploration.Software Layers. The TCB of our PrivacyCA service, which is written inJava, can be grouped into the following layers: PrivacyCA service, JVM/JRE,OS runtime support, OS kernel and the TPM. The top layer is our Java PrivacyCAimplementation. In order for the Java bytecode to execute, a Java RuntimeEnvironment (JRE) with a Java Virtual Machine (JVM) is required. The JVMmakes use of the native environment to use system specific functions like graphics,printing and sound. The native environment is a set of high-level application

A PrivacyCA for Anonymity and Trust 113PrivacyCA applicationJVM/JREOS runtime supportOS kernelPlatform / TPMFig. 4. The Trusted Computing Base of the PrivacyCA service consists of several layerslibraries, the C/C++ standard libraries and operating system functions. Theoperating system kernel implements the low-level services.This full software stack is able to run directly on hardware as well as in avirtualized compartment, unaware of the surrounding virtualization layer. Weoptimized the TCB for the execution of our PrivacyCA service, by starting outwith an off-the-shelf configuration and then reducing the included functionalityin the respective layers to the absolute minimum. In addition, we employedfree-licensed open source components only.Java Environment. To provide the best possible Java compatibility and allowreuse of existing code we chose IcedTea 4 , which is based on Sun’s officialOpenJDK 5 . The actual subset of the Java environment which is necessary forthe PrivacyCA is small. Through the use of Java’s class loading profiling feature,we identified the crucial classes. The monitoring of the system dynamiclinker/loader ld.so produced a list of the necessary native libraries. To allowerror handling, the required set of Exception and Error were also added. Thisapproach reduces the Java runtime for a specific application to a more manageablesize in the range of 10 to 20MB. Note that this approach requiresmanual intervention and reasonable completeness is only achievable for smallapplications.We add cryptographic functionality using IAIK JCE 6 and TC support usingIAIK jTSS, a pure Java TSS [26].ASmallKernel.The minimal TCB guideline requires an OS which is smallin size, yet powerful enough to support the stripped down JVM. Of the opensource operating systems, GNU/Linux is widely used and actively maintainedby a large global community. It is a suitable environment to host IcedTea. Inaddition, the kernel build system allows a fine-grained selection of only thosecapabilities required by our application. Our configuration consists of essentialkernel functionality and a small set of drivers to enable execution directly onhardware or in a virtualized compartment environment (e.g. Xen).4 http://icedtea.classpath.org/5 http://openjdk.java.net/6 http://jce.iaik.tugraz.at/sic/products/core_crypto_toolkits/jca_jce

114 M. Pirker et al.Table 1. Overview of the size of the PrivacyCA software componentsLayer Component Size [kB]OS Kernel Linux Kernel 900OS Runtime BusyBox 750Baselayout-lite 61C Libraries libstdc++ 3545uClibc 1103GCC Runtime 42Java Core Stripped Icedtea JRE 8792Java Application PrivacyCA Server Core 200lib IAIK JCE 818lib IAIK jTSS 312lib TCcert 49A Minimal Runtime. The standard glibc system library uses about 20 to25 MB disk space on a typical installation. Additional system and shell toolsrequired for the boot process accumulate to over 3 MB. A component reducedboot process is implementable by employing the compact Busybox 7 toolkit. Itsupplies a minimal userland program environment. A minimal set of configurationfiles needed for starting and running a GNU/Linux system is provided bythe sys-apps/baselayout-lite package made available from the Embedded Gentooproject 8 . Furthermore, we chose the uClibc 9 as an alternative C library with adrastically reduced footprint.A Minimal PrivacyCA Compartment Prototype. The PrivacyCA servicebuilt from the above components is bundled into a single compartment image.Note that the privacy policy configuration is an intrinsic part of the image file.Thus it implicitly can be measured into the TPM at compartment startup. Acurrent snapshot and associated source code is available for download from [19].The size of the components in a current snapshot of our prototype are presentedin Table 1. The complete compartment has a total size of approximately17 Megabytes.5 Use CasesThe general availability of a small-sized, versatile PrivacyCA compartment enablesmultiple deployment scenarios for further research and gathering of practicalexperience. We describe multiple such scenarios, where our system architectureprovides added value over conventional service implementations.Scalability of PrivacyCAs. In a future Trusted Computing-enabled Internet aPrivacyCA potentially has to serve millions of users. A certain pressure to employ7 http://www.busybox.net/8 http://www.gentoo.org/proj/en/base/embedded/9 http://www.uclibc.org/

A PrivacyCA for Anonymity and Trust 115a multitude of certificates exists as the use of more AIKs per user increasesa users anonymity to service providers. This necessitates a powerful, scalablecertification authority infrastructure that is capable of issuing and validating agreat number of certificates.Scalability of a PrivacyCA service can be achieved through hosting manysmall PrivacyCA compartments. This is done by hosting a sufficient numberof compartments in parallel using virtualization technology on a set of servermachines. The preservation of a services’ trustworthiness is of crucial importance.The vision of such a Trusted Virtual Datacenter (TVDc) setting is an activearea of research, see e.g. [25] and [5]. We are optimistic that current TVDcrelated research results can be adapted to construct a massively scaled trustedPrivacyCA datacenter.Compact PrivacyCA Service for Restricted or Mobile Environments.As our PrivacyCA consists of open source components only, it is open to inspectionand analysis by the community. It is also compact and self-contained:once evaluated it is easy to show that any given instance has not been changedthrough TC attestation mechanisms. Furthermore, self-contained services areeasy to deploy, especially for in-house PrivacyCA services of organizations whichpresumably will precede Internet-wide use. The services’ compactness also allowsusage on performance restricted systems, such as trusted mobile phones [22].Trusted Core for Large Java Applications. To increase the security of applicationsin the Nizza virtualization architecture, [24] suggest to extract securitycritical modules out of legacy applications. Each of these modules is transferredinto a separate, trusted compartment called AppCore which features a smallTCB. We believe that our reduced Java environment is ideally suited to implementsimilar modifications for Java applications.6 Related WorkTo our knowledge the first experimental public PrivacyCA service 10 was put intooperation by us at IAIK in 2007. It served as a basis for the advanced versionpresented in this paper. In a seemingly private effort 11 another PrivacyCA wasstarted in 2008, but with limited functional scope. Zic and Nepal [35] presenteda scenario employing a prototype PrivacyCA service but to the best of ourknowledge this service has not been released.As an alternative to the trusted third party concept of a PrivacyCA, [6] proposesDirect Anonymous Attestation (DAA). TPM implementations are available,however the required software and service infrastructure has not yet beenprovided for. It remains a theoretical concept so far.TC-enabled hardware platforms [7] support hardware enforced virtualization.Generally, a hypervisor like the Xen [3] virtual machine monitor or the Fiasco/L410 http://opentc.iaik.tugraz.at/11 http://www.privacyca.com

116 M. Pirker et al.[12] µ-kernel, allows the creation, execution and hibernation of isolated compartments.Modern trusted platforms [10,20,15] could in the near future employ thesehardware features, given proper virtualization of the TPM [4,25,5,21].A significant body of research on Java virtual machines and using Java as anoperating system or a component thereof exists. Yet, Java is still evolving andthus older results may not reflect newer research developments or requirements.The results of [11], [34] or projects (SanOS 12 ) are currently not maintained.Also, mobile Java platforms such as Sun’s KVM 13 may be smaller, howevertheir feature set is restricted and not compatible with general Java applicationsor libraries. More recent efforts like JNode 14 or [1] do not consider small binarysize as a goal, thus resulting in a TCB that is too large for our purposes. The JavaKernel 15 project divides JRE libraries into separate bundles, which are laterfetched at runtime as required. Reliance on a full-featured Windows environmentintroduces additional overhead. Anderson et al. [2] created a small sized Xenlibrary OS running exclusively on top of the Xen hypervisor. Due to the lack ofbasic features it is not able to run a modern Java Runtime Environment such asOpenJDK.7 ConclusionThis paper describes the creation of a trustworthy PrivacyCA service. We presentand follow a set of guidelines that allow to achieve practical trustworthinesswith a novel combination of state-of-the-art methods. These methods includeformal yet compilable protocol specifications, the minimization of the TCB andthe utilization of hardware-supported virtualization. Foremost, our PrivacyCAservice lays the foundation for easy attestation of its state and consequently theprivacy policy it guarantees to its clients.The PrivacyCA is implemented as a self-contained image that can be executedstand-alone or by the Xen hypervisor. While the image is of minimal size, itcontains a bare-bone operating system and a Java Runtime Environment. Ourprocess can also be applied to support other services with a highly trustworthyenvironment. The PrivacyCA service protocol is partially auto-generated from aformal state-machine description. We outline several use-cases and incorporatethe results of operating an experimental public prototype setup.Future work will consider use cases in the context of distributed computingand advanced certification mechanisms for virtual TPMs. An integration of thenewest TCG credential type, a unified credential [33], may stimulate new workflows. We also desire to work on closing the gap between automatic generationof an implementation and the formal security analysis of network protocols andto apply this to future extended PrivacyCA interfaces.12 http://www.jbox.dk/sanos/13 http://java.sun.com/products/cldc/wp/KVMwp.pdf14 http://www.jnode.org/15 http://java.sun.com/javase/6/6u10faq.jsp

A PrivacyCA for Anonymity and Trust 117Acknowledgements. The authors thank the anonymous reviewers for theirinsightful comments and Andreas Niederl for assisting the implementations.The efforts at IAIK to integrate TC technology into the Java programminglanguage are part of the OpenTC project funded by the EU as part of FP-6,contract no. 027635. The project aims at providing an open source TC frameworkwith a special focus on the Linux operating system platform. Started as an opensource project the results can be inspected by everybody, thus adding towardsthe trustworthiness of Trusted Computing solutions.References1. Ammons, G., Appavoo, J., Butrico, M., Silva, D.D., Grove, D., Kawachiya, K.,Krieger, O., Rosenburg, B., Hensbergen, E.V., Wisniewski, R.W.: Libra: a libraryoperating system for a jvm in a virtualized execution environment. In: VEE 2007:Proceedings of the 3rd international conference on Virtual execution environments,pp. 44–54. ACM, New York (2007)2. Anderson, M.J., Moffie, M., Dalton, C.I.: Towards trustworthy virtualisation environments:Xen library os security service infrastructure. Technical Report HPL-2007-69, HP Research (2007)3. Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer,R., Pratt, I., Warfield, A.: Xen and the art of virtualization. In: SOSP 2003: Proceedingsof the nineteenth ACM symposium on Operating systems principles, pp.164–177. ACM, New York (2003)4. Berger, S., Cáceres, R., Goldman, K.A., Perez, R., Sailer, R., van Doorn, L.: vTPM:virtualizing the trusted platform module. In: USENIX-SS 2006: Proceedings of the15th conference on USENIX Security Symposium, pp. 305–320 (2006)5. Berger, S., Cáceres, R., Pendarakis, D., Sailer, R., Valdez, E., Perez, R., Schildhauer,W., Srinivasan, D.: TVDc: managing security in the trusted virtual datacenter.SIGOPS Oper. Syst. Rev. 42(1), 40–47 (2008)6. Brickell, E., Camenisch, J., Chen, L.: Direct anonymous attestation. In: CCS 2004:Proceedings of the 11th ACM conference on Computer and communications security,pp. 132–145. ACM, New York (2004)7. David Grawrock. The Intel Safer Computing Initiative. Intel Press (2006) ISBN0-9764832-6-28. Farrell, S., Housley, R.: An Internet Attribute Certificate Profile for Authorization(April 2002), http://www.ietf.org/rfc/rfc3281.txt9. Felleisen, M., Cartwright, R.: Safety as a metric. In: Proc. 12th Conference onSoftware Engineering Education and Training, pp. 129–131 (1999)10. Garfinkel, T., Pfaff, B., Chow, J., Rosenblum, M., Boneh, D.: Terra: a virtualmachine-based platform for trusted computing. In: SOSP 2003: Proceedings of thenineteenth ACM symposium on Operating systems principles, pp. 193–206. ACM,New York (2003)11. Golm, M., Felser, M., Wawersich, C., Kleinöder, J.: A Java operating system asthe foundation of a secure network operating system. Technical report tr-i4-02-05,Univ. of. Erlangen, Dept. of Comp. Science, Lehrstuhl 4 (2002)12. Hohmuth, M.: The Fiasco kernel: Requirements definition. Technical Report ISSN1430-211X, Dresden University of Technology (1998)

118 M. Pirker et al.13. Housley, R., Polk, W., Ford, W., Solo, D.: Internet X.509 Public Key InfrastructureCertificate and Certificate and CRL Profile (April 2002),http://www.ietf.org/rfc/rfc3280.txt14. Kerckhoffs, A.: La cryptographie militaire. Journal des sciences militaires IX (1883)15. Kuhlmann, D., Landfermann, R., Ramasamy, H.V., Schunter, M., Ramunno, G.,Vernizzi, D.: An open trusted computing architecture — secure virtual machinesenabling user-defined policy enforcement. Research Report RZ 3655, IBM Research(2006)16. Meadows, C.: Formal methods for cryptographic protocol analysis: emerging issuesand trends. IEEE Journal on Selected Areas in Communications 21(1), 44–54(2003)17. Myers, M., Liu, X., Schaad, J., Weinstein, J.: Certificate Management Messagesover CMS (April 2000), http://www.ietf.org/rfc/rfc2797.txt18. Mysore, S.H., Hallam-Baker, P.: XML key management specification (XKMS 2.0).W3C recommendation, W3C (June 2005),http://www.w3.org/TR/2005/REC-xkms2-20050628/19. Pirker, M., Toegl, R., Winkler, T., Vejda, T.: Trusted computing for theJava TM platform (2009), http://trustedjava.sourceforge.net/20. Sadeghi, A.-R., Stüble, C., Pohlmann, N.: European multilateral secure computingbase - open trusted computing for you and me. Datenschutz und Datensicherheit(DUD) (09/2004), pp. 548–554 (2004),http://www.trust.rub.de/media/publications/SaStPo2004Web.pdf21. Sadeghi, A.-R., Stüble, C., Winandy, M.: Property-based TPM virtualization. In:11th Information Security Conference (2008)22. Schmidt, A., Kuntze, N., Kasper, M.: On the deployment of mobile trusted modules.In: Wireless Communications and Networking Conference, 2008. WCNC 2008,pp. 3169–3174. IEEE, Los Alamitos (2008)23. Sheehy, J., Coker, G., Guttman, J., Loscocco, P., Herzog, A., Millen, J., Monk,L., Ramsdell, J., Sniffen, B.: Attestation: Evidence and trust. Technical Report 070186, MITRE Corporation (2007)24. Singaravelu, L., Pu, C., Härtig, H., Helmuth, C.: Reducing TCB complexity forsecurity-sensitive applications: three case studies. In: EuroSys 2006: Proceedingsof the ACM SIGOPS/EuroSys European Conference on Computer Systems 2006,pp. 161–174. ACM, New York (2006)25. Stumpf, F., Benz, M., Hermanowski, M., Eckert, C.: An approach to a trustworthysystem architecture using virtualization (2007)26. Toegl, R., Pirker, M.: An ongoing game of Tetris: Integrating trusted computingin Java, block-by-block. In: Proceedings of Future of Trust in Computing. Vieweg+ Teubner (2008)27. Trusted Computing Group, https://www.trustedcomputinggroup.org/28. Trusted Computing Group. TCG infrastructure specifications,https://www.trustedcomputinggroup.org/specs/IWG/29. Trusted Computing Group. TCG main specification version 1.1b,https://www.trustedcomputinggroup.org/specs/TPM/30. Trusted Computing Group. TCG software stack specification, version 1.2 errata a,https://www.trustedcomputinggroup.org/specs/TSS/31. Trusted Computing Group. TCG TPM specification version 1.2 revision 103,https://www.trustedcomputinggroup.org/specs/TPM/

A PrivacyCA for Anonymity and Trust 11932. Trusted Computing Group. TCG Reference Architecture for Interoperability (Version1.0) (June 2005), https://www.trustedcomputinggroup.org/specs/IWG33. Trusted Computing Group. TCG Credential Profiles Specifications (Version 1.1,rev 1.014) (May 2007), https://www.trustedcomputinggroup.org/specs/IWG34. van Doorn, L.: A secure Java virtual machine. In: Proceedings of the 9th USENIXSecurity Symposium. USENIX Association (2000)35. Zic, J., Nepal, S.: Implementing a portable trusted environment. In: Proceedingsof Future of Trust in Computing. Vieweg + Teubner (2008)

Revocation of TPM KeysStefan Katzenbeisser 1 ,KlausKursawe 2 , and Frederic Stumpf 31 Security Engineering Group,Technische Universität Darmstadt, Darmstadt, Germanykatzenbeisser@seceng.informatik.tu-darmstadt.de2 Information and System Security Group,Philips Research Europe, Eindhoven, The Netherlandsklaus.kursawe@philips.com3 Research Group IT-Security,Technische Universität Darmstadt, Darmstadt, Germanystumpf@sec.informatik.tu-darmstadt.deAbstract. A Trusted Platform Module (TPM) offers a number of basicsecurity services which can be used to build complex trusted applications.One of the main functionalities of a TPM is the provision of aprotected storage, including access management for cryptographic keys.To allow for scalability in spite of the resource constraints of the TPM,keys are not stored inside the TPM, but in encrypted form on external,untrusted storage. This has the consequence that the actual key storageis not under control of the TPM, and it is therefore not possible to revokeindividual keys. In this paper we introduce two basic methods to implementkey revocation without major changes to the TPM command set,and without inhibiting backwards compatibility with the current specification.Our methods introduce no overhead for normal operation, anda reasonable small effort for managing revocable keys.1 IntroductionOne of the basic functionalities of a Trusted Platform Module (TPM) as proposedby the Trusted Computing Group [9] is the secure storage of cryptographicencryption and signature keys. By protecting these keys with hardware measures,they cannot easily be removed in offline attacks or altered through the operatingsystem. To reduce the amount of non-volatile memory required inside the TPM,it acts as an access control device for externally stored keys rather than storingall keys itself. Only the storage root key (SRK ) remains permanently in theTPM and is used to encrypt all other externally stored keys. This strategy offersthe same security level as if all keys were stored internally. 1 This design choiceallows to reduce the production costs of a TPM, but introduces the problemthat the TPM is not able to reliably destroy externally stored keys once they1 The TPM does store other keys for internal use, especially the endorsement key;however these keys do not play a role in the context of the present paper.L. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 120–132, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

Revocation of TPM Keys 121get compromised. Thus, if an attacker once acquires access rights to a TPMmaintainedkey and an encrypted version of that key, he can always access thatkey through the TPM hardware.One secure way to prevent a compromised key from being used in the futureis to delete the storage root key. However, this makes all non-migrateable keysmaintained by the TPM unusable, which may be unacceptable in applicationswhere a single TPM needs to manage a large number of keys. To alleviate theproblem, a mechanism to revoke TPM keys is required; however, such a mechanismis not provided by the TPM specification of the Trusted Computing Group.In this paper, we analyse two ways of implementing a TPM key revocationscheme and propose appropriate extensions to the TPM specification. It seemsunavoidable to make changes to the TPM command set, as some additional verificationof the validity of a key is required inside the TPM. Our methods attemptto minimise the amount of modification required, and can be implemented in away that does not affect the compatibility of existing applications. In particular,we propose two revocation schemes: one is based on blacklisting of revokedkeys, while the other one employs a whitelist approach. Both approaches requireadditional communication with and computation in the TPM: either loading akey has a communication complexity linear in the number of revoked keys, or revokinga key has a communication complexity linear in the number of revocablekeys. In the last part of the paper, we propose to use a combination of blacklistsand whitelists to ensure practicability of the key revocation scheme.While our approach is applicable to all keys maintained by the TPM, themain application of key revocation lies in authentication keys for external services.In this application it is infeasible to guarantee that a party whose accessis to be revoked can be banned from accessing the TPM—for examplebecause he still uses the platform and is just banned from using a single service,or because an aggressive attacker may gain illicit access to a machine (thereason why keys where stored in the TPM in the first place). Thus, a mechanismis required to block the use of single keys, while other authenticationkeys should remain functional. In addition, a variant of the proposed protocolallows to change the authorisation information required to access a TPM keyin a way that reliably invalidates old authorisation information for an attackerthat holds a copy of the old TPM information; this allows for a substantiallymore secure key management for any application using TPM keys with a longlifetime.2 Related WorkEfficient key revocation has been studied in various settings, especially in thecontext of public key infrastructures [4], or in wireless sensor networks [10]. Thoseapplications show little connection to the TPM case though, as they usually dealwith a large number of networked participants. There is relatively little work onTPM key revocation; while the Trusted Computing Group spent quite someeffort on the revocability of TPMs [1] and some work has been done on key

122 S. Katzenbeisser, K. Kursawe, and F. Stumpfmanagement issues such as key migration [2], we are not aware of any schemesthat allow to revoke individual TPM keys.Some authors considered TPM-based applications that share some similaritieswith the key revocation problem. In [3], limited trusted memory is used to storea database in untrusted storage. As in our application, it is important that anattacker cannot replay an old version of the database: in some sense, the TPMkey storage can be seen as a database of keys. Sarmenta et. al. [5] proposeefficient ways to implement count objects based on a TPM by using hash trees.An externally stored counter poses similar challenges as an externally storedkey: it must not be possible to set the counter to an old value, while a key mustcontain a protected flag that marks him as valid or invalid. While it is possibleto translate the hash-tree approach to key management, we believe that theproblem of key revocation can be solved in a simpler way that fits better intothe TPM architecture.3 Basic Key Revocation Protocol SuiteKey revocation can be implemented either with a blacklist or a whitelist approach.While blacklists allow for an efficient (constant time) revocation ofkeys and introduce a performance penalty once a key is loaded into the TPM,whitelists provide fast (constant time) access to keys, but require a costly revocationoperation.A blacklist is an externally stored list of keys that have been revoked; integrityof the list is assured through a hash chain. The list is bound to the TPM by acryptographic key and a register, which securely stores the last element of thehash chain within the TPM. Whenever a key is revoked, a new entry to theblacklist is created, and the TPM updates its internally stored hash. Whenevera key is loaded into the TPM, the blacklist is fed sequentially through the TPM,its integrity is checked and its entries are compared to the key to be loaded. Ifthe key is on the blacklist, the TPM aborts the loading process. Thus, the useof a key gets expensive once a large number of keys are revoked.In contrast, in a whitelist approach, a special whitelist blob, containing a(keyed) hash of a counter and the key, is produced for every key that is notrevoked. Due to the use of a keyed hash, the blob is only accessible to theTPM. Inside the TPM, we need one secure counter. A key is only valid if thecounter value stored in the associated whitelist key blob matches the internalTPM counter. To revoke a key, the TPM increments its internal secure counterand updates (re-creates) all non-revoked whitelist blobs by incrementing thecontained counter value. This approach allows for very efficient (constant time)verification of the revocation status of a key. However, the revocation processitself is relatively complex, as the TPM needs to re-authenticate every singlewhitelist key blob corresponding to a non-revoked key.In both approaches, we change the implementation of the TPM LoadKey command.Furthermore, we require an additional command, which is used to passthe entire black- or whitelist through the TPM in a sequential manner, either

Revocation of TPM Keys 123during use or during revocation of the key. In the following sections, we provideimplementations for both the blacklist and whitelist approach. For simplicity,the algorithm descriptions show only the input/output parameters which areaccessed in the algorithms; additional parameters are given in the TPM specification[8].For efficiency and compatibility reasons, we do not make every key revocableby default. Rather, on generation of a key, a user can choose whether a keyshould be revocable or not. This way, old applications can use the TPM withoutany modification, and the data structures needed for revocation information donot need to be bloated with keys that are not required to be revocable.4 Blacklist ImplementationIn the blacklist approach, we store an authenticated list of revoked keys in externalmemory. The list of keys is kept in the form of a hash chain, which allows easyauthentication, sequential access and addition of new revoked keys. Furthermore,we securely store the last element of the hash chain (called TPM.lastHash in thesequel) inside the TPM for verification purposes; thus, only a small amount ofsecure persistent storage is required. Note however, that the blacklist must bestored on an external device in a way that is not accessible to an attacker, sincemalicious modifications (e.g., integrity changes or deletions) invalidate the wholelist and allow denial of service attacks, as all revocable keys cannot be loaded inthe future once the integrity of the blacklist is broken.In order to keep the option of using non-revocable keys for less critical taskswithout any performance penalties, we add a special field revocable to each keyblob generated by the TPM. Once a key is loaded, the TPM checks the flagand only executes the standard key loading process if the key is marked as nonrevocable.The revocable flag can be realized by introducing the new mask value0x00000016 to the TPM KEY FLAGS structure [6]. As not all possible mask valuesare used in the current version of the specification, this can be done with minimaleffort. Since the TPM KEY FLAGS structure is not protected by encryption, the flagalso needs to be integrated to the TPM STORE ASYMKEY structure [6] to ensure itsconsistency and integrity.In addition, another flag needs to be added to the TPM STORE ASYMKEY structure.This flag (called checked in the sequel) indicates whether a revocable keyhas been validated against the blacklist. This flag has the same characteristicsas a semaphore and is used to deliver state information between the commandwhich loads the key (TPM LoadKey) and a new TPM command that validatesthe loaded key against the blacklist (TPM ShowRevListElement, seebelowforthe implementation).Structure of the blacklist, Setup of the system. The blacklist contains the publickeys of all revoked keys, authenticated by the TPM and stored in the form of ahash chain. For authentication we use the storage root key (SRK). Alternatively,a different key which is a direct child of the SRK may be utilized; this requiresboth the SRK and an additional key to be loaded into the TPM. However, since

124 S. Katzenbeisser, K. Kursawe, and F. Stumpfthe TPM only possesses a very limited number of key slots, this concept maydeplete the TPM’s available key-slots and restrain the ability to load additionalkeys. Every element rev element of the hash chain has the following structure:〈key, Hash(REVOC LABEL ‖ key ‖ SRK ‖ prevHash)〉 ,where key denotes the public key that is revoked, SRK denotes the privatestorage root key, REVOC LABEL is a label that indicates that the hash value isintended solely for the construction of a revocation list, and prevHash denotesthe hash of the previous entry in the revocation list (the latter is set to a constantvalue 0 k for the first list element). The usage of SRK in the hash makes the hashkeyed: only the TPM, which is owner of the SRK, is able to generate hashes andverify hash values. The elements of the hash chain can easily be stored in a newTPM structure TPM REV ELEMENT of the following type:typedef struct tdTPM_REV_ELEMENT {TPM_STRUCT_VER ver;TPM_STORE_PUBKEY pubKey;TPM_REV_ELEMENT_HASH Hash;} TPM_REV_ELEMENT;The blacklist is managed by a software stack; however, only the TPM is able tooperate on the blacklist.To initialize the revocation mechanism, the hash TPM.lastHash (which issecurely stored within the TPM) is set to 0 k , indicating the absence of a revocationlist. This needs to happen whenever a new SRK is defined, i.e., as a part ofthe TPM TakeOwnership command. Furthermore, the commands for generatingkeys (such as TPM CreateWrapKey) have to be modified in order to initialize therequired fields revocable and checked, where the latter one is set to false bydefault.Revocation of a key. A key can be revoked by a call to the new TPM commandTPM RevokeKey: the command takes the handle keyHandle of the key to berevoked and a handle srkHandle to the SRK. Thus, we assume that a key isavailable when it is revoked (this excludes the possibility of revoking keys whichare not present). The command simply generates the new entry of the hash chainusing the hash of the last revocation list element that is stored securely withinthe TPM. Furthermore, it updates this hash and returns the new revocation listentry (see Algorithm 1). Note that the command does, for performance reasons,not verify the integrity of the existing hash chain. Moreover, it does not checkwhether the hash chain already contains an entry for the key in question. Weassume that all our commands are executed inside an established authorisationsession (e.g., TPM OSAP or TPM OIAP) [7]. The purpose of this session is to verifyauthorisation and to establish an authorisation handle between the TPM and thesoftware stack for the different keys. Since some of the commands introduced byus require authorisation of multiple keys with different authorisation knowledge,it is necessary to establish multiple authorisation sessions to the TPM. This is

Revocation of TPM Keys 125Algorithm 1. Algorithm TPM RevokeKeyInput : srkHandle, keyHandleOutput: returnCode, revElementnewHash := Hash(REVOC LABEL || keyHandle.pubKey || SRK || TPM.lastHash)TPM.lastHash := newHashreturn RET REVOKE KEY ACK, newHashsimilar to the TPM ActivateIdentity command that requires two concurrentOSAP sessions (Cf. [8], pp. 153). Note that the data-structures used here do notdirectly allow to maintain a TPM-key, but replace its authorisation information(i.e., blacklist the old version and bind the key to a new one); however, this caneasily be added if such a functionallity is desired.Usage of a TPM key. Every TPM key that is used in an application mustbe loaded by the function TPM LoadKey. If the loaded key is revocable it cannotbe directly used (key.revocable is set to true): The TPM rather has tocheck whether the key is present on the revocation list. Thus, the TPM requiresthe application (or the TSS) to execute a number of calls to the functionTPM ShowRevListElement, which sequentially feeds all entries of the revocationlist through the TPM. This function checks the integrity of the hash chain andverifies that the key to be loaded is not present on the blacklist. The functionaborts with failure (RET FAIL) if the hash chain is invalid, requests further callsuntil the end of the hash chain is reached (RET REVOC) or returns RET OK. Inthe latter case it sets a flag indicating that the key is ready to use. Finally, toterminate the process of loading a key, another call to TPM LoadKey is required,which returns the key handle for subsequent use. Note that the revocation testis only performed when a key is loaded into the TPM, not every time it is used.It is thus possible that a key got revoked, but still resides inside the TPM inusable form. To alleviate the problem, it may be necessary to flush all revokedTPM keys from the TPM cache; however, this incurs a performance penalty.Algorithm 2 shows the necessary changes to the TPM LoadKey command. Ifthe key inKey refers to a revocable key, it is first checked whether the revocationlist has already been tested against the given key (inKeyPlain.Keyflags.checkedis set to true); in this case, the command performs all operations that arenormally performed when loading a key; otherwise the encrypted inKey structureis returned along with the return code RET REVOC indicating that the key needsfurther processing by the function TPM ShowRevListElement.The implementation of the command TPM ShowRevListElement is given inAlgorithm 3. It takes a handle to the SRK, the encrypted inKey structure returnedby TPM LoadKey, one element of the revocation list, a handle to the parentkey, and information on the authorisation session (one Nonce of the authorisationsession for the parentHandle). It is necessary to integrate information ofthe authorisation session to ensure that the check against the blacklist is fresh.Thus, to successfully load a revocable key, the TPM LoadKey command must useparts of the same authorisation data as TPM ShowRevListElement.

126 S. Katzenbeisser, K. Kursawe, and F. StumpfAlgorithm 2. Additional performed actions of the TPM LoadKey commandInput : parentHandle, inKey, NonceOutput: returnCode, inKeyHandle, inKeyinKeyPlain := Decrypt(inKey, parentHandle)if inKeyPlain.Keyflags.revocable = true thenif inKeyPlain.Keyflags.checked =(true || Nonce ) thenContinue as denoted in TPM specificationreturn TPM SUCCESS, inKeyHandleelseinKeyPlain.Keyflags.checked := (false || Nonce)inKey = Encrypt(inKeyPlain, parentHandle)return RET REVOC, inKeyelseContinue as denoted in TPM specificationreturn TPM SUCCESS, inKeyHandleThe algorithm validates the hash chain, assures that all subsequent calls areperformed with the same public key and makes sure that the key is not presenton the revocation list. For this purpose, the TPM needs to internally store twohash values: the hash (prevHash) of the previously validated blacklist entry anda hash of the public key (previnKey). Both can be realized as additional fieldsof the TPM STANY DATA structure. Once the end of the hash chain is reached(this can be realized by comparing TPM.lastHash with the hash of the currentrevocation entry), the TPM subsequently checks whether the given public keycorresponds to the private key stored in the inKey structure. If this is the case,the label inKeyPlain.Keyflags.checked is changed and the inKey structure isreturned.Authorisation. It is not straightforward to decide which party—the TPM owner,the key owner, or even an external party—should have the right to revoke anindividual key. The blacklist approach can easily be extended to allow each ofthe above choices; a simple modification of the TPM RevokeKey command allowsto implement the desired authorisation for key revocation, and even to decideat key creation who is allowed to revoke that particular key. An unauthorisedparty then simply is not able to create the corresponding blacklist entry.Consolidation. The effort to load a revocable key increases linearly with thesize of the blacklist, as all entries have to be passed through the TPM beforea revocable key can be used. It is therefore desirable to have a consolidationprotocol which removes the contents of the blacklist: the consolidation protocolgenerates a new SRK in parallel to the old one, copies all non-revoked keys intoa new key tree under the new SRK, and then deletes the old SRK. Asalloldkey blobs are useless without the old SRK, and only non-revoked keys will betransferred, the blacklist can be deleted and the TPM is again in a state withan empty blacklist.

Revocation of TPM Keys 127Algorithm 3. Algorithm of the TPM ShowRevListElement commandInput : srkHandle, revElement, parentHandle,inKey, NonceOutput: returnCode, inKeyif undefined(prevHash) thenprevHash=0 kcurHash := Hash(REVOC LABEL || revElement.pubKey || SRK || prevHash)if (curHash !=revElement.Hash) || (revElement.pubKey = inKey.pubKey) thenreturn RET FAILif not(undefined(previnKey)) thenif previnKey != Hash(inKey.pubKey) thenreturn RET FAILprevinKey := Hash(inKey.pubKey)prevHash := curHashif curHash = TPM.lastHash theninKeyPlain := Decrypt(inKey, parentHandle)if inKeyPlain.Keyflags.checked =(false ||Nonce) thenif inKeyPlain contains public key corresponding to previnKey theninKeyPlain.Keyflags.checked := (true || Nonce)inKey := Encrypt(inKeyPlain, parentHandle)return RET OK, inKeyelsereturn RET FAILelsereturn RET REVOCHowever, this approach encounters a number of practical problems. A TPMallows to store keys in a tree structure (e.g., the SRK may encrypt a user keywhich then itself encrypts a signature key). Thus, it may happen that a nonrevocablekey is used to protect a revocable key. In this case it is important to alsochange the non-revocable key to prevent it from being used to decrypt the old,revoked key once the blacklist is cleaned. Another problem is that the keys mayhave different access rights, and the appropriate key owners may not be availableto authorise usage of the keys; the consolidation protocol thus would need tocircumvent all access control mechanisms, which leads to additional complexityin the implementation. Finally, the key tree needs to be presented to the TPM inthe right order, as parents need to be transferred before their children. While itis possible to implement a consolidation protocol that takes all above-mentionedproblems into account, the added complexity may not be worth the effort. Insituations where keys need to be revoked very often, a different strategy basedon whitelists (as described in the next section) is much more favorable.Hash trees. When the number of revoked keys is expected to be large, anotherstrategy to limit the efforts of loading a key can be employed. Instead of a hash

128 S. Katzenbeisser, K. Kursawe, and F. Stumpfchain, the blacklist can be arranged in a tree structure. In this case, we firstcompute a short (e.g., 64 bit) hash of the key to be loaded, which determinesthe position of the key within the hash tree in the natural way: the hash isinterpreted as a binary string, where each bit indicates for each level of the treewhether to continue in the left or right subtree. Every leaf node stores a hashof the form Hash(REVOC LABEL ‖ key ‖ SRK), while every non-leaf node stores ahash of both children. Note that for efficiency reasons we do not store the entiretree, but omit subtrees that contain only empty leaf nodes (by replacing theentire subtree with a special node). Furthermore, the hash contained in the rootofthetreeisstoredwithintheTPM.To revoke a key, we compute the short hash of the public key which determinesits position within the hash tree; subsequently, we update the path from this leafto the root and re-create all required hashes. The new root hash of the tree iscopied to the TPM. When loading a key, we have to determine whether the keyis present within the hash tree. Note that, due to the fact that we know theposition where a key is stored in a tree, we only need to examine one path inthe tree, namely the path from the root node to the position indicated by theshort hash of the key. If the integrity of this path is ensured and the key is notpresent in the leaf node, the key can be loaded. In this implementation both theuse and the revocation of a key requires logarithmic effort.5 Whitelist ImplementationThe blacklist approach described above has the disadvantage that with an increasingnumber of revoked keys, the effort of loading a revocable key into theTPM increases as well. If a large number of keys needs to be revoked—for example,because a policy requires frequent key updates, or there is reason to believethat the platform has been temporarily compromised—this can quickly renderusage of keys very cumbersome. A consolidation protocol can resolve this issue,but is difficult to implement. Therefore, it is worthwhile to consider the oppositeapproach, and implement revocation through a whitelist of allowed keys.In this case, the TPM creates a separate whitelist blob for every revocablekey. The whitelist blob contains a hash of the corresponding key and a counterindicating the current version of the whitelist, i.e., the number of revocationoperations performed. The TPM maintains a secure counter TPM.revCounterwhich stores the current version number. A key is only declared valid if thecounter value stored inside its associated whitelist blob is equal to the countervalue TPM.revCounter. Whenever a key is revoked, the counter in all whitelistblobs corresponding to non-revoked keys must be incremented to keep themup-to-date.As opposed to the key blob itself, the whitelist blobs are not part of thekey hierarchy; rather, they are encrypted and authenticated with a dedicatedkey, called the whitelist root key (WRK), which is situated directly under thestorage root key. This allows to update the whitelist without running into thesame access control problems encountered in the blacklist consolidation case,

Revocation of TPM Keys 129Algorithm 4. Additional actions performed by TPM CreateWrapKeyInput : parentHandle, wrkHandle, keyInfoOutput: returnCode, wrappedKey, whitelistblobSet wrappedKey.Keyflags.revocable according to keyInfoGenerate key as denoted in specificationif keyInfo.Keyflags.revocable = true thenwhitelistblob :=Hash(REVOC LABEL || keyInfo.pubKey ||WRK || TPM.revCounter)return TPM SUCCESS, wrappedKey, whitelistblobas an update to the whitelist (a key revocation or creation of a whitelist blobfor a new key) only requires access rights to the WRK. Using a separate WRKalso allows for external whitelist updates: the WRK may be migrated onto atrusted (external) device, which is then capable of computing a new whitelistwithout any involvement of the TPM; the only operation required to happeninside the TPM is the counter update. This also resolves another problemencountered in the blacklist consolidation protocol: if a key is missed duringthe update, it is still possible to generate the new whitelist entry after thetransformation.Key creation. Key creation commands remain largely unchanged, except that awhitelist blob needs to be returned in conjunction with the key blob (note thatthis operation requires the WRK to be loaded into the TPM). The necessarymodifications to the TPM CreateWrapKeyCommand are shown in Algorithm 4.Use of key. When a key is loaded, its whitelist blob must be presented to theTPM as well. The TPM hashes the public key together with the WRK and thecurrent counter TPM.revCounter and compares the hash to the whitelist blob.Only if this hash is correct, the algorithm proceeds as in the specification (Algorithm5 shows the implementation). Thus, preparing the key for use requiresonly constant time, independent of the size of the whitelist.Algorithm 5. Additional actions performed by TPM LoadKeyInput : parentHandle, wrkHandle, inKey, whitelistblobOutput: returnCode, keyHandleinKeyPlain := Decrypt(inKey, parentHandle)if inKeyPlain.Keyflags.revocable = true thenhashval := Hash(REVOC LABEL || inKey.pubKey || WRK || TPM.revCounter)if hashval !=whitelistblob thenreturn RET FAILContinue as in the specificationreturn TPM SUCCESS, keyHandle

130 S. Katzenbeisser, K. Kursawe, and F. StumpfAlgorithm 6. Algorithm of the TPM WhitelistTransformKey commandInput : wrkHandle, parentHandle, revokedHandle, whitelistblobOutput: returnCode, whitelistblobhashval :=Hash(REVOC LABEL || revokedHandle.pubKey || WRK || TPM.revCounter)if hashval = whitelistblob thenwhitelistblob :=Hash(REVOC LABEL || revokedHandle.pubKey || WRK || TPM.revCounter+1 )return TPM SUCCESS, whitelistblobelsereturn RET FAILRevocation. To revoke a key, all whitelist blobs of non-revoked keys need to beupdated (i.e., their counter values need to be incremented). This can be performedwith the command TPM WhitelistTransformKey (Algorithm 6), which,after appropriate authorisation, takes a key blob, increments the counter valuestored in it, and returns a new blob. Once all whitelist elements are transferred,TPM WhitelistCommit (Algorithm 7) must be executed, which increments thewhitelist counter within the TPM. From this point on, the TPM only acceptswhitelist blobs with the new counter value.As the whitelist blob does not need to be protected by the same access controlmechanisms used for the main key blob, updating the corresponding blobsdoes not require special authorisation. This is necessary to allow revocation of akey by a party that does not have access rights to other keys. However, callingTPM WhitelistCommit is critical for the functioning of the TPM (a wrong callinvalidates all keys and may result in denial-of-service attacks). It is thus requiredto have owner authorisation to perform a call to TPM WhitelistCommit.In addition, we recommend to make WRK exportable, so it can be storedon an external device. This allows keys to be transferred even after a call toTPM WhitelistCommit, and even to revoke keys on a temporary basis.Algorithm 7.. Algorithm of the TPM WhitelistCommit commandInput : wrkHandleOutput: returnCodeTPM.revCounter++return TPM SUCCESS6 Combined Black- and WhitelistsAs noted above, the black- and the whitelist approaches both optimise the efficiencyof one of two important functions. The blacklist implementation allowskey revocation with constant effort, but loading a revocable key into the TPMneeds communication that is linear in the number of already revoked keys. It

Revocation of TPM Keys 131is possible to remove the blacklist through a consolidation protocol; howeverdue to authentication issues this protocol is unjustifiably complex. The whitelistapproach allows to very efficiently load keys into the TPM; it only requires tostore a very small additional whitelist blob. The price to pay is an expensiverevocation (the effort is linear in the number of revocable keys in the system).Furthermore, all key blobs must be available during revocation, unless an externaltrusted party is allowed to re-authenticate keys. The whitelist and blacklistapproaches also differ in flexibility of authorising a key revocation. In theblacklist approach, the process of revoking a key needs the TPM to create anew blacklist entry. However, it is possible to use any desired scheme to authorisethat action, and even different schemes for different keys. In the whitelistmodel, in contrast, an item has to be created for all keys but the one to berevoked, which calls for restricting the right to perform key revocation to theTPM owner.A pragmatic approach to combine the advantages of both schemes is to useboth of them in parallel. Essentially, we suggest to use the blacklist approach fornormal key revocation as described above, but additionally maintain a whitelistto efficiently consolidate the blacklists. Thus, if a key is revoked, it is first puton the blacklist and the TPM will refuse to load each key on the blacklist. Inaddition, during the creation of a revocable key, a whitelist blob is created, andthe TPM will also refuse to load any key that has no valid whitelist blob. If at anytime the blacklist becomes too long (and thus, loading a key becomes inefficient),the TPM owner can consolidate the blacklist by creating a new whitelist for allkeys that are not on the blacklist.This approach requires a slightly different TPM WhitelistTransformKey command,as an additional test—whether the key is present on the blacklist—mustbe performed. If the key is on the blacklist, no new whitelist blob is created,and the transform command instead returns an error. The second modificationis that the TPM WhitelistCommit command also resets the TPM internal hashvalue for the blacklist to 0 k . By using this approach, we gain the best of bothworlds: revoking a key can be done with constant effort, while the blacklists canstay short enough to allow for efficient key usage. Furthermore, the expensivewhitelist update operation only needs to be performed infrequently. Also, thescheme enables to use flexible authorisation methods to determine who is allowedto revoke a key. The only commands that necessarily need owner rights donot revoke keys themselves, but only rearrange already revoked keys to increaseperformance.7 ConclusionsWe have investigated two complementary approaches to implement TPM-basedkey revocation. While both seem to be reasonably practical on their own, thecombination can achieve key revocation with a very low overhead and with minimalchanges to the TPM specification. We have shown that both concepts canbe realized without breaking backwards compatibility. In addition, our proposed

132 S. Katzenbeisser, K. Kursawe, and F. Stumpfscheme is very flexible in terms of authorising the revocation: depending on theuse-case, keys can be revoked by the key owner, the TPM owner, or even byexternal parties.References1. Brickell, E.F., Camenisch, J., Chen, L.: Direct anonymous attestation. In: ACMConference on Computer and Communications Security, pp. 132–145 (2004)2. Kühn, U., Kursawe, K., Lucks, S., Sadeghi, A.-R., Stüble, C.: Secure data managementin trusted computing. In: Rao, J.R., Sunar, B. (eds.) CHES 2005. LNCS,vol. 3659, pp. 324–338. Springer, Heidelberg (2005)3. Maheshwari, U., Vingralek, R., Shapiro, W.: How to build a trusted databasesystem on untrusted storage. In: OSDI 2000 Proceedings of the 4th conference onSymposium on Operating System Design & Implementation, Berkeley, CA, USA,p. 10. USENIX Association (2000)4. Naor, M., Nissim, K.: Certificate revocation and certificate update. In: Proceedingsof the 7th USENIX Security Symposium, pp. 217–228 (1998)5. Sarmenta, L.F.G., van Dijk, M., O’Donnell, C.W., Rhodes, J., Devadas, S.: Virtualmonotonic counters and count-limited objects using a tpm without a trusted os. In:STC 2006: Proceedings of the first ACM workshop on Scalable trusted computing,pp. 27–42. ACM, New York (2006)6. Trusted Computing Group. TCG TPM Specification Version 1.2 Revision 103,TPM Main Part 2 TPM Structures. Technical report, TCG (July 2007)7. Trusted Computing Group. TCG TPM Specification Version 1.2 Revision 103,TPM Main Part 1 Design Principles. Technical report, TCG (July 2007)8. Trusted Computing Group. TCG TPM Specification Version 1.2 Revision 103,TPM Main Part 3 Command. Technical report, TCG (July 2007)9. Trusted Computing Group. Trusted Platform Module (TPM) specifications. Technicalreport (2008), https://www.trustedcomputinggroup.org/specs/TPM10. Xiao, Y., Rayi, V.K., Sun, B., Du, X., Hu, F., Galloway, M.: A survey of keymanagement schemes in wireless sensor networks. Comput. Commun. 30(11-12),2314–2341 (2007)

Securing the Dissemination of EmergencyResponse Data with an IntegratedHardware-Software ArchitectureTimothy E. Levin 1 ,JeffreyS.Dwoskin 2 , Ganesha Bhaskara 3 ,Thuy D. Nguyen 1 ,PaulC.Clark 1 ,RubyB.Lee 2 ,Cynthia E. Irvine 1 , and Terry V. Benzel 31 Naval Postgraduate School, Monterey, CA 93943, USA{levin,tdnguyen,pcclark,irvine}@nps.edu2 Princeton University, Princeton, NJ 08544, USA{jdwoskin,rblee}@princeton.edu3 USC Information Sciences Institute, Marina Del Rey, CA 90292{bhaskara,tbenzel}@isi.eduAbstract. During many crises, access to sensitive emergency-supportinformation is required to save lives and property. For example, for effectiveevacuations first responders need the names and addresses ofnon-ambulatory residents. Yet, currently, access to such information maynot be possible because government policy makers and third-party dataproviders lack confidence that today’s IT systems will protect their data.Our approach to the management of emergency information providesfirst responders with temporary, transient access to sensitive information,and ensures that the information is revoked after the emergency.The following contributions are presented: a systematic analysis of thebasic forms of trusted communication supported by the architecture; acomprehensive method for secure, distributed emergency state management;a method to allow a userspace application to securely display data;a multifaceted system analysis of the confinement of emergency informationand the secure and complete revocation of access to that informationat the closure of an emergency.Keywords: Information Assurance, Computer Security, Policy Enforcement,Secret Protection (SP), Transient Trust, Emergency Response.1 IntroductionIn a crisis, first-responders can often save lives and limit damage if they haveaccess to certain sensitive or restricted information. Examples of such emergencyinformation are: building floor plans, schematics for infrastructure or transitsystems in a city, or medical records of victims. However, government policymakers and third-party data providers lack confidence in the ability of emergencyIT systems to protect their data relative to confidentiality, sensitivity, privacy,liability, and other concerns, and are unwilling to release such data, even on atemporary basis, to civilian first responders[1].L. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 133–152, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

134 T.E. Levin et al.In this paper, we address the essential confidentiality, integrity, access control,revocation and data containment capabilities needed in future emergencyresponse systems. We show how a platform based on commercial off-the-shelftechnology can be used for the secure management of emergency informationand we detail how it can (1) communicate securely with a trusted authority,first responders, and information providers; (2) manage distributed emergencystate with high integrity and assurance; and (3) enable emergency access to sensitiveinformation while strictly maintaining its confinement as well as revokingaccess with high assurance.In the sections that follow, we show how a handheld Emergency Device, theE-Device, utilizing the latest generation separation kernel technology [2,3] andstate-of-the-art hardware security concepts [4], can be a trusted foundation forsecure crisis response.2 Secure Platform ArchitectureThe secure platform architecture of the E-Device (see Fig. 1) is based on acommercial general-purpose processor (nominally an x86) enhanced with theAuthority-Mode Secret Protection (SP) architecture features [4], a Trusted ManagementLayer (TML) — comprising a least privileged separation kernel [2], anda security services layer that virtualizes certain separation kernel resources —and trusted software programs that run in one of the TML-provided partitions.These hardware/software components, with the addition of a Trusted SoftwareModule (TSM) application supported by SP, form the Trusted Computing Base(TCB) for our E-Device.2.1 Secure Software StackThe trusted software for the E-Device utilizes Intel x86 privilege levels to protectthe resources in each level from the subjects in less-privileged domains. The twomost privileged layers are collectively referred to as the TML, while the next mostprivileged layers house a trusted executive and the Trusted Path Application(TPA).The TML provides software-based security enforcement, and is supported bysecurity features of the underlying Intel x86 and SP hardware. While support formany different client OSes is not the focus of this research, the TML is designedto provide to the commodity OS a standard execution environment with respectto platform hardware features.The TML manages all system hardware resources (e.g., memory, devices,processors, etc.). It reserves some resources for its own use, and exports otherresources in the form of processes, memory segments, I/O devices, raw disk volumes,segment volumes, etc. The TML separates all exported resources into distinctpartitions, governs the flow of information between partitions and betweenindividual exported resources, and protects raw disk volumes by encryption.The TML creates three types of partitions: Emergency, Trusted and Normal.A normal partition and an emergency partition each run a commodity

Securing Emergency Response Data 135Fig. 1. Security architecture instantiated for an emergency scenario(untrusted) OS. The Trusted Partition runs an extremely compact trusted executive.Information flow rules and partition definitions provided to the TMLdefine a partial ordering of flows between partitions, indicative of a multilevelsecurity (MLS) policy, and corresponding security labels may be associated withpartitions.The TML manages interactive user sessions through what is referred to aspartition focus, whereby the user can interact with one partition at a time, viathe system keyboard and screen.For applications in the trusted partition, the trusted executive provides simpleOS-like support. The trusted executive manages passwords and provides userauthentication services. The TPA is invoked by pressing what is known as thesecure attention key (SAK), such as Ctrl-Alt-Delete. When the TML detects theSAK, it changes partition focus to the Trusted Partition, which starts the TPA.The TPA provides a variety of other security services to the user, including:setting the security sensitivity label for a session, changing a password, andshutting down the E-Device.2.2 Trusted Software Protected by SP HardwareA novel aspect of our architecture is provided by SP’s Trusted Software Module(TSM). TSMs have two critical characteristics: they are protected from observationand modification by non-TSM software (including the OS), and they haveexclusive access to SP crypto-transforms and to two processor-resident dataregisters.A TSM is defined to be code that is executable in a special processor modecalled Concealed Execution Mode (CEM) that is entered via the Begin CEMinstruction. Once in CEM, special SP instructions can be executed — SP derive,Secure Load, Secure Store, andEnd CEM — and special SP registers can be

136 T.E. Levin et al.used — Device Root Key (DRK) and Storage Root Hash (SRH). Other CEMonlyinstructions are provided to read and write the SRH register. Also, whenin CEM, the processor checks the integrity of each instruction cache line of theTSM with respect to compiled-in signatures based on the DRK.The Secure Load and Secure Store instructions cause memory locations tobe tagged as TSM-only while they reside in on-chip caches, and to be automaticallyencrypted and hashed when they move to off-chip memory to preventunauthorized observation or modification. CEM execution is suspended duringan interrupt and is automatically resumed upon return, with data in processorregisters protected from the OS by the hardware.The protection of TSM code can be viewed as being independent from theprotection of the underlying OS, as follows. The trustworthiness of a program isgenerally understood to be limited by the trustworthiness of the programs thatit depends on. The TSM, which runs in the Emergency Partition “on top of” anuntrusted OS, does not make calls to the OS (i.e., and can not, since the OS isnot a TSM) and so a TSM is not “functionally” dependent on the OS, and canactually be more trustworthy than the OS itself.SP stores two master secrets in non-volatile registers on-chip, which providethe roots of trust for the E-Device’s operations. The DRK, which never leavesthe processor, protects the integrity of TSM code and is also used by SP deriveto cryptographically derive new keys for the TSM. The SRH can only be reador written by the TSM, and provides it with a small amount of on-chip storage,which can be used to store the output of crypto-hashing operations for protectinglarger persistent data structures such as key chains (a hierarchy of keys) and thepolicies regarding use of those keys. This allows the TSM to moderate all accessto the protected data and enforce the corresponding policies on each access.The Authority can communicate with the E-Device during operation, providingupdates to keys and policies in its persistent secure storage and to sendnew encrypted data to the E-Device. When establishing a secure communicationchannel, the parties use derived keys. Therefore, the E-Device’s ability to generatethose keys and communicate demonstrates that it still has the correct DRKvalue and signed TSM code, and serves as an implicit authentication, since onlythe E-Device and the Authority know the DRK.3 Information Sharing during an EmergencyOur concept for emergency response involves a network of participants (theEmergency Network), including a coordinating Authority, the expected firstresponders, andthird party data providers who maintain information that isexpected to be useful during an emergency. The Authority manages the distributionof keys and policies via its own secure computing facility, and coordinatesemergency response for a given crisis, including alerting all entities on theEmergency Network of the emergency and disseminating emergency data to firstresponders.

Securing Emergency Response Data 137Fig. 2. Emergency Network ArchitectureWhile E-Devices may be owned by various emergency network participants,their correct configuration is the responsibility of the authority, and they will beoperated in the field by first responders. Fig. 2 shows the emergency network.The operation of the Emergency Network is governed by prearranged organizationalsecurity policies [5]. These include the lattice-based MLS policy enforcedby the TML and the access policy enforced by the TSM in the application domain.3.1 Emergency OperationThe Authority maintains a binary global emergency state, i.e., ON or OFF, andnotifies the authorized E-Devices of any state changes. The E-Devices may grantaccess to emergency information if the state is ON, and must deny access whenOFF. Secure synchronization of the global state is discussed below.When an emergency is declared, the Authority sends state-change notificationsto the E-Devices. Once the TML interprets the message, it prompts theuser to access the Emergency Partition, via the TPA.While the emergency is in effect, the user can access any active partition theuser is cleared to see, including the preconfigured Emergency Partition. Withinthe Emergency Partition, finer granularity application-specific access controls onemergency data may be provided by an application domain Emergency ManagementTSM.When the emergency is over, the Authority announces a change to the globalemergency state, prompting the TML to start the emergency closure process. Itdisplays an end-of-emergency message which prompts the user to change focusto the Trusted partition (to be completed within a configurable period), revokesaccess to the Emergency Partition, and restores the Emergency Partition to itsoriginal state.

138 T.E. Levin et al.4 New Security MechanismsThis section presents a systematic analysis of the available secure communicationchannels and describes mechanisms for completing the trust chain from theremote Authority to the E-device, and to its Emergency Partition and display,including: emergency state management, trustworthy display and mechanismsfor revocation of sensitive data.4.1 Secure Communication ChannelsA secure communications protocol protects against message content disclosureand modification, as well as traffic analysis and insertion or deletion of packets.We consider a channel to be a secure channel if it uses a secure protocol, theprotocol is implemented correctly, and the channel endpoints are secure againstboth the modification of their behavior and against unauthorized disclosure ofchannel and keying information.The E-Device, while simple, supports several different forms of secure communicationschannels, which provide emergency systems designers with flexibility inconstructing new systems. Three basic channels are shown in Fig. 3: the TrustedChannel (A), the TSM-TSM Channel (D), and the Trusted Path (B).A Trusted Channel (A) is a secure channel between two TCBs (e.g., a TMLor a trusted system) [6]. A TSM-TSM Channel (D) provides cryptographic assuranceagainst message disclosure and modification between application TSMs,e.g., on different machines. A Trusted Path (B) is a secure channel between auser and the TML on the E-Device, implemented by the TPA.A Remote Trusted Path (E) is a secure channel between a remote user (e.g.,the Authority) and a TML, which is constructed by combining a Trusted Pathwith the remote end of a Trusted Channel. An Extended Trusted Channel (F)Fig. 3. Types of Channels

Securing Emergency Response Data 139is a secure channel created by extending the I/O interface of a Trusted Channelto the TML interface of a given partition, which allows applications to securelyinteract with a remote TCB.A Trusted Application Display (C), discussed below, enables an application(i.e., the Emergency Partition TSM) executing in the context of an insecure OSto securely write to the screen, which is managed by the TML. A Remote TrustedDisplay (G) connects a TSM-TSM Channel with a Trusted Application Displayso a remote system, such as that used by the Authority, can display data to thelocal user with assurance against message disclosure and modification.The TML exports to partitions virtual NICs (see Fig. 4), which are logicaldevices, each with an IP address, for use by the OS and applications in a specificpartition.The TML manages the negotiation of session keys and cryptographic algorithms,as well as the cryptographic transformation of data for encrypted channelsvia the IPsec “security association” paradigm [7], although the entire IPsecsuite is not required (e.g., crypto-transforms are statically assigned). An ExtendedTrusted Channel therefore embodies the mapping of a partition ID to aremote IP address and a security association. Communication channels, displaychannels and logical devices are configured during E-Device initialization withinformation such as: each channel’s remote TCB address, and security level; variouskeying material; and the mapping of Extended Trusted Channels to specificpartitions. Security levels are also assigned to partitions and physical devices.An out-of-band distributed “root” secret key that is shared with the TCB atthe other end of a trusted channel is the basis for channel session keys [8]. Fortrusted channels between the E-Device and the Authority, the DRK is used asthe root secret. For other trusted channels, such as those with third party dataFig. 4. Networking Support of the TML

140 T.E. Levin et al.providers, a shared secret key is stored by a TSM in the TML’s Trusted ChannelManager instead.Nonces to support generation of session keys are dynamically exchanged orperiodically distributed. The TSM hashes the nonce with the root secret toderive a temporary shared secret, with which it can generate a session key usinga standard key exchange protocol, such as TLS. Alternatively, the derived valueitself could be used as a session key. All communications between endpointswithin the emergency network use these channels.4.2 Emergency State ManagementAs discussed above, the Authority manages the global emergency state withemergency state management messages. State management consists of the followingsteps: (1) message generation; (2) message transmission; and (3) messageprocessing on the E-Device. Each of these steps needs to be trustworthy to ensureconsistent and correct emergency state management.In addition to the emergency state, the Authority maintains a counter of thenumber of state changes it has issued; also, it maintains a record of the acknowledgedstate and counter values for each E-Device, along with its DRK. Whenthe Authority changes the global state, it must securely synchronize with each E-Device. On the individual E-Device, local emergency state and a state transitioncounter are maintained by a state-management (E-State) TSM in the TML.When the Authority declares an emergency, it increments its counter associatedwith the E-Device and generates an emergency state management messagefor each E-Device that consists of: (a) a command type indicator (indicating astate update message); (b) a payload of the new state and counter, encryptedwith an encryption key derived from the DRK; (c) a signature (cryptographickeyed hash) of the encrypted payload and command, using a signing key derivedfrom the DRK; and (d) two nonces to derive the encryption and signing keys.The emergency state management message is sent to the E-Device through aRemote Trusted Path channel. Only the E-Device to which the emergency statemanagement message was intended is able to successfully process the message.The E-State TSM independently 1 verifies the originator of the state managementmessage. For emergency state management, two functions, Update Stateand Get State are implemented on the E-Device. The Update State functionchecks the integrity of the message using the signature, and the counter. It alsogenerates a response to the Authority by generating a signature over the messageusing a signing key derived from the signing nonce and the DRK. The E-StateTSM sends the signature back to the Authority over the trusted channel, butdoes not need to send the message payload or nonce, since the Authority alreadyhas the initial update message.The TML, via its TSM, uses Get State to retrieve the new state, as discussedin Section 3.1. To ensure that the update of emergency state is trustworthy, only1 Decoupling the channel authentication from message authentication allows for flexibilityto incorporate ad-hoc and/or peer-to-peer transmission of emergency statemanagement messages in the future.

Securing Emergency Response Data 141the TML can pass update messages from the trusted channel with the Authorityinto the E-State TSM; and only the E-State TSM can invoke Update State andGet State.For high-threat deployment environments, enhanced assurance is provided bya version of SP that includes state management primitives in its ISA. Instead ofimplementing them in the E-State TSM software, this version, includes registersfor a state variable and a state transition counter, as well as instructions for theUpdate State and Get State functions. With these hardware enhancements, eventhe TSM does not have the ability to directly modify the emergency state onthe device.4.3 Containment of Emergency DataThe organizational security policy enforced by the E-Device requires that emergencyinformation from the data providers only be accessible to authorized usersacting within the emergency partition, and only during a proper emergency declaredby the Authority. MAC policy enforcement (by the TML) and DAC policyenforcement (by the Emergency Management TSM) jointly restrict informationflows on the E-Device before, during and after the emergency.Emergency data is installed at the Authority’s secure facility or sent to theE-Device from the Authority and data providers over Trusted Channels, and isconfined in the Emergency Partition. The data may be further encrypted so thatit can only be accessed by the Emergency Management TSM application, whichcan enforce more granular access policies within the Emergency partition.The Authority establishes an Extended Trusted Channel to the EmergencyPartition. The Emergency Partition and the Authority are allocated an “emergency”MLS label that is distinct from that associated with other partitions.The TML attaches the “emergency” label to data it receives over the channel,restricting the data to only this partition of the E-Device. Data flows for emergencymanagement are shown in Fig. 5, as follows: (1) the Authority propagateschanges to the global emergency state and receives confirmation from the device;(2) the Authority sends keys, policies, and revocations to the EmergencyManagement TSM, via an Extended Trusted Channel managed by the TrustedChannel Manager (TCM); (3) the authority sends encrypted emergency data tothe Emergency Partition, via an Extended Trusted Channel; (4) data providersprovide additional data for the authority to send to the E-Device; (5) whenneeded, the Emergency Management TSM decrypts the emergency data withkeys and policies in its storage.Trusted channels between the TML and the Authority are protected usingfreshly negotiated channel secrets for each connection, based on the DRK ratherthan a stored root key. As a result, only parties with access to the DRK (theAuthority and the E-Device) can authorize an Extended Trusted Channel to theEmergency Partition.Aside from these secure channels, the information cannot flow out of theEmergency Partition, e.g., to any other partition, device or network, ensuringthat emergency data cannot be revealed outside of the equivalence class of

142 T.E. Levin et al.Fig. 5. Data Flow for Emergency Managementcomponents labeled as “Emergency.” Additionally, the Emergency Partition itselfis only made available to the user by the TML and TPA when an emergencyhas been declared, as previously described. This temporal restriction limits thethreat of malicious insiders, and in combination with the partition’s spatial separation,provides defense in depth for the confinement of emergency information.The Authority provides its own emergency data to the E-Device, and canconvey data provided by third party data providers. When the latter data isproxied through the Authority and the third party has no direct communicationwith the E-Device, the third party does not need and is not given the privilegesassociated with the “Emergency” label.If a third party is considered trusted, it can be included in the “Emergency”equivalence class and allowed to establish an Extended Trusted Channel directlyto the Emergency Partition. Since the Third Party does not have access to the E-Device’s DRK, it and the Emergency Management TSM share an “emergency”key, which is stored locally in the TSM’s persistent secure storage. Even whenthird party data is provided directly, the TSM on the E-Device can still beconfigured to only accept policies for that data directly from the Authority.All emergency data sent over the Extended Trusted Channel is encrypted bythe Authority or data provider prior to transmission using keys only available(on the E-Device) to the TSM. This enables the TSM to enforce its discretionaryaccess control policy on use of the data by the responder or any software withinthe Emergency Partition, and audit the use of the data, even though it executesalongside untrusted software in the Emergency Partition.Within the Emergency Partition, the TSM can release data to untrusted,feature-rich commercial applications for display. However, there is no assurancethat untrusted applications will accurately display data when asked. Some information,e.g., that which is critical and easy to manipulate, may require greater

Securing Emergency Response Data 143protection. For this, we provide the high-integrity Trusted Application Displaymechanism, which allows an application-TSM to send text-only emergency datadirectly to a reserved region of the display via a secure call to the TML thatbypasses the untrusted software in the Emergency Partition.The trusted display mechanism provides an unspoofable means for an applicationdomain program to display messages with high integrity such that theycannot be observed or modified by any untrusted software in the system. Thismechanism is available to the TSM in the Emergency Partition and the TPArunning in the Trusted Partition. Both the TSM and TPA are designed to beevaluated to ensure their correct behavior, which helps to ensure that the correctdata is input to the trusted display mechanism.The TML virtualizes the video graphics card such that it appears to eachpartition that it has control of the screen. These virtual devices pass input tothe TML’s secure display driver, which divides the physical display into tworegions. One region is restricted for the TML-controlled high-integrity display(for example, the bottom two lines of text on the screen). The remaining regionof the screen is exported to the partition with focus as normal.High integrity data to be displayed is encrypted and either comes directlyfrom the Authority for Remote Trusted Display or is chosen to be released bythe TSM during its operation for Trusted Application Display. To pass the datasecurely to the TML, the TSM is divided into two pieces: an application-TSMin the partition and a kernel-TSM in the TML. The former is responsible forpreparing the data for display and the latter for passing the plaintext data tothe TML securely. SP’s CEM protects the data as it is passed between privilegelevels through the untrusted software in the Emergency Partition.The application-TSM first decrypts the data using keys in its storage, andthen stores the resulting display text in a memory buffer (at a known location)using Secure Store instructions. This data is now only accessible in plaintext toTSM code. An x86 call-gate is used to transition from the application-TSM to thekernel-TSM without an interrupt. The kernel-TSM uses Secure Load instructionsto read from the CEM-protected memory buffer and regular Store instructionsto write the cleartext data to the TML buffer. It then exits CEM mode andinvokes the TML-provided Trusted Screen Handler, which sends the data tothe TML’s Trusted Screen Driver for display in the restricted display region.Finally, the kernel-TSM code re-enters CEM and returns to the call gate in theapplication-TSM, with a return value indicating the success or failure of thedisplay operation.To complete the data lifecycle, access to emergency data must be rescindedonce the emergency is over. Data revocation takes place through complementarymechanisms, using both mandatory and discretionary access control.The coarsest granularity of revocation available to the Authority is to declarethe emergency to have ended. As described in Section 4.2, this results in theclosing of the Emergency Partition to users and applications, and restores itscode and data to the pre-emergency state. Stopping application activity and

144 T.E. Levin et al.overwriting the entire partition effectively removes all data generated or releasedinside the partition.A finer-granularity of revocation is provided by the Emergency ManagementTSM itself, as described in [4]. Over and above the TSM-enforced policies restrictingaccess to data based on expiration dates, usage counts, search queryrestrictions, etc., at its discretion, the Authority can communicate with the TSMand direct it to modify policies, keys, and other emergency restrictions to revokeaccess to existing data, for example, in preparation for ending the emergency.Guarantees to the Authority and third parties about revocation and the stateof the E-Device depend on connectivity and availability of the TSM. If the E-Device is disconnected temporarily from the network, or an application TSMmanaging communication with the Authority is subject to a functional denial ofservice attack, the Authority will be unable to synchronize the local emergencystate with its own global state. An emergency expiration timer is provided by theTML, such that if connectivity with the Authority cannot be established withina defined time, the TML can end the emergency on the E-Device. The use of thistimer may not be appropriate for all responders and is therefore configurable.Once communication is restored, the E-Device can attest to the Authority thatthe requested updates to emergency state, policy, and keys have been made.5 System Security AnalysisOverall system security can be understood in terms of the threats to which itwill be exposed and how the system is capable of counteracting those threats.5.1 Threat Model and AssumptionsWe assume that the E-Device is initialized securely with TML-, TSM- and SPspecifickeys. We also assume that the third parties and the Authority securelyexchange the required keying material and protect their own keys from exposure.We assume the standard Dolev-Yao model [9], that arbitrary parties can capture,modify or insert network traffic. Intentional or malicious network-level denialof service — as opposed to prevention of process functionality at the workstation— is outside the threat model. The threat model and analysis for SP,which includes spoofing, splicing and replay of TSM code, intermediate datain registers and memory, and secure persistent storage, are discussed in [4], includingthe protection of emergency data encrypted with TSM keys. The threatmodel for the TML is that applications of the TML, including guest OSs otherthan the trusted executive, are not trusted to conform to its policies, and may infact be hostile. For example, at runtime, the software executing above the TMLmay attempt to access keys used by the TML to establish secure channels — andapplication software or the commodity operating systems may attempt to writeemergency data to a location outside the partition or attempt to access highintegrity information through low integrity mechanisms. The trusted executiveis only trusted to manage its applications in a manner that does not introduce

Securing Emergency Response Data 145covert channels between applications that are at different security levels. Thepersistent disk storage is encrypted and signed, and so is protected against, e.g.,theft of the E-Device.TCB software at the Authority, third parties and in the E-Device is assumedto behave correctly and securely. But, application TSMs are subject to inconsistenciesin their execution environment, such as denial of access to the processor,as they execute independently from the trusted software that controls physicalresources.5.2 Security CapabilitiesThe architecture presented in this paper combines the secure execution and keyconfidentiality provided by SP hardware with information containment assuranceprovided by the TML. Further, secure boot ensures that the correct TMLconfiguration is loaded on boot and SP’s code integrity checking (CIC) ensuressyntactic runtime integrity of TML code. This ensures that large classes of softwareattacks that involve code modification are prevented.The DRK acts as the shared secret between the E-Device and the Authority.On the E-Device, the confidentiality provided by the SP hardware ensures thatsoftware never has access to the DRK directly, ensuring this shared secret isalways protected with high assurance.Software is only allowed to use the DRK to derive other keys, which is sufficientfor mutual authentication and secure channel establishment. The SP hardwarealong with the TSM ensures that all computation involving keys derived fromthe DRK, including intermediate data, never leaves the processor chip in unencryptedform. This avoids the possibility of any software outside the TSMgetting access to derived keys. Since this is an invariant of the TSM and SPhardware, keys used for secure channels are always protected. The TML codeis protected by the CIC mode of the SP processor, ensuring that the accesscontrol polices enforced by the TML cannot be changed by code modificationattacks. The privilege levels provided by hardware ensure that subjects withlesser privilege than the TML cannot read or write to objects in the TML. Thisensures that the TML always sets up the secure channels between the differentendpoints on the E-Device and the Authority/third parties as configured.A Trusted Path provides bidirectional security: (1) ensuring that user inputto the TCB is accurately and securely received by the TCB, via a keyboard-to-TCB data pipeline (where the keyboard is a proxy for the user); and (2) ensuringthat output from the TCB is seen by the user, without ambiguity or compromise,via the TCB-to-screen data pipeline (where the screen is a proxy for the user).The Trusted Path is a secure channel, since it is secure and it provides adirect connection to the TCB endpoint via a secure interface provided by theTML, with no intervening untrusted components. The Trusted Channel is asecure channel, since it is assumed to use secure protocols and the endpoints aresecure.The E-Device has three TSMs: one is an Emergency Partition application,and the other two are TML modules. Since these TSMs provide system security

146 T.E. Levin et al.services, they are considered to be part of the TCB and are built to the samelevel of assurance as the TML. When they communicate, the TSMs on bothends of the TSM-TSM Channel have access to DRK-derived keys as well asCEM-protected memory, so the receiver can validate the integrity of messagesand ensure confidentiality. The TSMs on the E-Device similarly share the sameDRK-derived keys with the Authority, and two TSMs on different devices canbe provided a shared secret by the Authority. We further assume that a TSM-TSM Channel to the Authority or another E-Device utilizes a Trusted Channel,adding another layer of protection over the network.Any data used, transmitted, or displayed by an application-TSM is still subjectto a functional denial of service by the untrusted OS, which may prevent its executionor tamper with its encrypted data — but the tampering will be detected.In the Extended Trusted Channel, the TML makes Trusted Channels availableto partitions as logical I/O devices, which provides a secure channel between theI/O device interface and the trusted component at the other end of the TrustedChannel. The Extended Trusted Channel can provide plain-text or encrypteddata to a given partition (where the cryptographic functions are provided byapplications in the partition).In Normal and Emergency Partitions, a commercial OS manages the logicalI/O device, and makes it available to its applications via an abstraction such asa socket. The security of the Extended Trusted Channel from the perspective ofthe OS application then depends on the security of the OS and any encryptionof the data.The Trusted Application Display is a uni-directional secure channel betweenthe local application TSM and the user, assuming continuity in execution of theTSM and protection of TSM message data. Continuity of execution dependson the TSM’s processing environment, including the ability of the applicationdomain OS to schedule the TSM and other applications consistently and avoidanceof attacks on application-TSM code, data buffers, or communications to theTML. While these would constitute a functional denial of service attack on theTSM, they could not compromise the confidentiality or integrity of the displaydata. Of course, the confidentiality of displayed data is not protected from outof band analog mechanisms, e.g., visual observation of the screen.Combining a TSM-TSM Channel with the Trusted Application Display channelresults in a Remote Trusted Display channel that is a single-direction channelwhose security depends on the security of the component channels (i.e., theTSM-TSM Channel and Trusted Application Display channel discussed above).Emergency state management message generation is a security critical operation.Only the Authority is able to generate valid messages for a given E-Device asthey are based on the device-specific DRK, known only to the authority and theE-Device. Since SP hardware ensures software never has access to the DRK andthe authority secures its copy of DRK, arbitrary parties cannot generate a validmessage. Since the emergency state change generates a response that is also cryptographicallysigned by a DRK-derived key, the authority can be assured that theemergency state management was correctly processed by the intended E-Device.

Securing Emergency Response Data 147There are several layers of protection that detect and prevent replay attackson emergency state management messages: (a) all messages are transmitted oversecure primary channels such that only the subjects with access to the endpointsof the secure channels can see even the encrypted message; (b) the TSM inthe TML could also overlay a secure mutual-authentication protocol betweenthe TSM and the Authority to prevent other parts of the TML from accessingthe encrypted emergency state management message; (c) since the message isencrypted using keys derived from the DRK, only the TSM on the correct E-Device can decrypt and process the message; (d) the monotonically increasingcounter ensures that a given message is never processed twice.Once the emergency is declared, and the E-Device successfully changes itsemergency state, the Emergency Partition is enabled and the user is able toaccess it. The TML ensures that the Emergency Partition can write only tochannels leading to the Authority and to trusted data providers. Further, noother partition on the E-Device can read content in the emergency partitionlabeled as “Emergency.” The TML ensures only known virtual device abstractionsof trusted pre-configured physical devices are presented to the OS inthe Emergency Partition, thus avoiding the possibility of the user being ableto attach a device with unconstrained information flow properties to thepartition.When the emergency data is decrypted and displayed within the EmergencyPartition, the untrusted applications or OS may keep parts of the clear textemergency data in memory and/or write it to disk, but the TML’s Emergencypartitionseparation policy ensures that the data remains in the Emergency Partition.While all data in memory is erased or otherwise invalidated on a shutdownof the E-Device, the data on the disk may still be accessible if the EmergencyPartition is still present. Any offline attacks on emergency data on disk are preventedas the TML protects all data on disk by encryption with keys derivedfrom the DRK. These encryption keys are derived as needed and are never revealedor stored. These properties ensure emergency data containment duringthe emergency. When the declaration of emergency is rescinded, the EmergencyPartition becomes inaccessible to the user and its contents are encrypted andstored for audit purposes or immediately deleted.Applications in the Emergency Partition are not expected to display highintegrity content, as both the applications and the OS are not trusted. Instead,high integrity information is displayed on the reserved portion of the screen, viathe Trusted Application Display, with data that is appropriately encrypted andhashed. Since the TML manages the physical display, no partitions are givendirect access to the portion of the screen reserved for high integrity display.6 ValidationWe have implemented an E-Device prototype that provides a worked example ofhow the coherent integration of complementary hardware and software securitymechanisms can enhance security, and validates elements of our overall approach.

148 T.E. Levin et al.6.1 Prototype ImplementationThe prototype demonstrates the feasibility of TSM technology as well as keylayering and partitioning mechanisms in the TML.The prototype TML runs on bare hardware on the x86 platform and providesmultiple partitions which the user can switch between using the Secure AttentionKey. The partitions each run a primitive trusted executive, providing I/O to theuser-space application running above it. Authority-mode SP features, which havebeen independently prototyped [4], are provided here by a trusted kernel modulewhich emulates its behavior and security properties.Our prototype implementation of the integrated architecture demonstratesthe feasibility of: (a) emergency management operations using remote trustedpath; (b) the ability for the Authority and data providers to disseminate keysand data to the emergency partition; (c) the use of the trusted display mechanismprovided by the TML to applications to securely display high integritydata; (d) protection of the code integrity of TSMs and its secure storage bythe SP hardware; (e) prevention of access to TSM secure storage by the untrustedOS or untrusted applications; and (f) detection of simulated attackson the remote trusted path, key/data usage policies, and confidentiality andintegrity of emergency data using standard cryptographic algorithms. For theprototype, it is assumed that the TML-managed trusted channels for securecommunication with the Authority and data providers are in place and the keymanagement messages between the E-Device and the Authority/data providersare pre-computed.7 Related WorkPrevious work in processor-based cryptographic support include: SP [4], separationkernels [2], and “least privilege” security architectures [3]. We note thatcryptographic coprocessor mechanisms [10,11] do not provide processor-level protectionfor system software and data, and may be more vulnerable to attack byelements within the platform. Also, while IBM announced an architecture [12]featuring processor-based encryption for protecting data on chip and in transit toremote systems, little information is available regarding system trustworthiness,or the separation of information based on events or mandatory policies.The Turaya [13,14] and MILS [15,16] architectures are designed to host commercialoperating systems and security services as parallel application-domainentities, with certain interactions between those entities controlled by a microkernel(e.g., L4) and a separation kernel, respectively. The security architecturepresented here differs from these efforts in that it does not rely on applicationdomain programs for enforcement of the primary underlying security policy, andit provides an interface for the enforcement of intra-OS least privilege policiesas well as inter-OS sharing policies. Additionally, the Turaya and MILS effortsdo not address the temporal confinement, revocation, and distributed statechangeissues inherent to emergency management of information, and they do not

Securing Emergency Response Data 149provide processor cryptographic transformations or processor protection of criticalkeying material.Trusted Channels provide point-to-point encrypted tunnels between a TMLand a remote TCB that has at least as much assurance of security enforcementas the TML. Trusted Channels are similar to Virtual Private Networks [17]although VPNs are usually expected to support arbitrary and changing sets ofnetwork nodes rather than point-to-point connections.The “trusted path” has been understood as a requirement for secure computersystems since the early 1970s [18], and has been implemented in manyhigh assurance [19,20] and commercial systems [21,22]. In our work, the TrustedPath Application implements a traditional user interface for trusted interactionbetween the user and the TCB (TML). The Remote Trusted Path extendsthe user’s ability to communicate, from the local TCB to a remote TCB. Ourwork differs from previous remote trusted pathresults(e.g.,[23,6])inthatthesecurity of the communication is rooted in a processor-resident secret key, forcommunication with the Authority.The Xen “hypervisor” provides support for security policies by way of “domains”that are similar to TML partitions. Security labels can be associatedwith a domain, and a security policy can be defined to describe resource isolationor controlled inter-domain information flow [24]. However, Xen was builtspecifically to provide hardware-assisted virtualization of operating systems [25]rather than a more generic operating environment with other services, such asthose provided by the TML.With the Extended Trusted Channel we replace the Trusted Path’s humaninterface to the TCB with a direct programmatic interface, which allows applicationsto interact with a remote TCB (via a Trusted Channel). Similarly, forthe Trusted Application Display, the TML exports a programmatic interface forsubmitting data to the TCB for display. A TML-resident TSM subsequently decryptsthe data and then the TML displays it on the screen in a reserved area.Securing the computer display against subversion has been reflected in early workon multilevel windowing [26], and subsequent hardware and software-supporteddevelopment [27,28]. Our work differs from these developments in providing ameans for an application executing in the context of an insecure operating systemto securely write to the screen.In its Global Information Grid (GIG), the US Government has recognizedthat, in emergencies, the need to access information may be more important thanthe need to protect the information, and has developed extensive technical andpolicy roadmaps to support that vision [29,30]. Our framework for managementof emergency information advances these concepts by providing a theory andconcrete realization to confine information made available under extraordinarycircumstances and to rescind access after the completion of those circumstances.OASIS provides the EDXL standard [31] for information exchange duringemergencies, such as payload and message encryption. Our architecture providesa trusted context for the management of EDXL data.

150 T.E. Levin et al.8 ConclusionsTo address the inability of existing IT systems to support integrated informationsharing, temporary emergency data access, and secure revocation of thataccess, we have developed an architectural solution that integrates hardwareanchoredcryptographic protection with a high assurance software architecturethat provides data separation and security services. We have proposed a securehardware-software platform for an E-Device that can provide trustworthy disseminationand revocation of access to sensitive data during an emergency.We described the architectural support for trusted communication channels,including a remote trusted path between the authority and the E-Device, as wellas trusted display channels in the E-device. We integrated the SP protocols forDRK-based key-generation into the trusted channel mechanism to protect thestorage of channel keys and ensure the authentication of parties who will gainaccess to the Emergency Partition.We presented a comprehensive design for the management of distributed emergencystate, which is critical for effective emergency response. We also describedthe Trusted Application Display to allow user-space applications to securely communicatewith the user via direct x86-style call gates to a kernel-TSM. We alsodescribed the multifaceted containment of emergency data and reliable revocationof access at the end of the emergency, using a combination of hardware andsoftware mechanisms and trust chains.Finally, we have built a prototype that validates key concepts of the architecture,indicating the feasibility of using commodity mobile and wearable platformsfor secure emergency-response data dissemination. In the future, in-depth usabilityand performance testing, as well as formal system security verification, willfurther validate this work.Acknowledgments. This material is based upon work supported by the NationalScience Foundation under Grants No. CNS-0430566, CNS-0430487 andCNS-0430598 with support from DARPA ATO. This paper does not necessarilyreflect the views of the National Science Foundation or of DARPA ATO.References1. Johns Hopkins University, National center for study of preparedness and catastrophicevent response. Technical Report,http://www.pacercenter.org2. IAD: U.S. Government Protection Profile for Separation Kernels in EnvironmentsRequiring High Robustness. Version 1.021 edn. National Information AssurancePartnership (March 2007)3. Levin, T.E., Irvine, C.E., Weissman, C., Nguyen, T.D.: Analysis of three multilevelsecurity architectures. In: Proceedings 1st Computer Security ArchitectureWorkshop, Fairfax, VA, 37–46 (November 2007)4. Dwoskin, J.S., Lee, R.B.: Hardware-rooted trust for secure key management andtransient trust. In: Proc. of 14th ACM conference on Computer and communicationssecurity, pp. 389–400. ACM, New York (2007)

Securing Emergency Response Data 1515. Sterne, D.F.: On the buzzword “security policy”. In: Proceedings of the IEEESymposium on Research on Security and Privacy, Oakland, CA, pp. 219–230. IEEEComputer Society Press, Los Alamitos (1991)6. CCMB: Common Criteria for Information Technology Security Evaluation, Part 2:Security functional components. 3.1 revision 1 edn. Number CCMB-2006-09-001in Criteria. Common Criteria Maintenance Board (September 2006)7. Kent, S., Atkinson, R.: Security Architecture for the Internet Protocol. Number4301 in Request for Comments. The Internet Society (December 2005)8. Badra, M., Hajjeh, I.: Key-exchange authentication using shared secrets. Computer39(3), 58–66 (2006)9. Dolev, D., Yao, A.C.: On the security of public key protocols. In: Proc. Of 22Thannual symposium on foundations of computer science. IEEE Computer Societypress, Los Alamitos (1981)10. Smith, S., Weingart, S.: Building a high-performance, programmable secure coprocessor.Computer Networks 31, 831–860 (1999)11. Trusted Computing Group: TCG specification architecture overview. TechnicalReport Rev 1.2, Trusted Computing Group (April 28, 2004)12. IBM: Ibm extends enhanced data security to consumer electronics products.Technical Report,http://www.cio.com/article/20075/IBM to Offer Chip Based Encryption for PCs PDAs13. Alkassar,A.,Scheibel,M.,Sadeghi,A.R.,Stüble, C., Winandy, M.: Security architecturefor device encryption and vpn. In: Proc. of Information Security SolutionEurope (ISSE) (2006)14. Sadeghi, A.R., Stüble, C., Pohlmann, N.: European Multilateral Secure ComputingBase - Open Trusted Computing for You and Me. In: Datenschutz und Datensicherheit(DUD), pp. 548–554. Vieweg Verlag (2004)15. Alves-Foss, J., Taylor, C., Oman, P.: A multi-layered approach to security in highassurance systems. In: Proceedings of the 37th Annual Hawaii International Conferenceon System Sciences, Big Island, HI (January 2004)16. Vanfleet, W.M., Beckwith, R.W., Calloni, B., Luke, J.A., Taylor, C., Uchenick,G.: Mils: Architecture for high assurance embedded computing. CrossTalk 18(8),12–16 (2005)17. Gleeson, B., Lin, A., Heinanen, J., Armitage, G., Malis, A.: A framework for ipbased virtual private networks. Technical Report RFC 2764, IETF (February 2000)18. Bell, D.E., Fiske, R.S., Gasser, M., Tasker, P.S.: Secure on-line processing technology- final report. Technical Report ESD–TR-74–186, The MITRE Corporation,Bedford, MA (August 1974)19. Solutions, G.G.: XTS-400, STOP 6.0, User’s Manual. Getronics Government Solutions,LLC, Herndon, VA. Xtdoc0005-01 edn. (August 2002)20. National Computer Security Center: Final Evaluation Report of Gemini Computers,Incorporated Gemini Trusted Network Processor, Version 1.01 (June 28, 1995)21. Gligor, V., Burch, E., Chandersekaran, G., Chapman, R., Dotterer, L., Hecht, M.,Jiang, W., Luckenbaugh, G., Vasudevan, N.: On the design and implementationof secure xenix workstations. In: IEEE Symposium on Security, pp. 102–117 (May1986)22. Bickel, R., Cook, M., Haney, J., Kerr, M., Parker, T.: Guide to Securing MicrosoftWindows XP. National Security Agency (2002)23. Burger, W., et al.: Remote trusted path mechanism for telnet. Number 07/150966in Patent. International Business Machines Corporation, Armonk, NY (May 1989)

152 T.E. Levin et al.24. Xen User’s Manual. Xen v3.0 edn. University of Cambridge (2005)25. Barham, P., et al.: Xen and the art of virtualization. In: Proc. Nineteenth ACMSymposium on Operating System Principles, pp. 164–177 (2003)26. Epstein, J., et al.: Evolution of a trusted b3 window system prototype. In: Proc.of the 1992 IEEE Symposium on Research in Security and Privacy (May 1992)27. Anderson, M., North, C., Griffin, J., Milner, R., Yesberg, J., Yiu, K.: Starlight:Interactive link. In: Proceedings 12th Computer Security Applications Conference,San Diego, CA (December 1996)28. Epstein, J.: Fifteen years after tx: A look back at high assurance multi-level securewindowing. In: Computer Security Applications Conference. ACSAC 22nd Annual,pp. 301–320 (2006)29. National Security Agency. Executive Summary of the End-to-End IA Componentof the GIG Integrated Architecture. Version 1.0 edn. National Security AgencyInformation Assurance Directorate (April 2005)30. Wolfowitz, P.: Global Information Grid (GIG) Overarching Policy, directive number8100.1. U.S. Department of Defense (September 2002)31. OASIS Emergency Data Exchange Language (EDXL) Distribution Element. v1.0edn, http://docs.oasis-open.org/emergency/EDXL-DE/V1.0

Trustable Remote Verification of Web ServicesJohn LyleOxford University Computing Laboratory,Wolfson Building, Parks Road, Oxford, OX1 3QDjohn.lyle@comlab.ox.ac.ukAbstract. Service Oriented Architectures currently provide little or noevidence that each remote component has been implemented correctly.This is a problem for businesses hoping to exploit the potential benefitsof SOA. We present a technique called Trustable Remote Verification,which lets providers create behavioural guarantees of their web services.Our approach is flexible, using Extended Static Checking for verificationand has the significant advantage of requiring no additional trusted thirdparty.1 IntroductionAs applications and services move online, we are implicitly expected to placemore trust in the developers and providers of these systems. But how do weknow if a remote service is trustworthy? Bugs and vulnerabilities will continueto exist, and while dedicated providers might be considered more capable ofadministering systems than end users, they also become valuable targets forattack. As a single point of failure, a poorly implemented service will affecteveryone who relies upon it. We therefore need some way of establishing trustin remote systems.There are several issues to overcome before being able to trust an online application.Fundamentally, the users of a web service have no information about thequality of its implementation. Furthermore, most services only have a WSDL[1]description, which contains little semantic information, only method names andbasic data types. Without a more detailed behavioural interface, trustworthinessis difficult to establish. If we do not know how it should work, whether or notit has been programmed correctly becomes irrelevant. Finally, software installedat a service will frequently be patched and upgraded, usually without warningor notification. As a result, a relying party will potentially need to reassess itbefore every request.We have developed a solution to some of these problems which uses trustedcomputing and tools for specifying and verifying Java programs. A brief overviewof these in given in Section 2. In Sections 3, 4 and 5 we refine the problem,introduce the idea of Trustable Remote Verification, and present details of ourprototype. It is then evaluated and compared against existing solutions in Section6. Future work is discussed in Section 7 and in Section 8 we conclude.L. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 153–168, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

154 J. Lyle2 Background, Definitions and Related Work2.1 Remote AttestationRemote attestation is an authentication technique for trusted computing platforms.It uses the ‘TPM Quote’ operation to create a signed record of the attestingcomputer’s Platform Configuration Registers (PCRs)[2]. These are intendedto be used to record the platform’s boot process, including the bios, bootloader,OS and applications. A quote can therefore be considered trustworthy evidenceof what software has been run on the attesting platform. This is a valuable pieceof information, as it potentially gives a remote user the ability to identify andmake a judgement about the software that is running.In a basic server implementation, PCRs are held on a separate chip, theTrusted Platform Module (TPM), and store a 20 byte SHA-1 hash value. Thesevalues can only be modified by software through the extend(..) command.This appends the current PCR value to the supplied input, hashes it, and storesthe result in the PCR. A PCR value therefore reflects a chain of individualhashes. The TPM Quote operation takes a number of these PCR values andsigns them with the private half of an Attestation Identity Key (AIK), whichis held within the platform’s TPM. This AIK must have a credential, issuedby a trusted third party (a ‘Privacy CA’), which typically states that the platformhas a valid TPM[3]. Upon receiving a quote, therefore, it is necessaryto check that the AIK used has been certified by a trustworthy Privacy CA.Quotes can also contain a nonce, set by the challenger, in order to guaranteefreshness.On platforms which support authenticated boot, every piece of code executedin the boot process is hashed and extended into a PCR. This is done sequentially(a chain of trust), with each preceding step extending a measurement of the nextbefore allowing it to execute. This means that a malicious piece of code cannotbe run without its identity first being recorded. So long as every step in theprocess is trusted to perform measurements faithfully, it is possible to attestthat a platform is only running known pieces of software. Remote attestationis therefore about reporting system integrity measurements, as the modificationof any executable will be noticed. This is obviously attractive from a systemsecurity perspective, as it becomes possible to identify a machine which hasbeen infected with a virus or rootkit.However, attestation does not necessarily give any indication of a platform’ssecurity state but rather its execution state[4]. Sadeghi and Stüble[5] introducethe notion of ‘Property-Based Attestation’ (PBA) in order to simplify the process.In PBA, platforms provide a list of guaranteed security properties, ratherthan just a binary integrity measurement. This can be implemented in a numberof ways, but generally relies upon at least one party being able to match thePCR values to security properties, and then issuing certificates to this end. PBAis a level of indirection which can take some of the burden from the attestationrequester.

Trustable Remote Verification of Web Services 1552.2 Web ServicesWeb services are a well-established approach to creating large, component-basedapplications[6]. Services communicate and describe themselves using standarddata formats, such as SOAP[7] and WSDL, and have interoperability as a primaryrequirement. Each service offers some kind of useful functionality, but thereal benefit of SOA is that they can be combined together easily, allowing therapid creation of new, custom applications. These workflows also have the potentialto be very reliable, as services can be chosen and composed together atthe last minute. This means that an individual fault can be dynamically avoidedby choosing alternative services where necessary.However, many of the perceived advantages rely upon better specification andassurance of the component services. Without knowing precisely how each willbehave, it is difficult to use them in combination with any confidence. Testing webservices is also difficult, as they might exist in different administrative domainsor operate on live data. This becomes more of an issue when considering serviceswith critical functionality, such as in financial, medical or valuable intellectualproperty scenarios. Remote verification of web services therefore seems necessary,but few methods of doing so have been developed.2.3 JML and Design by ContractThe Design by Contract (DbC) approach advocates having a ‘precise definitionof every module’s claim and responsibilities’[8] in order to create reliableand, importantly, reusable components. This is exactly what we would like to/*@ requires@ accFrom != null && accTo != null && amount > 0;@@ ensures@ ((accFrom.getBalance() == \old(accFrom.getBalance())) &&@ (accTo.getBalance() == \old(accTo.getBalance())) ) &&@ (errLog.content.theSize == \old(errLog.content.theSize+1))@ ||@ ((accFrom.getBalance() == (\old(accFrom.getBalance()) - amount)) &&@ (accTo.getBalance() == \old(accTo.getBalance()) + amount) &&@ (transLog.content.theSize == \old(transLog.content.theSize+1)));@*/public void makeTransfer(Account accFrom, Account accTo, intamount) {...}Fig. 1. An example web method, complete with JML annotations. Two outcomes arespecified: either the account balances change in the expected way, or both remain thesame. An entry is added to the transaction log in the first case, and to the error log inthe second.

156 J. Lyleachieve with web services. Module interfaces are annotated with pre- and postconditionsin the form of requires and ensures clauses. There are also classinvariants, which express ‘general consistency constraints that apply to everyclass instance as a whole’[8]. Several annotation languages exist for the DbCmethodology, including Eiffel, Spec# and JML, the Java Modeling Language.JML[9] offers other language features, including specification of exceptions, nonnullannotations and class ownership. A simple example of JML can be found inFigure 1.2.4 ESC/Java2The annotations introduced by Design by Contract can be used for automaticsource-code checking. This is usually performed with a static analyser, whichattempts to verify assertions without ever executing the code. One such analyseris ESC/Java2[10], an extended static checker for Java and JML. It translates codeand annotations into logical terms, and then runs these through the Simplifytheorem prover, producing either a counter example or an ‘ok’ result.3 A Basic Web Service Behavioural Attestation ModelFor the purposes of this work, we assume a simple scenario where a servicerequester (R) wants to use a web service (W ). Before doing so, R wants to findout two things: what software is being run at W and what that software promisesto do. The first part can (in theory) be achieved through remote attestation,but the second is more difficult. The approach we have taken is to add JMLannotations to the service end point. This means that each web method caninclude pre- and postconditions, as well as other formal properties. Althoughonly Java services are supported, similar methods could be used with Spec# for.Net services, or any other Design by Contract language.However, we have yet to show that the annotations attached to a service arereally implemented. In this basic architecture, a Trusted Compilation Service (C)fulfils this role. The source code (W src )ofW is compiled and checked against itsannotations (W ann )byC, using a method such as model checking. A certificateis then produced by C which contains a hash of the compiled application (W bin ),a list of any dependent libraries used in the compilation process and an assertionstating which program properties hold. W can then present this certificate to R,along with a fresh remote attestation 1 ,andR will have a much greater level ofconfidence that W has the promised behaviour.There are a number of assumptions. R must trust that C will do a thoroughanalysis of the source code at W . W must trust C with all the source code,which may not be possible. More fundamental assumptions include:1 The fresh attestation must, of course, contain an entry which is identical to W bin .If it does not, then the certificate produced by C cannot be used to validate thisservice.

Trustable Remote Verification of Web Services 157– C must be capable of analysing the source code at W . This is not a trivialtask, and may depend on the availability of numerous code libraries, operatingsystem features, and so on.– The middleware and OS running at W must also be trusted by C and R.– All important configuration settings must be either made available to C or R.This might be undesirable if they contain passwords or confidential settings.– The middleware and OS must be attestable. Each part of the software stackmust support integrity measurement. It must be possible for R to receive aremote attestation from W and interpret it. This implies the existence of anintegrity management infrastructure, which has a list of ‘known-good’ piecesof software. Every binary running at W will need to be on this list.Overall, this is a proposal for using Remote Attestation to establish meaningfulproperties of a web service. However, there are a number of drawbacks, includingthe requirement for a trusted third party, C. The rest of this paper introducesTrustable Remote Verification, which allows us to remove C altogether.4 Trustable Remote VerificationThere are generally two approaches to program verification. It can be done by atrusted third party, but they may charge a high price for their services. They arealso a target for attack, and should be avoided if at all possible. The alternativeis to verify an application locally. If source code can be inspected before compilation,any errors can potentially be spotted before it is run. However, giventhe size of any complex application, even a highly skilled programmer wouldstruggle to spot potentially erroneous behaviour in source code. This has beenimproved by Proof Carrying Code[11], where the majority of the effort is carriedout by the application distributor. However, this is not a suitable solution forweb services, where all applications are running remotely. Users have no ideawhat source code is being run at the service, and have no way of verifying it.Neither third-party nor local analysis can be considered appropriate and insteadwerequiresomewaytolettheprovider perform verification, and then prove tousers that they have done so.4.1 OverviewTrustable Remote Verification (TRV) uses TPM attestations as credentials. Theservice provider performs program analysis using a local machine (the verificationplatform, V ) and then attests the result. To do this, V must be booted intoa trustworthy OS, which measures every step of the process and extends eachinto a PCR. After authenticated boot, the annotations (W ann ) which representthe service contract are measured. These will specify some important propertyof the service which the requester requires (see Figure 1 as an example). Thena program verifier (TV) is measured and loaded, and the source code (W src )isanalysed against its annotations. The result of this step (TV res )isalsomeasured

158 J. Lyle Fig. 2. An overview of the Trustable Remote Verification process, showing the orderof execution and all items measured into PCRsand extended into a PCR. Next, the source code is compiled by a trusted compiler,TC. A hash of it and all the compiled binaries (W bin ) are measured andextended. At the end of the verification process, a quote (V quote ) is producedwhich contains two sets of PCRs, holding measurements:{ }PCR 0..15 = { [ boot process at V ] }V quote =(1)PCR 21 = { TV,TC,W ann ,TV res ,W bin }AIK VThis is a credential, which will be used by the provider to show that a programbinary, W bin , was compiled from source code which was verified againstits annotations, with analysis result TV res . In the ideal case, TV res would statesomething simple such as ‘verified’. The credential can be checked by making surethat TV, TC and the boot process are all trustworthy, checking that TV res doesnot show any errors and finally verifying that the annotations are sufficientlystrong for the program to be trusted.At runtime, the service provider attests in the normal way, creating anotherquote:{ }PCR 0..15 = { [ boot process at W ] }W quote =(2)PCR 21 = { L bin }AIK WWhere L bin is the measurement of the binary that has been loaded at serviceruntime and will be accepting requests. In order for the V quote credential to beuseful, L bin must be equal to W bin .4.2 AssumptionsTrustable Remote Verification relies on several assumptions:– The platform performing verification has a valid TPM which has not beentampered with.– A PKI infrastructure for issuing AIKs exists and all platforms have validAIKs and certificates available to them.– There exists a verifier, a piece of software which can read the program contractand source code and automatically decide whether the latter correspondswith the former. This must run without any user interaction, and

Trustable Remote Verification of Web Services 159 Fig. 3. The chain of trust for Trustable Remote Verification, showing execution orderand measurement storagebe trusted to work properly by the client. In our proof-of-concept implementationwe have JML annotations as a contract and use ESC/Java2 forverification.– There is a simple operating system and boot loader, again trusted by theclient, which the verifier can run on without interference. This will measureall programs executed on the platform, and is itself measured as part of theboot process.– The verifier, compiler and operating system have SHA-1 identities known tothe client.– Any third-party libraries that the verified application uses are either annotatedand verified with the service, or their identities are published by theserver and trusted by the client.– All configuration files used by the web service or the verifier are made availableto the client.4.3 The New Chain of TrustTRV decouples the process of certification and application execution. This meansthat once the web service binary has been verified, it can be run on any servicewhich supports authenticated boot, and the same credential can certify it. Thisis desirable from an end-user perspective, as the amount of effort required to establishtrust in a set of remote services (perhaps implemented for load-balancingreasons) is greatly reduced. The disadvantage is that the chain of trust is nowlonger, and contains potentially two TPMs, one for the web server (TPM W )andone for the verifier (TPM V ).5 Prototype ImplementationWe developed two parts of this system: the credential-creation stage on V andrequester validation stage at R. In our prototype, services are written in Java,with methods from one class exposed as a web service. This class is annotatedwith JML assertions, which are the properties that this service promises to fulfil.ESC/Java2 is used as the program verifier (TV) and Ant plus the standard

160 J. LyleSun JDK are used as the compiler (TC). The result of compilation is a WAR 2file which is run from the Glassfish Application Server. We did not implementauthenticated boot for either the verification or web service, but several potentialcandidates exist for this purpose[12].5.1 Server Credential Creation StageThe program verification stage requires the following steps:1. The service source code and configuration files are placed onto V .2. An AIK certificate is obtained from a Privacy CA.3. The trustworthy OS with authenticated boot is started.4. The OS measures the JVM, and then runs the verifier. This measures thefollowing items into the TPM:– The front-end JML annotations of the service.– All libraries and files necessary for compilation.– The WAR archived created by compiling the service.– The output of running ESC/Java2.5. A quote (V quote ) is created, signed by the AIK, containing 2 sets of PCRvalues. One has the trustworthy OS and application measurements and theother has all the measurements made by the verifier.Additionally, an archive is created to help the service requester validate themeasurements. This includes references to external libraries, ESC/Java2 output,JML annotations and a log of the entire process. This is used by the requesterto validate the process later on. References to external libraries should point towhere the end user can download the library to verify its identity.V arch = { V quote , [ libraries ],W ann ,TV res , log , [ config files ] } (3)The compilation stage and WAR file creation is complicated by incompatibilities.Java web service annotations are only valid in Java 1.5 and above butESC/Java2 can only interpret version 1.4 source code. As a result, the servicemustbewritteninJava1.4andthenwrapped by an automatically-generatedJava 1.5 front-end class.5.2 Credential Validation StepsThe service requester, R, must obtain and verify the credential that was createdusing the steps in Section 5.1. This requires the requester to download V arch andobtain a fresh attestation of the web service’s current configuration, W quote ,andthen do the following:1. Check that the software running on W ,asreportedinW quote is trustworthy.2. Check that the currently-running web service application, L bin ,matchestheverified service identity W bin , included in V arch .2 Web application archive http://java.sun.com/developer/technicalArticles/Servlets/servletapi/

Trustable Remote Verification of Web Services 1613. Check the AIK used to sign W quote and V quote .4. Check the freshness of W quote . V quote is not time dependent, so a freshnesscheck is unnecessary.5. Check that V ’s OS and boot process are trustworthy.6. Check that the verification program (including TV and TC) is trustworthy.We imagine checking against a public list of verifiers (with available sourcecode) which are known to be sound and complete.7. V arch contains a log of the verification process, which will need to be checkedagainst the PCR values held in V quote .8. Each individual step described in the log must now be verified. The servermust provide any comparison resources that the client does not have accessto. This includes:– All configuration files used in the verification process.– The external libraries used and any assumptions made about them.– The verification result itself.– The verified service annotations.Additionally, some useful service properties must be described in the annotations,and the verification result should not show any situation where they donot hold. With our sample implementation, some of the checks described areperformed manually, but it would be feasible to create automated tools. Part 1and 5 require an integrity management infrastructure, such as IMI [13].5.3 Configuration Files and Compilation with AntBecause the credential-creation step is complex, involving program compilationand creation of web service artifacts, there are a number of configuration options.These could potentially make the verification process untrustworthy (forexample, running ESC/Java2 on one piece of software and then compiling andmeasuring another). Therefore, we measure the configuration files and includethem in V arch .Program compilation can also be complicated, involving libraries, configuration,and archive creation. As a result, most Java developers use Ant ratherthan just javac . For the compilation step of our prototype, we have to dealwith the same issues, so reusing the Ant build file seems sensible. However, Antis a powerful tool and it would be possible to write a malicious build file toavoid verification. In order to stop this from happening, the build file must bemeasured into the quote and included in V arch .Itmustalsobecheckedbytherequester, along with all the libraries and files it references. In our prototypethis is done manually.Another problem arises from runtime configuration. Most applications are designedto work differently at runtime depending on how they are configured. Ifany of the security properties of a service can be violated by a change of settingsfile, then they will (correctly) not pass the verification step of our system.The same is true for a service which depends upon a running database or human

162 J. Lyleinput. Essentially, any system that can be made to violate its specification aftercompilation will be a problem. The alternative method discussed in Section 7does not have this limitation.6 Evaluation6.1 Benefits of Trustable Remote VerificationIn our proposed system it is possible to determine, with a fairly high level ofassurance, something about what a remote service will do when invoked. Thissomething will range from a complete logical description of the functionality ofthe service, down to perhaps a simple invariant. In the example given in Figure1, we gain the knowledge that the method makeTransfer will at least revertback to our previous state rather than fail in an unknown way. We also knowthat the error log is guaranteed to keep track of any failures. In terms of security,we could use assertions about information flow to be sure of confidentiality. JMLhas been used before for security properties[14].JML’s ability to express useful properties (and ESC/Java2’s ability to checkthem) is a significant consideration when evaluating the prototype. There areproperties that cannot be expressed or checked, and the properties that theservice provider has asserted may not be important to the requester. BecauseESC/Java2 requires a significant amount of supporting JML, time must be spentannotating the source code for each particular property. However, this time canbe justified by considering some of the other benefits of Design by Contract, suchas improving documentation and overall code robustness. Furthermore, we mustalso assume that the requester will correctly understand the given properties,and not misinterpret a set of conditions or invariants which may be complex.More research is needed to find out where Trustable Remote Verification wouldbe most beneficial, but it is likely to be services which have simple propertiesto assert, such as the conditions in which an exception will be thrown, or thecorrect implementation of simple mathematical functions.No additional third party is required to create the service credentials, beyonda Privacy CA which may exist already. However, as noted in Section 5.2, anintegrity measurement infrastructure will be needed for verifying the trustedsoftware components, such as TC and TV. This may require a trusted thirdparty. The client and server-side code needed to implement these features isfairly small (the prototype is under 3000 lines of code), with the only significantextra requirement being an operating system that supports authenticated boot.Furthermore, this system allows for software update, as each new version of aservice can be re-verified and a new credential produced. This can be part ofthe standard build-cycle for a project. Another key benefit to this system overthe basic architecture is that the source code of the service never needs to berevealed, not even to a third party. This would be attractive to a company withvaluable or confidential code.

Trustable Remote Verification of Web Services 1636.2 Trustworthiness of the ArchitectureThe strength of TRV can be measured by how difficult it is for a provider tofalsely claim that a service has certain properties. Any system can be brokenthrough weaknesses in its trusted components, so we will now assess ours. Werely upon one (or more) TPMs, a verification OS, verification tool, compiler andthe software stack running at the web service. TPMs are designed to be immuneto software attack, and hardware attacks are non-trivial. They are thereforeunlikely to be the weakest point in the system.The verification environment also needs to be a trusted component. However,theverificationOScanbesmallandsimpleandonlyneedstobeabletoruna program verifier and compiler. It does not need network access, or the abilityto accept user input at runtime. Future CPUs which run bytecode might bea good way of avoiding vulnerabilities, as might a microkernel-based OS. Theverifier and compiler, on the other hand, are a bigger issue. They are necessarilycomplex systems, which accept input in the form of program code and configurationfiles. Arguably, however, we must already trust the compilers we use, andthere are several open source compilers which have gone through considerablescrutiny. A weakness in the verifier would be a problem. If it produced falsenegatives, it could then potentially certify a system which does not maintain itsproperties.Weoffernosolutiontothisproblem, but expect that creating oneacceptable verifier or compiler is likely to be easier than creating many perfectapplications.Perhaps the most significant trusted element is the rest of the software runningat the web service. If a bug or vulnerability causes it to behave in an unexpectedmanner, then the properties guaranteed by the web service application are irrelevant.This is likely to happen, as the amount of code running which has notbeen formally checked greatly outweighs the small amount that has. It includesthe service middleware, operating system, and any libraries that the service reliesupon. This ‘middleware problem’ has been discussed in a grid scenario byCooper and Martin[15], and solutions involving virtualization sound promising.This problem is true of almost all trusted computing systems involving legacyapplications, and ours is no exception.Overall, TRV is clearly limited in the level of trust it can establish, and isnot appropriate for extremely high assurance systems. Instead, it would workbest as an additional check for service providers who are attempting to improvetheir perceived reliability in the marketplace. In such a scenario, one threat isthat a company with normally good intentions tries to subvert the system fora new version of their service. They might try to rush a new feature, at theexpense of verification. TRV would make this much more difficult to do, andso the provider would be more likely to spend the extra effort on verificationinstead.6.3 Related WorkHaldar et al. [16] introduce Semantic Remote Attestation, a technique for verifyingthe remote behaviour of a platform. They use a Trusted Virtual Machine

164 J. Lyle(TVM) to attest to high-level properties of the running code. The presence ofthe TVM is attested first using normal methods, then the TVM can reporton properties such as class hierarchies, Java VM security constraints and runtimedynamic state. Arbitrary properties can also be tested by requesting theTVM accept and run code written by the requester. This is a powerful technique,offering remote users the ability to make better trust decisions. However,the focus of this work is on dynamic feedback and testing rather thanshowing formal properties. We feel that our work compliments this by provingdifferent semantic properties. Our approach is also significantly different, notrelying on a runtime virtual machine, thus removing any potential performanceissues.Yoshihama et al. [17] and Monetoh et al. [13] have created and extendeda web service attestation architecture called WS-Attestation. It uses a thirdparty Validation Service (VS), which maintains an integrity database, linkingsoftware hash values to known application identities. The VS also has accessto a vulnerability database. The idea is that the attesting platform reports itsintegrity measurement to the requester along with a certificate issued by theVS. This certificate can state a more easily interpreted property, such as thenumber of known vulnerabilities. However, this system is best suited to verifyingthe integrity of the OS and middleware of a platform, rather than ofa custom application, which is unlikely to have any entries in the vulnerabilitydatabase. It is also not clear how properties beyond vulnerability counts might beestablished.Betin-Can et al. [18] use a design for verification approach to verify services.They introduce the ‘Peer Controller Pattern’ which separates out the messageexchange from the logic, simplifying the verification process. An explicit behaviouralinterface is also generated. Assertions that are known to hold in individualservices are then combined and the behaviour of the whole system can bechecked with regard to synchronizability. Individual implementations are consideredto conform with their interfaces if their call-sequences are acceptable to itsstate machine. This is verified using the JavaPathFinder model checker. It seemsan excellent approach when considering concurrency issues, but does depend onall source code being available to the verifier, with trust in remote parties beingless of an issue.Tsai et al. [19] describe a framework (‘WebStrar’) for web service assurance.Services are registered and a series of tests are performed on it. Each servicehas a specification written in OWL-S and this is checked via ‘Completeness andConsistency’ analysis and model checking of the specification and verificationpatterns. There is also a step involving positive and negative test cases, which allgo towards ranking the services in terms of reliability. This approach is a logicalway of gaining assurance, but does have some issues. Testing is not appropriatein a situation where the service operates on live data, and it is also not clearwhether the tested services have any obligation to re-register in the case of achange to their implementation.

7 Observations and Future WorkTrustable Remote Verification of Web Services 1657.1 Runtime Checking and Compile-Time TranslationA similar but alternative approach to the one taken in our prototype is to usethe JML compiler[9], jmlc, as opposed to the Java compiler. Jmlc adds runtimeassertion checks into the program bytecode in addition to normal compilation.These will raise an exception if any of the preconditions, postconditions or invariantsfail. Except for a small performance hit, this behaviour is transparentunless one of the assertions is violated.The advantage of this scheme is that we no longer need to perform staticanalysis. This was one of the issues identified in Section 6.2. As a result, runtimecomponents such as configuration files and databases can be accessed withoutbreaking the assertions. However, the major downside is that an untrustworthyservice can make promises, and then break when they are not fulfilled. This mightresult in lost data and an unreliable system. The best this would be able to sayis that if the service does not fail, it will work as expected. However, despitethese limitations it may be worth investigating in the future. This approach issimilar to earlier work by Haldar et al. [16].7.2 Multiple Verifications and the New Chain of TrustOne useful property of our system is that the credential-creationprocessisentirelyseparate from the runtime attestation. As a result, we can extend ourprototype to offer multiple, potentially independent verifications and certificatesfor the same service. For example, one service provider could first verify theirsource code with ESC/Java2, producing a certificate, and then do the same withan alternative program analyser. This might satisfy users who will only trust aparticular analysis program.We can go even further, and let multiple organisations verify the same service.Assuming they are given the source code, they can all independently run a verifierand produce a certificate. This significantly strengthens the chain of trust, as itis no longer ‘anchored’ by just one TPM. Figure 3 is no longer as big a problem,as the top chain can be put in parallel with several others. This might be usefulfor high-assurance systems, such as e-voting.7.3 Using a Dynamic Root of TrustOne way in which we could optimise our proposed TRV system, with respect ofthe number of integrity measurements, would be to use a dynamic root of trust.Rather than measuring every part of the boot process, including the BIOS, wecould use either AMD’s Secure Virtual Machine (SVM) architecture or Intel’sTrusted Execution Technology (TXT) to dynamically load and measure (‘latelaunch’) a trustworthy operating system. McCune et al. [20] provide a goodsummary of these technologies. This would reduce the number of measurementsthat the service requester needs to verify, and therefore make the overall system

166 J. LyleCert B0Pre: ...Post: Q or ZVerifier: ESC/Java2Cert B1Pre: ...Post: ZVerifier:TrustedThird Party Cert A0Pre: ...Post: X and YVerifier: ESC/Java2Cert A1Pre: ...Post: X and WVerifier: SPINCert A2Pre: WPost: YVerifier: NoneFig. 4. The challenge of verifying service workflowstrustworthiness easier to quantify. With the recent development of a suitablebootloader[21] this would be a sensible future improvement.7.4 Verifying Multiple ServicesWe have not considered verifying web services which themselves contact otherservices. This is quite a common scenario, and a significant limitation of ourprototype. However, there do not seem to be any obvious reasons why any serviceswhich have also followed this scheme could not be incorporated. These ‘subservices’ could be wrapped by a stub object, which asserts the same annotatedproperties. This would not be verified, and instead all the certificates could bepresented to the user. Implementing this in a user friendly and secure mannerwould be a challenge.Presenting multiple service certificates presents another set of problems.Firstly, what happens if one of the sub services is not considered trustworthy?This could be for a number of reasons, for example the verification tool might beout of date, or the AIK certificate could have expired. The implications of thismay affect all or part of the overall combined service. Secondly, do we still trusta system with so many trusted components? If a TPM was successfully attackedon any of the sub services it might compromise the whole process. Finally, itis possible that we will be contacting services which do not use this certificationsystem. They may have a different trust mechanism, or none at all. How toweight the trustworthiness of this service is an open question.8 ConclusionWe have introduced the idea of Trustable Remote Verification, a technique whichallows a service provider to verify its own software and create a trustworthyguarantee of the result. The main advantages are that no new third partiesare needed, and providers can easily create a new verification result whenever

Trustable Remote Verification of Web Services 167necessary. Furthermore, one verification can be used as a credential for manyplatforms. We have also identified the key shortcomings and limitations to ourwork, including the large amount of necessarily trusted code, and the need for anannotated, verifiable service. However, our prototype implementation uncoveredfew additional issues, and we feel justified in persuing these ideas further. Overall,this technique has great potential, and could be a viable way of adding assuranceto Service Oriented Architectures. Future work will concentrate on finding wherethe best applications of this idea are, what properties it can guarantee, andwhether architectural approaches can be used to reduce the trusted computingbase of verified services.AcknowledgementsSpecial thanks go to Andrew Martin and Jun Ho Huh for several helpful discussionswhile writing this paper and developing the concepts. I am also grateful toJoe Loughry, Andrew Cooper, Shamal Faily and Cornelius Namiluko for theircomments. Finally, I thank the reviewers for their useful and positive feedback.References1. Christensen, E., Curbera, F., Meredith, G., Weerawarana, S.: Web Services DescriptionLanguage (WSDL) 1.1. Technical report, W3C (March 2001),http://www.w3.org/TR/2001/NOTE-wsdl-200103152. The Trusted Computing Group: TCG Specification Architecture Overview, Revision1.4 (August 2007), https://www.trustedcomputinggroup.org/groups/TCG 1 4 Architecture Overview.pdf3. The Trusted Computing Group: TCG Glossary of Technical Terms (2008),https://www.trustedcomputinggroup.org/groups/glossary/4. Poritz, J.A.: Trust[ed | in] Computing, Signed Code and the Heat Death of theInternet. In: SAC 2006: Proceedings of the 2006 ACM Symposium on AppliedComputing, pp. 1855–1859. ACM Press, New York (2006)5. Sadeghi, A.R., Stüble, C.: Property-based Attestation for Computing Platforms:Caring About Properties, Not Mechanisms. In: NSPW 2004: Proceedings of the2004 Workshop on New Security Paradigms, pp. 67–77. ACM Press, New York(2004)6. Papazoglou, M.P., Dubray, J.j.: A Survey of Web Service Technologies. TechnicalReport DIT-04-058, Informatica e Telecomunicazioni, University of Trento (June2004)7. The W3C: Simple Object Access Protocol (SOAP) (April 2007),http://www.w3.org/TR/soap/8. Meyer, B.: Design by Contract: Building Reliable Software. In: Object-OrientedSoftware Construction, pp. 331–341. Prentice Hall, Englewood Cliffs (1997)9. Leavens, G., Cheon, Y.: Design by Contract with JML (2003),http://citeseer.ist.psu.edu/leavens04design.html10. Cok, D.R., Kiniry, J.R.: ESC/Java2: Uniting eSC/Java and JML. In: Barthe, G.,Burdy, L., Huisman, M., Lanet, J.-L., Muntean, T. (eds.) CASSIS 2004. LNCS,vol. 3362, pp. 108–128. Springer, Heidelberg (2005)

168 J. Lyle11. Necula, G.: Proof-Carrying Code. Website (July 2002),http://raw.cs.berkeley.edu/pcc.html12. Jaeger, T., Sailer, R., Shankar, U.: PRIMA: Policy-Reduced Integrity MeasurementArchitecture. In: SACMAT, pp. 19–28 (2006)13. Munetoh, S., Nakamura, M., Yoshihama, S., Kudo, M.: Integrity Management Infrastructurefor Trusted Computing. IEICE Transactions on Information and SystemsE91-D(5), 1242–1251 (2008)14. Pavlova, M., Barthe, G., Burdy, L., Huisman, M., Lanet, J.L.: Enforcing High-LevelSecurity Properties for Applets (2004)15. Cooper, A., Martin, A.: Towards a secure, tamper-proof grid platform. In: CCGRID2006. Sixth IEEE International Symposium on Cluster Computing and the Grid,2006, vol. 1, p. 8 (May 2006)16. Haldar, V., Chandra, D., Franz, M.: Semantic Remote Attestation - Virtual MachineDirected Approach to Trusted Computing. In: Virtual Machine Research andTechnology Symposium, USENIX, pp. 29–41 (2004)17. Yoshihama, S., Ebringer, T., Nakamura, M., Munetoh, S., Maruyama, H.: WSattestation:efficient and fine-grained remote attestation on Web services. In: ICWS2005. Proceedings. 2005 IEEE International Conference on Web Services, pp. 743–750 (July 2005)18. Betin-Can, A., Bultan, T.: Verifiable Web services with Hierarchical Interfaces. In:ICWS 2005. Proceedings. 2005 IEEE International Conference on Web Services,vol.1, pp. 85–94 (July 2005)19. Tsai, W., Wei, X., Chen, Y., Xiao, B., Paul, R., Huang, H.: Developing and assuringtrustworthy Web services. In: Autonomous Decentralized Systems, 2005. ISADS2005. Proceedings, pp. 43–50 (April 2005)20. McCune, J.M., Parno, B.J., Perrig, A., Reiter, M.K., Isozaki, H.: Flicker: an executioninfrastructure for tcb minimization. In: Eurosys 2008: Proceedings of the3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008, pp.315–328. ACM, New York (2008)21. Wei, J., Cihula, J., Wang, S.: Trusted Boot Sourceforge Project Website (2008),http://sourceforge.net/projects/tboot/

Trustworthy Log Reconciliation for DistributedVirtual OrganisationsJunHoHuhandJohnLyleOxford University Computing LaboratoryWolfson Building, Parks RoadOxford, OX1 3QD{jun.ho.huh,john.lyle}@comlab.ox.ac.ukAbstract. Secure management of logs in an organisational grid environmentis often considered a task of low priority. However, it must berapidly upgraded when the logs have security properties in their ownright. We present several use cases where log integrity and confidentialityare essential, and propose a log reconciliation architecture in whichboth are ensured. We use a combination of trusted computing and virtualizationto enable blind log analysis, allowing users to see the results oflegitimate queries, while still withholding access to privileged raw data.1 IntroductionThe notion of a Virtual Organisation (VO) runs commonly through many definitionsof what constitutes a grid: “many disparate logical and physical entitiesthat span multiple administrative domains are orchestrated together as a singlelogical entity” [15]. The rise of many types of organisational grid systems,and associated security threats, makes the provision of trustworthy audit-basedmonitoring services necessary; for instance, to monitor and report violation ofservice-level agreements [18], or to detect events of dubious user behaviour acrossmultiple domains and take retrospective actions [17].In reality, a lot of these audit-based controls are prone to be compromiseddue to the lack of verification mechanisms for checking the correctness and theintegrity of logs collected from different sites; and also because some of theselogs are highly sensitive, and without the necessary confidentiality guarantees,neither trusts the other to see the raw data. Many log anonymisation techniqueshave been proposed [9,12,19] to solve the latter issue; however, adapting suchtechniques and assuring that these anonymisation policies will be correctly enforcedat a remote site, is a whole new security issue. The problem with existingsolutions is that they provide only weak protection (or none) for such securityproperties upon distributed log collection and reconciliation (Section 3).In our previous work [8] we have proposed a logging infrastructure using thedriver virtualization in Xen that enables trustworthy generation and storage ofthe log data. In this paper, we take a step further and describe a log reconciliationmethod for guaranteeing their integrity and confidentiality.L. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 169–182, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

170 J.H. Huh and J. LyleThe rest of the paper is organised as follows. In Section 2, we present a numberof motivational examples and highlight distinct security challenges with processingdistributed log data. Section 3 discusses the security gaps of existingsolutions. Then, in Section 4, we present the trustworthy log reconciliation requirementswhich address these security gaps. Mindful of such requirements, wedescribe a reconciliation infrastructure for a VO in Sections 5 and 6. Finally, inSection 7 we discuss the contribution of this paper and the remaining work.2 Motivational Examples2.1 Healthcare Grids and Dynamic Access ControlThe first example application arises in the context of a healthcare grid. In ‘e-Health’, many data grids are being constructed and interconnected in order tofacilitate the better provision of clinical information. Each clinic (an independentlegal entity) participating in the grid owns and manages physical databases whichtogether form the virtualized clinical data and log stores. To motivate the usecases described later in this section we use an abstract viewoftheVO(seeFigure1): each node consists of external and internal services where the virtualizationof data sources takes place; it also has its own local data and logs; a standardexternal service enables communication between different nodes.Consider the following example in the context of Figure 1. A simplified healthcaregrid consists of two nodes, a GP Practice (GP ) and a Specialist Clinic (SC).A patient in GP is often referred to SC to see a specialist. We shall assume thata single table at each clinic (T 1 ,T 2 ) is made accessible to a researcher R, andthat the National Health Index (NHI) uniquely identifies a patient across thegrid to enable the linking of data. R is carrying out a study that looks at associationbetween smoking status (T 1 ) and development of lung cancer (T 2 )inthepopulation of Oxfordshire.R has originally been granted full access to both T 1 (at GP )andT 2 (at SC)to conduct this research. By joining the data across two clinics, R would haveaccess to potential identifiable information about patients: for example, R couldFig. 1. Abstract View of the Virtual Organisation

Trustworthy Log Reconciliation for Distributed Virtual Organisations 171find out that patient 1, born on the 20/05/88 and living in OX2 5PS who hasDr. Anderson as their GP, is a smoker and has a lung cancer.GP Practice (GP ) T 1NHI DOB GP Smoke Risks1 20/05/88 Dr. Anderson yes overweight2 30/07/88 Dr. Anderson no allergiesSpecialist Clinic (SC) T 2NHI Postcode LungCancer1 OX2 5PS yes2 OX2 6QA noIn a secure VO, as soon as R finds out from querying T 2 that patient 1 haslung cancer, R’s access on T 1 for patient 1 needs to be restricted to, for example,only the NHI and Smoke fields. For GP to have restricted R’s access rights toinformation pertaining to patient 1 on T 1 , would have required GP to collectdata access logs from SC to build up a picture of what R already knows, andto update its own access control policies to prevent R from collecting potentialidentifiable information. Although, in general, SC would never give out patients’lung cancer status in the form of audit logs to an untrusted GP .This type of distributed audit approach has been suggested [17] to detectpatterns of behaviour across multiple administrative domains by combining theiraudit logs. However, the problem arises from the fact that log owners do not trustother sites to see their privileged raw logs. This approach will only work if logowners can be assured of confidentiality during transit and reconciliation.2.2 The Monitorability of Service-Level Agreements (SLAs)The provision of Service-Level Agreements (SLAs) and ensuring their monitorabilityis another example use for trustworthy log reconciliation.A SLA is a contract between customers and their service provider which specifiesthe levels of various attributes of a service like its availability, performanceand the associated penalties in the case of violation of these agreements. Considera case where the client receives no response for a service (for which theyhave entered into a SLA) within the agreed interval of time, complains to theprovider that a timely response was not received and requests financial compensation.The provider argues that no service request was received, and producesa log of requests in their defense. There is no way for the client to find out thetruth: the provider could have delivered tampered evidence regarding this event.The problem with this type of SLA is that it is defined in terms of events thatthe client cannot directly monitor, and they must take the word of the providerwith respect to the service availability.Skene et al [18] suggest a way of achieving the monitorability with trustedcomputing. This involves generating trustworthy logs, ensuring that unmodified

172 J.H. Huh and J. Lylelogs have been reported by both parties and that these logs have been usedfor monitoring SLAs. For instance, if the client is able to verify with remoteattestation that trustworthy logging and reporting services operate at a remotesite, then the client may place conditions on any event of their interest andconstruct more useful SLAs. This approach needs to guarantee the integrity ofall service request/response logs to an evidential standard (i.e. to a standardacceptable for judicial usages) upon distributed reconciliation and analysis. Amonitoring service would then be able to generate a reliable SLA report for theclient to make claims.Logs often contain sufficient information to be used as evidence in a varietyof context. However, the inability of a site to verify the integrity of logs collectedfrom other sites and the lack of guarantees that their own logs are being usedunmodified at remote sites, make it extremely challenging for one to adapt theusual audit-based monitoring method to the VO.3 Relevant Work and a Gap AnalysisHaving identified the security challenges of imposing audit-based controls, weare now in a position to present a gap analysis on existing solutions.DiLoS (Distributed General Logging Architecture for Grid Environments) [5]provides general logging facilities in service oriented grid environments to enabletracking of the whole system. One of its application models is to facilitate accountingfor resource-providing services: to measure and annotate who has usedwhich services, and to bill usage prices. In this accounting domain, however,DiLoS does not consider the log integrity issues and the possible threats thathave been covered in Section 2.2. Without security mechanisms to protect logintegrity, their architecture cannot be relied upon to perform calculating andbilling functions.Piro et al [14] have developed a more secure and reliable data grid accountingsystem based on metering resource usage. All communications are encrypted [13];but a privileged user may still configure the Home Location Register (HLR), acomponent that collects remote usage records for accounting, to disclose sensitiveusage records. A rogue resource owner may modify the Computing Element(CE), which measures the exact resource usage, in order to fabricate recordsand prices for profit.The NetLogger Toolkit [20] provides client application libraries (C, Java,Python APIs) that enable one to generate log messages in a common format. Italso includes monitoring tools for log collection and analysis at a central point.Again, the log integrity and confidentiality threats discussed in the previoussection undermine their approach: access requests are processed without any authorisationpolicy enforcement, and the logs are transferred across the networkin an unencrypted and unsigned format. No attempt is made to safeguard thelogs while they are being collected and processed at the reconciliation point.Similar security problems undermine other existing grid monitoring tools suchas APEL (Accounting Processor for Event Logs) [3], which builds accounting

Trustworthy Log Reconciliation for Distributed Virtual Organisations 173records from system and gatekeeper logs generated by a site; and GMS (GridMonitoring System) [11], a system that captures and stores job information ina relational database, and supports resource usage monitoring and visualising.4 Trustworthy Log Reconciliation RequirementsTo fill the security gaps identified above, we provide a high-level overview of thekey requirements with respect to our motivational examples.Log Migration Service. Due to the number of potential security vulnerabilities,complex grid middleware services can not be relied upon to perform trustedoperations [4]. Instead the security controls required for safe log data transferneed to operate within a more secure migration service. This implies data flowencryption and signing requirements upon log access and transfer requests. Theseare integral in preventing intruders from sniffing the logs processed through insecuregrid middleware, and from launching man-in-the-middle type of attacks. Itis also possible for a log owner to deliver fabricated logs, as the service providermight do in the SLA example. To provide a safeguard against such a threat, themigration service needs to access the signed logs (and the original logs) directlyfrom the protected log storage. This would give sufficient information for an enduser to verify the log integrity.Log Reconciliation Service. Our examples have a common set of requirementsfor a trustworthy reconciliation service. They require each site to negotiate withothers and grant permissions to view their logs. These sites (before granting permissions)need to be assured that their logs will not be compromised and will beused without modification. The integrity and the confidentiality of the collectedlogs as well as the processed results (e.g. summaries on SLA violation) need to beprotected to prevent a malicious user from modifying or stealing them.To make it harder for insiders to gain unauthorised access and modify thereconciled logs, this service needs to run in a strongly isolated compartmentwith robust memory protection. It should also be a small and simple code tominimise the number of security holes that might be exploited.Blind Analysis of the Logs. Returning to our healthcare example, imaginethat SC has agreed to share their logs with GP for dynamic access control. Butat the same time they are unwilling to let the system administrator at GP seethe actual contents of the logs; or only let part of the data be seen as a summaryinformation. For example, “R’s access rights on T 1 for a patient with NHI 1,aged 20 and living in OX2 area, have been restricted to NHI and Smoke fields.”.Such anonymisation of end results ensures that the administrator cannot findout about a patient’s lung cancer status, and yet, still know exactly how theaccess control policy has been changed for R.Log owners need to be assured that any sensitive information contained intheir logs will only be revealed to an extent that has been agreed and stated in

174 J.H. Huh and J. Lyleanonymisation policies: this requires a mechanism, possibly within the reconciliationservice, to carry out a blind analysis of the collected logs so that a useronly sees the running application and the end results, which are just sufficientfor them to carry out post log analysis or to know about the important systemupdates.5 Trustworthy Logging ArchitectureIn our previous work [8], we have developed a logging architecture based onVirtual Machine (VM) isolation and remote attestation (see Figure 2). Uponinstallation of this architecture, each VO participant will be capable of generatingand storing log data, and proving to other sites that these logs are trustworthy.The Trusted Computing Group (TCG) [1] has developed a series of technologiesbased around a Trusted Platform Module (TPM) which helps to provide twonovel capabilities [7]: a cryptographically strong identity and reporting mechanismfor the platform, and a means to measure reliably a hash of the softwareloaded and run on the platform (from the BIOS upwards); such measurementsare stored and retrieved from Platform Configuration Registers (PCRs) in theTPM. These provide the means to seal data so that it is available only to a particularplatform state, and to undertake remote attestation: proving to a thirdparty that a remote device is in a particular software state. TPM-generatedAttestation Identity Keys (AIKs) are used to sign PCR values and to preventtracking of platforms. These trusted computing capabilities can be used in a virtualizedenvironment where a physical host is segmented into strongly isolatedcompartments to make attestation feasible (with robust memory protection),and to limit the impact of any vulnerability in attested code. Our architectureuses the Xen Virtual Machine Monitor (VMM) [2] to achieve this isolation: athin layer of software operating on top of the hardware to enable VM abstractionand control the way a VM accesses the hardware and peripherals.All log security functions are enforced by the log security manager VM, a smallamount of code running inside back-end driver VMs and the log analysis managerVM; each of which has been designed to perform a small number of simpleoperations so that it can be compartmented with a high degree of assurance.Fig. 2. Abstract View of Trusted Logging Services

Trustworthy Log Reconciliation for Distributed Virtual Organisations 175Attestation of these compartments, the Policy Enforcement Point (PEP) andthe VMM is sufficient for one to establish trust with a VO platform, and tobe assured that its log security functions have not been subverted; this is ourTrusted Computing Base (TCB).A small number of trusted back-end driver VMs are responsible for generatingall logging requests upon use of device drivers. All other VMs must communicatewith one of these driver VMs to access the physical hardware. Inside these VMs,the log transit component collects important I/O details and submits requeststo the log security manager. Applications and middleware services running inother compartments are no longer relied upon to generate trustworthy log data.The log security manager performs a range of security functions through thefollowing services:– The logging service ensures that no adversaries can access or modify thelog data dispatched from log transits. It filters out untrustworthy loggingrequests and verifies their integrity before storing them.– The reconciliation service facilitates trustworthy reconciliation and transformationof the collected logs. It enables blind analysis of the logs by enforcinganonymisation policies.– The migration service is an external service which facilitates secure communicationbetween VMs in one or more sites by enforcing security controlsrequired for safe log transfer.End-user applications only have access to the externally facing visualisationservice running inside the log analysis manager, which provides the minimalinterface necessary for user applications to interactively analyse the processedlog information. A compartment manager within the PEP executes a job in aper-user log access VM configured with trustworthy services. The grid servicescompartment isolates the middleware stack and is untrusted; it performs resourcebrokering and job scheduling.6 Trustworthy Log ReconciliationBased on the work in previous section and the requirements analysed in Section4, we present a trustworthy reconciliation infrastructure.6.1 The Configuration ResolverWe expand our abstract view of the VO to include a Configuration Resolver(CR) that manages metrics about the available sites in the VO and their currentsoftware configurations. To become part of the VO a site needs to first registeritself with the CR by submitting the PCR representations of its TCB and logaccess VM image files, and a credential containing its public key for which theprivate-half has been sealed to both PCR values. The CR then creates a ConfigurationToken (CT) from this information:

176 J.H. Huh and J. LyleCT =(PCR AIKS(N) (TCB),PCR AIKS(N) (LA),cred AIKS(N) (P K ))A trustworthy PCR(TCB) value proves that secure logging VMs have beenresponsible for generating and protecting the log data; this allows a participant tohave high confidence in the correctness of the logs stored in node N.Furthermore,a trustworthy PCR(LA) value guarantees the security configurations of a logaccess VM. A value of PCR(LA) isstoredinaresettable PCR 23 because theseVM image files will be remeasured and verified by the PEP at run-time beforebeing launched.The CR acts as a token repository in our system and offers no other complexfunctionality. The burden of verifying tokens is left to the participant. This isattractive from a security perspective, as the CR can remain an untrusted component.The worst that a malicious CR can do is affect the availability of theinfrastructure. However, the simple CR does increase the management overheadon each node. They will all need the ability to check tokens. This involves maintaininga list of trustworthy software (a white-list), and keeping a revocation listof compromised TPMs and platforms. The security of our system depends on theproper management of this information. We suggest that a suitable compromisemight be to devolve some of this functionality to local proxy-CRs, which wouldperform the token filtering for one specific administrative domain. This keepscontrol local to one site, but would decrease the effort at each individual node.To conform to existing standards, we imagine that CR would be implementedas a WS-ServiceGroup [10]. Each node would then be a member of this CR’sgroup, and have a ServiceEntry in its list. The membership constraints wouldbe simple, requiring only a valid token and identity. We assume that there isa public key infrastructure available to verify their identity. As a result, thelevels of indirection introduced by the TCG to prevent any loss of anonymityare unnecessary. We would suggest that the Privacy CA is not a key componentof the system, and a publically-available one could be used. AIKs can be createdas soon as the platform is first installed, and should very rarely need updating.6.2 Trustworthy Log Reconciliation InfrastructureWith the resolver in place, security procedures of the reconciliation infrastructurehave been carefully designed. Our healthcare example in Section 2.1 has beenrevisited to explain these procedures.Creation and Distribution of a Log Access Grid Job. All end user interactionswith a clinic node are made via the visualisation service. It providesthe minimal interface (APIs) necessary for development of grid-enabled applications.An analysis tool should be designed to allow a user to select acceptablehost configurations and user credentials, and enter the log access code/query (1,numbers refer to Figure 3).A system administrator at GP , using one of these tools, requests for dynamicupdates on the local access control policies. The visualisation service requestsfor the list of available configuration tokens (CTs) (2, 3, Figure 3); the list is

Trustworthy Log Reconciliation for Distributed Virtual Organisations 177Fig. 3. Creation and Distribution of a Log Access Grid Jobforwarded to the log migration service running inside the log security manager(4, Figure 3). The migration service makes a list of acceptable hosts by comparingeach CT against a user-specified white-list. It then creates a set of gridjobs, each of which contains the administrator’s credential, log access code, jobdescription, a nonce (N GP ) and an Attestation Token (AT ) that can be used byany SCs to verify the security state of the system running at GP (5, Figure3);AT consists of the following information:AT =(PCR AIKS(GP ) (TCB GP ),cred AIKS(GP ) (P K ))cred AIK(GP ) (P K )isGP ’s P K credential which identifies the correspondingS K as being sealed to PCR(TCB GP ).For each job, the credential, the code and N GP are encrypted with a P K (SC)obtained from a CT to prevent an adversary from modifying the code and toensure that the credential is only revealed to a trustworthy SC. The use of thenonce, N GP , is explained further on in this section. After encryption, these jobsare sent across the network via an untrusted grid middleware compartment whichcan only read the job description to identify the target SC; jobs are submittedto the PEPs of their target nodes that handle job submission (6, Figure3).Operations of a Trusted Log Access VM. In Figure 4 we take a closerlook at how a job gets processed at one of the target nodes, SC A . Any securityprocessing required before becoming ready to be deployed in a per-user log accessVM is done through the PEP: it compares PCR AIKS(GP ) (from AT )withitssetof known-good values stated in a policy to verify that the job has been createdand dispatched from a correctly configured log security manager; this is howthe job is authenticated at SC A (1, Figure 4). Upon successful attestation, thePEP first measures the local copy of log access VM image (and a configuration

178 J.H. Huh and J. LyleFig. 4. Submission of a Grid Job, Creation and Operations of a Log Access VMfile), and resets PCR 23 with the new measurement, PCR(LA A ); this imageconsists of the guest OS and the trusted middleware stack (authorisation policymanagement and migration services) which provides a common interface fora job to access the logs. The PEP then attempts to unseal the decryption key,S K (SC A ) (bound to PCR(TCB A )andPCR(LA A )), in order to decrypt the job.Note that S K (SC A ) will only be available if SC A is still running with trustworthyconfigurations and the VM image files have not been subverted. This is intendedto guarantee that only a trusted VM has access to the decrypted credential, codeand N GP .If these security checks pass, the compartment manager launches a trustedVM from the verified VM image files, and deploys the decrypted job on topof the middleware stack (2, Figure 4). The migration service first requests thepolicy management service to decide whether the administrator is authorised toview the requested logs (3, 4, Figure 4). If the conditions are satisfied, the codegets executed. A log anonymisation policy (Pols) specified by the log owner,which states what part of the requested log data should be available to theadministrator at GP , is also selected (5, Figure 4): in this scenario Pols wouldrestrict disclosure of LungCancer status (see T 2 ). Existing log anonymisationtechniques such as FLAIM [19] can be used in specifying these policies, in orderto sanitise the sensitive data while pertaining sufficient information for analysis.The migration service then generates a secure message containing these results(6, Figure4):R = {Logs, P ols, N GP } PK(GP )GP ’s nonce, N GP , is sufficient to verify that this message has been generatedfrom a trusted VM and unmodified code has been executed. The entire messageis encrypted with P K (GP ) so that it can only be decrypted if the system

Trustworthy Log Reconciliation for Distributed Virtual Organisations 179Fig. 5. Reconciliation of Collected Logsat GP is still configured to match PCR(TCB GP )(fromAT ); a compromisedsystem will not be able to decrypt this message. An attacker will not be able totamper with it since the private-half, S K (GP ), is strongly protected inside theTPM.Reconciliation of Collected Logs. This message arrives at the PEP of GP ’ssystem where it is decrypted using S K (GP )(1, Figure 5). The decrypted messageis then forwarded to the migration service which compares the returned N GPwith the original nonce (2, Figure 5). A matching value verifies the correctnessand the integrity of the collected Logs.The internal reconciliation service reconciles the logs collected from SC A ,SC B and SC C and updates the access control policies according to what usershave previously seen from these three specialist clinics (3, Figure 5). Duringthis process Pols are enforced to fully anonymise the log data. Attestationof GP ’s log security manager (1, back in Figure 4) is sufficient to establishthat these anonymisation policies will be imposed correctly during reconciliation.VM isolation and its robust memory protection prevent an attackerfrom accessing the memory space of the log security manager to steal the rawdata.A summary of the policy updates is then generated using the anonymised dataand forwarded to the original requestor, the visualisation service (4, 5, Figure5). The administrator only sees this summary information on how the policiesfor their patient data have been updated for different users, and performs blindlog analysis (6, Figure 5). VM Policy Attestation [6] may be used on the loganalysis VM to verify that it does not permit the summary to be exported toan unauthorised device.

180 J.H. Huh and J. LyleTable 1. Trustworthy Log Reconciliation FeaturesSecurity GoalsTrustworthy Log Reconciliation FeaturesLogs need to be protected Isolation of untrusted grid middleware services; the logfrom the grid middleware migration service encrypts logs using a log owner’s publicserviceskey for which the private-half is strongly protected insidelog owner’s TPM.A log requester needs to be Trustworthy log-generating sites are selected from configurationtoken verification; only a trusted log access VMable to verify the integrity ofthe collected logsis able to decrypt the grid job and return the logs from aremote site.A log owner needs to be Attestation token (part of the grid job) is used to verifythe trustworthiness of a log requester’s platform andassured that their logs willbe safeguarded from compromiseits reconciliation services; the logs are encrypted using re-and used unmodified at quester’s public key for which the private-half is sealed toremote sitesa trustworthy configuration.Blind log analysisLog anonymisation policies are enforced by the reconciliationservice and the raw data never leaves the log securitymanager; an end user only sees the fully anonymised data.6.3 ObservationsConfiguration Token Verification. The trustworthiness of our architectureis dependent on the ability for each participant to make the right decision aboutthe security provided by software at other nodes. The identity of this software isreported in the PCR values contained in the CTs. We imagine that these valueswill then be compared to a white-list of acceptable software. However, this assumesprior knowledge of all trusted node configurations, which may not be thecase if the VO is particularly large. Such a scalability issue is magnified whenconsidering settings files, many of which will have the same semantic meaningbut different measured values. It is difficult to assess how big a problem this is,but future work may look at using Property-Based Attestation [16] as a potentialsolution.Node Upgrades. The most significant overhead of our system is the cost of upgradingexisting nodes to support the new infrastructure. This involves installingthe Xen VMM and various logging VMs. While this is a large change, the advantageof our architecture is that legacy operating systems and middleware can stillbe used in their own VMs. The overall administration task is therefore not solarge. Furthermore, virtualization is increasing in popularity, and it seems likelythat the scalability and management advantages will persuade VO participantsinto upgrading to a suitable system anyway.7 Conclusions and Future WorkIn this paper, we have described a trustworthy log reconciliation infrastructure tofacilitate audit-based monitoring in distributed virtual organisations with strong

Trustworthy Log Reconciliation for Distributed Virtual Organisations 181guarantees of the log integrity and confidentiality. Table 1 summarises how ourinfrastructure satisfies the security requirements analysed in Section 4.Prototype implementations of some of these features will be constructed andtheir inherent security and practicality will be carefully evaluated.We intend to extend and generalise this work into a Digital Rights Management(DRM) framework in the future. Our reconciliation and migration VMs,as the root of trust, will enforce DRM policies to protected data and ensure thatthey are safeguarded wherever they move in a virtual organisation.AcknowledgementsThe work described is supported by a studentship from QinetiQ. Andrew Martinreviewed an early draft of this paper and provided constructive comments andsuggestions. David Power and Peter Lee provided help with the healthcare gridexample.The authors would also like to thank the anonymous reviewers for their carefulattention and insightful comments.References1. Trusted computing group backgrounder (October 2006),https://www.trustedcomputinggroup.org/about/2. Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T.: Xen and the art ofvirtualization. Technical report, University of Cambridge, Computer Laboratory(2003)3. Byrom, R., Cordenonsi, R., Cornwall, L., Craig, M., Djaoui, A., Duncan, A., Fisher,S.: Apel: An implementation of grid accounting using r-gma. Technical report,CCLRC - Rutherford Appleton Laboratory, Queen Mary - University of London(2005)4. Cooper, A., Martin, A.: Trusted delegation for grid computing. In: The SecondWorkshop on Advances in Trusted Computing (2006)5. de Alfonso, C., Caballer, M., Carrión, J.V., Hernández, V.: Distributed general loggingarchitecture for grid environments. In: Daydé, M., Palma, J.M.L.M., Coutinho,Á.L.G.A., Pacitti, E., Lopes, J.C. (eds.) VECPAR 2006. LNCS, vol. 4395, pp. 589–600. Springer, Heidelberg (2007)6. England, P.: Practical techniques for operating system attestation. In: Lipp, P.,Sadeghi, A.-R., Koch, K.-M. (eds.) Trust 2008. LNCS, vol. 4968, pp. 1–13. Springer,Heidelberg (2008)7. Grawrock, D.: The Intel Safer Computing Initiative, pp. 3–31. Intel Press (2006)8. Huh, J.H., Martin, A.: Trusted logging for grid computing. In: 3rd Asia-PacificTrusted Infrastructure Technologies Conference, China (2008)9. Lincoln, P., Porras, P., Shmatikov, V.: Privacy-preserving sharing and correction ofsecurity alerts. In: 13th conference on USENIX Security Symposium, p. 17 (2004)10. Maguire, T., Snelling, D.: Web services service group 1.2 (ws-servicegroup). Technicalreport, OASIS Open (June 2004)

182 J.H. Huh and J. Lyle11. Ng, H.-K., Ho, Q.-T., Lee, B.-S., Lim, D., Ong, Y.-S., Cai, W.: Nanyang campusinter-organization grid monitoring system. Technical report, Grid Operationand Training Center, School of Computer Engineering - Nanyang TechnologicalUniversity (2005)12. Pang, R.: A high-level programming environment for packet trace anonymizationand transformation. In: ACM SIGCOMM Conference, Germany (2003)13. Piro, R.M.: Datagrid accounting system - basic concepts and current status. Workshopon e-Infrastructures (May 2005)14. Piro, R.M., Guarise, A., Werbrouck, A.: An economy-based accounting infrastructurefor the datagrid. In: Fourth International Workshop on Grid Computing (2003)15. Power, D.J., Politou, E.A., Slaymaker, M.A., Simpson, A.C.: Towards secure gridenabledhealthcare. Software Practice And Experience (2002)16. Sadeghi, A.-R., Stüble, C.: Property-based attestation for computing platforms:Caring about properties, not mechanisms. In: NSPW 2004: Proceedings of the2004 workshop on New security paradigms. ACM Press, New York (2004)17. Simpson, A., Power, D., Slaymaker, M.: On tracker attacks in health grids. In: 2006ACM Symposium on Applied Computing, pp. 209–216 (2006)18. Skene, J., Skene, A., Crampton, J., Emmerich, W.: The monitorability of servicelevelagreements for application-service provision. In: 6th International Workshopon Software and Performance, pp. 3–14 (2007)19. Slagell, A., Lakkaraju, K., Luo, K.: Flaim: A multi-level anonymization frameworkfor computer and network logs. In: 20th Large Installation System AdministrationConference (2006)20. Tierney, B., Gunter, D.: Netlogger: A toolkit for distributed system performancetuning and debugging. Technical report, Lawrence Berkeley National Laboratory(December 2002)

Attacking the BitLocker Boot ProcessSven Türpe, Andreas Poller, Jan Steffan,Jan-Peter Stotz, and Jan TrukenmüllerFraunhofer Institute for Secure Information Technology (SIT),Rheinstrasse 75, 64295 Darmstadt, Germany{sven.tuerpe,andreas.poller,jan.steffan,jan-peter.stotz,jan.trukenmueller}@sit.fraunhofer.dehttp://testlab.sit.fraunhofer.deAbstract. We discuss five attack strategies against BitLocker, whichtarget the way BitLocker is using the TPM sealing mechanism. BitLockeris a disk encryption feature included in some versions of Microsoft Windows.It represents a state-of-the-art design, enhanced with TPM supportfor improved security. We show that, under certain assumptions,a dedicated attacker can circumvent the protection and break confidentialitywith limited effort. Our attacks neither exploit vulnerabilities inthe encryption itself nor do they directly attack the TPM. They ratherexploit sequences of actions that Trusted Computing fails to prevent,demonstrating limitations of the technology.1 IntroductionOne promise of Trusted Computing is better protection of system integrity. Variousapplications can profit from mechanisms that protect software on a computerfrom being tampered with. To this end, a v1.2 TPM supports authenticatedboot, keeping track of the boot process and eventually basing operations suchas sealing and attestation upon the result. This is one step short of what theorysuggests for best security: stopping the boot process of fixing the issue as soonas a manipulation has been detected [1,2].This leads to the question what the implications of this difference are in practice.We explore this question for one particular software design and application:BitLocker. Included with some editions of Microsoft Windows Vista and WindowsServer, BitLocker encrypts volumes on disk and uses the sealing functionof a v1.2 TPM for part of its key management. We devise several scenarios fortargeted attacks that break the confidentiality BitLocker is supposed to protect.Note that there are two distinct attack strategies against which BitLockershould ideally protect. Opportunistic attacks use only what is easily obtainedunder common real-world conditions. An example is recovering data on a disk orcomputer that has been bought in used condition from somebody else, or stolensomewhere. A targeted attack is different in that the attacker attempts to getaccess to data on a specific, predetermined disk or machine, usually within sometime and resource constraints. According to Microsoft, BitLocker is designedL. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 183–196, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

184 S. Türpe et al.to withstand at least opportunistic attacks. Considering targeted attacks as weare doing here may be beyond its specification. However, disk encryption alongwith TPM-based key management might be expected and perceived to be morepowerful than what the manufacturer is willing to promise, and we deem it usefulto explore the actual security properties and limitations regardless of claims andcautionary notes.The remainder of this paper is organized as follows. Section 2 briefly describesthe design of BitLocker, focusing on its key management and how it is using theTPM. Our adversary model and security considerations are outlined in section 3.Section 4 describes attack scenarios that seem feasible and either yield secret keyor data or achieve some important steps towards a successful attack. Causes andcontributing factors are discussed in section 5. Section 6 outlines our practicalimplementation of the attack, followed by the conclusions in section 7. Relatedliterature is referenced where appropriate but not specifically discussed.2 An Overview of BitLockerThis section only mentions facts about BitLocker that we will use in this paper.For further details refer to the documentation available from the manufacturer[3,4] and from unofficial sources [5].2.1 Integrity Model and Design ConstraintsBitLocker works, at boot time, as a component of the boot loader and lateras a driver of the operating system kernel. Its design assumes that the kernelboots from a BitLocker-protected volume, that BitLocker sufficiently protectsthe integrity of data on this volume, and that anything that happens after initiatingthe OS boot process is sufficiently controlled by other security mechanisms.We do not challenge these assumptions here; see [6,7,8] for two known attacksagainst the running system.According to these assumptions, BitLocker has to protect the integrity of theboot loader and its execution environment up to the point where the kernel canbe read from the locked volume. This code is read from an unencrypted partof the disk and needs to be supplied with a secret key for the AES algorithm.This is where the TPM is being used in. BitLocker uses the sealing functionto store all or part of its key material in such a way that it becomes accessibleonly if the platform configuration as represented by the PCR values is in linewith the reference configuration. The reference configuration is determined bythe administrator accepting the current system configuration at some point intime. This adoption of a reference configuration is initially done during BitLockeractivation but can be repeated at any time from the running Windows system.2.2 Key Management and Recovery MechanismsApart from special cases—BitLocker can also be operated without a TPM orwith all key material being managed by the TPM—key material is divided. One

Attacking the BitLocker Boot Process 185part is managed by the TPM and released only if the platform is in the trustedstate, the other is supplied by the user as a password and/or key file on a USBmemory stick.If the TPM works as desired, there is no way according to the design to gainaccess to all required key material if the platform state measured is differentfrom the reference state. This is intended if the platform state is modified byan attack, it is not, if state is modified for a legitimate reason and the changecan not be reverted easily, e.g. after BIOS update or hardware repair. BitLockertherefore offers two recovery mechanisms, the recovery password and the recoverykey. Both are designed to circumvent the TPM and supply BitLocker with itssecret key independent of the current platform state. The recovery mechanismsdon’t correct the problem, though. This is left to the administrator who, afterthe recovery boot, may set a new reference state from the running system.The actual encryption key does not change during the recovery process.2.3 User ExperienceThe user experience hides most of the details. When switching on their PC, userswill see a text-mode prompt for their PIN and/or USB stick. If the platform is notin reference state they will next be prompted for their recovery key or password.Otherwise the boot process will resume after the PIN or USB key have beenprovided. Depending on how the computer is being used, users may experiencea recovery prompt from time to time, e.g. after accidentally leaving a bootableCD or DVD in the drive or when a bootable USB stick is plugged into theircomputer.3 Security Considerations3.1 Security ObjectivesThe primary security objective is confidentiality of any data stored on the encryptedvolume. Encryption alone, however, cannot guarantee confidentiality asa system security property. Its scope has—at least—two intrinsic limitations.First, disk encryption is not expected to protect cleartext data before en- or afterdecryption. The system must provide further security mechanisms to providesuch protection. Second, encryption does not solve confidentiality problems butrather shifts them: from the data to the key(s). Encryption therefore cannot bemore secure than its key management allows it to be.A secondary objective is integrity of the data stored on disk. We considerintegrity here only insofar as it is a prerequisite for protecting cleartext dataand keys.3.2 Attack Success ConditionsThere are several distinct conditions that, if achieved by an attacker, wouldviolate the primary security objective:

186 S. Türpe et al.– The attacker obtains all or some ciphertext and breaks the encryption.– The attacker obtains the cleartext from place or situation where cleartext isnormally handled. The attacker works outside the scope of the encryptionin this case and exploits a vulnerability elsewhere.– The attacker obtains all or some ciphertext as well as sufficient key material,and decrypts the ciphertext.An attack may achieve everything at once, or it may comprise a sequence ofsteps, each of which brings the attacker closer to success. We assume that stepscan be arranged in arbitrary sequence. But we require that no step except thelast one may spoil continuation, e.g. by preventing necessary subsequent stepsor by clearly alerting the user to the ongoing attack before it is finished.3.3 Attack SituationsWhen accessing the system, the attacker may encounter one of several differentsituations. Situations can be thought of as a set of parameters that the attackerdoes not control. The situation found, together with capabilities, determine whatthe attacker can achieve during the visit. Though not being able to control thesituation, in a targeted attack the attacker can wait for the right moment. Someparameters, however, may have a very low probability of changing. An exampleis the configuration of a disk encryption scheme once it has been installed.Situational parameters are:– The time and channel available for undetected interaction with the targetsystem. This is really a continuum but we can roughly distinguish threeclasses of physical access: brief visits (up to few minutes), temporary controlof the device (up to a few days), and permanent possession. Another channelis remote communication. We assume that the attacker must successfullyinstall software on the target machine to gain such a channel, and the channelis available only while this software is running.– The boot state of the target computer. The system may be powered on andfully booted, or it may be powered off. When it is running, encryption keysare present in RAM. The attacker can power it down at the risk of thechange being noticed by the user. If the system is powered off, the attackeris not able to fully boot the system without the user-managed secrets. Hemay boot his own software, however; this is indeed one of the actions thatusing a TPM should protect against.– System configuration. There is a vast amount of system configurations thatan unprepared attacker may encounter. For a particular target system, however,the configuration rarely changes. If it does, and the system has a TPMand uses it, expected or deliberate changes are likely to be accepted, changingthe reference configuration.If the attacker encounters the system running and has enough time available,the attack is successful immediately: keys can be read from memory using oneof the known online attack techniques, and used to decrypt disk contents.

Attacking the BitLocker Boot Process 1873.4 Adversary CapabilitiesWith physical access to the target system the attacker can perform one or multipleactions depending on the time available, the state of the system and whether(later) detection is acceptable or not. We are thinking along the lines of [9] herebut do not attempt to establish a comprehensive model. Our lists below arelikely incomplete.Brief visits During a brief visit the attacker could:Power off or on the system, depending on its current state. Powering off impliesthat the original state cannot be restored if the attacker does not knowthe secrets requested at boot time. Although the change is noticeable, theattacker may get away with it if the change is plausible to the user. If thesystem is originally powered off, the attacker can revert to the original stateat any time. The attacker will not be able to boot into the regular systemwithout knowing the boot-time secrets.Modify boot code if the system is powered off or can plausibly be left in thiscondition. Whether and when such a modification might be detected by theuser depends on various side conditions, particularly on the use of a TPMand the actions the code performs. We can expect such code to be executedat least once.Steal the system, turning a brief visit into permanent possession of the machine.Theft will usually be detected. The attacker may or may not be ableto preserve the boot state of the machine, depending on whether it has asufficiently charged battery or not.Replace the machine with one that looks exactly the same. This requires somepreparation and investment but seems feasible. In addition to getting handson the target machine permanently the attacker retains the ability of interactingwith the target user. The attack will be noticed as soon as the copybehaves differently than the target would, or any other distinguishing featurebecomes visible and noticed.Copy small amounts of data from the disk but not an entire volume or disk.This leaves no traces if the system is powered off, or changes its state if itwas powered on. (We assume the software running on the machine cannot beexploited to this end.) Copying entire disks fails not because of any securitymechanism but due to the amount of time required.Possibly copy small amounts of RAM contents if a DMA-capable interface isavailable and supported, and the system is up and running.Temporary control. If the attacker can spend more, but sill limited time withthe system, additional actions become available:Install a concealed hardware extension such as a key logger. Whether the systemhas to be powered down if encountered running depends on the type ofextension and various details of the hardware design.

188 S. Türpe et al.Copy the entire disk or an entire volume of data. This leaves no traces if thesystem is powered off, or may change its power state if it was powered on.However, given sufficient time the attacker may be able to disconnect thedisk from the system without resetting the machine, connect it to anothermachine, copy all data, and reconnect the drive to the target machine.Non-destructive attacks against a TPM or other hardware components such asa TPM reset attack [10,11]. Such attacks may have specific prerequisites. Areset attack against a TPM, for instance, requires that the attacker knows theproper sequence of PCR values during regular boot. One way of obtaining thissequence would be to record it during such a boot process, which requires theability to boot the unmodified system to the point where the TPM is used.Permanent access. An attacker in permanent possession of the target systemhas all the capabilities described above. The difference from temporary controlis that the attacker does not have to hide anything from the user. Destructiveattacks become an option.Communication. Communication with the attacker is possible whenever the attackermanages to run his own software on the target system or controls existingsoftware with communication capabilities. There are different modes of communication.The most common are: storing data locally where they can be pickedup later; transmitting data through a network interface card to the local wiredor wireless network; or using an IP network if the computer is connected toone. None of these options requires that the attacker uses the operating systeminstalled on the target system.4 Attack Strategies4.1 Plausible RecoveryThe attacker modifies the BitLocker code on disk, adding a backdoor. Such abackdoor could be as simple as saving a clear key in some location on disk orelsewhere in the system from where it can be retrieved later. This modificationwill of course be detected the next time the system is started by a legitimate user.However, the attacker hopes that the user applies one of the TPM-independentrecovery mechanisms to overcome the problem. The attacker later visits thesystem again to collect the key. Encrypted volume data could be copied duringeach visit to the target system as the actual encryption key does not usuallychange.Requirements This attack requires:– that recovery mechanisms are used at all, and– that the attacker can physically access the target machine at just the righttime without taking it away permanently, and– that the reported platform validation error seems plausible for the victim.

Attacking the BitLocker Boot Process 189One obvious implementation of this attack would be to wait for a situationthat plausibly changes the state of the platform, such as a repair. It may alsobe possible to provoke such a situation. The attacker will then have to sneakinto the process somewhere before the user accepts the seemingly legitimatemodification. This would mask the malicious change with the legitimate one.Result. If the attack succeeds, the attacker has successfully planted a backdoorinto the system in such a way that all software-based security features could becircumvented. The attack is unlikely to be noticed by the victim. In order to getboth the encrypted data and the secret key the attacker will have to visit thetarget system at least twice. However, the backdoor may also use other channelsto leak cleartext data, possible increasing the risk of detection.4.2 Spoofed PromptSimilar to the plausible recovery attack, the attacker modifies BitLocker on thetarget system and lives with the fact that the TPM will detect this modification.The attacker adds code that spoofs the user interface of BitLocker up to the pointwhere the user has given up his secrets. The malicious code may spoof either thenormal-operations UI or the prompt for a recovery key.Requirements. This attack requires that the attacker can physically access thetarget system. It is not necessary that the attacker takes the system away permanently.Result. The attack is easily detected as soon as secrets have been provided to thespoofed prompt. After detection it is generally possible to prevent the attackerfrom interacting with the compromised system again. Also, the TPM will refuseto unseal its part of the key material while the platform is in this modified state.If a recovery prompt is successfully spoofed and operated by the user, the attackwill yield sufficient key material for decryption of a volume.Extensions. Although it may work under some circumstances, this attack doesnot appear very critical. However, the next subsection describes a more criticalextension.4.3 Tamper and RevertThe tamper and revert attack extends the spoofed prompt attack. Instead ofsimply accepting that platform modifications can be detected, the attacker attemptsto exploit tampering yet hiding it. This becomes surprisingly easy if oneadditional boot cycle is possible. The attacker could make a temporary modificationto TPM-verified code. If we stick to the spoofed prompt example, thismeans to add a cleanup function to the malicious code, whose purpose it is torestore the former platform state. After a reboot—which might be initiated bythe malicious code after showing a bogus error message—the platform state asmeasured will be compliant with the reference PCR values again.

190 S. Türpe et al.Requirements. Requirements are similar to those of the spoofed prompt attack.In addition the attacker needs to get away with a boot cycle after platformintegrity failure without disturbing the victim so much as to spoil further stepsof the attack. Depending on how the credentials or keys obtained are transmittedto the attacker, a further visit to the system may or may not be required.Results. This attack yields copies of keys controlled by the user. In a simpleimplementation these keys will end up in clear somewhere on the target systemitself but more sophisticated approaches can be imagined, for instance sendingthe key somewhere using a built-in WLAN interface. Additional effort is requiredon the attacker’s part to gain access to TPM-managed key material.4.4 Replace and RelayThis is a hardware-level phishing attack. The attacker replaces the entire targetmachine with another computer prepared for the attack. The replacement, whenturned on, produces all the messages and prompts that the original machinewould have produced. Up to the point where BitLocker would start, it takes alluser inputs (via keyboard or USB) and relays them to the attacker, e.g. usingradio. The attacker, being in possession of the unmodified original system, usesthis information to start up the stolen computer.Requirements. This attack requires that:– the attacker is capable of replacing the BitLocker-protected machine altogetherwith an identically-looking copy, and– the machine is plausibly turned off or in suspend-to-disk mode when thelegitimate user returns, and– the replacement device is capable of relaying user input to the attacker.The attacker will have to remain—or leave some device—in proximity to thetarget until the next boot is initiated by the victim. The attacker will also needsome prior knowledge of non-secret facts, specifically everything that might beneeded to perfectly reproduce the user experience.Result. As a result of this attack, the attacker receives the user-controlled secrets.Depending on the mode in which BitLocker is deployed on the target system,the result is either key material or authentication credentials or both. Either onecan be used in conjunction with the unmodified system to start up the operatingsystem. Security mechanisms of the operating system remain intact; anotherattack will be required to actually access any encrypted data. Such attacks exist[8,7]. The attack will likely be noticed right after the victim provided credentialsor keys to the spoofed machine. This attack may be combined with any attackthat yields the TPM-managed portion of the key material.Extensions and Variants. A more sophisticated version of this attack involvestwo-way communications, turning the replacement into a terminal of the stolentarget machine. This would probably require quite some additional effort but

Attacking the BitLocker Boot Process 191might extend the time span between success and detection of the attack. Allvariants of this attack may also be attempted against recovery mechanisms,which yields sufficient key material to decrypt disk contents immediately.4.5 Preemptive ModificationThis attack is similar to the plausible recovery attack, but at a different point intime. The recovery attack targets systems on which BitLocker has already beenactivated. Preemptive modification attacks earlier, before BitLocker has beenactivated at all.When defining the reference state for future booting, the operator has nochoice other than using the current platform state. BitLocker does not providethe user with any means of verifying that this current state has or hasn’t anyparticular property. If an attacker manages to modify critical parts of the platformbefore BitLocker is activated, this modification therefore goes unnoticedand will be incorporated into the trusted (but not trustworthy) platform state.Requirements. Preemptive modification requires that the attacker gets physicalaccess to the target system before BitLocker is activated. Arbitrary modificationsare possible at that time that would weaken the security of the BitLockerinstance affected forever. Another physical visit may be required later to retrievea disk image for decryption or leaked cleartext. However, the system may alsobe modified in such a way that it leaks data at runtime. Everyone who getsphysical access to the machine or OS installation media before BitLocker setupis a potential attacker.Results. The attacker potentially gains read and write access to all data handledon the system throughout its lifetime. This attack is hard to detect unless thereare additional means of verifying the integrity of executable code against externalreferences.5 Causes and Contributing FactorsThis section identifies factors that make the overall system—a PC with BitLockerand Trusted Computing technology—vulnerable to the attacks described above.Factors include fundamental properties of the security mechanisms involved aswell as features in the design and implementation of BitLocker and the TrustedComputing platform.Authenticated boot. Theory states that secure booting requires an appropriateaction if the measured state deviates from the reference. The boot processcould be stopped or it may be possible to fix the issue once it had beendetected [2]. So far, however, we have only authenticated boot. The TPMdoes not enforce a trusted platform state, it only refuses to unseal a key ifthe state is currently not trusted. This leaves loopholes for attacks, but alsomakes it easier to provide recovery mechanisms if they are desired.

192 S. Türpe et al.No trusted path to the user. BitLocker uses secrets to authenticate the user:the PIN and key material. The channel between the legitimate user and thesystem in a trusted state is prone to spoofing and man-in-the-middle attacks(replace and relay; spoofed prompt; and tamper and revert). or specifically,the system lacks context-awareness and the user is unable of authenticatingthe system. Similar problems exist elsewhere, e.g. ATM skimming. Bothdirections of authentication can be discussed separately:No context-awareness. The BitLocker has no means of determining whetherthe computer is under control of a legitimate user or somebody else. Itsimply assumes that whoever provides the correct key or credential is alegitimate user. Although requesting a PIN or key may be interpreted asauthentication, it is not a very strong one, and adding stronger authenticationmay be difficult.Lack of system authentication. While BitLocker is capable of authenticatingits user at least in the weak sense described above, the user has no meansof verifying authenticity and integrity of the device. Keys and passwordsare to be entered into an unauthenticated computer.History-bounded platform validation. The Trusted Computing platform detectsand reports platform modifications only within the scope of the current bootcycle. BitLocker uses this feature through the sealing function of the TPMand does not add anything. The system is therefore unable to detect, andreact to, any tampering in the past that has not left permanent traces in thesystem.Incomplete diagnostic information. If current and reference state are out ofsync, it is difficult or even impossible for the user or administrator to determinethe exact cause(s). This leaves the user with a difficult choice: touse recovery mechanisms blindly, or not to use them at all. The lack of diagnosticinformation contributes to the plausible recovery attack. Note thatdetailed diagnostic information may not be required where a trusted statecan be enforced, e.g. by re-installing software from trusted sources.Lack of external reference. This is another issue that has already been discussedin the literature. BitLocker is capable only of using any current platform stateas a reference for future boot cycles. There are no means of verifying that thisreference state is trustworthy, opening the road to preemptive modificationattacks.Recovery mechanisms that circumvent the TPM altogether. Except for TPMreset and preemptive modification, all attacks described above do or mayprofit from the recovery mechanisms built into BitLocker. These mechanismspose a particularly attractive target as they yield a key that is independentfrom the TPM and thus can be used more flexibly. The plausible recoveryattack would not even be possible without recovery mechanisms.Online attacks. Disk encryption does not protect from online attacks [6,7,8] andis not expected to do so. They must be considered, however, as they offer astraightforward way of finishing the attack once the attacker has obtainedthe target system along with sufficient secrets to complete the boot process.

Attacking the BitLocker Boot Process 193Table 1. Attack scenarios and contributing factorsReplaceand relayPlausibleRecoverySpoofedpromptTamperand revertAuthenticated boot • •No trusted path to user • • •No context awareness •Lack of systemauthentication• •History-boundedplatform validationIncomplete diagnosticinformationLack of externalreference••Preemptivemodification• •Online attacks • • •Recovery mechanismscircumventing TPM• • • •Unprotected disk space • • •Confidentiality assecurity objective• • • • •Large amount of unprotected disk space. This is a secondary contributing factorto attacks involving purposeful, detectable modification of the platform(plausible recovery; spoofed prompt; tamper and revert). Large amounts ofdisk space are available for the attacker to install software or data in. Thismay be difficult to avoid, though.Confidentiality as the security objective. The security objective of disk encryptionalso has an impact on attacks. In order to achieve this objective, theattacker has to obtain a small amount of protected data—the key—alongwith a larger amount of unprotected data—the ciphertext—or a functioningdecryption device. This entails a great deal of flexibility on the attacker’spart: individual steps of the attack can be executed in almost arbitrary sequence,and there is little the victim can do to restore secrecy once it hasbeen lost. The latter is what Whitten and Tygar call the barn door property[12].Table 1 shows how these causes and factors contribute to the attacks describedbefore. Each column represents an attack, each line a cause or factor. If a factorcontributes to an attack—makes it possible, makes it easier, or makes the resultmore useful for the attacker—the respective cell is marked with an X. The lasttwo lines contain question marks in all cells: the authors do not fully understandthe impact of these factors yet.

194 S. Türpe et al.Fig. 1. Spoofed BitLocker PIN-entry screen6 Proof-of-concept ImplementationWe have fully implemented the tamper and revert attack described in section 4.3,in order to show its practical feasibility.The attacker installs the BitLocker PIN Trojan on the victim’s computerby starting it from a specially prepared USB drive which contains a strippeddown Linux system. This takes less than two minutes and requires nointeraction.The BitLocker PIN Trojan consists of a boot loader installed into the MBRand a second stage that is loaded from an unencrypted NTFS partition which ispart of every BitLocker installation. An installation tool is responsible for storingthe second stage along with the old MBR as a normal file into a continuous areaof the unencrypted NTFS partition. The LBA address of the beginning of thefile is written into the MBR.At the next boot, the MBR boot loader loads this file and transfers control toit. A fake BitLocker prompt is displayed (see figure 1); the entered PIN is storedin the NTFS partition, the original MBR is restored and the system rebooted.Later, the entered PIN can be read from the NTFS partition.7 ConclusionWe outlined five strategies for targeted attacks against BitLocker, a TPMsupported,software-based disk encryption system. All five strategies requireand exploit physical interaction of the attacker with the target computer. WhileTrusted Computing is expected to help protect against such attacks, our

Attacking the BitLocker Boot Process 195research shows this is not necessarily the case. Using a TPM for key managementin a straightforward way provides only very limited protection against a dedicatedattacker. None of our attack strategies targets the TPM as such. Theyall exploit the way it is being used by one particular implementation of diskencryption.Designers as well as users of disk encryption solutions should be aware ofthese attack strategies in order to realistically assess how much security they getout of trusted computing. The most important lesson to be learned is that evenwith Trusted Computing a system needs additional physical protection for goodsecurity. This has been known for the running system [7]; our research showsthat it is true as well if the attacker gains physical access only when the systemis powered off. Even if direct physical attacks are excluded from consideration,Trusted Computing does not offer the same level of protection as conventionalmeasures of physical security [13,14]Out of the contributing factors discussed above, three seem crucial. First,Trusted Computing as of today is limited to authenticated boot. The technologycannot enforce any policy for a program, malicious or not, that does not requireany support from the TPM to run. Second, to successfully attack an encryptionscheme one needs to find just one way to obtain a small secret, the key. TheTPM helps protect keys but only during part of their life cycle. Third, theuser is forced to trust the computer with his secrets, regardless of its state.There is no way for the user to detect skillful tampering and man-in-the-middleattacks.A proof-of-concept implementation of the tamper and revert attack showsthat malicious manipulation of boot code is not only a theoretical issue.Our work leads to several questions for further research:– Design standards and evaluation criteria for TPM-supported disk encryption.The point of this paper is not to dismiss Trusted Computing as uselessbut rather to get a better idea how it should be used in particular applicationsto achieve the security properties desired.– More generally, it seems that the exact role of Trusted Computing technologywithin applications is still unclear. Like any technology, Trusted Computingprovides primitives and building blocks that need to be employed and arrangedin meaningful ways. We hope that a set of patterns will emerge overtime to show developers how to apply Trusted Computing properly.– Solutions to particular problems, such as establishing trusted channels betweenthe user and the TPM, or providing useful diagnostic and referenceinformation for users and operators to help them in making their securitydecisions.– Modeling of attacker capabilities. We have not found a practical methodthat would have allowed us to model and analyze in a systematic way whatan attacker might do to a system. An easy way of describing a system andanalyzing what could or could not be done to it would be helpful.

196 S. Türpe et al.References1. Mitchell, C.J. (ed.): Research workshop on future TPM functionality: Final report,http://www.softeng.ox.ac.uk/etiss/trusted/research/TPM.pdf2. Arbaugh, W.A., Farbert, D.J., Smith, J.M.: A secure and reliable bootstrap architecture.In: Proceedings of the IEEE Symposium on Security and Privacy, pp.65–71. IEEE Computer Society, Los Alamitos (1997)3. Fergusson, N.: AES-CBC + Elephant diffuser: A disk encryption algorithm forwindows vista. Tech. rep., Microsoft (2006)4. Microsoft TechNet. BitLocker Drive Encryption Technical Overview (May 8, 2008),http://technet.microsoft.com/en-us/library/cc732774.aspx5. NVlabs: NVbit: Accessing bitlocker volumes from linux. Web page (2008),http://www.nvlabs.in/node/96. Hendricks, J., van Doorn, L.: Secure bootstrap is not enough: Shoring up thetrusted computing base. In: Proceedings of the Eleventh SIGOPS European Workshop,ACM SIGOPS. ACM Press, New York (2004)7. Halderman, J.A., Schoen, S.D., Heninger, N., Clarkson, W., Paul, W., Calandrino,J.A., Feldman, A.J., Appelbaum, J., Felten, E.W.: Lest we remember: Cold bootattacks on encryption keys. Tech. rep., Princeton University (2008)8. Becher, M., Dornseif, M., Klein, C.N.: Firewire: all your memory are belong to us.Slides, http://md.hudora.de/presentations/#firewire-cansecwest9. Templeton, S.J., Levitt, K.: A requires/provides model for computer attacks. In:Proceedings of New Security Paradigms Workshop, pp. 31–38. ACM Press, NewYork (2000)10. Sparks, E.R.: Security assessment of trusted platform modules. Tech. rep., DartmouthCollege (2007)11. Sparks, E.R.: TPM reset attack. Web page,http://www.cs.dartmouth.edu/~pkilab/sparks/12. Whitten, A., Tygar, J.D.: Why Johnny can’t encrypt. In: Proceedings of the 8thUSENIX Security Symposium (1999)13. Weingart, S.H.: Physical security devices for computer subsystems: A survey ofattacks and defenses. In: Paar, C., Koç, Ç.K. (eds.) CHES 2000. LNCS, vol. 1965,pp. 302–317. Springer, Heidelberg (2000)14. Weingart, S.: Physical Security Devices for Computer Subsystems: A Surveyof Attacks and Defenses 2008, updated from the ches 2000 version (2008),http://www.atsec.com/downloads/pdf/phy_sec_dev.pdf15. Drimer, S., Murdoch, S.J.: Keep your enemies close: Distance bounding againstsmartcard relay attacks. In: USENIX Security 2007 (2007)16. Tygar, J.D., Yee, B.: Dyad: A system for using physically secure coprocessors.In: Tech. rep., Proceedings of the Joint Harvard-MIT Workshop on TechnologicalStrategies for the Protection of Intellectual Property in the Network MultimediaEnvironment (1991)17. Grawrock, D.: The Intel Safer Computing Initiative: Building Blocks for TrustedComputing. Intel Press (2006)18. Hargreaves, C., Chivers, H.: Recovery of encryption keys from memory using a linearscan. In: Proceedings of Third International Conference on Availability, Reliabilityand Security, ARES 2008, pp. 1369–1376 (2008), doi:10.1109/ARES.2008.109

Secure VPNs for Trusted Computing EnvironmentsSteffen Schulz and Ahmad-Reza SadeghiHorst-Görtz Institute and Chair for System Security, Ruhr-University Bochum{steffen.schulz,ahmad.sadeghi}@trust.rub.deAbstract. Virtual Private Networks are a popular mechanism for building complexnetwork infrastructures. Such infrastructures are usually accompanied bystrict administrative restrictions on all VPN endpoints to protect the perimeter ofthe VPN. However, enforcement of such restrictions becomes difficult if theseendpoints are personal computers used for remote VPN access. Commonly employedmeasures like anti-virus or software agents fail to defend against unanticipatedattacks. The Trusted Computing Group invested significant work intoplatforms that are capable of secure integrity reporting. However, trusted bootand remote attestation also require a redesign of critical software components toachieve their full potential.In this work, we design and implement a VPN architecture for trusted platforms.We solve the conflict between security and flexibility by implementing aself-contained VPN service that resides in an isolated area, outside the operatingsystem environment visible to the user. We develop a hardened version of theIPsec architecture and protocols by addressing known security issues and reducingthe overall complexity of IPsec and IKEv2. The resulting prototype providesaccess control and secure channels for arbitrary local compartments and is alsocompatible with typical IPsec configurations. We expect our focus on security andreduced complexity to result in much more stable and thus also more trustworthysoftware.1 IntroductionVPNs are a simple and cost effective way to manage and control complex networks.With increasing user mobility however, the VPN perimeter also becomes increasinglycomplex. Mobile systems are expected to serve as secure VPN gateways, workstationsand personal devices at the same time. As a result, it becomes increasingly difficult toassure the security of such systems. Allowing them to connect to a VPN potentiallyundermines perimeter security and may expose the network to outside attacks. Vendorstry to solve this conflict with proprietary security software and software agents, but suchsolutions increase complexity of the software stack while decreasing interoperabilitywith other software solutions.With trusted computing, the state of a system can be measured at boot time. A hardwareanchor is used to vouch for the correctness of measurement reports, so that theintegrity of a system can be verified by remote parties before granting any kind of access.The measurement itself however is not sufficient to trust the system. The integrityof a software configuration is only useful if the software itself can be trusted to fulfillthe security requirements. This implies a resistance to attacks and misconfiguration thatL. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 197–216, 2009.© Springer-Verlag Berlin Heidelberg 2009

198 S. Schulz and A.-R. Sadeghicurrent commodity systems do not achieve. We follow architecture proposed in [1] toseparate volatile userspace environments from components that are critical to systemsecurity and to allow strong isolation of userspaces for the different roles assumed bythe user.An architecture similar to ours is described in in [2]. However, their work does notconsider integration with trusted computing technologies. and proved unsuitable for ourwork to build up on.1.1 ContributionThis work adapts the IPsec security architecture for a robust and reliable VPN servicefor trusted platforms. In our design, critical functionality is externalized into isolated,self-contained security services in a trusted hypervisor environment. We use acentral security policy from trusted storage to establish secure channels between isolateduserspace environments and to connect them to other IPsec networks. As a result,our architecture enables coexistence of arbitrary userspace environments with restrictedworkspaces while reliably enforcing the platform owner’s network access policy.To harden our VPN security service, we investigate a simplified IPsec architecturesupporting only tunnel mode with ESP 1 protection [3] and IKEv2 2 key negotiation [4].By removing unnecessary functionality and features that allow insecure IPsec operationmodes, we resolve known security issues in IPsec and significantly reduce the complexityof architecture and implementation.We have implemented a prototype based on the L4 microkernel to verify the feasibilityof our solution, to evaluate its interoperability with commodity IPsec implementations,and to measure the complexity in terms of code size. Finally, we discusscompatibility and security of our architecture and suggest feature improvements.1.2 ApplicationsOur architecture has significant security-benefits for users that assume different rolesduring their work. The typical example for home users is online banking, where thesVPN architecture allows to setup a fully isolated userspace environment with strongadministrative restrictions to secure banking sessions. Similar use-cases can be foundin corporate environments, where access to critical network resources is often restrictedto machines with specific software configurations. In such setups, the sVPN service resolvesthe conflict between flexibility and security by moving all critical functionalityout of the userspace environment. Once we finish our integration with trusted storageand remote attestation, our architecture also allows to verify the state of a peer’s securitysubsystem, enforce arbitrary security requirements on connected userspaces. Additionally,our design also delivers a very simple and usable way to deploy secure andIPsec-compatible VPNs. Since our design also focuses on minimal complexity for thecritical components, environments with high security demands may also benefit fromthe possibility of formal code-reviews of the critical components of their VPN. Finally,1 Encapsulated Security Payload.2 Internet Key Exchange version 2.

Secure VPNs for Trusted Computing Environments 199our implementation also provides virtualized IPsec gateways that can be used to consolidatehardware resources in more complex VPN setups.1.3 OutlineWe present the general idea of our architecture in section 2, followed by a requirementsanalysis in section 3. In section 4, we investigate related VPN designs and security architecturesfor microkernel environments. Section 5 reviews the security of the IPsecarchitecture we leverage on. Based on these results, we design a secure compartmentalizedVPN service in in section 6. Section 7 presents our prototype implementationand compares its code-complexity with standard implementations. In sections 8 and 9,we discusses how our modifications influence compatibility and security. We concludewith summary of results and suggestions for future work.2 High-Level ArchitectureFigure 1 shows the VPN architecture of two platforms connected through a wide areanetwork (WAN). The right system shows a commodity IPsec implementation, while theleft system shows the design proposed in this work.In commodity systems, IPsec packet processing is typically implemented as partof the network stack in the kernel. An IPsec boundary enforces the IPsec security policy(BYPASS, DISCARD, PROTECT) on all traffic that passes through it, dividing the systeminto a "protected" and "unprotected" area. Userspace environments (compartments) inthe"protected"areausetheVPNservicebyspecifyingthePROTECT-target on specificProposed ArchitectureTypical ArchitectureunprotectedHardwareNICWANNICHardwareHypervisorSecurity ServicesPRNG storage ...sVPNIKE IPsecunprotectedIPsecKernelspaceIKEUserspace"A"Userspace"B"UplinkProviderUserspace "C"protected protected unprotectedIPsec channel from userspace A to CLocal insecured IPCprotectedFig. 1. Overview of the sVPN architecture interfacing with a commodity IPsec implementationthrough WAN/Internet. The sVPN security service processes all data passing through a localchannel between "B" and the "Uplink Provider", according its IPsec policy. By applying IPsecprotection to some of the data streams, local channels are logically extended into secure remotechannels that reach through the unprotected area to a peer IPsec gateway.

200 S. Schulz and A.-R. Sadeghitraffic flows. The IPsec boundary then provides a secure channel through the "unprotected"area. The channel ends at a peer IPsec boundary, which decapsulates the dataand forwards it to its local "protected" area. In such systems, key negotiation is typicallyhandled by the "protected" endpoints of the channel. With only a single IPsec boundary,such systems also support only a single "protected" area that must be shared betweenall userspace applications.The left-hand system in contrast provides multiple isolated userspace environmentsby design. Virtualization of legacy operating systems and basic operating system functionalityis provided by a trusted hypervisor, which is accompanied by an environmentof system and security services. Since the different userspace environments have potentiallyconflicting security requirements, they build separate "protected" areas in IPsecthat require a dedicated logical IPsec boundary for policy enforcement. Similarly, thekey negotiation component is not part of any particular userspace environment anymorebut must be implemented as a neutral security service of the system. Both componentsare thus implemented as self-contained security services in the trusted hypervisor environment.They are configured by the platform owner and do not rely on any untrustedcomponents to maintain their security. Once packets are processed, the "unprotected"area has the non-critical task of delivering the data to the destination IPsec gateway. Figure1 thus only shows a single common uplink provider for post-processing and uplinkmanagement.The proposed compartmentalized architecture is called sVPN architecture throughoutthis paper, our prototype implementation of it is called sVPN service or just sVPN.In includes the two mentioned security services in the hypervisor environment and someuntrusted applications for pre- and post-processing.3 Requirement Analysis3.1 Functional RequirementsIPsec Virtualization. In contrast to typical IPsec implementations, the sVPN servicehas to be able to provide its VPN service for multiple "protected" areas with potentiallyconflicting security requirements./R1/ sVPN must establish bidirectional channels between local compartments andmanage a separate IPsec security policy database (SPD) and security associationdatabase (SAD) for each channel.Usability. To let users to benefit from the enhanced security of our design, it is necessarythat the user interface provides high usability and prevents typical configurationerrors./R2/ sVPN must provide a usable VPN configuration interface that is able to defineand deploy secure VPNs and prevents accidental use of insecure cryptographicprimitives, operation modes or authentication schemes./R3/ sVPN must depend on as few components as possible to implement its security.These dependencies must be specified and easy to understand.

Secure VPNs for Trusted Computing Environments 201Compatibility. Interoperability with other IPsec-based VPN solutions is strongly desired,as long as it does not conflict with the security of the VPN service./R4/ sVPN must be compatible with IPsec in typical VPN configuration./R5/ sVPN must provide basic support for the canonical key exchange protocol forIPsec VPNs (i.e., IKEv2).Security Subsystem. We optimize our VPN service for low internal complexity tofacilitate formal security analysis and to reduce the possibility of security flaws in theimplementation./R6/ The sVPN architecture must isolate components that must be trusted to meet thesecurity requirements./R7/ All critical subcomponents and the services they depend on must be of manageableinternal complexity with simple communication interfaces.3.2 Security RequirementsAdversary Model. To simulate the susceptibility of complex applications to local andremote attacks, we assume an adversary to have full access to all userspaces a legal userof the platform has access to. In contrast to legal users however, adversaries are assumedto have no physical access to the platform. An adversary is considered successful if hemanages to extract secret key material from the sVPN security service or if he is able toviolate the sVPN security policy, for example by creating additional channels betweenlocal compartments. In addition, when attacking only from "unprotected" compartmentsor networks, i.e. without implicit knowledge of transmitted data, he is also consideredsuccessful if he manages to extract data that is labeled with PROTECT in the sVPNsecurity policy.The attack model for the sVPN security service is stronger than that of traditionalIPsec-based VPN solutions. The main difference is that local compartments which interfacewith sVPN are assumed to be compromised, thus providing an attacker with reliableaccess to data transfers and statistics about resource usage to launch side-channelattacks (e.g. timing attacks, traffic pattern analysis). We assume however that isolationprovided by the hypervisor also protects against side-channel attacks based on sharedresources[5,6]. Therefore, we only considers side-channel attacks in form of traffic patternanalysis.Further, we assume that the IPsec architecture has no security flaws aside from thosementioned in section 5.1, i.e. that the core IKEv2 protocol, the ESP protocol and theIPsec architecture itself are sound. Based on these assumptions, we identify the followingrequirements for the sVPN architecture to remain secure in the described attack model.Virtualization Security. sVPN has to provide a logically isolated IPsec boundary forevery compartment that uses the service, thus isolating every connected userspace environmentinto a separate "protected" area./S1/ sVPN must be able to identify endpoints of a local channel and must enforce thecorresponding IPsec policy for that channel.

202 S. Schulz and A.-R. Sadeghi/S2/ Communication channels between local compartments that are not directedthrough sVPN must be restricted by the hypervisor such that they can not be usedto circumvent the security enforced by sVPN./S3/ Although acting as a common endpoint for multiple local channels, sVPN mustnot break isolation between compartments that are not allowed to establish a channelbetween each other.IPsec Security. sVPN must provide a secure VPN service through secure authentication,key management and secure channels./S4/ The sVPN architecture must provide a secure channel for deploying IPsec policyand authentication secrets to the sVPN service./S5/ sVPN must never disclose any key data to untrusted components. Accessibilityof key material must be minimized to the necessary sub-components of sVPN./S6/ sVPN must be able to directly authenticate the user of a "protected" area whenrequired so by IPsec policy./S7/ The IPsec compatible remote channels provided by sVPN must be secure./S8/ sVPN must be able to enforce restrictions on the configuration of compartmentsthat request a particular VPN access.Since non-critical functionality of sVPN, including receiving and sending of data, is externalizedto the connecting "protected" and "unprotected" compartments which are expectedto be compromised, it is not possible to protect against DoS in the adversary modeldescribed above. If a DoS resistance similar to commodity IPsec implementations is desired,it can thus be implemented in the traffic pre-processing in untrusted compartments.4 Related WorkHypervisor-based operating systems environments with userspaces on multiple virtualmachines have recently been reconsidered as a base for increased security. The idea toexternalize security subsystems into a hypervisor environment resulted in several newarchitectures like sHype, Terra, EROS, Nizza and Perseus [7,8,9,10,1,11].A conceptionally similar setup can be found in many microkernel operating systems,but their current IPsec implementations do not exploit the features of their environmentfor additional security. They exist only in form of adapted versions from monolithicsystems or university classes 3 .With µSINA, the authors of [2] present a comparable redesign of IPsec for Nizza.In their architecture, a "network hub" is added to the operating system environment ofa Fiasco/L4 microkernel. It processes traffic between two paravirtualized Linux compartmentsthat run on top of the microkernel (L4Linux compartments), enforcing IPsecpolicies and traffic protection. µSINA aims for enhanced reliability and security byminimizing the attack surface of critical components. An implementation of the IPsecpacket processing component is provided with the Viaduct security service.3 See for example www.cis.syr.edu/~wedu/seed/Labs/IPSec/, where simple IPsec processingis regularly implemented on Minix 3.

Secure VPNs for Trusted Computing Environments 203µSINA was later supplemented by a key negotiation component [12]. To manage thehigh complexity of the IKEv1 protocol, this component was implemented as a port ofthe isakmpd server from the OpenBSD project. Two adapter components for translationto Unix sockets and the servers native management interface PF_KEYv2 [13] whereadded to simplify the port.However, the Viaduct source code is difficult to read, poorly documented and containsconsiderable amount of non-critical code, for example to route packets betweencompartments. We were also unable to test it since the development was discontinuedand does not work with the current DROPS environment. From the descriptions of theIKEv1 implementation in [12], it is also obvious that µSINA suffers from the highcomplexity of the IKEv1 standard.In contrast to µSINA, we do not aim for a generic IPsec implementation. As detailedin the following sections, we propose a more abstract VPN service instead thatimplements only a reduced set of the IPsec functionalities and exploits the potentialof secure virtualization and trusted computing architecture. The resulting design solvesmany common security issues of VPN endpoints and maximizes the leverage on policyenforcement available through remote attestation.5 IPsec SecurityThe IPsec security standard was first specified in 1995 [14]. It is a collection of Internetstandards that provide access control, integrity protection and authentication, confidentialityand partial protection against packet replay.The Internet Engineering Task Force (IETF) published the latest version of the architecturein [15], featuring mainly a simplified design and description. The associatedInternet Key Exchange (IKE) protocol was subject to a major redesign and publishedas version 2 (IKEv2) in [4]. IPsec uses two protocols to implement its security serviceson a per packet basis, Authenticated Header (AH) and Encapsulated SecurityPayload (ESP). While the latest version of AH was published without major modifications[16], the current revision of ESP [3] was enhanced with extended Traffic FlowConfidentiality (TFC) and Combined Cipher Modes. The term IPsec is used throughoutthis work to refer to this latest revision of architecture and protocols.The reader is referred to [17] for an introduction to IPsec or [18] for a review thatfocuses on cryptographic aspects. For a discussion of the IKE protocol design and alternativessee [19].5.1 Security IssuesOne of the early known security evaluation of IPsec is the comprehensive analysis in[20]. Its authors criticize the complexity of the architecture, point out several designweaknesses and also demonstrate some simple attacks. Their concerns have been confirmedwhen systematic design flaws where found in IPsec operation modes that useESP without integrity protection[21,22]. In addition, concerns about information leakagedue to traffic analysis led to the advanced TFC scheme introduced in [23]. Thiscriticism from the academic community found only limited recognition in the IETF,

204 S. Schulz and A.-R. Sadeghiwith the result that insecure configurations are still part of the standard and thus alsostill in operation. Based on these works and our own review of the latest revision of theIPsec standards and implementations, we identify the following security issues in thecurrent specifications./P1/ Encryption-only ESP. While previous attacks on ESP encryption without authenticationor with AH-based authentication have been blamed on implementations,[22] shows that it is indeed a flaw in the standard to allow encrypted traffic tobe unauthenticated or make use of other layers to authenticate the traffic./P2/ Traffic Flow Confidentiality. To prevent information leakage via traffic flowanalysis, the authors of [23] propose a combination of payload padding, injectionof dummy packets and recombination of payloads. But although the problem isacknowledged, only a small subset of the proposed traffic obfuscation mechanismswas standardized in the latest version of ESP. In addition, even these simplified TFCmeasures are not yet implemented in commodity operating systems like Linux andOpenBSD./P3/ Manual Keying. Manual keying poses a serious security threat. It provides noforward or backward secrecy and enables attacks through observation of ciphertextblock collisions. IPsec however demands explicit support for manual keying forIPsec packet processing [15], even though any secure key provisioning could beadapted to use the automated keying interface. As a result, popular IPsec instructionguides 4 tend to discuss manual keying in great detail and it must be assumed thatsuch configurations are in widespread use./P4/ Pre-Shared Key (PSK) Authentication. The IKEv2 specification [4] describesauthentication based on pre-shared keys, a feature that is also much appreciatedin IPsec configuration guides 5 and likely in broad use. As also pointed out in thespecification, PSK authentication is only secure when keys with high entropy areused. However, although such an assumption does typically not hold when keys arechosen or transmitted by humans, the specification requires ("MUST") PSK supportfor scenarios where the initiator uses a shared key and the responder uses public-keyauthentication, clearly a scheme that addresses password-based user authentication.The specification also fails to mention any rate limit behavior to counter brute forceattacks on short PSKs./P5/ Pseudo User Authentication. The IKEv2 authentication mechanismsthemselves are not aware of the type of entity that provides authentication data. Thetwo most common authentication mechanisms, public-key authentication based onX.509 certificates (PKIX) and pre-shared keys, are both often used to authenticateusers. However, none of the major IKEv2 implementations currently support "direct"user authentication. Instead, the shared key or secret key is typically stored onthe local disk, in files that are assumed to be accessible only to the platform administrator.Authentication secrets are thus actually used as tokens, allowing simpleattacks like theft or use of the access in absence of the user./P6/ Complexity. The complexity of IPsec and particularly IKEv1 has often beensubject to criticism, for example in [20] and [24]. Subsequent versions of the4 http://www.ipsec-howto.org/5 http://wiki.bsdforen.de/howto/ipsec-vpn

Secure VPNs for Trusted Computing Environments 205architecture and particularly IKE include some improvements. However, the complexityof the IPsec architecture and IKEv1 still leads to insecure deployments andeven incompatibilities in the key exchange. This complexity is not necessary however.It was noted in [20] already that transport mode is a subset of tunnel mode andthat security features provided AH can by large be replaced by a corresponding configurationand application of the ESP protocol. The IKEv2 is much more simple indesign than IKEv1, but still has considerable complexity, e.g. in the SA negotiationpayloads and the general payload design (wire format). Simpler key negotiationschemes like SKIP [25] and JFK [19] have been proposed, but not accepted for thestandard./P7/ Miscellaneous Issues. Both versions of IKE employ hash-cookies, simple challengesto efficiently filter spoofed initialization requests, thus mitigating DoS attacks[26]. More advanced protection against DoS is possible by forcing initiatorsto invest computation resources, but such proposals have been discarded by theIETF due to unclear patent encumbrance 6 . Also, since timeout lengths, retransmissioncounts and session keep-alive behavior for UDP packet transfer in IKE is notspecified, it is trivial to fingerprint IKE servers by observing such behavior [27].To achieve the security requirements, sVPN has to implement measures against thementioned problems. Section 6.6 presents measures taken to mitigate /P1/ to /P6/./P7/ is not covered in this work however, since any information leaked this way is notconsidered sensitive. As already mentioned in 3, DoS protection is not necessarily atask of the sVPN service and shall be discussed separately in section 6.2.6 sVPN DesignThe IPsec architecture uses secure channels essentially to bind transferred data to cryptographicidentities. This mapping is used to enforce a security policy for each transferreddata packet and provides the secure access control and secure channels needed insVPN. In this section we describes how the sVPN architecture was designed to complywith our requirements and how the IPsec issues discussed in 5.1 are resolved.6.1 IPsec VirtualizationAs described in requirement /R1/, sVPN must be able to implement an isolated IPsecboundary for each "protected" area. For a secure IPsec virtualization as defined in requirements/S1/ to /S3/, sVPN must also be able to identify endpoints of a requestedchannel and locate the corresponding IPsec policy.We therefore extend the IPsec policy for sVPN with fields for the source and destinationidentity of local channels. These identities can be arbitrary labels that are providedto sVPN by other security services. To establish remote channels with other IPsec gatewaysit must be possible to unambiguously address and authenticate the destinationof a channel. In particular, a standard IPsec implementation must be able to request a6 http://www.ietf.org/mail-archive/web/ipsec/current/msg02606.html

206 S. Schulz and A.-R. Sadeghichannel to a specific compartment "protected" by sVPN. To achieve this level of interoperability,existing methods for identification and authentication of peers must be used,which is why sVPN behaves like multiple VPN gateways. It uses separate IP addressesfor identification on the network layer and separate cryptographic identities for unambiguousauthentication during key exchange. If multiple IPs for a single host are notavailable, NAT (Net Address Translation) can be used to map them to a single address.This limitation is inherent to the IPsec architecture.6.2 Critical ComponentsRequirement /R6/ is achieved by aggressively delegating functionality into the untrusted"protected" and "unprotected" endpoints of each local channel. This process isrestricted by /R7/, which requires all critical functionality to reside in trusted components,i.e. in the security service in the hypervisor environment. Based on our securityrequirements, we identify the following functions as critical.– The virtualized policy enforcement described in /S1/ requires that identification,classification and policy matching algorithms are implemented in trusted components.– /S3/ requires that any component that is connected to multiple local channels thatshould remain isolated must be trusted.– To meet requirement /S5/, authentication and key exchange via IKEv2 and IPsectraffic processing must be trusted. Availability of key material is reduced by dividingthe trusted sVPN security service into two separate modules, the IKEv2 serveriked and the ipsec traffic processing component. As a result, the bulk traffic processingcomponent is isolated from any kind of long-term authentication keys orkey negotiation internals.– /S6/ and /S7/ require the complete IKEv2 key negotiation and IKE SA managementto be trusted, as well as the traffic processing components for ESP encapsulation,TFC padding, replay-protection and lifetime management of sessions andkeys.Any remaining functionality is not critical and should be provided by other compartments.Examples are IP routing, packet fragmentation, hardware drivers and NATtraversal. Since the protected and unprotected compartments need to function correctlyto establish a connection, DoS protection is only relevant if these are not compromised.Therefore, this feature can be delegated to untrusted components as well.The rather generic analysis of critical subcomponents is sufficient since our choicesin interfaces and components are limited by complexity limitation /R7/.6.3 UsabilityWe address our usability requirements /R2/ and /R3/ by providing a more abstractVPN service instead of a universal IPsec implementation. This allows us to ignore specialuse cases of IPsec and make additional assumptions about the user’s intentions. As aresult, we can ignore the IPsec transport mode as well as AH encapsulation and enforce

Secure VPNs for Trusted Computing Environments 207secure usage of ESP encapsulation. This reduces the complexity of our key negotiationand traffic processing components and facilitates the design of a usable configurationinterface. We solve the deployment issue mentioned in /R2/ and /S4/ by leveragingtrusted storage, a basic trusted computing service that allows secure transport and storageof information by sealing data to known-good system states. [28]6.4 CompatibilityAs described in /R4/ and /R5/, sVPN is required to provide basic interoperability withother IPsec-based VPNs. We implement this by staying compatible with certain operationmodes of IPsec, namely authenticated ESP encryption in tunnel mode, and byproviding a IKEv2 implementation that is sufficiently compatible with standard implementationsto negotiate this particular configuration. We leverage the flexibility of theIKEv2 negotiation to activate additional non-standard features if supported by the peer.A more detailed discussion of interoperability issues follows in section 8.6.5 Remote UsersSince VPN access for remote users is one of the main use cases of VPN technology,requirement /R4/ implies support for this scenario in sVPN. Apart from direct userauthentication required by /S6/, IP configuration of the remote "protected" compartmentis also desirable in this use case. For sVPN, we currently rely on higher levelprotocols like the Layer 2 Tunneling Protocol (L2TP, see [29]) to provide dynamic IPconfiguration. 7For direct user authentication, we aim to leverage trusted user I/O paths of the operatingsystem to protect the user’s login credentials when unsealing the IPsec authenticationkey from trusted storage. The actual authentication keys are always asymmetricand either imported from an existing PKI or automatically generated by the configurationfrontend, which also provides secure deployment. For more complex authenticationmechanisms, remote attestation of the peer’s TCB will allow to delegate critical functionalityto other security services which then vouch for successful authentication of thecorrect user.6.6 IPsec HardeningSection 5.1 discussed several issues in IPsec that need to be resolved to meet our requirementsfor sVPN. Unfortunately, the manipulation of IPsec internals is limited byour compatibility requirements /R4/ and /R5/, with the result that our IKEv2 implementationstill suffers from high complexity when compared to our processing component.Nevertheless, our modifications address all identified problems except for fingerprintingand DoS, which we declared minor.7 Native IKEv2 support through IKE configuration payloads and traffic selector narrowing isstill under investigation. Although simpler in design, these would also add non-critical functionalityto the security service.

208 S. Schulz and A.-R. Sadeghi/M1/ ESP protection. To prevent attacks based on /P1/, sVPN enforces ESP encapsulationwith encrypted authentication for all traffic that is labeled PROTECT in thesecurity policy. Weak ciphers are not supported./M2/ Advanced TFC. To mitigate /P2/, ESP processing supports Traffic Flow Confidentiality(TFC) padding as specified in [4] as well as advanced TFC featuresdescribed in [23]. Both are negotiated if supported by the peer or enforced bypolicy./M3/ Manual Keying and PSKs. To prevent weak keys and exploitable key managementas mentioned in /P3/ and /P4/, our processing component exposes only alow-level interface for automated configuration of keys and policies. To resolveproblems with weak PSKs, PSK authentication is not supported in sVPN./M4/ User Authentication. As described in 6.5, sVPN authenticates users eitherthrough direct user authentication or by leveraging other security services andtrusted storage. We expect these mechanisms to supersede the often weak and complexauthentication schemes provided by EAP or PSK and to discourage the behaviordescribed in /P5/./M5/ Reduced Complexity. To mitigate the complexity issues described in /P6/,transport mode and AH protection are not supported in sVPN. It implements onlythe minimal set of functionalities of the IKEv2 specification, which additionallywas stripped of authentication in X.509 certificate-based public key infrastructures(PKIX). Instead, sVPN currently authenticates peers based on raw RSA keysand key fingerprint whitelists. Leveraging remote attestation, sVPN may also delegateauthentication to trusted remote security services.7 ImplementationWe implemented a prototype as a proof-of-concept, to identify interoperability issuesand to estimate complexity of the solution. It encompasses the two critical sVPN componentsipsec and iked as well as simple adapters named tun2ipc and udp2ipc for connectivitywith userspace compartments.Turaya was chosen as the operating system environment. It is open source and implementsthe PERSEUS security framework based on the L4/Fiasco microkernel andmicrokernel environment of the DROPS project [30,31]. With L4Linux, a paravirtualizedversion of the Linux kernel, L4/Fiasco is also able run Linux systems as guestVMs. Access control for inter-process communication (IPC) and secure identificationof compartments through the compartment manager is not yet implemented in Turaya.Our prototype currently simulates this functionality through a local name registrationservice.7.1 sVPN ArchitectureFigure 2 provides a more detailed view of the sVPN architecture. It shows a platformwith two virtualized L4Linux compartments running on top of the Fiasco hypervisorand its environment. The two critical sVPN components reside in the hypervisor environment,next to other security services like trusted storage and the randservice random

Secure VPNs for Trusted Computing Environments 209Untrusted Components Trusted Services KernelLANnameservicerandservicetun2ipcadapterSADSPDIDsSPDikedeth0 tun0tun0 lo:0 eth0IPsec−protectedL4Linux KernelFiasco Kernel / Ressource Managementip2ipcipsectrusted storageip2ipcIPsec boundarytun2ipcadapterpolicy interfaceudp2ipcadapterudp2ipcL4Linux KernelIPsec−unprotectedWANFig. 2. Detailed architecture of sVPN. A single platform acts as a VPN gateway with two physicalnetwork interfaces. The "protected" compartment routes plaintext traffic between the LAN andsVPN. The "unprotected" compartment is responsible for routing the secured data streams intothe WAN.number generator. The two L4Linux compartments have established a local channelthrough the ipsec module and each also connect to a physical network interface. Byconfiguring the sVPN security policy such that one compartment is in the "protected"and one in the "unprotected" area, the platform is transformed into a VPN gateway,processing traffic between its two interfaces.Traffic Processing. The tun2ipc adapters establish a local point-to-point IP connectionbetween the "protected" and "unprotected" compartments. The connection is set up byconnecting to the ipsec module and requesting a forwarding to the destination compartment.The adapters then translate between the socket interface expected by the Linuxuserspace and the ip2ipc IPC interface of the sVPN service. The ipsec module acceptsthe local connection request only if corresponding policy entries exist in the SPD. Inthat case, a dedicated filter thread is spawned to handles the actual traffic processing forthis channel. The filter thread then finalizes the local ip2ipc connection by establishingthe second part to the actual destination of the channel. Once the connection is established,each thread is responsible for enforcing the locally relevant subset of the securitypolicy. Interface and implementation are further simplified by making all ip2ipc channelsunidirectional. The destination tun2ipc adapter is responsible for establishing theip2ipc connection in the other direction, provoking another filter thread to be spawnedwith corresponding subset of SPD and SAD.To identify relevant subsets of SPD and SAD, each SPD entry in sVPN also containstwo labels identifying source and destination of the ip2ipc channel they apply to, andeach SAD entry is linked to an SPD entry. With the relevant parts of SPD, SAD anda unidirectional channel, traffic processing is straight forward. The filter threads haveto enforce one of the policy targets (DISCARD, BYPASS, PROTECT) on all traffic they

210 S. Schulz and A.-R. Sadeghiip2ipcadapterip2ipcadapterconnect()write()close()connect()write()close()startFilter()ipsecfilter threadprocess()encapsulate()decapsulate()SPD(slave)SADinitSPD()needSA()addSA()delSA()reset()send_init()handle_init()send_auth()...upload_SA()ConStateikedmyIKE−SPIpeerIKE−SPIflagskeyMaterialtemp_dataSPD(master)AuthDBactiveSA SPIsget_config()new_config()connect()connect()write()close()TrustedStorageudp2ipcadapterFig. 3. Schematic overview of the iked and ipsec security modules and IPC channels. Arrowsindicate the possible direction of a call, order of calls represents a possible session flow for thatinterface. The iked component creates a ConState structure for each handshake attempt and maintainsa list of active SPIs.receive, which is trivial to achieve for the first two targets. If PROTECT is specified or anencapsulated package is encountered, the packet must be de- or encapsulated with ESP.All required information for ESP processing is contained in the SAD entries availableto the thread. If the required SAD entry is not available, the packet is discarded. In caseof encapsulation, missing SAD entries additionally trigger a request to the iked moduleto establish the required SAs. In case of decapsulation, the frames are once more parsedand matched against the SPD to check if the protected environment is allowed to receivethis packet. At this point, the SPD would typically specify BYPASS or DISCARD as thetarget, but re-encapsulation with a different SA is also possible.Successfully processed IP frames are forwarded to the adapter of the destinationcompartment. An ip2ipc adapter or its environment may implement additional uncriticalpre- and post-processing of received traffic, like IP (de-)fragmentation, NAT or bandwidthmanagement. Our prototypes simply forward all IP frames between the ip2ipcchannel and the L4Linux socket interface.Key and Protocol Negotiation. The key negotiation component iked is a simplifiedIKEv2 implementation. On startup, it retrieves SPD and long-term authentication keysfrom trusted storage and establishes the local policy and udp2ipc connections to the ipsecand udp2ipc components. The udp2ipc adapter essentially provides a UDP socket to iked,allowing it to send and receive IKEv2 UDP traffic. As can be seen in figure 3, the possiblecalls for ip2ipc and udp2ipc are very similar, the main difference is that udp2ipcattaches to a UDP socket and that the incoming IPC connection comes from the sameiked thread. Like the ip2ipc adapter, it may implement uncritical traffic transformationslike defragmentation or even handle IKEv2 protocol features like DoS protection cookiesand NAT traversal support. The policy interface between ipsec and iked is used preliminaryby iked to initialize the ipsec SPD at startup and manage the ipsec SAD at runtime.The ipsec component only uses it to request a refresh for expired or not yet negotiatedSAD entries. Both ends are also able to submit a reset command in case database inconsistenciesare detected, e.g. when one component was manually restarted.As IPsec key negotiation does not require high throughput, iked is implementedas a simple single-threaded application. SA negotiation requests from ipsec or remote

Secure VPNs for Trusted Computing Environments 211IKEv2 servers trigger a simple IKEv2 negotiation and that negotiates authenticated encryptionwith tunnel mode ESP encapsulation and the strongest available cipher suite.Features like NAT detection, DoS protection, endpoint configuration or renegotiationof SAs are not supported. If desired, these should be implement in the untrusted compartments.On success, the resulting SAs pair is uploaded to the ipsec SAD, possiblyreplacing previous instances for that SPD entry.7.2 ComplexityWe estimate the complexity of the prototype by counting lines of source code (LoC)with SLOCCount 8 , which excludes comments from the measurements. As it is custom,our measurements do not include external libraries and cryptographic primitives.However, the two critical components do not make use of use any complex librariesand the cryptographic primitives are comparatively easy to verify. Although the Mikro-SINA project did not document how LoC were measured, their reports for the Viaductcomponent do not substantially deviate from our own measurement of it with SLOC-Count (3,575 LoC). Our prototype has a total code-complexity of 5,187 LoC includingadapter components. The critical subcomponents iked and ipsec have a complexityof only 2,919 and 839 LoC, respectively, plus 917 LoC for common SPD and SADmanagement. Although our prototype still misses some important features, the differenceto standard IPsec implementations is impressive. The Mikro-SINA adaption of theisakmpd IKEv1 server in [12] has an estimated 22,800 critical LoC if unnecessary componentswere to be removed. We counted 46,600 and 30,800 LoC for the IKEv1 andIKEv2 implementations of the strongSwan project, plus 30,000 lines of IKE specificlibraries. Our ipsec module is significantly less complex than the Mikro-SINA Viaduct(839+917 vs. 3,575 LoC), since we exclude transport mode and AH encapsulation. Forcomparison, a sample of obviously IPsec related files in Linux 2.6.26 9 results in a similarfigure of about 3,500 LoC.7.3 Current StatusOur prototype successfully establishes ESP tunnels with a standard IPsec implementationand the strongSwan IKEv2 server. The connection was established with PSK authenticationhowever, since raw public key authentication is not yet implemented in ikedand strongSwan. The negotiated SAs for IKEv2 and ESP use AES-128, SHA-1 and thestandard Diffie-Hellman groups from [4]. The current implementation still misses somenecessary functionality like timeout handling and public key authentication for iked andadvanced TFC for ipsec. Still, we do not expect their complexity to rise anywhere nearthe size of standard implementations.8 Interoperability IssuesThe IPsec modifications /M1/ to /M5/ and the untypical compartmentalized architecturepotentially result in interoperability problems with standard IPsec implementations. As8 SLOCCount by David A. Wheeler: http://www.dwheeler.com/sloccount/9 include/net/{ip.h,ah.h,esp.h,xfrm.h,ipcomp.h} net/ipv4/{esp4.c,ah4.c,xfrm4*,ipcomp.c}.

212 S. Schulz and A.-R. Sadeghiwill be seen in this section however, most modifications are simply a matter of appropriateconfiguration of the IPsec peer. We shall also discuss some optional features likeIPComp and NAT detection that conflict with our compartmentalized design approach.IPsec Modifications. To reduce implementation complexity and improve security, section6.6 specified modifications to the IPsec implementation in sVPN. As described belowhowever, most of these modifications are only a question of correct configurationso that interoperation with standard IPsec implementations is still possible./M1/ Authenticated Encryption and Primitives. Employed cryptographic algorithmsand their combination are by design negotiated during key exchange and subject toSPD configuration. Standard IPsec implementations tend to include as many strong andrequired suites as possible, increasing the chance to find a common cipher suite./M2/ Advanced TFC Padding. Similarly to the extended TFC, support for advancedTFC padding can be negotiated during IKEv2 key exchange. It thus does not interferewith standard implementations except when enforced by sVPN policy./M3/ Manual Keying and PSK. Manual key provisioning and pre-shared key authenticationare alternative key distribution models supported by IPsec, along with public keyauthentication and others. sVPN in contrast supports only public key authentication.However, any resulting interoperability problems are an intended trade off for complexityand security. If desired, it is possible to use alternative key management systemsinstead and directly interface with the policy IPC interface of the ipsec module./M4/ No direct User Authentication. Although identity types are supported in theIKEv2 protocol, the authentication mechanism is ignorant of the type of entity that isauthenticated. However, direct user authentication can obviously not be enforced onIPsec implementations that do not support remote attestation or direct user authentication.The enhanced user authentication can only be beneficial to the platform thatsupports it, possibly decreasing the security of the overall network security./M5/ Transport Mode, AH, raw RSA Keys. Missing support for transport mode and theAH protocol should not result in unsolvable interoperability issues since their use is amatter of policy configuration and negotiated via IKE. The same applies for raw RSAkey authentication, although this authentication mode is less commonly supported byother IKEv2 implementations.Automated NAT Traversal. IPsec uses UDP encapsulation of ESP payloads for compatibilitywith NAT, adding 8 bytes of overhead per packet to traverse NAT routers[32,33]. In IKEv2, existence of NAT is automatically detected during SA negotiationand UDP encapsulation is activated. In sVPN however, udp2ipc abstracts from the UDPsocket interface and currently just provides a channel ID instead of ports and addresses,relieving iked from any layer 3 protocol handling. Additionally, NAT detection is not acritical feature and should ideally be implemented in untrusted components.

Secure VPNs for Trusted Computing Environments 213From a security perspective, the best solution may be to add fake NAT detection payloadsinto the IKEv2 exchange and thus transform the automated detection into a manualconfiguration option controlled by the adapters. Alternatively, the udp2ipc adapterscould provide network layer information to iked when establishing a new udp2ipc channel,thus enabling iked to implement NAT detection.IP Fragmentation. As discussed in section 7 of the specification in [15], the IPsecarchitecture has systematic issues with fragmentation. For sVPN, the relevant placeswhere fragmentation may be encountered are ESP encapsulation and decapsulation,where header information may be missing for correct policy matching of packets orauthentication of ESP fragments may fail. Additionally, the ip2ipc channel also imposesa limitation to the size of packets that may have been defragmented to larger frames inthe untrusted compartment.Our approach is similar to the suggestions in [15]. At startup, our ipsec processingthread searches their sub-SPD for any entries that require knowledge of higher layerprotocols. If such entries are not encountered, any kind of packet can be parsed accordingto policy. Otherwise, it will drop any fragmented packets and leave defragmentationto the sending adapter or its environment. For successful decapsulation, the securityservice has no choice but to rely on the sending compartment to defragment the ESPframes. Fragmented frames are dropped based on IP header information, since they willalways fail to authenticate. The behavior is optimized by setting the Don’t Fragmentbit in the IP header of outgoing ESP frames. The Maximum Transmission Unit (MTU)of the ip2ipc IPC channel is also handled in the adapter components. They must watchthe size of defragmented ESP frames or other payloads and inform the sender on thelimited maximum segment size if required.IP Compression. The IP compression standard IPComp specified in [34] compressesIP payloads, inserting itself as a logical protocol layer between the payload and the IPlayer before encryption of the packet. While it should be implemented in the tun2ipcadapters, IPComp changes the information available to ipsec. The protocol type ischanged to indicate a compressed payload and the transport layer information is notdirectly available to the ipsec module. Therefore, IPComp has to be applied betweenprocessing steps in the ipsec component and can not be delegated to untrusted components.9 Security ConsiderationsIn this section, we re-evaluate our design based on our security requirements in 3.2 toshow that all demands are met./S1/ For local IPC channels, identification of the endpoints is an implementation detailthat should be solved by the operating system’s IPC mechanisms. We alsoextended the standard SPD entries by two fields to specify source and destinationidentity each rule applies to. Even without OS support, this already allows us toimplement secure identification by providing random unique identification labelsto the untrusted compartments at startup time. Requirement /S1/ is thus fulfilled.

214 S. Schulz and A.-R. Sadeghi/S2/ We fulfill this requirement since we assume that the hypervisor enforces isolationbetween all local compartments and channels. It follows directly that anyinterconnection of compartments is thus be routed through sVPN or other trustedservices./S3/ This requirement is fulfilled by a correct implementation of the trusted service,i.e. logically isolated processing of channels in the service. We implemented thisby launching a separate processing thread for each local channel. The threads donot share any writeable resources; they could even be encapsulated in separate L4tasks so that the memory isolation is enforced by the kernel./S4/ This requirement is fulfilled since sVPN is designed to retrieve its IPsec policyand authentication secrets directly from trusted storage. The sealing functionalityof trusted computing systems protects the configuration data using public keycryptography and local attestation of the environment that requests accesses tothe data./S5/ As discussed in section 6.2, we implement all critical functionality, including allfunctionality that requires long-term authentication secrets or session keys, in thesVPN security service. Keys are only transmitted inside this module or in a localisolated channel between sVPN and trusted storage. The interfaces exposed bysVPN are equivalent to those exposed by standard IPsec implementations. Basedon the security of the IKEv2 and ESP protocols, it follows that no covert channelsexist to retrieve key material. Additionally, we reduced the availability of shortandlong-term keys to the required subcomponents./S6/ As a trusted component in the security services layer, our service is able to directlyconnect to other trusted security services. These in turn are able to establishphysical presence of a user or to enforce arbitrary authentication schemes.Although not yet implemented in our prototype, our design thus fulfills /S6/./S7/ We hardened our traffic processing based on our review of IPsec security issues insection 5.1. Additionally, we aim to provide optional advanced protection againsttraffic flow analysis (advanced TFC). Except for possibly weak authenticationmodes, which we addressed through direct user authentication in section 6.5,there are no relevant security issues with IKEv2. There are thus no known problemswith the secure channels provided by sVPN.10 ConclusionWe proposed an adaption of the IPsec architecture for VPNs in trusted computing environments.In accordance with the PERSEUS security concepts, we isolated criticalfunctionality into self-contained subcomponents of minimal complexity. We solved severalsecurity issues of IPsec by reducing the framework to a simple VPN service anddiscussed how additional features can be integrated in a compatible fashion.The result is a high-security VPN service that should provide a high usability. Thearchitecture solves the conflict of interest between owner and user in the remote user usecase, allowing companies to deploy machines that are highly secure regarding access tothe company VPN and applications, but use flexible compartments to suite the needs ofthe employees. Its small code-size and modular design make sVPN an ideal target forfuture research on secure channels in trusted environments.

Secure VPNs for Trusted Computing Environments 21511 Further WorkAs noted in section 7.3, our implementation is far from complete. We also postponedinvestigation of IKE mobility extensions [35] , resistance against timing-based sidechannelattacks and detailed performance optimizations.For remote attestation, the Trusted Network Group (TNG) proposes an extensiveframework in [36]. However, these specifications seem to add significant overhead tosVPN. It remains an open question if similar flexibility can be achieved through othermeans or if this level of flexibility is even required.References1. Sadeghi, A.R., Stüble, C.: Bridging the Gap between TCPA/Palladium and Personal Security(2003), citeseer.ist.psu.edu/575430.html2. Helmuth, C., Warg, A., Feske, N.: Mikro-SINA - Hands-on Experiences with the Nizza SecurityArchitecture. In: Proceedings of the D.A.CH Security (March 2005)3. Kent, S.: IP Encapsulating Security Payload (ESP). RFC 4303, Internet Engineering TaskForce (December 2005)4. Kaufman, C.: Internet Key Exchange (IKEv2) Protocol. RFC 4306, Internet EngineeringTask Force (December 2005)5. Kocher, P.C.: Timing attacks on implementations of diffie-hellman, rsa, dss, and other systems.In: Koblitz, N. (ed.) CRYPTO 1996. LNCS, vol. 1109, pp. 104–113. Springer, Heidelberg(1996)6. Percival, C.: Cache missing for fun and profit. In: Proceedings of BSDCan 2005 (2005)7. Sailer, R., Valdez, E., Jaeger, T., Perez, R., van Doorn, L., Griffin, J.L., Berger, S.: sHype:Secure Hypervisor Approach to Trusted Virtualized Systems. Research Report RC23511,IBM Research (February 2005)8. Garfinkel, T., Pfaff, B., Chow, J., Rosenblum, M., Boneh, D.: Terra: A Virtual Machine-BasedPlatform for Trusted Computing. In: Proceedings of the 9th ACM Synopsium on OperatingSystem Principles, pp. 193–206 (2003)9. Shapiro, J., Hardy, N.: EROS: A Principle-Driven Operating System from the Ground Up.IEEE Software, 26–33 (January 2002)10. Härtig, H., Hohmuth, M., Feske, N., Helmuth, C., Lackorzynski, A., Mehnert, F., Peter, M.:The Nizza Secure-System Architecture. In: Proceedings of IEEE CollaborateCom 2005, p.10. IEEE Press, Los Alamitos (2005)11. Heiser, G., Elphinstone, K., Kuz, I., Klein, G., Petters, S.M.: Towards Trustworthy ComputingSystems: Taking Microkernels to the Next Level. ACM Operating Systems Review 41(4),3–11 (2007)12. Syckor, J.: IPSec Infrastruktur für Mikro-SINA, Diplomarbeit, Technische Universität Dresden(November 2004), os.inf.tu-dresden.de/papers_ps/syckor-diplom.pdf13. McDonald, D., Metz, C., Phan, B.: PF_KEY Key Management API, Version 2. RFC 2367,Internet Engineering Task Force (July 1998)14. Atkinson, R.: Security Architecture for the Internet Protocol. RFC 1825, Internet EngineeringTask Force (August 1995)15. Kent, S., Seo, K.: Security Architecture for the Internet Protocol. RFC 4301, Internet EngineeringTask Force (2005)16. Kent, S.: IP Authentication Header. RFC 4302, Internet Engineering Task Force (December2005)

216 S. Schulz and A.-R. Sadeghi17. Doraswamy, N., Harkins, D.: IPsec: The new Security Standard for the Internet, Intranetsand Virtual Private Networks, 2nd edn. Prentice Hall PTR, Englewood Cliffs (2003)18. Paterson, K.G.: A Cryptographic Tour of the IPsec Standards,citeseer.ist.psu.edu/737404.html19. Aiello, W., Bellovin, S.M., Blaze, M., Ioannidis, J., Reingold, O., Canetti, R., Keromytis,A.D.: Efficient, DoS-resistant, secure key exchange for internet protocols. In: CCS 2002:Proceedings of the 9th ACM conference on Computer and communications security, pp. 48–58. ACM, New York (2002)20. Ferguson, N., Schneier, B.: A Cryptographic Evaluation of IPsec (2000),www.schneier.com/paper-ipsec.html21. Bellovin, S.: Problem Areas for the IP Security Protocols. In: Proceedings of the Sixth UsenixSecurity Symposium (July 1996)22. Degabriele, J.P., Paterson, K.G.: Attacking the IPsec Standards in Encryption-only Configurations(2007), eprint.iacr.org/2007/12523. Kiraly, C., Bianchi, G., Formisano, F., Teofili, S., Lo Cigno, R.: Traffic masking in IPsec:architecture and implementation. In: Mobile and Wireless Communications Summit, 16thIST, pp. 1–5 (2007)24. Simpson, W.A.: IKE/ISAKMP Considered Harmful. Usenix, login 24(6) (December 1999)25. Aziz, A., Patterson, M.: Design and Implementation of SKIP. In: INET 1995 HypermediaProceedings (1995)26. Kaufman, C., Perlman, R., Sommerfeld, B.: DoS protection for UDP-based protocols. In:CCS 2003: Proceedings of the 10th ACM conference on Computer and communicationssecurity, pp. 2–7. ACM, New York (2003)27. Izadinia, V.D., Kourie, D., Eloff, J.: Uncovering identities: A study into VPN tunnel fingerprinting.Computers & Security 25(2), 97–105 (2006)28. Storage Work Group. Tcg storage architecture core specification. Technical report, TrustedComputing Group (May 2007)29. Lau, J., Townsley, M., Goyret, I.: Layer Two Tunneling Protocol - Version 3 (L2TPv3). RFC3931, Internet Engineering Task Force (2005)30. Alkassar, A., Stüble, C.: Die Sicherheitsplattform Turaya. In: Trusted Computing, pp. 86–96.Vieweg+Teubner (May 2008)31. Härtig, H., Roitzsch, M.: Ten years of research on l4-based real-time systems. In: Proceedingsof the Eighth Real-Time Linux Workshop (2006)32. Aboba, B., Dixon, W.: IPsec-Network Address Translation (NAT) Compatibility Requirements.RFC 3715, Internet Engineering Task Force (2004)33. Huttunen, A., Swander, B., Volpe, V., DiBurro, L., Stenberg, M.: UDP Encapsulation of IPsecESP Packets. RFC 3948, Internet Engineering Task Force (2005)34. Shacham, A., Monsour, R., Pereira, R., Thomas, M.: IP Payload Compression Protocol (IP-Comp). RFC 2393, Internet Engineering Task Force (December 1998)35. Eronen, P.: IKEv2 Mobility and Multihoming Protocol (MOBIKE). RFC 4555, Internet EngineeringTask Force (June 2006)36. TNC Work Group. Architecture for interoperability. Specification, Trusted Computing Group(April 2008)

Merx: Secure and Privacy Preserving DelegatedPaymentsChristopher Soghoian 1 and Imad Aad 21 Berkman Center for Internet and Society, Harvard University, USAcsoghoian@gmail.com2 DOCOMO Euro-Labs, Germanyaad@docomolab-euro.comAbstract. In this paper we present Merx, a secure payment system thatenables a user to delegate a transaction to a third party while protectingthe user’s privacy from a variety of threats. We assume that the user doesnot trust the delegated person nor the merchant and wishes to minimizethe information transmitted to the user’s bank. Our system protects theuser from fraud perpetrated by the delegated party or by the merchant.The scheme has a number of other applications such as delegating thewithdrawal of cash from Automated Teller Machines (ATM) and allowingcompanies to restrict an employee’s expenses during business trips.Merx is designed to be used with mobile phones and mobile computingdevices, especially in situations where end-users do not have access to theInternet. We evaluate the performance of the proposed mechanism andshow that it requires negligible overhead and can be gradually deployedas it is able to piggyback on existing payment-network infrastructures.1 IntroductionA new form of mobile electronic payments is on the horizon and is alreadybeing used in a few advanced markets. This technology, based on Near FieldCommunications (NFC), allows people to use their mobile phones to pay fortickets, goods and services in a practical and fast way. Users simply wave theirmobile phone over a pad and they’re done [1]. Mobile phones with e-wallet andcredit card capabilities will soon replace our wallets and the paper currencywithin as the means of paying for shopping, a restaurant bill or even as a wayto give “virtual pocket money” to your children before they go on holiday.While these NFC-based mobile payment systems are ideal for in-person transactions,they do not (yet) allow users to delegate purchases. Mobile systems arenot alone in failing to address this need, as most other existing electronic paymentschemes also fail to provide usable delegated payment functionality.Traditional payment methods require that users place significant trust in thoseto whom they delegate tasks. Parents cannot prevent their teenage children, awayon holiday, from spending food money on alcohol and other unapproved products.Servants and cooks may opt to purchase lower quality food with the week’sL. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 217–239, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

218 C. Soghoian and I. Aadbudget and keep the money that they saved for themselves. Companies cannotbe sure how their traveling employees are spending their per diem budget. Manypeople in remote areas of developing countries without banking services nearbymust give their ATM card and Personal Identification Number (PIN) to friendsor family who are themselves making the journey to the ATM several hours away[2]. While these individuals only wish to have a moderate sum withdrawn, theymust trust their friends not to completely drain their account.We present a system for securely delegating a payment or withdrawal task toa third party (e.g. the concierge, in an example setting involving a customer, aconcierge, a merchant and a bank). We provide a means for restricting the itemsthat can be purchased. Our system is privacy preserving, in that the accountholder does not reveal her shopping list to the bank, yet it provides a means forthe bank and merchant to communicate in order to prevent un-approved itemsfrom being purchased. Our scheme does not suffer from the problems of doublespending. Furthermore, merchants do not learn the customer’s name or bankaccount details. The scheme allows for a shopping list to be partially fulfilled bymultiple merchants, without requiring that the consumer specify them ahead oftime. The scheme also enables the consumer to restrict which delegated partiesmay retrieve the items, as well as restricting, should she wish, which merchantsare permitted to sell the selected items.Our proposed payment system provides privacy preserving transaction delegationto users with mobile phones and portable computing devices. Our schemeis not dependent on mobile Internet access or NFC capabilities. As we will showin the following sections, our system can also be used by fixed computers withor without Internet service. However, the most likely usage scenario involves auser delegating payments with her smart-phone, PDA or laptop.When considering the problem of payment delegation in the real-life scenariosthat we have described, it is easy to see that the existing payment methods,such as cash, credit cards and even some digital payment schemes, simply donot provide the needed functionality. As we show below, existing schemes thatpermit payment delegation are simple and prone to abuse. Later, in the relatedwork section, we show why the Internet-based solutions lack the features requiredfor real-world mobile commerce.The Problems of Delegation Using Cash: The simplest of the traditional delegationmethods involves giving someone cash and telling them what they canand cannot purchase. The security of this system relies completely on trust. Thepayer has no way of knowing if the delegated party will run off with the moneyor attempt to purchase inferior-quality goods and pass them off as the genuinearticle.The Problems of Delegation Using Credit Cards: Many businesses give theiremployees corporate credit cards. This method of delegation also involves a fairlysignificant amount of trust. Information on the individual items purchased is notprovided to the credit card company by the merchants but rather the merchant

Merx: Secure and Privacy Preserving Delegated Payments 219ID only. Thus, the business has no reliable method of knowing which items anemployee has purchased.Another significant problem which credit cards introduce is that of insidertheft, or a data loss incident by the merchant. For a credit card transaction toprocess successfully, the customer, or concierge must provide her credit card detailsto the merchant during the sale. A malicious merchant, a corrupt employee,or an intrusion by hackers and subsequent theft of data from the merchant’sdatabase can result in the theft of a customer’s credit card information. Whilemost credit card companies place minimal, if any liability on the customer incases of credit card fraud, the very act of disputing invalid charges, cancelinga credit card and requesting a new one can be time consuming and disruptive.Any scheme which prevents the merchant from gaining access to the customer’scredit card information will avoid these problems.The Problems of Delegation Using Reimbursement. Another delegation schemecommonly used by businesses requires that employees pay for all expenses withtheir own funds, collect receipts, and then submit expense reports afterwards.This system has a number of downsides. Employees often resent the loan theyare essentially making to their employer. Prolonged business travel or legitimatelarge purchases can result in financial difficulties for employees. Employees canalso forge false receipts.The rest of the paper is organized as follows: In Sec. 2 we discuss related workin the field of electronic payment systems. In Sec. 3 we present the system modeland the proposed solution. In Sec. 4 we evaluate the privacy protections providedby our solution and the processing and communication overhead. Section 5 showsexample applications of our payment delegation method., and Sec. 6 concludesthe paper.2 Related WorkThere has been a considerable amount of research into electronic payment systemsover the past few years. [3] lists several of these payment schemes. Theunderlying characteristic of all of the proposed systems is obviously “security.”Other desirable properties include scalability, anonymity, non-repudiation, delegability,and various others that are specific to certain applications. We can splitmost of the electronic payment techniques into two groups: macro and micropayments.While macro-payments are typically used to exchange high valuesums, micro-payment techniques [4,5,6,7,8,9,10,11] involve far smaller amounts ofmoney that are typically used to pay for Internet-based services such as streamingmulti-media, software downloads, VoIP etc. The major features that differentiateour scheme from existing payment systems are: delegability and theability to function offline. Other differences are cited in the later sections, afterintroducing the technical details of our approach.Anonymity is an appealing feature for numerous applications. The challengingproblem with anonymity is that it typically contradicts non-repudiation, an essentialproperty in payment systems. The iKP scheme [4], one of the first papers

220 C. Soghoian and I. Aadto tackle this issue, is also quite similar to our system. iKP (where i=1,2,or3) is a set of protocols where the security and complexity of the system increasewith i. The protocols implement credit card based transactions between a customer,a merchant, and a bank while using the existing payment networks forgradual deployment. A requirement of the 1KP protocol is that the bank mustcreate an asymmetric encryption key pair and publish its public key. Customersand merchants must have a copy of the bank’s public key in order to engage incommerce. While the bank’s communications can be authenticated through theuse of public key based signatures, a customer can only authenticate herself in1KP by using her credit card number and PIN which she then encrypts with thebank’s public key. The 2KP protocol is similar, although both the merchant andbank are required to have asymmetric cryptographic keys. 3KP further requiresthat the customer also have a public and private encryption key pair. Unlike oursystem, the iKP protocols do not support delegation 1 . As a result, our goals ofattempting to control which items can be purchased and a desire to keep themsecret from the bank are both not possible with the iKP protocols.Until recently, research into payment delegation was almost completely absentfrom the literature. The projects most relevant to our work is the research doneby Patil et al. [12,13,14,15]. In [12,13] the authors propose a micro-paymentsystem called e-coupons. Their system is secure, like most payment schemes.However, they also provide transaction delegation in such a way that users donot have to obtain an authorization from the bank before each payment. Ane-coupons user wishing to delegate payments first requests a “PayWord” [8]chain from the bank, which enables them to pre-register multiple transactiondelegations for a single vendor. The user must sync with each vendor before aPayWord chain can be used. The user can also delegate control of a portion ofa PayWord chain to other agents. For Internet-based commerce, it is perfectlyreasonable to require users to synchronize with the bank and vendor beforeany actual exchange of goods. However, this requirement can be a significantproblem for real life scenarios in which users might not have regular Internetaccess. Furthermore, the e-coupons scheme requires that the delegating personknow the identity of the merchants ahead of time, which is almost impossible inmany situations. Finally, the e-coupons system does not allow the customer toremain anonymous with respect to the merchant.Our delegation solution applies to the real-life scenarios discussed above withoutthe need for any apriori customer contact with the bank or the merchants.It is secure, preserves the anonymity of the user, and can involve one or severalmerchants without extra preparation overhead. In fact, our solution keepsthe apriori contacts between all involved parties to an absolute minimum: withoutcontacting the bank or the merchant(s), the user passes the “token” to theconcierge at the same time as the shopping list. The concierge passes the tokento the merchant as she purchases at the checkout. The merchant contacts the1 More precisely, iKP assumes that the issuer and inquirer (the customer and conciergein our protocol) share some level of trust, an assumption that runs contrary to oneof the central design requirements for our system.

Merx: Secure and Privacy Preserving Delegated Payments 221bank only during the payment. We believe that reducing the number of aprioricontacts is vital for a system to succeed in real-life scenarios.In addition to keeping the number of contacts to a minimum, our techniquepreserves the privacy of the user foremost. The concierge obviously has no accessto the user account number or PIN (similar to e-coupons), and the user’s identityis kept hidden from the vendor, and even optionally from the concierge, unlikee-coupons. The shopping items are kept hidden from the bank, while still givingit control over what is allowed to be purchased. The e-coupons system can hidethe purchased items from the bank, however, it is not possible to control whatcan be bought from a given vendor. For these reasons, we believe that e-couponsand the other payment schemes are not suited to real-world delegated payments.One of the key standards for securing electronic payments is SET [11], originallydeveloped by VISA and MasterCard. In spite of the strong industry backing,SET failed to gain market share due to a number of reasons, one of which wasthe logistics of client-side certificate distribution, i.e. requiring every user to havean asymmetric key pair. Merx leverages the level of trust that customers usuallyshare with their banks, to keep the “default requirements” for the customers to aminimal level, and therefore increase the chance of rapid market penetration.Finally, mobile-banking (commonly known as m-banking) [16] is a rapidlygrowing industry, that aims to bring financial services to the world’s underbankedvia the millions of deployed mobile phone handsets. M-banking schemesare similar to Merx, in that they function primarily using the customer’s phone.However, the m-banking products already on the market do not allow for delegationof payments, controlled purchases are limited to specific products, nor dothey function when the customers are in areas without cellular connectivity.3 System ModelWe will first introduce the actors who interact using Merx 2 , their goals, andwhat they will hope to get out of the scheme. We then provide the technicaldescription of the whole system.3.1 The ActorsWithout loss of generality, we consider an example scenario in which a customerdelegates a concierge to purchase goods from a merchant, wherethepaymentisprocessed by the customer’s bank.The Customer: This person would like to have a third party, the concierge,purchase one or more items for her. She wants to be sure that the concierge canonly buy the items that she has specified, within the price constraints she hasdictated. She also requires that the merchant does not know who she is, thatthe bank does not know what she bought, and that neither the concierge normerchant should be able to learn her credit card or bank account information.2 From Latin, “merchandise, goods”.

222 C. Soghoian and I. AadThe Concierge: This person is hired by the customer to visit one or moremerchants and purchase items listed on a supplied shopping list. Depending onhow the list is transmitted to the concierge (possible methods include Bluetooth,Multimedia Messaging Service (MMS), email and a paper print out) and howitems are delivered to the customer, it is quite possible that the concierge maynever learn the customer’s identity. The concierge will not learn the customer’sfinancial details, including her bank or credit card account numbers.The Merchant: The merchant is a business with goods or services to sell.It wants to be sure that the customer’s banking information provided by theconcierge is valid and that the items are authorized (by the user, then the bank)before it permits the transaction. The merchant will not learn the identity northe financial details of the customer.The Bank: The customer has a pre-existing relationship with the bank. Thiscan be a more traditional bank account, a debit card, or a credit card. Thebank will never learn which items the customer has purchased. It will, however,learn the maximum price specified for each item as well as a maximum value forthe entire shopping list. The bank will enforce these limits by refusing to allowtransactions with a total price higher than the customer specified maximumvalue. Working with the merchant, the bank will also ensure that only those itemsdescribed in the shopping list will be approved for purchase by the customer.In other use cases, the bank can be substituted by a mobile phone operatorcharging its susbscribers using their monthly bills.Unlike most of the various existing techniques cited before, we reduce thenumber of interactions between the different actors to an absolute minimum:Neither the customer nor the concierge need to contact the bank and/or merchantprior to the actual sale of goods. Reducing the requirements for contactbetween the actors is of high practical relevance since we are primarily focusingon in-person retail experiences, rather than online purchases. Furthermore, thisis essential to permit the creation of tokens when the customer and concierge donot have Internet access.3.2 Secure and Privacy-Preserving Delegation SystemThe customer creates a shopping list (Fig. 1(a)) and the corresponding token(Fig. 1(b)). She transmits them both to the concierge, who acts as the delegatedparty. The concierge then passes the token and the list of items to be purchasedto the merchant, which validates the purchases with the bank. This process willbe described in detail below.Creating The Token: We now gradually present our solution, along with themotivation for each added component.– Motivation: The customer wishes to securely communicate her account informationto the bank, while keeping her account number (Acct#) and PINsecret from the merchant and concierge.

Merx: Secure and Privacy Preserving Delegated Payments 223(a) List (b) Decrypted token (c) Token QR codeFig. 1. A sample Merx shopping list, with the decrypted contents of the correspondingtoken and its QR codeSolution: Encrypt the token using the bank’s public key and require thatthe user enter her PIN each time a token is created. 3(...Acct#,PIN...) BankPubKAdvantages:• If the concierge’s mobile phone is stolen, a printed copy of the token islost or if the concierge is malicious, the customer’s Acct# andPINarenot revealed.• If the merchant accidentally loses a copy of the transaction data or suffersfrom a data breach, the customer’s Acct# and PIN are kept safe.• The merchant does not learn the customer’s identity.• If enough customers delegate the same concierge, it is possible to gainsome level of anonymity with respect to the merchant. As the numberof customers delegating any one concierge grows, the anonymity set alsoincreases. One example of this is a grocery delivery service used by severalcustomers.• If customers transmit their data to the concierge via Bluetooth, MMS,fax or the Internet, it is even possible to be anonymous with regard tothe concierge (using some kind of drop-box for the delivery of goodsafterwards).3 To validate the PIN locally, and avoid giving the concierge a token with an invalidPIN, a hash of the PIN concatenated to a salt value (h(PIN||salt)) can be encryptedand stored on the phone. This data will be encrypted with the phone’s PIN, whichthe user will be required to enter (along with her bank PIN) each time a token iscreated.

224 C. Soghoian and I. Aad– Motivation: Restrict the concierge to purchasing only those pre-selecteditems specified by the customer.Solution: Include the list of items in the token.(...item 0 ...item i ...) BankPubK– Motivation: Prevent the bank from learning which items are to be purchased.Solution: Compute a unique item identifier for each item, made by hashingthe concatenation of the item number and the transaction ID. Then, create a256-bit unique random number for each item. Finally, concatenate the itemidentifier and the random number, and hash this result. This will act as aprivacy-preserving item hash, which can be given to the bank.(...h(item 0 ||TransactionID||r 0 ) ...h(item i ||TransactionID||r i )...) BankPubKWhen items are purchased by the concierge, the merchant will calculate thehash of the item and its associated random number, and send the hash tothe bank to validate the purchase.Advantages:• The transaction can be split into n sub-transactions 4 .– Motivation: Restrict the concierge role to a specific individual.Solution: Include the Concierge’s ID in the token and/or require a transactionPIN at time of purchase.(...ConciergeID,TransactionPIN...) BankPubK– Motivation: Forbid double spending.Solution: Include a transaction identifier in the token, e.g. a timestamp anda unique, randomly generated transaction ID:(...TimeStamp,TransactionID...) BankPubK– Motivation: Set a maximum total price for all transactions authorized by atoken.Solution: Include a maximum total price field in the token, which the bankwill verify before permitting a transaction.(...TransTotal...) BankPubK– Motivation: Include open options in the token to enable future features, e.g.disallow specific merchants.4 From a brute-force attack computation point of view, h(item||TransactionID||r)is equivalent to h(item||r ∗ ) where r ∗ is orders of magnitude larger than r.h(item||TransactionID||r) is used instead to save storage space.

Merx: Secure and Privacy Preserving Delegated Payments 225(...options...) BankPubK– Motivation: Protect the transaction token from tampering by malicious persons.Solution: Use a Keyed-Hash Message Authentication Code (HMAC) to makethe token tamper evident. This is done by including a 256-bit randomly generatedkey, MacKey in the token, which is used to compute the HMAC ofthe encrypted token. Both the HMAC and encrypted token will be given tothe concierge, merchant and bank.(...MacKey...) BankPubKThe resulting token format therefore is:TransToken= Acct#,PIN,h(item 0 ||TransactionID||r 0 ) ...h(item i ||TransactionID||r i ),TransTotal,ConciergeID,TimeStamp,...T ransactionID, MacKey, options) BankPubKWith an associated Transaction HMAC calculated by 5 :Trans H MAC = HMAC MacKey (TransToken)A sample Merx shopping list with the corresponding token and its QR codeare shown in Fig. 1. The customer transmits the token, its HMAC, along withthe list of items item 0 ...item i and the associated random numbers r 0 ...r i (inclear text) to the concierge by one of many mediums including using MMS,Bluetooth, Infrared, Display on Mobile, or a paper print-out.From Concierge to Merchant: Once at the place of business, the conciergetransmits the token (using MMS, Bluetooth, infrared, reader/camera/OCR) andthe list of only those items that will be purchased to the merchant. Giving themerchant the complete shopping list (item 0 ...item i ) with each item’s randomnumber (r 0 ...r i ) will enable a malicious merchant to submit charges to thebank for authorized but not as yet purchased items. In order to ensure thatthe concierge maintains control over the items for which the merchant can requestpayment, the concierge gives the merchant using any of the communicationmethods mentioned above:– the token,– item i of each item purchased from this merchant,– r i of each item purchased from this merchant,– ConciergeID or transaction PIN, if specified by the customer at time of tokencreation,5 Computing an HMAC of the encrypted token, a.k.a. Encrypt-then-MAC, is themost robust among the 3 choices [17,18]: Encrypt-and-MAC, MAC-then-encrypt,and Encrypt-then-MAC.

226 C. Soghoian and I. AadFrom Merchant to Bank: The merchant computes the hash of each of theactually purchased items h(item 0 ||TransID||r 0 ) ...h(item i ||TransID||r i )andpasses them along with the encrypted transaction token to the bank.The bank decrypts the token using its private key and then:– checks the token integrity using the HMAC– validates the customer’s account number and PIN, ensuring that sufficientfunds are available in her account,– looks up the token’s transaction ID in a database of previously redeemedtokens. It then verifies that none of the items to be purchased have alreadybeen bought using that token,– compares the concierge ID or transaction PIN transmitted by the merchantto the one contained in the encrypted token,– compares the actually purchased items as computed by the merchanth(h(item 0 ||TransID)||r 0 ) ...h(h(item i ||TransID)||r i ) to those in the encryptedtoken,– checks the additional options in the token,then approves or rejects the transaction accordingly.3.3 Specification languageSo far we have assumed that the user can convey her shopping or restrictionneeds in an intuitive way to the bank. When it gets to the implementation,a specification language must be designed [19], similar to the ones used in supermarketsnowadays: groups (e.g. drinks), sub-groups (e.g. alcohol), sub-subgroups,..., down to the individual items (e.g. beer). This grouping should befurther combined with “black list”, “white list” that permit the user to specifywhich groups/items are allowed, and which are not. Using such a specificationlanguage, a company can give its employees, going on a business trip, some tokensfor buying given items (e.g. food, drink), while restricting others (e.g. strongalcohols). Though essential to the deployment of Merx for large scale automaticusage, and since it is orthogonal to the security and privacy aspects, we keepthis specification language out of scope of this paper.3.4 A Revocation ProtocolThe customer can contact the bank using any secure method (online, phone, inperson) to revoke a given token. The customer will need to provide the uniquetransaction token ID or the entire token, as well as confirming her account numberand PIN to prove that she created the token. The requirement to transmither PIN to the bank can be eliminated through the use of a zero knowledgebased key exchange protocol [20,21], but this is beyond the scope of our paper.Should the customer wish to permit concierges to revoke tokens, such as incases where the concierge loses a token that has not been locked with a transactionPIN, the customer would need to include a unique and random revocation

Merx: Secure and Privacy Preserving Delegated Payments 227number within the options field of the transaction token at time of token creation.This number would then be communicated to the concierge along withthe encrypted token and shopping list, as well as instructions on how to contactthe bank in case of loss.4 System PerformanceIn this section we evaluate our scheme and its ability to withstand a number ofdifferent attackers with a variety of capabilities. We also evaluate the system’scommunication and processing overhead.4.1 Adversarial ModelWe consider a multi-role adversarial model that takes into consideration whatthe adversary is assumed to be able to do during an attack against the system.1. A malicious concierge is able to save and later access transaction tokens andshopping lists. She can attempt to modify and reproduce the saved tokensand lists at a later date as well as attempt to use them with non-colludingmerchants. In cases where the user discloses her identity to the concierge,that concierge may disclose the user’s identity to others.2. A malicious merchant is able to save and later view transaction tokens,shopping lists, concierge IDs and any other data given to it during previoustransactions. It may later attempt to redeem them with a non-colludingbank.3. A malicious bank is able to save and later view transaction tokens and anydata given to it by merchants.4. A malicious customer, willing to fraudulently repudiate his shopping bills.5. A colluding concierge and merchant is the combination of adversaries (1) and(2). The concierge works with the merchant to try and defraud the customeror to evade the restraints imposed by the shopping list.6. A colluding merchant and bank is the combination of adversaries (2) and(3). The merchant and bank work together to try to reveal the identity andfull shopping list of the customer.7. A colluding concierge and bank is the combination of adversaries (1) and(3). The concierge and bank work together to reveal the identity and fullshopping list of the customer.4.2 Security and Privacy AnalysisWe now explore the options available to each adversary, and describe whichsensitive information they know and can potentially reveal to those with whomthey collude. This can also be seen visually in Figure 2.

228 C. Soghoian and I. AadConciergeNormal exchangeCollusion exchangeUser (?)(PIN)_BankPubK(Accnt#)_BankPubKitem_a , r_a{item_b , r_bitem_c , r_c{(unpurchased) item_d , r_dclear txtMerchant(PIN)_BankPubK(Accnt#)_BankPubKitem_a , r_aitem_b , r_b}item_c , r_cUserPINAccnt#h(item_a , r_a)h(item_b , r_b)h(item_c , r_c){{}HashedBankFig. 2. A representation of the information that each potentially malicious party knowsand what they can provide to those other entities with whom they collude. One caneasily see the advantage over existing payment systems, for instance the one-time-usecredit cards: using Merx the merchant does not know who the customer is.A Malicious Concierge: This attacker has very few options. Any attemptsat modifying, forging or replaying transaction tokens will be detected by thebank and rejected. If the customer sends the token to the concierge via anelectronic medium, the concierge may never never learn the customer’s identity.Furthermore, the concierge never learns the customer’s account number and PIN,and thus, it is impossible to later create fraudulent tokens.The size of the customer’s anonymity set [22] increases as the number ofother customers employing a single concierge (or a delivery service) increases.Customers who purchase uncommon items will reveal some information, enablingthe linking of multiple transactions even though the customer’s true identityremains unknown.A Malicious Merchant: This adversarial scenario includes both corrupt merchantsand situations involving an insider attack, where an employee of themerchant misuses or steals customer records. As the merchant never learns thecustomer’s name or account information, any system breach or data loss incidentinvolving the merchant’s computer systems will not result in the release ofidentifiable customer data or billing information. The only link to the customerthat the merchant has is the identity of the concierge. This link can be furtherweakened if the customer communicates with the concierge electronically.

Merx: Secure and Privacy Preserving Delegated Payments 229A Malicious Bank: The bank is prohibited from learning the individual itemsthat a customer purchases at each merchant. The bank is only able to learnhow many total items are on a shopping list, how many items from the list havebeen purchased at each merchant, and the total transaction cost charged by eachmerchant.Customers have their anonymity reduced when large shopping lists are brokenup into smaller transactions. In situations where consumers wish to permit thepurchase of a number of fixed and uniquely priced items from multiple merchants,it may be possible for the bank to learn which items the customer listed in theirshopping list.For example, this attack is possible when a concierge buys a single item fromeach of several merchants. While the bank does not know which items have beenpurchased, it does know how much each item costs, due to the the fact that eachtransaction was for a single item. Bank employees can later visit the merchant’sstore and attempt to find all items sold by the merchant for any particular price.This item identification risk can be mitigated through the purchase of variableprice/quantity items (such as bulk weight food items), items from merchantsthat charge the same price for a large variety of different goods, or by requiringper-merchant transactions to consist of at least two or more items.Repudiation Issues: RelyingonsharedPINsthatareknowntoboththecustomer and the bank for authentication can lead to repudiation issues: thecustomer may try to dispute a given shopping bill by accusing the bank of forgingit. This same problem exists under the existing banking system, and with thefinger pointing that has occurred with “phantom withdrawals.” That particularproblem has been mostly solved through legal liability. In many countries, theburden is on the bank to prove that the charge was valid, not for the customerto prove that it was fraudulent [23].Our scheme provides customers and banks with the same level of trust thatthey currently have using existing banking technologies (ATM, credit cardcharges without a signature, etc.). To avoid many repudiation issues, just aswith 3KP [4], the bank could require that specific customers (e.g. who usuallyperform highly valuable transactions) sign transaction tokens with their privatekeys. This of course introduces the overhead of issueuing public/private key pairsfor those customers. By assuming a level of mutual trust between the bank andthe customer equal to the relationship that already exists with “traditional”bank accounts, we are able to keep the default authentication of Merx as PINbased,and introduce key pairs for a fraction of customers, should they or themarket demand it.In addition to the repudiation issues between a customer and a bank, there isalso the possibility of a dispute between the customer and merchant. In the casethat a merchant sells a concierge a defective or poor quality item, the customerwould not discover the problem until the concierge delivered the goods. Thissituation is in no way unique to our scheme, and is a major problem for cashbasedtransactions. This problem is beyond the scope of our scheme, as we focus

230 C. Soghoian and I. Aadon giving customers at least the same level of protection that they have withcash-based transactions.A Colluding Concierge and Merchant: The bank does not learn the pricecharged for each item and instead relies on the merchant to enforce the maximumprice specified for each item in the shopping list. Thus, in this collusion scenario,the merchant can also overcharge for individual items. This risk can be mitigatedby requiring that merchants transmit the price of each item to the bank, butthis will result in a loss of purchase privacy for the customer.It is not possible to protect the privacy of the customer’s shopping list fromthe bank, without at the same time enabling a colluding merchant and conciergeto bypass the shopping list restrictions. This more advanced adversary is able toneutralize the enforcement of shopping lists. For example, the customer can listapples on her shopping list, yet the concierge can instead purchase oranges. Thecolluding merchant will provide the concierge with oranges but send the banka transaction with the (hashed) apple item in the shopping list. The maximumtotal price specified in the transaction token will at least protect the customerfrom more egregious abuses.A Colluding Merchant and Bank: This advanced adversary is able to neutralizethe privacy protection associated with shopping lists. The merchant canreveal the complete shopping list to the bank, and thus permit the bank to createa full record of every item purchased by the customer at that merchant.The bank is also able to share the customer’s information with the merchant,and thus strip the customer of her anonymity. In such a situation, the merchantwill know who the customer is, and the bank will know every item that thecustomer purchases from the colluding merchant.A Colluding Concierge and Bank: This is a more extreme case of theprevious adversary. Whereas a colluding merchant and bank are only able toviolate the customer’s privacy for that specific merchant, a colluding conciergeand bank are able to do so for all transactions. Thus, the bank is able to createa complete list of every item purchased through the concierge by the customer.If the customer has attempted to hide her identity from the concierge bytransmitting the transaction tokens electronically, this collusion will strip thecustomer of her privacy. The bank can reveal the customer’s identity to theconcierge, while the concierge can reveal the complete list of purchased items tothe bank.A Law Enforcement Investigation: In situations where government agentsor law enforcement officers are able to compel multiple actors to disclose transactioninformation, the customer’s anonymity and transaction privacy are lost.For purposes of privacy analysis, a search warrant executed on the bank anda merchant is the same as the collusion scenario outlined above in section 4.2.Our system is not designed to protect the customer’s purchase privacy against

Merx: Secure and Privacy Preserving Delegated Payments 231government investigations. Customers wishing that level of protection may wantto stick with cash.As we can see, Merx provides high levels of security and privacy against individualactors. The collusion between non-trusted parties leads to minor “controllable”effects. The only severe damages result from collusions involving thebank. However, such collusions are the least likely to occur in everyday life.4.3 Communication and Processing OverheadIn this section we evaluate the additional costs, processing, and communicationoverhead our system requires from all parties. The main observation is that thedelegation mechanism we propose, in its most basic form, requires no additionalhardware. It is a simple software solution using off-the-shelf components thatpiggyback on the existing payment-network infrastructure.For the numerical evaluation, we assume the customer uses a low-capacitymobile device (200MHz processor, 64MB RAM), whereas the merchant and thebank use an average speed server or desktop PC (Intel P4 2.8Ghz, 500MB RAM).We chose the SHA256 algorithm for all hashes, which we compute using thefree OpenSSL library. GnuPG, an open-source implementation of Pretty GoodPrivacy was used for all encryption. We selected GnuPG’s default algorithmsof El Gamal with 2048 bit keys (public key encryption) and AES (symmetricencryption) as these provide sufficient security while being quick to computeon a mobile platform. While we have chosen these particular algorithms, thescheme is flexible, and alternative encryption/hashing technologies could easilybe substituted.The processing time results shown in Fig. 3 are averaged over 10 runs for eachnumber of items. The confidence intervals are very small, therefore omitted fromthe figure.The Customer: To use such a system, the customer must have access to eithera mobile telephone or a computer. These devices do not necessarily need to beowned by the customer. In many cases, she merely needs to have temporaryaccess to them. If the customer owns the device, the she can store her accountnumber in it. If she is borrowing the device from someone else, she will need tofind a way to input her account number. This can be done manually (e.g. byentering a 16+ digit number), or perhaps by reading a QR code printed ontothe back of her bank card with a camera phone.Figure 3 shows the processing time required to create a token, for a givennumber of items in the shopping list. We can observe that in spite of the lowprocessingpower of the customer’s device, the processing delay is still acceptableeven for an exaggerated number of items. For low number of items, the processingdelay remain below 10 s.The total size of an encrypted transaction token for 10 items is approximately1.6 KBytes, with an additional 1 KByte required for the shopping list. For atransaction involving 50 items, the token grows to nearly 3 KBytes while the

232 C. Soghoian and I. AadProcessing time (s)504540353025201510564200 10 20 3000 100 200 300 400 500Number of itemsBankCustomerMerchantFig. 3. Processing time for the customer, merchant and bank, with respect to thenumber of purchased itemsshopping list grows to 4.5 KBytes, as the shopping lists are currently transmittedin plain text and are not compressed.Depending on the level of personal interaction that the customer wishes tohave with the concierge, the method of transmission and technical requirementswill differ. A transaction token can be electronically transmitted using email,instant message, Bluetooth, IR, or MMS. The token, and its HMAC, can alsobe printed on to paper by representing them as a QR codes which can then behand-delivered or faxed to the concierge.With Bluetooth 2.0 transmission rates of 2.1 Mbit/s, it is clear that a usershould be able transmit the token, its HMAC, and the shopping list to theconcierge in under a second (plus the time required to setup and teardown theBluetooth connection). If the user is not near to the concierge, the user can useMMS on her phone to transmit the token and shopping list. 3G cellular networkstypically offer speeds of 144Kbit/s in a high-velocity moving environment, 384Kbit/s in a low-velocity moving environment, and 2 Mbit/s in a stationary environment.Again, it takes less than a second for the token, its HMAC, and theshopping list to be transmitted.The Concierge: If the token has been electronically transmitted to theconcierge, she will either need to bring it to the merchant in electronic form,using a mobile phone or any other mobile computing device, or print it out ontopaper. The technical requirements for the concierge’s device will depend on thereceiving equipment that the merchant has. There are no processing tasks tobe performed by the concierge, as she merely relays the token and shopping listgiven to her by the customer. It is therefore possible for the concierge to simplyreceive paper printouts of the token and shopping list, which she can thenhand-deliver to the merchant when she purchases items.The Merchant: The merchant must have a means of reading in the transactiontokens. At the most basic and inter-operable level, the merchant will need

Merx: Secure and Privacy Preserving Delegated Payments 233to have the ability to read QR codes. To accept electronic tokens, the merchantwill also need to support either MMS, Bluetooth or IR. All of these tasks can beaccomplished with a camera-enabled smart phone. Complex integration with themerchant’s existing computerized point-of-sale system will of course require additionalhardware. The merchant will also need a way to transmit the encryptedtransaction tokens, the HMACs, and hashes of the purchased items to the bankin order to validate the transaction. However, most merchants already have anelectronic transmission system that enables them to process ATM and creditcard transactions. The transaction token system can easily piggyback on theexisting financial transaction transfer infrastructure, although the engineeringtask of this integration is beyond the scope of our work [24]. On the other hand,point-of-sales that already support mobile-phone payments, e.g. [25] widely deployedin Japan, would require simple software updates.Smaller merchants may use a basic credit card machine with a 56Kbps modem,while the larger firms may use a sophisticated point of sale system connected toan ISDN line or even use a VPN over a broadband Internet connection. Even forthese smaller merchants, the transmission time required to send a 1.6 KBytestransaction token for 10 items and a 1 KByte transaction request (listing theprice of each item, as well as the hash of each item and associated randomnumber) remains under 1 s. For the larger merchants with an even faster connectionto a payment processor, the transmission time for the transaction tokenis negligible.For a merchant to be able to process a Merx transaction, it must calculatea SHA256 hash for each item i ,r i pair before sending the list of hashes and thetransaction token to the bank. Thus, in addition to transmission time analyzedabove previously, we must also consider the time required to compute the itemhashes. On the merchant’s machine, a SHA256 hash takes approximately 10 ms.Therefore, even with 100 item hashes to calculate, the merchant will only introducea 1 second delay to the retail checkout process.Figure 3 shows that the time required for the merchant’s server to process atoken is approximately 4 s for 500 items. For a lower and more common numberof items, the processing time is below 1 s.The Bank: The bank already communicates with merchants during transactionsover the existing financial network, so that credit card numbers can beverified. Merx additionally requires that the bank decrypts the transaction token,verify the contents and then transmit a message back to the merchant. Inorder to stop double spending and allow transactions to be broken up into multiplesub-transactions serviced by different merchants, the bank must keep trackof and remember the contents of a transaction token for a significant time in thefuture.Let us assume that the bank stores 100 Bytes of information per item purchased(which includes the item hash, the price paid, the customer’s accountnumber, and a time stamp), as well as an additional 100 Bytes for every transactiontoken that has been used at least once. Thus, the storage overhead for a

234 C. Soghoian and I. Aadtransaction token with 100 purchased items is approximately 11 KByte. Assumingstorage costs of $250 per GByte for a Fiber Channel RAID system ($7 permonth for three years), the storage costs for a transaction token and 100 itemsis approximately 1/4 of a penny.Figure 3 shows that the processing time for the bank increases very slowly withthe number of items in the shopping list, however it remains less than 500 mseven for a transaction token with 500 items. Comparing the cumulative delays(≈ 4s for transmission + processing) of the concierge, bank, and merchant, to thetypical values of queuing delays at cash desks in [26], shows that the additionaloverhead introduced by Merx remains negligible.Insider theft is a major threat to the financial service industry [27]. Whilecustomers can buy shredders, monitor their credit reports and take otherpro-active steps to protect themselves against identity theft, there is little thatthey can do to stop a corrupt merchants (or their employees) from saving a copyof the customer’s credit card information. Due to pro-consumer legislation, thebanks are often responsible for this fraud. As a result, the banks often bear thefinancial consequences of merchant insider theft. In our scheme, the credit cardor account details are stored in an encrypted token. As the merchant has no wayof reading this information, there is no way for a corrupt employee to write downthe user’s account number for later use. By switching to Merx, banks should beable to significantly reduce their exposure to merchant insider theft.5 Example ApplicationsMerx, as described in the previous sections, has various use cases such as:– Delegated concierge service– Corporate environments, where the employer delegates payments to her employeesduring business trips. Merx gives the company more control overthe payments, while offering more flexibility to the employee. Moreover, theemployer has the option of keeping her identity hidden to the merchant.– Family situations where parents typically give money to their children (e.g.going on vacation), taking the risk of having it stolen, or simply used by thechildren for unwanted purchasesIn addition to the above scenarios, Merx can be slightly modified to support otherappealing applications such as ATM withdrawal delegation, or self-delegatedtravelers cheques.5.1 ATM Withdrawal DelegationPIN and password sharing is common amongst married couples and even sometrusted friends [2]. Unfortunately, banking policies do not reflect the reality ofthe real world trust relationships. Often, financial rules stipulate that the bankswill only be held responsible for fraud in cases where the customer has not shared

Merx: Secure and Privacy Preserving Delegated Payments 235their login information with anyone else. Thus, when users share their accountauthentication information with spouses or trusted friends, they lose any form oflegal liability protection in cases of fraud, even when the fraud is later committedby complete strangers [2].People in remote areas of the world often live and work very far from thenearest bank or ATM. Out of necessity, people must rely on their friends, familymembers or even neighbors for access to banking facilities. Typically, one personwill travel to the nearest large town and take care of everyone else’s businessfor them. This person will carry a large number of ATM cards, each with anaccompanying PIN written down on a piece of paper [2].This system requires a huge amount of trust, in that the trusted person couldchoose to draw down everyone else’s accounts, and then leave the country. Usersare not able to convey their intent (e.g. “Please allow Tom to withdraw 40dollars from my account”), and instead must give complete control over theirbank account to that trusted person.While mobile-phone based e-banking would also provide a solution to thisproblem (in that customers could transfer money online to the account of theconcierge, who would then withdraw it), this would require that each customerhave access to online banking facilities. This is often not a practical requirementin remote parts of the world, and so our scheme is designed to work withoutaccess to the Internet. Users can be offline when they create transaction tokens.We propose two adaptations of Merx to this problem. Both schemes requirethat the user wishing to delegate withdrawal have access to a mobile phone orcomputer. The first requires that the user have access to a printer or a Bluetoothenabled mobile phone and that the bank deploy a Bluetooth compatible ATMmachine. The second solution does not require Bluetooth mobile support, canbe used with a pen and paper and only requires that the bank deploy a softwareupgrade to enable the ATM machine to support long PINs.The first solution works as follows:Alice, who is staying at home, has asked her friend Bob to go to the ATM inthe nearest large town, which is 8 hours away by bus. Using her mobile phone,Alice thus creates a transaction token, and its HMAC:TransactionToken =(Acct#,PIN,TimeStamp,Amount,ConciergeID,T ransactionP IN, MacKey, n) BankPubKWhere n is a random nonce added to protect against dictionary attacks targetingthe user’s PIN. This token is then either transmitted to Bob’s mobile phonevia a Bluetooth connection or Alice prints the token in a computer-readableform, such as using QR codes.If Bob tries to modify the transaction token in any way, it will be rejectedby the bank. As he does not have Alice’s PIN, he cannot create a valid token.Thus, the security of this scheme depends on Alice maintaining the privacyof her PIN, which is an existing requirement for the security of her bank account.

236 C. Soghoian and I. AadFurthermore, if Bob tries to reuse the same token twice, the bank will rejectit. This of course requires that the bank must maintain a list of all redeemedtokens.The second solution works as follows:If Bob does not have a mobile phone, or the bank’s ATM machine does notsupport Bluetooth, it is not possible to use the previously described scheme.We must then fall-back to a more limited protocol, which uses the existinginfrastructure.This scheme still requires that Alice have access a mobile phone or a computingdevice, but it does not need to support Bluetooth. Alice must, at someprevious time, have established a long shared key (LongP IN) with the bank.This key must be suitably large, such that it is resistant to a dictionary attack.If Alice is willing to type in her authentication details each time, it is possiblefor her to use someone else’s phone to generate the token. This puts her at riskof PIN theft through keyboard sniffing and other attacks, and so it would be farsafer for her to use her own device. However, in cases where users are willing torisk these additional threats, it is possible for a large group of people to share asingle mobile phone to generate their delegated ATM withdrawal tokens.Using her mobile phone, Alice then creates the transaction token:TransactionToken= h(Acct#||LongP IN||Timestamp||Amount||BobID,TransactionPIN)Alice can then write this hash down on a piece of paper, along with her accountnumber, the timestamp, the transaction PIN and the amount to be withdrawn.We use SHA256 as our hash, which can be written as a 64 character string. Thisis short enough that it is reasonable to expect someone to type it into an ATMby hand.5.2 Self-delegated Travelers ChequesThe delegated concierge scheme described before can be modified slightly toprovide traveler cheque functionality. A user can either assign the ConciergeIDto be her own ID, or to protect against cases where she loses her wallet and allother forms of identification, a password or one time PIN can be substituted forthe ConciergeID field.The transaction token can also specify loose requirements for the kinds ofitems or services that can be purchased. Examples of this can include a travelerscheque limited to one train ticket priced less than 100 dollars, a night in a 4 staror below hotel or a meal in a restaurant that cost less than 30 dollars. 6Such travelers cheques could be photocopied, allowing an individual to keepmultiple copies on her person, should she be robbed or lose her wallet. A copycould be kept online by emailing it to herself. Likewise, business travelers could6 Again, the flexibility of such a system typically depends on the specification languageused,asdiscussedinSection3.3.

Merx: Secure and Privacy Preserving Delegated Payments 237leave a copy with their secretaries back at the office, who could then fax themthe transaction token upon demand.Advantages Over Existing Travelers Cheques and money wiringTravelers cheques are a stored payment medium, and not in any way a form ofcredit. In contrast with Merx, travelers Cheques have the following drawbacks:– They cannot be photocopied, transmitted by fax or email.– They must be paid up-front, therefore making the customer lost the interests.– Travelers cheques are often used by customers in emergencies. However, dueto the requirement that the customer purchase travelers cheques before theyare used, it may be reasonable for someone to go into unforeseen debt, dueto the circumstances of the situation.– If lost, the issuing authority must be contacted to get them canceled andhave new ones issued, therefore introducing undesirable delays.As for the advantages over wiring money– Banks typically charge a fairly significant commission or fee for a wire transfer.– The two banks, at the sender’s and recipient’s locations, must be open forthe money wiring to occur.– Wiring money also requires the co-operation of someone on the other end ofthe transaction, which in emergency situations in foreign countries, can berather difficult.6 ConclusionIn this paper we present a secure and privacy preserving payment delegation system,Merx, for end-users with mobile devices not necessarily connected to theInternet. It allows users to delegate a third party that will purchase a specificlist of items from a merchant, keeping the user’s ID secret from the merchant,and the list of items secret from the bank, while securing the transactions fromany fraudulent acts. The same mechanisms can be used to delegate money withdrawalfrom ATMs, for controlling children’s expenses, or employees’ expensesduring business trips. When the user delegates himself for the transaction, themechanism works as a secure travelers cheques solution. The user is required touse a computing device, which can be a shared one. The transactions can beperformed using SMS, Bluetooth/IR, camera phones, or even using a pen and apaper. Finally, we evaluate the performance of our system at thwarting differentlevels of attack models, and its capacity and communication overhead. Merxcan be gradually deployed since it can be used over existing payment networkinfrastructures.

238 C. Soghoian and I. AadReferences1. The Near Field Communication (NFC) Forum (2007), http://www.nfc-forum.org2. Singh, S., Cabraal, A., Demosthenous, C., Astbrink, G., Furlong, M.: Passwordsharing: implications for security design based on social practice. In: CHI 2007:Proceedings of the SIGCHI conference on Human factors in computing systems(2007)3. Peirce, M.: Payment mechanisms designed for the Internet (2001),http://ntrg.cs.tcd.ie/mepeirce/Project/oninternet.html4. Bellare, M., Garay, J., Hauser, R., Herzberg, A., Krawczyk, H., Steine, M., Tsudik,G., Waidner, M.: iKP – A family of secure electronic payment protocols. In: FirstUSENIX Workshop on Electronic Commerce (1995)5. Anderson, R.J., Manifavas, C., Sutherland, C.: Netcard - a practical electroniccashsystem. In: Proceedings of the International Workshop on Security Protocols(1997)6. Gabber, E., Silberschatz, A.: Agora: a minimal distributed protocol for electroniccommerce. In: WOEC 1996: Proceedings of the 2nd conference on Proceedings ofthe Second USENIX Workshop on Electronic Commerce (1996)7. Sirbu, M., Tygar, J.D.: Netbill: An internet commerce system optimized for networkdelivered services. In: COMPCON 1995: Proceedings of the 40th IEEE ComputerSociety International Conference (1995)8. Rivest, R.L., Shamir, A.: Payword and micromint: Two simple micropaymentschemes. In: Security Protocols Workshop (1996)9. Glassman, S., Manasse, M., Abadi, M., Gauthier, P., Sobalvarro, P.: The millicentprotocol for inexpensive electronic commerce. In: Proc. of the Fourth InternationWorld Wide Web Conference (WWW) (1995)10. Herzberg, A., Yochai, H.: Mini-Pay: Charging per Click on the Web. In: Proc. ofthe Sixth World Wide Web Conference (WWW) (1997)11. Paulson, L.C.: Verifying the SET Protocol: Overview. In: FASec. (2002)12. Patil, V., Shyamasundar, R.K.: e-coupons: An efficient, secure and delegable micropaymentsystem. Information Systems Frontiers Journal (2005)13. Patil, V., Shyamasundar, R.: An efficient, secure and delegable micro-paymentsystem. In: Proc. of IEEE International Conference on e-Technoloty, e-Commerceand e-Service (EEE) (2004)14. Patil, V., Shyamasundar, R.: Towards a flexible access control mechanism for e-transactions. In: International Workshop on Electronic Government, and Commerce:Design, Modeling, Analysis and Security (EGCDMAS) (2004)15. Patil, V., Shyamasundar, R.: ROADS: Role-based Authorization and DelegationSystem - Authentication, Authorization and Applications. In: Proc. of Int. Conf.on Computational & Experimental Engineering and Sciences (2003)16. Ivatury, G., Pickens, M.: Mobile phone banking and low-income customers evidencefrom south africa. In: Consultative Group to Assist the Poor/The World Bank andUnited Nations Foundation (2006)17. Bellare, M., Namprempre, C.: Authenticated encryption: Relations among notionsand analysis of the generic composition paradigm. In: Okamoto, T. (ed.) ASI-ACRYPT 2000. LNCS, vol. 1976, pp. 531–545. Springer, Heidelberg (2000)18. Okamoto, T. (ed.): ASIACRYPT 2000. LNCS, vol. 1976. Springer, Heidelberg(2000)19. Blaze, M., Ioannidis, J., Keromytis, A.D.: Offline micropayments without trustedhardware. In: Syverson, P.F. (ed.) FC 2001. LNCS, vol. 2339, p. 21. Springer,Heidelberg (2002)

Merx: Secure and Privacy Preserving Delegated Payments 23920. Jablon, D.P.: Strong password-only authenticated key exchange. SIGCOMM Comput.Commun. Rev. 26(5) (1996)21. Bellovin, S.M., Merritt, M.: Encrypted key exchange: Password-based protocolssecure against dictionary attacks. In: SP 1992: Proceedings of the 1992 IEEE Symposiumon Security and Privacy (1992)22. Pfitzmann, A., Hansen, M.: Anonymity, unlinkability, undetectability, unobservability,pseudonymity, and identity management - a consolidated proposal for terminology(2007)23. Anderson, R.J.: Liability and computer security: Nine principles. In: Gollmann, D.(ed.) ESORICS 1994. LNCS, vol. 875. Springer, Heidelberg (1994)24. International Organization for Standardization: ISO 8583: Financial transactioncard originated messages – Interchange message specifications (2003)25. http://www.nttdocomo.co.jp/english/service/osaifu/index.html26. Noldus Information Technology: LineControl reduces waiting time in supermarkets:Labor analysts use The Observer to get a grip on work processes (2004),http://www.noldus.com/site/doc20040110027. Sullivan, B.: Study: ID theft usually an inside job. MSNBC (2004),http://www.msnbc.msn.com/id/5015565

A Property-Dependent Agent Transfer ProtocolEimear Gallery 1,⋆ , Aarthi Nagarajan 2 , and Vijay Varadharajan 31 Royal Holloway, University of London, Egham, Surrey, TW20 0EX, United Kingdome.m.gallery@rhul.ac.uk2 Macquarie University, NSW 2109, Australiaaarthi@ics.mq.edu.au3 Macquarie University, NSW 2109, Australiavijay@ics.mq.edu.auAbstract. This paper examines how a secure agent transfer protocolbased upon TCG-defined mechanisms can be improved usingproperty-based platform state information. In doing so, we demonstratea practical implementation of property-based platform attestation usingan enhanced version of the component property certificates defined in[16]. To illustrate our solution we provide examples of properties andcomponent property certificates given a mobile aglet that is destined toexecute on a group of devices, where the mobile aglet originator wishesto protect the confidentiality of the aglet code.1 IntroductionA mobile agent, which is comprised of code, data and execution state, is definedas “an autonomous, reactive, goal-oriented, adaptive, persistent, socially awaresoftware entity, which can actively migrate from host to host” [27]. Mobile agentshave long been heralded as an important software paradigm in tackling problemssuch as bandwidth shortages, unreliable network connections, pre-definedand rigid system architectures, and network latency [13,18], which persist in themobile environment due to the physical characteristics/constraints of the connections[26]. If, however, these persistent, autonomous programs are permittedto roam freely in a mobile network, interacting with systems and other agentsto fulfil their predefined goals, the risk of a mobile host with malicious intentdamaging a mobile agent or a malicious agent damaging a mobile host becomesa very real danger. While the topic of host protection has been widely discussed,see for example [4,9,12,17,19,29,30,39,40], a relative dearth of information existson mobile agent protection. Recent research [3] suggests that the deployment oftrusted computing technology in a mobile agent setting can solve many securityissues intrinsic to mobile agent protection. However, the use of binary platformstate information has proved to be problematic. In this paper we examine howa secure agent transfer protocol which leverages trusted computing functionalitycan be enhanced using property-based platform state information in order⋆ Research was sponsored by the Open Trusted Computing project of the EuropeanCommissions Framework 6 Programme.L. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 240–263, 2009.c○ Springer-Verlag Berlin Heidelberg 2009

A Property-Dependent Agent Transfer Protocol 241to provide mobile agent protection. In doing so, we extend and demonstrate apractical use of component property certificates, as defined in [16].Sections 2, 3 and 4 review the necessary background material. In section 2trusted computing concepts are explored. Section 3 highlights prior art relatingto trusted computing and agent protection. In section 4 the concept of propertybasedattestation is introduced. The remainder of the paper describes a propertydependentagent transfer protocol. Section 5 identifies the security requirementsthat the protocol should satisfy and section 6 defines a key migration-basedagent transfer protocol currently supported by the Trusted Computing Group(TCG) specification set. Following a discussion of why a TCG mechanism basedprotocol is not sufficient in this particular scenario, the assumptions upon whichour protocol is based are outlined in section 7. Section 8 develops the conceptof property-based state information and property certificates (with examplespertaining to the aglet environment). In section 9 a secure agent transfer protocolwhich leverages property-based platform state information is defined andanalysed. We conclude in section 10.2 Trusted Computing FundamentalsA Trusted Platform (TP) is one that will behave in a particular manner fora specific purpose. The TCG’s Trusted Platform Module (TPM) specifications[34,35,36] are central to the implementation of a trusted computing platform.These specifications describe a microcontroller with cryptographic coprocessorcapabilities that provides a platform with a number of special purpose registersfor recording platform state information; a means of reporting this state toremote entities; secure volatile and non-volatile memory; random number generation;a SHA-1 hashing engine; and asymmetric key generation, encryption anddigital signature capabilities. The current documentation from the TCG alsoencompasses a vast set of specifications ranging from those relating to trustedpersonal computers [32], server systems [31], and to specifications for trustednetworking [33]. The TCG Mobile Phone Working Group (MPWG) has recentlypublished the TCG Mobile Trusted Module (MTM) specification [37,38] (namely,a TPM designed for a handheld mobile device) which enables the developmentof a Trusted Mobile Platform (TMP).Trusted computing, as currently defined by the TCG, is built upon five fundamentalconcepts: integrity measurement, authenticated boot, secure boot, platformattestation, andprotected storage.– An integrity measurement is defined in [23] as the cryptographic digest orhash of a platform component (i.e., a piece of software executing on theplatform).– During an authenticated boot, a pre-defined set of platform components isreliably measured and the resulting integrity measurements condensed andreliably stored to form a set of platform integrity metrics.– During a secure boot, a pre-defined set of platform components is reliablymeasured, the resulting measurements verified against their expected values,

242 E. Gallery, A. Nagarajan, and V. Varadharajanand stored as above. A secure boot mechanism is required in a TMP, but isnot mandated in other implementations.– Platform attestation enables a T(M)P to reliably report information aboutits current state (namely, the integrity metrics reflecting (all or part of) theplatform’s software environment).– Using its protected storage functionality a TPM/MTM can generate an unlimitednumber of asymmetric key pairs. For each of these pairs, private keyuse and mobility can be constrained. The notions of binding, the process ofencrypting data so that only a particular TPM/MTM can decrypt it, andsealing, the process of encrypting data so that only a particular TPM/MTMcan decrypt it when the TPM/MTM’s host platform is in a particular state,are also of fundamental importance to trusted computing.For a platform to be considered trusted, it must first obtain the following corecredentials from an endorsement Certification Authority (CA), a platform CA,and one or more conformance CAs, respectively.An endorsement credential: Each TPM is, and each MTM may be, associatedwith a unique asymmetric encryption key pair called an EndorsementKey (EK) pair. An endorsement credential binds the public component ofthis key pair to a TPM/MTM description and vouches that a TPM/MTMis genuine. The endorsement CA is typically the TPM/MTM manufacturer,with the binding taking the form of a digital signature created using a signingkey of the manufacturer.A platform credential: A platform credential asserts that a TPM/MTM hasbeen correctly incorporated into a design conforming to the TCG specifications.The platform CA is typically the platform manufacturer. In order tocreate a platform credential, the platform CA must examine the endorsementcredential, the conformance credentials relevant to the trusted platform, andthe platform to be certified.Oneormoreconformancecredentials:Conformance credentials vouchthat a particular type of TPM/MTM and associated components (such as aRTM and the connection of the RTM and TPM to a motherboard) conformto the TCG specifications. Conformance CAs must be entities with sufficientcredibility to evaluate platforms containing TPMs/MTMs, and are typicallyconformance testing facilities.In order to address privacy concerns resulting from routine use of an EK, theTCG introduced the ability for a TPM/MTM to generate and use an arbitrarynumber of pseudonyms, in the form of Attestation Identity Key (AIK) pairs. Inorder for a relying party to have assurance that an AIK represents a trustedplatform, a platform must obtain an AIK certificate from a mutually trustedthird party. Two approaches to AIK certification have been proposed by theTCG. In the first approach, a trusted third party, referred to as a Privacy-Certification Authority (P-CA), verifies a trusted platform’s core credential setand provides assurance that an AIK is bound to a genuine trusted platform inthe form of an AIK credential. However, this approach has attracted a certain

A Property-Dependent Agent Transfer Protocol 243amount of criticism, as a P-CA is capable of linking all the AIK credentials itissues to a specific platform via the EK, putting the P-CA in a position where it isable to defeat the anonymity protection provided by the use of AIKs. The secondapproach, Direct Anonymous Attestation (DAA), was introduced to counteractthis criticism. DAA requires a DAA CA, which can produce an anonymous DAAcredential for a trusted platform, which in turn can be used by the platform tosign AIK credentials. Using this approach, trusted platforms can generate anduse AIKs which cannot be easily linked to a particular EK by any third party.As privacy is not always of concern in a trusted mobile platform an MTM maybe only be provisioned with a single certified AIK pair which attests that it isindeed genuine and is integrated into a trusted mobile platform.The specification set produced by the TCG, however, is by no means the onlywork on trusted computing. Trusted computing also encompasses new processordesigns [1,7,11] as well as Operating System (OS) support [22,23] which facilitatesoftware isolation, i.e. the unhindered execution of software. For the interestedreader, introductory texts on trusted computing include [2,15].3 Trusted Computing and Mobile Agent SecurityThe use of trusted hardware as a method of protecting mobile agents can betraced back to Wilhelm, Staamann and Butty [41] who define a Trusted ProcessingEnvironment (TPE) to consist of a Computer Processing Unit (CPU),random access memory, read only memory, and non-volatile storage, all of whichexecutes in a virtual machine. An agent executes within this isolated TPE, whereit remains protected from observation by the host OS.The use of trusted computing in agent systems has been proposed in[6,20,21,25]. [6,20,21] describe how non-mobile agents can be used in the preservationof user privacy. Recently, a trusted computing enhanced mobile agentplatform called SMASH was proposed, [25]. In this system trusted computing isdeployed to form a middleware-based instantiation of some aspects of Wilhelm,Staamann and Butty’s proposal [41].Most recently, in [3] Balfe and Gallery examined how trusted computing functionalitycould be used to protect sensitive agent information (be it code, data orstate information) by demonstrating how an agent originator can extend theircontrol over environments in which their agent will subsequently execute. Ineach approach described in [3], access to an agent is made provisional on thehost platform’s PCRs containing a particular set of binary integrity metrics,which is proved to be problematic. For example, an agent platform may leaveitself open to attack from an incoming agent if its exact configuration (includingall system vulnerabilities) is revealed. Privacy issues are also associated withsuch revelations. In conjunction with this, since a software component’s binarychanges every time a patch or update is applied, and as a mobile agent maypotentially make numerous hops, it becomes next to impossible for an agentoriginator to choose a unique set of platform integrity metrics which reflect aplatform state that meets his/her requirements and which all destination hosts

244 E. Gallery, A. Nagarajan, and V. Varadharajansatisfy, given updates, patches and the multiplicity of agent platform configurations/installations.4 Property-Based AttestationAs an alternative to traditional binary integrity metric-based mechanisms, asdescribed in section 2, the concept of property-based attestation and sealing hasbeen introduced [10,24,28,42]. Using this approach, a platform’s state is definedin terms of its security-related properties rather than a set of integrity metrics.In this way a platform’s exact implementation details can be hidden, as can itsvulnerabilities. In conjunction with this, properties of components do not changeas often as software component binary integrity measurement values, therebyalleviating problems relating to patches and updates. Properties are also easierto understand, which can be helpful when writing meaningful policies. Threefundamental approaches to property-based attestation and sealing have beenexplored: delegation-based, the use of code control, and code analysis/propertyderivation [5].Papers such as [24,28,42] describe a delegation-based approach, where a challengerplatform or attestor is required to prove that a trusted third party hascertified properties of its software state. The proof takes the form of propertycertificates, i.e. signed statements which describe the security properties of softwarecomponents. Nagarajan, Varadharajan and Hitchens [16] refine this notion,and discuss certificates which describe course-grained platform properties, finegrainedproperties of individual components, and mid-level properties of groupsof components.The property derivation approach of Halder, Chandra and Franz in [10] uses alanguage-based Trusted Virtual Machine (TVM) in order to facilitate propertybasedattestation. A TVM (such as the Java Virtual Machine) derives variousproperties of applications running within it on behalf of a remote party. Forexample, code analysis may be completed on the code by the TVM. In thisscheme, software up to and including the TVM may be verified using binaryattestation.The TVM described above also employs code control/policy enforcement,whereby the code is under the control of the TVM, which monitors its execution.This approach is also adopted in [14], where SELinux and its associatedpolicies are attested to, and the policies are enforced by the operating system.5 Security RequirementsIn order to provide comprehensive mobile agent protection, and so that a widerange of agent applications can be supported, the following requirements mustbe fulfilled by the property-dependent agent transfer protocol.1. Destination host platform trust verification, so that the status of an agenthost platform as a genuine TP and its security-properties can be verified.

A Property-Dependent Agent Transfer Protocol 2452. Confidentiality of the agent code, data and state information in transit betweenand in storage on host platforms, so that unauthorised reading can beprevented.3. Integrity protection of the agent code, data and state information in transitbetween and in storage on host platforms, so that any unauthorised alterationcan be prevented, be it malicious or accidental.4. Confidentiality and integrity protection of the agent code, data and stateinformation during execution.5. Availability of the required resources and services to an agent duringexecution.6 A TCG Mechanism-Based Agent Transfer ProtocolThe mobile agent architecture model upon which our protocol is based involvesthree parties: an agent originator platform (A O ); an agent host platform (A H );and a trusted third party property certifier (TTP). A O is the trusted (mobile)agent platform from which an agent (A) originates, whereas A H representsthe trusted (mobile) agent platform upon which incoming agents execute. Eachtrusted (mobile) agent platform is supported by a TCG compliant TPM or MTM(in the protocol description a TPM or MTM will be denoted by TM). In thismodel an agent originator does not need to have a long term relationship withthe host platforms upon which its agent executes.As shown in [3,8] there are a number of ways by which standard TCG functionalitymay be used to meet security requirements 1 — 5, as listed in section 5.All methods, however, utilise facets of the TCG protected storage functionality,Fig. 1. TCG migration — Key exchange phase

246 E. Gallery, A. Nagarajan, and V. Varadharajanas described in section 2. For this particular scenario involving multi-hop mobileagents, an approach founded upon TCG key migration is most appropriate.This approach essentially involves a key distribution phase and an agent transferphase.Figure 1 illustrates the key distribution phase of an approach based on TCGkey migration. In this case each agent host possesses an AIK pair (which identifiesit as a genuine TP). Each agent host platform’s TM has also been used togenerate a non-migratable key pair and to certify (sign) the public key from thispair using a private AIK. The agent originator generates a migratable key pairusing his/her TM where private key use is bound to a specified host platformstate. The public key from this key pair is used to protect the outgoing mobileagent. This key pair needs to be ‘migrated’ to all trusted (mobile) agent platformswhich require agent access.Prior to key pair migration a trusted (mobile) agent platform must forward itsAIK-certified non-migratable public key to the agent originator for verification.Once this has been completed, and the agent originator has been convinced thathe/she is communicating with a genuine TP, the agent originator key pair canbe migrated under the protection of the public non-migratable trusted (mobile)agent platform TM public key. The key distribution phase described above maybe completed while the agent is in transit or prior to its distribution. Once thekey distribution phase has been completed, the mobile agent can be protectedwith the agent originator’s public migratable key and distributed as shown infigure 2.Problems, however, surround the use of TCG-defined platform state information(namely the PCR values) to restrict trusted (mobile) agent platformaccess to incoming executables. A mobile agent is designed to hop from host toFig. 2. TCG migration — Agent transfer phase

A Property-Dependent Agent Transfer Protocol 247host. Given the huge number of possible platform configurations, and given theabundance of updates and patches, it is difficult if not impossible for an agentoriginator to choose one platform state to which the agent originator migratableprivate key (and therefore agent access) is bound. In order to overcome theseproblems we propose a property-based secure agent transfer protocol.7 System AssumptionsWe now examine how the secure agent transfer protocol based upon the TCGdefinedmechanism described in the previous section can be improved usingproperty-based platform state information. In doing so, we demonstrate a practicaluse case for property-based platform attestation using an enhanced versionof the component property certificates defined in [16]. To illustrate our use casewe provide examples of properties and component property certificates given amobile aglet that is destined to execute on a group of devices, where the mobileaglet originator wishes to protect the confidentiality of the aglet code. The followingpre-conditions need to be satisfied for use of the protocol described laterin this paper.1. It is assumed, for the purposes of illustration, that the agent originator andhost platforms support an aglet system architecture. An aglet is a mobileJava agent that supports the concepts of autonomous execution and dynamicrouting on its itinerary [13]. An aglet system architecture is comprised of anaglet runtime layer and a communication layer. The main elements in anaglet runtime layer’s core framework include a context, i.e. the runtime environmentin which an aglet executes, and a security manager. Asecuritymanager protects both the host and aglets from malicious entities. The securitymanager uses aglet permissions, message permissions, and a policydatabase, in which security policies for aglet contexts are stored. Privilegesmay be defined through the association of one of the following resource typeswith a set of permissions: local file system; network sockets; local windows;Java properties; system resources such as memory and CPUs; security information;contexts; aglets; and messages.Aglets leverage this runtime environment. An aglet originator may also definea set of aglet preferences for each aglet generated. The following methodscan be restricted by the originator of an aglet: clone; deactivate; dispatch;retract; dispose; get AgentClassName/AgletContext/CodeBase/Identifier/Itinerary/Message Manager/Property/Property Keys/Text; send Message;set Itinerary/Property/Text; subscribe/unsubscribe (all) messages [13]. Eachaglet is represented by a proxy, which acts as a shield object that protectsthe aglet from malicious entities. The aglet proxy provides a common wayof accessing the aglet behind it. When invoked, the proxy object consults asecurity manager, which in turn uses context and aglet policies to determinewhether the caller is permitted to perform the method.2. It is assumed that both the aglet originator platform and the aglet hostplatform are Trusted Aglet Platforms (TAPs) or indeed Trusted Mobile Aglet

248 E. Gallery, A. Nagarajan, and V. VaradharajanPlatforms (TMAPs). Therefore, a fundamental component in both the agletoriginator platform and the aglet host platform is a TPM or, in the caseof a TMAP, an MTM. One or more of these tamper evident modules, TM,is assumed to be bound either physically or cryptographically to each agletoriginator and aglet host platform.3. The aglet originator platform and the aglet host platform enable softwareisolation through the deployment of mechanisms described in section 2.4. Both the aglet originator platform and the aglet host platform also incorporatea trusted computing extension which is capable of determining theproperties of a particular system configuration given a set of property certificatesand a list of entities trusted to issue property certificates, and ofdeciding whether a particular system configuration provides a specific property.5. As a TMAP has more than one stakeholder, for example, the device manufacturer,network operator and potentially numerous service providers, allTMAPs contain a set of engines, namely constructs that can “manipulatedata, provide evidence that they can be trusted to report the current state ofthe engine, and provide evidence about the current state of the engine” [38].Upon start-up and reset of the TMAP device manufacturer engine, the softwarestate of the engine is measured, verified and stored to the appropriateMTM PCRs (i.e. securely booted).6. Upon the start-up and reset of the remaining TMAP engines, the softwarestate of each is measured and stored to the appropriate MTM PCRs.7. In the case of a TAP it is assumed upon platform start-up and reset that thesoftware state of the platform is measured and stored to the TPM PCRs.8. Each TAP or TMAP engine has at least one AIK pair.9. The public signature verification key from the pair referred to in point 8 iscertified by a P-CA trusted by both the agent originator and agent hosts.10. The initial platform from which the mobile aglet originates, A O ,isconsideredtrustworthy.11. The agent originator platform possesses a signature key pair.12. The public signature verification key from the pair referred to in point 11is certified by a certification authority trusted by both the agent originatorand agent hosts.13. Every aglet host platform can acquire a set of software component propertycertificates to which the platform conforms from a trusted third partyproperty certifier.8 Required PropertiesAs described in [16], properties of computing platforms can be expressed usingvarious levels of granularity. For the purpose of this paper we extend the conceptof more granular component property certificates proposed in [16] for use inthe delegation-based models described in [24,28]. Figure 3 illustrates a propertygranularity pyramid for use in defining properties of trusted platforms.

A Property-Dependent Agent Transfer Protocol 249Fig. 3. Property granularity pyramidAt the top of the pyramid, properties are defined at a high level. Here, propertiesexpress an overall purpose or function. Properties at the lowest level ofthe pyramid are fine-grained. More generally, as we descend from the top of thepyramid, properties are expressed with an increasing focus on the implementationdetails. The pyramid is comprised of the following four levels (numbered1–4).– On top of the hierarchy are classes. A class is defined as a common intentregarding the services that belong to the class.– A service addresses a class of security requirement.– Services are provided using one or more service elements.– A mechanism is used to implement a service element in a system.Level 1 and 2 properties do not reveal platform implementation details and providemore privacy for the attesting party. However, there is less flexibility forexpressing fine-grained access control policies based on these properties. On theother hand, properties at the lower levels of the pyramid provide greater flexibilityfor expressing policies although they may compromise the privacy of theattesting party. In the context of an agent environment, upper level propertiesallow an agent originator to specify host platform requirements without restrictingan agent host platform to a specific configuration. To illustrate our solutionwe provide examples of component properties in the context of a mobile aglet,destined to execute on a group of T(M)APs, whose code the aglet originatorwishes to confidentiality protect during execution [13].‘Aglet code confidentiality’ is a class of security service, as shown in figure 4,which may be broken down into three core services — ‘aglet code confidentialityduring transmission’, ‘aglet code confidentiality during storage’ and ‘aglet codeconfidentiality during execution’. Confidentiality of aglet code in transit andwhile in storage on a host platform are provided through asymmetric encryptiondeployed in the secure transfer protocol described in section 9. In order to ensureconfidentiality of aglet code during execution, a host on which the aglet executesmust possess certificates which indicate that it provides a particular serviceand/or incorporates service elements/mechanisms which provide this particular

250 E. Gallery, A. Nagarajan, and V. VaradharajanFig. 4. Property granularity pyramid for aglet code confidentialitygrantcodeBase "http://some.host.com", owned by "RHUL" {{// aglet protectionsprotection com.ibm.aglet.security.AgletProtection"*", "dispatch,dispose,deactivate,activate,retract";};Fig. 5. Aglet code confidentialityservice. The service ‘aglet code confidentiality during execution’ may be providedby a number of service elements, namely, software integrity, software isolation,a trustworthy aglet environment and the implementation of aglet code accesscontrol policies, as shown in figure 4. A trustworthy aglet environment and aset of aglet access control policies ensure that the aglet is protected from otheraglets executing in the context and indeed the host itself. Software isolationensures that the aglet environment is executedinanisolatedcompartmentsuchthat malicious software executing in parallel cannot gain unauthorised access.Finally, software integrity implies that the software isolation mechanism can beverified as correct. A selection of mechanisms that provide these service elementsinclude a secure boot mechanism, an up-to-date isolation layer, an up-to-dateand reputable aglet environment and aglet access control policies (such as thatshown in figure 5).The sample policy statement, defined in figure 5, permits the host to dispatch,dispose, deactivate, activate and retract an aglet owned by ‘RHUL’ and originatingfrom ‘http://some.host.com’ but does not at any stage permit aglet cloning.Properties describing a secure boot mechanism, an up-to-date isolation layeror an up-to-date and reputable aglet environment may include identification,version and update information for each of the components.

A Property-Dependent Agent Transfer Protocol 2519 A Property-dependent Agent Transfer ProtocolIn order to meet all requirements defined in section 5, and in order to provide anefficient solution given a multi-hop agent, we modify the protocol described insection 6 to incorporate the use of property-based platform state information. Inthis case, due to the modified T(M)P architecture assumed in section 7, we haveTPM/MTM functionality as defined by the TCG and a TPM/MTM extension.This TM extension must enable the generation of a key pair where private keyuse is contingent on a platform fulfilling a specific set of properties. It must alsosupport key use once a platform fulfills the set of properties to which private keyuse is bound. In order to do this the extension must be able to determine theproperties of a particular system configuration given a set of PCR values, a setof property certificates and a list of entities trusted to issue property certificates.9.1 Key GenerationIn order to implement key generation a variant of the TPM CreateWrapKeycommand functionality is required. Rather than specifying the state constraintsto which private key use is bound in terms of PCR values (as is the casewhen defining the PCRInfo parameter of the keyInfo parameter input to theTPM CreateWrapKey command) this new functionality inputs a new keyInfoparameter, for example propertyInfo, which allows state constraints to be specifiedas:– the property/properties to which a platform must comply prior to privatekey use;– the identity/identities of the third parties trusted to certify the propertiesspecified; and– the public key(s) of the root third party/parties trusted to certify the property/propertiesspecified.Private key use can be made dependent on a high level property, namely a level2 property such as ‘aglet code confidentiality during execution’. Alternatively,depending on the requirement of the agent originator, it may be dependent ona level 3 property such as ‘software isolation’ or indeed a level 4 property wherea particular isolation layer in a set version with the required updates must beprovided by a specified provider. An agent originator may even choose to ‘mixand match’ the properties required of an agent host platform.9.2 Property CertificatesEach property certificate contains a validity period, component identifers, a set ofproperties to which the component complies, and an identifier for and a digitalsignature of a property certifier. When defining level 4 properties a propertycertificate will contain the integrity measurement (i.e. the hash) of a componentin the ‘Component Identifiers’ field and the properties to which it complies in

252 E. Gallery, A. Nagarajan, and V. VaradharajanFig. 6. Level 2 property certificateFig. 7. Level 3 property certificatethe ‘Properties’ field. Given a level 2 or 3 property, however, the ‘ComponentIdentifiers’ field may contain the integrity measurement of a component or aset of properties which identify a (set of) component(s). The ‘Properties’ fieldwill list properties which the component(s) fulfill(s). Property certificates whichdefine the level 2 property of ‘aglet code confidentiality during execution’, thelevel 3 property of ‘software isolation’, the level 4 properties of isolation layer‘name’, ‘version’, ‘software provider’ and ‘update status’ may be defined as shownin figures 6, 7 and 8.

A Property-Dependent Agent Transfer Protocol 253Fig. 8. Level 4 property certificateOnce the agent originator key pair has been communicated to each T(M)AP,the T(M)AP can decrypt and examine the properties to which private key useis bound and the root third parties trusted to certify the properties specified.Following this, the T(M)AP must acquire the required property certificates.This could involve a T(M)AP providing the specified TTP(s) with the requiredproperties it must fulfill in return for all relevant property certificates.If, for example, the key is bound to the level 4 property set {Name =XEN on V T − x, V ersion =3.0, Software provider = Citrix, Updated >May 2009 || TTP2} the agent host could request all certificates where the nameis XEN on VT-x, the version is 3.0, the software provider is Citrix and the updateddate is after May 2009 from TTP2, or, alternatively, it could send themeasurement of its isolation layer in return for all certificates pertaining to thismeasurement. Once these certificates have been retrieved a chain can be constructedfrom an integrity measurement representing a platform component toa root trusted third party-certified property/set of properties to which privatekey use is bound.If, for example, the key is bound to the level 3 property set {Service elementname = software isolation || TTP1} the agent host could initially requestall certificates where the property field indicates that the service element nameis software isolation from TTP1. Once it has received these it must examinethe identifiers for components which fulfill the property ‘software isolation’,for example in the case of the Level 3 property certificate shown in figure7, the ‘Component Identifiers’ are {Name = XEN on V T − x, V ersion =3.0, Software provider = Citrix, Updated > May 2009 || TTP2}. Itmustthen in turn request of TTP2 all certificates where the ‘Properties’ field indicatesthat the component’s name is XEN on VT-x, the version is 3.0, thesoftware provider is Citrix and the updated date is after May 2009. There is now

254 E. Gallery, A. Nagarajan, and V. Varadharajansufficient information to build a chain representing a platform component to aroot trusted third party-certified property/set of properties to which private keyuse is bound. Using this method provides two advantages in the mobile agentenvironment. Firstly, it adds a level of abstraction which allows a mobile agentoriginator to bind a key to a property which multiple platforms with differentstate configurations can fulfill. Secondly, it enables a mobile host platform tocontrol the release of platform state information.9.3 Property MappingOnce the agent originator has generated and migrated an asymmetric key pairas described in sections 9.1 and 9.2, the agent originator can sign and encryptany sensitive agent code, data, and state information (or indeed a symmetrickey used to confidentiality and integrity protect an agent) using the agent originatorpublic key, in the knowledge that this sensitive information can only beaccessed by a destination host platform to which the agent originator key pairhas been migrated and only when that platform fulfills the required securityproperty/properties.In order to use the private key the properties to which key use is bound mustbe compared to the properties which the host platform satisfies. A variant of theTPM Unbind command functionality is required in this instance. Assuming wehave a full set of TM PCRs, the corresponding stored measurement log (whichnames and lists the measurements of all components which have been reliablystored to the PCRs), and a set of property certificates, collected as described inthe previous section, this command variant will result in the following actions.– The {Security properties, TTP ID, TTP publickey} sets to which privatekey use is bound are examined.– The integrity of the stored measurement log is initially verified against theintegrity metrics stored in the PCRs.– Each integrity measurement is then compared against those held in all retrievedcertificates.– When a match is found between an integrity measurement and a level nproperty certificate, the properties of this component are compared againstthe component identifiers listed within the retrieved level n − 1 certificates.– When a match is found, the public key of the TTP listed in the componentidentifiers field of the level n − 1 property certificate is used to verify theintegrity of the level n property certificate.– The property defined in the level n − 1 property certificate is then comparedagainst the component identifers held in all retrieved level n − 2 propertycertificates.– When a match is found the signature of the TTP who signed the level n − 1property certificate is verified using a key belonging to the TTP identifiedin the level n − 2 certificate.This process continues until a match is found between the security property froma {Security properties, TTP ID, TTP public key} set to which private key

A Property-Dependent Agent Transfer Protocol 255use is bound and one defined in a property certificate and the certificate canbe verified using the public key associated with the TTP identified within the{Security properties, TTP ID, TTP public key} set. This process is repeateduntil all required properties have been fulfilled.Suppose that the agent originator private key is bound to the level 3 property‘software isolation’ and the identity and public key of the property certifier,TTP1. On receipt of the incoming aglet, the certificates shown in figure7 and 8 are input into a T(M)AP trusted computing extension. The integrityof the stored measurement log is verified against the integrity metrics storedin the PCRs. The measurement of the platform’s isolation layer is matched tothe component identifiers held in the property certificate shown in figure 8. Thismeasurement is mapped to a set of properties shown in figure 8 and these propertiesare in turn mapped to the service component property of ‘software isolation’(to which private key use is bound) using the certificate shown in figure 7. Theintegrity of the level 4 property certificate is then verified using the public key ofTTP2 listed in the level 3 certificate and the level 3 certificate is verified usingthe public key of TTP1 contained within the property set to which private keyuse is bound.By design, once an aglet has executed, it is re-encrypted with the agent originatorpublic key prior to its migration, or indeed re-protected in terms of confidentialityand integrity using its associated symmetric key(s) which is/are inturn protected using the agent originator public key. The protocol can be brokendown into four phases: agent host key generation; agent originator key generation;key transfer; and mobile agent transfer.9.4 Stage 1: Agent Host Key Generation1. A H → A H TM : TPM CreateWrapKey. ThekeyInfo input parameter isused to request the generation of a non-migratable key.2. A H TM : Generates a non-migratable asymmetric key pair. A TPM Keystructure, which contains the public key P AH and the encrypted private keyS AH , is output.3. A H → A H TM : TPM LoadKey2 — Request to load the TPM Key generatedin step 2.4. A H TM : Loads the TPM Key.5. A H TM → A H : Outputs a handle to where the decrypted private key fromthe TPM Key is loaded.6. A H → A H TM : TPM LoadKey2 — Request to load the TPM Key structure,which contains the A H attestation identity key pair as described inassumption 9.7. A H TM : Loads the TPM Key.8. A H TM → A H : Outputs a handle to where the private AIK is loaded.9. A H → A H TM : TPM CertifyKey2. ThekeyHandle and certHandle inputparameters are used to specify the handles of the key to be certified (loadedin step 4) and the private attestation identity key to be used to certify thekey (loaded in step 7).

256 E. Gallery, A. Nagarajan, and V. VaradharajanFig. 9. Stage 1:Agent host key generation10. A H TM :SignsH(certifyInfo) using the chosen private attestation identitykey.The certifyInfo structure describes the key-to-be-certified, including anyauthorisation data requirements, a digest of the public key-to-be-certified,160 bits of external data, and a description of the platform configurationdata required for the release and use of the certified key.11. A H TM → A H : P AH || SIG AH (H(certifyInfo)) || A H TM AIKCertificateFollowing stage 1 of the protocol A H is in possession of an AIK-certified nonmigratablekey pair, P AH and S AH . The protocol message flow is illustrated infigure 9.9.5 Stage 2: Agent Originator Key Generation1. A O : Chooses the property/properties with which A H must comply in orderto gain access to the agent it wishes to protect, and the identities and publickeys of the property certification authorities trusted to certify that a (setof) software component(s) provide(s) the property/properties specified, e.g.{Security properties, TTP ID, TTP public key}.2. A O → A O TM : TPM CreateWrapKey variant. The keyInfo input parameteris used to request the generation of a migratable key pair. The migrationauthorisation data for the new key is set to a value known only to A O ,sothat the key pair can only be migrated by A O . An agent host which hasimported the key will not be able to migrate the key. In order to ensure thatthe private key from this key pair can only be used when the host platformconforms to a set of properties rather than a set of PCR values, the pcrInfoparameter of keyInfo must be changed. For example, a new keyInfo inputparameter called propertyInfo could be defined to hold a parameter calledpropertiesAtRelease which contains {Security properties, TTP ID, TTPpublic key} sets.

A Property-Dependent Agent Transfer Protocol 257Fig. 10. Stage 2:Agent originator key generation3. A O TM : Generates an asymmetric migratable key pair, TPM Key, whichcontains the public key, P AO , and the encrypted private key, S AO ,whereprivate key use is dependent on the host platform’s conformance to a set ofproperties, and key pair migration is dependent on proof of knowledge of themigration authorisation data.Following stage 2 A O is in possession of a CA-certified signing key pair (as perassumptions 11 and 12) and a migratable key pair, P AO and S AO . The protocolmessage flow is illustrated in figure 9.9.6 Stage 3: Agent Creation and Key Transfer1. A O : Creates a mobile agent, A.2. A O : Formulates the itinerary for A.3. A O → A H : Requests the certified public key generated in stage 1 for everyA H on A’s itinerary.4. A H → A O :TransmitsP AH || SIG AH (H(certifyInfo)) || A H TM AIKCertificate.5. A O : Verifies A H T M AIK Certificate for each A H .6. A O : Verifies SIG AH (H(certifyInfo)) for each A H using the public AIK ofthe A H contained in its corresponding A H T M AIK Certificate.Through verification of the AIK signature, SIG AH (H(certifyInfo)), theagent originator can verify whether or not the corresponding private key isstored within a genuine T(M)AP TM.7. A O → A O TM : TPM AuthorizeMigrationKey.Using this command A O can authorise each A H public key under which theprivate key, S AO , will be migrated.8. A O → A O TM : TPM CreateMigrationBlob.Using this command A O indicates the key pair to be migrated and provesknowledge of the key’s migration authorisation data.9. A O TM : Encrypts the migratable private key, S AO ,withtheA H public keyauthorised in step 7, E PAH (S AO ).10. A O TM → A O : E PAH (S AO ).11. A O → A H : P AO || E PAH (S AO ).12. A H → A H TM : TPM ConvertMigrationBlob.Using this command, E PAH (S AO ) is decrypted. Both S AO and P AO are thenimported into the local A H TM key hierarchy.13. A H :Examines{Security properties, TTP ID, TTP public key} sets towhich private key use is bound.

258 E. Gallery, A. Nagarajan, and V. VaradharajanFig. 11. Stage 3:Agent key transfer14. A H → TTP : Requests the necessary property certificates from the specifiedthird party property certifiers asdescribedinsection9.3.15. TTP → A H : The requested property certificates, for example those shownin figures 6, 7, 8.Following stage 3, A H is in possession of A O ’s migratable key pair, where useof the private key S AO by A H is dependent on the platform conforming to aset of A O -defined security properties. The protocol message flow is illustrated infigure 11.9.7 Stage 4: Mobile Agent Transfer1. A O :SignsA using its private signing key and encrypts the result using P AO ,E PAO (A || SIG AO (A)).Alternatively, A O may generate a symmetric key(s) in order to confidentialityand integrity-protect A andthensignandencryptthesymmetrickey(s)asshown above.2. A O → A H : E PAO (A || SIG AO (A)).3. A H → A H TM : TPM LoadKey2 — Request to load the private key, S AO ,which has been migrated to each A H in the agent’s itinerary.4. A H TM : Loads the TPM Key.5. A H TM → A H : Outputs a handle to where the private key, S AO ,fromtheTPM Key is loaded.6. A H → A H TM : Variant of TPM Unbind(E PAO (A || SIG AO (A))). In orderto use S AO the properties of A H must conform to those to which S AO isbound.7. A H TM Extension : Examines the {Security properties,TTP ID, TTPpublic key} sets to which S AO is bound.8. A H → TM : TPM P CRRead9. A H TM → A H : PCR Values

A Property-Dependent Agent Transfer Protocol 259Fig. 12. Stage 4: Mobile agent transfer10. A H TM Extension : Verifies the stored measurement log entries (whichname and contain the measurement of each platform component) againstthe PCR values to ensure their integrity.11. A H TM Extension : Attempts to build a chain from the properties towhich S AO use is bound and the integrity measurements which reflect theplatform’s state as described in section 9.3.12. A H TM Extension :Verifies the property certificates within each chain.13. A H TM : Decrypts E PAO (A || SIG AO (A)) if all properties are fulfilled.14. A H : Verifies SIG AO (A) using the public key certificate of A O .15. A H : Executes A.16. A H : Re-encrypts the agent and the agent signature and forwards the agent.The protocol message flow for stage 4 is illustrated in figure 12.9.8 Security RemarksIn this protocol a mobile agent (or indeed a symmetric key used to confidentialityand integrity protect the agent) is signed and encrypted such that it can only bedecrypted and executed upon a host platform which has retrieved the requiredprivate key and which satisfies certain security properties. In this way:1. A platform is verified as trusted prior to the migration of the agent originatorkey pair through the validation of the A H T M AIK Certificate andSIG AH (H(certifyInfo)) as shown in steps 5 and 6 in stage 3. The securityproperties of a host’s software environment are verified as trusted prior tokey use (i.e. agent decryption).2. The confidentiality of the aglet code, data and/or state information is protectedin transit between and in storage on a host platform through the useof asymmetric encryption using the public agent originator key P AO .(a) Secure encryption/decryption key pair generation: The migratable keypair (which is used to protect the confidentiality of the agent) is generatedsecurely within the TPM or MTM of the mobile agent originator.(b) Secure encryption/decryption key pair transmission: As stated above,the migratable key pair is initially generated within the agent originatorTPM/MTM and must then be securely transmitted to each mobile host.

260 E. Gallery, A. Nagarajan, and V. VaradharajanIn order to do this, the agent originator takes an AIK-certified publicnon-migratable key from a mobile host, and verifies that it is from a nonmigratablekey pair and has indeed been generated within a TPM/MTM.The private key from the agent originator key pair is then encryptedusing the public key from the mobile host’s non-migratable key pair andmigrated to the mobile host in conjunction with the corresponding publickey.(c) Confidentiality-protected agent transmission, storage and access control:The mobile agent is then encrypted using the agent originator publickey. The agent remains encrypted while in transit to and in storage onthe mobile host, until its use. Because the corresponding private keyis known only to TPM/MTMs to which it has been migrated and canonly be used on the platform when it fulfills particular properties, anattacker cannot compromise the confidentiality of the agent in transit orin storage.3. The integrity of the aglet code, data and/or state information is protectedin transit between and in storage on host platforms through the use of adigital signature SIG AO (A).(a) Secure signature/verification key pair generation: The signature key pairis generated securely by the mobile agent originator. The TPM/MTMmay be used for key pair generation and private key storage to enhancethe security of its protection.(b) Secure verification key transmission: Is is assumed that the agent originatorpublic signature verification key is certified by a trusted certificationauthority.(c) Integrity-protected agent transmission and storage: The mobile agent isdigitally signed by the mobile agent originator. This signature can beverified by an agent host prior to agent execution to verify that theagent has not been accidentally or maliciously modified.4. Binding the use of S AO to a set of properties as described in stage 2 steps 1–3allows A O to ensure A is protected as required when executing and also thatthe required services are available. Properties can be chosen such that theconfidentiality and/or integrity of agent code, data and state is protected,for example.10 Conclusions and Future WorkThis paper explains how trusted computing technologies can be extended toprotect mobile agents from attack. We outline the shortcomings of previoussolutions [3] that focus on the use of binary integrity measurements to allowan agent originator to extend their control over subsequent environments inwhich their agents will execute. Instead we examine how a TCG mechanismbasedsecure agent transfer protocol can be enhanced to incorporate the use ofproperty-based state information. We extend the work completed on propertycomponent certificates in [16] through the definition of a property granularity

A Property-Dependent Agent Transfer Protocol 261pyramid and provide examples of properties (and property certificates) thatcan be used in the context of a mobile agent environment. If this solution isto succeed, however, further work must be completed in the area of propertyderivation/definition and certification. We are currently refining the propertygranularity pyramid defined in this paper and investigating its application.AcknowledgementsWe wish to acknowledge the valuable contributions provided by Sigi Guergens,Chris Mitchell and the anonymous TRUST2009 referees, which have significantlyimproved the paper.References1. Alves, T., Felton, D.: TrustZone: Integrated Hardware and Software Security.White paper, ARM (July 2004)2. Balacheff, B., Chen, L., Pearson, S., Plaquin, D., Proudler, G.: Trusted ComputingPlatforms: TCPA Technology in Context. Prentice Hall, Upper Saddle River (2003)3. Balfe, S., Gallery, E.: Mobile Agents and the Deus Ex Machina. In: Proceedings ofthe 2007 IEEE International Symposium on Ubisafe Computing (UBISAFE 2007),May 21–23, pp. 486–492. IEEE Computer Society, Los Alamitos (2007)4. Berkovits, S., Guttman, J.D., Swarup, V.: Authentication for Mobile Agents. In: Vigna,G. (ed.) Mobile Agents and Security. LNCS, vol. 1419, pp. 114–136. Springer,Heidelberg (1998)5. Chen, L., Landerfermann, R., Rohe, H.L.M., Sadeghi, A.R., Stuble, C.: A Protocolfor Property-Based Attestation. In: Proceedings of the 1st ACM Workshop onScalable Trusted Computing, Fairfax, Virginia, USA, November 3, 2006, pp. 7–16.ACM, New York (2006)6. Crane, S.: Privacy Preserving Trust Agents. Technical Report HPL-2004-197, HPLabs, Bristol, UK (November 11, 2004)7. Ekberg, J.-E., Asokan, N., Kostiainen, K., Eronen, P.: OnBoard Credentials PlatformDesign and Implementation. Technical Report NRC-TR-2008-001, Nokia ResearchCenter, Helsinki, Finland (January 2008)8. Gallery, E., Tomlinson, A.: Secure Delivery of Conditional Access Applications toMobile Receivers. In: Mitchell, C.J. (ed.) Trusted Computing. IEE ProfessionalApplications of Computing Series 6, ch. 7, pp. 195–238. The Institute of ElectricalEngineers (IEE), London (2005)9. Gray, R.S., Kotz, D., Cybenko, G., Rus, D.: D’Agents: Security in Multiple-Language, Mobile Agent System. In: Vigna, G. (ed.) Mobile Agents and Security.LNCS, vol. 1419, pp. 154–187. Springer, Heidelberg (1998)10. Haldar, V., Chandra, D., Franz, M.: Semantic Remote Attestation – A VirtualMachine Directed Approach to Trusted Computing. In: Proceedings of the 3rdConference on Virtual Machine Research And Technology Symposium, San Jose,California, USA, May 6–7, 2004, pp. 29–41. USENIX Association, Berkeley (2004)11. Intel. LaGrande Technology Architectural Overview. Technical Report 252491-001,Intel Corporation (September 2003)

262 E. Gallery, A. Nagarajan, and V. Varadharajan12. Johnston, W., Mudumbai, S., Thompson, M.: Authorization and Attribute Certificatesfor Widely Distributed Access Control. In: Proceedings of the IEEE 7thInternational Workshops on Enabling Technologies: Infrastructure for CollaborativeEnterprises (WETICE 1998), Palo Alto, California, USA, June 17–19, 1998,pp. 340–345. IEEE Computer Society, Washington (1998)13. Lange, D.B., Oshima, M.: Programming and Deploying Java Mobile Agents withAglets. Addison Wesley Longman, Inc., Reading (1998)14. Marchesini, J., Smith, S., Wild, O., Stabiner, J., Barsamian, A.: Open-source Applicationsof TCPA Hardware. In: ACSAC 2004, pp. 294–303. IEEE ComputerSociety, Washington (2004)15. Mitchell, C. (ed.): Trusted Computing. IEE Professional Applications of ComputingSeries 6. The Institute of Electrical Engineers (IEE), London (2005)16. Nagarajan, A., Varadharajan, V., Hitchens, M.: Trust Management for TrustedComputing Platforms in Web Services. In: Proceedings of the 2nd ACM Workshopon Scalable Trusted Computing, Alexandria, Virginia, USA, November 2, 2007,pp. 58–62. ACM, New York (2007)17. Necula, G.C., Lee, P.: Safe, Untrusted Agents Using Proof-Carrying Code. In:Vigna, G. (ed.) Mobile Agents and Security. LNCS, vol. 1419, pp. 61–91. Springer,Heidelberg (1998)18. Nwana, H.S., Ndumu, D.T.: An Introduction to Agent Technology. In: Nwana,H.S., Azarmi, N. (eds.) Software Agents and Soft Computing: Towards EnhancingMachine Intelligence. LNCS, vol. 1198, pp. 3–26. Springer, Heidelberg (1997)19. Ousterhout, J.K., Levy, J.Y., Welch, B.B.: The Safe-Tcl Security Model. In: Vigna,G. (ed.) Mobile Agents and Security. LNCS, vol. 1419, pp. 217–235. Springer,Heidelberg (1998)20. Pearson, S.: Trusted Agents that Enhance User Privacy by Self-Profiling. TechnicalReport HPL-2002-196, HP Labs, Bristol, UK (July 15, 2002)21. Pearson, S.: How Trusted Computers can Enhance for Privacy Preserving MobileApplications. In: Proceedings of the 1st International IEEE WoWMoM Workshopon Trust, Security and Privacy for Ubiquitous Computing (WOWMOM 2005),Taormina, Sicily, Italy, June 13–16, 2005, pp. 609–613. IEEE Computer Society,Washington (2005)22. Peinado, M., Chen, Y., England, P., Manferdelli, J.L.: NGSCB: A Trusted OpenSystem. In: Wang, H., Pieprzyk, J., Varadharajan, V. (eds.) ACISP 2004. LNCS,vol. 3108, pp. 86–97. Springer, Heidelberg (2004)23. Peinado, M., England, P., Chen, Y.: An Overview of NGSCB. In: Mitchell, C.J.(ed.) Trusted Computing. IEE Professional Applications of Computing Series 6,ch. 7, pp. 115–141. The Institute of Electrical Engineers (IEE), London (2005)24. Poritz, J., Schunter, M., van Herreweghen, E., Waidner, M.: Property Attestation– Scalable and Privacy-friendly Security Assessment for Peer Computers. ResearchReport RZ 3548, IBM Research GmbH, Zurich Research Laboratory, Switzerland(October 2004)25. Pridgen, A., Julien, C.: A Secure Modular Mobile Agent System. In: Proceedingsof the 2006 International Workshop on Software Engineering for Large-Scale Multi-Agent Systems (SELMAS 2006), Shanghai, China, May 22–23, pp. 67–74. ACMPress, New York (2006)26. Reinicke, M., Strasser, M.: Decentralized Management of Persistent BandwidthProvision for Mobile Devices in Cellular Radio Networks. In: Sprague, R.H. (ed.)Proceedings of the 37th Annual Hawaii International Conference on System Sciences(HICSS 2004), Big Island, Hawaii, January 5-8. IEEE Computer Society, LosAlamitos (2004)

A Property-Dependent Agent Transfer Protocol 26327. Rothermel, K., Schwehm, M.: Mobile Agents. In: Kent, A., Williams, J.G. (eds.)Encyclopedia for Computer Science and Technology, vol. 40, pp. 155–176. M.Dekker Inc., New York (1999)28. Sadeghi, A.R., Stuble, C.: Property-based Attestation for Computing Platforms:Caring about Properties, not Mechanisms. In: Proceedings of the 2004 Workshopon New Security Paradigms (NSPW 2004), Nova Scotia, Canada, September 20-23,pp. 67–77. ACM, New York (2004)29. Sekar, R., Ranalrishnan, C.R., Ramakrishnan, I.V., Smolka, S.A.: Model CarryingCode (MCC): A New Paradigm for Mobile Code Security. In: Proceedings of theNew Security Paradigms Workshop (NSPW 2001), Cloudcroft, New Mexico, USA,September 10–13, pp. 23–30. ACM Press, New York (2001)30. Tardo, J., Valente, L.: Mobile Agent Security and Telescript. In: Proceedings of the41st International IEEE Computer Society International Conference: Technologiesfor the Information Superhighway (COMPCON 1996), Santa Clara, California,USA, February 25–28, pp. 58–63. IEEE Computer Society Press, Los Alamitos(1996)31. TCG. TCG Generic Server Specification. TCG specification Version 1.0 Revision0.8, The Trusted Computing Group (TCG), Portland, Oregon, USA (March 2005)32. TCG. TCG PC Client Specific Implementation Specification For ConventionalBIOS. TCG specification Version 1.2 Final, The Trusted Computing Group (TCG),Portland, Oregon, USA (July 2005)33. TCG. TCG Trusted Network Connect TNC Architecture for Interoperability. TCGspecification Version 1.1 Revision 2, The Trusted Computing Group (TCG), Portland,Oregon, USA (May 2006)34. TCG. TPM Main, Part 1: Design Principles. TCG Specification Version 1.2 Revision94, The Trusted Computing Group (TCG), Portland, Oregon, USA (March2006)35. TCG. TPM Main, Part 2: TPM Data Structures. TCG Specification Version1.2 Revision 94, The Trusted Computing Group (TCG), Portland, Oregon, USA(March 2006)36. TCG. TPM Main, Part 3: Commands. TCG Specification Version 1.2 Revision 94,The Trusted Computing Group (TCG), Portland, Oregon, USA (March 2006)37. TCG MPWG. The TCG Mobile Reference Architecture. TCG specification version1 revision 1, The Trusted Computing Group (TCG), Portland, Oregon, USA (2007)38. TCG MPWG. The TCG Mobile Trusted Module Specification. TCG specificationversion 1 revision 1, The Trusted Computing Group (TCG), Portland, Oregon,USA (September 2007)39. Varadharajan, V.: Security Enhanced Mobile Agents. In: Proceedings of the 7thACM Conference on Computer and Communications Security, Athens, Greece,November 1–4, pp. 200–209. ACM, New York (2000)40. Vigna, G.: Cryptographic Traces for Mobile Agents. In: Vigna, G. (ed.) MobileAgents and Security. LNCS, vol. 1419, pp. 137–153. Springer, Heidelberg (1998)41. Wilhelm, U.G., Staamann, S., Butty, L.: Introducing Trusted Third Parties to theMobile Agent Paradigm. In: Vitek, J., Jensen, C. (eds.) Secure Internet Programming.LNCS, vol. 1603, pp. 469–489. Springer, Heidelberg (1999)42. Yoshihama, S., Ebringer, T., Nakamura, M., Munetoh, S., Maruyama, H.: WS-Attestation: Effecient and Fine-Grained Remote Attestation on Web Services. In:Proceedings of the IEEE International Conference on Web Services (ICWS 2005),Orlando, Florida, USA, July 11-15, pp. 743–750. IEEE Computer Society Press,Washington (2005)

Author IndexAad, Imad 217Alam, Masoom 63Ali, Tamleek 63Baiardi, Fabrizio 81Benzel, Terry V. 133Bhaskara, Ganesha 133Ceccarelli, Francesco 81Cilea, Diego 81Clark, Paul C. 133Danner, Peter 101Dietrich, Kurt 29Duflot, Loïc 14Dwoskin, Jeffrey S. 133England, Paul 1Gallery, Eimear 240Hein, Daniel 101Huh, Jun Ho 169Irvine, Cynthia E. 133Katzenbeisser, Stefan 120Kursawe, Klaus 120Lee, Ruby B. 133Levillain, Olivier 14Levin, Timothy E. 133Löhr, Hans 45Lyle, John 153, 169Morin, Benjamin 14Nagarajan, Aarthi 240Nauman, Mohammad 63Nguyen, Thuy D. 133Pirker, Martin 101Poller, Andreas 183Sadeghi, Ahmad-Reza 45, 197Schulz, Steffen 197Sgandurra, Daniele 81Soghoian, Christopher 217Steffan, Jan 183Stotz, Jan-Peter 183Stüble, Christian 45Stumpf, Frederic 120Tariq, Talha 1Toegl, Ronald 101Trukenmüller, Jan 183Türpe, Sven 183Varadharajan, Vijay 240Weber, Marion 45Winandy, Marcel 45Winter, Johannes 29Zhang, Xinwen 63

Lecture Notes in Computer Science 5471 - tiera.ru

Create successful ePaper yourself

Delete template?

Save as template?