Abstract
Content Centric Networking (CCN) is an effective communication paradigm that well matches the features of wireless environments. To be considered a viable candidate in the emerging wireless networks, despite the clear benefits of location-independent security, CCN must at least have parity with existing solutions for confidential and anonymous communication. This paper designs a new cryptographic scheme, called Asymmetric Index Encapsulation (AIE), that enables the router to test whether an encapsulated header matches the token without learning anything else about both of them. We suggest using the AIE as the core protocol of anonymous Content Centric Networking. A construction of AIE which strikes a balance between efficiency and security is given. The scheme is proved to be secure based on the DBDH assumption in the random oracle with tight reduction, while the encapsulated header and the token in our system consist of only three elements.
1. Introduction
Conventional networking protocols designed to support end-to-end communications between nodes which are uniquely identified through an IP address may fail in wireless environments due to dynamic changes caused by the mobility. Content Centric Networking is an emerging networking architecture with the goal of becoming an alternative to the IP-based Internet. Communication in CCN adheres to the pull model. Its primary characteristic is that content and routable content in the network are always named. Interests represent the willingness of the consumer to retrieve certain content, independently of its location. A consumer who wishes to obtain content first issues an interest by name, which is then routed to the producer or router that is capable of satisfying the request. The corresponding content carrying the same name is then sent to the consumer along the reverse path.
The CCN architecture has some innate privacy friendly features; for example, the source addresses of contents are hard to trace. However, support for name privacy is not a standard feature. Names reveal significantly more information about content than IP addresses [1].
ANDaNA [2] and AC3N [3] are the initial attempt to provide anonymous communication in CCN. They are inspired by Tor, using onion-like encryption to wrap interests, and forwarded by participating anonymizing routers. However, caching mechanism as one of the most important features of CCN could not be used in these designs due to the lack of an cryptographic primitive keeping the name private while ensuring accessibility and routability.
In this paper we propose a new cryptographic scheme called Asymmetric Index Encapsulation (AIE) to hide the name except the entity which is given appropriate token. Token can be viewed as a kind of encrypted interest; it can only be generated from the authorized consumers and the functionality of the token kept secret even during the name and interest match procedure. We believe AIE is a positive answer to the open question raised in [1, 4]. AIE is proved to be secure based on the DBDH/CDH assumption in the random oracle with tight reduction, while the encapsulated header and the token in our system consist of only three elements. Moreover, AIE is applicable in any CCN incarnation, for example, CCNx and NDN [5].
1.1. Organization
The rest of this paper is organized as follows. The next section shows the related work of our paper. Section 3 gives an overview of CCN. The scheme description is presented in Section 4. Definitions of security model are given and discussed in Section 5. The reduction proofs are shown in Sections 6 and 7. Then we show implementation and provide an analysis of the performances of the proposed schema in Section 8. Finally, we conclude with related work and future work in Section 9.
2. Related Work
Symmetric searchable encryption with adaptive security against chosen-keyword attacks was first considered explicitly in [6], where symmetric index encapsulation was first considered explicitly by [7]. Unlike in asymmetric settings, securely encapsulating a single keyword/index is nearly trivial in symmetric settings. In these schemes and subsequent work [8–11], researchers focus on how to handle full text indices and try to improve efficiency. Another line of work uses deterministic encryption [8, 12]. It only provides security for data and queries that have high entropy.
Starting with the work of Boneh et al. [13–15], searchable encryption has also been considered in the public key setting [10, 16–19]. The early works lack function privacy until the first definition was suggested very recently by Boneh et al. [20].
One of the key goals of CCN projects is “security by design” [21]. In contrast to today’s Internet, where security problems were identified along the way, the research community stresses both awareness of issues and support for features and countermeasures from the outset. To this end, a few of papers investigate various attacks and solutions in CCN or CON [1, 2, 5]. However, to the best of our knowledge, there is an absence of cryptographic perspective. The major contribution of our paper is in defining a new cryptographic primitive known as Asymmetric Index Encapsulation scheme.
A preliminary version of this paper [22], which concentrated on solving the related fundamental cryptographic problem, appeared at ProvSec 2016, while this paper focuses more on solving practical problem of CCN network. The extra contents mainly are shown in Sections 8 and 9.
3. CCN Overview
We now review the building blocks of Content Centric Networking. There are three types of entities in CCN:(i)Consumer which issues interests for content(ii)Producer which generates and publishes content to the network(iii)Routers which forward interest messages and content between consumers and producers
CCN supports two types of packets:(i)Named content: in CNN, contents are always named to facilitate data dissemination and search. A content name is a URI-like string composed of one or more variable-length segments.(ii)Interest: to obtain content, consumer issues a request, called an interest message, with the name of the desired content. This interest will be satisfied by either a router or the content producer.
Name and interest matching in CCN is exact, for example, an interest for “/2017/news.txt” can only be satisfied by a content object named “/2017/news.txt.”
Each CCN entity should maintain the following components:(i)Forwarding Interest Base (FIB): this includes a lookup table used to determine entities for forwarding incoming interests.(ii)Pending Interest Table (PIT): this include a lookup table of outstanding pending interests and a set of corresponding incoming entities.(iii)Content Store (CS): this is a buffer used for content caching and retrieval. Each network entity can provide content caching, which is limited only by resource availability. Note that this is different from packet buffers in today’s routers, as cache size is expected to be several orders of magnitude bigger in CCN.
All CCN communication is initiated by a consumer that sends an interest for a specific content [23]. When a router receives an interest, it looks up its PIT to determine whether an interest for the content is pending:(i)If the desired name in the PIT, the interest does not need to be forwarded further. If the arrival entity is new, the router just updates the PIT entry by adding a new incoming entity.(ii)Otherwise, the router looks up its CS for a matching content. If it succeeds, the cached content is returned and no new PIT entry is needed. If no matching content is found, the router creates a new PIT entry and forwards the interest using its FIB.
During receipting of the interest, the producer distributes requested content among the network, thus satisfying the interest. Then, the content is forwarded towards the consumer, by the path of the preceding interest, in reverse.
4. Scheme Description
Formally, AIE is specified by a quadruple of probabilistic polynomial-time algorithms:(i)The setup algorithm is run by the central authority, takes a security parameter , and outputs the public system parameters together with a master secret key . The system parameters will be publicly known, while the master key will be known only to the key generation algorithm.(ii)The index (a.k.a. name) encapsulation algorithm is run by the producer, takes as input an index , and outputs encapsulated header .(iii)The token generation algorithm is run by the central authority, takes as input the master secret key and an interest , and outputs a related token .(iv)The test algorithm is run by the router, takes as input a header and a token , and outputs a value which indicates the matching relationship between and , “1” for matching and “0” on the contrary. Usage of this algorithm is to show the linkability between headers and tokens.
To deploy AIE in CCN, we should introduce a trusted central authority which is in charge of issuing token. As illustrated in Figure 1, if a consumer plans to request a content named , instead of sending the plain interest packet, it should use the token issued by from the central authority. Token is like a private key of public encryption scheme. However, its functionality is not decrypting but testing.
When a producer generates new content named , it encrypts the content at first. The encryption algorithm used by consumers to conceal content should be secure against adaptive chosen ciphertext (CCA) attacks. Then, the producer runs encapsulation algorithm to encapsulate the name . We call the output of the encapsulated header of . Finally, a signature binds the encrypted content with its encapsulated header and provides origin authentication no matter how or from where it is retrieved. For any adversary without the correct token, this signed and encrypted packet will lose no information under our security model (discussed in Section 5.4).
When a token is received and there are no same pending tokens in its cache, router runs algorithm to find an encapsulated header which matches the token. If there is no such encapsulated header, the router forwards this new token to the neighbor routers. When the desired content is returned or there is already an encapsulated header matching this token in the cache, the router forwards it out on all neighbors and flushes the corresponding cache entry.
Since adversary can mount a guessing attack, exhaustively testing the known token, we give a reasonable security model in Section 5.5 to ensure that there is no more obviously effective attack better than the brute force method.
4.1. Construction
Let be a probabilistic polynomial-time algorithm taking as security parameter and outputs , where and are groups of prime order , , is a generator of group , and is a nondegenerate efficiently computable bilinear map. See [24] for a description of the properties of such pairings. We present AIE scheme as follows; the design inspiration comes from [20, 25].(i) : on input security parameter , the setup algorithm works as follows:(1) Generate .(2) Randomly sample .(3) Compute .(4) Choose two cryptographic hash functions and . The security analysis will view , as random oracles.(5) Output as master key and as public parameters.(ii) : given , the index encapsulation algorithm does the following:(1) Randomly sampling (2) Computing , , and (3) Outputting as an encapsulated header(iii) : on input master key and an index , the token generation algorithm does the following:(1) If the same query for is repeated twice, then the same token is provided.(2) It randomly chooses .(3) It computes .(4) It outputs and records as the token of .(iv) : given an encapsulated header and a token , the test algorithm does the following:(1) It parses as and as .(2) It checks if the following equation holds true: and if it holds, output “1,” meaning matches ; else output “0.”
Correctness. For any index , we need to guarantee , where and . Denoting and , that is clear since
5. Security Models
We give the precise formal definitions based on the above discussion.
5.1. Notation
We denote by a joint distribution of random variables, and by a sample drawn from . The min-entropy of a random variable is . A -source is a random variable with . A -block-source is a random variable , where, for each , holds that is -source. The statistical distance between two random variables and over a finite domain is defined as
5.2. DBDH and CDH Assumption
Decisional bilinear Diffie-Hellman (DBDH) problem is to distinguish two distributions and for random , , , and . Computational Diffie-Hellman (CDH) problem is to compute given and . To state the assumption asymptotically we rely on the bilinear group generator algorithm .
Definition 1. Let be a bilinear group generator. The DBDH assumption holds for if, for all probabilistic polynomial-time algorithm , its BDDH advantage, denoted byis a negligible function of , where the probability is over , , .
Definition 2. Let be a bilinear group generator. The CDH assumption holds for if, for all probabilistic polynomial-time algorithm , its CDH advantage, denoted byis a negligible function of , where the probability is over , .
5.3. The Leftover Hash Lemma
Definition 3 (universal hash function). A collection of function with form is universal if for any such that the following holds:
Theorem 4 (leftover hash lemma for block-source; see [20]). Let be a universal collection of functions ; let be -block-source where . Then there exists the distributionwhere is -close to the uniform distribution over .
5.4. Security Model for Anonymity
AIE is anonymous if leaks no information about . To capture the anonymity properties formally, a game between a challenger and an adversary is defined as follows:(i)Setup Phase: the challenger runs and sends to adversary and keeps to itself.(ii)Prechallenge Phase: in this phase, adversary is allowed to make token extraction query. The challenger responds to the query about index by sending to the output of .(iii)Challenge Phase: submits two indices , , which is restricted to the indices that he did not request in prechallenge phase. The challenger flips a fair binary coin and returns as challenge header.(iv)Postchallenge Phase: this phase is repeat of prechallenge phase. The adversary issues additional adaptive queries with the restriction where it can not request token of or .(v)Guess Phase: finally, submits a guess of . The adversary wins if .
Definition 5 (anonymity of AIE). AIE is anonymous if, for any probabilistic polynomial-time algorithm , its ANON advantage, denoted byis a negligible function of , where the probability is over the random bits used by the challenger and the adversary.
5.5. Security Model for Function Privacy
Formalizing such a notion is not straightforward since adversary can mount a guessing attack. If adversary has some knowledge that the token comes from a small set, it can encapsulate each candidate index and run the legitimate procedure to learn the function embedded inside the token. We adapt the notion from [20] which requires that is indistinguishable from a random token if is chosen from a sufficiently high min-entropy distribution. The following security game parameterized by a distribution helps us capture properties of function privacy:(i)Setup Phase: the challenger runs and sends both master secret key and public parameters to adversary .(ii)Challenge Phase: in this phase, the challenger samples an indices vector from the distribution and then, for every , computes and returns to .(iii)Guess Phase: finally, submits a guess of the distribution challenger has used. It outputs “” standing for uniform distribution; otherwise it outputs “.”
Definition 6 (privacy of AIE). AIE says private function if, for any probabilistic polynomial-time algorithm and any -block-source distribution where is a polynomial of , its PRIV advantage, denoted byis a negligible function of where stands for uniform distribution.
To gain reasonable high min-entropy in anonymous CCN, we suggest that data provider should assign a complicated name of the encrypted data. Since adversary can mount a guessing attack (exhaustively testing the token by using pairings), the definition of privacy actually guarantees that there is no more obviously effective attack better than the brute force method.
6. Proof of Anonymity
We use reduction to prove anonymity of our scheme under the DBDH assumption.
Lemma 7. Suppose there is an adversary that can win the anonymity game with advantage . Then there is an algorithm which solves the DBDH problem with advantage .
Given a tuple , which is either sampled from or from , algorithm interacts with adversary as follows.
Setup Phase. sets up public parameter .
Programming the Random Oracle. simulates the random oracle for as follows. If the same query is repeated twice, then the same return value is provided, on issuing a fresh query for , and (1) samples , ,(2) stores tuple in table ,(3) returns , On issuing a fresh query for , (1) samples , ,(2) stores tuple in table ,(3) returns .
Prechallenge Phase. On issuing a token for index , algorithm does the following:(1) If the same query for is repeated twice, then the same token is provided.(2) If has not made a query for and/or , it programs and/or as mentioned above.(3) It retrieves from and from .(4) It samples and computes . That is, it randomly samples and such that .(5) It computes .(6) It returns .
Correctness of Simulation. We argue that is always a proper token corresponding to since
Challenge Phase. After sends and , algorithm does the following:(1)It picks a random bit .(2) If has not made a query for and/or , it programs and/or as mentioned above.(3) It retrieves from and from .(4) It computes , , .(5) It returns as challenge header.
Postchallenge Phase. responds as before in prechallenge phase.
Guess Phase. Finally outputs a guess of . concludes its own game by outputting a guess as follows. if , returns , else returns .
Analysis of ℬ’s Behavior. Denote . If is sampled from , that is, , then is a perfectly legitimate header of since Therefore, simulates a perfect environment of , and the probability of the event winning the game is identical to . However, when is uniformly random, the challenge header will not be legitimate. This is not a problem, and indeed it is crucial to the proof of security.
Lemma 8. If is sampled from uniform random, the distribution of is independent of the adversary’s view, so the probability of event winning the game is identical to .
Proof. Consider the joint distribution of the adversary’s view. Note that the adversary is not allowed to make a token query for and ; from his view, only , , , and may leak information about . What we need to prove is that, for any fixed , , , , , , , , and ,where the probability is over , , , , and . That is clear because the four equations are linearly independent since, for any fixed , , , and ,That concludes that learns nothing about .
To summarize, when the input tuple is sampled from , then adversary’s view is identical to its view in a real security game and therefore satisfies . When the input tuple is sampled from , then . Therefore, we have thatWe present our conclusion as the following statement.
Theorem 9. The AIE scheme one proposed is anonymous, assuming the DBDH assumption holds for the bilinear group generated by .
7. Proof of Function Privacy
Proof. Denote by the distribution of ’s view in the game and by the distribution of ’s view in the game . We prove that is statistically close to even for arbitrary fixed public parameters.
Suppose received tokens corresponding to in the challenge phase. As knows the master key and having fixed , we can assume that is equivalent towhere and for each .
Without loss of generality, we can assume that and are injective since they are modeled as random oracle. Assuming that and are injective guarantees that for any -block-source over the fact that is also a -block-source over holds.
Note that the collection of functions defined by are universal (see [26]). This enables us to directly apply the leftover hash lemma on block-source, implying that the statistical distance between and the uniform distribution is negligible in . The same holds also for since is a -block-source in particular. This completes the proof of function privacy.
We present our conclusion as the following statement.
Theorem 10. The AIE scheme one proposed is (computational) function privacy under random oracle model.
8. Implementation and Performance
We implement our AIE schema by JPBC Library [27]. JPBC Library provides cryptographic interface to perform the mathematical operations underlying pairing-based cryptosystems. Our experiments were deployed on Intel Xeon E3-1231, a 4-core 3.40 GHz CPU, with 8 GB of RAM. We calculate the average time cost of each algorithm run on security parameters with different length. The result is shown in Table 1.
As we introduced in Section 3, is run by the central authority only once, when deploying the environment. When the producer generates new content, is run by producer once. When a consumer plans to request a content, is run by the central authority and is run by each router. Thus, the extra time a consumer would spend for AIE is no more than , where represents the hop count. Taking 120-bit security parameter as an example, assuming the hop count is 5 on average [2], the total extra time cost for a consumer is ms on average. AIE schema brings only less than 5 ms latency on each hop.
The relationship between time cost and the length of security parameter is shown in Figure 2. The comparison of four groups of data with different length of security parameter is shown in the graph horizontally. Each bar represents an algorithm in AIE, which is , , , and from left to right. The vertical axis represents the average time cost of each experiment. It concludes that the performance of AIE is satisfying with small size of security parameter. But the time cost increases by a large margin with the increase of security parameter size. However, it is not necessary to choose too large security parameter since no one can break DBDH and CDH assumption up to the present.
Finally we turn to study the stability of our protocols run time. Figures 3 and 4 show time cost of each independent call of and with 240-bit security parameter. -axis represents the index of each call and -axis represents the time cost. Each point in the graph represents a result of one experiment. As expected, the result shows most calls of and are very close to the average time cost.
The experimental results are quite different from other approaches [2, 3]. The main time costs of [2, 3] are used in the transmission of data. But since our scheme decouples index from data, the run time costs are used in encapsulating the index, and the performance of our scheme can be seen as a negligible constant, which is uncorrelated with the data size.
9. Conclusion
This work presents an initial attempt to provide privacy and anonymity in CCN by cryptographic protocol. We embed AIE scheme in the CCN to provide comparable anonymity with lower relative overhead.
AIE is a new cryptographic primitive. There are at least two differences between Asymmetric Index Encapsulation and PEKS or identity based searchable encryption [13, 20]. Firstly, the goal of AIE scheme is to decouple index hiding and searching procedure from encryption scheme. There are independent application scenarios of index encapsulation. Identity based searchable encryption can be replaced by any combination of AIE and anonymous identity based encryption. Secondly, Asymmetric Index Encapsulation scheme does not imply public key encryption or identity based encryption. There is possibility of getting better security reduction and efficiency.
The security of our scheme relies on the DBDH/CDH assumption in prime-order groups and random oracle. An encapsulated header in our system consists of only three elements, while a token in our system also consists of only three elements. Besides the acceptable efficiency in practice, the scheme has tight security reduction against all kinds of adversaries. (A security reduction is said to be tight when breaking the scheme is exactly as hard as solving the underlying problem.)
We introduce new adversarial models for anonymous CCN. The anonymity model captures the intuitive notion that an adversary should not be able to distinguish between the encapsulated header of two challenge indices of his choice, even if it is allowed to obtain tokens for any other indices. The privacy model requires any token belonging to index to be indistinguishable from a random token if is chosen from a sufficiently high min-entropy distribution.
An interesting open problem is to construct AIE schemes for other classes of functions. A possible starting point is to consider simple functionalities, such as wildcard [28] and inner-product testing [29]. Another fascinating open problem is to design a scheme which is secure in the standard model as well as keeping the token size and header size constant. Finally, we leave it as an open problem to design an AIE scheme without pairing.
Disclosure
An extended abstract was presented at Provable Security 10th International Conference, ProvSec 2016 [22].
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.