Embark: Securely Outsourcing Middleboxes to the Cloud Chang Lan, - - PowerPoint PPT Presentation

▶
embark securely outsourcing middleboxes to the cloud
SMART_READER_LITE
LIVE PREVIEW

Embark: Securely Outsourcing Middleboxes to the Cloud Chang Lan, - - PowerPoint PPT Presentation

Apr 07, 2024 854 likes •1.31k views

Embark: Securely Outsourcing Middleboxes to the Cloud Chang Lan, Justine Sherry, Raluca Ada Popa, Sylvia Ratnasamy, Zhi Liu UC Berkeley Tsinghua University 1 Background Middleboxes are prevalent and problematic Number of Middleboxes

slide-1
SLIDE 1

Embark: Securely Outsourcing Middleboxes to the Cloud

Chang Lan, Justine Sherry, Raluca Ada Popa, Sylvia Ratnasamy, Zhi Liu UC Berkeley Tsinghua University

1

slide-2
SLIDE 2

Background

➢ Middleboxes are prevalent and problematic

■

Number of Middleboxes ≈ Number of Routers (APLOMB [SIGCOMM ‘12])

■

Lots of Problems:

■

MB Manifesto [HotNets ‘11], CoMb [NSDI ‘12], Honda et al. [IMC'11], DOA [OSDI '04], ETTM [NSDI '11], …

➢ A Promising Solution: Outsourcing ■ APLOMB [SIGCOMM ‘12] ■ Aryaka, Zscaler ■ AT&T NFV/CORD

2

slide-3
SLIDE 3

New Challenge: Confidentiality and Privacy

➢ The middleboxes sees the traffic unencrypted. ➢ Strawman: End-to-end Encryption (e.g. TLS):

■ Some middleboxes cannot process traffic (e.g. Deep Packet Inspection). ■ Unencrypted packet fields still leak information

3

slide-4
SLIDE 4

Enterprise Cloud Src IP: 169.229.123.170 Src Port: 21453 Dst IP: 172.217.1.36 (Google) Dst Port: 80

4

Src IP: 169.229.123.170 Src Port: 24363 Dst IP: Amazon Dst Port: 80 Src IP: 169.229.123.170 Src Port: 12568 Dst IP: Twitter Dst Port: 80 Src IP: 169.229.123.170 Src Port: 12568 Dst IP: Twitter Dst Port: 80 Src IP: 169.229.123.170 Src Port: 12568 Dst IP: Twitter Dst Port: 80 Src IP: 169.229.123.170 Src Port: 12568 Dst IP: Twitter Dst Port: 80 Src IP: 169.229.123.170 Src Port: 12568 Dst IP: Twitter Dst Port: 80

Even with end-to-end encryption, Cloud can still infer the user profile.

slide-5
SLIDE 5

Problem Statement

Can we outsource middleboxes without compromising privacy?

5

Embark

the first system that allows middlebox outsourcing, while keeping traffic confidential.

slide-6
SLIDE 6

Overview

➢ Approach ■ Middleboxes process encrypted traffic without decrypting it ➢ Crypto Primitives ■ KeywordMatch: For Signature Matching

■ BlindBox [SIGCOMM ‘15]: Prohibitive Setup Time Per Flow Contribution: System Design + Implementation without Per-flow Setup Time

■ PrefixMatch: Prefix/Range Matching

Contribution: A fast, secure encryption scheme for prefix matching

6

slide-7
SLIDE 7

Overview

➢ Approach ■ Middleboxes process encrypted traffic without decrypting it ➢ Crypto Primitives ■ KeywordMatch: For Signature Matching

■ BlindBox [SIGCOMM ‘15]: Prohibitive Setup Time Per Flow Contribution: System Design + Implementation without Per-flow Setup Time

■ PrefixMatch: Prefix/Range Matching

Contribution: A fast, secure encryption scheme for prefix matching

7

slide-8
SLIDE 8

Outline

1. Service Model of Embark 2. PrefixMatch: Two Functions

■ EncryptRanges ■ EncryptValue

3. Evaluation 4. Conclusion

8

slide-9
SLIDE 9

Service Model

9

Enterprise Cloud

slide-10
SLIDE 10

Service Model

10

Enterprise Cloud

Gateway

Encrypt / Decrypt traffic to/from the cloud

slide-11
SLIDE 11

Service Model

11

Enterprise Cloud

Middlebox Rules

IP firewall rules, IDS signatures, etc.

slide-12
SLIDE 12

Initialization

12

Enterprise Cloud

Enterprise encrypt rules using EncryptRanges.

slide-13
SLIDE 13

Initialization

13

Enterprise Cloud

Middleboxes deploy encrypted rules.

slide-14
SLIDE 14

Packet Flow

14

Enterprise Cloud

  • 1. Outgoing traffic

are sent to Gateway.

slide-15
SLIDE 15

Packet Flow

15

Enterprise Internet Cloud

  • 2. Encrypt the traffic

■ Encrypt packet headers field by field using EncryptValue

■

Encrypt payloads using stream cipher Implication: no change to packet structure

slide-16
SLIDE 16

Packet Flow

16

Enterprise Cloud

  • 3. Forward to Cloud
slide-17
SLIDE 17

Packet Flow

17

Enterprise Cloud

  • 4. Middleboxes process

encrypted traffic.

No change to algorithms: E.g., LPM, multi-dimensional classifiers, etc.

slide-18
SLIDE 18

Packet Flow

18

Enterprise Cloud

  • 5. Back to Gateway
slide-19
SLIDE 19

Packet Flow

19

Enterprise

Internet

Cloud

  • 6. Decrypt and Forward
slide-20
SLIDE 20

Outline

1. Service Model of Embark 2. PrefixMatch: Two Functions

■ EncryptRanges ■ EncryptValue

3. Evaluation 4. Conclusion

20

slide-21
SLIDE 21

PrefixMatch

➢ Property

■ Answer if a value V matches a range Ri from [R1, R2, ...]

➢ Security

■ Do not reveal the value of V and Ri ■ If both V1 and V2 match Ri, do not reveal the ordering between V1 and V2

21

slide-22
SLIDE 22

PrefixMatch vs. OPE

22

Operation BCLO mOPE PrefixMatch Encrypt, 10K rules 9333 us 6640 us 0.53 us Encrypt, 100K rules 9333 us 8300 us 0.77 us Decrypt 169 us 0.128 us 0.128 us

➢ Order-preserving Encryption

■ Preserve the ordering of values after encryption

➢ PrefixMatch is better than OPE in this scenario

■ More secure (No relative ordering) ■ Faster (10000x) ■ Compare with the state-of-the-art OPE schemes (BCLO and mOPE)

slide-23
SLIDE 23

EncryptRanges

➢ Firewall Rules

23

block from 192.168.1.0/24 to 205.203.224.0/19 block from 192.168.0.0/16 to 223.254.0.0/16 block from 10.1.0.0/16 to 223.201.0.0/16

slide-24
SLIDE 24

EncryptRanges

24

10.1.0.0/16 192.168.1.0/24

0.0.0.0 255.255.255.255

192.168.0.0/16 62.0.0.0/8 162.0.0.0/8 3.0.0.0/8 Assign Random Prefixes

slide-25
SLIDE 25

EncryptRanges

25

10.1.0.0/16 192.168.1.0/24

0.0.0.0 255.255.255.255

192.168.0.0/16 62.0.0.0/8 162.0.0.0/8 3.0.0.0/8

192.168.1.0/24 -> 3.0.0.0/8 192.168.0.0/16 -> 3.0.0.0/8 162.0.0.0/8 10.1.0.0/16 -> 62.0.0.0/8

slide-26
SLIDE 26

EncryptRanges

26

block from 192.168.1.0/24 to 205.203.224.0/19 block from 192.168.0.0/16 to 223.254.0.0/16 block from 10.1.0.0/16 to 223.201.0.0/16

Source IP 192.168.1.0/24 -> 3.0.0.0/8 192.168.0.0/16 -> 3.0.0.0/8 162.0.0.0/8 10.1.0.0/16 -> 62.0.0.0/8 Destination IP 205.203.224.0/19 -> 12.0.0.0/8 223.254.0.0/16 -> 241.0.0.0/8 223.201.0.0/16 -> 163.0.0.0/8

block from 3.0.0.0/8 to 12.0.0.0/8 block from 3.0.0.0/8 to 241.0.0.0/8 block from 162.0.0.0/8 to 241.0.0.0/8 block from 62.0.0.0/8 to 163.0.0.0/8

slide-27
SLIDE 27

➢ Encrypt each field independently ■

Source IP, Destination IP, Source Port, Destination Port...

EncryptValue

27

slide-28
SLIDE 28

EncryptValue

28

➢ Encrypt each field independently ■

Source IP, Destination IP, Source Port, Destination Port...

10.1.0.0/16 192.168.1.0/24

0.0.0.0 255.255.255.255

192.168.0.0/16 62.0.0.0/8 162.0.0.0/8 3.0.0.0/8

slide-29
SLIDE 29

EncryptValue

29

10.1.0.0/16 192.168.1.0/24

0.0.0.0 255.255.255.255

192.168.0.0/16 62.0.0.0/8 162.0.0.0/8 3.0.0.0/8 Src IP = 10.1.1.1

slide-30
SLIDE 30

EncryptValue

30

10.1.0.0/16 192.168.1.0/24

0.0.0.0 255.255.255.255

192.168.0.0/16 62.0.0.0/8 162.0.0.0/8 3.0.0.0/8 Src IP = 10.1.123.123 Enc (Src IP) = 62.0.0.0 + Rand(0, 2^24)

slide-31
SLIDE 31

➢ Problem 1: How to support NAT and Load Balancers?

■ Deterministic: The value from the same flow will be mapped to the same value ■ Injective: Values from different flows will be mapped to different values ■ Sufficient condition

EncryptValue

31

Src IP = 10.1.123.123 Enc (Src IP) = 62.0.0.0 + Rand(0, 2^24)

Sufficient condition: Let v = (sip, dip, sp, dp, proto) v’ = (sip’, dip’, sp’, dp’, proto’) v = v’ if and only if Enc(v) = Enc(v’)

slide-32
SLIDE 32

➢ Problem 1: How to support NAT and Load Balancers?

■ Use pseudorandom function, seeded by 5-tuple ■ Use IPv6 to avoid collisions

EncryptValue

32

Src IP = 10.1.123.123 Enc (Src IP) = 62.0.0.0 + Rand(0, 2^24) Src IP = ::FFFF:10.1.123.123 Enc (Src IP) = 3e00::/8 + PRF(Src IP)

slide-33
SLIDE 33

➢ Problem 1: How to support NAT and Load Balancers? ➢ Problem 2: How to decrypt?

■ Store AES(Src IP) in IP Options ■ Decrypt AES(Src IP)

EncryptValue

33

slide-34
SLIDE 34

Outline

1. Service Model of Embark 2. PrefixMatch: Two Functions

■ EncryptRanges ■ EncryptValue

3. Evaluation 4. Conclusion

34

slide-35
SLIDE 35

➢ What kinds of middleboxes does Embark support?

■ Performance of each type of middleboxes

➢ How much does PrefixMatch increase the number of rules? ➢ Microbenchmarks

■ How does PrefixMatch compare with OPE? ■ How well does PrefixMatch scale with the number of rules?

➢ Performance

■ How fast is the gateway (with PrefixMatch and with KeywordMatch) ■ How much does the service model increase the page load time?

Evaluation

35

slide-36
SLIDE 36

Supported Middleboxes

IP Firewall Linux iptables PrefixMatch NAT Linux iptables L3 Load Balancer ECMP L4 Load Balancer HAProxy HTTP Proxy Embark vs Squid KeywordMatch Parental Filter Embark vs Squid Intrusion Detection

(excluding scripts and other statistical techniques)

Embark vs Snort

36

slide-37
SLIDE 37

➢ Upper bound

■ O(nd), d is the number of fields

➢ Empirically

■ Rulesets ■ 3 firewall rulesets from campus network at UC Berkeley ■ 1 firewall ruleset from Emerging Threats ■ Result ■ UCB rulesets: No increase ■ Emerging Threats: from 1363 to 1370 ■ Intuition ■ Most firewall rules don’t overlap

How much does PrefixMatch increase Firewall rules?

37

slide-38
SLIDE 38

How fast is the gateway (without KeywordMatch)?

38

7.2 Gbps 1.2 Gbps Performance with 1k rules:

  • 1.2 Gbps (min-size)
  • Line rate (other cases)

With KeywordMatch enabled: 240 Mbps per core (Pkt size: 1400 B)

Baseline PrefixMatch

slide-39
SLIDE 39

See the paper for ...

39

  • How we design and implement middleboxes
  • Formal proof of sufficient conditions for NAT and L3/TCP Load Balancers
  • Limitations
  • More in-depth evaluation
  • ...
slide-40
SLIDE 40

Conclusion

Middleboxes can be outsourced in a way that still keeps the traffic confidential with Embark.

Paper: changlan.org/papers/embark. pdf Contact: clan@eecs.berkeley.edu Thanks!

40

slide-41
SLIDE 41

Related work

41

Middlebox Outsourcing:

  • Making Middleboxes Someone Else’s Problem. SIGCOMM 2012

Data Confidentiality

  • Shielding Applications from an Untrusted Cloud with Haven, OSDI 2014
  • Hails: Protecting Data Privacy in Untrusted Web Applications, OSDI 2012
  • Building Web Applications on Top of Encrypted Data Using Mylar, NSDI 2014
  • CryptDB: Protecting Confidentiality with Encrypted Query Processing, SOSP 2011
  • BlindBox: Deep Packet Inspection over Encrypted Traffic, SIGCOMM 2015
  • Multi-Context TLS (mcTLS): Enabling Secure In-Network Functionality in TLS, SIGCOMM 2015

Trace Anonymization and Inference

  • A High-level Programming Environment for Packet Trace Anonymization and Transformation, SIGCOMM 2003

Encryption Schemes

  • Order preserving encryption for numeric data, SIGMOD 2004
  • Order-Preserving Symmetric Encryption, EUROCRYPT 2009
  • An Ideal-Security Protocol for Order-Preserving Encoding, Oakland 2013
  • Fully Collusion Resistant Traitor Tracing with Short Ciphertexts and Private Keys, EUROCRYPT 2016
slide-42
SLIDE 42

How much does the service model inflate the page load time? (Alexa Top-500)

42

Median-case increase ISP/Central Office: < 50ms CDN: < 100 ms Public Cloud (EC2): < 720 ms

slide-43
SLIDE 43

How does PrefixMatch scale with # of rules?

43

Single-core Performance of PrefixMatch Packet size: 64 B

slide-44
SLIDE 44

➢ Primitive for Deep Packet Inspection

■ Detect if a keyword presents in a bytestream

➢ Searchable Encryption

■ Leverage the scheme in BlindBox (SIGCOMM ‘15)

➢ Reconstruct TCP Bytestream at the Gateway

■ Middleboxes receive bytestreams from a separate, reliable channel ■ Process packet flows based on bytestream content

KeywordMatch

44