A Mimicry Privacy Shield a System’S Approach to Data Privacy on Public Cloud
Total Page:16
File Type:pdf, Size:1020Kb
Mimesis Aegis: A Mimicry Privacy Shield A System’s Approach to Data Privacy on Public Cloud Billy Lau, Simon Chung, Chengyu Song, Yeongjin Jang, Wenke Lee, and Alexandra Boldyreva College of Computing, Georgia Institute of Technology, Atlanta, GA 30332 fbilly, pchung, csong84, yeongjin.jang, wenke, [email protected] Abstract on Android: imperceptible encryption/decryption la- Users are increasingly storing, accessing, and ex- tency and a low and adjustable false positive rate when changing data through public cloud services such as searching over encrypted data. those provided by Google, Facebook, Apple, and Mi- crosoft. Although users may want to have faith in cloud 1 Introduction providers to provide good security protection, the confi- dentiality of any data in public clouds can be violated, A continuously increasing number of users now utilize and consequently, while providers may not be “doing mobile devices [2] to interact with public cloud services evil,” we can not and should not trust them with data con- (PCS) (e.g. Gmail, Outlook, and WhatsApp) as an es- fidentiality. sential part of their daily lives. While the user’s con- To better protect the privacy of user data stored in the nectivity to the Internet is improved with mobile plat- cloud, in this paper we propose a privacy-preserving sys- forms, the problem of preserving data privacy while in- tem called Mimesis Aegis (M-Aegis) that is suitable for teracting with PCS remains unsolved. In fact, news about mobile platforms. M-Aegis is a new approach to user the US government’s alleged surveillance programs re- data privacy that not only provides isolation but also pre- minds everybody about a very unsatisfactory status quo: serves the user experience through the creation of a con- while PCS are essentially part of everyday life, the de- ceptual layer called Layer 7.5 (L-7.5), which is inter- fault method of utilizing them exposes users to privacy posed between the application (OSI Layer 7) and the user breaches, because it implicitly requires the users to trust (Layer 8). This approach allows M-Aegis to implement the PCS providers with the confidentiality of their data; true end-to-end encryption of user data with three goals but such trust is unjustified, if not misplaced. Incidents in mind: 1) complete data and logic isolation from un- that demonstrate breach of this trust are easy to come by: trusted entities; 2) the preservation of original user ex- 1) PCS providers are bound by law to share their users’ perience with target apps; and 3) applicable to a large data with surveillance agencies [14], 2) it is the business number of apps and resilient to app updates. model of the PCS providers to mine their users’ data and In order to preserve the exact application workflow share it with third parties [11, 22, 24, 40], 3) operator er- and look-and-feel, M-Aegis uses L-7.5 to put a transpar- rors [34] can result in unintended data access, and 4) data ent window on top of existing application GUIs to both servers can be compromised by attackers [47]. intercept plaintext user input before transforming the in- To alter this undesirable status quo, solutions should put and feeding it to the underlying app, and to reverse- be built based on an updated trust model of every- transform the output data from the app before displaying day communication that better reflects the reality of the the plaintext data to the user. This technique allows M- threats mentioned above. In particular, new solutions Aegis to transparently integrate with most cloud services must first assume PCS providers to be untrusted. This without hindering usability and without the need for re- implies that all other entities that are controlled by the verse engineering. We implemented a prototype of M- PCS providers, including the apps that users installed to Aegis on Android and show that it can support a number engage with the PCS, must also be assumed untrusted. of popular cloud services, e.g. Gmail, Facebook Messen- Although there are a plethora of apps available today ger, WhatsApp, etc. that come in various combinations of look and feel and Our performance evaluation and user study show that features, we observed that many of these apps provide users incur minimal overhead when adopting M-Aegis text communication services (e.g. email or private/group 1 messaging categories). Users can still enjoy the same fering more reliable infrastructure to facilitate user quality of service1 without needing to reveal their plain- communication, but also by offering a better user text data to PCS providers. PCS providers are essen- experience [16, 58]. Ultimately, users will choose tially message routers that can function normally with- apps that feel the most comfortable. To reduce in- out needing to know the content of the messages being terference with a user’s interaction with the app of delivered, analogous to postmen delivering letters with- their choice, security solutions must be retrofittable out needing to learn the actual content of the letters. to existing apps. Solutions that repackage/rewrite Therefore, applying end-to-end encryption (E2EE) existing apps have this criterion. without assuming trust in the PCS providers seems to 3. For a solution to be sustainable, it must be easy to solve the problem. However, in practice, the direct ap- maintain and scalable: the solution must be suffi- plication of E2EE solutions onto the mobile device envi- ciently general-purpose, require minimal effort to ronment is more challenging than originally thought [65, support new apps, and withstand app updates. In the 59]. A good solution must present clear advantages to the past, email was one of the very few means of com- entire mobile security ecosystem. In particular it must munication. Protecting it is relatively straightfor- account for these factors: 1) the users’ ease-of-use, hence ward because email protocols (e.g. POP and IMAP) acceptability and adoptability; 2) the developers’ efforts are well defined. Custom privacy-preserving apps to maintain support; and 3) the feasibility and deploya- can therefore be built to serve this need. How- bility of solution on a mobile system. From this analysis, ever, with the introduction of PCS that are becom- we formulate three design goals that must be addressed ing indispensable in a user’s everyday life, a good coherently: solution should also be able to integrate security 1. For a solution to be secure, it must be properly features into apps without requiring reverse engi- isolated from untrusted entities. It is obvious that neering of the apps’ logic and/or network protocols, E2EE cannot protect data confidentiality if plain- which are largely undocumented and possibly pro- text data or an encryption key can be compromised prietary (e.g. Skype, WhatsApp, etc.). by architectures that risk exposing these values. Traditional solutions like PGP [15] and newer so- In this paper, we introduce Mimesis Aegis (M-Aegis), lutions like Gibberbot [5], TextSecure [12], and a privacy-preserving system that mimics the look and SafeSlinger [41] provide good isolation, but force feel of existing apps to preserve their user experience users to use custom apps, which can cause usabil- and workflow on mobile devices, without changing the ity problems (refer to (2)). Solutions that repack- underlying OS or modifying/repackaging existing apps. age/rewrite existing apps to introduce additional se- M-Aegis achieves the three design goals by operating at curity checks [68, 26] do not have this property a conceptual layer we call Layer 7.5 (L-7.5) that is po- (further discussed in Sect. 2.3). Solutions in the sitioned above the existing application layer (OSI Layer form of browser plugins/extensions also do not have 7 [8]), and interacts directly with the user (popularly la- this property (further discussed in Sect. 2.2), and beled as Layer 8 [19, 4]). they generally do not fit into the mobile security From a system’s perspective, L-7.5 is a transparent landscape because many mobile browsers do not window in an isolated process that interposes itself be- support extensions [7], and mobile device users tween Layer 7 and 8. The interconnectivity between do not favor using mobile browsers [27] to access these layers is achieved using the accessibility frame- PCS. Therefore, we rule out conventional browser- work, which is available as an essential feature on mod- plugin/extension-based solutions. ern operating systems. Note that utilizing accessibility features for unorthodox purposes have been proposed by 2. For a solution to be adoptable, it must preserve the prior work [56, 48] that achieves different goals. L-7.5 user experience. We argue that users will not accept extracts the GUI information of an app below it through solutions that require them to switch between dif- the OS’s user interface automation/accessibility (UIA) li- ferent apps to perform their daily tasks. Therefore, brary. Using this information, M-Aegis is then able to simply porting solutions like PGP to a mobile plat- proxy user input by rendering its own GUI (with a differ- form would not work, because it forces users to use ent color as visual cue) and subsequently handle those in- a separate and custom app, and it is impossible to put (e.g. to process plaintext data or intercept user button recreate the richness and unique user experience of click). Using the same UIA library, L-7.5 can also pro- all existing text routing apps offered by various PCS grammatically interact with various UI components of providers today. In the context of mobile devices, the app below on behalf of the user (refer to Sect.