Science, Faculty of
Computer Science, Department of
DSpace
UBCV
Mehrotra, Puneet
Master of Science - MSc
University of British Columbia
Users desire control over their data even as they share them across device boundaries. At the moment, they rely on ad-hoc solutions such as sending self destructible data with ephemeral messaging apps such as SnapChat. We present Trusted Capsules, a general cross-device access control abstraction for files. It bundles sensitive files with the policies that govern their accesses into units we call capsules. Capsules appear as regular files in the system. When an app opens one, its policy is executed in ARM TrustZone, a hardware-based trusted execution environment, to determine if access should be allowed or denied. As Trusted Capsules is based on a pragmatic threat model, it works with unmodified apps that users have come to rely on, unlike existing work. We show that policies in Trusted Capsules are expressible and that the slowdowns in our approach are limited to the opening and closing of capsules. Once an app opens a capsule, its read throughput of the file is identical to regular non-capsule files.
Cross-device Access Control with Trusted CapsulesbyPuneet MehrotraB. Engineering, Birla Institue of Technology and Science, 2013M. Science, Birla Institute of Technology and Science, 2013A THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFMaster of ScienceinTHE FACULTY OF GRADUATE AND POSTDOCTORALSTUDIES(Computer Science)The University of British Columbia(Vancouver)October 2019c© Puneet Mehrotra, 2019The following individuals certify that they have read, and recommend to the Fac-ulty of Graduate and Postdoctoral Studies for acceptance, the thesis entitled:Cross-device Access Control with Trusted Capsulessubmitted by Puneet Mehrotra in partial fulfillment of the requirements for thedegree of Master of Sciencein Computer Science.Examining Committee:Ivan Beschastnikh, Computer ScienceSupervisorMargo Seltzer, Computer ScienceSupervisory Committee MemberiiAbstractUsers desire control over their data even as they share them across deviceboundaries. At the moment, they rely on ad-hoc solutions such as sending self-destructible data with ephemeral messaging apps such as SnapChat. We presentTrusted Capsules, a general cross-device access control abstraction for files. Itbundles sensitive files with the policies that govern their accesses into units we callcapsules. Capsules appear as regular files in the system. When an app opens one,its policy is executed in ARM TrustZone, a hardware-based trusted execution envi-ronment, to determine if access should be allowed or denied. As Trusted Capsulesis based on a pragmatic threat model, it works with unmodified apps that users havecome to rely on, unlike existing work. We show that policies in Trusted Capsulesare expressible and that the slowdowns in our approach are limited to the openingand closing of capsules. Once an app opens a capsule, its read throughput of thefile is identical to regular non-capsule files.iiiLay SummaryPeople are increasingly using mobile devices to share digital content with eachother. While this is convenient and easy to do, they must trust in good faith thatthe recipient to handle the data as per their wishes. This is not always the caseand there are many data leaks that point to this. There is a need to let the userscontrol access to their data even after they have shared it with someone they haveno influence over.We present TrustedCapsules, a system that enables users to define an accesspolicy for their data that is guaranteed to be followed on the recipients device.Our contribution here is this cross-device access control abstraction that workswith unmodified applications. We design this system around hardware enabledsecurity guarantees, and evaluate our prototype to show that it imposes a reasonableslowdown when compared to regular file access.ivPrefaceAll work presented henceforth was conducted in the Networks, Systems andSecurity (NSS) lab in the Department of Computer Science at the University ofBritish Columbia, Vancouver Campus. This thesis is an original, unpublished workby Puneet Mehrotra, written under the supervision of Ivan Beschastnikh. It buildson previous prototypes developed by Peter Feifan Chen and Amanda Levin.vTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiLay Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 TrustZone & OP-TEE Overview . . . . . . . . . . . . . . . . . . . . 42.1 TrustZone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Linaro OP-TEE . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.1 ARM Trusted Firmware . . . . . . . . . . . . . . . . . . 82.2.2 OP-TEE OS . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3 OP-TEE Supplicant . . . . . . . . . . . . . . . . . . . . . 93 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1 Contextual Theat Model . . . . . . . . . . . . . . . . . . . . . . 113.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12vi4 Trusted Capsules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1 Capsules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Policy API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3 Data monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.4 Security analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Device Registration and Key Distribution . . . . . . . . . . . . . . . 245.1 Registering a Capsule Recipient . . . . . . . . . . . . . . . . . . 245.2 Capsule Generation and Key Distribution . . . . . . . . . . . . . 266 Use case examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.0.1 Prototype Evolution . . . . . . . . . . . . . . . . . . . . 348 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368.1 Policy language . . . . . . . . . . . . . . . . . . . . . . . . . . . 368.2 System call microbenchmarks . . . . . . . . . . . . . . . . . . . 378.3 Policy Performance Evaluation . . . . . . . . . . . . . . . . . . . 399 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419.1 Design Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 419.2 Prototype Limitations: . . . . . . . . . . . . . . . . . . . . . . . 4210 Securing Applications . . . . . . . . . . . . . . . . . . . . . . . . . . 4410.1 Modifying Applications to Use a TEE . . . . . . . . . . . . . . . 4410.2 Securing Unmodifed Applications . . . . . . . . . . . . . . . . . 4811 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5012 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55viiList of TablesTable 2.1 The privilege levels at which the various components of theTrustZone based system run. The Secure Monitor runs at thehighest privilege. . . . . . . . . . . . . . . . . . . . . . . . . . 7Table 3.1 An enumeration of the possible system state and adversary typecombinations. The! and# symbols indicate whether or notTrusted Capsules prevents data exfiltration in the correspond-ing scenario. Note that the adversary here is not authorized todirectly open a capsule on the device. . . . . . . . . . . . . . . 13Table 4.1 The Lua-based API that policies in Trusted Capsules may use . 17Table 8.1 LOC for example policies from Section 6. . . . . . . . . . . . 37viiiList of FiguresFigure 1.1 (a) Today, a data creator has no control over their data on re-mote devices: devices enforce local policies on data they re-ceive. We propose (b) cross-platform policies that move withdata and are enforced uniformly across devices. . . . . . . . . 2Figure 2.1 The Physical CPU maps to two virtual CPUs - one running theTEE (secure world) and the other running the rich OS (normalworld). The context transitions between these are handled bythe smc instruction that gets serviced by the monitor modesoftware, which runs at the highest level of privilege. . . . . . 5Figure 2.2 ARM TrustZone Boot Sequence. . . . . . . . . . . . . . . . . 8Figure 2.3 OP-TEE API calls to open A TA session . . . . . . . . . . . . 10Figure 3.1 A finite-state machine view of Trusted Capsule’s threat model.Each capsule on a device begins in the pessimistic state. Asuccessful transition from the pessimistic to optimistic statemeans an app on the device tried to open the capsule and thecapsule’s policy authorized the access. Only that app processis allowed to access that file in the optimistic state. When thethe process closes the file, the system transitions back to thepessimistic state. . . . . . . . . . . . . . . . . . . . . . . . . 12Figure 4.1 Trusted capsule layout. . . . . . . . . . . . . . . . . . . . . . 16ixFigure 4.2 Trusted capsule data monitor design. Application system callsto the filesystem for accessing trusted capsules are interceptedand forwarded to the trusted capsule application through theFUSE filesystem and OP-TEE Linux Driver. The secure worldtrusted capsule applications access peripheral I/O through RPCcalls to the OP-TEE Supplicant via the OP-TEE Linux Driver. 20Figure 4.3 Trusted capsule monitor operation (shaded region operates inthe secure world). A. Application open system call is inter-cepted. B, C. FUSE identifies if a file is a capsule, and if so,invokes an RPC into the secure world to decrypt the capsule.D. The trusted capsule application (TA) evaluates the open pol-icy. E. FUSE writes the decrypted contents to a shadow file F.The application is returned a filehandle to the shadow file, andall subsequent I/O requests are directed to the shadow file. . . 20Figure 5.1 Registration as Recipient - intiating the registration process . . 25Figure 5.2 Registration as Recipient - validation of the request . . . . . . 26Figure 5.3 Capsule Generation and Key Registration . . . . . . . . . . . 27Figure 5.4 Capsule Decrypt as Recipient . . . . . . . . . . . . . . . . . 28Figure 6.1 Simple location based access policy . . . . . . . . . . . . . . 31Figure 6.2 Location based redaction policy . . . . . . . . . . . . . . . . 32Figure 6.3 Policy to allow content pre-distribution . . . . . . . . . . . . 33Figure 8.1 Average system call latency . . . . . . . . . . . . . . . . . . 38Figure 8.2 Throughput of Read and Write operations to a capsule . . . . 38Figure 8.3 Normalized latency of servicing an open for different policieswith respect to the latency to service a null-policy capsule openrequest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Figure 10.1 An application can be split into two parts - one that resides inthe untrusted operating system and has the interfaces to securefunctionality that resides in the trusted environment. . . . . . 45xFigure 10.2 Virtual Ghost uses LLVM to create an intermediate layer theOS and the processor to protect the application from the unfet-tered access otherwise enjoyed by a kernel . . . . . . . . . . . 46xiAcknowledgmentsThis work was supported by the NSA National Information Assurance Lab andby the Institute of Computing, Information and Cognitive Systems (ICICS) at theUniversity of British Columbia, Vancouver Campus.I would like to thank Dr. Ivan Beschastnikh for all his help and guidancethroughout the entirety of this project and giving me the courage and inspiration topersevere even when I was ready to hang up my boots. I would also like to thankProf. Margo Seltzer for giving me valuable feedback and agreeing to be my secondreader. More than that, I am eternally grateful to Prof. Seltzer for being the beaconof hope during my time at UBC, and for all her advise, kindness, and warmth.This work would not have been possible had it not been for Dr. Ali Razeen.The time and energy he spent on this project and in guiding me through the mazeof academic publishing has made me develop a deeper understanding and appreci-ation towards the process. His optimism perfectly balances his scepticism (whicha security researcher has oodles of) and gave me the much needed confidence tokeep calm and carry on. I would also like to thank Eric Semeniuc - undergraduateextraordinaire - for sticking through with the project and executing to perfectionthe many things I asked. I could not have asked for a better partner.I would also like to thank all the members of NSS lab who were with me alongthis journey through graduate school: Amanda Levin (ne´e Carbonari), ClementFung, Fabian Ruffy, Adam Geller, Vaastav Anand, Surbhi Palande, Nodir Kodirov,and Anthony Mason. I am eternally grateful for all the support and making mytime at UBC incredibly fun.In addition to my friends mentioned above, I would also like to thank all myfriends at UBC: Hayley Guillou, Anna Scholtz, Giovanni Viviani, Nico Ritschel,xiiAarti Kashyap, Syed Mubashir Iqbal, and many others who deserve to be listed.You have kept me sane and going when my research was not, and helped me keepsome form of work-life balance.Lastly, I must thank my family and friends. Three different time-zones and thegreat physical distance between us never came in the way of your unconditionaland complete support of this path I have embarked upon. I am extremely gratefuland blessed to have you all on my side.xiiiChapter 1IntroductionModern mobile devices are highly capable and have enabled users to create andshare rich content such as videos, pictures, and documents. However, users oftenhave little control over their shared data. As illustrated in Figure 1.1, a user hasfull control over her file as long as it stays on her device. She loses this controlthe moment the file leaves her device boundaries. For example, files backed upto iCloud or Dropbox are vulnerable to the security of those platforms and filesshared with other users are vulnerable to their benevolence and their device securitypolicies.Users today rely on ad-hoc solutions. For example, they might use Cryptomator[3] to encrypt their files before backing them up to the cloud or SnapChat to sendself-destructing images that are viewable only for a limited period of time [11].These apps address particular use-cases with coarse controls and do not provideany general-purpose data protection mechanisms.Existing work has proposed several solutions to let users retain control overtheir data as it crosses device boundaries. A current state of the art approach is touse a hardware-based trusted execution environment (TEE) to control accesses tosensitive files. The focus is to ensure that users retain full control over their shareddata. DroidVault [43], for example, does not allow regular apps running outsidethe TEE to access the data. Instead, it requires data owners to explicitly write andwhitelist the code that is allowed to process sensitive data, and it executes this codewithin the TEE. We believe that such restrictions make the corresponding systems1F.docxF.docx F.docxPolicy B Policy C(b) Cross-devicedata-centric access control(a) Device-centricaccess controlemail dropboxPolicy AF.docxF.docx F.docxPolicy B Policy CPolicy APolicy APolicy Aemail dropboxFigure 1.1: (a) Today, a data creator has no control over their data on remotedevices: devices enforce local policies on data they receive. We pro-pose (b) cross-platform policies that move with data and are enforceduniformly across devices.impractical. Users already trust and rely on a variety of apps to create and sharecontent. It is unlikely that users would use a system that does not support theirapps.We present a platform-level file protection mechanism that does not restrictusers into using certain apps. To achieve this, we rely on a pragmatic pessimistic-optimistic threat model. In the pessimistic state, we consider the device and appscompletely untrusted and rely on a TEE to perform safety checks. When it isconsidered safe, the system transitions into the optimistic state where we also trustthe OS kernel and the app accessing sensitive data. Finally, when the app no longeruses the data, the system switches back into the pessimistic state. We leave a furtherdiscussion of our threat model to Section 3.We contribute Trusted Capsules, a data-centric access control abstraction thatprovides a mechanism to protect against this threat model. It enables users tobundle sensitive files with flexible policies that govern their accesses into encryptedunits we call capsules. Each capsule appears in the system as a regular file. Whenan app attempts to open a capsule, the platform evaluates the policy in a TEE. If thethe policy allows the access, the capsule’s contents are unsealed (decrypted) andprovided to the app and are resealed (re-encrypted) when the app later closes thefile. In our prototype, we use ARM TrustZone as the TEE and design policies as2stateful programs that can base access decisions on information such as location,time, or the number of prior accesses and may, if necessary, modify the data itself(e.g., for redaction).Our contributions may be summarized as follows:• A pragmatic access control abstraction for protecting sensitive files acrossdevice boundaries that works with existing unmodified apps.• Using our prototype, we show that our proposed approach imposes slow-downs only when a capsule is being opened or closed (An overhead of 1.96xand 1.67x, respectively, in the absence of any real security policy). Oncea capsule file is open, data can be read at a throughput identical to readingregular files.3Chapter 2TrustZone & OP-TEE OverviewTrusted capsules allow advisory policies to be enforced on remote devices thatthe data owner does not control. To protect sensitive operations such as trustedcapsule policy evaluation from remote users who can run an arbitrarily softwarestack, we require a Trusted Execution Environment (TEE) that is resistant to poten-tial compromise of both applications and OS running on the remote device. We useARM TrustZone technology as our hardware-based Trusted Execution Environ-ment and Linaro OP-TEE as the operating system that runs in our TEE. Withinthis TEE, we handle sensitive cryptographic operations, perform policy evaluation,securely store policy state, and establish a secure channel to the remote policy co-ordinator server.In the following, we provide a brief overview of the properties of TrustZoneand OP-TEE.2.1 TrustZoneARM TrustZone [13] is widely available on current commodity ARM pro-cessors. A TrustZone enabled processor maps to two virtual processors that thatexecute in a time-sliced fashion, context switching between each other through aspecial core mode called the “monitor mode”. We call a virtual processor that isrunning in the TEE to be running in Secure World. A virtual processor that runsthe regular operating system is said to be running in Normal World. The monitor4mode software acts as a robust gatekeeper to manage the physical processor’s con-text switch between these virtual processor modes by means of interrupt handling.These modes of operation of a physical processor and the transitions between themare visualized in Figure 2.1.vCPU running TEEvCPU running REEMonitor Mode SoftwareSMC SMCSecure World Normal WorldFigure 2.1: The Physical CPU maps to two virtual CPUs - one running theTEE (secure world) and the other running the rich OS (normal world).The context transitions between these are handled by the smc instruc-tion that gets serviced by the monitor mode software, which runs at thehighest level of privilege.One way in which world switch can be triggered by the software is by executinga dedicated instruction, the Secure Monitor Call (SMC) instruction. The softwarethat runs in the monitor mode is defined by the implementation of the chipset, butit generally saves the state of the current world and restores the state of the worldbeing switched to. Once the restoration is complete, the monitor performs a return-from-exception call to restart the processing in the restored world.A TrustZone enabled processor implements three sets of interrupt vectors -one for each world, and one for the monitor mode. The locations of these tablesare programmable and can be modified by changing the appropriate Vector Base5Address Register (VBAR). This can be used to control where the smc instructionwill trap to. VBARs are only accessible in privileged modes. The secure copy ofthe VBAR holds the vector base address for the Secure State and the non-securecopy of the VBAR holds the vector base address for the Non-secure state.The ARM TrustZone security model provides the following hardware-basedguarantee: the normal world cannot access the registers, memory or peripher-als assigned to the secure world; but the secure world can access normal worldregisters and memory.1This security guarantee for register access is maintained by tracking the exe-cution mode of a processor. The monitor mode software executes in secure world.The world in which a processor is currently executing is indicated by the NS-bit inthe Secure Configuration Register (SCR) in the system control coprocessor (CP15).When in monitor mode the processor is running in Secure World, regardless of thevalue of the NS-bit, but operations on the banked CP-15 registers will access theNormal World copies if the SCR NS-bit is set to 1.For memory, the secure world provides such a guarantee by either taking exclu-sive control of on-chip memory such as secure SRAM [6] or by mapping a sectionof the general off-chip memory and hiding it from the MMU of the normal world.For peripherals, secure and normal world access are partitioned by interruptmodes. ARM processors contain two interrupt modes – FIQ (Fast Interrupt Re-quest) and IRQ (Interrupt Request). Each interrupt mode can be individually as-signed to trap to code in the normal or secure world. Therefore, a peripheral canbe assigned to a specific world by assigning it to the corresponding interrupt mode.The usual set-up assigns FIQ to the secure world and IRQ to the normal world, asmost existing normal world drivers currently operate using the IRQ mode.For additional hardware protection for off-chip memory and device protection,additional hardware, such as TrustZone Protection Controller (TZPC) and Trust-Zone Address Space Controller (TZASC), can be added to extend the dual-worldabstraction to the AXI-bus, memory controllers and interrupt controllers. This isdone by propagating the NS-bit over the system bus.1TEEs cross-world ability to manipulate the memory and registers are grounds for Spectre[36]and Meltdown[45] type bugs. This has been acknowledged by Linaro and ARM and they havepublished page table isolation patches to fix these[32].6Exception Level Secure World Normal WorldEL0 Trusted Application ApplicationEL1 Secure OS Normal OSEL2 - HypervisorEL3 Secure MonitorTable 2.1: The privilege levels at which the various components of the Trust-Zone based system run. The Secure Monitor runs at the highest privilege.The secure monitor operates at Exception Level(EL) 3 - a higher privilege levelthan both the application (trusted or regular) and the operating system (secure ornormal). The Secure OS and the Normal OS operate at EL1, while the Applications- both in secure and normal world - run at EL0. This is shown in Table 2.1.2.2 Linaro OP-TEELinaro OP-TEE is an open-source operating system that has been designed forARM TrustZone. Linaro is part of the industry consortium called Global Platform,which leads efforts in standardizing APIs exposed by different TEE OS vendors.OP-TEE is the OS and related firmware that incorporates this standardized API andis ported across several hardware vendors.OP-TEE is the secure OS for executing trusted applications and is composedof:1. A low-level secure monitor for world-switching (ARM Trusted Firmware).This is where the SMC implementation resides.2. A TrustZone driver (OP-TEE Linux driver) which is used to access the TEEservices from the normal world, and3. OP-TEE Supplicant which runs in normal world user space as a single threadedapplication and is responsible for accessing services expected by the TEE-OS.The remaining discussion in this section is based arouind the HiKey system-on-chip (SoC) with Debian Linux as the normal world OS. This is configuration7BL1Boot ROMTrusted boot boardRESETBL2Trusted Boot FirmwareTrusted boot boardBL32Secure EL1 PayloadTrusted OS KernelBL33Non Trusted Firmware to load Non Secure OS(U-Boot, EDK2)BL31EL3 Runtime FirmwareWorld Switch and SMCTo Hypervisor/ Linux KernelNormalWorldSecureWorldFigure 2.2: ARM TrustZone Boot Sequence.we used for this project.2.2.1 ARM Trusted FirmwareARM Trusted Firmware (ATF) [2] provides a reference implementation ofthe Secure Monitor and the varoius Arm interface standards around system controland management, secure boot conventions, and interrupt management interface. Itis the critical piece in booting the secure environment, a process which is outlinedin Figure 2.2. There are three bootloaders involved in the process, and each isresponsible for initializing the image for the next level in the process. BL2 loadsall images in the third level of initialization. A root-of-trust can be built by havingeach stage attest the image of the next.2.2.2 OP-TEE OSOP-TEE OS is a small operating system that has been designed to run in theTrustZone backed TEE. It supports multi-threading and memory management, and8some peripheral control over GPIO pins. Despite being a multi-threaded multi-coreoperating system, OP-TEE does not have a scheduler. OP-TEE does not differen-tiate between single core and multicore hardware - which core it runs on dependson which core was in use in the normal world user-space when the SMC call wasinitiated. On receiving the SMC call, the first trap occurs to the cpu on handler()call on a fixed core (usually core 0), and it finishes with the SMC switching backto ARM-TF (EL3) and then the dispatcher does the world change to another core.Communication between the normal world and secure world occurs over buffersthat are allocated by the normal world but are managed by the secure world. Thesebuffers are used to pass information to and from the secure world for tasks suchas TEE function invocation and Normal world filesystem access from within theTEE.OP-TEE OS provides APIs that can be used to construct user space trustedapplications running in secure world (EL0 in secure world). OP-TEE OS applica-tions conform to the GlobalPlatform Internal API [5] where each trusted applica-tion must implement a set of well-defined functions as entry-points. These trustedapplications run in the secure world user space (Secure EL0 in Table 2.1). Trustedapplications can have a single-instance running in the secure world. Trusted Appli-cations can, however, have multiple sessions active with the normal world. Clientapplications in the normal world invoke these trusted applications through a similarset of GlobalPlatform Client APIs. The flow of one such API call - to load a trustedapplication and establish a session with the trusted application is shown in Figure2.3.2.2.3 OP-TEE SupplicantOP-TEE Supplicant takes RPC invocations from OP-TEE Linux Driver andexecutes the equivalent system calls through the normal world OS to access therelevant peripheral devices. These peripheral devices can include file system blockdevices and network cards for I/O. Linux dmabuf and mmap are used to pass databetween the user space OP-TEE supplicant and kernel space OP-TEE Linux Driver.Only a single instance of the OP-TEE supplicant can run at any given time and thisis enforced by the Linux TEE driver.9User Calling Application(Normal World)TEE Application(Normal World)OP-TEE Core(Secure World)Start to open TASessionTEEC_OpenSession (TA UUID) Tee_ta_open_sessionLook for TA in Secure MemoryLoad Signed and encrypted TA from NW filesystemRPC SMCAllocate shard memory and copy TA to shared memoryCopy TA from shared memory to OP-TEE coreSMCAuthenticate and load TA to TA memoryTA anti-rollback checkFinish open TA SessionFigure 2.3: OP-TEE API calls to open A TA session10Chapter 3Threat Model3.1 Contextual Theat ModelTrusted Capsules use a threat model that changes based on the context in whichthe application is executing. As illustrated in Figure 3.1, this model has two states,pessimistic and optimistic, and there is a transition between the two states depend-ing on the context. We assume that device owners have full control over the soft-ware stack running in the normal world but may not modify the stack runningwithin TrustZone.The system begins in the pessimistic state when the user first receives a capsule,which is encrypted data bundled with a policy that governs its access. In this state,the TCB consists solely of ARM TrustZone and the secure monitor; the OP-TEEOS running in TrustZone; the Trusted Capsules data monitor that runs in OP-TEEOS. All code running outside of TrustZone (i.e., the normal world kernel and apps)are considered untrusted. In this state, we guarantee that the capsule’s decryptedcontents are not available and that it is safe from attempts to either exfiltrate ormodify its data or policies. When the user opens the capsule with an app (whichwill use the open() syscall), the policy embedded in the capsule is executed bythe Trusted Capsules data monitor. If the policy denies access to the file, the systemremains in the pessimistic state (and the app’s call to open() will fail).If access is allowed, the system transitions to the optimistic state where thedecrypted capsule data is given to the app. The TCB in this state expands to in-11OptimisticStatePessimisticStateSuccessfulclose()Failed open() read(),write()open()Figure 3.1: A finite-state machine view of Trusted Capsule’s threat model.Each capsule on a device begins in the pessimistic state. A successfultransition from the pessimistic to optimistic state means an app on thedevice tried to open the capsule and the capsule’s policy authorized theaccess. Only that app process is allowed to access that file in the opti-mistic state. When the the process closes the file, the system transitionsback to the pessimistic state.clude the normal world kernel and the app that opened the file. Only that app isauthorized to access the file and we rely on the process isolation mechanisms inthe normal world kernel to prevent other unauthorized apps from accessing the de-crypted data. When the app closes the file (with the close() syscall), the capsuleis re-sealed and the system transitions back to the pessimistic state. If the app mod-ifies the file before closing it, the changes are saved only if allowed by the capsulepolicy. Otherwise, they are discarded and the capsule is resealed with the originalcapsule data. Any session data in TrustZone is also discarded.We consider side-channel and analog attacks out-of-scope. We can not con-trol the application from transmitting the capsule’s decrypted contents during theoptimistic state of operation.3.2 DiscussionTable 3.1 summarizes the protections Trusted Capsules offers depending on theadversary’s capabilities and the state of the system. Consider the scenario whenAlvin sends a capsule with a photo to Barbara’s smartphone with a policy thatrequires Barbara to authenticate herself before she can view the photo. In the worst12AdversaryStatePessimistic OptimisticWeak ! !Strong ! #Table 3.1: An enumeration of the possible system state and adversary typecombinations. The ! and # symbols indicate whether or not TrustedCapsules prevents data exfiltration in the corresponding scenario. Notethat the adversary here is not authorized to directly open a capsule on thedevice.case, Barbara herself is an adversary interested in leaking the photo. There are nomechanisms in Trusted Capsules preventing Barbara from doing so; the best thatcan be done is for Alvin to be sure he trusts Barbara before he authorizes her toview the photo.Consider instead the situation where Barbara is trustworthy but her smartphoneis sometimes accessible by Charlie, an adversary who is secretly interested in view-ing Alvin’s photo. Charlie aims to modify the state of the smartphone so thatwhen Barbara subsequently regains control of her phone and opens Alvin’s cap-sule, Charlie surreptitiously receives a copy of the photo.If the system is in the pessimistic state, there is no way for Charlie to viewthe photo because the capsule is sealed and encrypted. In the optimistic state,whether Charlie can exfiltrate the photo depends on whether he is a weak or a strongadversary. A weak adversary is one who is not technically inclined and hence maynot do much more than install new apps from the smartphone app store. In thisevent, when Barbara opens the capsule and the system switches to the optimisticstate, Trusted Capsules relies on the kernel’s app isolation mechanisms to preventother unauthorized apps Charlie might have installed from accessing the decryptedcapsule data.On the other hand, if Charlie is a strong adversary, then he may use a varietyof techniques such as kernel modifications to access the photo in the optimisticstate. While Trusted Capsules does not protect against this scenario at the moment,it may be mitigated by having the policy reason about the normal world softwarestack before opening the capsule. We leave an investigation of this strategy to13future work. Finally, note that regardless of the system state and adversary type, anadversary may not alter the policy embedded in a capsule and it never leaves theTrustZone environment.14Chapter 4Trusted CapsulesIn this section, we describe the components of our system in more detail anddescribe how they work together. A capsule (Section 4.1) is the data encryptedtogether with its access policy. This access policy is written in Lua and uses TrustedApplication’s functionality defined by the Policy API (Section 4.2). The handoverof the data from the normal world to the secure world is handled by a FUSE baseddata monitor (Section 4.3).4.1 CapsulesA capsule consists of data and an access policy for the data, both encapsulatedinto a single encrypted file. Figure 4.1 illustrates the format of a capsule. A capsulehas an unencrypted header segment (Shown in blue in Figure 4.1) followed by anencrypted data block (Shown in pink in Figure 4.1). The header identifies the fileas a capsule and contains integrity metadata used by the data monitor:1. Trusted Capsule Identifier: This is used to identify that the file being ac-cessed is a capsule. This identifier spells “TRUSTEDCAP” in plaintext.2. Capsule UUID: This is a unique identifier that gets assigned to the capsuleat the time of creation. This is used to find the decryption keys in TrustZone.3. Capsule Size: This field stores the size of the capsule in bytes. This is usedto create communication buffers to pass the contents to the secure world.15Trusted Capsule IdentifierCapsule UUIDCapsule SizeHashData PolicyData TextCapsule MetadataCapsule Access LogCapsuleHeaderCapsuleDataHello WorldAllow open if GPS coordinates in rangeCreated: Hogsmeade 2018-08-15 16:20:36Last Open: Hogsmeade2018-08-26 02:27:572a2ae2dbcce4486 BytesCreator: Jane DoeLast User: John Smith6201b4d7e6TRUSTEDCAPFigure 4.1: Trusted capsule layout.4. Hash: This field stores the hash of the data block of the capsule.The data block contains the following:1. Data Policy: This Lua Policy script that is run by the Policy Engine in TEE.This is written in accordance with the Policy API.2. Data Text: These are the exact contents of the file being encrypted.3. Capsule Metadata: This section is to hold any Key:Value based metadatathat the Policy Engine might need to evaluate the policy.4. Capsule Access Log: This section holds the latest accesses to the capsule.Every time a capsule is accessed, an entry gets appended here.The cryptographic keys required to decrypt capsules are securely loaded into a16DescriptionOpen-Onlyredact(start, end, replaceBytes) Replace byte range [start, end]of trusted capsule data withbytes replaceBytes.Close-OnlyreadNewCapsuleData(offset, length) Return length bytes from offsetof new trusted capsule data.newCapsuleLength() Return the length of new trustedcapsule data.SharedgetState(key, where) Get state mapped to key fromwhere.setState(key, val, where) Set state mapped to key to val inwhere.getLocation(where) Get location of device fromwhere.getTime(where) Get current time from where.readOriginalCapsuleData(offset,length)Return length bytes from offsetof original trusted capsule data.originalCapsuleLength() Return the length of originaltrusted capsule data.deleteCapsule() Delete the trusted capsule.updatePolicy() Check for policy update withtrusted capsule server.appendToBlacklist(key, where) Append key to blacklist of where- used by log to prune states inwhere.removeFromBlacklist(key, where) Remove key from blacklist ofwhere.Table 4.1: The Lua-based API that policies in Trusted Capsules may usesecure storage area accessible only by the TEE. The protocol to securely load keysinto the TEE is described in Chapter 5.174.2 Policy APIIn Trusted Capsules, policies are written in the Lua programming language andhave one simple requirement: they must implement an evaluate policy(op)function that is called when the capsule is being opened or closed; the op argumentdistinguishes between the two. There is a basic sanity check in the trusted appli-cation to ensure that the operation is valid - for example, the calling applicationcannot request a close() on a capsule that was never opened. In either case,the function has to return a boolean value that is interpreted differently dependingon the operation. If it returns true on a capsule open, the data is decrypted andgiven to the normal world app. Otherwise, access is denied. On a capsule close, re-turning true means file modifications by the normal world app will be kept whilefalse means they will be discarded. Policies may also use the Trusted CapsulesAPI listed in Table 4.1 to easily perform common operations:Storing state: Policies may store and retrieve arbitrary state using the state-oriented APIs such as getState and setState. When using such methods,the policy must specify where the state is to be kept. A policy may securely storestate in the metadata space within its capsule, in external secure storage, or at aremote server. If a policy communicates with a remote server, the networkingstack in the normal world kernel is used to initiate the connection. However, asthe OP-TEE OS includes the mbed TLS library [8], it is possible to safely make anHTTPS connection from the secure world without trusting the normal world.Ensuring data integrity: Our Lua policy provides APIs to retrieve the originaltrusted capsule data at file open (read) and the new trusted capsule data at file close(write). Using these APIs, data owners can express policies that, for example,protect specific data regions from being overwritten.Redaction: Selective policy-based disclosure of trusted capsule contents isa key feature of trusted capsules. Using our byte-oriented redaction API, dataowners can express arbitrary data transformations on regions of the data based onthe environment and the state of the device prior to disclosing information to thenormal world. Examples of data transformations include removing sensitive textsor blurring images.Revocation: A policy can specify revocation in two ways. First, we provide18APIs to allow policies to self-delete a trusted capsule. When the deleteCapsuleAPI is called, we overwrite the trusted capsule file with zeros1. We then make anRPC call into the normal world to delete the file and destroy the trusted capsuleapplication session. Such a revocation is permanent. Second, we allow retroactivepolicy changes via the remote capsule server. In this scenario, the policy specifiesa condition under which updatePolicy is called. If a new policy exists at the trustedcapsule server, it is downloaded by the trusted world and replaces the prior policy.Policy changes are temporary as the owner could always change the policy back.Logging: We extended the Lua language with the ability to report informationto the remote capsule server. To enable logging on open and close, log open andlog close flags must be set to true, respectively. By default, the Lua sandbox willreport the location, identity, time, and the operation. Additional local or capsulestate information is also logged, unless otherwise specified by the APIs append-ToBlacklist and removeFromBlacklist. The logs are written into the LOG sectionof the trusted capsule. If the section runs out of space, the logs are flushed to theremote server and then overwritten.4.3 Data monitorIn Figure 4.2, we illustrate the different components of the data monitor in oursystem and in Figure 4.3, we show a detailed data flow between them when anapplication opens a capsule. These components may be broadly classified into (1)framework code that runs in the normal world OS, and (2) a policy execution enginein the secure world. Next, we discuss each component in detail while referring tothe data flow in Figure 4.3.Normal world framework: We implemented a passthrough FUSE filesystemin the normal world and expose it as a separate mount point. When an applicationopens files located on this mount point, our framework will interpose on the ap-plication’s open syscall. It will check the header of the file to identify if it is acapsule. If it is a regular file, it will just load the raw file from the underlying filesystem and return it to the app.1This is because the Linux OS does not delete the file until the file’s reference count becomeszero19Application OP-TEE SupplicantFUSE FSVirtual FilesystemFUSE Kernel ObjectGPS & I/OOP-TEELinux DriverUserspaceOP-TEEOSOSSecureMonitorARM Trusted FirmwareSecure WorldNormal WorldTrusted CapsuleApplication PolicyEngineData CacheNetworkFigure 4.2: Trusted capsule data monitor design. Application system callsto the filesystem for accessing trusted capsules are intercepted and for-warded to the trusted capsule application through the FUSE filesystemand OP-TEE Linux Driver. The secure world trusted capsule applica-tions access peripheral I/O through RPC calls to the OP-TEE Supplicantvia the OP-TEE Linux Driver.Direct subsequent I/O to Shadow FileInvoke TA Command (e.g. CAPSULE_OPEN)Return from invoked TA commandI/O operationsFUSEApplication TrustedApplicationABNormal World TEE driverOP-TEEOSNative FSCInvoke TA CommandReturn decrypted dataReturn to normal worldRead encrypted capsuleReturn encrypted capsule contentsOpen( )EData CacheCreate shadow file FSecure Monitor CallEntry into OP-TEE OSDEvaluatePolicyLuaSandboxReturn shadow file handle to AppFigure 4.3: Trusted capsule monitor operation (shaded region operates in thesecure world). A. Application open system call is intercepted. B, C.FUSE identifies if a file is a capsule, and if so, invokes an RPC into thesecure world to decrypt the capsule. D. The trusted capsule application(TA) evaluates the open policy. E. FUSE writes the decrypted contentsto a shadow file F. The application is returned a filehandle to the shadowfile, and all subsequent I/O requests are directed to the shadow file.20If it is a capsule, the file contents are copied into a memory buffer. FUSEthen shares this buffer with the policy execution engine running inside the secureworld and invokes the engine’s decrypt function (A-C in Figure 4.3). If the policyauthorizes the access, the policy engine will return the decrypted contents of thecapsule and FUSE will save them into a shadow file (E). It will subsequently returna handle to this shadow file to the application (F). Hence, all reads and writes tothe capsule by the application will be transparently redirected to the shadow file.When the application closes the capsule, FUSE copies the shadow file backinto a shared buffer, sends it to the policy execution engine, and invokes the encryptoperation. This returns the reconstructed capsule, with the updated policy metadataand data contents (as authorized by the policy), which is then written in place ofthe original capsule file.Our framework prevents multiple applications from concurrently opening thesame capsule. This simplifies the design of our data monitor as we do not have toreason about multiple-reader/multiple-writer type problems when saving a capsule.An application may, however, have multiple capsules open.Policy execution engine: We implemented a Trusted Application (TA) thatruns in the secure world. It contains a Lua interpreter, to execute a capsule’s poli-cies, and it is responsible for maintaining the runtime session state associated witha capsule (e.g., cryptographic keys) and updating the capsule metadata.When a decrypt operation is received from the normal world (because a normalworld application used the open syscall on a capsule), a new instance of the trustedapplication is started. It (1) loads the capsule, (2) loads the cryptographic keys forthe capsule, (3) executes the policy, and (4) returns the decrypted capsule dataif authorized by the policy. During policy evaluation, it may communicate to aremote server directly from the secure world.On an encrypt operation (which is initiated because a normal world applicationused the close syscall to close a capsule), the TA evaluates the policy and pro-vides it the opportunity to allow or deny modifications to the capsule data. Next, itupdates the metadata, produces a new capsule file with updated contents in the datablock, and updates the integrity metadata in the header. Finally, the reconstructedcapsule is given to the normal world for storage and subsequent use.We use OP-TEE OS native secure storage capability to store our cryptographic21keys and persistent trusted capsule states. The cryptographic information is storedin serialized binary while trusted capsule states are stored in key-value format. Alltrusted capsule encryption keys are stored in a single secure key file. We allow thekey file to be accessible by multiple trusted capsule applications at a time so thatmultiple sessions can be instantiated simultaneously to handle different capsules.In contrast, each capsule gets its own secure state file. State files can only beopened by a single trusted capsule application at a time. This is enforced throughthe OP-TEE OS. In this way, we enforce a single trusted capsule instance at a timeper capsule.4.4 Security analysisWe consider two important security aspects of the Trusted Capsules data mon-itor.Trusted Capsules: Operations on the trusted capsule are performed by thetrusted application in the secure world. We isolate each trusted capsule by havingseparate instances of the trusted application handle each capsule and by relyingon OP-TEE OS to isolate each trusted application instance. Our system storespersistent state associated with capsules (such as cryptographic keys) in the securestorage functionality available in OP-TEE.Given our use of TrustZone, the confidentiality and integrity of the capsuledata is protected against compromises of the normal world OS, particularly in thepessimistic state. A compromised normal world OS may corrupt a capsule, but thatcorruption will be detected during decryption. In the worst case, a compromisedOS may leak the data of capsules that are open during the compromise.Policy Evaluation: To account for malicious policies, we made several changesto the Lua interpreter to make it a sandbox. We disabled any Lua library that al-lows the interpreter to interact with external systems (e.g., I/O, packages, debug,and OS). We also extended the interpreter to prevent policies from (1) interactingwith any files other than the capsule, (2) from accessing keys associated with othercapsules, and (3) reading unauthorized device peripherals. A malicious policy mayattempt denial-of-service attacks such as infinite loops. However, these may be ad-dressed even by the normal world, by canceling an encrypt or decrypt commands22that do not complete after some time.23Chapter 5Device Registration and KeyDistributionThere is also a need to register the devices on which the capsule can be accessedand created and simultaneously make known the users who are using these de-vices. This <user,device RSA pubkey, approved capsules > re-lationship is maintained on the remote server, and is queried when a user requestsdecryption of a capsule for which she does not have the decryption key.This access control relationship is developed over two steps - a user needs toregister his/her device and the capsule creator needs to create a list of users whoare approved to receive the decryption keys. We take a look at both of these stepsand then inspect the protocol followed to resolve a decryption request.5.1 Registering a Capsule RecipientThe process to register a user as a capsule recipient is outlined in figure 5.1.The user initiates a register call to the secure world with the email addressthey use to receive the capsule. The secure world at this point, looks up the securestorage to identify if it has a RSA public/private key pair saved. If it does not, theRSA key pair is generated.On receipt of the register request, the secure worldhandler initiates a TCP request to the remote server and passes the email addressand the RSA public key it fetched (or generated).24Normal World Secure World Server Database Gmailregister(email)register(email, pubkey)insert(email, pubkey, nonce)email(nonce’)okokokemail(nonce’)nw register device(email) okFigure 5.1: Registration as Recipient - intiating the registration processOn the receipt of this request, the remote server generates a nonce for this re-quest and inserts the <email, device RSA pubkey, nonce> tuple intoit’s database. Using the received RSA public key, the remote server encypts thegenerated nonce and sends an email to the users email address. This marks the firststep of the registration process.When the user receives the email with the encrypted nonce, the second part ofthe registration process can commence. This part of the process is used to vali-date that it was indeed the user who sent the registration request and establishesthe <email,device RSA pubkey> relationship. This process is detailed infigure 5.2.To begin the validation request, the user passes the received encrypted nonceand the email address to the secure world using the verify request. The se-cure world decrypts the nonce using the private RSA key that is held in the securestorage. Once the nonce has been decrypted, the secure world initiates a TCP con-nection to the remote server and passes the nonce, email address, and the deviceRSA public key for verifcation.25Normal World Secure World Server Databaseverify(nonce’, email)decrypt(nonce’, private key)nonceverify(nonce, email, pubkey)verify(nonce, email, pubkey)okokoknw verify device(nonce’, email)Figure 5.2: Registration as Recipient - validation of the requestThe remote server verifies that the email id and the nonce it had saved in thedatabase while creating the verification request. If the nonce, email, and the publickey all match, the tuple is persisted and an OK status is returned to the user.At the end of this process, the identity of the user is tied to the email addressand the device pair. This process can be repeated on any other devices a user owns.The <user,device RSA pubkey> relation is a unique key that is used toresolve all queries related to distributing a capsules keys.5.2 Capsule Generation and Key DistributionThe capsule generation process is outlined in figure 5.3. To create the capsule,the data owner transmits to the remote trusted server the data file, the policy (writ-ten in the policy API), and a list containing email addresses of people approvedto receive the decryption keys. On receiving the request, the remote server createsan 128 bit AES key and a randomly generated UUID. This UUID is added to thecapsule header.The header, the data file and the policy are merged and encrypted26User A User B Server Databasegen cap(file, policy, emails)gen aes()aeskeygen uuid()uuidcgen(aeskey, uuid, file, policy)okinsert(emails, aeskey, uuid)ok(ok, capsule)gen cap(file, policy, emails)Figure 5.3: Capsule Generation and Key Registrationusing the AES key that was generated.Once the encryption step is complete, the <UUID, AES key, approvedemail list > tuple is persisted to the database. At the end of this process, thecapsule thus created is returned to the user.Once the capsule creation step is complete, the data creator can send the cap-sule to the designated recipients. When a capsule recipient wishes to open thecapsule, a decryption process is triggered as illustrated in figure 5.4. The opencall to the capsule file is mediated through the FUSE filesystem, which initiatesa capsule open call to the secure world. On receiving the capsule openrequest, the Trusted Application searches secure storage for the AES key corre-sponding to the UUID found in the capsule header.If no AES key is found, the secure world initiates a lookup request to the remoteserver by sending a get key request with the caspule’s UUID and the secureworlds RSA public key. The remote server looks at the registered capsules and27User A NW User B NW User B SW Server Databasecapsuleopen(capsule)capsule open(capsule)get key(uuid, pubkey)verify uuid(uuid, pubkey)uuidis auth(uuid, pubkey)aeskey, okaeskey signed, okdecrypt(aeskey signed, pvtkey)aeskeydecrypt(aeskey, encrypted data)datadataopen(capsule)Figure 5.4: Capsule Decrypt as Recipientverifies that the RSA public key belongs to an approved user. If it does, it returnsthe AES key encrypted with the RSA public key received by the server in theget key request. On receiving the encrypted AES key from the remote server,the secure world uses it’s private RSA key to decrypt the capsules AES key. ThisAES key is used to decrypt the capsule and return the data to the normal world.28Chapter 6Use case examplesIn this section, we discuss several use cases to highlight the capabilities ofTrusted Capsules.Access control based on time or location: Enterprises may wish to restrictemployees from opening company files outside the office or a user may requirehis family members to view shared pictures only at their homes. Alternatively,the data owner may wish to allow access to sensitive content only within a pre-determined time period. Such requirements are straightforward to express in oursystem. When a capsule policy’s evaluate policy() function is evaluatedat the time of open(), it can access the device location and time 1 to decide ifthe access should be allowed or denied. Alternatively, instead of simply denyingaccess to a capsule, policies may use the redact() API in Table 4.1 to allowaccess but with sensitive content redacted.For example, Figure 6.1 illustrates a policy that denies access to the capsule ifthe location from which it is being accessed is outside the specified location range.Requiring permissions in real time: In some cases, users may wish to havereal-time control over their data. For example, Alvin may wish to be asked eachtime Barbara opens his capsule whether or not to allow her access. It is straight-forward to support this scenario in Trusted Capsules as policies can communicate1Information such as device location can only be trusted if the device driver is located withinTrustZone and the peripheral bus allows exclusive access to the sensors. There has been prior workthat achieves this. The Trusted Capsules prototype does not do this, and relies on the Normal WorldOS to provide this information. We leave this as future work.29with remote servers over the Internet.We implemented this scenario in our prototype using Twitter. When a useropens a capsule, the policy uses the getState() API method to communicatewith a custom server and passes the Twitter handle of the capsule owner. Theserver then sends a direct Twitter message to the owner of the capsule with anaccess request and asks him to respond with a “yes” or “no” to approve or declinethe access, respectively. The server returns the owner’s decision to the policy andthe appropriate action is taken. At the moment, the Twitter message to the ownerdoes not identify the user trying to open the capsule but this can be implementedby mapping unique device identifiers to Twitter handles.Progressive trust: The APIs in Table 4.1 may be composed to support otheruseful scenarios. Suppose Bob wants to share sensitive data with someone but doesnot yet completely trust that person. He can use a policy that contacts a remoteserver to log access attempts and to identify what data should be returned to theapp. Initially, Bob may choose to provide a heavily redacted version of the data(e.g., an image with blurred-out faces or a document with key sections removed).As his trust towards the person grows, he can progressively share more sensitivecontent by recording his decisions on the server.As an example of a policy with progressive trust, considers Figure 6.3 whichconsider content pre-distribution: a capsule creator writes this policy to pre-distributetheir content while ensuring that the content cannot be viewed until a pre-set re-lease date. For this use case, we rely on a trusted remote server for getting the time.Capsule metadata is first inspected using getState() to check if the content hasalready been approved for access by the policy. If this is indeed the first accessto the capsule, using the getTime() API, the remote server is contacted to getthe epoch value and it is compared to the epoch value in the policy. If the remoteepoch stamp is greater than the time encoded in the policy, the access is approved,and the metadata is updated using setState() to reflect this. Any subsequentaccesses to the capsule do not involve querying the remote server for getting thetime.Location based redaction: The policy as specified is fairly restrictive andblocks all access to the data contents outside a geographical range. There can bea scenario where the data owners wish to allow the partial revelation of the data in301 l o n g i t u d e = 12502 l a t i t u d e = 2003 r a n g e = 1045 f u n c t i o n e v a l u a t e p o l i c y ( op )6 i f op == POLICY OP OPEN or op == POLICY OP CLOSE then7 long , l a t , e r r = g e t L o c a t i o n ( POLICY LOCAL DEVICE )8 i f e r r ˜= POLICY NIL then9 comment = ” F a i l e d t o g e t L o c a t i o n ”10 re turn f a l s e11 end12 i f math.abs ( l ong − l o n g i t u d e ) <= r a n g e13 and math.abs ( l a t − l a t i t u d e ) <= r a n g e then14 comment = ”GPS c o o r d i n a t e s i n r a n g e ”15 re turn true16 e l s e17 comment = ”GPS c o o r d i n a t e s a r e n o t i n r a n g e ”18 re turn f a l s e19 end20 end21 endFigure 6.1: Simple location based access policylocations that are not trusted. To fulfill this requirement, the policy in Figure 6.1can be tweaked to allow redaction of data that is marked confidential by the creator.The data creator can encapsulate sensitive information in the data within somepolicy defined secrecy tags (for example: <secret> , </secret> can beused). The redact() API can be used in the policy to look for these tags andreplace the text contained therein with a replacement string. This policy is shownin Figure 6.2.311 r e p l a c e V a r = ”REDACTED”2 l o n g i t u d e = 12503 l a t i t u d e = 2004 r a n g e = 105 s t a r t T a g = ”<s e c r e t>”6 endTag = ”</ s e c r e t>”7 f u n c t i o n e v a l u a t e p o l i c y ( op )8 i f op == POLICY OP OPEN or op == POLICY OP CLOSE then9 long , l a t , e r r = g e t L o c a t i o n ( POLICY LOCAL DEVICE )10 i f e r r ˜= POLICY NIL then11 p o l i c y r e s u l t = POLICY NOT ALLOW12 comment = ” F a i l e d t o g e t L o c a t i o n ”13 re turn14 end15 i f math.abs ( l ong − l o n g i t u d e ) <= r a n g e16 and math.abs ( l a t − l a t i t u d e ) <= r a n g e then17 comment = ”GPS c o o r d i n a t e s i n r a n g e ”18 p o l i c y r e s u l t = POLICY ALLOW19 re turn20 e l s e21 comment = ”GPS c o o r d i n a t e s a r e n o t i n r a n g e . R e d a c t i n g d a t a . ”22 p o l i c y r e s u l t = POLICY NOT ALLOW23 end24 whi le s ˜= n i l and e ˜= n i l do25 s = s t r i n g . f i n d ( da t a , s t a r t T a g , s )26 i f s ˜= n i l then27 e = s t r i n g . f i n d ( da t a , endTag , s +1)28 i f e ˜= n i l then29 e r r = r e d a c t ( s , e , ” r e p l a c e V a r ” )30 i f e r r ˜= POLICY NIL then31 p o l i c y r e s u l t = e r r32 re turn33 end34 end35 end36 endFigure 6.2: Location based redaction policy321 −− remote s e r v e r i n f o r m a t i o n2 r e m o t e s e r v e r = ” 198 . 1 6 2 . 5 2 . 1 2 7 :3490 ”3 −− r e t u r n keywords4 p o l i c y r e s u l t = POLICY NOT ALLOW5 comment = ” ”67 −− p o l i c y−s p e c i f i c keywords8 o p e n t i m e = 15233380419 opened = ” opened ”1011 f u n c t i o n e v a l u a t e p o l i c y ( op )12 i f op == POLICY OP OPEN then13 r , e r r = g e t S t a t e ( opened , POLICY CAPSULE META )14 i f r == ” t r u e ” then15 re turn true16 e l s e17 c u r r t i m e , e r r = getTime ( POLICY REMOTE SERVER )18 end19 i f e r r ˜= POLICY NIL then20 p o l i c y r e s u l t = e r r21 comment = ” F a i l e d t o g e t t ime from remote s e r v e r ”22 re turn f a l s e23 end24 i f c u r r t i m e > o p e n t i m e then25 e r r = s e t S t a t e ( opened , ” t r u e ” , POLICY CAPSULE META )26 i f e r r ˜= POLICY NIL then27 p o l i c y r e s u l t = e r r28 comment = ” F a i l e d t o u p d a t e c a p s u l e m e t a d a t a ”29 re turn f a l s e30 end31 re turn true32 end33 end34 endFigure 6.3: Policy to allow content pre-distribution33Chapter 7PrototypeWe prototyped Trusted Capsules on a LeMaker HiKey development board [6].It has an octa-core ARM Cortex-A53 processor, 2 GB of RAM, 8 GB of flashstorage. and it comes with TrustZone unlocked, thereby allowing us to controlwhat OS runs on the TEE. We use Linaro OP-TEE OS (version 3.3) in TrustZoneand a HiKey Debian OS (based on Linux 4.4.15) in the normal world. We modifiedthe OP-TEE OS to implement several missing libc functions (such as atoi andstrcmp). As the HiKey board does not have a GPS receiver, we mocked a GPSdevice that returns predefined longitude and latitude values.Capsules are encrypted with 128-bit AES. We consider the distribution of keysrequired to decrypt capsules outside the scope of this paper.Our data monitor is written in C and consists of about 6.2K SLOC: the policyexecution engine, which runs within the TEE, has about 4.2K SLOC while thenormal world framework has 2K.7.0.1 Prototype EvolutionThe system design and the prototype evaluated in this paper has evolved froma previous design of the system. This prior system (“version-0”) had the ambitiousgoal of evaluating a Lua-based policy in TEE on all intercepted file I/O system callson a capsule file: open, close, read, write, and lseek. As well, Version-0revealed chunks of the file to normal world applications, rather than decrypting andrevealing the entire file contents on open. Version-0 was not based on FUSE, but34it used a custom system call interceptor in the normal world OS. This interceptorworked in a manner similar to the FUSE filesystem in our current designVersion-0 prototype was mature and stable, but had to be abandoned becauseof unacceptable application slowdown. This was due to the invasive nature of thesystem call handler that slowed down the behaviour of most applications that openand close many files at start-up.More concretely, the time to open a small document under a no-op policy withFUSE on our hardware is 24ms, while the latency in Version-0 was 1.2s. This is aspeed-up of 50x over Version-0.The latency and throughput gap dramatically increased for large and complexfile types, such as PDF JPEG. This can be observed in the raw video footage forseveral use-cases in Version-0 of the system: https://goo.gl/SiBEJB.We note that while overhead in Version-0 was significantly better at the ap-plication layer as compared to the system call layer, nevertheless, the cost wasprohibitive and was tightly connected to the policy being used. For example, ourMP4 video played smoothly with a null policy in VLC (which did not interact withthe trusted capsule server), but degraded to extreme jitter once we added a policythat reported actions to a policy coordinator and accessed secure storage for everyread operation. This effect was particularly acute for the PDF reader, which re-peatedly read the data in small chunks frequently and even when the user was idle.Each read by the PDF incurred the cost of a single round-trip to the trusted capsuleserver, requiring on average 5ms each.Our experiences with Version-0 of the Trusted Capsules prototype have beenour guiding principle in making our current system perform better. Our bench-marking results (presented in the next Section) indicate which the current TrustedCapsules design, that evaluates policy exclusively on open and close calls,strikes a better trade-off between security and performance.35Chapter 8EvaluationWe evaluated four aspects of our system: (1) the utility and simplicity of thepolicy language, (2) latency at the system call layer, and (3) the overhead associatedwith different policies. All performance evaluations were performed on our HiKeydevelopment board.8.1 Policy languageIn our policy language evaluation we aimed to answer two questions: is thepolicy language adequate for expressing useful policies? And, are these policieseasy to express?We answered our first question by writing trusted capsule policies for the ex-ample use-cases from Section 6. For our second question, we measured the LOCfor each policy that we wrote and show the result in Table 8.1.The ability to easily express complex policies tersely is important both as aproxy of simplicity and to bound the memory overhead of the Lua interpreter inthe secure world. We found that with a few lines of code we were able to ex-press complex time and location based policies1 for usecases such as redaction andrevocation.1Refer Chapter 9 for a discussion about extending the Policy API.36Policy LOCLocation Based Access (Fig 6.1) 30Location Based Redaction (Fig 6.2) 36Content Distribution (Fig 6.3) 28Table 8.1: LOC for example policies from Section 6.8.2 System call microbenchmarksIn considering system call level microbenchmarks, we focus on three questions.Are operations on regular files affected? We measured the latency of filesys-tem operations for a regular file and a capsule. Since our system is based on FUSE,we evaluate the performance of the Trusted Capsule system by comparing againstsystem call latencies for a regular file on the same mountpoint.We found that the performance of system calls on regular data is only affectedon open syscall. This is due to the overhead of checking whether the target file is atrusted capsule.What is the latency and throughput of the system calls we intercept for op-erations on trusted capsules? We measured the latency and throughput of syscalloperations on trusted capsules. For latency measurements, we measured the end-to-end time for a syscall and averaged over 1000 runs. For throughput measurements,we randomly read and wrote 4KB of data to a trusted capsule for 10 seconds. Toget an estimate of performance on the first use, we repeat the experiment with acold cache achieved by dropping the page cache. For each test trusted capsule, weattached an empty null policy that always evaluated to true. We present our resultsin Figure 8.1 and 8.2.The latency for open and close operations for a capsule present a prominentspike when compared to the operations on regular files. This is expected since ourcurrent prototype interposes on only these operations. An open operation on anull-policy capsule (warm cache) completes in 23 milliseconds compared to the11.7 milliseconds for a regular file. The close operation on a capsule completes in37102030 Capsule: cachingCapulse: no cachingRegular file: cachingRegular file: no cachingopen close read write lseek0.000.250.50Latencies (ms)Figure 8.1: Average system call latencyread write8101214161820Throughput (MB/sec)Capsule: cachingCapsule: no cachingRegular file: cachingRegular file: no cachingFigure 8.2: Throughput of Read and Write operations to a capsule144 microseconds as compared to 86 microseconds for a regular file.The observed latency spike is more pronounced for open than for close. Weunderstand this to be a direct result of the greater number of steps that have tohappen in TrustZone to initialize the Trusted Application, which do not need to bedone while servicing close call on a capsule.38We were able to achieve 17.59MB/s throughput for reading and 11.52MB/s through-put for writing to a no-op capsule on a warm cache. This is comparable to the read(17.6 MB/s) and write throughput (11.1 MB/s) achieved for a regular file when ac-cessed in the same experimental setup. When the same experiments were repeatedfor a cold cache, the throughput drops marginally.The read and write throughputs for a capsule, as compared to a normal file, wereexpected to be nearly identical. This is expected in our system since all reads andwrites to a capsule gets directed to a shadow file, which is treated like a regular filein FUSE.8.3 Policy Performance EvaluationIn this section we present our findings on the impact that policies of varyingcomplexity have on the performance of the system. To measure the overhead as-sociated with the policy execution, we compare the latency microbenchmarks foropen operations for a policy containing capsule, normalized with respect to the la-tency for opening a null-policy capsule. These results are presented in Figure 8.3.There is a sharp increase in the latency when there is a non-null policy being eval-uated, and this latency increases with the complexity of the policy.Redaction Time based redaction051015Normalized OverheadFigure 8.3: Normalized latency of servicing an open for different policieswith respect to the latency to service a null-policy capsule open request.39Figure 8.3 compares two policies: a redaction policy that redacts sensitive tagswithout performing other checks and a local time based redaction policy, whichperforms redaction based on the epoch value obtained from the device. The redac-tion policy uses the redact() API from Table 4.1, while the Time based redactpolicy uses the redact()API as well as well as the getTime()API. This extrawork to service an open request is evident from Figure 8.3.We believe that such performance degradation can be mitigated with more effi-cient policy code, for example policies that run at coarser granularity or use cachingto mitigate expensive checks.40Chapter 9LimitationsNow we turn to discuss the design limitations of Trusted Capsules. In thissection, we cover the limitations imposed by our design choices and the limitationsimposed by the specific choice of software and hardware. Then later on, in Chapter10, we take a gander at why Trusted Capsules remains a rather naive attempt atsolving the problem of retrofitting existing applications with security extensions.9.1 Design Limitations1. Inability to limit trust in optimistic state: In the optimistic state, we trustthe normal world kernel, the app, and the user, to not leak capsule datato unauthorized apps. Such trust may not be warranted even in a non-adversarial setting. For example, an app might create temporary copies ofthe files it has opened into a world-readable directory or the user might copythe data into the system clipboard. While we may use techniques such as in-formation flow control to detect such data leaks, doing so would dramaticallyreduce performance.2. Lack of app semantics: Since we interpose only on the open() and close()syscalls to execute policies, a policy may not reason about why an app isopening a file. For example, when a user opens a document in a vim, vimopens the document, creates a swap file, copies the contents of the docu-ment to the swap file, and then closes the document. All subsequent reads41and writes are done to the swap file thereafter. On close, the original fileis opened again, the contents of the swap file are copied back to the maindocument, and the main file is closed and the swap file deleted.Hence, while from a user’s perspective, the capsule was opened once andclosed once, the policy would observe multiple capsule access attempts.This makes it difficult to identify the legitimate accesses from the applicationquirks. The data monitor handles Policies that rely on access logs have to beaware of this disconnect.3. Abusive policies: Although we run capsule policies in a sandbox, we donot completely prevent all damage a malicious policy can inflict. It can,for example, access a user’s GPS data and send them to a server to trackher whereabouts. To handle this limitation, we either need some systematicway of vetting the data a policy sends to a remote server or prevent it fromsending device data altogether.4. Trusting actions from untrusted OS: In our design, the signal (open()and close() ) to the TEE to decrypt a capsule originates in the untrustedpart of the system. The TEE cannot differentiate between genuine accessand similar access requested by a malicious application.Trusting the actions originating in the normal world dilutes the guarantees wemake about the transition from the pessimistic state to the optimistic state ofour threat model. Moreover, trusting the normal world invalidates the needto use a TEE for secure processing of a Trusted Capsule.9.2 Prototype Limitations:In this section, we list the limitations that bound the current prototype fromrealizing the full vision of the Trusted Capsule model of data protection. Here wenote some design and implementation limitations.1. FUSE can be used interpose on only the file I/O system calls that are directedto a FUSE serviced mount point. This poses some challenges in makingTrusted Capsules work seamlessly with an unmodified application.42There is no way for the FUSE filesystem code to identify when a process thathad been issuing IO to the mount point dies. The implication of this fact forthe prototype is that there is no good and atomic way to delete the shadowfile on the termination of the process. The prototype handles this by settingup a background process that monitors if the process that had accessed themount point has terminated.2. The stock configuration for the TrustZone memory partitions makes the Se-cure World a very memory-constrained environment. The memory that isavailable in the secure world is only 10 MB, and that needs to host the Se-cure OS as well as any trusted application code that must run in Trustzone.Linaro OP-TEE recently included dynamic shared memory in their SecureOS, but to access those features, one has to have a higher kernel versionthan what gets shipped with the stock Debian OS rootfs image. More recentLinux kernel versions have known problems with the HDMI drivers, whichcauses the Linux kernel to panic when a monitor is plugged in.This limitation hits our prototype particularly badly. In the current prototype,we send a copy of the entire file to TrustZone to decrypt. Since there aresevere restrictions on the amount of memory available in TrustZone, we areunwittingly bounded on the maximum file size that can be processed as acapsule.3. The implementation has a limitation that it needs to create copies of thedata buffers to process each part of the capsule. This creates more memorypressure in an already resource-constrained environment.4. The Policy API is currently limited to policies that require access to localtime and the GPS coordinates (ideally, the GPS driver should run in the TEEOS). To support policies that rely on other signals and/or sensors will re-quire adding the device driver, writing the interfacing code in the trustedapplication, and updating the Lua-to-C bindings. This is a well-defined al-beit convoluted workflow that makes it harder to make the policy languagemore flexible.43Chapter 10Securing ApplicationsTrustZone was first announced in the year 2004 [13], and has since been usedfor a diverse range of applications as can be seen in section 11. Some of these appli-cations target new use-cases that can benefit from the guarantees a TEE provides,while in other cases, pre-existing applications are re-structured and re-factored tomake use of a TEE. How these projects structure their secure applications differbased on the information being protected and the threat model around which theapplication has been designed. We first investigate the patterns in prior work, andthen analyse why these are not the right fit for Trusted Capsules.10.1 Modifying Applications to Use a TEEWe begin by inspecting how prior research in the space of TEE-enabled secu-rity have structured their applications. We have identified four distinct patterns thatprior research has taken in trying to structure their secure applications, and theseevolve based on the threat model that the application is being designed to protectagainst.1. Manually Split the Application into Trusted and Untrusted Parts: Thisis the most commonly used methodology designing applications with theview to use a TEE to safeguard some aspect of the program state [14, 46, 59,62].The basic idea is that there is some easily identifiable functionality that can44Application AUntrustedApplication A'SecureApplication A"TEEUntrusted OSInvoke Secure FuncFigure 10.1: An application can be split into two parts - one that resides inthe untrusted operating system and has the interfaces to secure func-tionality that resides in the trusted environment.be plucked out of the monolithic application and can be offloaded to theTEE. The rest of the application that remains on the untrusted OS only hasinterfaces to the secure functions in the TEE. This is shown in Figure 10.1.The TEE in this scenario could either be a trusted operating system that ishosted as a virtual machine or it could be a more conventional hardware-based TEE like Intel’s SGX or ARM’s TrustZone.This application splitting paradigm is promising in scenarios where the crit-ical functionality that needs protection is small, well defined, and can be ex-tracted out into a TEE-resident service. Prime examples of this are biometricverification, cryptographic functions, payment processing, and verifying theuser’s action and intent. An implicit assumption with this strategy is that thepartitioning of the application is a deliberate decision that is made at the timeof designing the application and therefore can not be used for an unmodified45ApplicationsVirtual Ghost VMNative Instruction SetUntrusted OS KernelProcessorVirtual Instruction SetApplicationsUntrusted OS KernelProcessorFigure 10.2: Virtual Ghost uses LLVM to create an intermediate layer the OSand the processor to protect the application from the unfettered accessotherwise enjoyed by a kernelapplication.2. Compiler Supported Application Sequestering: There has been work insecuring application using compiler wizardry. VirtualGhost [19] defines acompiler-based instrumentation of the kernel and the application to protectthe applications data confidentiality and integrity. The OS is compiled to avirtual instruction set which is handled by the Virtual Ghost VM as shown inFigure 10.2. This “virtual machine” is used to limit the accesses the kernelhas into the state of the application. This is an interesting work that providesstrong guarantees about the application’s integrity and data confidentialitywithout using a hardware-based TEE.There has been work in automatically identifying which parts of the appli-cation need to be protected and splitting the application using the TEE API[44, 56]. This approach involves using static analysis and dataflow analy-sis along with optional annotations in the program to automatically identifythe partitioning scheme, and then refactoring the application into two partsthat are bridged using the TEE API. Programming language theory can beused to demonstrate equivalence between the split halves and the originalapplication.These approaches might be an efficient way to retroactively make an unmod-ified application ready for a TEE.3. Complete Isolation of the Application Inside the Secure World This ap-proach is, in theory, the path of least resistance to use a TEE. There have been46some projects that try to contain an entire application in the TEE - Graphene[63, 64] and TrustShadow [27], for example. These systems rely on theTEE to make available all services that the application might require - mostimportantly the I/O and peripheral access and the system call interface. Thisapproach, while promising, is fraught with its own set of problems. TEE’sare a restrictive execution environments - Intel SGX, for example, does notprovide access to a system call interface. No application running in SGXis allowed to make a system call. Similarly, in TrustZone and specificallyOP-TEE, because the TEE OS is minimalist, it is difficult to support a full-fledged application.Graphene [64] provides good insight into the TEE software design space.While designing any secure application, the developer has to decide between- pulling too much functionality into the TEE vs keeping the Trusted Com-pute Base minimal and simplifying the application to require lesser of theruntime vs making a rich run time; application changes to make it moreamenable to the TEE runtime. These are challenging choices to make andrely not on the application but the baseline runtime he/she is working with.4. System Call Interception If the complete isolation of an application isnot possible, and it is necessary to maintain some part of the application inthe untrusted OS, the most enticing option available to the security engineeris to use system call interception in the normal world OS and handle the“sensitive” accesses to data and the network in the TEE. This approach cango awry if there is not a strict control on the number and type of systemcalls that are handled in the TEE - the more elaborate the handler in theTEE, the higher will be the slowdown, and less usable will be the system.TrustedCapsule’s first prototype was overly ambitious in the amount of workthat was being done on every single system call to a capsule file, causing insome cases a 300x slowdown on simple tasks such as opening a capsule.4710.2 Securing Unmodifed ApplicationsWhile the TEE OS can be extended to include all the services that a rich ap-plication would provide, it defies the rationale behind having a small trusted com-puting base. This limits the range of applications that are a good fit for runningin the TEE. Applications that are computation heavy and need little or no I/Oare good fits for this - Machine Learning tasks [52] and Cryptography and keymanagement[4, 12].For applications that have to run I/O to be useful - which is a lot of user-centric applications such as word-processing systems, image viewers and othersuch interactive applications. These interactive applications have their utility inrevealing information to the user and allowing the user interact with the data ondemand. When the user interaction is an indispensable part of the application andits utility, none of the application structuring schemes lead to completely satisfyingoutcomes. This problem is exacerbated when the TEE usage is provided as anoverlay scheme atop an existing application to provide backward compatibility andease of deployment1.These secure overlay schemes do not align with any application structuringmethodologies that researchers have come up with. Supporting a full-fledged ap-plication is difficult because there are a lot of quirks that need to addressed and atthe same time, the technique needs to be generic enough to support a wide range ofapplications. The goal of keeping the interface generic and the application unmod-ified limits the security guarantees that can be made. For example, in the case ofTrustedCapsules, because the application still receives all the decrypted data backfrom TrustZone, there can be no further guarantees made after the first file accessfrom the normal world. Moreover, the policy engine in the secure world needs toreason about the state of the normal world, which is problematic because such in-formation is gleaned from the normal world. A malicious normal world user couldfake these state values (for example, the GPS coordinates) while requesting thedecryption, and because the policy engine relies on the veracity of these signals, itcould be tricked into incorrect policy evaluation.1The FUSE-based interception scheme is an overlay on top of regular file access that unmodifiedapplications perform. Using such an overlay scheme has an advantage that it doesn’t require a specialfile viewer for a capsule file and provides a better user experience.48If we place trust in the normal world, we don’t need a TEE. If we don’t im-plicitly trust the normal world, then the data should never be revealed back to thenormal world. This cyclical conundrum can only be resolved by refactoring theapplication in a way that uses the TEE by following the design patterns mentionedearlier in section 10.1.49Chapter 11Related WorkSecuring data with policies: The concept of associating policies to data withauthenticate accesses to that data is not new. An early expression of this is XACL,which specifies access control policies within XML documents [28]. Karjoth etal. proposed using sticky policies to provide enterprises better oversight over thecustomer data they collect [34]. These policies capture customer-specified require-ments (e.g.: “delete my data after 30 days”) and are associated with the collecteddata. They are then enforced cooperatively within the enterprise as the data is used.Subsequent work strengthened this scheme by encrypting the data bundled with thepolicy using IBE (identifier-based encryption) and decrypting it only if its policiesare satisfied [50, 53]. Encrypting the data reduces the need for cooperation andallows sharing data across enterprise boundariesManiatis et al. outlined a vision that allows all users to protect their data beforethey share them across machine boundaries [48]. Their conceptual architectureuses the sticky policy approach to package data in units known as data capsules.When an application needs to use a capsule and satisfies the capsule’s policies,an abstract secure execution environment decrypts the capsule and executes theapplication. An implementation of this architecture was left as an open question.More recent works use trusted computing features on mobile devices to pro-tect data with the sticky policy approach. Li et al. proposed DroidVault to allowemployees in an enterprise to securely store and process sensitive company dataon their untrusted Android devices [43]. Its architecture only allows trusted code50signed by the enterprise to operate on the data and executes it in ARM TrustZone.To display data and receive user inputs, it relies on secure I/O between the periph-erals (display, keypad, etc.) and TrustZone. This architecture ensures unencryptedversions of the sensitive data do not leave the TrustZone environment. Lazouskiet al. proposed using TPMs (Trusted Platform Modules) to ensure only vetted ver-sions of the OS and applications are loaded before accessing sensitive data andexecuting their policies [39]. In principle, this approach allows policy executionand data access in the normal world (outside TrustZone) while guaranteeing theabsence of malicious applications.Other related works in this area include Excalibur, which enables a cloudprovider to protect data stored in its cloud from being exfiltrated by its admin-istrators who have access to the cloud management interface [58]; PCD (policy-carrying data), which lets an end-user attach terms of service to his data beforesharing it cloud service providers and thereby disincentivizing them from misus-ing the data [60]; Ryoan, which enables users to submit their sensitive data to acloud service provider for processing without requiring either the user to disclosethe data or for the provider to release their proprietary code [31]; and P3, a privatephoto-sharing service that protects images shared by users from untrusted serviceproviders [54].Trusted Capsules differs from these in its aim and scope: it uses the sticky pol-icy technique to allow end-users to protect their data as they share it with other endusers and unlike P3, it is data type agnostic. While Trusted Capsules uses ARMTrustZone to securely execute the policies, it allows unvetted normal world pro-cesses to access unencrypted sensitive data in the optimistic state (unlike Droid-Vault and the work by Lazouski et al.). Our approach is motivated by usabilityconcerns as we want authorized users to be able to use their desired third-partyapps to process sensitive data.There are now startups that have emerged as players in the domain of providingdata security systems. A startup called Sandstorm [9] abstracts data as a grain –a package of all the apps, libraries, and configuration files needed to operate on asingle piece of data locally within a container. Sandstorm then creates an enclosurearound the container and interposes on all operations to enforce the grain’s accesspolicies. Unlike trusted capsules, which operates at the granularity of a piece of51data, Sandstorm operate at the granularity of an entire software ecosystem for thedata.Information Flow Control based mechanisms: There has also been a vastbody of research that studies providing data confidentiality through label-basedsolutions such as Distributed Information Flow Control [18, 21, 38, 51, 55, 66, 67].They use labels to specify access control, capabilities, and authority. These labelsare used to track the flow of information at various levels of the software stack.By not allowing data to move to processes that do not have the right labels,DIFC prevents sensitive data from being exfiltrated.In DIFC, labels create a natural ecosystem for composition that allows a pro-cess to access multiple pieces of data. Trusted capsules are less composable. If twotrusted capsules have contradictory policies, they cannot be accessed by a processat the same time. On the other hand, trusted capsules are backward compatible anddo not require constructing a complex security lattice as in DIFC.Another popular approach is tainting [23, 24, 30, 68]. It tracks informationflow by interposing on the system operations at the instruction-level. These solu-tions can track the flow of information at an extremely fine granularity. resource-intensive, both in memory and CPU.Policy Based Isolation Mechanisms: Traditional isolation-based solutions re-main one of the most widely used practical solutions currently to provide dataprotection. These solutions, such as VPN, VMWare Ace [1], Secure Spaces [10]and Hypori [7], attempt to prevent sensitive data from leaving in the first place byenforcing policy at the network boundary between external and internal systems.In these cases, policies that restrict the movement of sensitive data can still bedefeated by transformations, such as encryption and compression. Also, some ofthese solutions incur substantial network cost as they do not support offline opera-tions.Finally, other work has sought to ensure data confidentiality by enforcing ap-plication structures [29, 40], limiting data lifetimes [20, 33] and providing recourseactions such as backtracing intrusions [25, 35].Other TEE work: The research community has used TEEs such as ARMTrustZone and Intel SGX for a variety of purposes - to provide a secure environ-ment for running VMs, secure partitions or executing parts of third-party applica-52tions and to store their data [22, 37, 59], to provide a root-of-trust for performingruntime measurements [15–17, 61] and to secure peripherals [47]. In general,these are orthogonal to Trusted Capsules.VButton uses TrustZone to attest whether the UI inputs on the smartphonewere initiated by the user [42]; SeCloak provides direct control (on/off) over de-vice peripherals even when the normal world OS is compromised [41]; Truz-Droidenables users to securely input and send secrets e.g., login credentials, to autho-rized servers without executing third-party code in TrustZone [65]; TrustShadowprotects applications from untrusted OSes by executing them with a runtime inTrustZone [26]; and SchrodinText allows the untrusted normal world OS to rendersensitive text in the display received from an application backend server withoutrevealing the contents of the text [57]; DelegaTEE, which uses Intel SGX to en-able users to share their access to online service providers without revealing theircredentials [49].53Chapter 12ConclusionData security on remote devices that the data owner cannot control representsa unique challenge in our data promiscuous world. Systems exchange data indis-criminately and do not offer the data owner any ability to control access policy onremote devices. At best, data is encrypted to prevent declassification.We introduced graduated access control and realized it using a trusted capsuleabstraction and a data monitor that runs inside ARM’s TrustZone trusted executionenvironment. Our solution builds on the file abstraction and does not require anymodification to applications, is gradually deployable, and can be ported to otherkinds of trusted execution environments.54Bibliography[1] About VMware ACE.https://www.vmware.com/support/ace/doc/whatsnew ace.html. Accessed:2016-11-26. → page 52[2] Arm trusted firmware.https://github.com/ARM-software/arm-trusted-firmware. Accessed:2019-02-15. → page 8[3] Cryptomator - free cloud encryption. =https://cryptomator.org/. → page 1[4] Security solutions based on runtime encryption R© platform.=https://fortanix.com/solutions/. → page 48[5] Global platform api specifications. http://www.globalplatform.org/.Accessed: 2019-02-15. → page 9[6] LeMaker HiKey. http://www.lemaker.org/product-hikey-index.html. →pages 6, 34[7] Hypori. http://www.hypori.com/. Accessed: 2019-02-15. → page 52[8] ARM mbed TLS. https://tls.mbed.org. → page 18[9] Sandstorm. https://sandstorm.io/. Accessed: 2019-02-15. → page 51[10] Secure spaces. https://www.spacesmobile.com/. Accessed: 2019-02-15. →page 52[11] When does snapchat delete snaps and chats?=https://support.snapchat.com/en-GB/article/when-are-snaps-chats-deleted.→ page 1[12] Web cryptography api. =https://www.w3.org/TR/WebCryptoAPI/. → page4855[13] T. Alves and D. Felton. Trustzone: Integrated hardware and softwaresecurity. ARM white paper, 3(4):18–24, 2004. → pages 4, 44[14] A. Amiri Sani. Schrodintext: Strong protection of sensitive textual contentof mobile applications. In Proceedings of the 15th Annual InternationalConference on Mobile Systems, Applications, and Services, MobiSys ’17,pages 197–210, New York, NY, USA, 2017. ACM. ISBN978-1-4503-4928-4. doi:10.1145/3081333.3081346. URLhttp://doi.acm.org/10.1145/3081333.3081346. → page 44[15] A. M. Azab, P. Ning, J. Shah, Q. Chen, R. Bhutkar, G. Ganesh, J. Ma, andW. Shen. Hypervision across worlds: Real-time kernel protection from thearm trustzone secure world. In Proceedings of the 2014 ACM SIGSACConference on Computer and Communications Security, pages 90–102.ACM, 2014. → page 53[16] A. M. Azab, K. Swidowski, J. M. Bhutkar, W. Shen, R. Wang, and P. Ning.Skee: A lightweight secure kernel-level execution environment for arm.2016.[17] F. Brasser, D. Kim, C. Liebchen, V. Ganapathy, L. Iftode, and A.-R. Sadeghi.Regulating arm trustzone devices in restricted spaces. In Proceedings of the14th Annual International Conference on Mobile Systems, Applications, andServices, pages 413–425. ACM, 2016. → page 53[18] W. Cheng, D. R. Ports, D. Schultz, V. Popic, A. Blankstein, J. Cowling,D. Curtis, L. Shrira, and B. Liskov. Abstractions for usable information flowcontrol in aeolus. In Presented as part of the 2012 USENIX AnnualTechnical Conference (USENIX ATC 12), pages 139–151, 2012. → page 52[19] J. Criswell, N. Dautenhahn, and V. Adve. Virtual ghost: Protectingapplications from hostile operating systems. In ACM SIGPLAN Notices,volume 49, pages 81–96. ACM, 2014. → page 46[20] A. M. Dunn, M. Z. Lee, S. Jana, S. Kim, M. Silberstein, Y. Xu,V. Shmatikov, and E. Witchel. Eternal sunshine of the spotless machine:Protecting privacy with ephemeral channels. In Presented as part of the 10thUSENIX Symposium on Operating Systems Design and Implementation(OSDI 12), pages 61–75, 2012. → page 52[21] P. Efstathopoulos, M. Krohn, S. VanDeBogart, C. Frey, D. Ziegler,E. Kohler, D. Mazieres, F. Kaashoek, and R. Morris. Labels and event56processes in the asbestos operating system. In ACM SIGOPS OperatingSystems Review, volume 39, pages 17–30. ACM, 2005. → page 52[22] J.-E. Ekberg, N. Asokan, K. Kostiainen, and A. Rantala. Schedulingexecution of credentials in constrained secure environments. In Proceedingsof the 3rd ACM workshop on Scalable trusted computing, pages 61–70.ACM, 2008. → page 53[23] W. Enck, P. Gilbert, S. Han, V. Tendulkar, B.-G. Chun, L. P. Cox, J. Jung,P. McDaniel, and A. N. Sheth. Taintdroid: an information-flow trackingsystem for realtime privacy monitoring on smartphones. ACM Transactionson Computer Systems (TOCS), 32(2):5, 2014. → page 52[24] A. Ermolinskiy, S. Katti, S. Shenker, L. Fowler, and M. McCauley. Towardspractical taint tracking. EECS Department, University of California,Berkeley, Tech. Rep. UCB/EECS-2010-92, 2010. → page 52[25] A. Goel, K. Po, K. Farhadi, Z. Li, and E. De Lara. The taser intrusionrecovery system. In ACM SIGOPS Operating Systems Review, volume 39,pages 163–176. ACM, 2005. → page 52[26] L. Guan, P. Liu, X. Xing, X. Ge, S. Zhang, M. Yu, and T. Jaeger.TrustShadow: Secure Execution of Unmodified Applications with ARMTrustZone. In Proceedings of MobiSys ’17, June 2017. → page 53[27] L. Guan, P. Liu, X. Xing, X. Ge, S. Zhang, M. Yu, and T. Jaeger.Trustshadow: Secure execution of unmodified applications with armtrustzone. arXiv preprint arXiv:1704.05600, 2017. → page 47[28] S. Hada and M. Kudo. XML Access Control Language: ProvisionalAuthorization for XML Documents.http://xml.coverpages.org/xacl-spec200102.html. → page 50[29] R. Herbster, S. DellaTorre, P. Druschel, and B. Bhattacharjee. Privacycapsules: Preventing information leaks by mobile apps. In Proc. of MobiSys,2016. → page 52[30] A. Ho, M. Fetterman, C. Clark, A. Warfield, and S. Hand. Practicaltaint-based protection using demand emulation. In ACM SIGOPS OperatingSystems Review, volume 40, pages 29–41. ACM, 2006. → page 52[31] T. Hunt, Z. Zhu, Y. Xu, S. Peter, and E. Witchel. Ryoan: A DistributedSandbox for Untrusted Computation on Secret Data. In Proceedings ofOSDI ’16, November 2016. → page 5157[32] M. B. D. T. Joakim Bech, Ard Biesheuvel. Implications of meltdown andspectre : Part 2, Feb 2018. → page 6[33] J. Kannan and B.-G. Chun. Making programs forget: Enforcing lifetime forsensitive data. In HotOS, 2011. → page 52[34] G. Karjoth, M. Schunter, and M. Waidner. Platform for Enterprise PrivacyPractices: Privacy-enabled Management of Customer Data. In Proceedingsof PET ’02, April 2002. → page 50[35] S. T. King and P. M. Chen. Backtracking intrusions. ACM SIGOPSOperating Systems Review, 37(5):223–236, 2003. → page 52[36] P. Kocher, J. Horn, A. Fogh, , D. Genkin, D. Gruss, W. Haas, M. Hamburg,M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom. Spectreattacks: Exploiting speculative execution. In 40th IEEE Symposium onSecurity and Privacy (S&P’19), 2019. → page 6[37] K. Kostiainen, J.-E. Ekberg, N. Asokan, and A. Rantala. On-boardcredentials with open provisioning. In Proceedings of the 4th InternationalSymposium on Information, Computer, and Communications Security, pages104–115. ACM, 2009. → page 53[38] M. Krohn, A. Yip, M. Brodsky, N. Cliffer, M. F. Kaashoek, E. Kohler, andR. Morris. Information flow control for standard os abstractions. In ACMSIGOPS Operating Systems Review, volume 41, pages 321–334. ACM,2007. → page 52[39] A. Lazouski, F. Martinelli, P. Mori, and A. Saracino. Stateful Usage Controlfor Android Mobile Devices. In Proceedings of STM ’14, September 2014.→ page 51[40] S. Lee, D. Goel, E. L. Wong, A. Kadav, and M. Dahlin. Privacy preservingcollaboration in bring-your-own-apps. In Proceedings of the Seventh ACMSymposium on Cloud Computing, SoCC ’16, pages 265–278, New York,NY, USA, 2016. ACM. ISBN 978-1-4503-4525-5.doi:10.1145/2987550.2987587. URLhttp://doi.acm.org/10.1145/2987550.2987587. → page 52[41] M. Lentz, R. Sen, P. Druschel, and B. Bhattacharjee. SeCloak: ARMTrustzone-based Mobile Peripheral Control. In Proceedings of MobiSys ’18,June 2018. → page 5358[42] W. Li, S. Luo, Z. Sun, Y. Xia, L. Lu, H. Chen, B. Zang, and H. Guan.VButton: Practical Attestation of User-driven Operations in Mobile Apps.In Proceedings of MobiSys ’18, June 2018. → page 53[43] X. Li, H. Hu, G. Bai, Y. Jia, Z. Liang, and P. Saxena. DroidVault: A TrustedData Vault for Android Devices. In Proceedings of ICECCS ’14, August2014. → pages 1, 50[44] J. Lind, C. Priebe, D. Muthukumaran, D. O’Keeffe, P.-L. Aublin, F. Kelbert,T. Reiher, D. Goltzsche, D. Eyers, R. Kapitza, et al. Glamdring: Automaticapplication partitioning for intel {SGX}. In 2017 {USENIX} AnnualTechnical Conference ({USENIX}{ATC} 17), pages 285–298, 2017. →page 46[45] M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, A. Fogh, J. Horn,S. Mangard, P. Kocher, D. Genkin, Y. Yarom, and M. Hamburg. Meltdown:Reading kernel memory from user space. In 27th USENIX SecuritySymposium (USENIX Security 18), 2018. → page 6[46] D. Liu and L. P. Cox. Veriui: Attested login for mobile devices. InProceedings of the 15th Workshop on Mobile Computing Systems andApplications, page 7. ACM, 2014. → page 44[47] H. Liu, S. Saroiu, A. Wolman, and H. Raj. Software abstractions for trustedsensors. In Proceedings of the 10th international conference on Mobilesystems, applications, and services, pages 365–378. ACM, 2012. → page 53[48] P. Maniatis, D. Akhawe, K. Fall, E. Shi, and D. Song. Do You Know WhereYour Data Are? Secure Data Capsules for Deployable Data Protection. InProceedings of HotOS ’11, May 2011. → page 50[49] S. Matetic, M. Schneider, A. Miller, A. Juels, and S. Capkun. DelegaTEE:Brokered Delegation Using Trusted Execution Environments. InProceedings of USENIX Security ’18, August 2018. → page 53[50] M. C. Mont, S. Pearson, and P. Bramhall. Towards AccountableManagement of Identity and Privacy: Sticky Policies and EnforceableTracing Services. In Proceedings of DEXA Workshop ’03, September 2003.→ page 50[51] A. C. Myers and B. Liskov. Protecting privacy using the decentralized labelmodel. ACM Transactions on Software Engineering and Methodology(TOSEM), 9(4):410–442, 2000. → page 5259[52] O. Ohrimenko, F. Schuster, C. Fournet, A. Mehta, S. Nowozin, K. Vaswani,and M. Costa. Oblivious multi-party machine learning on trusted processors.In 25th {USENIX} Security Symposium ({USENIX} Security 16), pages619–636, 2016. → page 48[53] S. Pearson and M. C. Mont. Sticky Policies: An Approach for ManagingPrivacy across Multiple Parties. IEEE Computer, 44(9):60–68, 2011.doi:10.1109/MC.2011.225. URL https://doi.org/10.1109/MC.2011.225. →page 50[54] M.-R. Ra, R. Govindan, and A. Ortega. P3: Toward privacy-preservingphoto sharing. In Proceedings of NSDI ’13, April 2013. → page 51[55] I. Roy, D. E. Porter, M. D. Bond, K. S. McKinley, and E. Witchel. Laminar:practical fine-grained decentralized information flow control, volume 44.ACM, 2009. → page 52[56] K. Rubinov, L. Rosculete, T. Mitra, and A. Roychoudhury. Automatedpartitioning of android applications for trusted execution environments. In2016 IEEE/ACM 38th International Conference on Software Engineering(ICSE), pages 923–934. IEEE, 2016. → page 46[57] A. A. Sani. SchrodinText: Strong Protection of Sensitive Textual Content ofMobile Applications. In Proceedings of MobiSys ’17, June 2017. → page 53[58] N. Santos, R. Rodrigues, K. P. Gummadi, and S. Saroiu. Policy-Sealed Data:A New Abstraction for Building Trusted Cloud Services. In Proceedings ofUSENIX Security ’12, August 2012. → page 51[59] N. Santos, H. Raj, S. Saroiu, and A. Wolman. Using arm trustzone to build atrusted language runtime for mobile applications. In ACM SIGARCHComputer Architecture News, volume 42, pages 67–80. ACM, 2014. →pages 44, 53[60] S. Saroiu, A. Wolman, and S. Agarwal. Policy-Carrying Data: A PrivacyAbstraction for Attaching Terms of Service to Mobile Data. In Proceedingsof HotMobile ’15, February 2015. → page 51[61] A. Seshadri, M. Luk, N. Qu, and A. Perrig. Secvisor: A tiny hypervisor toprovide lifetime kernel code integrity for commodity oses. In ACM SIGOPSOperating Systems Review, volume 41, pages 335–350. ACM, 2007. →page 5360[62] R. Ta-Min, L. Litty, and D. Lie. Splitting interfaces: Making trust betweenapplications and operating systems configurable. In Proceedings of the 7thSymposium on Operating Systems Design and Implementation, OSDI ’06,pages 279–292, Berkeley, CA, USA, 2006. USENIX Association. ISBN1-931971-47-1. URL http://dl.acm.org/citation.cfm?id=1298455.1298482.→ page 44[63] C.-C. Tsai, K. S. Arora, N. Bandi, B. Jain, W. Jannen, J. John, H. A.Kalodner, V. Kulkarni, D. Oliveira, and D. E. Porter. Cooperation andsecurity isolation of library oses for multi-process applications. InProceedings of the Ninth European Conference on Computer Systems,EuroSys ’14, pages 9:1–9:14, New York, NY, USA, 2014. ACM. ISBN978-1-4503-2704-6. doi:10.1145/2592798.2592812. URLhttp://doi.acm.org/10.1145/2592798.2592812. → page 47[64] C.-C. Tsai, D. E. Porter, and M. Vij. Graphene-sgx: A practical library{OS} for unmodified applications on {SGX}. In 2017 {USENIX} AnnualTechnical Conference ({USENIX}{ATC} 17), pages 645–658, 2017. →page 47[65] K. Ying, A. Ahlawat, B. Alsharifi, Y. Jiang, P. Thavai, and W. Du.TruZ-Droid: Integrating TrustZone with Mobile Operating System. InProceedings of MobiSys ’18, June 2018. → page 53[66] N. Zeldovich, S. Boyd-Wickizer, E. Kohler, and D. Mazie`res. Makinginformation flow explicit in histar. In Proceedings of the 7th symposium onOperating systems design and implementation, pages 263–278. USENIXAssociation, 2006. → page 52[67] N. Zeldovich, S. Boyd-Wickizer, and D. Mazieres. Securing distributedsystems with information flow control. In NSDI, volume 8, pages 293–308,2008. → page 52[68] Q. Zhang, J. McCullough, J. Ma, N. Schear, M. Vrable, A. Vahdat, A. C.Snoeren, G. M. Voelker, and S. Savage. Neon: system support for deriveddata management, volume 45. ACM, 2010. → page 5261
Thesis/Dissertation
eng
Computer Science
Vancouver : University of British Columbia Library
Attribution-NonCommercial-NoDerivatives 4.0 International
Graduate
Cross-device access control with Trusted Capsules
Text