Loading in 2 Seconds...

Collaborative Enforcement of Firewall Policies in Virtual Private Networks

Loading in 2 Seconds...

- 149 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about ' Collaborative Enforcement of Firewall Policies in Virtual Private Networks' - amanda-hatfield

**An Image/Link below is provided (as is) to download presentation**

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

### Collaborative Enforcement of Firewall Policies in Virtual Private Networks

Fei Chen

Dept. of Computer Science and Engineering

Michigan State University

Joint work with Prof. Alex X. Liu

Introduction

Virtual Private Network (VPN)

MSU

IBM

Malicious

websites

1.1.0.0/16

2.2.0.0/16

A secure hole

VPN Server

Firewall

IBM

Representative

Confidential

Database

1.1.0.10

2.2.0.1

2.2.0.25

2.2.0.2

Header

Header

Encrypted

Payload

Payload

Motivation

- The problem: MSU firewall cannot know what traffic is inside VPN
- Viruses or worms can enterinto MSU’s networks
- Two straight forward ways
- Goal: MSU and IBM collaboratively enforce the firewall policy without MSU knowing IBM packet and IBM knowing MSU firewall

MSU

Firewall

IBM

VPN Server

×

×

Firewall

packet

Related Work

- Secure Function Evaluation (SFE) (Yao, 1982)
- Garbled circuits (Yao, 1986)
- Computation cost is O(2b)
- Oblivious Attribute Certificates (OACerts) (Li et al., 2005)
- Trusted third party
- Expensive PKI operation
- Cross-Domain Cooperative Firewall (CDCF) (Cheng et al., 2007)
- CDCF is insecure
- MSU knows which rule matches which packet
- CDCF is inefficient
- It uses commutativeencryptionfunctions

Our Approach: VGuard

MSU

Firewall

IBM

VPN Server

- Key idea I: We propose Xhash protocol for oblivious comparison
- Three orders faster than the commutative encryption
- Key idea II: We uses Firewall Decision Diagrams (FDD)
- For security purpose, FDD can help to prevent MSU from knowing which rule matches which packet
- For efficiency purpose, processing packets using FDD is much more efficient than using linear search

f1(Firewall)

Bootstrapping Protocol

f2(f1(Firewall))

f2(packet)

1. Compute f1(f2(packet))

Filtering Protocol

decision

2. Search f1(f2(packet))inf2(f1(Firewall))

Oblivious Comparison

c1

c2

IBM

MSU

- Oblivious comparison problem
- Xhash protocol

c1=c2

?

If c1≠c2, no party should learn the value of the other party

c1⊕K1

IBM(K2)

MSU(K1)

h(c1⊕K1⊕K2)

c2⊕K2

Compute h(c2⊕K2⊕K1)

Compare with h(c1⊕K1⊕K2)

Membership Query

c

IBM

[a, b]

MSU

- Membership query problem
- Solutions using Xhash protocol

Does c in the range [a,b]?

No party should learn the value of the other party

[3, 7]

5

Prefix format

Prefix family

{011, 1**}

PF(5)={101, 10*,1**,***}

1**

1**

How to check the intersection of two sets in a privacy preserving manner ?

MSU

IBM

[3, 7]

5

Prefix format

Prefix family

{011, 1**}

PF(5)={101, 10*,1**,***}

Prefix numericalization

{01100, 10010}

{01100⊕K1, 10010⊕K1}

Prefix numericalization

{h(01100⊕K1⊕K2),

h(10010⊕K1⊕K2)}

Store

{h(01100⊕K1⊕K2),h(10010⊕K1⊕K2)}

{10111, 10010,10001,00011}

10111⊕K2, …,00011⊕K2

Compute

{h(10111⊕K2⊕K1), …, h(00011⊕K2⊕K1)}

The BootstrappingProtocol (1/3)

- Why to prevent MSU from knowing which rule matches which packet?

f1(Firewall)

Bootstrapping Protocol

f2(f1(Firewall))

f2(packet)

1. Compute f1(f2(packet))

2. Search f1(f2(packet))inf2(f1(Firewall))

Filtering Protocol

decision

IBM cannot figure out

Firewall by using f1(Firewall)

MSU may figure out packet by knowing the original rule that matches packet

f2(packet)

match

change by MSU

F1(packet) is in [1, 2]

F2(packet) is not in [5, 6]

……

The BootstrappingProtocol (2/3)

- Convert overlapping rules to non-overlapping rules

FDD

construction

Prefix

generation

Overlapping rules

Prefix

