Privacy-Preserving Data Packet Filtering Protocol with Source IP Authentication

Abstract

Packet filtering allows a network gateway to control the network traffic flows and protect the computer system. Most of the recent research works on the filtering systems mainly concern the performance, reliability and defence against common network attacks. However, since the gateway might be controlled by red an untrusted attacker, who might try to infer the identity privacy of the sender host and mount IP tracking to its data packets. IP spoofing is another problem. To avoid data packets to be filtered in the packet filtering system, the malicious sender host might use a spoofed source IP address. Therefore, to preserve the source IP privacy and provide source IP authentication simultaneously in the filtering system is an interesting and challenging problem. To deal with the problem, we construct a data packet filtering scheme, which is formally proved to be semantic secure against the chosen IP attack and IP guessing attack. Based on this filtering scheme, we propose the first privacy-preserving packet filtering system, where the data packets whose source IP addresses are at risk are filtered, the privacy of the source IP is protected and its correctness can be verified by the recipient host. The analysis shows that our protocol can fulfil the objectives of a data packet filtering system. The performance evaluation demonstrates its applicability in the current network systems. We also presented a packet filtering scheme, where the data packets from one subnet can be filtered with only one filter policy.

1 Introduction

Computer networks have encountered many types of attacks such as Denial-of-Service (DoS), IP spoofing, network inspection and unauthorized access, etc. The data packet filtering systems (e.g., [1, 2]) have played an important role in firewalls for protecting a local network or a computer system against intrusion. In Internet, packet filtering is the process of passing or blocking packets at a network interface based on specific filtering rules, e.g. the source and destination addresses, ports, or protocols.

Take the source IP address-based packet filtering mechanism as an example. As shown in Fig. 1, the data packets from a sender host with specified source IP address “130.10.1.1” will be filtered and blocked. The recipient host of IP address “175.10.1.2” lists the source IP addresses at risk in the access control list (ACL). Assume the IP address “130.10.1.1” is in the ACL. Firstly, the recipient host specifies the IP address “130.10.1.1” at the recipient gateway. There are many data packets which are of the same destination IP address “175.10.1.2” arriving at the recipient gateway. The recipient gateway, acting as a filter router, operates the filtering process and filters out the data packet whose source IP is “130.10.1.1” (called DROP) and approves others (called ACCEPT) based on the specified filtering policy. Then the recipient gateway forwards the approved data packets to the recipient host.

Fig. 1

Data packet filtering mechanism

Since the birth of the seminal BSD packet filter (BPF) [3], filtering systems have become essential to a variety of network services ranging from traffic monitoring [4] to intrusion detection [5] in network. The research of the filtering system mainly concern about improving the filtering performance for large volume of data packets [6], providing fault tolerance, stability and reliability in the filtering systems [7,8,9] and protecting the network against the common attacks [10,11,12,13], e.g. the Denial-of-Service (DoS) attacks, Distributed Denial-of-Service (DDoS) attacks, the spoofing attacks, the packet drop attacks and so on.

In the existing filtering systems [6,7,8,9,10,11,12,13], the IP headers are in plaintext, where the outsiders and the recipient gateways can obtain the source IP addresses. Some IP addresses might be sensitive, e.g. the IP addresses used in the army, the government or the special organizations. When the attackers including the outside attackers and the untrusted gateway know their IP addresses, these attackers might mount long-time IP tracking and auditing to learn the sensitive information. Therefore, for these special cases the IP addresses should be protected. One approach to protect the IP addresses is to encrypt the IP headers in the filtering systems [14, 15]. However, this approach will block the filtering function. A privacy-preserving packet filtering system becomes a desirable issue.

As shown in Fig. 1, to escape from the packet filtering, a malicious sender host might spoof the source IP address in its data packets. Therefore, in our system, the malicious data packets should be correctly filtered out and the source IP address of the legal data packet should be authenticated to resist IP spoofing, while in both cases the privacy of the IP addresses is protected against the outsiders and the recipient gateway.

Soundness and completeness are two important properties for the filtering system, which are used to show the system can work properly. Soundness means any illegal data packet should be filtered out and dropped, while completeness means none of the legal data packets is filtered out.

It is difficult to design a filtering system, where both soundness and completeness are met; the IP privacy is preserved against the recipient gateway; and the IP spoofing attack can be resisted at the same time for both hardware and software based filtering mechanisms. A plausible approach is the searchable encryption (SE) [16]. However, SE cannot meet our objective since the gateway is still able to obtain the source IP address by insider IP guessing attacks. Hence, to construct a packet filtering scheme without leaking the source IP privacy is still a challenging problem.

In this paper, we explore a privacy-preserving packet filtering system to deal with the problems of source IP privacy protection and authentication. In the novel system, the filter policy is defined at the recipient gateway, and an index is included in each data packet. A filtering function takes as input the index of the data packet and one piece of filtering policies. If one of the filtering functions outputs “1”, the data packet is filtered out and dropped. Otherwise, if all of the filtering functions output “0”, the data packet is accepted and forwarded to the recipient host. Then the recipient host authenticates the source IP address. During the whole process, the recipient gateway executes the filtering operation without obtaining the source IP address.

Contribution We propose the first privacy-preserving data packet filtering protocol in Internet. To summarize, the major contributions are of four folds.

• We introduce a new privacy-preserving data packet filtering system model, revisit the general demanded objectives including confidentiality, integrity, source authentication, soundness, completeness and IP privacy-preserving.

• We propose a new notion of privacy-preserving data packet filtering, construct a privacy-preserving data packet filtering scheme and formally prove its semantic security against the chosen IP attack and the IP guessing attack.

• Applying the data packet filtering scheme as a building block, we present a basic data packet filtering protocol featured with source IP privacy-preserving and authentication, and analyze that the protocol has achieved the objectives we defined. The theoretic analysis and experimental results show that the proposed data packet filtering protocol is practical for the current network environment.

• An enhanced privacy-preserving data packet filtering scheme is proposed, where the data packets from the same organization or a district are filtered with only one piece of filtering policy.

Organization The remainder of the paper is organized as follows. In Sect. 2, we review some recent related work. Section 3 describes the system model of the privacy-preserving data packet filtering system and the required objectives. In Sect.  4 the notion of the privacy-preserving data packet filtering scheme and the threat model are defined. A privacy-preserving data packet filtering scheme is proposed and its security is formally proved in Sect. 5. The data packet filtering protocol featured with source IP privacy-preserving and authentication is proposed in Sect. 6. The protocol analysis, the functionality comparison and simulation evaluation are presented in Sect. 7. The enhanced data packet filtering scheme is proposed in Sect. 8. Finally, we conclude the paper in Sect. 9.

2 Related Work

Since the birth of the seminal BSD packet filter [3], the filtering system has become more and more important for protecting the networks, such as the traffic monitoring [4] and the intrusion detection [5]. Nowadays, both hardware and software based data packet filtering systems have been proposed to improve the performance of packet filtering. Hardware based mechanisms usually use parallel lookups to accelerate the filtering procedure. However, hardware based filtering system has its disadvantage. The hardware resources in the system, such as ternary content addressable memory (TCAM) devices, may limit the size of supported filter sets [17]. Software based systems which provide better scalability have drawn much more attention. However, the algorithm and data structure for storing the filter sets significantly affect the performance [18]. Most filtering systems take advantage of both hardware and software based mechanisms.

The recent research of the packet filtering systems are mainly on three aspects: (1) the high performance of the filtering system for filtering large volumes of data; (2) various functionalities of the filtering algorithm; (3) the design of filter algorithm for protecting the network against various attacks.

To improve the performance of the packet filtering system, Wu, Xie and Wang [6] proposed an alternative approach called “Swift” to improve the filtering efficiency, especially for dynamic filtering tasks. However, their system can neither protect the IP privacy nor resist the IP spoofing attack. Some new functionalities are considered in filtering systems, e.g. the fault-tolerance, the stability and the reliability of filtering, etc.. Huang, Tan and Lee [8] proposed a residual generator based on the Kalman filter to detect fault, and when a fault is detected, the fault-tolerant control mechanism is used to accommodate the failure. Li et al. [9] employed the binary Markov process to improve the stability of the unscented Kalman filter over unreliable communication channel states and gave the sufficient conditions for the peak covariance stability. He et al. [7] designed a novel network strong tracking filter to effectively deal with the problem of filtering a class of nonlinear NSs with multiple packet dropout rates. These systems are efficient and reliable. However, none of them can resist the IP spoofing and protect the source IP.

To resist IP spoofing attacks, Wang, Jin and Shin [12] proposed an easy-deploying filtering technique called Hop-Count Filtering to detect and discard spoofed IP packets. In their scheme, however, the soundness and source IP privacy-preserving are not satisfied. Antikainen, Aura and Sarela [10] recently pointed out DoS attacks against broad classes of Bloom-filter-based protocols, and showed that the Bloom-filter-based forwarding needed further improvements on security before deployment. However, their scheme also cannot resist IP spoofing and protect IP privacy. Liu et al. [11] proposed the mutual egress filtering to resist the spoofing attacks, which provides continuous deployment incentives. It satisfies soundness and completeness. However their scheme [11] cannot protect the source IP against the gateway. Wang and Sun [13] proposed an IP-traceback-based packet filtering scheme to solve the problem of DDoS attack. However, their system cannot protect the IP privacy and resist the IP spoofing.

From the above introduction, we find that there is no solution in protecting the privacy of the source IP address in the data packet filtering systems. A cryptographic primitive “searchable encryption” [16] might be a plausible technique. In a searchable encryption scheme, the keywords are encrypted into ciphertext and stored at the server, and a trapdoor of the keyword is generated to search the corresponding ciphertext. The server executes the search operation to test whether the ciphertext and the trapdoor contain the same keyword. However, since the keyword can be obtained by launching the keyword guessing attack by the server, searchable encryption is infeasible to achieve the source IP privacy protection against the filter (i.e. the server) in the packet filtering system.

