cleanos: limiting mobile data exposure with idle eviction€¦ · usenix association 10th usenix...

USENIX Association 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’12) 77

CleanOS: Limiting Mobile Data Exposure with Idle EvictionYang Tang, Phillip Ames, Sravan Bhamidipati, Ashish Bijlani, Roxana Geambasu, Nikhil Sarda

Columbia University

AbstractMobile-device theft and loss have reached gigantic propor-

tions. Despite these threats, today’s mobile devices are satu-rated with sensitive information due to operating systems thatnever securely erase data and applications that hoard it on thevulnerable device for performance or convenience. This paperpresents CleanOS, a new Android-based operating system thatmanages sensitive data rigorously and maintains a clean envi-ronment at all times. To do so, CleanOS leverages a key prop-erty of today’s mobile applications – the use of trusted, cloud-based services. Specifically, CleanOS identifies and tracks sen-sitive data in RAM and on stable storage, encrypts it with akey, and evicts that key to the cloud when the data is not inactive use on the device. We call this process idle eviction ofsensitive data. To implement CleanOS, we used the TaintDroidmobile taint-tracking system to identify sensitive data locationsand instrumented Android’s Dalvik interpreter to securely evictthat data after a specified period of non-use. Our experimentalresults show that CleanOS limits sensitive-data exposure drasti-cally while incurring acceptable overheads on mobile networks.

1 IntroductionMobile technology is replacing desktops as the primarypersonal computing platform and is being used in in-creasingly sensitive contexts. For example, today’s usersrely on smartphones and tablets to access their personaland corporate email, prepare tax returns, and review cus-tomer documents [32]. Even the US military recentlyannounced that it will equip soldiers with Android de-vices for accessing classified documents [28]. The drawto new mobile technology is justifiable: mobile devicesoffer convenient and constant connectivity, increase pro-ductivity, and provide access to feature-rich, cloud-basedapplications (a.k.a. “apps”).

Despite these advantages, the transition to mobile de-vices raises serious and yet unresolved concerns, partic-ularly with respect to data security in the event of devicetheft and loss. Unlike desktops, generally assumed to bephysically secure, mobile devices are extremely prone totheft and loss. Statistics here are staggering: 49% ofthe New York City population has experienced mobilephone loss/theft [24], and the FCC recently declared mo-bile theft an “epidemic” in major US cities [13].

Though alarming, these statistics have yet to promptmobile OSes to address the serious data-security threatsposed by device theft or loss. Like their desktop precur-sors, such as Linux and Mac OS X, mobile OSes let sen-sitive data accumulate uncontrollably on the device. Forexample, the OS accumulates significant amounts of datain cleartext memory, and the file system retains deleted

files by not purging their contents. Despite being backedby clouds, applications hoard sensitive data – such asemails, documents, and banking information – on the vul-nerable device. Although encrypted file systems [26], en-crypted RAM [34], and remote-wipeout systems [3, 21]help protect this data, they are imperfect stopgaps forOSes that were simply not designed with physical inse-curity in mind. For example, a recent study shows that57% of corporate users employ no locking mechanismson their smartphones, rendering encryption useless [32].

This paper presents CleanOS, a new Android-basedmobile operating system1 designed to manage sensitivedata rigorously and maintain a clean environment at alltimes in anticipation of device theft. The crucial insightin CleanOS is to leverage the tight integration of today’smobile applications with trusted cloud-based services inorder to evict sensitive in-memory and on-disk data tothose services whenever it is not needed on the device.CleanOS thus ensures that the minimal amount of sensi-tive data is exposed on the vulnerable device at any time.

CleanOS extends Android in two major ways. First, itintroduces sensitive data objects (SDOs), a new abstrac-tion that facilitates management of sensitive data on mo-bile devices. An SDO is a logical collection of Java ob-jects, files, and database items that applications create anduse to manage their sensitive data, such as emails, finan-cial data, or documents. SDOs and their data “disappear”from the device unless they are frequently used by an ap-plication. For example, if an email app adds an email’scontent to an SDO, any “trace” of that content automati-cally disappears from RAM and stable storage unless theuser is actively reading that email on an unlocked screen.Recovering the email requires interaction with the cloud.

Second, to evict idle SDOs, CleanOS modifies An-droid’s Java interpreter (Dalvik) to introduce a new typeof Java garbage collector (GC), called an evict-idle GC(eiGC). While a traditional GC deallocates only those ob-jects guaranteed to never be used in the future (i.e., nopointers to them exist), eiGC eliminates objects that havenot been used for a period of time even if they might beused again in the future (i.e., pointers to them still ex-ist). To do so, eiGC walks through all Java objects in anidle SDO and encrypts their data-bearing fields, such asprimitives and arrays of primitives, with a key that is es-crowed in the cloud. Our modified Dalvik interpreter thenfaults when a bytecode instruction executes on an evicted

1We view the OS notion broadly in this paper to include both thetraditional OS and the entire Android framework on which apps run.

78 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’12) USENIX Association

Component New or Changed Features

Dalvik (JVM) Evict-idle Garbage Collector (eiGC) Eviction-aware bytecode interpretation Secure deallocation of interpreted stacks

Android SDK SDO API Default SDO heuristics

TaintDroid Support for millions of taints SQLite vulnerability fix

SQLite Taint tracking in database

Webkit Screen-buffer purging

Bionic (libc) Secure user-space deallocation

Linux Kernel Secure page deallocation with grsecurity

Figure 1: CleanOS Modifications to Android, TaintDroid.

object, retrieves the key from the cloud, and decrypts theobject. Thus, data eviction in CleanOS is logical; the dataitself remains on the device in encrypted form, while thekey is shipped to the cloud.

The major security benefit of CleanOS stems from thevalue-added services that app clouds can build on top ofit. For example, a cloud could revoke data access fol-lowing a theft report, provide an audit log of data ex-posed upon theft, or monitor data access to detect anoma-lous uses. Building such services on today’s “dirty” de-vices would be tremendously challenging and likely re-quire sacrificing semantics or performance. For example,Gmail allows email access revocation [18], but emailscached on the device remain exposed. Conversely, notcaching sensitive data on the device degrades perfor-mance over slow mobile networks. CleanOS providesdevice-side OS support for building robust, secure, andefficient value-added cloud services.

We built CleanOS in Android using the TaintDroidtaint-tracking system [12] and also implemented avalue-added cloud service that provides post-theft data-exposure auditing. To do so, we modified several corecomponents in Android and TaintDroid, summarized inFigure 1. Together, our changes provide: (1) evictionof idle Java objects, (2) heuristics for identifying sensi-tive data without requiring app changes, (3) support formillions of taints in TaintDroid, and (4) multi-layer se-cure deallocation of freed data in Java, native, and kernelspace. While CleanOS’ design extends in-memory evic-tion to stable storage, this paper and our current prototypefocus on in-memory data eviction.

Overall, we make the following contributions:1. We demonstrate the sensitive data exposure problem

by analyzing 14 popular Android apps (§2).2. We define SDOs, a new abstraction for managing

sensitive data on theft-prone devices (§3).3. We implement CleanOS, an Android OS extension

that combines known encryption-based data destruc-tion [4, 16, 30] with a new GC process that evictsidle sensitive data (§4 and §5).

4. We present a set of valuable add-on services thatclouds could build on top of CleanOS (§6).

2 Case Study: Data Exposure on AndroidWe selected for analysis 14 Android apps according totheir popularity in five sensitive categories: email, fi-nance, document editing, password management, and so-cial networking. We define as exposed any data that per-sists on the device – either in RAM or on storage – fora prolonged period of time, such as 10 minutes (§3 de-scribes our rationale for this threat model). Our goalin the analysis was to answer three questions: (1) Issensitive-data exposure a real problem? (2) If so, whatare its causes? and (3) Is the exposure necessary? Wetackle each question using examples from our analysis.Is Data Exposure a Real Problem? We installed the14 apps on a rooted Nexus S phone with Android 2.3.4and asked the following question: what kinds of sensi-tive data can one find by dumping RAM and databasecontents while apps run in the background? Our acqui-sition process was vastly simplified by our rooted phoneand the lack of encryption on the default Android config-uration. Nevertheless, we believe that our findings indi-cate the level of data exposure on better-protected phonesin face of realistic, albeit sophisticated, attacks, such ascold boot RAM imaging [19]. We created a stable-stateenvironment – akin to the one a thief might find on a lostdevice – by ensuring that apps had not been used for 10minutes prior to taking RAM and DB dumps.

The answer to our question is eye-opening: with sim-ple techniques, we retrieved cleartext copies of sensitiveinformation from all but one app. Figure 2(a) shows ex-amples of cleartext sensitive data we extracted from a se-lect subset of the apps. Figure 2(b), column “ExtractedCleartext Data,” expands the result set to all 14 appsand categorizes data in three classes of varied sensitivity:passwords, contents (e.g., email body, document content,bank account), and metadata (e.g., email subject, docu-ment title). Overall, we captured passwords in 5/14 apps,contents in 11/14 apps, and metadata in 13/14 apps.What Causes Data Exposure? Given these results, anobvious question is what leads to so much leakage. Thereare several possible answers:Insecure Deletion: The Android OS, including the kernel,system libraries, and the Java framework, leaks sensitiveinformation by not erasing data securely after it is deallo-cated or by not securely erasing files when an app asks itto do so. These problems are well known in desktop andserver settings and have been addressed with secure deal-location [6] and assured deletion [30, 39], respectively.OS Data Buffering: Recent work shows that OSes and de-vice drivers retain data in buffers past its intended life. Italso shows how to limit OS-buffered data exposure [10].App Data Hoarding: Although most of the apps arecloud-based, our experiments show that they hoard sig-nificant amounts of cleartext sensitive information on thedevice, either in RAM or in the local database. For exam-