numericalization

Non-Overlapping rules

Rule

generation

XOR by MSU

(0100010⊕K1, 0000010⊕K1) → a

(0100010⊕K1, 0100011⊕K1) → a

(1000010⊕K1, 0000010⊕K1) → a

(1000010⊕K1, 0100011⊕K1) → a

(0100010⊕K1, 0110011⊕K1) → d

……

The order of non-overlapping rules does not affect their function

The BootstrappingProtocol (3/3)

(0100010⊕K1, 0000010⊕K1) → a

(0100010⊕K1, 0100011⊕K1) → a

(1000010⊕K1, 0000010⊕K1) → a

(1000010⊕K1, 0100011⊕K1) → a

(0100010⊕K1, 0110011⊕K1) → d

……

(h(0100010⊕K1⊕K2), h(0000010⊕K1⊕K2)) → a

(h(0100010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → a

(h(1000010⊕K1⊕K2), h(0000010⊕K1⊕K2)) → a

(h(1000010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → a

(h(0100010⊕K1⊕K2), h(0110011⊕K1⊕K2)) → d

……

Send to IBM

IBM shuffles rules

(h(0100010⊕K1⊕K2), h(0000010⊕K1⊕K2)) → a

(h(0100010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → a

(h(1000010⊕K1⊕K2), h(0000010⊕K1⊕K2)) → a

(h(0100010⊕K1⊕K2), h(0110011⊕K1⊕K2)) → d

(h(1000010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → a

……

- MSU statistically analyze
- Frequency of values
- Frequency of decisions

Send back to MSU

IBM add

dummy rules

(h(0100010⊕K1⊕K2), h(dummy1⊕K2)) → d

The Filtering Protocol (1/2)

0101 0011

010* 001*

01** 00**

0*** 0***

**** ****

0101100 0011100

0100011 0010011

0100010 0000010

0000001 0000001

0000000 0000000

A Packet:

Prefix family

generation

Prefix

Numericalizaiton

(0101, 0011)

XOR by IBM

h(0101100⊕K2⊕K1) h(0011100⊕K2⊕K1)

h(0100011⊕K2⊕K1) h(0010011⊕K2⊕K1)

h(0100010⊕K2⊕K1) h(0000010⊕K2⊕K1)

h(0000001⊕K2⊕K1) h(0000001⊕K2⊕K1)

h(0000000⊕K2⊕K1) h(0000000⊕K2⊕K1)

0101100⊕K20011100⊕K2

0100011⊕K2 0010011⊕K2

0100010⊕K2 0000010⊕K2

0000001⊕K2 0000001⊕K2

0000000⊕K2 0000000⊕K2

XOR and HMAC

By MSU

The Filtering Protocol (2/2)

- To improve search efficiency, MSU can convert non-overlapping rules to a FDD

(h(0100010⊕K1⊕K2), h(0000010⊕K1⊕K2)) → d

(h(0100010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → d

(h(1000010⊕K1⊕K2), h(0110011⊕K1⊕K2)) → a

(h(1000010⊕K1⊕K2), h(0100011⊕K1⊕K2)) → d

(h(0100010⊕K1⊕K2), h(0110011⊕K1⊕K2)) → a

(h(dummy5⊕K1⊕K2), h(dummy7⊕K1⊕K2)) → d

……

Experimental Results (1/3)

- For real-life firewalls in bootstrapping protocol
- Bootstrapping cost of VGuard is lower than that of CDCF for most firewalls

MSU

IBM

Experimental Results (2/3)

- For real-life firewalls in filtering protocol
- VGuard is 552 times faster than CDCF on the MSU side
- VGuard is5035 times faster than CDCF on the IBM side

(Log scale)

(Log scale)

MSU

IBM

- Two intuitive reasons for the better performance
- Xhash is three orders faster than commutative encryption
- FDD is much efficient to search the decision of a given packet

Experimental Results (3/3)

- For synthetic firewall policies in filtering protocol
- VGuard is 252 times faster than CDCF on the MSU side
- VGuard is5529 times faster than CDCF on the IBM side

(Log scale)

(Log scale)

MSU

IBM

Concluding Remarks

- VGuard is secure
- VGuard prevents MSU from identifying which rule matches the given packet
- VGuard is efficient
- Xhash is three orders faster than the commutative encryption
- VGuard uses firewall decision diagrams for processing packets
- Xhash is very efficient for oblivious comparison and can be used for other applications

Questions?

Thank you!

Download Presentation

Connecting to Server..