In this paper, we provide a novel approach to solve the source IP protection problem in the packet filtering system.

3 System Model and Objectives

3.1 System Model

As shown in Fig. 2, a privacy-preserving data packet filtering system generally consists of five types of entities: the trusted authority, the sender host, the sender gateway, the recipient gateway and the recipient host.

Fig. 2

Privacy-preserving data packet filtering architecture

• Trusted authority The trusted authority serves as a trusted key generation center, which verifies the hosts’ and gateways’ IP addresses and generates the secret keys for the IP addresses.

• Sender host We define the IP address of the sender host, i.e. the source IP address, as SIP. The sender host sends his data packet to the recipient host through a tunnel between the sender gateway and the recipient gateway. These data packets will arrive at the recipient host only after being filtered and approved by the recipient gateway.

• Sender gateway We define the IP address of the sender gateway as SGIP. The sender gateway is a trusted outside gateway which stores the subnet number I of the sender host. The sender gateway and the recipient gateway share a secret key K by running Internet Key Exchange protocol previously. By using the secret key K, a secret tunnel is generated between the sender gateway and the recipient gateway. The sender gateway transmits the data packet from the sender host to the recipient gateway through this secret tunnel.

• Recipient gateway We define the IP address of the recipient gateway as RGIP. The recipient gateway stores a list of tuples [TN, SGIP], where TN is the tunnel number of the tunnel between a sender gateway with IP address SGIP and itself. The recipient gateway acts as a filter, which performs the filtering operation to the received data packets according to the filtering policy specified by the recipient host. Then the recipient gateway forwards the approved data packets to the recipient host and filters out the data packets from hosts whose source IP addresses are at risk.

• Recipient host We define the IP address of the recipient host, i.e. the destination IP address, as DIP. The recipient host in the system serves as a data receiver which specifies his filtering policy at the recipient gateway for filtering out the data packet from dangerous IP addresses and obtains his concerned data packets. Upon receiving a data packet, the recipient host authenticates its source IP address SIP. If the verification fails, the data packet will be discarded. Otherwise, the recipient host accepts the data packet and returns a response packet to the sender host. The connection between the recipient host and the recipient gateway is through a local intranet.

As shown in Fig. 3, the privacy-preserving data packet filtering system works as follows. Firstly, the recipient host records all the source IP addresses to be filtered. The hosts with these source IP addresses may be controlled by attackers or vulnerable to different attacks. Then, the recipient host specifies the filtering policy at the recipient gateway. The filtering policy is defined that if the source IP address SIP is one of the recorded IP addresses at risk, the data packet is dropped; otherwise, the data packet is accepted. The data packet from the sender host is transmitted to the recipient gateway through the secure tunnel between the sender gateway and the recipient gateway. When the data packets from different sender hosts arrive at the recipient gateway, it executes the filtering operation according to the specified filtering policy. If the data packet is accepted, the recipient gateway passes the data packet to the recipient host. Otherwise, it drops the data packet. Upon receiving the approved data packet, the recipient host verifies its source IP address. If the verification fails, the data packet will be discarded; Otherwise, it is accepted. Then the recipient host sends a response back to the sender host.

Fig. 3

Data packet filtering system

In order to resist IP tracing attacks, the privacy of the IP addresses in the data packet need to be preserved. Therefore, the source IP address should be encrypted. However, to support data packet filtering, the IP address can not be encrypted simply. There should be a mechanism to support data packet filtering with privacy-preserving. To resist IP spoofing attacks, the recipient host should be able to authenticate that the source IP address is a correct one. Therefore, to provide data packet filtering, IP address privacy-preserving and IP address authentication, we adopt the format of data packet that is similar to that in the tunnel mode of IPsec [19]. To achieve the security of the data packet transportation, the entire original IP data packet is encrypted by applying a symmetric encryption algorithm and becomes the data component of a new data packet. As shown in Fig. 4, the new IP data packet is of seven segments.

Fig. 4

IP data packet format

• New IP HDR The sender gateway IP address SGIP and the recipient gateway IP address RGIP are in this segment. They are in plaintext.

• Security HDR The data for IP address filtering and authentication is in this segment.

• IP HDR The sender host IP address SIP and the recipient host IP address DIP are in this segment. It is in ciphertext.

• TCP/UDP HDR The TCP or UDP header is in this segment, which is in ciphertext.

• IP Payload The content of the original data packet is in this segment, which is in ciphertext.

• Original Trailer The data integrity check code of the original data packet is in this segment, which is in ciphertext.

• New Trailer The data integrity check code of the new data packet is in this segment, which is in plaintext.

3.2 Objectives

According to the aforementioned system features and requirements, a privacy-preserving data packet filtering system should satisfy the following properties.

• (1) Confidentiality The content of the original IP data packet will not be leaked to the outsiders.

• (2) Integrity Any modification of the IP data packet can be detected.

• (3) Source authentication The source IP in the legal data packet can be authenticated. Any faked source IP address in the data packet can be detected in the data packet filtering system.

• (4) Soundness Accordingly to the filtering policy, any illegal data packets should be filtered out and dropped by the recipient gateway in the packet filtering system. The gateway cannot accept any illegal data packet.

• (5) Completeness Accordingly to the filtering policy, the recipient gateway should accept all the legal data packets, i.e. any legal data packet should not be dropped.

• (6) IP Privacy-preserving The source IP address SIP should be secretly preserved against both outsider attackers and the recipient gateway during the whole filtering process, i.e. the filtering policy in the packet filtering system or the data packets transmitted will not leak any information of the source IP address SIP.

4 The Privacy-Preserving Data Packet Filtering Scheme and its Security Model

In this section, we define the notion of the privacy-preserving data packet filtering scheme and its security model which covers the semantic security against the chosen IP attack and IP guessing attack.

4.1 The Privacy-Preserving Data Packet Filtering Scheme

Definition 1

(Privacy-Preserving Data Packet Filtering Scheme) The privacy-preserving data packet filtering scheme consists of the following five algorithms.

${\mathsf {Setup}}(1^{\lambda }).$ Taking as input the security parameter $1^{\lambda }$, it outputs the public parameters ${{\mathsf{Params}}}$ and the master secret key ${\mathsf{MSK}}$.

${\mathsf {KeyGen}}(\mathsf{MSK},IP).$ Taking as input the master secret key ${\mathsf{MSK}}$ and the IP address IP, it outputs the private key $d_{IP}$ for the IP address IP.

${\mathsf {Token}}({\mathsf{Params}},d_{DIP},SIP).$ Taking as input the public parameters ${{\mathsf{Params}}}$, the private key $d_{DIP}$ of the destination IP address DIP, and the specified source IP address SIP, it outputs a token Token.

${\mathsf {Index}}({{\mathsf{Params}}},d_{SIP},DIP).$ Taking as input the public parameters ${{\mathsf{Params}}}$, the private key $d_{SIP}$ of the source IP address SIP, and the destination IP address DIP, it outputs an index Index.

${\mathsf {Filter}} (Index,Token).$ Taking as input an index Index for the source IP address SIP and the destination IP address DIP, and a token Token for the source IP address $SIP'$ and the destination IP address $DIP'$, it outputs 1 if and only if $SIP=SIP'$ and $DIP=DIP'$; otherwise, it outputs 0.

Definition 2

