1 / 18

Collaborative Enforcement of Firewall Policies in Virtual Private Networks

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.

gail
Télécharger la présentation

Collaborative Enforcement of Firewall Policies in Virtual Private Networks

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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))

  6. 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)

  7. 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**

  8. 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)}

  9. 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] ……

  10. 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

  11. 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

  12. 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

  13. 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 ……

  14. 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

  15. 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

  16. 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

  17. 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

  18. Questions? Thank you!

More Related