1

Microsoft Cloud Computing Research Centre

1st Annual Symposium, Cambridge 2014

Jon Crowcroftjon.crowcroft@cl.cam.ac.uk

Cloud Panopticon: Technical History

2

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

3

What happened next?

IETF “won”

1. TLS/HTTPS started to become routine

2. DNSSec & Certifcates

3. Cryptography

4. Better securing of infrastructure

4 4

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”

5 5

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

6 6

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.

7 7

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’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

8 8

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

9 9

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)

10 10

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/

11 11

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}

}

12

Microsoft Cloud Computing Research Centre

1st Annual Symposium, Cambridge 2014

Jat Singhjatinder.singh@cl.cam.ac.uk

Jon Crowcroftjon.crowcroft@cl.cam.ac.uk

Regional clouds: technical considerations

13

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’

14

Outline

Explore different levels of the technical stack

Focus:

1. Network-level routing

2. Cloud provisioning

3. Cryptography

4. Flow controls (‘data tagging’)

15 15

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

16 16

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

17 17

Cloud provisioning: service levels

• Provider manages that below, tenants above

• Different management concerns for each service offering

Maybe IllustrateTenants/users

18 18

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

19 19

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

20 20

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

21

Data-centric controls

22 22

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?

23 23

• Cloud services

– Computation generally on plaintext

– Fully homomorphic encryption not practicable (yet)

– Encrypted search, privacy-preserving targeted ads

Client-side encryption

Cloud provider

Client

P C

24 24

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?

25 25

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)

26 26

IFC: Regional isolation at application-level

Application 1<zone, EU>

<zone, EU>Database

<zone, EU>Service X

<zone, EU>

✔

Service X<zone, US>

<zone, EU>

✖

<zone, EU>

✔

• Entities run in a ‘security context’ (tagged)

• Tags: <concern, specifier>

• All context and flows audited

• Mechanisms for EU->US, but trusted, privileged (audited!)

27 27

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

28 28

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

29 29

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

30 30

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!

31 31

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

32 32

Information Flow Control: Regional example (2)

Application 1<zone, EU>

Application 2<zone, US>

• Only privileged, trusted, entities may change context

– Encrypt EU data before sending

Application 1<zone, US>

Context changeAudit <zone, US>

✔

33 33

Information Flow Control: Regional example (2)

zone-mixer<zone, EU><zone, US>

Application 2<zone, US>

• More accurate…

zone-mixer<zone, US>

Audit

<zone, US>

✔

<zone, EU>

✔

Context change

NB this isn’t “application 1”,as it’s previous outputs would have had US and EU tagged outputs…