(Correctness) The correctness of the privacy-preserving data packet filtering scheme is defined as follows. Assuming the algorithm ${\mathsf {Setup}}(1^{\lambda })$ is to generate the public ${{\mathsf{Params}}}$ and the secret master key ${\mathsf{MSK}}$, the algorithm ${\mathsf {KeyGen}}(\mathsf{MSK},IP)$ to generate the private key $d_{IP}$ for the IP address IP, the algorithm ${\mathsf {Token}}({\mathsf{Params}},d_{DIP},SIP)$ to produce the token Token, and the algorithm ${\mathsf {Index}}({\mathsf{Params}},d_{SIP'},DIP')$ to produce the Index, the algorithm ${\mathsf {Filter}}(Index,Token)$ outputs 1 if and only if $SIP=SIP'$ and $DIP=DIP'$.

4.2 Security Model

We define the security model of the privacy-preserving data packet filtering scheme, where the security against the chosen IP attack and the IP guessing attack are covered. Since compared with the outsider attackers, the recipient gateway, i.e. the filter, is more powerful in attacking the packet filtering scheme, in our adversary model we only define the recipient gateway as the adversary.

Game 1

(Chosen IP attack) This game defines the semantic security against the chosen IP attack, where the adversary is able to query for some private keys and some tokens with some restrictions. The adversary cannot distinguish an index $Index_0$ for the target source IP address $SIP_{0}$ and a designated destination IP address DIP from an index $Index_1$ for another target source IP address $SIP_{1}$ and the same designated destination IP address DIP.

Setup The challenger ${\mathcal {C}}$ runs the ${\mathsf {Setup}}$ algorithm and sends the public parameters ${{\mathsf{Params}}}$ to ${\mathcal {A}}$. The adversary ${\mathcal {A}}$ outputs a challenge source IP address $SIP_b$ and destination IP address DIP.

Phase 1 ${\mathcal {A}}$ performs a polynomially bounded number of queries.

Private key Query $\mathcal {A}$ issues an IP address $IP_j$ to $\mathcal {C}$, and $\mathcal {C}$ returns the private key $d_{IP_j}$ to $\mathcal {A}$ by running ${\mathsf {KeyGen}}$ algorithm.

Token Query $\mathcal {A}$ issues a token query of the source IP address $SIP_{j}$ and the destination IP address DIP to $\mathcal {C}$. $\mathcal {C}$ returns the token $Token_j$ for $SIP_{j}$ and DIP to $\mathcal {A}$ by running the ${\mathsf {Token}}$ algorithm.

Challenge Once $\mathcal {A}$ decides Phase 1 is over, $\mathcal {A}$ chooses two source IP addresses $SIP_{0}, SIP_{1}$ and a destination IP address DIP on which it wants to be challenged. $\mathcal {A}$ did not previously ask for the private key for $SIP_{0}$ or $SIP_{1}$, and did not issue token query for $(SIP_{0},DIP)$ or $(SIP_{1},DIP)$. $\mathcal {C}$ takes a random bit $b\in \{0, 1\}$ and returns the challenge index $Index^{*}_{b}$ of $(SIP_{b},DIP)$ to $\mathcal {A}$.

Phase 2 $\mathcal {A}$ continues to ask for the private key query for $IP_{j}\ne SIP_{0},SIP_{1}$, and the token query for $(SIP_{j},DIP)$, where $SIP_{j}\ne SIP_{0}$ or $SIP_{1}$. $\mathcal {C}$ responds as in Phase 1.

Guess $\mathcal {A}$ outputs a bit $b'\in \{0,1\}$ as his guess of b and wins the game if $b'= b$.

We define that advantage of the adversary $\mathcal {A}$ in breaking the semantic security against chosen IP attack as

$$\begin{aligned} Adv_{CIPA}=|\Pr [b'=b]-{1}/{2}|. \end{aligned}$$

Game 2

(IP guessing attack) This game defines the semantic security against the IP guessing attack, where the adversary is able to query for some private keys and some indexes with some restrictions. The adversary cannot distinguish a token $Token_0$ for a specified the source IP address $SIP_{0}$ and a designated destination IP address DIP from a token $Token_1$ for another source IP address $SIP_{1}$ and the same destination IP address DIP for which he is not permitted to obtain the associated index.

Setup $\mathcal {C}$ runs the ${\mathsf {Setup}}$ algorithm and sends the system public parameters ${\mathsf{Params}}$ to $\mathcal {A}$. The adversary $\mathcal {A}$ outputs a challenge source IP address $SIP_b$ and destination IP address DIP.

Phase 1 $\mathcal {A}$ performs a polynomially bounded number of queries.

Private key Query $\mathcal {A}$ issues an IP address $IP_{j}$ to $\mathcal {C}$. $\mathcal {C}$ runs the ${\mathsf {KeyGen}}$ algorithm and returns the private key $d_{IP_{j}}$ to $\mathcal {A}$.

Index Query $\mathcal {A}$ issues the source IP address $SIP_{j}$ and the destination IP address DIP to $\mathcal {C}$. $\mathcal {C}$ returns the index $Index_j$ for $(SIP_{j},DIP)$ to $\mathcal {A}$ by running the ${\mathsf {Index}}$ algorithm.

Challenge $\mathcal {A}$ outputs two source IP addresses $SIP_{0}, SIP_{1}$ and a destination IP address DIP, on which it wants to be challenged. $\mathcal {A}$ did not previously ask for the private key for $SIP_{0}$ or $SIP_{1}$, and did not issue the index query for $(SIP_{0},DIP)$ or $(SIP_{1},DIP)$. $\mathcal {C}$ takes a random bit $b\in \{0, 1\}$ and returns the token $Token^{*}_{b}$ of $(SIP_{b},DIP)$ to $\mathcal {A}$.

Phase 2 $\mathcal {A}$ continues to query the private key for $IP_{j}\ne SIP_{0},SIP_{1}$, and the index for $(SIP_{j},DIP)$, where $SIP_{j}\ne SIP_{0}$ or $SIP_{1}$. $\mathcal {C}$ responds as in Phase 1.

Guess $\mathcal {A}$ outputs a bit $b'\in \{0,1\}$ as his guess of b, and wins the game if $b'= b$.

We define that advantage of the adversary $\mathcal {A}$ in breaking the semantic security against IP guessing attack as

$$\begin{aligned} Adv_{IPGA}=|\Pr [b'=b]-{1}/{2}|. \end{aligned}$$

5 Proposed Privacy-Preserving Data Packet Filtering Scheme

We construct a privacy-preserving data packet filtering scheme, where the recipient gateway can efficiently filter the specified data packet without IP privacy exposure. The hard problem assumption and its intractability analysis are given. The security of the proposed privacy-preserving data packet filtering scheme is formally proved under the defined threat model.

We first briefly review the bilinear pairing [20]. Assume that two multiplicative cyclic groups $\mathbb {G}$ and $\mathbb {G}_{T}$ are of the same prime order p, and g, h are two generators of $\mathbb {G}$. A bilinear map $e: \mathbb {G}\times \mathbb {G}\rightarrow \mathbb {G}_{T}$ has the properties: (1) bilinearity: for any $g,h\in \mathbb {G}$ and $a,b\in \mathbb {Z}^{*}_{p}$, $e(g^{a},h^{b})=e(g,h)^{ab}$; (2) non-degeneracy: $e(g,g)\ne 1$.

5.1 Construction

${\mathsf {Setup}}(1^{\lambda }).$ Taking as input the security parameter $1^{\lambda }$, a bilinear map group system $\mathcal {B}=(p,\mathbb {G},\mathbb {G}_{T},e)$ is constructed such that $|p|=\lambda$. The generators $g,h\in \mathbb {G}$ and a secret value $\alpha \in \mathbb {Z}^{*}_{p}$ are randomly selected. It chooses the cryptographic hash function $H:\{0,1\}^*\rightarrow \mathbb {Z}^{*}_{p}$, and defines the master secret key as $\mathsf{MSK}=(g,\alpha )$ and the public parameters as ${\mathsf{Params}}=(h,h^{\alpha },h^{\alpha ^{2}},h^{\alpha ^{3}},h^{\alpha ^{4}},H(\cdot ),\mathcal {B})$.

${\mathsf {KeyGen}}(IP,\mathsf{MSK}).$ Taking as input the IP address $IP=[I_1.I_2.I_3.I_4]$ and the master secret key $\mathsf{MSK}$, it outputs the private key $d_{IP}$ for IP as

$$\begin{aligned} i_1&= {} H(I_1),\\ i_2&= {} H(I_1\Vert I_2),\\ i_3&= {} H(I_1\Vert I_2\Vert I_3),\\ i_4&= {} H(I_1\Vert I_2\Vert I_3\Vert I_4),\\ d_{IP}&= {} g^{\frac{1}{\prod _{t=1}^4(\alpha +i_t)}}. \end{aligned}$$

Here, “$\Vert$” denotes a bitwise concatenation.

${\mathsf {Token}}({\mathsf{Params}},d_{DIP},SIP).$ Taking as input the public parameters ${\mathsf{Params}}$, the private key $d_{DIP}=g^{\frac{1}{\prod _{t=1}^4(\alpha +i_{D_t})}}$ of the destination IP address $DIP=I_{D_1}.I_{D_2}.I_{D_3}.I_{D_4}$, and the source IP address $SIP=I_{S_1}.I_{S_2}.I_{S_3}.I_{S_4}$, it randomly chooses $s\in \mathbb {Z}^{*}_{p}$, and computes the token $Token=(T_1,T_2)$ as

$$\begin{aligned} i_{S_1}&= x {} H(I_{S_1}),\\ i_{S_2}&= {} H(I_{S_1}\Vert I_{S_2}),\\ i_{S_3}&= {} H(I_{S_1}\Vert I_{S_2}\Vert I_{S_3}),\\ i_{S_4}&= {} H(I_{S_1}\Vert I_{S_2}\Vert I_{S_3}\Vert I_{S_4}),\\ T_1&= {} h^{s\prod _{t=1}^4(\alpha +i_{S_t})},\\ T_2&= {} (d_{DIP})^s=g^{\frac{s}{\prod _{t=1}^4(\alpha +i_{D_t})}}. \end{aligned}$$

${\mathsf {Index}}({\mathsf{Params}},d_{SIP},DIP).$ Taking as input the public parameters ${\mathsf{Params}}$, the private key $d_{SIP}=g^{\frac{1}{\prod _{t=1}^4(\alpha +i_{S_t})}}$ of the source IP address $SIP=I_{S_1}.I_{S_2}.I_{S_3}.$ $I_{S_4}$, and the destination address $DIP=I_{D_1}.I_{D_2}.I_{D_3}.I_{D_4}$, it randomly picks $r\in \mathbb {Z}^{*}_{p}$, and computes the index $Index=(C_1,C_2)$ as

$$\begin{aligned} i_{D_1}&= {} H(I_{D_1}),\\ i_{D_2}&= {} H(I_{D_1}\Vert I_{D_2}),\\ i_{D_3}&= {} H(I_{D_1}\Vert I_{D_2}\Vert I_{D_3}),\\ i_{D_4}&= {} H(I_{D_1}\Vert I_{D_2}\Vert I_{D_3}\Vert I_{D_4}),\\ C_1&= {} h^{r\prod _{t=1}^4(\alpha +i_{D_t})},\\ C_2&= {} (d_{SIP})^s=g^{\frac{r}{\prod _{t=1}^4(\alpha +i_{S_t})}}. \end{aligned}$$

${\mathsf {Filter}}(Index,Token).$ Taking as input an index $Index=(C_1,C_2)$, and a token $Token=(T_1,T_2)$, it outputs 1 if the equation

$$\begin{aligned} e\left( C_{1},T_{2}\right) \mathop {=}\limits ^{?}e\left( C_{2},T_{1}\right) \end{aligned}$$

holds; otherwise, it outputs 0.

5.2 Correctness

Given the index $Index=(C_1,C_2)$ of (SIP, DIP) and the token $Token=(T_1,T_2)$ of (SIP, DIP), the correctness can be verified as follows.

$$\begin{aligned}&e(C_{2},T_{1})\\&\quad = e(g^{\frac{r}{\prod _{t=1}^4(\alpha +i_{S_t})}},h^{s \prod _{t=1}^4(\alpha +i_{S_t})}) \\&\quad = e(g,h)^{rs}\\&\quad = e(h^{r\prod _{t=1}^4(\alpha +i_{D_t})},g^{\frac{s}{\prod _{t=1}^4(\alpha +i_{D_t})}})\\&\quad = e(C_{1},T_{2}). \end{aligned}$$

Therefore, we find that when the index and token are generated from the same source and destination addresses, the equation $e\left( C_{1},T_{2}\right) =e\left( C_{2},T_{1}\right)$ holds. Then, the filter algorithm ${\mathsf {Filter}}$ outputs 1. Thus, the correctness holds.

5.3 Hard Problem Assumption

As the analysis made in [21], our security proof can be reduced to the general Diffie-Hellman exponent problems based on [20]. Boneh et al. presented a series of assumptions which appeared with new pairing-based schemes. Even if group systems equipped with bilinear maps are far from being generic, an intractability result in this framework is a first step for getting some confidence in the actual intractability. In our case, we assume the intractability of the (n, 2)-MSE-DDH Problem.

Definition 3

((n,2)-MSE-DDH Problem) Let n be an integer and $(p,\mathbb {G},\mathbb {G}_{T},e)$ be a bilinear map group system. Let $g_{0}, h_{0}$ be the generators of $\mathbb {G}$. Given several sequences of group elements,

$$\begin{aligned} \begin{array}{lccl} g_0^{f_1}, &{} \cdots , &{} g_0^{\alpha ^{4n-1} f_1}, &{} \\ g_0^{\beta f_1}, &{} \cdots , &{} g_0^{\beta \alpha ^{4n-1} f_1},&{} g_0^{\gamma f_3},\\ h_0, &{} h_0^{\alpha },h_0^{\alpha ^2},h_0^{\alpha ^3},&{} h_0^{\alpha ^{4}},&{}h_0^{\beta f_2} \end{array} \end{aligned}$$

and $Z\in \mathbb {G}$, where $f_1$, $f_2$, $f_3$ are three random coprime polynomials of $\alpha$ whose orders are $\text{ deg }~f_1=\text{ deg }~f_2=4$ and $\text{ deg }~f_3=4n$, respectively, distinguish whether Z equals to $h_0^{\gamma f_2}$ or some random element in $\mathbb {G}$.

Intractability of (n,2)-MSE-DDH Problem Since $g_{0}$ and $h_{0}$ are two different generators of group $\mathbb {G}$, we pose $h_{0}=g^{\kappa }_{0}$. The above problem can be reformulated as the problem to show that P is independent of (D, E), where D, E, P are as follows,

$$\begin{aligned} D&= {} \left( \begin{array}{lccl} f_{1}, &{} \cdots , &{} \alpha ^{4n-1} f_{1}, &{} \\ \beta f_{1}, &{} \cdots , &{} \beta \alpha ^{4n-1} f_{1},&{} \gamma f_{3},\\ \kappa , &{} \kappa \alpha ,\kappa \alpha ^{2},\kappa \alpha ^{3},&{} \kappa \alpha ^{4},&{}\kappa \beta f_{2} \end{array}\right) \\ E&= {} \begin{array}{r} 1,\\ \end{array}\\ P&= {} \kappa \gamma f_{2}. \end{aligned}$$

To show that P is independent of (D, E), we will show that no coefficients $\{x_{i,j}\},y_k,z_1$ exist such that

$$\begin{aligned} \varSigma x_{i,j} d_id_j=\varSigma y_kd_kp_{1}+z_1, \end{aligned}$$

(1)

where the polynomials $d_{i}$, $d_j$, $d_k$ are chosen from D, and $p_{1}$ is from P. The coefficients of all possible products of any two polynomials from D, P are $\kappa \gamma , \kappa \gamma \beta , \kappa ^{2}\gamma , \kappa \gamma ^{2}, \kappa ^{2}\beta \gamma$, while the coefficients of all possible products of any two polynomials from D are $\beta , \kappa ,\gamma , \kappa \beta , \beta \gamma ,\kappa \beta ^{2}, \kappa \gamma ,\kappa ^{2}\beta , \kappa \gamma \beta$. Hence, only the products of two polynomials associated with $\kappa \gamma$ and $\kappa \gamma \beta$ might satisfy the equation (1). We list all the polynomials with coefficients $\kappa \gamma$ and $\kappa \gamma \beta$ which are the possible products of two polynomials from D, P in X, and list all the polynomials with coefficients $\kappa \gamma$ and $\kappa \gamma \beta$ which are the possible products of two polynomials from D in Y as follows.

$$\begin{aligned}X & = \left( \begin{array}{ccc} \kappa \gamma f_1f_2, &{} \cdots , &{} \kappa \gamma \alpha ^{4n-1} f_1f_2,\\ \kappa \gamma \beta f_1f_2, &{} \cdots , &{}\kappa \gamma \beta \alpha ^{4n-1} f_1f_2,\\ \end{array}\right) \\ \\Y &=\left( \begin{array}{ccc} \kappa \gamma f_3,&{} \kappa \gamma \alpha ^2f_3,\kappa \gamma \alpha ^3f_3, &{} \kappa \gamma \alpha ^4f_3,\\ \kappa \gamma \beta f_2f_3,&{} &{} .\\ \end{array}\right) \end{aligned}$$

We prove that there is no linear combination among the polynomials from X and Y.

• Any such linear combination associated with $\kappa \gamma$ can be written as

  $$\begin{aligned} \kappa \gamma f_1f_2A=\kappa \gamma f_3B, \end{aligned}$$

  where A, B are polynomials, $\text{ deg }\ A\leqslant 4n-1$, $\text{ deg }\ B\leqslant 4$. We can simplify the equation as $f_1f_2A= f_3B$. Since $f_1,f_2,f_3$ are coprime, we have $f_3|A$. Since $\text{ deg }\ A\leqslant 4n-1$ and $\text{ deg }\ f_3=4n$, it implies $A=0$.

• Then we consider the items associated with $\kappa \gamma \beta$. Any such linear combination associated with $\kappa \gamma \beta$ can be written as

  $$\begin{aligned} \kappa \gamma \beta f_1f_2A'=\kappa \gamma \beta f_2f_3B', \end{aligned}$$

  where $A'$ is a polynomial and $B'$ is constant, $\text{ deg }\ A'\leqslant 4n-1$. We can simplify the equation as $f_1A'= f_3B'$. By the assumption, $f_1,f_2$ are coprime, we have $f_3|A'$. Since $\text{ deg }\ A'\leqslant 4n-1$ and $\text{ deg }\ f_3=4n$, it implies $A'=0$.

Hence, there are no coefficients $\{x_{i,j}\},y_k,z_1$ such that the equation $\varSigma x_{i,j} d_id_j$ $=\varSigma y_k d_kp_1+z_{1}$ holds.

From the above analysis we find that given the following group elements,

$$\begin{aligned} \begin{array}{lccl} g_0^{f_1}, &{} \cdots , &{} g_0^{\alpha ^{4n-1} f_1}, &{} \\ g_0^{\beta f_1}, &{} \cdots , &{} g_0^{\beta \alpha ^{4n-1} f_1},&{} g_0^{\gamma f_3},\\ h_0, &{} h_0^{\alpha },h_0^{\alpha ^2},h_0^{\alpha ^3},&{} h_0^{\alpha ^{4}},&{}h_0^{\beta f_2} \end{array} \end{aligned}$$

and $Z\in \mathbb {G}$, the probability of distinguishing whether Z equals to $h_0^{\gamma f_2}$ or some random element in $\mathbb {G}$ is negligible.

Therefore, the (n, 2)-MSE-DDH Problem is intractable.

5.4 Security Analysis

Theorem 1

The proposed privacy-preserving data packet filtering scheme is semantically secure against chosen IP attack in Game 1 if (n, 2)-MSE-DDH Problem is intractable for any polynomial-time algorithm.

Proof

Suppose there exists a polynomial-time adversary $\mathcal {A}$ in Game 1, who can attack our scheme with advantage $\epsilon$, we build a simulator $\mathcal {B}$, who simulates the challenger and has advantage $\epsilon /eq_{T}$ in solving the (n, 2)-MSE-DDH Problem. $\mathcal {B}$’s running time is approximately the same as $\mathcal {A}$’s.

Setup The simulator $\mathcal {B}$ is given a bilinear group parameters $(p,\mathbb {G},\mathbb {G}_{T},e(\cdot ,\cdot ))$ and the (n, 2)-MSE-DDH instances as input,

$$\begin{aligned} \begin{array}{lccl} g_{0}^{f_{1}},&{} \cdots , &{} g_{0}^{\alpha ^{4n-1} f_{1}},&{} \\ g_{0}^{\beta f_{1}}, &{} \cdots , &{} g_{0}^{\beta \alpha ^{4n-1} f_{1}},&{} g_{0}^{\gamma f_{3}},\\ h_{0}, &{} h_{0}^{\alpha },h_{0}^{\alpha ^{2}},h_{0}^{\alpha ^{3}},&{} h_{0}^{\alpha ^{4}},&{} h_{0}^{\beta f_{2}}. \end{array} \end{aligned}$$

We also have co-prime polynomials $f_{1},f_{2},f_{3}$ of $\alpha$, of respective orders 4, 4, 4n, with their pairwise distinct roots. $\mathcal {B}$ is further given $Z\in \mathbb {G}$, and uses $\mathcal {A}$ as a subroutine to distinguish $Z=h_{0}^{\gamma f_{2}}$ or a random element in $\mathbb {G}$. If $Z=h_{0}^{\gamma f_{2}}$, $\mathcal {B}$ outputs 1; Otherwise, Z is random, $\mathcal {B}$ outputs 0. The simulator randomly chooses $\{a_1^{*},a_2^{*},a_3^{*},a_4^{*}\},\{a_{j_1},a_{j_2},a_{j_3},a_{j_4}\},\{n_1,n_2,n_3,n_4\}\in \{\mathbb {Z}^{*}_{p}\}^4$ and implicitly sets

$$\begin{aligned} f_{1}&= {} \prod \limits _{t=1}^4(\alpha +a_t^{*}),\\ f_{2}&= {} \prod \limits _{t=1}^4(\alpha +n_t),\\ f_{3}&= {} \prod \limits _{j=1}^{n}(\prod \limits _{t=1}^4(\alpha +a_{j_t})).\\ \end{aligned}$$

For $j\in [1,n]$, we set $f_{3_j}=\dfrac{f_3}{\prod \limits _{t=1}^4(\alpha +a_{j_t})}$.

To generate the system parameters, the simulator $\mathcal {B}$ sets $g=g^{f_{1}f_{3}}_{0},h=h_{0}$ and the public parameters ${\mathsf{Params}}=(h_{0},h_{0}^{\alpha },h_{0}^{\alpha ^{2}},h_{0}^{\alpha ^{3}},h_{0}^{\alpha ^{4}})$. Then $\mathcal {B}$ sends ${\mathsf{Params}}$ to $\mathcal {A}$. Also, $\mathcal {B}$ specifies the target source IP address $SIP_{\theta }=[I_{S_{\theta _1}}.I_{S_{\theta _2}}.$ $I_{S_{\theta _3}}.I_{S_{\theta _4}}]$ and the destination IP address $DIP=[I_{D_1}.I_{D_2}.I_{D_3}.I_{D_4}]$.

Hash Query $\mathcal {B}$ maintains a hash list $L_1$, whose entry is $(IP_{j},[x_{j_1},x_{j_2},x_{j_3},x_{j_4}])$, where $IP_{j}=[I_{j_1}.I_{j_2}.I_{j_3}.I_{j_4}]$. The hash list is initially set empty.

$H(IP_j)$-query Upon receiving a hash query for $IP_{j}$, if $IP_{j}$ is in the list $L_1$, $\mathcal {B}$ returns the corresponding tuple $[x_{j_1},x_{j_2},x_{j_3},x_{j_4}]$ to $\mathcal {A}$. Otherwise, $\mathcal {B}$ sets the hash values as follows.

$$\begin{aligned} H(I_{j_1})=x_{j_1}&= {} \left\{ \begin{array}{ll} a_1^{*}, &{} \text{ if }\, I_{j_1}=I_{S_{\theta _1}},\\ n_1, &{} \quad \text{ if }\, I_{j_1}=I_{D_1},\\ a_{j_1}, &\quad otherwise.\\ \end{array} \right. \\ H(I_{j_1}\parallel I_{j_2})=x_{j_2}&= {} \left\{ \begin{array}{ll} a_2^{*}, &{} \text{ if }\, I_{j_t}=I_{S_{\theta _1}}, \quad (t=1,2),\\ n_2, &{} \text{ if }\, I_{j_t}=I_{D_t},\quad (t=1,2),\\ a_{j_2}, & \quad otherwise.\\ \end{array} \right. \\ H(I_{j_1}\parallel I_{j_2}\parallel I_{j_3})&= {} x_{j_3} =\left\{ \begin{array}{ll} a_3^{*}, &{} \text{ if }\, I_{j_t}=I_{S_{\theta _t}}, \quad (t=1,2,3),\\ n_3, &{} \text{ if }\, I_{j_t}=I_{D_t}, \quad (t=1,2,3),\\ a_{j_3}, &\quad otherwise. \\ \end{array} \right. \\ H(I_{j_1}\parallel \cdots \parallel I_{j_4})&= {} x_{j_4} =\left\{ \begin{array}{ll} a_4^{*}, &{} \text{ if }\, I_{j_t}=I_{S_{\theta _t}}, \quad (t=1,\ldots ,4),\\ n_4, &{} \quad \text{ if }\, I_{j_t}=I_{D_t},\quad (t=1,\ldots ,4),\\ a_{j_4}, &\quad otherwise. \\ \end{array} \right. \end{aligned}$$

Then $\mathcal {B}$ adds $(IP_{j},[x_{j_1},x_{j_2},x_{j_3},x_{j_4}])$ to the list $L_1$ and returns $[x_{j_1},x_{j_2},x_{j_3},x_{j_4}]$ to $\mathcal {A}$.

Phase 1 The adversary can issue the private key query and token query as follows.

Private Key Query $\mathcal {A}$ asks for the private key query for $IP_{j}=[I_{j_1}.I_{j_2}.I_{j_3}.I_{j_4}]$, where $IP_{j}\ne SIP_{\theta }$ or DIP. Let $(IP_{j},[a_{j_1},a_{j_2},a_{j_3},a_{j_4}])$ be the corresponding tuple in the $L_1$ list. $\mathcal {B}$ responds $\mathcal {A}$ with the private key

$$\begin{aligned} d_{IP_{j}}&= {} g^{\frac{1}{(\alpha +a_{j_1})(\alpha +a_{j_2})(\alpha +a_{j_3})(\alpha +a_{j_4})}}\\&= {} g_0^{\frac{f_{1}f_3}{(\alpha +a_{j_1})(\alpha +a_{j_2})(\alpha +a_{j_3})(\alpha +a_{j_4})}}\\&= {} g_0^{f_1f_{3_j}}, \end{aligned}$$

where $g_0^{f_{1}f_{3_j}}$ can be computed from $g_0^{f_1},\ldots , g_0^{\alpha ^{4n-1} f_{1}}$ in (n, 2)-MSE-DDH instances.

Token Query $\mathcal {A}$ asks for the token query for $(SIP_{j},DIP)$. $\mathcal {B}$ runs the ${\mathsf {Token}}$ algorithm and responds as follows.

• If $SIP_{j}=SIP_{\theta }$, outputs failure and aborts the game.

• Otherwise, let $(SIP_{j},[a_{j_1},a_{j_2},a_{j_3},a_{j_4}])$ and (DIP, $[n_{1}, n_{2},n_{3},n_{4}])$ be the corresponding tuples in $L_1$ list. $\mathcal {B}$ randomly chooses $s'\in {\mathbb Z}^{*}_{p}$ and computes the token $Token=(T_1,T_2)$ as follows

  $$\begin{aligned} T_{1}=h_0^{s'\beta f_{2}},\quad T_{2}=g_0^{s'\beta f_{3_j}f_{1}}, \end{aligned}$$

  where $T_1$, $T_2$ can be computed from elements $h_0^{\beta f_{2}}$, $g_0^{\beta f_{1}}, \ldots , g_0^{\beta \alpha ^{4n-1} f_{1}}$ in (n, 2)-MSE-DDH instances. One can verify it by implicitly setting

  $$\begin{aligned} s=\frac{s'\beta f_2}{(\alpha +a_{j_1})(\alpha +a_{j_2})(\alpha +a_{j_3})(\alpha +a_{j_4})}, \end{aligned}$$

  and then

  $$\begin{aligned} T_{1}&= {} h^{s(\alpha +a_{j_1})(\alpha +a_{j_2})(\alpha +a_{j_3})(\alpha +a_{j_4})}\\&= {} h_0^{s(\alpha +a_{j_1})(\alpha +a_{j_2})(\alpha +a_{j_3})(\alpha +a_{j_4})}\\&= {} h_0^{\frac{s'\beta f_2(\alpha +a_{j_1})(\alpha +a_{j_2})(\alpha +a_{j_3})(\alpha +a_{j_4})}{(\alpha +a_{j_1})(\alpha +a_{j_2})(\alpha +a_{j_3})(\alpha +a_{j_4})}}\\&= {} h_0^{s'\beta f_{2}},\\ T_{2}&= {} g^{\frac{s}{(\alpha +n_{1})(\alpha +n_{2})(\alpha +n_{3})(\alpha +n_{4})}}\\&= {} g_0^{\frac{sf_{1}f_{3}}{(\alpha +n_{1})(\alpha +n_{2})(\alpha +n_{3})(\alpha +n_{4})}}\\&= {} g_0^{\frac{s'\beta f_{2}f_{1}f_{3}}{(\alpha +a_{j_1})(\alpha +a_{j_2})(\alpha +a_{j_3})(\alpha +a_{j_4})f_{2}}}\\&= {} g_0^{s'\beta f_{3_j}f_{1}}.\\ \end{aligned}$$

Challenge $\mathcal {A}$ outputs a pair of source IP addresses $SIP_{0}$ and $SIP_{1}$ and a designated destination IP address DIP that it wishes to be challenged and sends $SIP_{0}$, $SIP_{1}$ and DIP to $\mathcal {B}$. $\mathcal {A}$ did not previously ask for the private key query for $SIP_{0}$, $SIP_{1}$ or DIP, and token query for $(SIP_0,DIP)$ or $(SIP_1,DIP)$. $\mathcal {B}$ responds as follows.

• If $SIP_{\theta }\notin \{SIP_{0},SIP_{1}\}$, $\mathcal {B}$ outputs failure and aborts the game.

• Otherwise, $\mathcal {B}$ randomly picks $SIP_{\theta }$ from $\{SIP_{0},SIP_{1}\}$. Let $(SIP_{\theta },[a_1^*,a_2^*,$ $a_3^*,a_4^*])$ and $(DIP,[n_{1},n_{2},n_{3},n_{4}])$ be the corresponding tuples in the $L_{1}$ list, where $SIP_{\theta }=I_{S_{\theta _1}}.I_{S_{\theta _2}}.I_{S_{\theta _3}}.I_{S_{\theta _4}}$, $a_1^*=H(I_{S_{\theta _1}})$, $a_2^*=H(I_{S_{\theta _1}}\parallel I_{S_{\theta _2}})$, $a_3^*=H(I_{S_{\theta _1}}\parallel I_{S_{\theta _2}}\parallel I_{S_{\theta _3}})$, $a_4^*=H(I_{S_{\theta _1}}\parallel \cdots \parallel I_{S_{\theta _4}})$, and $DIP=I_{D_{1}}.I_{D_{2}}.I_{D_{3}}.I_{D_{4}}$, $n_{1}=H(I_{D_{1}})$, $n_{2}=H(I_{D_{1}}\parallel I_{D_{2}})$, $n_{3}=H(I_{D_{1}}\parallel I_{D_{2}}\parallel I_{D_{3}})$, $n_{4}=H(I_{D_{1}}\parallel \cdots \parallel I_{D_{4}})$. Then $\mathcal {B}$ randomly chooses $r'\in {\mathbb Z}^{*}_{p}$ and responds $\mathcal {A}$ with the challenge index $Index^{*}=(C_1^*,C_2^*)$ as follows,

  $$\begin{aligned} C_1^*=g_0^{r'\gamma f_3},\quad C_2^*=Z^{r'}, \end{aligned}$$

  where $C_1^*$ can be computed from the element $g_0^{\gamma f_3}$ in (n, 2)-MSE-DDH instances. If $Z=h_0^{\gamma f_2}$, one can verify it by implicitly setting $r=r'\gamma$ as

  $$\begin{aligned} C_1^*&= g^{\frac{r}{(\alpha +a_1^*)(\alpha +a_2^*)(\alpha +a_3^*)(\alpha +a_4^*)}}\\ &= g_0^{\frac{rf_1f_3}{(\alpha +a_1^*)(\alpha +a_2^*)(\alpha +a_3^*)(\alpha +a_4^*)}}\\ =& g_0^{\frac{r'\gamma f_1f_3}{f_{1}}}\\ &= (g_0^{\gamma f_3})^{r'},\\ C_2^*&= {} h^{r(\alpha +n_{1})(\alpha +n_{2})(\alpha +n_{3})(\alpha +n_{4})}\\&= {} h_0^{r'\gamma (\alpha +n_{1})(\alpha +n_{2})(\alpha +n_{3})(\alpha +n_{4})}\\&= {} (h_0^{\gamma f_{2}})^{r'}\\ &= {} Z^{r'}.\\ \end{aligned}$$

  If Z is a random element in $\mathbb {G}$, the challenge index $Index^{*}$ will be random from the $\mathcal {A}$’s view and $Index^{*}$ contains no information about $SIP_{\theta }$.

Phase 2 $\mathcal {A}$ continues to issue the private key query for $IP_{j}\ne SIP_{0},SIP_{1},DIP$, and token query for $(SIP_j,DIP)\ne (SIP_0,DIP)$ or $(SIP_1,DIP)$ . $\mathcal {B}$ responds as in Phase 1.

Guess $\mathcal {A}$ outputs its guess $\theta '$. $\mathcal {B}$ outputs 1 if $\theta '=\theta$, otherwise outputs 0.

As we see, if Z is an (n, 2)-MSE-DDH value, $Z=h_0^{\gamma f_{2}}$, the challenge index is a perfectly legitimate index. It is clear in this case that the response from $\mathcal {B}$ in the Challenge phase has the right form, since $g=g_0^{f_{1}f_{3}},h=h_{0}$, we have

$$\begin{aligned}&g_0^{r'\gamma f_{3}}=g^{\frac{r}{(\alpha +a_1^*)(\alpha +a_2^*)(\alpha +a_3^*)(\alpha +a_4^*)}},\\&(h_0^{\gamma f_{2}})^{r'}=h^{r(\alpha +n_1)(\alpha +n_2)(\alpha +n_3)(\alpha +n_4)}. \end{aligned}$$

The simulation is indistinguishable from the actual attack. Therefore, when $Z=h_0^{\gamma f_{2}}$, the probability that $\theta '$ is a correct guess of $\theta$ is $\Pr [\theta '=\theta |Z=h_0^{\gamma f_{2}}]=\epsilon$. When Z is a random value from $\mathbb {G}$, the challenge index will be random and independent from $\mathcal {A}$’s view. This is a perfect one-time pad encryption. Therefore, when Z is a random value from $\mathbb G$, the probability that $\theta '$ is a correct guess of $\theta$ is $\Pr [\theta '=\theta |Z \,\text{ is } \text{ random }]=\frac{1}{2}$.

If $\mathcal {B}$ does not abort, then $|\Pr [\theta '=\theta ]-\frac{1}{2}|\geqslant \epsilon$. Without loss of generality we assume that $\mathcal {A}$ does not ask for the token of the same IP addresses twice.

Assume that $\mathcal {A}$ makes at most $q_{T}$ token queries and $q_s$ key extraction queries in Phase 1 and Phase 2. According to the above process, $\mathcal {B}$ aborts if a token query is made for the challenge source IP $SIP_0$ or $SIP_1$. The probability to make token query for $SIP_0$ or $SIP_1$ is $1/(q_{T}+1)$. The private key query does not make $\mathcal {B}$ abort. Thus, $\mathcal {B}$ does not abort if none of the $q_T$ token queries is made for $SIP_0$ or $SIP_1$. Therefore, in Phase 1 or 2, the probability that $\mathcal {B}$ does not abort is at least $(1-1/(q_{T}+1))^{q_{T}}\geqslant 1/e$.

In the challenge phase, $\mathcal {B}$ will abort if $\mathcal {A}$ does not choose $SIP_{0}$ or $SIP_{1}$. Since $\mathcal {A}$ has not queried for the token for $SIP_{0},SIP_{1}$, the choice of both $SIP_{0}$ and $SIP_{1}$ are independent of $\mathcal {A}$’s current view. Therefore, the event that $\mathcal {A}$ does not choose $SIP_0$ and the event that $\mathcal {A}$ does not choose $SIP_1$ are independent. Since $\Pr [SIP_{\theta }=SIP_{0}]=\Pr [SIP_{\theta }=SIP_{1}]=1/(q_{T}+1)$, we have $\Pr [SIP_{\theta }\ne SIP_{0},SIP_{1}]=(1-1/(q_{T}+1))^{2}\leqslant 1-1/q_{T}$. Hence, the probability of the event that $SIP_{\theta }\in \{SIP_{0},SIP_{1}\}$ is at least $1/q_{T}$.

Observe that $\mathcal {B}$ does not abort if and only if $\mathcal {A}$ has never issued the token query for the challenge source IP addresses $SIP_{0},SIP_{1}$ in Phase 1 and Phase 2 and it has chosen $SIP_{0}$ or $SIP_{1}$ in the challenge phase. The event that $\mathcal {B}$ does not abort in Phase 1 and Phase 2 and the event that $\mathcal {B}$ does not abort during the challenge phase are independent. Hence, the probability that $\mathcal {B}$ does not abort is at least $\epsilon /(e\cdot q_{T})$. $\mathcal {B}$’s running time is approximately the same as $\mathcal {A}$’s. $\square$

Theorem 2

The proposed privacy-preserving data packet filtering scheme is semantically secure against IP guessing attack in Game 2 if (n, 2)-MSE-DDH Problem is intractable for any polynomial-time algorithm.

Proof

The semantic security of our privacy-preserving data packet filtering scheme in Game 2 can be proved similarly as that in Theorem 1. Therefore, our privacy-preserving data packet filtering scheme resists the IP guessing attack. $\square$

6 The Proposed Privacy-Preserving Data Packet Filtering Protocol

In this section, we propose a data packet filtering protocol with source IP privacy-preserving and authentication. In our protocol, the recipient gateway performs the filtering operation without knowing the source IP address SIP, i.e. the recipient gateway cannot identify the source IP address from the filtering policy and the IP packets by mounting the chosen IP attack and IP guessing attack. Five types of participants take part in the protocol: the trusted authority, the sender host, the sender gateway, the recipient host and the recipient gateway. The data packet filtering protocol consists of seven phases: system initiation, IP address registration, policy setting, data packet transmission, data packet filtering, data packet authentication and data packet response. The procedure of the protocol is shown in Fig. 5 and the notations used in the protocol are listed in Table 1.

Table 1 Notations used in the proposed protocol

Fig. 5

The privacy-preserving data packet filtering and authentication procedure

6.1 System Initiation

In this phase, the system parameters of the data packet filtering system are set up by the Trusted Authority (TA). TA manages the whole system running and maintenance. TA generates its master secret key and public parameters by running the ${\mathsf {Setup}}$ algorithm. TA keeps the master secret key $\mathsf{MSK}$ private and publicizes the system parameters ${\mathsf{Params}}$.

6.2 IP Address Registration

Each host in the system registers to TA. This phase runs via a secret channel.

• 1. The host with IP address $IP=I_{1}.I_{2}.I_{3}.I_{4}$ submits its IP address IP to TA.

• 2. Upon receiving IP, TA checks the ownership and correctness of the IP address and runs the ${\mathsf {KeyGen}}$ algorithm to generate the private key $d_{IP}$. Then TA distributes $d_{IP}$ to the host of IP address IP through a secure channel. Each host in the system can be a sender host SH or a recipient host RH. For a sender host of IP address SIP, we denote its secret key as $d_{SIP}$; for a recipient host of IP address DIP, we denote its secret key as $d_{DIP}$.

6.3 Policy Setting

The recipient host RH of IP address DIP specifies the filtering policy at the recipient gateway RG as follows.

• 1. The recipient host RH stores the source IP addresses which need to be filtered in the Access Control List (ACL).

• 2. For each source IP address $SIP_j$ ($j\in [1,n]$) in ACL, the recipient host RH runs the ${\mathsf {Token}}$ algorithm to generate a new token $Token_j=(T_{1_j},T_{2_j})$ for the source IP $SIP_j$ and destination IP DIP, where

  $$\begin{aligned} T_{1_j}=h^{s\prod _{t=1}^4(\alpha +i_{S_{j_t}})},\quad T_{2_j}=(d_{DIP})^s=g^{\frac{s}{\prod _{t=1}^4(\alpha +i_{D_t})}}. \end{aligned}$$

• 3. Then the recipient host RH sends $Token_j$ to the recipient gateway RG through a public channel. The recipient gateway RG helps to set each piece of filter policy as $Policy_j=Token_j$.

6.4 Data Packet Transmission

The sender host SH of IP address SIP sends the data packet to the recipient host RH of IP address DIP via a secure channel between the sender gateway and the recipient gateway. The original data packet is repackaged and the new data packet is transmitted as follows.

• 1. The sender host SH runs the ${\mathsf {Index}}$ algorithm to generate the index $Index=(C_1,C_2)$ as

  $$\begin{aligned} C_1=h^{r\prod _{t=1}^4(\alpha +i_{D_t})},\quad C_2=(d_{SIP})^r=g^{\frac{r}{\prod _{t=1}^4(\alpha +i_{S_t})}}. \end{aligned}$$

• 2. The sender host SH generates the secret key $SK=e(g,h)^r$ and encrypts the source IP address in the original data packet Pack with SK by applying the symmetric encryption algorithm $Enc_{SK}(\cdot )$ as $\overline{SIP}=Enc_{SK}(SIP)$. The sender host SH stores the encrypted source IP address $\overline{SIP}$ and replaces the source IP address SIP in Pack with $\overline{SIP}$ to generate the data packet $\overline{Pack}$. Then SH sends the index $Index=(C_1,C_2)$, the subnet number I and the new data packet $\overline{Pack}$ to the trusted sender gateway SG. Assume that in $\overline{Pack}$, the destination IP address is DIP, the IP payload is IPP and the trailer Tr is the MAC of the data packet Pack.

• 3. Upon receiving the index Index, the subnet number I and the data packet $\overline{Pack}$, the sender gateway SG of IP address SGIP firstly encrypts the data packet $\overline{Pack}$ with the shared secret K by applying the symmetric encryption algorithm $Enc_K(\cdot )$. To generate the new data packet $Pack'$, SG repackages the encrypted data packet by appending the new IP HDR, the security HDR and the new trailer NTr to the encrypted data packet $Enc_K(\overline{Pack})$ as defined in Sect. 3, where the IP address SGIP of the sender gateway and the IP address RGIP of the recipient gateway are in the new IP HDR, the index $Index=(C_1,C_2)$ and the subnet number I are in the security HDR, and the new trailer NTr is the MAC of the new data packet $Pack'$. Then the sender gateway SG sends the new data packet $Pack'$ to the recipient gateway RG.

6.5 Data Packet Filtering

The recipient gateway RG acts as a filter and filters out those data packets whose source IP addresses are in the list ACL by running the ${\mathsf {Filter}}$ algorithm, and accepts the legal data packets according to the filtering policies specified by the recipient host RH. After that RG forwards the approved data packets to the recipient host RH.

• 1. Upon receiving the data packet $Pack'$ from the sender gateway SG, the recipient gateway RG checks the integrity of the data packet by verifying the NTr. If the integrity does not hold, the data packet $Pack'$ is discarded; Otherwise, the recipient gateway RG extracts the index $Index=(C_1,C_2)$ and the subnet number I from the security HDR in $Pack'$.

• 2. The recipient gateway RG reads the first filtering policy $Policy_1=Token_1$ and performs filtering operation by running ${\mathsf {Filter}}$ algorithm with respect to the filtering policy $Policy_1=Token_1$ and outputs the filtering result. If the recipient gateway RG outputs 1, which means the source IP in the data packet is one of the IP addresses to be filtered, the gateway discards the data packet; Otherwise, the recipient gateway RG reads the next filtering policy and performs filtering operation. If for all of the filtering policies RG outputs 0, it accepts the data packet $Pack'$ and decrypts the ciphertext in $Pack'$ with the shared secret key K to obtain the corresponding data packet $\overline{Pack}$. Then it forwards $\overline{Pack}$, the subnet number I, the index Index and the corresponding tunnel number TN to the recipient host RH.

6.6 Data Packet Authentication

Upon receiving the data packet $\overline{Pack}$, the subnet number I, the index Index and the corresponding tunnel number TN from the recipient gateway RG, the recipient host RH authenticate the original data packet as follows.

• 1. RH generates the shared secret key by computing $SK=e(C_1,d_{DIP})=e(g,h)^r$. Using SK, RH decrypts $\overline{SIP}$ to obtain the source IP address SIP. The RH uses SIP to replace $\overline{SIP}$ and obtains the original data packet Pack.

• 2. RH checks the integrity of the original data packet Pack by verify the correction of the MAC in the original trailer Tr. If the verification fails, RH discards the data packet.

• 3. Otherwise, the recipient host RH verifies the correctness of the source IP address $SIP=I_{S_1}.I_{S_2}.I_{S_3}.I_{S_4}$ by verifying

  $$\begin{aligned} e(C_2,g^{\prod \limits _{t=1}^4(\alpha +i_{S_t})})=e(C_1,d_{DIP})=e(g,h)^{r}, \end{aligned}$$

  where

  $$\begin{aligned} i_{S_1}&= {} H(I_{S_1}),\\ i_{S_2}&= {} H(I_{S_1}\Vert I_{S_2}),\\ i_{S_3}&= {} H(I_{S_1}\Vert I_{S_2}\Vert I_{S_3}),\\ i_{S_4}&= {} H(I_{S_1}\Vert I_{S_2}\Vert I_{S_3}\Vert I_{S_4}). \end{aligned}$$

  If the verification fails, the source IP will be a spoofed IP. Otherwise, the data packet is from the sender host with a valid source IP. Then the data packet Pack is accepted.

6.7 Data Packet Response

After the data packet is authenticated and approved, the recipient host RH makes a response to the sender host SH as follows.

• 1. RH generates a response data packet RPack, where $(DIP,\overline{SIP})$ is in its IP HDR. RH sends the tunnel number TN, the subnet number I, and RPack to the recipient gateway RG.

• 2. Upon receiving TN, I and RPack, RG checks the list to find the IP address SGIP of the sender gateway SG with respect to TN. RG repackages the data packet to generate a new data packet $RPack'$, where SGIP and RGIP are in the New IP HDR, the subnet number I is in the security HDR. RG sends $RPack'$ to SG through the secret tunnel.

• 3. Upon receiving $RPack'$, the sender gateway SG extracts the subnet number I and the original data packet RPack from $RPack'$ and broadcasts RPack in the subnet of number I.

• 4. Each host in the subnet checks $\overline{SIP}$ in its own storage. If $\overline{SIP}$ is in its storage, the sender host SH of IP address SIP accepts the response packet RPack.

7 Analysis and Discussion

7.1 Protocol Analysis

In this subsection, we analyze that our privacy-preserving data packet filtering protocol achieves the objectives we mentioned in Sect. 3.

Confidentiality In our protocol, when the sender gateway SG transmits the data packet $\overline{Pack}$ to the recipient gateway, the whole packet is encrypted under the secret key K. Therefore, the outside attackers cannot obtain any information about the data packet without the secret key K.

Integrity In our protocol, in both the original data packet Pack and the new data packet $Pack'$, a MAC is appended in the trailer of each packet, and the intended recipient gateway and recipient host can check the integrity of the data packet by checking the MAC. Any modification of the data packet can be discovered. Therefore, our protocol guarantees the integrity of the data packets.

Source authentication The recipient host RH can verify the source IP address SIP by checking the equation

$$\begin{aligned} e(C_2,g^{\prod \limits _{t=1}^4(\alpha +i_{S_t})})=e(C_1,d_{DIP}). \end{aligned}$$

If the equation does not hold, the source IP address SIP must be incorrect. According to [22], any attacker can not forge a valid index $Index=(C_1,C_2)$ without the secret key $d_{SIP}$. Therefore, the source IP address SIP can be authenticated. If the source IP address is a spoofed IP, the equation will not hold. Then IP spoofing can be detected. Therefore, our protocol provides source authentication, i.e. it resists the IP spoofing attack.

Soundness In our protocol, the filtering policy is specified by the recipient host of IP address DIP as Token for filtering the data packet whose source IP address is SIP. The data packet with the index Index is from the host of IP address $SIP'$, and it is sent to host with IP address $DIP'$. The filter gateway drops the data packet with index Index as long as the source IP $SIP'$ and the destination IP $DIP'$ in Index match the source IP SIP and the destination IP DIP correspondingly in the policy Token. Also, any data packet with matched Index is not accepted by the gateway. Hence, our protocol achieves soundness.

Completeness In our protocol, The filter gateway accepts the data packet with index Index as long as the source IP $SIP'$ and the destination IP $DIP'$ in Index does not match the source IP SIP and the destination IP DIP correspondingly in the policy Token. Also, the filter gateway does not filter out any data packet with unmatched index Index. Hence, our protocol achieves completeness.

IP Privacy-Preserving Since the recipient gateway has stronger attacking capability than any outsider attacker, we only need to analyze the IP privacy-preserving against the recipient gateway. According to Theorems 1 and 2, in our proposed data packet filtering scheme, the recipient gateway cannot obtain the source IP address by launching the chosen IP attack and the IP guessing attack. The outside attackers are weaker than the recipient gateway. Therefore, for both outsider attackers and the recipient gateway, the proposed packet filtering protocol achieves semantic security against the chosen IP attack and the IP guessing attack, i.e. the recipient gateway can neither obtain the source IP address SIP from the data packet nor from the specified policy Token. As in the response packet, SIP is also transmitted in ciphertext, i.e. $\overline{SIP}$, the outside attackers cannot obtain the source IP from the response packet. Thus, the source IP privacy is preserved against both the recipient gateway and the outsider attackers in our packet filtering system.

7.2 Comparison of Filtering Systems

We compare the achievements of our system with those of some recently proposed data packet filtering systems in Table 2 in terms of the objectives including “confidentiality”, “integrity”, “resistance against IP spoofing attack”, “soundness”, “completeness” and “source IP privacy-preserving”. In Table 2 the entry “✓” indicates “satisfied”, “$\times$” denotes “not satisfied” and “−” means “not mentioned”.

Table 2 Functionality comparison

The observations from Table 2 demonstrate that only our data packet filtering system achieves “confidentiality”, “integrity” and “source IP privacy-preserving”, whereas the others do not. Therefore, our data packet filtering protocol strengthens the privacy and usability of the filtering system according to the objectives.

7.3 Performance Evaluation and Comparison

In this subsection, we evaluate the performance of our data packet filtering system by demonstrating the filtering efficiency. The efficiency is evaluated by showing the simulation results in two experiments. In the first experiment, the recipient host RH only sets one piece of filtering policy at the filter gateway. In the second experiment, many pieces of filtering policies corresponding to different source IP addresses are set. Then we compare the performance of our filtering system with that of Liu et al.’s system [11], which satisfies soundness, completeness and resistance against the IP spoofing attack, but cannot achieve source IP privacy-preserving.

In order to evaluate the computation cost, we exploit PBC [23] and OpenSSL libraries [24] on the Windows 7 system with the Inter(R) Core (TM) i5-2500K processor (6M cache, 3.30GHz with 8GB memory). In the experiment, we use the Tate pairing defined over a supersingular elliptic curve $E/\mho _p:y^2=x^3+x$ with an embedding degree of two. The group $\mathbb G$ generated over the elliptic curve $E/\mho _p:y^2=x^3+x$ is of order p, where $\mid {\mathbb G}\mid =160$ bits and $\mid p\mid =160$ bits.

In the first experiment, we evaluate the performance of the filtering operation with many data packets and only one filtering policy. In the experiment, we set the recipient host’s IP address as $DIP=175.10.1.2$ and the filtering policy to filter the source IP address $SIP=130.10.1.1$. The filter gateway operates the filtering procedure by running the ${\mathsf {Filter}}$ algorithm. From the experiment result, we find that the data packets with the source IP $SIP=103.10.1.1$ are filtered out and others are accepted. Therefore, the property of soundness and completeness can be verified.

Fig. 6

Computation cost of filter gateway for filtering multiple data packets

Figure 6 shows the computation cost of the filtering operation increases almost linearly with the number of the received data packets.

In the second experiment, we evaluate the performance of the filtering operation with many filtering policies corresponding to different source IP addresses. In the experiment, we also set the recipient host’s IP address as $DIP=175.10.1.2$. The source IP addresses to be filtered are listed as follows.

$$\begin{aligned} \begin{array}{llll} SIP_1&{}=130.10.1.1;~&{}~SIP_2&{}=130.10.1.2;\\ SIP_3&{}=130.10.1.3;~&{}~SIP_4&{}=130.10.1.4;\\ SIP_5&{}=130.10.1.5;~&{}~SIP_6&{}=130.10.1.6;\\ SIP_7&{}=130.10.1.7;~&{}~SIP_8&{}=130.10.1.8;\\ SIP_9&{}=130.10.1.9;~&{}~SIP_{10}&{}=130.10.1.10;\\ SIP_{11}&{}=130.10.1.11;~&{}~SIP_{12}&{}=130.10.1.12. \end{array} \end{aligned}$$

The filter gateway operates the filtering procedure by running the ${\mathsf {Filter}}$ algorithm. From the experiment result, we find that the data packet with the source IP address in the above list is filtered out and others are accepted. Therefore, the property of soundness and completeness can also be verified.

Fig. 7

Computation cost of filter gateway for multiple filter policies

In Fig. 7, we only show the worst case. Figure 7 shows the computation costs of the filtering operation increase with the number of the filter policies when the number of data packets to be operated is $m=1$, $m=10$, $m=50$, $m=100$ respectively. From Fig. 7, we can find that the computation cost of the filter gateway increases almost linearly with the number of the filter policies. When 100 data packets are to be operated in a filter system with 10 filter policies, in the worst case, it takes about 4.5 ms computation cost, which is acceptable in practical system.

In the following, we compare the performance of our system with that of [11]. When filtering 1 data packet in a filtering system with 50 filter policies, it costs 235 ms in our system, and 19 ms in [11]. When filtering 1 data packet in a filtering system with 100 filter policies, it costs 459 ms in our system, and 23 ms in [11]. When filtering 1 data packet in a filtering system with 200 filter policies, it costs 920 ms it our system, and 30 ms in [11].

Although the computation cost is the tradeoff, our system offers much better security property, i.e. the source IP privacy-preserving. Therefore, our filtering system can be applied in some special cases where the source IP cannot be revealed, e.g. for army, government, etc. To solve the problem of source IP protection in the filtering system, it will inevitably introduce additional computation due to the cryptographic algorithms. However, from our experiments, the computation overheads are still acceptable.

8 Extension of Public Gateway System Filtering

As shown in Fig. 8, the recipient host may set only one filter policy to filter all of the data packets from the same subnet. For example, the recipient host with IP address “175.10.1.2” sets the filter policy to filter out all the data packets with source IP address “130.10.*.*”, where “*” means wildcard. In the following, we construct an extended data packet filtering scheme with source IP privacy-preserving, where the data packets from a subnet can be filtered out with only one piece of filter policy. For simplicity, we do not write down the complete data packet in Fig. 8, but only SIP, DIP and Payload in the data packets.

Fig. 8

Extended data packet filtering mechanism

8.1 Construction

In the extended scheme, the ${\mathsf {Setup}}$, $\mathsf {KeyGen}$ and ${\mathsf {Index}}$ algorithms are the same as those in the basic scheme. Assume that the data packets from the subnet with source IP address $SIP^*=I_{S_1}.I_{S_2}.*.*$ will be filtered out. Then the ${\mathsf {Token}}$ algorithm and the ${\mathsf {Filter}}$ algorithm are as follows.

${\mathsf {Token}}({\mathsf{Params}},d_{DIP},SIP^*).$ Taking as input the public parameters ${\mathsf{Params}}$, the private key $d_{DIP}$ of the destination IP address $DIP=I_{D_1}.I_{D_2}.I_{D_3}.I_{D_4}$, and the source IP address $SIP^*=I_{S_1}.I_{S_2}.*.*$, it chooses a random number $s\in \mathbb {Z}^{*}_{p}$, and computes the token $Token=\{T_1,T_2,T_3,T_4\}$ as

$$\begin{aligned} i_{S_1}&= {} H(I_{S_1}),\\ i_{S_2}&= {} H(I_{S_1}\Vert I_{S_2}),\\ T_1&= {} h^{s(\alpha +i_{S_1})(\alpha +i_{S_2})},\\ T_2&= {} h^{s\alpha (\alpha +i_{S_1})(\alpha +i_{S_2})},\\ T_3&= {} h^{s{\alpha }^2(\alpha +i_{S_1})(\alpha +i_{S_2})},\\ T_4&= {} (d_{DIP})^s=g^{\frac{s}{\prod _{t=1}^4(\alpha +i_{D_t})}}. \end{aligned}$$

${\mathsf {Filter}}(Index,Token).$ The filter takes as input the index $Index=(C_1,C_2)$ from the host of IP address $SIP=I_{S_1}.I_{S_2}.I_{S_3}.I_{S_4}$ and the token $Token=(T_1,T_2,T_3,T_4)$. It tries the last two segments of the IP address $I_{S_3}$ and $I_{S_4}$, which are chosen from the address pool, and outputs 1 if there is one equation

$$\begin{aligned} e\left( C_1,T_4\right) \mathop {=}\limits ^{?}e\left( C_2,({T_1}^{I_{S_3}}{T_2})^{I_{S_4}}({T_2}^{I_{S_3}}{T_3})\right) \end{aligned}$$

holds; otherwise, it outputs 0.

8.2 Correctness

Given the index Index of (SIP, DIP), where $SIP=I_{S_1}.I_{S_2}.I_{S_3}.I_{S_4}$ and $DIP=I_{D_1}.I_{D_2}.I_{D_3}.I_{D_4}$, and the token Token of $(SIP^*,DIP)$, where $SIP^*=I_{S_1}.I_{S_2}.*.*$, the correctness in the ${\mathsf {Filter}}$ phase can be verified as follows.

As $({T_1}^{I_{S_3}}{T_2})^{I_{S_4}}({T_2}^{I_{S_3}}{T_3})=h^{s \prod _{t=1}^4(\alpha +i_{S_t})}$, we have

$$\begin{aligned}&e(C_{2},({T_1}^{I_{S_3}}{T_2})^{I_{S_4}}({T_2}^{I_{S_3}}{T_3}))\\&\quad = e(g^{\frac{r}{\prod _{t=1}^4(\alpha +i_{S_t})}},h^{s \prod _{t=1}^4(\alpha +i_{S_t})}) \\&\quad = e(g,h)^{rs}\\&\quad = e(h^{r\prod _{t=1}^4(\alpha +i_{D_t})},g^{\frac{s}{\prod _{t=1}^4(\alpha +i_{D_t})}})\\&\quad = e(C_{1},T_{4}). \end{aligned}$$

Therefore, the data packet from the sender host of IP address $SIP=I_{S_1}.I_{S_2}.*.*$ can be filtered out correctly. From the index Index and the token Token, the recipient gateway cannot obtain the whole source IP address, but only knows $I_{S_3}$ and $I_{S_4}$.

Based on this extended data packet filtering scheme, we can construct an extended privacy-preserving data packet filtering protocol just as that in Sect. 6. In the extended protocol, with only one filter policy the data packets from a specified subnet can be filtered, and the properties of confidentiality, integrity, source authenticity, soundness, completeness and source IP privacy-protection can also be satisfied.

9 Conclusion

Motivated to protect the source IP privacy against the outside attacker and the malicious filter gateway in the data packet filtering system, we built the first privacy-preserving packet filtering system. We firstly proposed a privacy-preserving packet filtering scheme, which is provably secure against the chosen IP attack and the IP guessing attack. Based on the packet filtering scheme, a data packet filtering protocol featured with the source IP privacy-preserving and authentication was presented, where the filter gateway executes efficient filtering operation without obtaining the source IP address of the data packets and the recipient host can detect the spoofed source IP in data packets. Through the functionality comparison with related packet filtering systems, we demonstrate that only our filtering system achieves confidentiality, integrity, privacy-preserving and source IP authentication. Experimental results show that the proposed protocol is feasible for practical use in the current filter gateway. We also presented an extension of our privacy-preserving packet filtering scheme to filter out data packets from the same subnet with only one piece of filter policy.