Microsoft Cloud Computing Research Centre
CloSe Workshop, Apr 16, 2014
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-brother20debateconversazione-lady.html
• Wes Hardaker’s story…
• 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 =
year =
month =
url =
{{Regional clouds: technical considerations}},
2014,
nov,
{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
CloSe, Apr 16, Part Deux
Regional clouds: technical considerations
Jon Crowcroft
Jat Singh
jon.crowcroft@cl.cam.ac.uk
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
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
Security
Management
Monitoring
Accounting
Audit
…
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
Data-centric controls
21
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>
<zone, EU>
Application 1
<zone, EU>
✔
✔
Database
<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
Audit
Context
change
Application 1
<zone, EU>
US>
<zone, US>
✔
Application 2
<zone, US>
32
32
Information Flow Control: Regional example (2)
• More accurate…
<zone, EU>
✔
Audit
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
Application 2
<zone, US>
<zone, US>
✔
zone-mixer
<zone, US>
33
33