App Extracted Cleartext Data

Email password, email contents, subjects, from/to, contacts

OI Notepad (doc) document and metadata

KeePass (password mgr)

app password, all stored passwords & descriptions

Pageonce (finance) password, transactions, bank account information

Facebook (social) wall posts and messages

(a) Examples of data extracted from RAM / DB.

App Description

Extracted Cleartext Data Hoarding

Cleartext Data RAM SQLite DB

Pass-word

Cont-ents

Meta-data

Pass-word

Cont-ents

Meta-data

Pass-word

Cont-ents

Meta-data

Email email (default) Y Y Y Y Y Y Y Y

GMail email Y Y Y Y

Y! Mail email Y Y Y Y Y

GDocs documents Y Y Y Y

OI Notepad documents Y Y Y Y

DropBox documents Y Y Y

KeePass password mgr Y Y Y Y Y Y

Keeper password mgr Y Y Y Y Y

Amazon commerce

Pageonce finance Y Y Y Y Y Y Y

Mint finance Y Y Y Y Y Y

Google+ social Y Y Y Y

Facebook social Y Y Y Y

LinkedIn social Y Y Y Y Y

(b) Exposure of cleartext sensitive data across all 14 apps.

App Data When App Uses Data

Email

password user/automatic refresh

subjects on the email list screen

contents user opens the email

OI Notepad

note title on the note list screen

note body user edits the note

KeePass

master password app launches

entry name on the entry list screen

entry password user opens the entry

(c) Example usage of hoarded data by apps.

Figure 2: Sensitive Data Exposure. (a) Examples of captured sensitive data. (b) A ’Y’ indicates that we obtained cleartext copiesfrom RAM/DB. A blank cell does not mean that the data is not on the device, but just that we did not find it in cleartext; the datacould exist in some encrypted form. (c) Examples of when hoarded sensitive data is being actually used by the apps.

ple, the default Android email app maintains the emailaccount password in cleartext RAM at all times, whileKeePass, a popular password manager, loads its entirepassword database into RAM at startup and keeps it there.Column “Cleartext Data Hoarding” in Figure 2(b) showsthe persistent, app-intended cleartext data we found inRAM or DBs.2 It demonstrates that the hoarding behav-ior is pervasive: all but one of the 14 apps permanentlymaintain at least one type of sensitive data either in RAMor in the database, while 6/14 apps permanently maintaintheir passwords or some sensitive content in RAM.Memory Leaks: Beyond the scope of our experiments isthe well-known ease of unwittingly introducing memoryleaks into Android applications [2]. If small, these leaksmay go undetected and expose sensitive information.Is Data Exposure Necessary? Although apps hoard sig-nificant amounts of sensitive data on mobile devices, theytend to access this data fairly infrequently, suggesting thatdata is often exposed longer than it needs to be. By wayof example, Figure 2(c) identifies situations where threeof our most problematic apps use hoarded sensitive data.For example, the password in the default Android Emailapp, which we know is exposed in RAM at all times, is infact used only during inbox refreshes (the default is every15 minutes). Similarly, each email’s content is exposed inSQLite at all times but accessed only when the user opensthat particular email. While the frequency of these oper-ations depends on the workload, intuitively it should berelatively rare, making prolonged exposure unnecessary.Implications for Mobile OS Design. Secure deletion forstorage, RAM, and OS buffers has been acknowledged as,and developed into, a primary OS function [6, 30, 10];

2For RAM, we conservatively assume an object to be persistent if italways appears in the app’s Java object dump.

however, the management of app-driven data hoardingor leakage has thus far been considered an app’s ownresponsibility. For example, faced with similar data-hoarding practices in desktop and server applications,Chow, et al. [6] conclude that “little can be done withoutmodifying the application” and that “leaks are recognizedas bugs by application programmers, so they are activelysought after and fixed.” Unfortunately, relying on the appto manage sensitive data is problematic. Sensitive-datacaching presents tradeoffs between security on one handand performance, usability, and energy/bandwidth con-sumption on the other hand. Without solid abstractions,calibrating these tradeoffs is challenging. For example,should a document-editing app cache the documents lo-cally for good performance over cellular networks (asrecommended in some mobile app guidelines [14]), orshould it not do so for security reasons (as recommendedin other guidelines [40])? Should it cache the user’s pass-word for convenience, or should it prompt the user for itwhenever it is needed?

We argue that mobile OSes can and should offer ab-stractions for apps to manage their sensitive data rigor-ously without sacrificing their performance, usability, orother properties. This paper introduces one such abstrac-tion in CleanOS, whose goals we next describe.

3 Goals and AssumptionsGoals. The primary goal of CleanOS is to minimize theexposure of an app’s allocated sensitive data by evict-ing it from the device whenever the data is idle (i.e., notbeing actively used by the application). The key insightthat makes this possible is the tight integration betweentoday’s mobile apps and cloud services. CleanOS lever-ages clouds to create a new abstraction, called a sensitivedata object (SDO). SDOs track sensitive information as


it flows through RAM and stable storage. As soon as theybecome idle, they are automatically evicted to the cloudand are recovered only when the app needs them again.

Specific design goals of CleanOS include:1. Eviction: SDOs should “disappear” as soon as they

become idle whether or not they are expected to beused by an application in the future.

2. Reasonable performance: We seek to provide rea-sonable performance for popular mobile apps de-spite data eviction over Wi-Fi or cellular networks.

3. Reasonable defaults: While we admit app changesfor best performance and semantics, we aim to offerreasonable defaults even for unmodified apps.

4. Leverage technology trends: CleanOS must inte-grate naturally with existing tech trends, such as thetight integration of mobile apps with cloud services.

5. Design for mobiles: CleanOS’ design should targetmainstream mobile technologies, such as Android.

Eviction of idle data (Goal 1) is our primary goal andcontribution in CleanOS. We strive to ensure that a thiefcannot get a “free lunch” by capturing a device. Rather,he should be required to contact the cloud in order to ac-cess data of interest, at which time the cloud could denyaccess, log it, rate-limit it, etc. However, enforcementof precise timeouts on idle sensitive data is a non-goal.From a performance perspective (Goal 2), we wish toensure that popular apps remain usable despite evictionacross Wi-Fi or cellular networks (e.g., 3G/4G).

A common pitfall when proposing new OS abstrac-tions is to require application changes to gain any benefit.To avoid this, CleanOS should include heuristics to con-struct default SDOs that provide reasonable eviction andperformance properties even for unmodified apps (Goal3). Finally, we aim to exploit unique properties of popularmobile technologies in CleanOS’ design (Goals 4 and 5).First, we leverage the tight integration between most mo-bile apps and trusted cloud services to evict device data tothose services. For local-only apps, however, the user canstill integrate them with his own CleanOS service. Sec-ond, while the data eviction concept is applicable to anymobile OS, we focus our design on Android, which letsus leverage its technological properties to facilitate dataeviction. For example, since all Android apps are writtenin Java, we decided to tap into the garbage collector toevict idle sensitive Java objects.Threat Model. Our threat model considers any data ona mobile device to be vulnerable to data-driven thieves.While many data protection systems exist – including en-crypted file systems [26, 38, 11], encrypted RAM [34,23, 31], and data wipeout systems [3, 21] – they are im-perfect when confronted with negligent users or (sophis-ticated) physical attacks. First, users can foil any pro-tection system by not locking their devices [32], assign-ing trivial PINs or passwords [20], or writing passwords

down in easily retrievable locations [36]. Second, mobiledevices are prone to physical attacks, which are notori-ously difficult to protect against. For example, an attackercould use cold boot attacks [19] to retrieve in-RAM de-cryption keys or data, break the seal of tamper-resistanthardware [1, 35], or shield the device from the networkto prevent remote wipeout [3]. Such threats are especiallyrelevant for corporate, government, and military users,who interact with particularly sensitive data, such as tradesecrets, customer data, health data, or state secrets.

To maintain post-loss control over data despite suchthreats, CleanOS evicts data to a cloud service, which isassumed to be trusted and non-compromisable. In real-ity, mobile users are already required to trust the cloudson which their apps rely, so our assumption is reason-able. Depending on the deployment model, these cloudscould integrate directly into CleanOS to help cleanse theirapps automatically. For apps without a cloud component,we assume that users can evict data to a trusted commu-nity or self-administered CleanOS service. Finally, weassume that the cloud learns about a monitored device’stheft, either directly from the user or via an automaticmobile-theft detection mechanism.

CleanOS explicitly assumes that the mobile device,along with all software running on it, is trusted until itis lost. For example, the thief cannot install malware ona user’s device, tamper with the device physically, or in-spect it prior to stealing the device. After loss, we trustneither the hardware nor the software on the device.

We assume that disconnection is the exception ratherthan the rule. With pervasive wireless and cellular net-work coverage, this assumption is becoming increasinglyrealistic. Moreover, CleanOS is especially geared towardcloud-based apps, which typically require connectivityfor full functionality. Nevertheless, we present tech-niques to allow disconnected operation in certain cases.

CleanOS is most applicable to long-lived daemon-likeapps, whose execution consists of brief computation ses-sions interspersed with long periods of inactivity. Most oftoday’s mobile apps follow this model, including email,browsers, document editors, and social apps. CleanOSdisables exposure during periods of inactivity.

Finally, we explicitly assume the existence of robustsecure deallocation and OS buffer-cleanup techniques [6,30, 10] and do not aim to improve the state of the artin these intensely-researched directions. Rather, we fo-cus on limiting the exposure of sensitive data that appli-cations hoard or leak, a problem previously thought in-tractable from an OS perspective (see §2).

