MessageGuard: Retrofitting the Web with User-to-user Encryption
Scott Ruoti, Daniel Zappala, Kent Seamons Brigham Young University Provo Utah, USA [email protected], [email protected], [email protected]
ABSTRACT third-party libraries [34], compromise of the website’s back Users today share a great deal of private information on the end, poor protocol design and implementation [12], and co- Web. While HTTPS protects this data during transmission, erced information disclosure by governments. it does not protect data at rest, nor does it protect user data This state of affairs motivates the need for user-to-user from the websites which store or transmit that data. These encryption, an approach in which data is encrypted and de- issues can be addressed with user-to-user encryption, an ap- crypted at each user’s computer and is opaque to the web- proach where data is encrypted and decrypted at the user’s sites that store or transmit this data. There are many use computer and is opaque to websites. In this paper we present cases for user-to-user encryption. For example, two users MessageGuard, the first system that retrofits the Web with can encrypt their email, preventing either of their email user-to-user encryption and is designed to work with all web- providers from accessing its contents. Similarly, users may sites, in all browsers, on all platforms. We demonstrate that want to encrypt sensitive files shared through DropBox or MessageGuard operates out-of-the-box on 47 of the Alexa Google Drive. In some cases, a user may wish to be the only top 50 sites, has minimal performance overhead, and is rated endpoint, such as when storing private items in a Web-based as highly usable by study participants. to-do list. Significant work has been done to explore different dimen- sions of the user-to-user encryption problem. Some work Categories and Subject Descriptors examines protecting a single type of application. For exam- K.4.4 [Computers and Society]: General—security; D.4.6 ple, BabelCrypt protects mobile messaging applications [40]. [Operating Systems]: General—security and protection Other work has examined how a wide variety of websites might be protected in a single browser [11, 19]. There is General Terms also work that examines how browsers and websites might be modified in order to allow for user-to-user encryption [34]. Web, Security While this work makes significant progress, it leaves open the question of whether a single approach could be used to pro- Keywords vide user-to-user encryption for all websites and all browsers User-to-user encryption, usable security on today’s Web. In this paper, we present MessageGuard, the first system 1. INTRODUCTION that retrofits the Web with user-to-user encryption and is designed to work with all websites, in all browsers, and on Users today share a great deal of private information on all desktop and mobile platforms. MessageGuard provides the Web and do so through a variety of applications (e.g., a security overlay that isolates plaintext from websites, so email, instant messaging, social media, document sharing). that only ciphertext is uploaded and stored on the website’s HTTPS can be used to protect this information during trans- back end. This approach works out-of-the-box for most ex- mission, but does not protect users’ data while at rest. Ad- isting websites, allowing MessageGuard to scale with the ditionally, middleboxes can weaken HTTPS connections by ever-increasing number of applications on the Web. In rare failing to properly implement TLS or adequately validate cases where the default overlay does not work, or if addi- certificate chains [23]. Ultimately, even if a website correctly tional functionality is desired, MessageGuard can be cus- employs HTTPS and encrypts user data while at rest, the tomized for a specific website. user’s data is still vulnerable in a number of ways — honest- The main contributions of this paper are the following: but-curious websites that mine user data [30], misbehaving • An analysis and comparison of the various implemen- tation strategies for retrofitting the Web with user-to- Permission to make digital or hard copies of all or part of this work for user encryption. We propose two new hybrid strate- personal or classroom use is granted without fee provided that copies are gies that address limitations in existing strategies and not made or distributed for profit or commercial advantage and that copies maximize deployability, security, and usability. bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific • The design of MessageGuard, a user-to-user encryp- permission and/or a fee. WWW ’16 Montreal, Canada tion system that bridges the gap between the need for Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$15.00. secure user-to-user communication and the capabilities
1 of current browsers and websites. While other research 2.2 System Goals has focused on a small subset of this problem space Based on an examination of existing work on encrypting or requires significant modifications to browsers and user-to-user messages in specific applications (e.g., [41, 13, websites, MessageGuard works everywhere and can be 33, 36]) and our own experience in this area (i.e., [30, 31, deployed today. 27, 28, 29]), we have identified several key goals for systems retrofitting the Web with user-to-user encryption. These • An analysis of MessageGuard in terms of its deploya- goals encompass deployment, security, and usability con- bility, performance, and usability. We show that Mes- cerns. sageGuard works with 47 of the Alexa Top 50 websites (only one site needed customized functionality to get 2.2.1 Deployment it to work, the other two were not testable). Message- Guard has little impact on page load times, consuming Goal1 Ubiquitous: Encryption should be available for all approximately 1% of load time for Facebook and 3% websites. for Gmail. We evaluate MessageGuard for usability Goal2 Available: Encryption should available in all major in a series of laboratory studies involving a total of desktop and mobile browsers. 220 users, with MessageGuard receiving a SUS score of 80.0, putting it in the top 15% of systems previously Users want to continue using the websites they already tested using SUS [32]. use [30, 28]. While it may be impossible to fully retrofit the Web with user-to-user encryption (e.g., Flash applications or input fields drawn using an HTML canvas), standard HTML 2. USER-TO-USER ENCRYPTION interfaces should all be supported and where possible non- In this section, we describe the threat model that moti- standard interfaces should also be handled. Similarly, users vates our work. We then discuss system goals necessary for want to continue using their current devices and browsers, retrofitting the Web with user-to-user encryption in a way so encryption should be available on all major desktop and that could be adopted by the masses. Next, we detail where mobile browsers. user-to-user encryption needs to be implemented in order to be compatible with existing browsers. Finally, we discuss 2.2.2 Security limitations inherent to retrofitting the Web with user-to-user Goal Secure: Encryption interfaces should be clearly dis- encryption. 3 tinguishable from the website’s interface. 2.1 Threat Model In addition to protecting user-to-user messages from web- Our threat model is very closely aligned with the threat sites, it is important that systems clearly delineate which model for HTTPS [25], except that in our case users are interfaces belong to the website and which belong to the the endpoints and websites are considered to be a part of user-to-user encryption software. This helps users to feel the network infrastructure that user-to-user messages tra- assured that their data is being protected and assists them verse. We consider websites, middleboxes (e.g. CDNs), and in avoiding mistakes [30, 27]. Additionally, visual indica- the content they serve to be within the complete control tors should be included that can help protect against an of the adversary. The adversary wins if she is able to use adversary that attempts to social engineer a user into be- these resources to access the user’s sensitive data. While lieving they are entering text into a secure interface when it is true that most websites are not malicious,1 in order in reality they are entering text directly into the adversary’s to retrofit the Web with user-to-user encryption it is nec- interface [9,6]. essary to also address those websites that are truly mali- cious. Users’ computers, operating systems, software, and Goal4 Automatic: Key management should be automatic user-to-user encryption software2 are all considered part of and meet the needs of both novice and expert users. the trusted computing base in our threat model. Research has shown that users can successfully use en- Since retrofitting the Web with user-to-user encryption cryption when key management is automatic [13, 30,1], but does not allow modification of websites, and by extension struggle otherwise [41, 33, 29]. Key management scheme(s) the protocols they use, our threat model allows for the leak- should meet the needs of both novice and expert users, age of some meta-data, but requires that this meta-data does though to date this is still an open problem area [36]. not compromise the confidentiality, integrity, or authenticity of the messages passed between users. First, meta-data re- 2.2.3 Usability garding the encrypted package is available to the adversary 3 (e.g., length of the encrypted message). Second, meta-data Goal5 Simple: The system should be approachable to novice that is exposed by the website as it transmits or stores data users. is also available. For example, an encrypted email is still sent using the SMTP protocol and information revealed by Easy-to-use systems are more likely to be adopted by the that protocol (e.g., recipients, subject) will be available to public at large [36]. Furthermore, complicated systems fos- the adversary. ter user errors, decreasing system security [41, 30]. As such, a primary concern is to ensure that users are both willing 1Many websites are best described as honest-but-curious. to use the system and can do so correctly. At a minimum 2This includes the software’s website and any web services this includes the use of informative messages for first time the software relies upon (e.g., key server). recipients of a secure messages, intuitive interfaces, and in- 3This type of leakage also occurs in HTTPS. tegrated, content-sensitive tutorials [27, 28].
2 problems that keep this from being an acceptable design choice:
i Browsers and websites must be modified to support this approach.
ii In practice, it is difficult to ensure that users’ data is Figure 1: Locations where content can be encrypted sufficiently protected while also allowing the website to function as intended [34]. Goal Seamless: The system should integrate seamlessly 6 iii The implementation of the website and the JavaScript with existing websites and avoid burdening the user. plugin is tightly coupled, implicitly trusting the web-
Goal7 Reactive: The system should modify its interfaces site more than is allowed by our threat model. to be usable for any dimensions.
Interfaces for user-to-user encryption should be integrated 3. Between the website’s front end and the user. tightly with existing Web applications. Research has repeat- Encrypting a user’s sensitive data before it is ever passed to edly demonstrated that users prefer this approach to inter- an adversary’s website is the most reliable way to protect faces that do not integrate with their existing web applica- user’s data. Additionally, since encryption occurs regardless tions [30, 31,1, 27]. Furthermore, these interfaces should of the underlying website, this approach is able to scale with react to the space available, providing appropriate function- the Web. This is the same approach taken by TLS, which ality at any display size. Finally, it is important that the sys- encrypts data before it leaves an endpoint. tem should minimize the effect on the secured website’s user This is the only approach that is compatible with our experience; if encryption gets in the way of users complet- threat model (i.e., does not trust websites). Moreover, this ing tasks it is more likely that they will turn off user-to-user approach can be accomplished without modifying current encryption [20]. browsers or websites. As this is the only approach that sat- isfies our system goals, the remainder of this paper focuses Goal Controllable: Users should control when and how 8 on the type 3 approach. their data is secured. Research has shown that most users are not interested in 2.4 Limitations encrypting all of their online data [14, 30]. As such, it is The following are limitations inherent to the type 3 ap- important that users be able to control when their data is proach. First, a Web service can perform a denial-of-service encrypted. attack [22, 19] by refusing to store or transmit data that has been encrypted.4 Alternatively, a website can attempt to 2.3 Data Encryption Locations disrupt a user-to-user encryption system’s ability to secure With the above goals in mind, there are three locations the website. where users’ data can be encrypted (Figure1). Second, encrypted messages are opaque to the website, limiting the website’s ability to provide any useful com- 1. At the website’s back end. putation on the data (e.g., sorting data, context-sensitive The Web service can encrypt data before storing it to disk. ads). Additionally, any custom composition interfaces pro- While this improves over just using HTTPS, it does not pro- vided by the website (e.g., rich text editing) are unavailable vide user-to-user encryption and still leaves users open to when composing the encrypted message, and similar inter- vulnerabilities (e.g. honest-but-curious websites, misbehav- faces must be re-implemented by the encryption software. ing third-party libraries, compromise, and coercion). Fur- thermore, requiring all websites to implement back end en- 3. IMPLEMENTATION STRATEGIES cryption is not feasible. In line with our system goals, we examined approaches for encrypting sensitive data before it reaches the website. 2. Between the website’s front end and the network. In this section, we review related work and analyze the im- There are two ways that this can be done: (a) the website’s plementation strategies used in that work with respect to JavaScript could encrypt users’ messages before transmis- our system goals (i.e., deployability, security, usability). We sion or (b) a user-supplied JavaScript plugin could encrypt group the implementation strategies into two categories: in- a user’s sensitive message before it is transmitted to the web- tegrated strategies and non-integrated strategies. We also site. The problem with (a) is that in our threat model, the propose two new hybrid strategies that address limitations website is untrusted and cannot be relied upon to encrypt in the existing strategies and are better suited to meet our user-to-user messages. Furthermore, requiring all websites system goals. to implement (a) is not scalable. There are two approaches to implement (b). First, a 3.1 Integrated Strategies JavaScript plugin can perform taint analysis and ensure that Integrated strategies attempt to add user-to-user encryp- any user-created data is encrypted before being sent to the tion directly to the interfaces of existing websites. In a pro- website [21,8]. Second, Mandatory Access Control (MAC) cess known as overlaying [37], the browser can replace por- can be used to allow websites to collaborate with a JavaScript tions of the website’s interface with secure interfaces known plugin in order to provide user-to-user encryption [34, 15]. as overlays (Figure2). These overlays are displayed as if A significant benefit of (b) is that it uses the websites’ cur- rent interfaces without modification. Still, there are several 4 This limitation also applies to the type 2 approach.
3 strategy to work with non-browser applications that display HTML interface elements retrieved from the Web. A proxy application can work on any platform, except for Windows on mobile devices. Still, there are two significant drawbacks to this approach: (1) for non-rooted phones, the proxy must be implemented using the phone’s VPN service and (2) it must proxy HTTPS connections in order to modify their contents.
In prior work, we used iFrames to develop Pwm, a secure Portions of the Web application (shown on the left) have email client for the masses [30]. Pwm tightly integrated been overlayed with secure interfaces (shown on the right). with Gmail and was designed to maximize usability. Pwm focused on helping first time recipients of an encrypted email Figure 2: Overlaying a Web application understand how to install Pwm and decrypt their message. Pwm was rated as highly usable by participants in several us- ability studies. Since our work on Pwm, additional systems they were a part of the Web application, but their contents in both research [1] and industry (e.g., Virtru, Mailvelope) are inaccessible to the Web application. Often, there are have also used the iFrame strategy to secure email. different overlays for different functions, such as composing textual content, uploading files, and decrypting content. 3.1.2 Shadow DOM Shadow DOM is a new feature proposed in the HTML5 3.1.1 iFrame specification, and currently has a partial implementation in The oldest integrated strategy is to create overlays us- blink-based browsers (e.g., Chrome). The Shadow DOM al- ing HTML iFrames [37]. Since iFrames are a part of the lows for the creation of a “shadow” DocumentFragment (i.e., browser’s DOM, it is trivial to integrate them with websites. ShadowRoot) that will be rendered in place of another frag- Further, iFrames are protected by the browser’s same-origin ment (i.e., host) on the website. Elements contained in the policy. There are three methods for overlaying websites with ShadowRoot are invisible to the rest of the DOM and must iFrames: be accessed through their parent ShadowRoot. For example document.getElementById cannot find children of a Shad- 1. Browser extension. Extensions are desktop only, owRoot. except in the case of Firefox on Android. Overlays can be implemented using a ShadowRoot. How- ever, while ShadowRoot objects and their contents should 2. Bookmarklet. Bookmarklets are user scripts that only be accessible to the entity that created the ShadowRoot are stored as browser bookmarks. When a user clicks object, in practice this is not the case: a bookmarklet, the associated script is executed on the current page. Bookmarklets are supported on all plat- 1. The Shadow DOM allows for an element to have multi- forms, both desktop and mobile, and do not require ple ShadowRoots, with the newest ShadowRoot having users to install any software. access to older ShadowRoot objects through their old- erShadowRoot property. When using bookmarklets, the iFrame’s src attribute will need to reference a trusted remote domain. To 2. There are two CSS selectors that “pierce” the Shadow maximize security, this domain should only host the DOM. First the “>>>” selector can be used to grab contents needed by the bookmarklet’s user script. This any element that matches the selectors to the right of limited functionality makes it easier to lock down the “>>>”, regardless of whether that element is inside a domain’s servers in order to prevent an intrusion by ShadowRoot. Similarly, the “::shadow” pseudo-selector the adversary. can be used to select the ShadowRoot attached to any Bookmarklets are affected by the browser’s Content element. Security Policy (CSP), which can be used to limit the 3. The Element.prototype.createShadowRoot method source of frames and scripts. Still, this limitation has can be replaced by the Web application with a version been marked as a bug in Chromium5 and Firefox,6 and that saves references to the created ShadowRoots, al- it is possible that in the future this limitation will be lowing the Web application to access the contents of removed. In practice, only a small number of websites these ShadowRoots. use CSP. In order to implement overlays using a ShadowRoot, it 3. Proxy application. A proxy application can be used is necessary to modify the JavaScript environment to ad- to augment the bookmarklet approach. First, it can dress these access methods [19]. Because of this limitation, modify the CSP settings of a website to allow iFrame’s ShadowDOM cannot be implemented using a bookmarklet, to reference the system’s trusted domain. Second, a which cannot guarantee that the JavaScript environment is proxy can automatically inject the bookmarklet script modified before the website has the ability to store pointers into a webpage, obviating the need for the user to click to these access methods. Instead, a Shadow DOM strategy the bookmarklet. Third, a proxy can allow the iFrame must be implemented using either an extension or a proxy 5https://code.google.com/p/chromium/issues/ application. detail?id=233903 He et al. used the Shadow DOM to implement Shad- 6https://bugzilla.mozilla.org/show_bug.cgi?id=866522 owCrypt, a Chrome extension that attempted to add secure
4 communication to arbitrary websites [19]. In our experience, 3.2.2 Standalone Application usability issues keep ShadowCrypt from working with most A standalone application is the traditional strategy for websites. Moreover, flaws in ShadowCrypt’s implementa- implementing user-to-user encryption. Security is provided tion allow the website to retrieve the user’s sensitive data by the operating system’s app separation policies. (for further details see Section 3.3.3). This demonstrates The earliest example of a standalone user-to-user encryp- the danger of relying on non-standard security models cre- tion application is Pretty Good Privacy (PGP). PGP was ated by developers. created in 1991 by Phil Zimmerman and is used to protect a wide range of data. Since then, many similar programs have 3.1.3 Greasemonkey been created. Greasemonkey is a Firefox plugin that allows for websites to be modified with custom interface elements defined us- 3.3 Comparison ing XUL. XUL interface elements can be used for overlays, We have analyzed and compared each of the above strate- and the contents of these interfaces are protected by the gies based on their deployability, usability, and security. The browser’s sandboxing of websites [7]. results are summarized in Table1. Fahl et al. used Greasemonkey to create a Firefox exten- sion that added user-to-user encryption to Dropbox, Face- 3.3.1 Deployability book, and email [10]. Their plugin used Confidentiality-as- There are three key areas of deployability: which browsers a-Service (CaaS) to automate key management. Usability are supported, which desktop operating systems are sup- studies demonstrate that their system was highly usable. ported, and which mobile devices are supported. Both the Greasemonkey and Shadow DOM strategies are limited to a 3.1.4 Accessibility single type of browser, Firefox and blink-based, respectively. Most operating systems have an accessibility layer that is On mobile, Greasemonkey only works with Firefox on An- used by accessibility tools to modify apps to make them us- droid and the Shadow DOM requires the use of a proxy able by individuals with disabilities. Lau et al. proposed us- application, which as mentioned earlier is less than ideal ing the accessibility layer to implement secure overlays [22]. (marked as “Partial support” in Table1). Greasemonkey In this strategy, the content of secure overlays is protected by uses XUL, which is slated for deprecation. On the other the browser’s sandbox. While our work is concerned with en- hand, Shadow DOM is part of the HTML5 specification and crypting content within the browser, the accessibility layer is there is a good chance that sometime in the future it will interesting in that it has the potential to secure non-browser become standard in more browsers. applications. While iFrames implemented using a proxy ap- The deployment challenge faced by both the accessibility plication can also support non-browser applications, the ac- and standalone app strategy is that every platform, both cessibility layer has the potential to be more universal and desktop and mobile, requires its own implementation. For reliable. standalone apps, this burden could be reduced through the Lau et al. used this strategy to develop Mimesis Aegis use of a cross-platform framework (e.g., Java, Mono), though (M-Aegis), a system for enhancing Android apps with user- these frameworks commonly lead to systems with a poor to-user encryption. Their system secured several communi- look-and-feel. Unfortunately, there is not a cross-platform cation apps (e.g., Gmail) and also provided a method for accessibility layer and each platform does require a unique 7 support to be added for additional apps. A usability study implementation. These limitations have been marked in Ta- of the Android Gmail app secured with M-Aegis showed that ble1 using the “Partial support” symbol. most participants did not report any noticeable difference Both iFrames and standalone websites are built on com- between the original Gmail app and the Gmail app with monly deployed approaches, and work on all platforms and M-Aegis enabled. browsers. iFrames on mobile can be implemented using ei- ther bookmarklets or an application proxy. In the case of 3.2 Non-integrated Strategies bookmarklets, iFrames are limited by websites’ CSP poli- In contrast to integrated strategies, non-integrated strate- cies, and in the case of a proxy application on mobile de- gies use separate applications to provide encryption, relying vices, there is the degradation of user experience (marked on the user to copy-and-paste encrypted content in and out as “Partial support” in Table1). of the original application. Because these applications are not integrated with websites, they are free to make UI de- 3.3.2 Usability sign choices that maximize usability, without any concern The standalone strategies suffer from a lack of integration, that these choices will clash with a website’s UI. which is disliked by users [30,1]. On the other hand, be- cause the standalone strategies are not tied to the website’s 3.2.1 Standalone Website interface, the standalone strategies support non-standard in- A standalone website can be used to handle encryption terfaces (e.g., input field drawn using an HTML canvas). and decryption. While it is not integrated with websites, it While the integrated strategies could contain logic to han- is integrated with the browser. Since a browser is used to run dle website-specific interfaces, this approach is a significant the website, no installation is required. Security is provided engineering effort (marked as “Partial support” in Table1). by the browser’s same-origin policy. This approach is not The standalone website strategy does not require installa- common, but there have been a few standalone websites that tion. When the iFrame strategy is implemented using book- provide PGP encryption.8 marklets, there is also no installation. 7This method is not generic and requires custom logic for each supported application. 8For example, https://www.igolder.com/pgp/encryption/ and http://www.hanewin.net/encrypt/PGcrypt.htm.
5 Browsers Desktop OS Mobile OS Usability
Strategy Chrome Firefox IE Opera Safari Others Linux Mac OS Windows Android iOS Windows Integration Non-standard Interfaces No install Security Model iFrame ✓✓✓✓✓✓ ✓✓✓ ––– 5 ✓ –– 5 Same-origin Shadow DOM –2 ✗✗ –2 ✗✗ ✓✓✓ –– ✗ ✓ – ✗ None Greasemonkey1 ✗✓✗✗✗✗ ✓✓✓ – ✗✗ ✓ – ✗ Browser Sandbox Accessibility ✓✓✓✓✓ –3 ✗4 –– – ✗✗ ✓ – ✗ Browser Sandbox Standalone Website ✓✓✓✓✓✓ ✓✓✓ ✓✓✓ ✗6 ✓✓ Same-origin Standalone App ✓✓✓✓✓✓ ––– ––– ✗✓✗ Browser Sandbox ✓ Full support, – Partial support, ✗ No support
1 Scheduled for deprecation. 4 In development – AT-SPI [42]. 2 ShadowDOM is not fully supported in Chrome. 5 Potentially limited by CSP. 3 Depends on whether the browser is accessible. 6 Integrated with the browser, but not the website.
Table 1: Comparison of implementation strategies
3.3.3 Security 1 var elements= document.querySelectorAll( ' [contentEditable] ' ); The Greasemonkey, accessibility, and standalone app strate- 2 for(vari = 0, len= elements.length;i< len;i++) { 3 var newShadowRoot= elements[i].createShadowRoot(); gies all rely on the browser’s sandbox for security [7]. The 4 newShadowRoot.innerHTML= '
6 Browsers Desktop OS Mobile OS Usability
Strategy Chrome Firefox IE Opera Safari Others Linux Mac OS Windows Android iOS Windows Integration Non-standard Interfaces No install Security Model iFrame + Standalone Website ✓✓✓✓✓✓ ✓✓✓ ✓✓✓ ✓✓✓ Same-origin Accessibility + Standalone App ✓✓✓✓✓ – ✗ –– – ✗✗ ✓✓✓ App Separation
Table 2: Comparison of hybrid strategies cerns. First, if cryptography is being used because TLS is browsers and platforms, both mobile and desktop. Further- not trusted by the website, then the website cannot guar- more, in most situations it provides tight integration with antee that the JavaScript is delivered to the user’s browser websites, but can fall back to a standalone website when unmodified. Second, if cryptography is being used to en- non-standard interfaces are encountered. Moreover, using crypt the data so that it is opaque to the website, then you bookmarklets, this strategy can be run on systems where cannot trust the website to send you JavaScript that will the user does not have install permissions. encrypt this data. Both of these are valid concerns, but are orthogonal to the 4. MESSAGEGUARD strategies that use JavaScript-based cryptography. First, Using the hybrid iFrame + standalone website strategy, the strategies do trust TLS to correctly deliver the user- we created MessageGuard. MessageGuard is the first system to-user encryption software. Second, the strategies do not that retrofits the entire Web with user-to-user encryption trust the website, and that is precisely why the encryption and works with all websites, in all browsers, on all platforms, software is separate from the website. Finally, except in both desktop and mobile. It is also the only system that the case of iFrames implemented using Bookmarklets, the attempts to address all of the system goals we identified for cryptographic JavaScript code is only downloaded once, at user-to-user encryption (Section 2.2). installation (iFrame, Shadow DOM, Greasemonkey) or on Figure4 shows an overview of MessageGuard’s architec- first run (standalone website). ture. MessageGuard’s workflow is as follows: 3.4 Hybrid Strategies 1. MessageGuard injects the front end component into The comparison of implementation strategies shows that the website’s front end. MessageGuard’s front end the iFrames and accessibility strategies best match our goals component scans for encrypted payloads and data en- of retrofitting the Web with user-to-user encryption. Still, try interfaces. When found, it replaces these items both of these approaches struggle with non-standard inter- with an overlay. After this initial scan, changes to faces. To address this, we suggest that each of these strate- the page are tracked and only elements that have been gies be modified to fall back to a standalone strategy when modified are scanned. users encounter a non-standard interface that the system 2. Read overlays are used to display sensitive informa- was unable to overlay. We pair strategies that have the same tion to the user, and a compose overlay allows users to security model: i.e., iFrame + standalone website (same- encrypt sensitive information before sending it to the origin) and Accessibility + standalone app (browser sand- website. Each overlay is displayed within an iframe box). The capabilities of these new hybrid approaches are and uses the browser’s same-origin policy to protect its summarized in Table2. contents from the website, which sees only ciphertext. Using the hybrid strategies, a bookmarklet implementa- Overlays use the packager component to handle the tion of iFrames can protect websites that don’t employ CSP, actual encryption/decryption and packaging of data. and for those websites that do use CSP, the implementation can fall back to the standalone website. This standalone 3. In conjunction with the key management compo- website could be displayed in either a new window or tab. nent, the packager encrypts and decrypts data. The Alternatively, when a user encounters a non-standard in- packager also encodes encrypted data, making it suit- terface that is not overlayed, they could click a button to able for transmission to and from the website. launch the standalone website. This allows iFrames to fully support mobile platforms without using a proxy application. 4.1 Front End Additionally, this means that the no-install implementation of iFrames (i.e., bookmarklets) is available for all browsers MessageGuard’s front end component is injected into ev- and platforms. ery website. The front end has three responsibilities: 1. Identify encrypted payloads. The front end iden- 3.5 Best Strategy tifies encrypted payloads, overlays these payloads with Based on our goal of retrofitting the Web with user-to-user a read overlay, and sends the payloads to the overlay encryption, the hybrid strategy iFrames + standalone so that they can be decrypted and displayed to the website is the best strategy. It works with all current user (Figure5).
7 Figure 6: Compose overlay.
Figure 7: Compose overlay in small input field.
Figure 4: Overview of MessageGuard architecture. MessageGuard includes two standard overlays: a read overlay (Figure5) and a compose overlay (Figure6). 11 Read overlays are responsible for decrypting and displaying sensi- tive information to users. Compose overlays allow users to Figure 5: Read overlay. compose rich text messages and encrypt these messages be- fore sending them to the website. Both overlays are reactive and modify their behavior based on available space (Goal7: 2. Identify data entry interfaces. The front end iden- Reactive). For example, at small sizes, the compose overlay tifies interfaces where the user may wish to enter en- no longer shows tools for formatting text, but still allows crypted data (e.g., TextArea, ContentEditable). Each their use through keyboard shortcuts (Figure7). of these interfaces is then modified to display a button that users can click to replace the interface with a com- 4.3 Packager pose overlay (Figure6) ( Goal8: Controllable).The front The packager encrypts/decrypts user data and encodes end also handles passing data between the the compose the encrypted data to make it suitable for use with web- overlay and the website (e.g., initial message contents, sites. The packager uses standard cryptographic primitives saving drafts). and techniques to encrypt/decrypt data (e.g., AES-CCM). Ciphertext is packaged with all information necessary for 3. Displaying context-sensitive tutorials. The front recipients of the message to decrypt it. Currently, the pack- end displays tutorials that instruct new users how to ager uses a custom package format that has been optimized use MessageGuard. These are all context-sensitive, ap- to reduce its footprint, allowing it to be compatible with pearing as the user performs a given task for the first websites that limit the length of content (e.g., chat applica- 12 time (Goal5: Simple). tions). The package data is then Base64 encoded.
The front end is the only MessageGuard component that 4.4 Key Management runs outside of MessageGuard’s protected origin. For this MessageGuard’s key management back end is flexible and reason, MessageGuard is designed to treat the front end allows for the deployment of various key management schemes as untrusted. Since the front end component does not ex- (e.g., shared secrets, PGP, IBE). In practice, this could be ist as part of MessageGuard’s protected origin, it cannot used by researchers to compare different key management directly access the packager, key management, or overlay schemes while holding the front end constant. components. Instead, it is limited to communicating with In our MessageGuard prototype, we used Identity-based the overlay component using the web messaging API [39]. Encryption [5] (IBE) for our key management scheme. Sim- Additionally, the overlay always encrypts user data before ilar to how MessageGuard secures websites without requir- transmitting it to the front end component and sanitizes any ing changes to the website, IBE allows messages to be en- data it receives from the front end. crypted for a user without requiring the user to first perform key management (Goal4: Automatic). We considered us- 4.2 Overlays ing PGP in our MessageGuard prototype, but PGP has a MessageGuard’s overlays are designed to mimic the place- long history of being unusable [41, 33, 13] and in our own ment and dimensions of the content they overlay (Goal6: experimentation we found that this still holds true [29]. In Seamless, Goal7: Reactive) and to be visually appealing contrast, IBE-like systems have consistently been shown to and intuitive (Goal5: Simple). Overlays have a distinc- be usable [10, 30, 28]. tive, dark color scheme that stands out from most website, allowing users to easily identify secure overlays from inse- 4.5 Customization cure website interfaces (Goal3: Secure). There is also a MessageGuard is able to overlay standard HTML inter- user-selected watermark displayed in each overlay that fur- faces on all websites (Goal1: Ubiquitous). For websites 10 ther differentiates it from interfaces created by the website, that use non-standard interfaces, MessageGuard allows for though research into potentially better indicators is ongoing. per-website customization. This customization can also be Finally, overlays sanitize the plaintext contents of encrypted messages in order to prevent malicious messages from com- 11Support for a file upload overlay is also nearing completion. promising the overlay. 12In tandem with the upcoming file input overlay, the pack- ager is currently being modified to be able to produce files 10For readability, the watermark is not shown in the figures. in a variety of formats.
8 Figure 8: Standard MessageGuard in Gmail.
Figure 10: Instructions included in encrypted email.
https://messageguard.io.
Figure 9: Customized MessageGuard in Gmail. 5. VALIDATION We evaluated MessageGuard in terms of deployability, used to enhance the default experience provided by Mes- performance, and usability. sageGuard (Goal6: Seamless). For example, in Gmail the default behavior of Message- 5.1 Deployability Guard marks the To field for possible encryption (with an We tested MessageGuard on major browsers and it worked On/Off button) and requires users to enter email recipients in all cases: Desktop – Chrome, Firefox, Internet Explorer, in two different locations (Figure8). Using MessageGuard’s Opera, and Safari. Android – Chrome, Firefox, Opera. iOS customization functionality, we were able to address these – Chrome, Mercury, Safari. issues. First, we modified Gmail to use a custom overlay We tested MessageGuard on the Alexa top 50 Web sites. that allows users to include images and links (Figure9). One of the sites is not a Web application (t.co) and an- Second, we modified Gmail’s interface to indicate to users other requires a Chinese phone number in order to use it which fields were not encrypted and allow the composition (weibo.com). MessageGuard was able to encrypt data in of an unencrypted preamble to their sensitive information. 47 of the 48 remaining Web applications. The one site that Third, we modified the packager to wrap the encoded data failed (youtube.com) did so because the application removed inside an email message that instructs the user to download the comments field when it lost focus, which happens when MessageGuard and install it to read their message. (Fig- focus switched to MessageGuard’s compose overlay. We ure 10). Last, we modified the front end to provide special- were able to address this problem with a customized front ized tutorials on how to use MessageGuard with email. end that required only five lines of code to implement. 4.6 Implementation 5.2 Performance We implemented MessageGuard as both a browser exten- We profiled MessageGuard on several popular Web appli- sion and as a bookmarklet. MessageGuard’s implementation cations and analyzed MessageGuard’s impact on load times. only relies on JavaScript functionality that is available in all In each case, we started the profiler, reloaded the page, and major browsers. This has the benefit that MessageGuard stopped profiling once the page was loaded. Our results show runs on all major desktop and mobile browsers, and that it that MessageGuard has little impact on page load times and will also work with smaller browsers that support standard does not degrade the user’s experience as they surf the Web: JavaScript functionality. Facebook – 0.93%, Gmail – 2.92%, Disqus – 0.54%, Twitter MessageGuard was developed use a modern toolset that – 1.98%. includes NodeJS, Gulp, Browserify, and Kango. This al- Since MessageGuard is intended to work with all web- lows us to leverage quality JavaScript libraries, simplify de- sites, we created a synthetic Web app that allowed us to test velopment and deployment, and generate documentation. MessageGuard’s performance in extreme situations. This This will assist developers and researchers who wish to use app measures MessageGuard’s performance when overlay- or contribute to MessageGuard. We are in the process of ing static content present at page load (Stage 1) and when preparing MessageGuard to be open sourced, and by the overlaying dynamic content that is added to the page after conference MessageGuard and its source will be available at load (Stage 2). The application takes as input n, the num-
9 Stage Static Dynamic the MessageGuard prototype and an existing secure email n 100 500 1000 100 500 1000 system: Voltage, Encipher.it, Tutanota, or Virtru. Partici- pants rated MessageGuard as being substantially more us- Chrome1 1.14 0.84 0.95 3.17 6.49 11.0 1 able than Voltage, Encipher.it, and Tutanota, and ranked Firefox 1.06 0.99 0.96 2.26 3.15 4.45 MessageGuard as being equally usable with Virtru. Safari1 0.45 0.63 0.53 3.73 12.8 25.5 Chrome2 4.27 4.39 4.60 12.9 30.2 51.1 6. DISCUSSION 3 Chrome 5.68 5.97 5.94 12.4 32.0 61.2 In this section, we discuss lessons learned and observations Safari3 2.57 2.46 1.79 15.1 25.2 39.5 made while designing and implementing MessageGuard. As we were developing MessageGuard, it became clear 1 MacBook Air (OSX 10.10.3, 1.7GHz Core i7, 8GB RAM). Chrome – 42.0.2311.135, Firefox – 37.0.2, Safari – 8.0.5. that current JavaScript cryptographic libraries are lacking. 2 OnePlus One (CyanogenMod 12S, AOSP 5.1, 64GB). Some libraries have a limited selection of encryption schemes Chrome – 42.0.2311.47. and modes (e.g., Crypto-JS) while others had poor API de- 3 iPad Air (iOS 8.3, 1st gen, 64GB). sign and were confusing (e.g., SJCL). Based on our experi- Chrome – 42.0.2311.47, Safari – 8.0. ence, we have the following two suggestions: First, work on the JavaScript Web Crypto API [24] needs to be accelerated Table 3: Average time to overlay an element (ms) in order to provide developers with a standardized, trust- worthy, and efficient crypto API. Second, JavaScript crypto libraries need to expose building-block operations (e.g., el- ber elements that will be overlayed in each stage. Half of liptic curve addition and multiplication) in order to allow these elements will require read overlays and half will require developers to add support for unsupported schemes (e.g., compose overlays. IBE). Using this synthetic Web application, we tested Message- We also learned that except for Firefox on Android, mo- Guard with six browsers and three values of n. We averaged bile browsers do not support extensions. This means that measurements over ten runs and report our findings in Ta- bookmarklets are the only universal mechanism for users ble3. Performance for overlaying static content does not to modify or extend their mobile browsers. As such, it is significantly vary based on the number of overlays created. disappointing that even though the Content Security Pol- In contrast, performance for overlaying dynamic content for icy (CSP) specification allows for bookmarklets to be ex- most browsers seems to grow polynomial in the number of empted from CSP [38], browsers have not chosen to do so. overlays added. Still, performance in the Firefox desktop We strongly recommend that browsers follow existing rec- browser demonstrates that this is not an inherent limitation ommendations by the community [24, 17] and exempt book- of MessageGuard. Finally, we note that even in extreme marklets from CSP in order to give users control of their cases (dynamic - n = 1000) overlaying occurs quickly (max mobile browsing experience. 61 ms). Finally, we are intrigued by the ability of the accessibility strategy (see Section 3.1.4) to overlay non-browser applica- 5.3 Usability tions. Even though the limitations of this strategy made The design and implementation of MessageGuard was guided it unsuitable for MessageGuard, certain changes could help by seven IRB-approved laboratory usability studies involv- it become a preferred approach. First, a single platform- ing a total of 220 participants [26, 30, 27, 28]. These studies neutral accessibility framework implemented across all op- examined two prototype versions of MessageGuard. Tasks erating systems could reduce the development burden for for the studies included using Facebook Chat and Gmail to this strategy (e.g., AT-SPI [42]). Second, iOS and mobile send encrypted messages. Windows need to allow for the installation of accessibility All studies but the first utilized a standard usability met- tool apps. Last, the accessibility layer should be more gen- ric, the System Usability Scale (SUS) [2,3]. SUS generates eralized so that non-accessibility tools (e.g., security tools) a single score between 0 and 100 to rate a system’s overall can leverage it. usability. SUS consists of ten discriminating questions that users answer after completing tasks using a system. In our early studies, we achieved SUS scores in the low 70’s, but 7. CONCLUSIONS after addressing issues discovered during these early studies, In this paper, we analyzed and compared potential imple- the most recent prototype of MessageGuard received a SUS mentation strategies for retrofitting the Web with user-to- score of 80.0 [27]. A SUS score of 80.0 represents “excellent” user encryption. Our analysis shows that a hybrid approach usability [2, 31], and is in the 85th to 90th percentile of a using iFrames plus aspects of a standalone website is the large number of systems tested with SUS [32].13 only way to support user-to-user encryption without requir- In that same study, we asked participants to indicate ing modifications to websites or browsers. whether they were interested in encrypting sensitive email. We also present the design and implementation of Mes- In their responses, 83% of participants expressed a desire to sageGuard, the first system that retrofits the existing Web begin using MessageGuard to secure their data. Moreover, with user-to-user encryption and that is designed to work nearly all participants (92%) believed that their friends and with all applications, in all browsers, on all platforms. Mes- family could easily start using MessageGuard. sageGuard bridges the gap between the need for secure user- In several of our studies [30, 28], participants used both to-user communication and the capabilities of current browsers and websites. We show that MessageGuard works every- 13The percentiles are for all applications, not just security where and can be deployed today, has little impact on page applications. load times, and has high usability.
10 8. REFERENCES Fernandez-Kelly. Secrecy, flagging, and paranoia: [1] Erinn Atwater, Cecylia Bocovich, Urs Hengartner, Adoption criteria in encrypted email. In Proceedings of Ed Lank, and Ian Goldberg. Leading Johnny to water: the SIGCHI Conference on Human Factors in Designing for usability and trust. In Proceedings of the Computing Systems, CHI ’06, pages 591–600, New Eleventh Symposium on Usable Privacy and Security, York, NY, USA, 2006. ACM. 2015. [15] Daniel B Giffin, Amit Levy, Deian Stefan, David Terei, [2] Aaron Bangor, Philip Kortum, and James Miller. An David Mazieres, John C Mitchell, and Alejandro empirical evaluation of the System Usability Scale. Russo. Hails: Protecting data privacy in untrusted International Journal of Human–Computer web applications. In OSDI, pages 47–60, 2012. Interaction, 24(6):574–594, 2008. [16] Google. Browser security handbook, part 2. [3] Aaron Bangor, Philip Kortum, and James Miller. https://code.google.com/p/browsersec/wiki/Part2. Determining what individual SUS scores mean: Accessed 2015/10/13. Adding an adjective rating scale. Journal of Usability [17] Google. Issue 233903: CSP: Bookmarklets should Studies, 4(3):114–123, 2009. bypass pages’ policies. https://code.google.com/p/ [4] Adam Barth. The web origin concept, 2011. chromium/issues/detail?id=233903. Accessed https://tools.ietf.org/html/rfc6454. 2015/05/07. [5] Dan Boneh and Matt Franklin. Identity-based [18] NCC Group. Javascript cryptography considered encryption from the Weil pairing. In Advances in harmful. https://www.nccgroup.trust/us/about-us/ CryptologyˆaA˘TCRYPTOˇ 2001, pages 213–229. newsroom-and-events/blog/2011/august/ Springer, 2001. javascript-cryptography-considered-harmful/. [6] Cristian Bravo-Lillo, Lorrie Cranor, Julie Downs, Accessed 2015/10/13. Saranga Komanduri, Stuart Schechter, and Manya [19] Warren He, Devdatta Akhawe, Sumeet Jain, Elaine Sleeper. Operating system framed in case of mistaken Shi, and Dawn Song. ShadowCrypt: Encrypted web identity: measuring the success of web-based spoofing applications for everyone. In Proceedings of the 2014 attacks on OS password-entry dialogs. In Proceedings ACM SIGSAC Conference on Computer and of the 2012 ACM conference on Computer and Communications Security, pages 1028–1039. ACM, communications security, pages 365–377. ACM, 2012. 2014. [7] Chromium. Sandbox. http://www.chromium.org/ [20] C. Herley. So long, and no thanks for the externalities: developers/design-documents/sandbox. Accessed the rational rejection of security advice by users. In 2015/10/13. Proceedings of the 2009 workshop on New security [8] Gabriele D’Angelo, Fabio Vitali, and Stefano paradigms workshop, pages 133–144. ACM, 2009. Zacchiroli. Content cloaking: preserving privacy with [21] Dongseok Jang, Ranjit Jhala, Sorin Lerner, and Hovav Google Docs and other web applications. In Shacham. An empirical study of privacy-violating Proceedings of the 2010 ACM symposium on applied information flows in javascript web applications. In computing, pages 826–830. ACM, 2010. Proceedings of the 17th ACM conference on Computer [9] Rachna Dhamija and J Doug Tygar. The battle and communications security, pages 270–283. ACM, against phishing: Dynamic security skins. In 2010. Proceedings of the 2005 symposium on Usable privacy [22] Billy Lau, Simon Chung, Chengyu Song, Yeongjin and security, pages 77–88. ACM, 2005. Jang, Wenke Lee, and Alexandra Boldyreva. Mimesis [10] Sascha Fahl, Marian Harbach, Thomas Muders, and aegis: A mimicry privacy shield–a system’s approach Matthew Smith. Confidentiality as a service–usable to data privacy on public cloud. In Proceedings of the security for the cloud. In 2012 IEEE 11th 23rd USENIX Security Symposium, pages 33–48. International Conference on Trust, Security and USENIX Association, 2014. Privacy in Computing and Communications [23] Jinjin Liang, Jian Jiang, Haixin Duan, Kang Li, Tao (TrustCom), pages 153–162. IEEE, 2012. Wan, and Jianping Wu. When HTTPS meets CDN: A [11] Sascha Fahl, Marian Harbach, Thomas Muders, case of authentication in delegated service. In Security Matthew Smith, and Uwe Sander. Helping Johnny 2.0 and Privacy (SP), 2014 IEEE Symposium on, pages to encrypt his Facebook conversations. In Proceedings 67–82. IEEE, 2014. of the Eighth Symposium on Usable Privacy and [24] Mozilla. Bug 866522 - bookmarklets affected by CSP. Security, page 11. ACM, 2012. https://bugzilla.mozilla.org/show_bug.cgi?id= [12] Ian Foster, Jon Larson, Max Masich, Alex C. Snoeren, 866522. Accessed 2015/05/07. Stegan Savage, and Kirill Levchenko. Security by any [25] Eric Rescorla. SSL and TLS – the internet threat other name: On the effectiveness of provider based model. http://www.iang.org/ssl/rescorla_1.html. email security. In Proceedings of the 2015 ACM Accessed 2015/10/07. SIGSAC Conference on Computer and [26] Chris Robison, Scott Ruoti, Timothy W van der Communications Security. ACM, 2015. Horst, and Kent E Seamons. Private Facebook chat. [13] Simson L Garfinkel and Robert C Miller. Johnny 2: a In Privacy, Security, Risk and Trust (PASSAT), 2012 user test of key continuity management with S/MIME International Conference on and 2012 International and Outlook Express. In Proceedings of the First Confernece on Social Computing (SocialCom), pages Symposium on Usable Privacy and Security, pages 451–460. IEEE, 2012. 13–24. ACM, 2005. [27] Scott Ruoti, Jeff Andersen, Travis Hendershot, Daniel [14] Shirley Gaw, Edward W. Felten, and Patricia Zappala, and Kent Seamons. Helping Johnny
11 understand and avoid mistakes: A comparison of 2015. automatic and manual encryption in email, 2015. [41] Alma Whitten and J. D. Tygar. Why Johnny can’t Under submission. encrypt: A usability evaluation of PGP 5.0. In 8th https://isrl.byu.edu/pubs/ruoti2016helping.pdf. USENIX Security Symposium, 1999. [28] Scott Ruoti, Jeff Andersen, Mark O’Neill, Scott [42] Wikipedia. Assistive technology service provider Heidbrink, Justin Wu, Elham Vaziripour, Daniel interface. https://en.wikipedia.org/wiki/ Zappala, and Kent Seamons. Johnny and Jane: Assistive_Technology_Service_Provider_Interface. Analyzing secure email using two novice users, 2015. Accessed 2015/10/13. Under submission. [43] Wikipedia. Pwm2own. https://isrl.byu.edu/pubs/ruoti2016johnny.pdf. https://en.wikipedia.org/wiki/Pwn2Own. Accessed [29] Scott Ruoti, Jeff Andersen, Daniel Zappala, and Kent 2015/10/13. Seamons. Why Johnny still, still can’t encrypt: Evaluating the usability of a modern pgp client, 2015. Under submission. https://isrl.byu.edu/pubs/ruoti2016why.pdf. [30] Scott Ruoti, Nathan Kim, Ben Burgon, Timothy van der Horst, and Kent Seamons. Confused Johnny: when automatic encryption leads to confusion and mistakes. In Proceedings of the Ninth Symposium on Usable Privacy and Security, page 5. ACM, 2013. [31] Scott Ruoti, Brent Roberts, and Kent Seamons. Authentication melee: A usability analysis of seven web authentication systems. In Proceedings of the 24th international conference on World wide web. International World Wide Web Conferences Steering Committee, 2015. [32] Jeff Sauro. A practical guide to the system usability scale: Background, benchmarks & best practices. Measuring Usability LLC, 2011. [33] S. Sheng, L. Broderick, CA Koranda, and JJ Hyland. Why Johnny still can’t encrypt: evaluating the usability of email encryption software. In Proceedings of the Second Symposium On Usable Privacy and Security - Poster Session, 2006. [34] Deian Stefan, Edward Z Yang, Petr Marchenko, Alejandro Russo, Dave Herman, Brad Karp, and David Mazieres. Protecting users by confining JavaScript with COWL. In Proceedings of the USENIX Symposium on Operating Systems Design and Implementation (OSDI 14), 2014. [35] Paul Stone. Pixel perfect timing attacks with HTML5. Context Information Security (White Paper), 2013. [36] Nik Unger, Sergej Dechand, Joseph Bonneau, Sascha Fahl, Henning Perl, Ian Goldberg, and Matthew Smith. SoK: Secure messaging. In Security and Privacy (SP), 2015 IEEE Symposium on. IEEE, 2015. [37] Timothy W van der Horst and Kent Eldon Seamons. Encrypted email based upon trusted overlays, March 2009. US Patent 8,521,821. [38] W3C. Content security policy. http://www.w3.org/TR/CSP/#processing-model. Accessed 2015/05/07. [39] W3C. Web messaging. http://www.w3.org/TR/ webmessaging/#channel-messaging. Accessed 2015/05/07. [40] Michael Weissbacher, Collin Mulliner, William Robertson, and Engin Kirda. BabelCrypt: The universal encryption layer for mobile messaging applications. In Financial Cryptography and Data Security: 19th International Conference, FC 2015, San Juan, Puerto Rico, January 26-30, 2015, Revised Selected Papers, volume 8975, page 355. Springer,
12