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 transforming them to be fed to the underlying app, and reverse-transform the data from the app before display- We are now in the intersection of the cloud computing ing the plaintext data to the user. This technique allows age and mobile revolution. Increasing number of users M-Aegis to transparently integrate with most cloud ser- are storing and exchanging their data from their mo- vices without hindering usability and without the need bile devices to and through public cloud services such for reverse-engineering. We implemented a prototype of as those provided by Google, Facebook, Apple, and Mi- M-Aegis on Android and show that it can support a num- crosoft. Although users may want to have faith in cloud ber of popular cloud services, e.g. Gmail, Google Hang- providers to provide good security protection, the recent out, Facebook, WhatsApp, and Viber. Edward Snowden story is the latest reminder of the real- Our performance evaluation and user study show that ity: the confidentiality of any data in public clouds can users incur minimal overhead in adopting M-Aegis on be violated, and consequently, while the providers may Android: imperceptible encryption/decryption latency not be “doing evil”, we can not and should not trust them and very low and adjustable false positive rate when with data confidentiality. searching over encrypted data. To better protect the privacy of user data stored on the cloud, in this paper we propose a privacy-preserving sys- 1 Introduction tem called Mimesis Aegis (M-Aegis) that is suitable for mobile platform. M-Aegis presents a novel approach to As a result of the growth in cloud computing and mobile user data privacy by providing good isolation and pre- technology, today we witness a continuously increasing serving user experience through the creation of a concep- number of users who utilize mobile devices [2] to interact tual layer called Layer 7.5 (L-7.5), which is interposed with public cloud services (PCS) (e.g. Gmail, Outlook, between the application (Layer 7) and the user (Layer 8). and WhatsApp) as an essential part of their daily lives. This approach allows M-Aegis to implement a true end- Generally, while the user’s connectivity to the Internet is to-end encryption of user data with three goals in mind: improved, the problem of preserving data privacy in the 1) plaintext data is never visible to the (untrusted) client interaction with PCS is yet unsolved. In fact, news about app used to access the cloud service or any intermediary the US government’s alleged surveillance programs re- entities in the communication; 2) the original user expe- minds everybody about a very unsatisfactory status quo: rience with target apps is preserved; and 3) our technique while PCS are essentially part-of-life, the default way is generalizable to a large number of apps and resilient to of utilizing them exposes the users to privacy breaches, app updates, hence our solution is scalable. We argue because it implicitly requires the users to trust the PCS that while existing solutions may achieve a combination providers with the confidentiality of their data, and thus of these goals, none can achieve all three, and thus M- their privacy; but such trust truly is unjustified, if not Aegis presents a clear advantage from the point of view misplaced. Incidents that demonstrate the breach of this of three entities in a security ecosystem: the user, the trust are easy to come by: 1) PCS providers are bounded system, and the developer. by law to share their users’ data with surveillance agen- In order to preserve the exact application workflow cies [12], 2) it is the business model of the PCS providers and look-and-feel, M-Aegis utilizes L-7.5’s unique lay- to go through their users’ data and share it with third par- ering hierarchy to form a coating on top of existing ap- ties [10, 19, 22, 40], 3) operator errors [34] can result in plication GUIs to both intercept user plaintext before unintended data access, and 4) data servers can be com- 1 promised by attackers [47]. bile device users simply do not favor using mobile To alter this undesirable status quo, solutions should browsers [28] to access PCS. Therefore, we rule out be built based on an updated trust model of everyday conventional browser-extension/plugin-based solu- communication that better reflects the reality of threats tions. mentioned earlier. In particular, new solutions must first 2. For a solution to be adoptable, it must preserve user assume PCS providers to be untrusted. This implies that experience. We posit that users will not accept solu- all other entities that are controlled by the PCS providers, tions that require them to switch between different including apps that users installed to engage with the apps to perform their daily tasks. Therefore, sim- PCS, must also be assumed untrusted. ply porting solutions like PGP onto mobile platform Although there are a plethora of apps available today would not work, because besides forcing users to that comes in various combinations of look-and-feel and use a separate and custom app, and it is impossible features, we observed that for a large class of these apps to recreate the richness and unique user experience that provides text communication services (e.g. email or of all existing email apps offered by various PCS private/group messaging categories), users can still enjoy providers today. In the context of mobile devices, the same quality of service1 without needing to reveal PCS nowadays are competing for market share not the true content of their data to the PCS providers. PCS only by offering more reliable infrastructure to fa- providers are essentially message routers and can func- cilitate user communication, but also by offering a tion normally without needing to know the content of the better user experience [14, 57]. Ultimately, users messages being delivered, analogous to postman deliver- will choose apps that they feel most comfortable ing letters without needing to learn the actual content of with. To reduce interference with the user’s interac- the letters. tion with the app of their choice, security solutions Hence, in theory, applying end-to-end encryption must be retrofittable to existing apps. Solutions that (E2EE) without assuming trust in the PCS providers repackage/rewrite existing apps have this criteria. seems to solve the problem. However, in practice, the 3. For a solution to be sustainable, it must be easy to direct application of E2EE solutions onto the mobile maintain and scalable: the solution must be suffi- device environment is more challenging than originally ciently general-purpose, requiring minimal efforts thought. A good solution must present clear advantages to support new apps and withstand app updates. to the entire mobile security ecosystem, in particular ac- In the past, email was one of the very few means counting for these factors: the users’ ease-of-use, hence of communication and protecting it is relatively acceptability and adoptability; the developers’ efforts to straightforward because email protocols (e.g. POP maintain support, and the feasibility and deployability of and IMAP) are well defined and therefore custom solution on the mobile system. From this analysis, we privacy-preserving apps can be built to serve this formulate three key challenges that must be addressed need. However, with the plethora of PCS that are coherently: becoming indispensable in a user’s everyday life today, a good solution should also be able to in- 1. For a solution to be secure, it must be properly tegrate security features to apps without requiring isolated from untrusted entities. It is obvious the reverse engineering of the app logic and/or net- that E2EE cannot protect data confidentiality if the work protocols, which are largely undocumented plaintext or even the encryption key can be com- and possibly proprietary (e.g. Skype). promised by architectures that risk exposing these Mimesis Aegis (M-Aegis) values. Traditional solutions like PGP [13] and In this paper, we introduce , newer solutions like Gibberbot [5], TextSecure [11], a privacy-preserving system that “mimics” the look and and SafeSlinger [41] provide good isolation prop- feel of existing apps to preserve user experience and erty, but forces user to use custom apps, which workflow on mobile devices, without changing the un- can cause usability problems (refer to (2)). Solu- derlying OS or modifying/repackacing existing apps. M- tions that repackage/rewrite existing apps to intro- Aegis achieves the design goals by operating at a con- Layer 7.5 (L-7.5) duce additional security checks [65, 27] do not have ceptual layer we call that is positioned this property (further discussed in Sect. 2.3). So- above the existing application layer (OSI Layer 7 [8]), lutions in the form of browser plugins/extensions and interacts directly with the user (popularly labeled as also do not have this property (further discussed in Layer 8 [16, 4]). Sect. 2.2), and they generally do not fit into the mo- From a system’s perspective, L-7.5 is a transparent bile security landscape because besides the fact that window in an isolated process that interposes itself be- mobile browsers do not support extensions [7], mo- tween Layer 7 and 8. The interconnectivity between these layers is achieved using the accessibility frame- 1the apps’ functionality and user experience are preserved work, which is available as an essential feature on mod- 2 ern operating systems (OS).