4 The CleanOS ArchitectureWe now describe our CleanOS design for Android. Wefocus initially on in-RAM data eviction, after which weshow how to extend SDOs to stable storage.


Linux Kernel

App 1(active)

eiGCDalvik(JVM)

AndroidSDK

SQLite libc

App 2(inactive)

SDO3

SDO4SDO5

Trusted Cloud(s)

SDOID

SDODescription

SDOKey

AppName

SDO Database

Available SDO

Evicted SDO

Available Java object

Evicted Java object

Mobile Device

SDO1

SDO2

SDO API

App Code

Java Heap

Libs

Na

tive

Java

FS

SDO API:

class SDO { SDO(String description, SDOLevel level) // new SDO void add(Object o) // adds object to SDO void remove(Object o) // removes object from SDO}

CleanOS Protocol:

registerSDO(sdoID, appName, description, key) // registers SDO with DBfetchKey(appName, sdoID, bucketID) → key || null // fetches the key for a bucket in the SDO // bucketID = 0 returns the SDO's keysdoEvicted(appName, sdoID) // announces an SDO's eviction to the cloud

(b) CleanOS APIs.(a) CleanOS Architecture.C

lea

nO

S P

roto

col

Figure 3: The CleanOS Architecture and APIs. (a) The architecture, with key components highlighted in grey. We add or modifyin some way all of the boxed components (except for FS and kernel). (b) The CleanOS SDO API and device-cloud protocol.

4.1 CleanOS OverviewFigure 3(a) shows the CleanOS architecture, which in-cludes three major components: (1) the sensitive dataobject (SDO) abstraction, (2) a modified, eviction-awareversion of the Dalvik interpreter, along with an evict-idlegarbage collector (eiGC), and (3) the SDO cloud store.Briefly, apps create SDOs and place their sensitive Javaobjects in them. The modified Dalvik tracks their prop-agation across RAM with TaintDroid and monitors theirbytecode-level accesses. The eiGC evicts SDOs to thecloud if they remain idle for a specified period.

An SDO is a logical collection of Java objects, such asstring objects representing the emails in a thread or ob-jects pertaining to a bank account in a finance app. Uponcreation, SDOs are assigned app-wide unique IDs and en-cryption keys (KSDO), and are registered with the cloud.

We implement three functions for SDOs. First, wetrack objects in an SDO with a modified TaintDroid sys-tem, using the ID as a taint. As objects are tainted withan SDO’s ID, they become part of the SDO. For exam-ple, SDO1 in Figure 3(a) includes three objects added to iteither explicitly by the app or automatically by our mod-ified Android framework. Second, we monitor accessesto SDOs and record their timings. Whenever an app ac-cesses an object in an SDO (e.g., to compute on it, sendit over the network, or display it on screen), that SDO ismarked as used. Third, we evict SDOs when they are idlefor a time period (e.g., one minute).

To evict idle SDOs, the eiGC eliminates unused Javaobjects from RAM even if they are still reachable. It pe-riodically sweeps through Java objects and evicts them ifthey are tainted with an idle SDO’s ID. In Figure 3(a),the active app (App 1) has one available SDO (SDO1) andone evicted SDO (SDO2). For example, an SDO associ-ated with an email thread might be available while theuser reads emails in that thread, but the password SDOmight remain evicted. When the app goes into the back-

ground, all of its SDOs might be evicted, as shown forApp 2. An SDO is evicted when all Java objects in ithave been evicted; however, an available SDO may haveboth evicted and available Java objects.

Conceptually, eviction occurs at the level of logicalSDOs. In practice, however, CleanOS must eliminate theactual data-bearing objects from the vulnerable device.To do so, eiGC leverages encryption-based data destruc-tion from assured-delete file systems [30, 16] and appliesit to the memory subsystem. Specifically, eiGC replacesdata-bearing fields in objects, such as primitives and ar-rays of primitives, with encrypted versions and then se-curely destroys the encryption key. To encrypt a data fieldF , eiGC uses a key KF that is uniquely generated fromthe SDO’s key KSDO in the cloud (see §5 for details). Wemodified Dalvik to fault when an app attempts to accessthe evicted data, at which time it retrieves KSDO from thecloud, generates KF , and decrypts the data. KSDO is thencached onto the device and securely removed when theSDO as a whole is again evicted.

We next provide more detail on the two main contribu-tions of CleanOS: the SDO abstraction and the eiGC.

4.2 The SDO AbstractionSDOs fulfill two functions in CleanOS. First, they letCleanOS identify sensitive data and focus its cleansingon that data for improved performance. Indeed, evictingall Java objects indiscriminately would be prohibitivelyexpensive, while evicting a few at random would dimin-ish security benefits. Second, SDOs are instrumental insupporting some of our envisioned add-on cloud services,such as the auditing service described in §6, as they iden-tify and classify sensitive data for the auditor.APIs. Figure 3(b) shows the SDO API. To realize thedata-control benefits of CleanOS, apps create SDOs andadd/remove Java objects to/from them. To create anSDO, an app specifies a description, which is a short,human-readable string that describes the sensitive data


associated with the SDO. For example, our modifiedemail app, CleanEmail, creates an SDO using “pass-word” for the description and adds the password objectto it. It also creates one SDO for each email thread, spec-ifying the thread’s subject as the description, and addseach email in the thread to it. Section 6 describes twoapps that we trivially ported to CleanOS with minimalmodifications (fewer than 10 LoC).

Figure 3(b) also shows the protocol used to regis-ter SDOs, retrieve their keys after eviction, and reporttheir eviction to the cloud. To create an SDO, theapp registers it with the cloud database using the SDOAPI, specifying its ID, the app’s package name (such ascom.android.email), the description, and the encryp-tion key. For example, the description for an SDO as-sociated with a certain thread might be the subject ofthat thread. In the database (whose schema is includedin Figure 3(a)), the tuple 〈app package name, SDO ID〉is a phone-wide unique identifier. Although not imple-mented in our current prototype, the database can use theapp user id to restrict access to keys only to the apps thatcreated them. Finally, to enable auditing services such asKeypad [15], CleanOS notifies the cloud asynchronouslywhenever it evicts an SDO (message sdoEvicted). Thenotification is needed because, unlike Keypad, CleanOSdoes not forcibly evict keys at an exact time after theywere fetched; rather, it does so when convenient, depend-ing on load and networking conditions (see §4.5 and §5).Default SDOs. As mentioned in §3 (Goal 3), we aim notto rely on app modifications to gain tangible benefit fromCleanOS. To this end, we modified the Android frame-work to register a set of default SDOs and use simpleheuristics to identify and classify Java objects coarselyon behalf of the apps. For example, our current prototypecreates several default SDOs by plugging into variouscore classes in the SDK: a User Input SDO for all inputa user types into the keypad (class InputConnection),a Password SDO for any Java objects that capture inputa user types into a password field (based on attributes ofclass TextView), a coarse SSL SDO for all objects readfrom incoming SSL connections (class SSLSocket), andSDOs for input from particularly sensitive sensors, suchas the camera. Some of these heuristics (e.g., SSL) wereinspired by prior work on automatic identification of sen-sitive data [9]. Although default SDOs are coarse andmay potentially include many non-sensitive objects (par-ticularly SSL), we believe that they offer comprehensiveidentification of most sensitive data in unmodified apps.For example, all the sensitive data we analyzed in §2would be capturable by a default SDO. For apps will-ing to adapt, CleanOS allows the overriding of defaultassignments of objects to SDOs.Eviction Granularities and Buckets. Thus far, evictiongranularities have been determined by SDOs, which is

problematic for two reasons. First, it forces app writersto consider granularities and taint propagation when theydesign their SDOs. Second, our default SDOs, such asSSL, are coarse. In our view, CleanOS should offer evic-tion benefits even when an app dumps all of its sensitiveobjects into one big SDO, e.g., “sensitive.”

To support fine-grained eviction with coarse-grainedSDOs, we introduce buckets. Specifically, an SDO is“split” into several disjoint buckets, which are evicted in-dependently. Java objects added to the SDO – either bythe app or by our framework – are placed in random buck-ets. Eviction occurs at the bucket level: when a buckethas been idle for a period, all objects in it will be evictedusing a bucket key, which is derived from the SDO’s keyusing a key derivation function [22]. For example, in anunmodified email app, we would place all emails into theSSL SDO. With buckets, different emails would be placedinto different buckets of the SSL SDO and might thereforebe evicted independently. Also, with bucketing, we cachebucket keys instead of SDO keys on the device.

4.3 The Evict-Idle Garbage CollectorA simple but important innovation in CleanOS is theevict-idle GC (eiGC). At its core (and independent ofCleanOS), eiGC implements for a managed languagewhat swaping implements for OSes: it monitors whenobjects are being accessed during bytecode interpretationand evicts them when they have not been used for a while.We believe that the eiGC concept has applications beyondCleanOS, such as limiting the amount of memory usedby Java applications on memory-constrained devices at afiner grain than OS-level paging would be able to sustain.In the context of CleanOS, however, eiGC evicts Java ob-jects in idle SDO buckets.

Using the GC to evict sensitive data is not the onlydesign worth considering when building a “clean” OS.We contemplated modifying the kernel’s paging mecha-nism to swap idle pages to a Keypad-like encrypted filesystem [15], which at its core achieves for files a simi-lar eviction function to the one we achieve for RAM. Wechose the GC approach for two reasons. First, evictingJava objects provides finer-grained control over sensitive-data lifetime than full-page eviction. Second, by evictingat the JVM level we can leverage TaintDroid, the onlytaint tracking system for Android. Tracking sensitive datais vital for constructing the SDO abstraction, which inturn is the base for building powerful add-on services,such as auditing. However, our decision has a downside:coverage. By evicting Java objects, we may miss dataintentionally maintained by native libraries. We discussthis limitation further in §8.

4.4 SDO Extension to Stable StorageLike RAM, stable storage requires sanitization. At firstglance, systems such as Keypad [15] could be directly


leveraged to evict unused files in CleanOS. Unfortu-nately, we found that eviction at file granularity is unsuit-able for Android, where apps typically rely on a databaselayer to manage their data. For example, 11 of the 14 appsin Figure 2(b) store their data in SQLite, which maps en-tire databases as single files in the FS. As a result, if theDB file were exposed, then all of its items would be ex-posed, including long-unaccessed emails and documents.

CleanOS tailors storage eviction specifically for An-droid by extending the in-RAM SDO abstraction to in-clude files and individual database items. For this, we usetwo mechanisms. First, we propagate SDO taints to filesand database items. Unfortunately, TaintDroid supportsonly the former, not the latter, an important vulnerabilitywe discuss in §5. We fixed this in CleanOS by modifyingthe SQLite DB. Specifically, we automatically alter theschema of any table to include for each data column, C,a new column, Taint C, which stores the taint for eachitem in that column (SDO ID and bucket ID). Second,before storing a tainted data object in a DB, we first evictthat object, i.e., encrypt it with its eviction key. When thedatabase needs the object, it must decrypt it.

4.5 Disconnected OperationWhile we assume that disconnection is the exceptionalcase, we present techniques to deal with two types of dis-connection: (1) short-term disconnection, such as tempo-rary connectivity glitches, and (2) long-term, predictabledisconnection, such as a disconnection during a flight. Toaddress short-term disconnection, we can extend evictionof already available SDOs by a bounded amount of time(e.g., tens of minutes). This allows an app to continueexecuting normally while temporarily disconnected untilit reaches an evicted object. For example, a user might beable to load recently accessed emails, but not older ones.

To address long-term disconnection, such as during airtravel, we hoard SDO keys before entering into discon-nection mode. For example, our prototype implementsDalvik support for hoarding SDO keys upon receipt of asignal. We plan to wrap this functionality into a privi-leged app that provides users with a “Prepare for Discon-nection” button, which they can press before boarding aflight. To prevent a thief from using this button to retrieveall SDO keys, the cloud would require the user to en-ter a password. While we generally shun user-configuredpasswords in CleanOS, we believe that long-term discon-nection is a sufficiently rare case to warrant enforcementof particularly strong password rules with limited impacton usability [27]. In contrast, imposing such rules on fre-quent unlock operations would be impractical.

4.6 Deployment ModelsCleanOS presents multiple deployment opportunities.First, security-conscious apps can use their own, dedi-cated clouds to host keys and provide add-on services,

such as auditing. In such cases, we expect that the mo-bile side of apps would define meaningful SDOs. Second,users who are particularly concerned with apps that havenot yet integrated with CleanOS might use a CleanOScloud offered by a third party or that they host themselves.For example, our prototype hosts all keys for all apps ona Google App Engine service that we implemented.

5 Prototype ImplementationWe built a CleanOS prototype by modifying Android2.3.4 and TaintDroid in significant ways (see Figure 1).To date, our prototype fully implements eviction of in-memory SDOs and propagates taints to SQLite, but itdoes not yet encrypt sensitive items in SQLite. Doingso will require changing the native part of the SQLite li-brary – a single, massive, over-100K-LoC file – the majordeterrant we encountered thus far. We next describe mod-ifications we made to components of particular interest.TaintDroid with Millions of Taints. Most dynamictaint-tracking systems, including TaintDroid, supportlimited numbers of taints, which would prevent CleanOSfrom scaling to many SDOs. For example, TaintDroidsupports only 32 taints by representing them as 32-bitshadow tags, where each taint corresponds to one tag bit.This limitation allows propagation of multiple taints onone object for tracking completeness and security againstmalicious applications. For CleanOS, which trusts appli-cations, we modified propagation to allow many taints.

We rely on a simple observation, which we validateexperimentally: in practice, when multi-tainting occurs,we can usually define a strict, natural ranking for taints interms of their sensitivity. As intuitive examples, a Pass-word SDO should be more sensitive than a generic UserInput SDO, and a KeePass secret’s SDO should be moresensitive than its description SDO. In these cases, “los-ing” the less sensitive taint would be admissible, becauseit does not weaken the user’s perception of the gravity ofan object’s exposure. Using a 24-hour real-usage tracefor the Email app (see §7.1), we confirmed that 98.8%of the tainted objects were either assigned a single taintduring their lifetimes or received multiple taints whosesensitivity could be strictly ordered using a simple, static,three-level ranking system: HIGH, MEDIUM, and LOW. Theremaining 1.2% of the objects received multiple taintsof undecidable ordering within this ranking system (i.e.,equal sensitivity levels). Similar traces for Facebook andMint indicated even fewer undecidable cases (< 0.01%).

Based on this observation, we introduce the concept ofsensitivity level for taints and use it to propagate a sin-gle taint per object. Apps specify a sensitivity level foreach SDO upon its creation. If an object were addedto two SDOs during taint propagation, CleanOS retainsthe one with the higher sensitivity level. For equal sen-sitivities (the rare case), CleanOS retains the most recent


31 30 29 28 4 3 0

E Level SDO ID Bucket

Figure 4: CleanOS Taint Tag Structure. We impose a struc-ture on TaintDroid taints to support arbitrary numbers of taints.

taint. Figure 4 illustrates the revised structure for the tainttag, in which we pack together the sensitivity level, SDOID, and bucket ID into 32 bits while supporting up to 225

SDOs. In our experience, assigning sensitivity levels toSDOs is natural, as demonstrated in §6. The idea of prop-agating a single taint was used before in hardware-basedtaint tracking systems for improved performance [5].Eviction-Aware Interpretation in Dalvik. We reservedthe most significant bit in the taint tag to denote the evic-tion state of a field. We modified the Dex bytecodeinstructions that access object instance fields and arraymembers. This includes instructions such as OP AGET,OP IGET, OP SGET (used to retrieve array members, in-stance fields, and static fields, respectively). Our new in-struction implementations first test the value of the evic-tion bit in the field’s taint tag. When the bit is set, werequest the aforementioned KSDO and decrypt the valuebefore allowing the instruction to proceed. If a key is notavailable, execution is suspended.The Evict-Idle Garbage Collector. While eiGC walksthe reachable objects, we inspect the taint tag for eachobject field and retrieve its idle time. If it exceeds theconfigured threshold, then eiGC retrieves the key asso-ciated with the tag and encrypts the value. Only fieldsthat represent actual data are evicted (primitives and ar-rays of primitives); fields implemented as pointers are notevicted, as a pointer is not in and of itself sensitive.

To evict data, we use AES in counter mode to generatea keystream, which we use as input to an XOR operationwith each byte of the data to be evicted. The size of thekeystream depends on the data’s type. For primitives, it iseither 4 bytes (for char, int, float, etc.) or 8 bytes (fordouble or long). For arrays, many bytes may be neces-sary. We use the bucket key to generate an appropriatelysized keystream. For primitives, we replace the data witha pointer to a structure containing metadata necessary fordecryption (e.g., initialization vectors) and the resultingciphertext. For arrays, we evict the contents in place andstore the necessary metadata inside the ArrayObject.

Running the eiGC continuously would prevent theCPU from turning off when the mobile device is idle,thereby wasting energy. Fortunately, eiGC needs to runonly while sensitive objects are left unevicted. Hence,in our prototype, eiGC stops executing as soon as it hasevicted all data, which should occur shortly after the appgoes idle. The eiGC resumes execution once the appfaults on an evicted object or assigns a new taint to anobject. Hence, eiGC runs only while the app also runs.Optimizations: Bulk Eviction and Prefetching. Perfor-mance and energy are major concerns with CleanOS, for

two reasons. First, garbage collection is expensive; henceperforming it frequently hurts app performance and en-ergy (e.g., the eiGC’s full-heap scans block interpretationfor 1-2s). Second, our reliance on the network to fetchdecryption keys causes app delays and dissipates energy.

To address the first problem, we developed bulk evic-tion, in which the eiGC evicts sensitive Java objects all atonce, soon after the app itself becomes idle. More specif-ically, while the app is executing, we evict nothing andperform no GC; once the app has remained idle for a pre-defined time (e.g., one minute), the eiGC performs a full-heap scan-through and evicts all cleartext tainted objects.This technique reduces the number of heavyweight GCsto just one per app execution session, thereby minimizingthe eiGC’s impact on performance and energy.

To address the second problem, we developed bulk keyprefetch, which prefetches all keys that were accessedduring the last eviction period upon the app’s first misson a key. For example, if a user opened his inbox sub-ject list and read two emails during a previous interactionsession with his email app, then the next time the userbrings the app into the foreground, CleanOS will fetchthe decryption keys for the subjects and the two emails’contents – all in one network request. If the user viewsonly his subject list but reads no emails in a previous ses-sion, then the next time around, CleanOS will fetch onlysubject keys again, not any email content keys. This tech-nique improves app launches and the latency of repeatedoperations, such as re-reading an email. It can be ex-tended to prefetch keys used in the last N sessions.

Although these optimizations may improve perfor-mance and energy, they may also increase sensitive-dataexposure. For example, prefetching previously-used keysmay expose some sensitive data needlessly. We quantifythis performance/exposure tradeoff in §7.2.Multi-Level Secure Memory Deallocation. Androidgoes to great lengths to keep an application running inthe background so it can re-launch quickly. This cancause an accumulation of sensitive data in areas of mem-ory that are no longer in use but have not been returned tothe kernel. The object heap in Dalvik is implemented us-ing dlmalloc mspaces and relies on the implementation offree() in dlmalloc to return memory to the mspace. Toimplement secure deallocation, we changed both free()and an Android-specific modification to dlmalloc thatmerges chunks of adjacent free memory. These functionsnow overwrite the space being released with a fixed pat-tern. We also modified Dalvik to overwrite interpretedstack frames on method exit, scrubbing them of sensitivedata. Finally, when assigning default taints to Java ob-jects, we made explicit efforts to taint objects as soon asthey enter Java space from native libraries.Addressing a TaintDroid Vulnerability. When imple-menting CleanOS, we uncovered a surprising implication


of a known limitation in TaintDroid. Specifically, Taint-Droid does not track changes in native libraries, which,as acknowledged by its authors, may allow a malicious li-brary to leak tainted data without triggering an audit log.To address this problem, TaintDroid prevents untrustedapps from loading any native libraries other than systemlibraries (e.g., SQLite and WebKit), which are includedin Android itself and are therefore trusted. This measurehas thus far been thought sufficient.

Nevertheless, we discovered that even trusted systemlibraries can be exploited by a malicious app to exposetainted data with no alarms. For example, because SQLiteis written in native code, a malicious app could washtaints off a tracked data item simply by storing it into thedatabase and reading it back. More generally, any statefullibraries that provide the ability to put and later retrievedata are vulnerable to attacks. Since disabling system li-braries is impractical (e.g., 12/14 apps in §2 depend onSQLite), we instead suggest identifying and modifyingall stateful system libraries to propagate taints.

To date, we modified two such libraries: SQLite andWebKit. For SQLite, we implemented taint propagationby persisting taints along with the data (see §4.4). ForWebKit, we disabled caching of rendered Web pages.While important for security, we leave identifying andfixing other libraries for future work and for now sug-gest notifying the cloud about a potential leak if sensitivedata were handed over to an unchecked native library. Wesuggest that TaintDroid proceed similarly. We discuss thecoverage limitation further in §8.

6 ApplicationsWe ported three of our “dirtiest” apps from §2 ontoCleanOS and built a proof-of-concept, add-on service.

6.1 Extending Apps with SDOsAlthough unmodified apps can benefit from the coarsedefault SDOs that CleanOS offers, they can also definetheir own SDOs for fine-grained control of sensitive data.To demonstrate how apps can be “ported” to our API, wemodified two open-source apps – Email and KeePass – todefine fine-grained SDOs. Changes for both apps weretrivial. For Email, we added these seven lines of code:� �

SDO subjectSDO = new SDO(”Subject”, SDO.LOW);subjectSDO.add(mSubject);SDO bodySDO = new SDO(”Content of ” + mSubject, SDO.MED);bodySDO.add(mTextContent);bodySDO.add(mHtmlContent);bodySDO.add(mTextReply);bodySDO.add(mHtmlReply);� �

We added each email’s subject to a global, low-sensitivitySDO and created a medium-sensitivity content SDO forits body, using the subject itself as the description. Pass-words, already embedded in an SDO by our defaultheuristics, needed no changes.

For KeePass, changes were similarly trivial (7 lines):

Figure 5: Screenshot of Audit Service Log in App Engine.� �SDO masterSDO = new SDO(”Master key”, SDO.MED);SDO entrySDO = new SDO(”Entry”, SDO.HIGH);masterSDO.add(mPassword); // In SetPassword.javamasterSDO.add(masterKey); // In PwDatabase.javaentrySDO.add(password); // In PwEntryV3.javaentrySDO.add(pass); // In EntryEditActivity.javaentrySDO.add(conf); // In EntryEditActivity.java� �

6.2 Add-on Cloud ServicesCleanOS evicts sensitive data to the cloud to prevent un-mediated accesses by device thieves. However, by itself,CleanOS cannot guarantee data security. For example,a thief could interact with the apps in an unlocked de-vice or force all SDOs to decrypt. Therefore, CleanOSprovides device-side mechanisms necessary for clouds tobuild clean-semantic security add-ons, such as assured re-mote wipeout or data exposure auditing. Such services al-ready exist today (e.g., Apple’s iCloud and Gmail’s two-step verification), but we maintain that their semanticsare unclear given the state of today’s devices. We nextdescribe an add-on service we trivially built on CleanOS.Prototype Auditing Service. Inspired by Keypad [15],we implemented an auditing service on CleanOS. Its goalis to provide users with audit logs of what was on the de-vice at the time of theft and what has been accessed since.The auditing service integrates with the CleanOS serviceand both are hosted on App Engine. When a device reg-isters an SDO or requests a decryption key, the cloud logsthat operation with the app name, SDO, and current time.In this way, the user can learn from the audit log exactlywhat data was leaked. For instance, Figure 5 shows asample audit log that contains entries for SDO registra-tion and key fetching. Were these operations to occur af-ter the device was stolen, the user will know that the emailpassword and KeePass entry may have been leaked.

Crucial to any auditing system is precision. In the au-dit log, data in different buckets of the same SDO areindistinguishable. Thus, accessing the data in one bucketmay cause false alarms for evicted buckets of the sameSDO. Using a finer SDO granularity helps reduce falsepositives. We evaluate audit precision in §7.1.Further Examples. A cloud could build many other use-ful services on CleanOS. For example, the cloud could:allow its mobile users to revoke data access from theirmissing devices, disable access to sensitive data whilethe phone is outside the corporate network, and performtheft detection based on access patterns. A variety of en-tities would find such services useful to host. For ex-ample, a company might integrate with CleanOS on the


(a) Sensitive data exposure period. (b) Sensitive data lifetime.

App Password Contents Metadata

Email without CleanOS 100% 95.5% 99.0%

Email with default SDOs 6.5% 5.9% 5.9%

CleanEmail (fine SDOs) 6.5% 0.3% 1.6%

AppWithout CleanOS

With CleanOS

1bucket

32buckets

1024buckets

Email

Password 22.5h 1h 28m 1h 19m 1h 11m

Contents 20.9h 3 min 1 min 1 min

Metadata 20.9h 18 min 6 min 6 min

Facebook 24h 3h 54m 3h 51m 3h 29m

Mint 24h 1h 10m 1h 2m 55 min

(c) Audit precision.

Figure 6: Data Exposure. (a) Fraction of time in which sensitive data was exposed. (b) Maximum sensitive data retention period.(c) Average probability over time that tainted data was actually exposed, given that the audit log shows its SDO as exposed.

device for all corporate apps (e.g., corporate email, cus-tomer database), to access its auditing, revocation, andgeography-constrained services. Similarly, Gmail couldintegrate with CleanOS to prevent email exposure afterauthentication-token revocation.

7 EvaluationWe next quantify CleanOS’ security, performance, andenergy characteristics. Our goal is to show that CleanOSsignificantly reduces sensitive data exposure while pro-viding reasonable performance and energy consumption,even over cellular networks. We conducted all exper-iments on rooted Samsung Nexus S phones runningCleanOS on Android 2.3.4 and TaintDroid 2.3.

7.1 Data Exposure EvaluationTo evaluate the data exposure benefits of CleanOS, wepose three questions: How much does eviction limit ex-posure of sensitive data? How much do default SDOheuristics limit exposure? How effective is the auditingservice? To answer these questions, we recorded a 24-hour trace of one of the authors’ phone running CleanOSas it was used to interact with regular apps, includingEmail, Facebook, and Mint. For Email, we experimentedwith both the unmodified app and our modified version ofit, which we call CleanEmail (see §6.1). The Email appwas configured with the author’s personal account, whichreceives about ten new mails daily, and with the default15-minute refresh period. Facebook and Mint had wid-gets enabled, which made them continuous services.Sensitive Data Exposure Period. We measured the ex-posure period for three types of tainted data (password,content, and metadata) in the Email app. Figure 6(a)shows the fraction of time that each type of tainted datawas exposed in RAM. Without CleanOS, the passwordwas maintained in RAM all the time, and the content andmetadata were exposed over 95% of the time. CleanOSreduced password exposure to 6.5%. For email content,the unmodified Email app with default SDOs reduced ex-posure time from 95.5% to 5.9%, and modifying the appto support fine-grained SDOs further reduced it to 0.3%.Similar observations held for metadata. To be clear, theseresults depend on workloads. From another, much moreintensive email workload – that registered for many mail-ing lists and Twitter feeds – we obtained a result of 7.3%and 12.7% for content and metadata, respectively. Over-

all, results demonstrate a significant reduction in expo-sure times for tainted data. Moreover, they show that ourdefault heuristics protect sensitive data reasonably well.Sensitive Data Lifetime. As SDO lifetime is critical tosystem security, we must also examine the maximum pe-riod that a tainted object could be retained in RAM. Fig-ure 6(b) shows the retention time for the longest-livedtainted object in three applications, where we break downemail into three types. Without CleanOS, all observed ap-plications retained certain tainted objects for more than20 hours. With CleanOS, the maximum SDO lifetimewas dramatically reduced. For instance, the Email appkept some metadata objects for as long as 20.9 hours,which CleanOS reduced to only 6 minutes when using1024 buckets. For Facebook and Mint, the impact ofbucketing on sensitive data lifetime was more limited be-cause these apps tend to use most objects in an SDO atthe same time. Overall, these results indicated that themobile device was significantly cleaner with CleanOS.Audit Precision. We next evaluated the effectiveness ofthe auditing service we built on CleanOS (see §6.2). Wecompared audit precision across four levels of SDO gran-ularity in Email: (1) mono-SDO, where we marked dataas only “sensitive” or “non-sensitive,” (2) default SDOs,where we used default heuristics, (3) coarse SDOs, wherethe application defined one content SDO and one meta-data SDO for all emails, and (4) fine SDOs, where eachemail had its own content and metadata SDOs. We defineaudit precision as the average probability over time thatthe tainted data is actually exposed on the device, giventhat the audit log shows its SDO has not been evicted.

Figure 6(c) shows audit precision for the Email app’spassword, content, and metadata. Password auditing was50.0% precise with mono-SDO but increased to 95.1%with default SDOs. The content and metadata, however,had poor precision (<3%) without application support:CleanOS could not differentiate data coming from theInternet and hence added every incoming object to theSSL SDO. With coarse, application-specific SDOs, au-dit precision for email content and metadata was 9.1%and 61.3%, respectively. When fine application-specificSDOs were available, audit precision reached 100%.Thus, our default SDOs were effective in auditing pass-word exposure, but application adaptation was needed toprovide precise auditing for other types of sensitive data.


Android

2.3.4

TaintDroid

2.3

CleanOS

not evicted

evicted, cached

evicted, Wi-Fi

evicted, 3G

Untainted Primitive 0.00021 0.00022 0.00026 - - -

Tainted Primitive - 0.00023 0.00056 1.24 22.844 336.07

Untainted Array 0.00027 0.00029 0.00035 - - -

Tainted Array (S) - 0.00030 0.00075 1.4 21.652 308.71

Tainted Array (M) - 0.00030 0.00075 1.331 21.702 316.79

Tainted Array (L) - 0.00030 0.00075 2.355 22.365 317.97

Figure 7: Micro-operation Performance (milliseconds).CleanOS Java object field access times compared with Android,TaintDroid. Times for non-sensitive and sensitive fields for var-ious eviction states. Averages over 1,000 accesses.

7.2 Performance EvaluationWe next evaluate the performance impact of CleanOS un-der different workloads and networking conditions. Here,we aim to: (1) quantify raw performance overheads, (2)demonstrate that CleanOS is practical over Wi-Fi for pop-ular apps, and (3) show how our optimizations makeCleanOS practical even over slow, cellular networks.In our experience, obtaining reliable and repeatable re-sults from the cellular network is tremendously difficult;hence, our results used emulated Wi-Fi and 3G networkswith RTTs configured at 20ms and 300ms, respectively.Because our transmission units were tiny (keys were 16-byte long), we did not enforce bandwidth restrictions.Micro-operation Performance Overheads. To evalu-ate raw performance overheads, we measured Java objectfield-access times for Android, TaintDroid, and CleanOS.Figure 7 compares them for four field types: primitives(int), small arrays (16 bytes), medium arrays (4KB), andlarge arrays (16KB). For CleanOS, we show access timesboth for non-sensitive fields (the vast majority) and sensi-tive fields under various eviction states. CleanOS’ accessoverhead for non-sensitive fields was small comparedwith TaintDroid (16%), which itself was close to rawAndroid (6% overhead for TaintDroid). The overheadfor sensitive field access increased to 141% over Taint-Droid: CleanOS performed last-time-of-use bookkeepingon every Dalvik field access instruction (e.g., OP AGET,OP IGET) that involved a tainted field. Further, whenevicted, CleanOS access overhead spiked dramatically,especially when the evicted field’s key was not cachedon the device but was fetched over Wi-Fi or 3G. More-over, unlike in Android and TaintDroid, access times forevicted arrays in CleanOS depended on the array’s sizebecause decryption times increase with data size. For ex-ample, the “evicted, cached” column shows that decrypt-ing a tainted array grew by 68% when the array’s sizeincreased from 16B to 16KB. Fortunately, in practice,sensitive fields are extremely rare compared with non-sensitive fields. For example, our email trace showed anaverage of 102,907 fields at any time, of which merely1,889 were tainted (or 1.83%). Hence, CleanOS shouldacceptably affect real app performance, as shown next.Application Performance. Figure 8(a) shows the time

to launch several popular apps (i.e., bring them into theforeground) and perform typical actions, such as open-ing an email, viewing a KeePass entry, or loading a Webpage. We chose three Web pages: a simple one (https://iana.org/domains/example) and two popular andmore complex ones (https://news.google.com andhttps://cnn.com). For CleanOS, results labeled “notevicted” correspond to cases where all accessed objectswere decrypted, while results labeled “evicted” corre-spond to cases where objects were all evicted.

In the “not evicted” case, interaction with the apps in-curred a limited performance penalty compared with bothTaintDroid and Android. For example, 8/13 operationsincurred less than 100ms penalties over TaintDroid, and7/13 did so over Android. Such penalties will likely gounnoticed by users, who are known to perceive delayscoarsely [29]. Hence, when users interact with a recentlyused app, they should not feel CleanOS’ presence.

When users interact with a cold app (“evicted”columns for unoptimized CleanOS), however, perfor-mance degraded but remained usable for Wi-Fi networks.Our cheapest app is the browser, for which CleanOS in-curred 8-23% overheads over Android for all operations.The reason is two-fold: (1) the browser deals with lit-tle sensitive data, and (2) during page loads, the browserfetches large amounts of data over Wi-Fi, which dwarfCleanOS’ key traffic delays. The most expensive app forCleanOS is CleanEmail, which incurred a larger penaltythan Email for “evicted” launches due to more granulartainting. For example, while Email needed to fetch 2 keysto load an email, CleanEmail needed to fetch 3 keys.

Over 3G, CleanOS penalties after eviction became sig-nificant. While some operations remained within rea-sonable bounds (e.g., launching the browser and loadingiana.org or cnn.com), many operations incurred over-heads in excess of 100%. For example, loading an emailonto the screen jumped from 197ms to 1.1s for Email and1.4s for CleanEmail. Such delays likely affect usability.Effect of Optimizations on Application Performance.Column “Optimized CleanOS” in Figure 8(a) shows theelapsed time of repeat operations under our bulk prefetch-ing optimization (see §5). All timed operations were in-voked in the previous application session; therefore, allof their relevant keys were prefetched together as part ofone bulk request during the timed session. The resultsshow dramatic improvements in performance for bothlaunching and interacting with the apps. For example,CleanEmail – our most expensive application – launchedin 589ms over 3G compared with 919ms on unoptimizedCleanOS (35.9% improvement) and loaded a previouslyread email in 420ms compared with 1.4s (71% improve-ment). In general, this optimization lets an app re-launchincur little more than one RTT over non-evicted CleanOS,while subsequent repeat operations incur no RTT. Natu-


Application ActionAndroid

2.3.4TaintDroid

2.3

CleanOSOptimized CleanOS

not evicted evicted, Wi-Fi evicted, 3G evicted, 3G*

EmailLaunch 197 202 241 312 919 589

Read Message 212 254 387 501 1165 379

CleanEmailLaunch - - 291 315 902 598

Read Message - - 452 526 1472 421

KeePassLaunch 173 192 217 221 527 672

Read Entry 125 150 146 155 479 135

Browser

Launch 130 151 160 144 222 138

Load Page (iana)

Wi-Fi 488 483 658 605 - -

3G 2067 2114 2125 - 2136 2031

Load Page (GNews)

Wi-Fi 1072 1043 1270 1160 - -

3G 1717 2475 2475 - 3536 2942

Load Page (CNN)

Wi-Fi 1065 1136 1394 1446 - -

3G 4570 4709 4325 - 4619 4538

* Actions were performed before.

(a) App Performance (milliseconds).

A T C A T C A T C0

20

40

60

80

100

120

140

160

180

Network

CPU

LCD

Ene

rgy (

Jo

ule

s/h

our)

A – AndroidT – TaintDroidC – CleanOS

0 6.4 8.4 0 2.9 8.60 3.8 8.2

CleanEmail KeePassBrowser

(b) Energy over Wi-Fi.Figure 8: Application Performance and Energy Consumption. (a) Performance of various popular app activities under Android,TaintDroid, and CleanOS for various eviction states and configurations. Results are averages over 40 runs. (b) Hourly energyconsumption attributed by PowerTutor to the three apps when running a long-term synthetic workload for at least 3 hours. Numberson top of each bar show energy overhead over default Android in percent.

rally, our optimization will not benefit non-repeat opera-tions, such as loading a brand new or long-unread email.However, one type of operation that will always benefit isapp launch, a latency-sensitive operation on mobiles.

Despite their performance benefits, our optimizationsmay increase data exposure. When applying these opti-mizations to the workloads in §7.1, we obtained limited,but non-trivial, exposure impact. The period for each typeof tainted data increased by up to 0.9 percentage pointsfor the workload in Figure 6(a), and by up to 23.2 percent-age points for our intensive Email workload. Prefetchingkeys from multiple sessions would cause further expo-sure. Hence, CleanOS should best apply this optimiza-tion only in specific cases (e.g., over 3G).Overhead Estimation for SDO Stable Storage Exten-sion. Thus far, our results show CleanOS’ overheads foreviction of in-RAM SDOs. While we have not fully im-plemented the SDO extension to stable storage, we nowoffer rough estimates for the extra overheads to expectfrom such an extension. We expect the major sourcesof overhead to be: (1) the key fetches required to ac-cess encrypted database items, and (2) the extra encryp-tion/decryption that occurs when accessing these items.To account for (1), we ran experiments with our test ap-plications that instruct CleanOS to fetch the appropri-ate decryption keys for any tainted database items beingaccessed. To account for (2), we added an extra 20%overhead per query, a number reported by CryptDB [33],which also does per-item encryption.

With this methodology, we estimate that extendingSDOs to SQLite would result in additional overheadsranging between 0-65% on 3G over CleanOS with in-RAM SDOs. We predict that these operations will sufferthe most: KeePass Launch (869ms, or 64.9% additionaloverhead), CleanEmail Read (1887ms, or 28.2% addi-tional overhead), and Browser Load (2542ms, 4086ms,and 4573ms for iana.org, news.google.com, and cnn.com, respectively, or 15-19% additional overhead). Most

of these overheads (82-99% across all apps) are due toextra RTTs incurred by necessary key fetches, which areoptimizable via batch prefetching. Thus, overall, we be-lieve that our system will be practical from a performanceperspective even when implemented in full.

7.3 Energy and Network EvaluationCleanOS’ encryption, network traffic, and extra GCsraise concerns about its impact on energy consumption.To evaluate this impact, we ran coarse-grained experi-ments that drove a simple, long-term workload againsteach app (CleanEmail, Browser, and KeePass) usingMonkeyRunner [17] and measured consumption usingthe PowerTutor online power monitor [42]. The work-load repeatedly launched an app, performed a set of typ-ical tasks (such as reading emails, accessing entries inKeePass, and visiting Web pages in the browser), sent theapp into the background, and then slept for 15 minutes.Each app interaction lasted for 36-46s, after which wepromptly turned off the LCD. We ran the workload con-tinuously for at least 3 hours and plotted per-app powerconsumption as reported by PowerTutor.

Figure 8(b) shows energy consumption for Android,TaintDroid, and CleanOS over a real home Wi-Fi net-work. For each app, we show the energy consumed bythe LCD, CPU, and Wi-Fi. Results show that CleanOS’total energy overheads over Wi-Fi were small comparedwith both Android and TaintDroid: 8.2-8.4% over An-droid (see labels above bars) and 1.9-5.5% over Taint-Droid. Drilling down on resource overheads, we observethat CleanOS increased energy consumption of both thenetwork (44-45%) and the CPU (32-74%), but those over-heads were dwarfed by the LCD energy draw. In general,our overheads were smallest for the browser, which itselfconsumed relatively more CPU and network energy, andlargest for KeePass, a lightweight application that per-formed little computation and had no network traffic.

Over 3G, energy overheads due to network traffic willlikely increase. Our experience shows that experiment-


Dat

a tra

nsm

itted

(KB

/min

)

Figure 9: Network Traffic Patterns of Apps vs. CleanOS.CleanOS traffic vs. app traffic for a one-hour trace. The Y axisis in log scale. In our cases, the phone has background traffic,which is included in both app and CleanOS lines.

ing with 3G networks leads to very unstable and unre-peatable results; hence, for these networks, we rely onan analytic evaluation grounded in a study of CleanOS’network traffic. Figure 9 compares CleanOS’ traffic pat-terns to those of the three apps using one-hour tracesfrom our energy experiments. It shows that CleanOS’network consumption depends on the application’s ownnetwork profile. For networked apps, such as email andbrowser, CleanOS’ traffic closely follows the app’s owntraffic distribution over time. For example, for email, ofthe 24 minutes during which CleanOS issued some traf-fic, only 9 of those had no accompanying app traffic; forthe browser, only 1 out of 5 one-minute periods did so.From an energy perspective, this means that CleanOSusually piggybacks on the app’s own use of the networkand only rarely needs to hold the interface up for its ownpurposes. On the other hand, for local-only apps, such asKeePass, CleanOS uses the network mostly for its ownpurpose; but even in such cases, however, its traffic willbe rare, brief, and small (≤ 10KB/min). Thus, we expectCleanOS to be practical from an energy perspective.

8 Security Discussion and LimitationsWe now discuss CleanOS’ security implications and limi-tations. There are two types of data that an attacker mightseek: unevicted data and evicted data. CleanOS does notprotect unevicted data on a stolen device; instead, it seeksto minimize the amount of such data. An audit-enabledcloud service can provide users with a robust audit trail ofdata exposed at the time of loss and data retrieved since.For evicted data, clouds can do much more. For example,after theft has been detected, they can revoke the device’saccess to still evicted data. They can also monitor ac-cesses to keys to detect anomalous behavior.

A thief might also try to retrieve keys for all evictedSDOs before the cloud disables them. Such aggressive at-tackers could be identified via anomalous access-pattern

detection. To evade detection, the attacker could retrieveSDO keys only for objects of interest, such as emails withtempting subjects. While some attackers may be unwill-ing to do so for fear of revealing their identities, the cloudcan provide an audit log of such accesses.

Attackers might also attempt to break the disconnec-tion password to hoard keys for apps of interest withoutraising suspicion. CleanOS could enforce sufficient en-tropy to make the disconnection password, which is ex-tremely rarely used, much stronger than a regular pass-word (which a user must type every time he unlocks hisdevice). However, even if the password were broken, thecloud could provide evidence of the attacker’s behavior.

Adversaries may perform network attacks to sniff ordisrupt CleanOS device-cloud traffic. To prevent sniff-ing of keys from network traffic, we encrypt connec-tions and authenticate the device to the cloud using a pre-established secret key (akin to the device token in Gmail’stwo-factor verification) and the cloud using public keycryptography. An attacker could also disrupt CleanOSdevice-cloud communication to induce CleanOS into anaccumulation mode, where it defers eviction until cloudconnectivity returns. To defend, CleanOS bounds itseviction delay for temporary disconnections. Moreover,a thief could prevent eviction messages from arriving atthe cloud. However, dropping those messages will notaffect confidentiality since data eviction will complete asplanned, but it might raise auditing false positives.

One CleanOS limitation is its limited coverage outsidethe Java realm. To be clear, expunging sensitive datafrom Java is an important contribution: 9/14 apps in Fig-ure 2(b) would expose some sensitive data permanentlyin RAM if we did not do so. Moreover, we have incor-porated some basic multi-level secure deallocation tech-niques and have modified two popular native libraries tolimit exposure (SQLite and WebKit). However, any dataretained in other buffers or caches in the OS or nativelibraries remains exposed. To limit this exposure, we rec-ommend: (1) incorporating additional OS data scrubbingmechanisms [10], (2) inspecting all remaining system li-braries for caches as we do for SQLite and WebKit, and(3) either disabling all third-party libraries (an approachsimilar to TaintDroid’s [12]) or informing the cloud aboutany data leakages to uninspected third-party libraries.

9 Related WorkCleanOS builds upon prior work that we now describe.Encrypted File Systems. Encrypted file systems [11]and full-disk encryption [26, 38] are designed to protectdata stored on a vulnerable device, but they do not pro-tect data in RAM. Moreover, as discussed in §3 (ThreatModel) and in prior work [15, 41], these systems can failin the real world due to human factors (e.g., non-existentor poor passwords) and physical attacks (e.g., key re-


trieval from RAM via cold-boot attacks [19]). CleanOSrecognizes these limitations and promptly removes un-used data from the vulnerable device.Encrypted RAM Systems. Encrypted RAM systems– such as XOM [23], CryptKeeper [31], and encryptedswap [34] – encrypt data while it sits in RAM. Crypt-Keeper resembles the CleanOS model by encrypting allmemory pages except for a small working set, therebyachieving a similar encrypted-unless-in-use effect asCleanOS. However, while the data is encrypted in thesesystems, the decryption keys themselves are still avail-able in RAM and potentially accessible to memory-harvesting unless extra hardware is deployed. Moreover,if the device were unlocked or the thief found the user’spassword, encrypted RAM would have no effect.

ZIA [7, 8] encrypts mobile data in RAM and on diskwhenever a device is not near its owner. The user wears abeaconing token at all times, whose presence is detectedby the mobile. Like ZIA, CleanOS encrypts data after aperiod of non-use, but the granularities, method, and us-age model are different. For example, we disable unuseddata at the Java object level as opposed to the device level,evict data to clouds for increased post-theft control, anddo not require users to carry (and secure!) tokens.Mobile Wipe-Out Systems. Varied commercial wipe-out systems exist and help increase users’ post-theft datacontrol. For example, remote wipe-out systems, such asiCloud [3], let the users send “kill” messages to lost de-vices. Unfortunately, these systems require network con-nectivity to function correctly. If the thief prevents deviceconnectivity (e.g., by wrapping it into a Faraday cage),the device will not receive the message and therefore notcomplete its wipeout. Moreover, configuring the deviceto self-destruct after a number of failed authentication at-tempts helps prevent access to file system data, but it doesnot preclude memory harvesting attacks, such as coldbootimaging [19]. Such attacks are particularly problematicon mobile devices, which hardly ever power off.Cloud-based Mobile Security Services. The value ofthe cloud for increased data control is being increasinglyrecognized. Examples of cloud-based security servicesinclude: online data access revocation with two-step veri-fication [18], location-based access control with location-aware encryption [37], and cloud-based authenticationwith capture-resilient cryptography [25]. Generally, thesesystems prevent the compromise of data not already ex-posed on the device, but they do not guarantee securityfor mobile-resident data. For example, none of thesesystems takes RAM-resident data into account, and theGoogle two-step verification does not even consider stor-age. CleanOS cleanses device RAM and storage in sup-port of such security services.Keypad. Particularly relevant is Keypad [15], an audit-ing file system for old-generation mobile devices, such as

laptops and USB sticks, that achieves file-level, strong-semantic auditing. CleanOS shares Keypad’s threatmodel, and our auditing service was inspired by it. How-ever, in addition to its support for in-RAM data auditing,CleanOS also differs from Keypad in its focus on new-generation mobile technologies, such as Android, whichhave distinct auditing granularity requirements. For ex-ample, file-level auditing in Keypad would be ineffectivefor apps using the SQLite database since they all wouldbe stored within one single file. Instead, CleanOS definesSDOs, an abstraction that encompasses fine-grained ob-jects, database items, and sdcard files.Secure-Deletion Systems. Secure deletion has been rec-ognized as a key OS primitive. It erases data in mem-ory [6], OS buffers [10], and stable storage [30, 39, 4]once the data is not needed by the application. CleanOSexplicitly assumes the existence and robustness of suchsystems, but addresses a distinct, important part of thesensitive data exposure problem for the first time: se-curing data explictly hoarded by applications for perfor-mance or convenience. CleanOS SDOs resemble the self-destructing data abstraction in Vanish [16] in that they“disappear” over time, but the setting is different: Van-ish makes Web data disappear after a specified time post-creation, whereas SDOs make mobile data disappear ifthey are unused for a specified time.

10 ConclusionsThis paper described CleanOS, a new design for theAndroid OS that manages sensitive data rigorously andkeeps mobile devices clean at any point in time. UnlikeAndroid, which lets sensitive data accumulate in cleartextRAM and on disk, CleanOS eliminates it from the vulner-able device by evicting it to the cloud whenever it is notneeded on the device. It provides a clean-semantic foun-dation for clouds to build add-on services, such as dataaccess revocation after a device has been lost or post-theftdata exposure auditing. We implemented CleanOS by in-strumenting Android’s Java virtual machine to securelyevict sensitive data objects after a specified period of non-use. On top of CleanOS, we built a sample auditing cloudservice. Our experiments demonstrate that CleanOS lim-its data exposure significantly while imposing acceptableperformance overheads and offering sound semantics forcloud-based applications.

11 AcknowledgementsWe thank our shepherd, Petros Maniatis, and anonymousreviewers for their valuable comments. We also thankSteve Gribble, Angelos Keromytis, Hank Levy, SimhaSethumadhavan, Salvatore Stolfo, and Junfeng Yang fortheir feedback. This work was supported by DARPAthrough FA8650-11-C-7190 and FA8750-10-2-0253 andNSF through CNS-0905246.


References

[1] R. Anderson and M. Kuhn. Tamper resistance: A cautionarynote. In Proc. of the USENIX Workshop on Electronics Com-merce, 1996.

[2] Android Developers Blog. Avoiding memory leaks.android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html, 2009.

[3] Apple iCloud. Find my iPhone, iPad, and Mac. www.apple.com/icloud/features/find-my-iphone.html, 2012.

[4] D. Boneh and R. Lipton. A revocable backup system. In Proc. ofUSENIX Security, 1996.

[5] S. Chen, M. Kozuch, T. Strigkos, and et.al. Flexible hardwareacceleration for instruction-grain program monitoring. In Proc. ofthe Annual International Symposium on Computer Architecture(ISCA), 2008.

[6] J. Chow, B. Pfaff, T. Garfinkel, and M. Rosenblum. Shreddingyour garbage: Reducing data lifetime through secure deallocation.In Proc. of USENIX Security, 2005.

[7] M. D. Corner and B. D. Noble. Zero-interaction authentication.In Proc. of the ACM Annual International Conference on MobileComputing and Networking, 2002.

[8] M. D. Corner and B. D. Noble. Protecting applications with tran-sient authentication. In Proc. of the International Conference onMobile Systems, Applications, and Services (MobiSys), 2003.

[9] L. P. Cox and P. Gilbert. Redflag: Reducing inadvertent leaks bypersonal machines. Technical Report TR-2009-02, Duke Univer-sity, 2009.

[10] A. M. Dunn, M. Z. Lee, S. Jana, S. Kim, M. Silberstein, Y. Xu,V. Shmatikov, and E. Witchel. Eternal sunshine of the spotlessmachine: Protecting privacy with ephemeral channels. In Proc. ofthe USENIX Symposium on Operating Systems Design and Imple-mentation (OSDI), 2012.

[11] EncFS. www.arg0.net/encfs, 2010.[12] W. Enck, P. Gilbert, B. gon Chun, L. P. Cox, J. Jung, P. McDaniel,

and A. N. Sheth. TaintDroid: An information-flow tracking sys-tem for realtime privacy monitoring on smartphones. In Proc. ofthe USENIX Symposium on Operating Systems Design and Imple-mentation (OSDI), 2010.

[13] Federal Communications Commission. Announcementof new initiatives to combat smartphone and data theft.www.fcc.gov/document/announcement-new-initiatives-combat-smartphone-and-data-theft, 2012.

[14] Future of Privacy Forum, Center for Democracy & Tech-nology. Best practices for mobile applications devel-opers. www.futureofprivacy.org/wp-content/uploads/Apps-Best-Practices-v-beta.pdf, 2011.

[15] R. Geambasu, J. P. John, S. D. Gribble, T. Kohno, and H. M.Levy. Keypad: An auditing file system for theft-prone devices.In Proc. of the ACM European Conference on Computer Systems(EuroSys), 2011.

[16] R. Geambasu, T. Kohno, A. Levy, and H. M. Levy. Vanish:Increasing data privacy with self-destructing data. In Proc. ofUSENIX Security, 2009.

[17] Google Inc. MonkeyRunner. developer.android.com/tools/help/monkeyrunner_concepts.html, 2012.

[18] Google Inc. Two-step verification. support.google.com/accounts/bin/topic.py?hl=en&topic=28786, 2012.

[19] J. A. Halderman, S. D. Schoen, N. Heninger, W. Clarkson,W. Paul, J. A. Calandrino, A. J. Feldman, J. Appelbaum, and E. W.Felten. Lest we remember: Cold boot attacks on encryption keys.In Proc. of USENIX Security, 2008.

[20] Imperva. Consumer password practices. www.imperva.com/docs/WP_Consumer_Password_Worst_Practices.pdf, 2010.

[21] Intel Corporation. Laptop security with Intel Anti-Theft technol-

ogy. www.intel.com/content/www/us/en/architecture-and-technology/anti-theft/anti-theft-general-technology.html, 2012.

[22] H. Krawczyk and P. Eronen. HMAC-based extract-and-expandkey derivation function (HKDF). tools.ietf.org/html/rfc5869, 2010.

[23] D. Lie, C. Thekkath, M. Mitchell, P. Lincoln, D. Boneh,J. Mitchell, and M. Horowitz. Architectural support for copy andtamper resistant software. In Proc. of the International Confer-ence on Architectural Support for Programming Languages andOperating Systems (ASPLOS), 2000.

[24] Lookout Mobile Security. Lost and found: The challengesof finding your lost or stolen phone. blog.mylookout.com/blog/2011/07/12/lost-and-found-the-challenges-of-finding-your-lost-or-stolen-phone, 2011.

[25] P. MacKenzie and M. Reiter. Networked cryptographic devicesresilient to capture. In Proc. of USENIX Security, 2001.

[26] Microsoft Corporation. Windows 7 BitLocker executive overview.technet.microsoft.com/en-us/library/dd548341(WS.10).aspx, 2009.

[27] Microsoft Corporation. Create strong passwords. www.microsoft.com/security/online-privacy/passwords-create.aspx, 2012.

[28] M. Milian. U.S. government, military to get secure An-droid phones. www.cnn.com/2012/02/03/tech/mobile/government-android-phones/index.html, 2012.

[29] J. Nielsen. Usability Engineering. Morgan Kaufmann, 1994.[30] R. Perlman. File system design with assured delete. In Proc. of

the Annual Network and Distributed System Security Symposium(NDSS), 2007.

[31] P. A. H. Peterson. Cryptkeeper: Improving security with en-crypted RAM. In Proc. of the IEEE International Conference onTechnologies for Homeland Security (HST), 2010.

[32] Ponemon Institute. The lost smartphone problem.www.mcafee.com/us/resources/reports/rp-ponemon-lost-smartphone-problem.pdf, 2011.

[33] R. A. Popa, C. M. S. Redfield, N. Zeldovich, and H. Balakrish-nan. CryptDB: Protecting confidentiality with encrypted queryprocessing. In Proc. of the ACM Symposium on Operating Sys-tems Principles (SOSP), 2011.

[34] N. Provos. Encrypting virtual memory. In Proc. of USENIX Se-curity, 2000.

[35] J. Robertson. Security chip that does encryption in PCshacked. www.usatoday.com/tech/news/computersecurity/2010-02-08-security-chip-pc-hacked_N.htm, 2010.

[36] M. Savage. NHS ‘loses’ thousands of medical records.www.independent.co.uk/news/uk/politics/nhs-loses-thousands-of-medical-records-1690398.html, 2009.

[37] A. Studer and A. Perrig. Mobile user location-specific encryption(MULE): Using your office as your password. In Proc. of theACM Conference on Wireless Network Security (WiSec), 2010.

[38] Symantec Corporation. PGP whole disk encryption. www.symantec.com/whole-disk-encryption, 2012.

[39] Y. Tang, P. P. C. Lee, J. C. S. Lui, and R. Perlman. FADE: Secureoverlay cloud storage for file assured deletion. In Proc. of theInternational ICST Conference on Security and Privacy in Com-munication Networks (SecureComm), 2010.

[40] W3C. Mobile app best practices. www.w3.org/TR/mwabp, 2010.[41] A. Whitten and J. Tygar. Why Johnny can’t encrypt: A usability

evaluation of PGP 5.0. In Proc. of USENIX Security, 1999.[42] L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. Dick, Z. M. Mao, and

L. Yang. Accurate online power estimation and automatic bat-tery behavior based power model generation for smartphones. InProc. of the IEEE/ACM/IFIP International Conference on Hard-ware/Software Codesign and System Synthesis, 2000.

cleanos: limiting mobile data exposure with idle eviction€¦ · usenix association 10th usenix...

Documents