1. Security and Privacy-preserving Applications minus the Pain Mohit Tiwari, Andrew Osheroff, Neel Rao, Prashanth Mohan, Eric Love, Elaine Shi, C. Papamanthou, Dawn Song, Krste Asanović UC Berkeley 1

2. Security for Users’ Benefit: Contexts Users – ACLs are natural. But on what? (posts, tweets, photos, spreadsheets,…) – Contexts: real-world events that data clusters around Developers – want to partition apps to provide rich functionality. But security labels? – App design pattern System – Info flow control desired. How to use simple, legacy mechanisms? – Mandatory ACLs + Layout generators + Integrity checking 2

3. App-centric Security: Problematic Permissions are complex – SD Card, File systems,… – 51 of 100+: dangerous – Statically assigned. App owns user’s data 3 What a Dope!

4. Information Flow Control: Problematic Data X  Principals Policies on Labels 4

5. NSF Proposal Security Course Files Camera Microphone Wifi Apps Contexts System resources Users Problem: User maps Contexts to Policies 5

6. Bubbles: Context-centric Security Data clusters around real-world contexts. Privacy policy as access control on contexts. Apps run in Bubbles; cannot affect privacy. NSF Proposal Security Course 6

7. 7

8. 8 Messages Events Data from current bubble only ACL for the bubble Simple Permissions (7/51 dangerous ones)

9. A Bubble is the Minimum Unit of Sharing Untrusted code can arbitrarily mix data inside a bubble – Hence, sharing one item == sharing any item Have to limit cross-bubble declassification – So that user has flexibility of re-sharing, e.g. meeting notes Bubbles have to be very light-weight contexts – when in doubt, just create a new bubble. Work/Personal very coarse 9

10. Challenges in implementing Bubbles Lots of bubbles  UI for navigating bubbles Apps don’t own data  API for developers System implementation  Infer dangerous permissions, and create light-weight containers 10

11. 11 Predict bubbles: current location, time, contacts, calendar Search by tags … by contacts

12. 12 …filter by location

13. Bubbles App Design Pattern Developer Updates, Ads, … Developer Zone User Marin Hike B’day Party Public profile info 13

14. Application Design Pattern: 3 components App – one app instance per bubble – app component examples to follow Viewer – developer provides Layout file. – system generates the viewer, assigns per-bubble data into layout elements Storage – deduplication, replication, caching, … 14

15. Message board 15

16. Calendar 16

17. Remote Medicine 17

18. App Component Most user-visible functionality – one app instance per bubble App can write data snapshots into tiles on bubble home page What about cross-bubble functionality? 18

19. 19 Layout by developer + putData(), flushData(), chooseBubble() Transfer to App component to edit New events: trusted UI to select bubbles

20. Storage Component Untrusted apps need unencrypted data from multiple bubbles – deduplication not efficient otherwise – performance: a shared memcached instance – legacy code: couchDB storage backend Untrusted applications can leak data across bubbles – how to declassify output of such applications? Cross-bubble functionality hidden behind storage abstraction – put – get (data): Integrity check data and declassify. 20

21. ComponentAPI CallsBubbles Actions Application POSIX/Android put,get_to_storage_chk register_app_interface( wsdl_file ) Linux syscall API. No compiler/runtime or hardware support required. Bubbles’ Storage checker stores a hash of put data, and uses the hash to declassify output of get. Bubbles uses wsdl_file to connect application with presentation layer. Storage put,get_frm_storage_chk Bubbles lets Storage components access plain text data from multiple capsules with different ACLs – key to storage optimizations like deduplication. Bubbles uses integrity checking to ensure data isn’t leaked across capsules – outputs can be declassified safely. Viewer Layout Template (HTML/js subset) wsdl_function_call( func, data) Bubbles uses template to generate HTML views; and ensures that data across capsules are mutually isolated. Bubbles ensures that data is sent only to data ’s bubble- specific Application instance – data can thus be declassified safely. Bubbles API API based on functionality, not security labels Benign apps see no security exceptions. Malicious behavior terminated

22. Application-initiated sharing – Recommendation engines, Spam filters – Differential privacy, k-anonymity, … User-initiated sharing – Storing, sharing, and editing docs – Real-time communication (voice, video) Pseudonymous: Not tied to real identity – Games, flashlights, wallpapers, – Browsing news, reviews, recipes, … Many Android Apps fit inside Bubbles Percent (of 700 top apps) 22

23. Data-centric Security policies = User-initiated sharing (this talk) + Anonymity (Link privacy, GUPT) Many Cloud-based Applications too fit Bubbles app initiated sharing pseudonymity user initiated sharing

24. System Design and Implementation Mandatory Access Control (MAC) for isolation, and – Bubble control and search – Viewer Layout Inflater – Sharing service: distributed database (use like sqlite) – modified android middleware: IPC, virtualized system logs per label System uses ACLs and API to infer detailed policy – Bubbles apps cover a lot of functionality of secure DIFC-based apps – Robust Declassification: Integrity checking (storage) and layout language (viewer) Minus the pain: users, developers don’t work with security labels 24

25. Context-centric Security Bubbles Project Context = data clustered around real-world events – minimum unit of sharing data. Is working in contexts intuitive? Learnable? Does API support all useful functionality? 25