Evolution of Surveillance in Cloud Computing
Delve into the historical progression of surveillance in cloud computing, from the era of lawful intercept agencies pressuring the internet community to weaken its tech to the modern landscape where mobile devices dominate traffic, leading to new challenges and solutions in protecting data privacy and security.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Microsoft Cloud Computing Research Centre KCL, Feb 18, 2015 Cloud Panopticon: Technical History Jon Crowcroft jon.crowcroft@cl.cam.ac.uk 1
Brief History of Surveillance Immune System We ve been here before mid 1990s lawful intercept agencies pressured Internet Community to weaken its tech Response was (aptly numbered) rfc1984 http://tools.ietf.org/html/rfc1984 IAB/IESG/Internet Society/IETF Attacks included Weakened keys, Key escrow Weaknesses included Conflicting International Policies Use of multiple layered encryption 2
What happened next? IETF won 1. TLS/HTTPS started to become routine 2. DNSSec & Certifcates 3. Cryptography 4. Better securing of infrastructure 3
Surveillance and DPI Tech for deep packet inspection, e.g. Endace Initially developed for traffic engineering to reveal popular application sest and traffic matrix Became widely used for full packet capture at IXPs Port mirrors all the data to security agency Response: accelerate default use of HTTPs/TLS Together with NATs, makes network intercept worthless Even for meta-data 4 4
What happens next? Around this time, dominant traffic became Mobile Device (many) <-> Cloud provider (few) Key changes are: Even more obfucasted (and secure) end points, but Far far less, highly visible end points instead of 100M NATd desktops talking to 100M websites, we have a billion smart phones talking to a dozen cloud providers, almost all of latter in the US Attack surface very very obvious 5 5
Surveillance on Cloud Was easy because: Easy to find cloud data centers Data stored in plain, so that analytics can work Data between cloud machines was txferred in plain Data is processed in the plain, so that targeted adverts can work i.e. the main (2 sided) business model of cloud makes them idea to be weaponised. 6 6
What happened next Those revelations Embarrassed & annoyed libertarian tech cloudsters Vancouver IETF plenary response vehement http://paravirtualization.blogspot.co.uk/2014/10/big-brother20- debateconversazione-lady.html Wes Hardaker sstory Tech solutions 1. Crypt data between data centers (google) 2. Crypt data in storage (most) 3. Client side decrypt (apple) 4. Research in cryptic processing is ongoing 7 7
Future Securing key distribution (see RFC1984) Viable solutions for cloud service on crypted data Search, targeted ads, solutions exist Analytics could use trusted 3rd party now Later, we ll see 8 8
What happens to lawful intercept? Two extremes 1. They lose 2. They have to do their job properly and 1. Have probable cause 2. get warrants 3. Do intelligence 3. Law mandates client side trapdoors (against RFC1984) 9 9
Conclusion The arms race between security agencies and bad guys on the one hand And the public on the other Is not new Is not over Is not transparent or informed by good cost benefit analysis; see for example this Cato report Responsible Counterterrorism Policy http://www.cato.org/publications/policy-analysis/ 10 10
Refs Hon, W. Kuan and Millard, Christopher and Reed, Chris and Singh, Jatinder and Walden, Ian and Crowcroft, Jon, Policy, Legal and Regulatory Implications of a Europe-Only Cloud (November 21, 2014). Queen Mary School of Law Legal Studies Research Paper. Available at SSRN: http://ss&+rn.com/abstract=2527951 @TechReport{UCAM-CL-TR-863, author = {Singh, Jatinder and Bacon, Jean and Crowcroft, Jon and Madhavapeddy, Anil and Pasquier, Thomas and Hon, W. Kuan and Millard, Christopher}, title = {{Regional clouds: technical considerations}}, year = 2014, month = nov, url = {http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-863.pdf}, institution = {University of Cambridge, Computer Laboratory}, number = {UCAM-CL-TR-863} } 11 11
Microsoft Cloud Computing Research Centre UCL, Dec 18, 2014, Part Deux Regional clouds: technical considerations Jon Crowcroft jon.crowcroft@cl.cam.ac.uk Jat Singh jatinder.singh@cl.cam.ac.uk 12
Regional Clouds Hard to define, many outstanding issues Management and control underpins the rhetoric Who has the power (capability), who is trusted. Technical mechanisms for management Offerings in a regional-cloud context Implications - does this make sense? Research, improving industrial best-practices 13
Outline Explore different levels of the technical stack Focus: 1. Network-level routing 2. Cloud provisioning 3. Cryptography 4. Flow controls ( data tagging ) 14
Internet & Routing Controls Autonomous Systems (AS): sections of the network Internet exchange points: exchange between AS Border Gateway Protocol encapsulates the routing policy between networks In practice, routing policy reflects peering/service/business arrangements 15 15
Internet & routing controls (regional clouds) Cloud providers manage their infrastructure Many already account for geography for better service provisioning (performance, latency, etc.) Bigger providers already involved in peering arrangements Technically feasible with right incentives to ensure that data is routed within a geographical boundary E.g. economic benefits, regulation, But such an approach is blunt applies to all traffic, regardless 16 16
Cloud provisioning: service levels SaaS? Speci ic? application? services? Security? ? Management? Monitoring? Accounting? Audit? ? PaaS? Maybe Illustrate Tenants/users Speci ic? languages? and? tools? Speci ic? libraries? and? services? (e.g.? storage)? ? Middleware:? Inter-process? communication? Operating? system? IaaS? Hypervisor:? Supports? VMs? and? possibly? VM? IPC? Hardware:? data? center? facilities? (machines,? disks,? network)? Routing? /? peering? arrangements? Provider manages that below, tenants above Different management concerns for each service offering 17 17
Cloud provisioning: service offerings Already work on tailoring services to particular constraints Differential privacy: tailor query results to not reveal too much private information Already offer services based on user/tenant locale Not only for performance, but also security, rights management, etc. (e.g. iPlayer) Providers already manage their infrastructure Customising service and content for regional concerns Thus, already the capability to tailor services for particular regional and/or jurisdictional concerns 18 18
Cloud provisioning: Unikernels Cloud exists to leverage shared infrastructure Isolation is important: VMs Separate for tenants, complete OS, managed by hypervisor Containers shared OS, isolated users Deployment heavy, isolation overheads, Future? Unikernels: library OS, build/compile a VM with only that required Hypervisor managed, removes user-space isolation concerns 19 19
Cloud provisioning: Unikernels (2) Very small, lightweight easily deployed VMs: Easily moved around the infrastructure Deploy in locales/jurisdictions when/where relevant Facilitates customised services Specific unikernels for particular services Encapsulating specific jurisdictional requirements? Transparency: Natural audit trail Pulls that what is required to build, on demand 20 20
Cryptography Range of purposes: Data protection: storage, transit, comm. channels Authentication, certification, attestation, etc. Encryption Unintelligible, except those with the keys encrypt(plaintext, key) => ciphertext decrypt(ciphertext, key) => plaintext Regional Q: Who can (potentially) access the keys? 22 22
Client-side encryption C P Cloud provider Client Cloud services Computation generally on plaintext Fully homomorphic encryption not practicable (yet) Encrypted search, privacy-preserving targeted ads 23 23
Encryption and keys Who could access the keys? Trust and legal regime(s) Client-held keys Cloud providers holding client keys Providers now (internally) use crypto provisioning Trusted third-parties: CAs, Key-escrows Key management isn t easy Vulnerabilities: compromised keys, broken schemes and/or implementations Transparency: when was data decrypted? 24 24
Flow controls: data tagging Tag data to track, and control where it flows Metadata stuck to data to effect data management policy Cloud benefits: Management within the provider s realm Control and/or assurance, transparency Various approaches E.g. CSN @ Imperial: tenants collaborate to find leaks Information Flow Control (IFC) 25 25
IFC: Regional isolation at application-level Entities run in a security context (tagged) Tags: <concern, specifier> <zone, EU> Service X <zone, EU> Database <zone, EU> <zone, EU> Application 1 <zone, EU> <zone, EU> Service X <zone, US> All context and flows audited Mechanisms for EU->US, but trusted, privileged (audited!) 26 26
IFC: Ongoing work Experimenting at the OS level, all application-level I/O System-calls within, messaging across machines Requires a trusted-computing base Protects at levels above enforcement Much more to do! Enforcement: Small as possible, verifiable, hardware Policy specification Privilege management Tag specifications and naming 27 27
IFC in the cloud Control and transparency Within the realm of the cloud provider Data-centric, fine-grained isolation Enforcement naturally leads to audit Aims at compliance/assurance, generally not spooks Potential for virtual jurisdiction? Cloud isolates/offers services for specific jurisdictions 28 28
Conclusion Regional cloud issues concern data management Technical mechanisms for control, and transparency Different mechanisms at different technical levels Different capabilities, visibility Developments in this space Improve cloud best practice May address concerns underpinning the balkanisation rhetoric 29 29
To summarise Nearly 20 yrs ago, CALEA asked us to colludge in weaker security for everyone This would be bad for civil society, so We said no! Now Snowden reveals that we were ignored Tit-for-tat is optimal strategy: This time we will make it no! 30 30
Technical workshop CLaw: Legal and technical issues in cloud computing IC2E: IEEE International Conference on Cloud Engineering (Mar 2015) http://conferences.computer.org/IC2E/2015 31 31
Information Flow Control: Regional example (2) Only privileged, trusted, entities may change context Encrypt EU data before sending Context change Audit <zone, US> Application 1 <zone, EU> <zone, US> Application 1 Application 2 <zone, US> 32 32
Information Flow Control: Regional example (2) More accurate <zone, EU> zone-mixer <zone, EU> <zone, US> NB this isn t application 1 , as it s previous outputs would have had US and EU tagged outputs Context change Audit Application 2 <zone, US> <zone, US> zone-mixer <zone, US> 33 33
