21-09-2012, 04:17 PM
Privacy Preserving Collaborative Enforcement of Firewall Policies in Virtual Private Networks
Privacy Firewall.pdf (Size: 1.54 MB / Downloads: 16)
Abstract
The widely deployed Virtual Private Network (VPN) technology allows roaming users to build an encrypted tunnel to a VPN
server, which, henceforth, allows roaming users to access some resources as if that computer were residing on their home
organization’s network. Although VPN technology is very useful, it imposes security threats on the remote network because its firewall
does not know what traffic is flowing inside the VPN tunnel. To address this issue, we propose VGuard, a framework that allows a
policy owner and a request owner to collaboratively determine whether the request satisfies the policy without the policy owner
knowing the request and the request owner knowing the policy. We first present an efficient protocol, called Xhash, for oblivious
comparison, which allows two parties, where each party has a number, to compare whether they have the same number, without
disclosing their numbers to each other. Then, we present the VGuard framework that uses Xhash as the basic building block. The
basic idea of VGuard is to first convert a firewall policy to nonoverlapping numerical rules and then use Xhash to check whether a
request matches a rule. Comparing with the Cross-Domain Cooperative Firewall (CDCF) framework, which represents the state-of-theart,
VGuard is not only more secure but also orders of magnitude more efficient. On real-life firewall policies, for processing packets,
our experimental results show that VGuard is three to four orders of magnitude faster than CDCF.
INTRODUCTION
Background and Motivation
VIRTUAL Private Network (VPN) is a widely deployed
technology that allows roaming users to securely use a
remote computer on the public Internet as if that computer
were residing on their organization’s network, which,
henceforth, allows roaming users to access some resources
that are only accessible from their organization’s network.
VPN works in the following manner. Suppose IBM sends a
field representative to one of its customers, say Michigan
State University (MSU). Assume that MSU’s IP addresses
are in the range 1.1.0.0-1.1.255.255 and IBM’s IP addresses
are in the range 2.2.0.0-2.2.255.255. To access resources (say,
a confidential customer database server with IP address
2.2.0.2) that are only accessible within IBM’s network, the
IBM representative uses an MSU computer (or his laptop)
with an MSU IP address (say, 1.1.0.10) to establish a secure
VPN tunnel to the VPN server (with IP address 2.2.0.1) in
IBM’s network. Upon establishing the VPN tunnel, the IBM
representative’s computer is temporarily assigned a virtual
IBM IP address (say, 2.2.0.25). Using the VPN tunnel, the
IBM representative can access any computer on the Internet
as if his computer were residing on IBM’s network with IP
address 2.2.0.25. The payload of each packet inside the VPN
tunnel is another packet (to or from the newly assigned IBM
IP address 2.2.0.25), which is typically encrypted.
Technical Challenges
This problem is technically challenging. First, MSU cannot
simply block VPN connections because, otherwise, the
IBM representative may fail to perform his duties. Second,
MSU cannot share its firewall policy with IBM. Firewall
policies are typically kept confidential due to security and
privacy concerns. Knowing the firewall policy of a
network could allow attackers to easily spot the security
holes in the policy and launch corresponding attacks. A
firewall policy also reveals the IP addresses of important
servers, which are usually kept confidential to reduce the
chance of being attacked. Furthermore, from a firewall
policy, one may derive the business relationship of the
organization with their partners. Third, IBM cannot share
the traffic in its VPN tunnel with MSU due to security and
privacy concerns.
Limitations of Prior Art
Although this is a fundamentally important problem, it is
largely underinvestigated. The state-of-the-art on this
problem is the seminal work in [5], where Cheng et al.
proposed a scheme called CDCF. However, CDCF is
vulnerable to selective policy updating attacks, by which
the policy owner can quickly reveal the request of the other
party. Furthermore, CDCF is inefficient because it uses
commutative encryption functions (such as the Pohlig-
Hellman Exponentiation Cipher [13] and Secure RPC
Authentication (SRA) [16]), which are extremely expensive
in nature, as the core cryptography primitive.
Our Solution
In this paper, we present VGuard, a secure and efficient
framework for collaborative enforcement of firewall policies.
In VGuard, different from CDCF, the policy owner
does not know which rule matches which request; thus, it
makes the selective policy updating attacks infeasible.
Furthermore, unlike CDCF, VGuard obfuscates rule decisions,
which prevents MSU from knowing the decision for
the given packet. To make VGaurd efficient, we propose a
new oblivious comparison scheme, called Xhash, which
uses XOR and secure hash functions. Xhash is three orders
of magnitude faster than the commutative encryption
scheme used in CDCF. Moreover, VGuard uses decision
diagrams to process packets, which is much faster than the
linear search used in CDCF. By side-by-side comparison,
our experimental results show that VGuard is 552 times
faster than CDCF on MSU side and 5,035 times faster than
CDCF on IBM side.
THREAT MODEL
First, we assume that the two parties of policy owner MSU
and request owner IBM are semihonest; that is, they follow
the preestablished VGuard protocol, but the policy owner
may attempt to reveal the request and the request owner
may attempt to reveal the policy. In particular, the
enforcement party IBM does enforce the decision made by
MSU. The assumption that the two parties follow the
VGuard protocol can be realized by the service level
agreement between MSU and IBM. Furthermore, we
assume that neither MSU nor IBM has the computational
power to break secure hash functions such as HMAC-MD5
or HMAC-SHA1 [7], [10], [14]. Second, we assume that
there exists a third party that facilitates the execution of our
protocol. This third party shares a secret key with MSU. We
assume that this third party follows our protocol and will
collude with neither MSU nor IBM. Third, we assume that
between any two of the three parties, MSU, IBM, and the
third party, there exists a reliable and secure channel. These
channels can be established using protocols such as SSL.
Our VGuard protocol runs inside these channels. Thus, we
do not consider the network level attacks on the communication
channels that VGuard is built upon.