An Effective Privacy-Preserving Data Coding
in Peer-To-Peer Network

Ngoc Hong Tran1, Cao Vien Phung 2, Binh Quoc Nguyen 1, and Leila Bahri 3
Vietnamese-German University 1, Vietnam, Technische Universität
Carolo-Wilhelmina zu Braunschweig2, Germany, and KTH 1, Sweden

Abstract

Coding Opportunistically (COPE) is a simple but very effective data coding mechanism in the wireless network. However, COPE leaves risks for attackers easily getting the private information saved in the packets, when they move through the network to their destination nodes. Hence, a lightweight cryptographic approach, namely SCOPE, was proposed to consolidate COPE against the honest-but-curious and malicious attacks. Honest-but-curious attack serves adversaries who accurately obey the protocol but try to learn as much private information as possible for their curiosity. Additionally, this kind of attack is not destructive consequently. However, it may leave the backdoor for the more dangerous attacks carrying catastrophes to the system. Malicious attack tries to learn not only the private information but also modifies the packet on harmful purposes. To cope with this issue, in this work, a lightweight cryptographic approach improves COPE, namely SCOPE, that is defensive to the both attacks. The private information in the COPE packet are encrypted by Elliptic Curve Cryptography (ECC), and an additional information is inserted into SCOPE packets served for the authentication process using the lightweight hash Elliptic Curve Digital Signature Algorithm (ECDSA). We then prove our new protocol is still guaranteed to be a secure method of data coding, and to be light to effectively operate in the peer-to-peer wireless network.

Keywords

Network Coding, Peer-to-Peer, Homomorphic Encryption, Elliptic Curve Cryptography (ECC), Elliptic Curve Digital Signature Algorithm (ECDSA), Honest-But-Curious Attack, Malicious Attac

1. Introduction

To increase the network performance, network coding mechanisms are adopted to reduce as much bandwidth consumption as possible. The network coding can do it as the intersecting node (i.e., intermediate node) aggregates (i.e., codes) several packets into a coded packet, then it broadcasts the coded packet to all nodes in its radio range. In our work, we leveraged a simple but very effective network coding mechanism for wireless networks, that is, the Coding Opportunistically (COPE) model [1]. COPE is simply applied for any 2-hop paths in the wireless network. It uses a binary Exclusive-OR (XOR) to code several eligible packets into the coded packet. Moreover, not all packets can be coded at the intersecting node. Only eligible packets, satisfying the wellpredefined coding conditions evaluated by the intersecting node, can be coded then broadcast to the intersecting node’s neighbors.

Although COPE is simple and effective, it still owns a number of drawbacks leading to the security and privacy issues. The challenge, however, is to ensure the security and privacy of a network coding protocol without much sacrificing the initial goal of increasing network capacity. It is indeed well known that cryptographic schemes do mostly come with huge costs both in terms of size and

securing COPE by adopting the Elliptic Curve Cryptography (ECC) algorithm [2]. SCOPE solves the security and privacy issues of COPE against the honest-but-curious attack. Honest-but-curious attackers accurately obey the protocol but try to obtain as much private information in the packets as possible. More particularly, SCOPE protects the packets against being overheard, so the packet content cannot be read easily by the other nodes. In another hand, the intermediate SCOPE nodes in charge of coding the packets cannot misuse the packet data. They cannot be aware of the packet queues of their neighbors, so cannot fetch packets that can be coded. SCOPE is still effective and
efficient in encrypting and coding at the same time, as ECC is a lightweight encryption algorithm and most of its operation are binary operators such as AND, OR, Ex-OR (XOR), etc. Therefore, SCOPE fits the features of a peer-to-peer networks.

Even though SCOPE can protect the data coding against honest-but-curious attack, SCOPE still has short-coming in protecting the packets against malicious attack. Malicious attack is more dangerous than honest-but-curious attack, as it can modify or change the data contained in the packet. For example, let us see the network scenario in Figure 2. We can see that 𝑁1 can listen to and get packets which 𝑁2 and 𝑁4 send to 𝑁5. If 𝑁1 is a malicious node, it can modify the packet’s data from 𝑁2 and 𝑁4 for the other transactions, or modify the data. In this work, we exploit the authenticating strategy to make SCOPE more robust against the malicious adversaries by applying the Elliptic Curve Digital Signature Algorithm (ECDSA) [3]. Under the security power of ECDSA, the zombie packets are removed from the transaction and cannot reach the destination node.

The rest of this paper is organized as follows: in Section 2 we review the related works about secure data coding. In Section 3 we introduce COPE and the core ECC encryption algorithm. In Section 4 we formalize our security models. Section 5 discusses the security requirements necessary for the proposal. Section 6 introduces our proposal, namely SCOPE. In Section 7 we present the COPE and SCOPE packet format to make a clarification of the security property of the proposal. The lightweight cryptographic SCOPE against attacks are detailed in section 8. The experiments are evaluated in Section 9. The security properties are expressed in Section 10. We finally conclude
the paper in Section 11.

2. Related Works

In the work [4], authors analyze the security of network coding mechanisms. This work considers the single source scenario in which an eavesdropper is able to read the private information. Subsequently, [5] secures network coding with different models has been proposed. In [6], authors propose a Wiretap model for collecting subsets of nodes in a network coding system such that each Wiretapper is allowed to access only one of these subsets. Moreover, we find another model proposed in [7] in which the authors focus on preventing traffic analysis and tracing in multi-hope wireless networks, by deploying Paillier [8], a homomorphic encryption scheme operating on large primes. Hence, the related performance as operations done on large prime numbers is quite costly. In [9], authors analyse a numerous shortcomings of the Homomorphic Message Authentication Code (H-MAC), that is, its vulnerability to pollution attacks, and how to secure communications in the transmission networks. The work is showed that the proposed method results in decreasing the related bandwidth overhead, but the overhead remains considerable. Additionally, a variety of the other related works [10, 11] also apply H-MAC based techniques to secure network coding; however, the overhead remains quite high and the problem of data and attack risk still remains an issue.
Moreover, authors in [12] identify a flaw in H-MAC in general and have provided a corresponding

inaccuracy in its formal security proof. This keeps it to doubt whether H-MAC based solutions are worthwhile in practice or not. Differently from the available works in cryptographic secure network coding schemes, our work adopts the lightweight ECC and ECDSA schemes to address the security and privacy issues. The work is applied into the COPE data coding scheme.

3. Preliminary

In this section, the coding algorithm COPE and the core encryption algorithm Elliptic Curve Cryptography (ECC).

3.1 Coding Opportunistically (COPE)

COPE has been the first practical network coding mechanism significantly reducing a number of transmissions in the wireless networks, so well optimizes the wireless bandwidth consumption. A standard COPE is always applied for the 2-hop flows only. A 2-hop flow is considered as a path includes three nodes that are connected and involved in a transaction. Among those three nodes, the middle node is called an intersecting node. It does the function of an encoder, more specifically, it codes (i.e., aggregates) several packets into one packet. The outputted packet, namely coded packet, is then forwarded through a single transmission. Whereas, the two sided nodes are called respectively destination node (i.e., receiving the coded packet) and source node (i.e., sending the packet to the destination node through the intersecting node). The destination node is also considered as a decoder. It can decode the coded packet and obtain the packet to be claimed for it. Let us understand the above concepts through the following example

Figure 1: Simple data transmission model for three nodes. a) Without COPE; b) With COPE.

𝑁2 → 𝑁1 in Figure 1. 𝑁2 is called an intersecting node or encoder, since it locates between 𝑁1 and 𝑁3. In flow 1, node 𝑁1 transfers the packet 𝑃1 to 𝑁3, thus 𝑁1 is a source node and 𝑁3 is a destination node or decoder. In flow 2, node 𝑁3 transfers the packet 𝑃3 to 𝑁1, thus 𝑁3 is a source node and 𝑁1 is a destination node or decoder. Figure 1-a describes the network transmission without being applied with COPE. In that case, 𝑁2 receives 2 packets 𝑃1 and 𝑃3 from 𝑁1 and 𝑁3, then creates 2 unicast transmissions to forward 𝑃1 to 𝑁1 and 𝑁3, and 2 unicast transmissions to forward 𝑃3 to 𝑁1 and 𝑁3. Whereas, Figure 1-b presents the network transmission applied with COPE. As 𝑁2 receives 𝑃1 and 𝑃3 from 𝑁1 and 𝑁3 respectively, it codes 𝑃1 and 𝑃3 by Exclusive-ORing (i.e., XORing) them to produce a coded packet 𝑃 = 𝑃1 + 𝑃3. Then, 𝑁2 creates one broadcast transmission to forward P to 𝑁1 and 𝑁3. At 𝑁1, 𝑃1 decodes 𝑃 to achieve 𝑃3 by XORing 𝑃 by its 𝑃1, i.e. 𝑃3 = 𝑃 + 𝑃1. The same decoding way is invoked at 𝑁3

3.2 Elliptic Curve Cryptography (ECC)

Let 𝑃1 and 𝑃2 be two considered messages, (𝑆𝑘, 𝑘) be secret key and public key, 𝑃 be the coded data of 𝑃1 and 𝑃2, 𝐶 be the cipher text of 𝑃 encrypted with 𝑘, 𝐷𝑒𝑐𝑘(𝐶) or 𝑃 be the plain text of 𝐶

decrypted with 𝑘. We have:
• Encryption: 𝐶 = 𝐸𝑛𝑐𝑘(𝑃) = 𝐸𝑛𝑐𝑘(𝑃1 + 𝑃2) = 𝐸𝑛𝑐𝑘(𝑃1) + 𝐸𝑛𝑐𝑘(𝑃2).
• Decryption: 𝑃 = 𝐷𝑒𝑐𝑆𝑘 (𝐸𝑛𝑐𝑆𝑘 (𝐶)) = 𝐷𝑒𝑐𝑆𝑘 (𝐸𝑛𝑐𝑆𝑘 (𝑃1 + 𝑃2)) = 𝑃1 + 𝑃2.

In this work, we adopt Elliptic Curve Cryptography (ECC) based on the binary finite field 𝐹2 𝑚. Assume each node 𝑛𝑖 in the network has a pair of keys (𝑘𝑖, 𝑘𝑖.𝐵) where 𝐵 is a base parameter of ECC and public to all over the network, 𝑘𝑖 is the private key, and 𝑘𝑖.𝐵 is the public key. With ECC, the encryption of a message 𝑃𝑖 with 𝑘𝑖 is 𝐶𝑖 = 𝐸𝑛𝑐𝑘𝑖 (𝑃) = (𝑟𝑖.𝐵, 𝑃𝑖 + 𝑟𝑖.𝐵.𝑘𝑖), and the decryption of 𝐶𝑖 with 𝑘𝑖 is 𝑃𝑖 = 𝐷𝑒𝑐𝑘𝑖 (𝐶𝑖) = 𝑃𝑖 + 𝑟𝑖.𝐵.𝑘𝑖 − (𝑟𝑖.𝐵).𝑘𝑖, where 𝑟𝑖 is a random number generated by the encryptor. Hence, the addition of two encryption gets 𝐶 = 𝐸𝑛𝑐𝑘𝑖 (𝑃1)+𝐸𝑛𝑐𝑘𝑖 (𝑃2) = (𝑟1.𝐵 + 𝑟2.𝐵, 𝑃1 + 𝑃2 + 𝑟1.𝐵.𝑘𝑖 + 𝑟2.𝐵.𝑘𝑖), and the responsive decryption is 𝐷𝑒𝑐𝑘𝑖 (𝐶) = 𝑃1 + 𝑃2 + 𝑟1.𝐵.𝑘𝑖 + 𝑟2.𝐵.𝑘𝑖 − (𝑟1.𝐵 + 𝑟2.𝐵).𝑘𝑖 = 𝑃1 + 𝑃2.

4. Threat Models

In this paper, both of honest-but-curious attack and malicious attack are taken into a careful consideration and discussed, as they affect seriously to the systems. Observing them well can reduce the risks of leaking the private information of the system for any harmful purpose.

Honest-but-curious attack. They correctly operate the protocol without modifying data. However, they try to learn as much personal information of the other users as possible to satisfy their curiosity. These adversaries do not cause serious consequences, but can leave a back door for the other attacks if they do not preserve well the learned data. In this work, each node may be considered as an honest-but-curious attacker. They can learn the private information from the COPE header as well as infer the path on which the packet moves through. If they are intersecting nodes, they can try on the received packets. In case they are surrounding nodes of the packet’s path, they can try to overhear the packets from that path.

Example 2. The adversary can get the aggregate package, e.g., 𝑃 = 𝑃1 + 𝑃2 + 𝑃3, at the same time it receives another aggregate packet, i.e., 𝑃′ = 𝑃1 + 𝑃2, so it can infer the content of the packet 𝑃3 = 𝑃 − 𝑃′.

Malicious attack. It is much more hazardous than honest-but-curious attack. A malicious adversary tries to intervene as much user data as possible. They not only aim to learn as much personal information as possible, but also to modify data or replay it to achieve the further goals. Since this kind of attack can affect to the user personal information and the systematic accuracy, it is very challenging to be coped with.

Example 3. Let us continue Example 2. After inferring the content of the packet 𝑃3, the adversary can even modify the COPE header of the packet as well as replace the packet 𝑃3 with another packet 𝑃4 by 𝑃” = 𝑃” + 𝑃4, then use 𝑃” to forge 𝑃′, and send 𝑃” to its destination.

5. Security Requirements
To avoid serious consequences of the above security threats, the security requirements need to be guaranteed on the aggregate packet moving through the network.

• Packet payload security. The packet payload cannot be read by any node in the network flow. The packet information should be accessed only by its claimed destination node. To satisfy this requirement, a solution should adopt cryptographic algorithms into the problem. The COPE packets should be encrypted with the public key of the destination node, and are aggregated in a secret way. Specifically, two parts need to be encrypted, that is, packetpayload and fields in the COPE header for coding condition evaluation (see Section 7.1). The solution for this requirement will be presented in further details in Section 8.
• Secure coding condition evaluation. The intersecting nodes only code the packets they receive if the packets satisfy the coding conditions (see Definition 1, Section 8.1) set in every flows. However, this coding condition evaluation process possibly leaks the packet flow information. To avoid the other party to see the evaluation process at the intermediate node, the security solution is needed. In this work, the cryptographic solutions are proposed to secure this coding condition evaluation process. This will be expressed in more details in
  Section 8.
• Packet data integrity evaluation. When a packet arrives at a node in its flow, any intersecting node, receiving the packets to be coded, can modify the packet data during that coding process, or it can keep the packet replayed later on. In order to avoid this problem, a data integrity evaluation is needed. The one-way hash algorithm is adopted to make the authentication to be accurate. In this work, we adopt ECDSA as a valuable candidate for this problem. This solution will be presented in Section 8.
• Cryptography-driven performance optimization. Devices in the wireless network have many restrictions, i.e., they have limited physical resource and performance. Hence it is required to select a lightweight cryptographic algorithm to secure packets and make the protocol of encrypting packets more securely. In this work, the lightweight cryptographic algorithms, i.e., ECC and ECDSA, are adopted to reduce the performance cost, at the same time keep the security complexity of an encryption algorithm. The details will be expressed in Section
  8.

6. SCOPE: A Lighweight Cryptogragphy Solution

SCOPE is come up with the idea of how to combine the crucially common computing features of COPE and ECC, at the same time, to reserve objectives of COPE and secure the data. As mentioned above, COPE and ECC use the same binary operator that is XOR in coding or ciphering the data. COPE uses XOR to code different data (see Section 3.1) to output one coded data. Whereas, ECC is an additive homomorphic encryption so can aggregate different data into a coded data, and cover the coded data in the format of a cipher text (see Section 3.2). Hence, aggregating different pieces of data in secret way using ECC generates an encryption of a coded data. This is the core idea of SCOPE. Let us describe in more detailed of the SCOPE protocol.

Let us see Figure 2. The 2-hop flows of three nodes 𝑁𝑖, 𝑁𝑚, 𝑁𝑗 are considered in the both protocols. In the flow 1, node 𝑁𝑖 sends a packet 𝑃𝑖 to node 𝑁𝑗 through node 𝑁𝑚. Whereas, in the flow 2, node 𝑁𝑗 sends a packet𝑃 𝑗 sent from 𝑁𝑖 through 𝑁𝑚. Hence, 𝑁𝑚 is the intersecting node in either case. 𝑁𝑚 is in charge of checking the coding conditions on the received packets before coding the packets. The Figure 2-a depicts the COPE protocol without encryption. In that, 𝑁𝑚 invokes a XOR operator (denoted as ”+”) over the two received packets, and obtains an aggregate value, that is,

𝑃𝑚 = 𝑃𝑖𝑗 + 𝑃𝑗𝑖.

Figure 2: Protocols: COPE vs SCOPE – a) COPE; b) SCOPE.

Whereas, the Figure 2-b depicts the SCOPE protocol with encryptions. Source node 𝑁𝑖 encrypts 𝑃𝑖𝑗 by 𝑁𝑗’s public key 𝑘𝑗 and obtains an encryption 𝐸𝑛𝑐𝐾𝑗 (𝑃𝑖𝑗). It then propagates this encryption to 𝑁𝑚. In the meantime, 𝑁𝑗 encrypts 𝑃𝑗𝑖 by 𝑁𝑖’s public key 𝑘𝑖 and obtains an encryption 𝐸𝑛𝑐𝑘𝑖 (𝑃𝑗𝑖). Then 𝑁𝑗 sends this encryption to 𝑁𝑚. The intersecting node 𝑁𝑚 aggregates the two received encryptions from 𝑁𝑖 and 𝑁𝑗 by performing the operator Exclusive-OR on the two cipher texts, to receive 𝐶 = 𝐸𝑛𝑐𝑘𝑗 (𝑃𝑖𝑗) + 𝐸𝑛𝑐𝑘𝑖 (𝑃𝑗𝑖) = 𝐸𝑛𝑐(𝑘𝑖, 𝑘𝑗)(𝑃𝑗𝑖 + 𝑃𝑖𝑗) where 𝐶 is the encryption of the coded data of 𝑃𝑖𝑗 and 𝑃𝑗𝑖. Then, 𝑁𝑚 broadcasts 𝐶 to both 𝑁𝑖 and 𝑁𝑗. With flow 1, the destination 𝑁𝑗 again adds its 𝐸𝑛𝑐𝑘𝑗 (𝑃𝑖𝑗) to 𝐶 and obtains 𝐸𝑛𝑐𝑘𝑗 (𝑃𝑖𝑗) + (𝐸𝑛𝑐𝑘𝑗 (𝑃𝑖𝑗) + 𝐸𝑛𝑐𝑘𝑖 (𝑃𝑗𝑖)) = 𝐸𝑛𝑐𝑘𝑖 (𝑃𝑗𝑖). 𝑁𝑗 then decrypts 𝐸𝑛𝑐𝑘𝑖 (𝑃𝑗𝑖) with its private key to achieve the data from 𝑁𝑖 claimed to it, that is, 𝑃𝑗𝑖. The same steps are similarly performed at 𝑁𝑖 on the flow 2.

7. Robust SCOPE Packet

In this section, COPE header format is presented. Then based on COPE header, a SCOPE header format is built up to empower COPE against the honest-but-curious and malicious attacks. More specifically, the key fields of COPE are encrypted using ECC with the public key of the destination node only which is allowed to read the packet data. Additionally, the COPE header has one more hashed field so that SCOPE can evaluate the integrity of the packet.

Figure 3: COPE Header Format.

7.1 COPE Header Format

A COPE header [1] (see Figure 3) is inserted into the header of a packet, placed between the MAC and IP headers. The COPE header has a structure, as follows. A COPE header includes three blocks, that is, coding report, reception report, and ACK report. Coding report contains information of the XOR-ed native packets and their next hop. Reception report contains information of overlearned packets from neighbors including the source, the received last packet from that source, and a bitmap presenting the list of recently received packets from that source. ACK reportcontains the information of received or missed packets which the sending node has, including a neighbor IP, the last ACKed packet from that neighbor and a bit map of ACKed packet.

7.2 SCOPE Packet

Based on the COPE header, in order to meet the security requirements mentioned in Section 5, the fields in the COPE header are encrypted with ECC in SCOPE, in terms of NEXTHOP, SRC_IP, LAST_PKT, Bit Map, NEIGHBOR, LAST_ACK, Ack Map, etc. Hence, all SCOPE nodes work on encryptions only whenever they access fields in the COPE header. SCOPE often access the header to read and compute the sets of neighbor nodes, next hops and previous hops, then used for evaluating the coding conditions. The coding conditions are defined in Definition 1, Section 8.1. For a reference to the coding condition evaluation, see Definition 3, Section 8.1.

Figure 4: SCOPE Packet Format.

Moreover, to avoid the packets leaking the private information to COPE nodes, SCOPE encrypts the payload then sends it through the neighbors. If the packet arrives at an intersecting node, the intersecting node will code the received packets, then broadcast the outcome packet to the network..

7.3 Robust SCOPE Packet

SCOPE header as in Section 7.2 can protect the packet information against the honest-but-curious attack, since no node, except the destination node owning the public key used for encrypting the packet payload, can read the packet. Thus, the content of the packet is secret, and the honest-butcurious or malicious node even when it is an intersecting node still cannot read the packet content. An honest-but-curious adversary can release the packet after learning it, but a malicious adversary can harm the packet sequentially by dishonestly coding the encrypted packets with another fake packets just to break the protocol, or by modifying the packet payload.

Hence in this section, the SCOPE header is modified to be against malicious attack. Particularly, the payload of SCOPE is separated into the two parts, that is, the hash for packet authentication and the coded or encrypted payload

Figure 5: Robust SCOPE Packet Format.

In the packet format, the hash of payload and the hash of SCOPE header both are generated using ECDSA [3]. The coded packet signature is made by the source node with its private key, and evaluated by the destination node with the public key of the source node. This signature is aimed to support the destination node to assess the packet if that packet is still original, or modified on the way to it. Hence, the integrity of packets can be guaranteed against the packet modification. Whereas, the signature of SCOPE header is made by the sending node with its private key. This signature is evaluated by the neighbor nodes using the public key of the sending node. The evaluation of this signature is aimed to support the receiving node in guaranteeing the received packets exactly from its neighbor.

8. Robust SCOPE Data Coding

8.1 Secure Coding Condition

Let us see Figure 2-b, node 𝑁𝑖 sends a packet 𝑃𝑖𝑗 to its target, that is, 𝑁𝑗, through 𝑁𝑚. To make 𝑃𝑖𝑗 able to reach 𝑁𝑗, the work at 𝑁𝑚 is crucial as it decides to forward the packet to 𝑁𝑗. Forwarding the packet is not simply receiving and sending the received packet 𝑃𝑖𝑗 to the network. It does not also mean that packets move through the intersecting nodes to reach their destination, not all of intermediates will code the by-passed packets and propagate the result packets towards. As the objectives of coding protocol, to reduce the bandwidth cost, 𝑁𝑚 needs to aggregate (i.e., code) several packets together and forwards only the aggregate packet. In order to support 𝑁𝑚 in deciding the 𝑃𝑖𝑗 propagation, the coding conditions are built up for 𝑁𝑚 to be evaluated. The necessary parameters for the coding condition evaluation are retrieved from the header of COPE packet. Only the packets satisfying the coding conditions will be aggregated into their suitable packet then sent towards to their destination. More specifically:

Definition 1. Coding condition. Let 𝐹𝑖 and 𝐹𝑗 be two flows of packets crossing at node 𝑁𝑚, i.e., 𝐹𝑖 ∩ 𝐹𝑗 = 𝑁𝑚. 𝑁𝑚 codes packets received from 𝐹𝑖 and 𝐹𝑗 in case the next hops of the packet at 𝑁𝑚 on flow 𝐹𝑖 (or flow 𝐹𝑗) are the previous hops of the packet at node 𝑁𝑚 on flow 𝐹𝑗 (or flow 𝐹𝑖), or are the neighbors of that previous hop. More formally:

where
• 𝐶(𝑁𝑚, 𝐹𝑖, 𝐹𝑗) is the coding condition.
• 𝑁𝑚 is the intersecting node of two flows 𝐹𝑖 and 𝐹𝑗.
• 𝑁𝐻[𝑁𝑚, 𝐹𝑖] is the set of next hops of node 𝑁𝑚 in flow 𝐹𝑖.
• 𝑃𝐻[𝑁𝑚, 𝐹𝑖] or 𝑋𝑖 is the set of previous hops of node 𝑁𝑚 in flow 𝐹𝑖.
• 𝑁𝐵𝑋𝑖 is the set of all neighbors of nodes in 𝑋𝑖 in flow 𝐹𝑖.

Example 4. Let us see Figure 1-b. It is noted that in case of COPE, the set of neighbor nodes and the set of previous nodes contain only one element. It is assumed that there are two flows of packets, that is, 𝐹1 and 𝐹2 (𝐹1 ∶ 𝑁1 → 𝑁2 → 𝑁3, and 𝐹2 ∶ 𝑁1 → 𝑁2 → 𝑁3). 𝑁2 is clearly the intersecting node of the two flows, so it is also the intermediate node where the coding can cause. Hence, the set of previous hops of 𝑁2 on 𝐹1 is 𝑃𝐻[𝑁2, 𝐹1] = {𝑁1}, whereas the set of next hops of 𝑁2 on 𝐹1 is 𝑁𝐻[𝑁2, 𝐹1] = {𝑁3}. In the meanwhile, the set of previous hops of 𝑁2 on 𝐹2 is 𝑃𝐻[𝑁2, 𝐹2] = 𝑁3, whereas the set of next hops of 𝑁2 on 𝐹2 is 𝑁𝐻[𝑁2, 𝐹2] = {𝑁1}. For each node

in sets of previous nodes of 𝑁2 in 𝐹1 and 𝐹2, 𝑁1’s neighbors is 𝑁𝐵𝑁1 = {𝑁2}, and the set of 𝑁3’s neighbors is 𝑁𝐵𝑁3 = {𝑁2}. Let us check the coding conditions in Definition 1, we see that the case 𝐶(𝑁2, 𝐹1, 𝐹2) = 𝑡𝑟𝑢𝑒 happens.

The above conditions are readable and stored in the header of each node. However, the coding condition evaluation process is done by the intersecting node (i.e., the intermediate node) 𝑁𝑚. Node 𝑁𝑚 also needs the information from its surrounding nodes, especially the nodes are the sender and the recipient of the packets through it, as in Figure 2-b, that is, 𝑁𝑖 and 𝑁𝑗. Hence, in case that 𝑁𝑚 is not an honest and benign node, this assessment process can leak the packet flow information to the intermediate, and cause a serious consequence to the data security and privacy as presented in Section 5. This process thus should be done in a secure way. In this work, we adopt the homomorphic encryption as an effective way to secure this process, particularly, ECC is used for securing data. More specifically, all information owned by 𝑁𝑚 are encrypted with a public key 𝐾𝑚. All data at 𝑁𝑖 and 𝑁𝑗 are respectively encrypted with the public keys of 𝑁𝑖 and 𝑁𝑗, that is, 𝐾𝑖and 𝐾𝑗. It is noted that the atomic data which is encrypted is the ID of node’s neighbors or previous hops or next hops. The encrypted atomic data is specified as in Definition 2.

Definition 2. Atomic Data Cipher. Let 𝐾2 be the public key of node 𝑁2. Let 𝐷2 is the atomic data to be encrypted with 𝐾2. Therefore, 𝐸𝑛𝑐𝐾2 (𝐷2) is the encryption (i.e., cipher) of the atomic data 𝐷2 encrypted with the key 𝐾2 of node 𝑁2.

Example 5. Let us continue Example 4. Let 𝐾𝑚 be the public key of 𝑁𝑚, 𝑁𝑖 be the previous hop of 𝑁𝑚 on flow 𝐹1. Hence, 𝐸𝑛𝑐𝐾𝑚 (𝑁𝑖) is the encryption of 𝑁𝑖’s ID. It is noted that 𝑁𝑖 is also considered as its own ID.

Each of nodes in the network keeps one previous hop list, one next hop list, and one neighbor list. Hence, for evaluating the coding condition, the intersecting node, i.e., 𝑁𝑚, exploits its previous hop list and next hop list, at the same time, requests each of its previous nodes for sending it their neighbor list. These lists are also the input parameters of the coding evaluation process. The coding condition parameters all are lists of atomic data ciphers, and defined in Definition 2. The lists of encryption defined in Definition 3 are also stored in the SCOPE header instead of the plain text as in COPE header.

Definition 3. Coding Condition Parameter Cipher. Let 𝑁𝑡, 𝐹𝑖 be respectively the considered node and the consider flow of data. Let 𝑁𝐻[𝑁𝑡, 𝐹𝑖], 𝑃𝑁[𝑁𝑡, 𝐹𝑖], 𝑁𝐵𝑃𝑁[𝑁𝑡, 𝐹𝑖] respectively 𝑁𝑡’s previous hop list, 𝑁𝑡’s next hop list and the neighbor node lists of 𝑁𝑡’s previous nodes. From Definition 2 of atomic data cipher, for each element of the lists 𝑁𝐻[𝑁𝑡, 𝐹𝑖], 𝑃𝑁[𝑁𝑡, 𝐹𝑖], 𝑁𝐵𝑃𝑁[𝑁𝑡, 𝐹𝑖], the respective cipher of the lists are denoted as 𝐸𝑛𝑐𝐾𝑡 (𝑁𝐻[𝑁𝑖, 𝐹𝑖])), 𝐸𝑛𝑐𝐾𝑡 (𝑃𝑁[𝑁𝑡, 𝐹𝑖]), 𝐸𝑁𝐵𝑃𝑁 [𝑁𝑡, 𝐹𝑖] and defined as follows:

Example 6. Let us continue Example 4 and 5. Let 𝑁2, 𝐾2 be respectively the considered node and its own public key. Let 𝐹1 be the considered flow. 𝑁2’s lists of next hops, previous hops, and its previous nodes’ neighbor node lists on flow 𝐹1 as follows: 𝐸𝑛𝑐𝐾2 (𝑁𝐻[𝑁2, 𝐹1]) = 𝐸𝑛𝑐𝐾2 (𝑁(3, 1)); 𝐸𝑛𝑐𝐾2 (𝑃𝐻[𝑁2, 𝐹1]) = 𝐸𝑛𝑐𝐾2 (𝑁1); 𝐸𝑛𝑐𝐾2 (𝑁𝐵𝑃𝐻[𝑁2, 𝐹1]) = 𝐸𝑛𝑐𝐾2 (𝑁1), 𝐸𝑛𝑐𝐾2 (𝑁3) as 𝑁2 on 𝐹1 has two neighbors, that is, 𝑁1 and 𝑁3.

The coding condition evaluation is processed at the intersecting node but it needs a collaboration among multiple parties (i.e., the intersecting node, and its previous hop and next hop on the same flow) to support this evaluation process. For example, as in Figure 1-b, the coding condition evaluation is done by 𝑁𝑚 but it needs a collaboration among 𝑁𝑖, 𝑁𝑚 and 𝑁𝑗. However, as presented in Section 5, to prevent the risk of information violation, this collaboration needs to be processed secretly to avoid leaking a nod’s private information to the others. In this situation, the information of 𝑁𝑖 and 𝑁𝑗 must be kept against the reading of 𝑁𝑚. Moreover, the nature of each coding condition evaluation is a comparison among elements of the two lists. Hence, to meet the security requirement in Section 5, this comparison is securely processed among encryptions of elements of the lists. For example, as in Definition 1, one of coding conditions is the comparison between the lists 𝑁𝐻[𝑁𝑚, 𝐹𝑖] and 𝑃𝐻[𝑁𝑚, 𝐹𝑗], whereas, the comparison between 𝑁𝐻[𝑁𝑚, 𝐹𝑖] and 𝑁𝐵𝑃𝐻[𝑁𝑚, 𝐹𝑖] is a series of comparisons between the list 𝑁𝐻[𝑁𝑚, 𝐹𝑖] and each of lists in 𝑁𝐵𝑃𝐻[𝑁𝑚, 𝐹𝑖] since 𝑁𝐵𝑃𝐻[𝑁𝑚, 𝐹𝑖] contains many lists, each of lists contains the neighbor nodes relating to each of 𝑁𝑚’s previous nodes. As in Definition 3, the coding conditions contain the lists of encrypted elements. The comparison operators used for assessing the coding conditions are executed on the lists of encryptions. Thus, let us present one secure comparison between 𝑁𝐻[𝑁𝑚, 𝐹𝑖] and 𝑃𝐻[𝑁𝑚, 𝐹𝑗] done at 𝑁𝑚. The other comparisons in the coding conditions are similarly performed.

Let us consider the two original lists of 𝑁𝐻[𝑁𝑚, 𝐹𝑖] and 𝑃𝐻[𝑁𝑚, 𝐹𝑗] as follows:

key, that is 𝑁𝑗’s public key (i.e., 𝐾𝑗), to obtain 𝐸𝑛𝑐𝐾𝑖 (𝑁𝐻[𝑁𝑚, 𝐹𝑖]) = {𝐸𝑛𝑐𝐾𝑖 (𝑁(0,𝐹𝑖)), 𝐸𝑛𝑐𝐾𝑖 (𝑁(1,𝐹𝑖)), ⋯ , 𝐸𝑛𝑐𝐾𝑖 (𝑁(𝑛,𝐹𝑖))}. In the meanwhile, 𝑁𝑗 is in charge of generating the encryption of 𝑃𝐻[𝑁𝑚, 𝐹𝑗] with its destination node’s public key, that is 𝑁𝑖’s public key (i.e., 𝐾𝑖), to obtain 𝐸𝑛𝑐𝐾𝑗 (𝑃𝐻[𝑁𝑚, 𝐹𝑖]) = {𝐸𝑛𝑐𝐾𝑗 (𝑁(𝑛+1,𝐹𝑗)), 𝐸𝑛𝑐𝐾𝑗 (𝑁(𝑛+2,𝐹𝑗)), ⋯ , 𝐸𝑛𝑐𝐾𝑗 (𝑁(𝑛+𝑚,𝐹𝑗))}. After generating the encryption lists, 𝑁𝑖 sends the encryptions to 𝑁𝑚, while 𝑁𝑗 sends the encryptions to 𝑁𝑚. Hence, 𝑁𝑚 can help transfer the received encryption lists to their destination nodes, that is, 𝑁𝑚 sends 𝐸𝑛𝑐𝐾𝑖 (𝑁𝐻[𝑁𝑚, 𝐹𝑖]) to 𝑁𝑗, and forwards 𝐸𝑛𝑐𝐾𝑗 (𝑃𝐻[𝑁𝑚, 𝐹𝑖]) to 𝑁𝑖. At 𝑁𝑖, 𝑁𝑖 continues to uses its public key, i.e., 𝐾𝑖, to encrypt the encryption list from 𝑁𝑚, to obtain a twice-encrypted list, that is, 𝐸𝑛𝑐(𝐾𝑖,𝐾𝑗)(𝑃𝐻[𝑁𝑚, 𝐹𝑖]) = {𝐸𝑛𝑐(𝐾𝑖,𝐾𝑗)(𝑁(𝑛+1,𝐹𝑗)), 𝐸𝑛𝑐(𝐾𝑖,𝐾𝑗)(𝑁(𝑛+2,𝐹𝑗)), ⋯ , 𝐸𝑛𝑐(𝐾𝑖,𝐾𝑗)(𝑁(𝑛+𝑚,𝐹𝑗))}. Similarly, 𝑁𝑗 again encrypts the received list of encryptions with its public key, i.e., 𝐾𝑗, and obtains the twice-encrypted list, that is, 𝐸𝑛𝑐(𝐾𝑗,𝐾𝑖)(𝑁𝐻[𝑁𝑚, 𝐹𝑖]) = {𝐸𝑛𝑐(𝐾𝑗,𝐾𝑖)(𝑁(0,𝐹𝑖)), 𝐸𝑛𝑐(𝐾𝑗,𝐾𝑖)(𝑁(1,𝐹𝑖)), ⋯ , 𝐸𝑛𝑐(𝐾𝑗,𝐾𝑖)(𝑁(𝑛,𝐹𝑖))}. After that, 𝑁𝑖 and 𝑁𝑗 transfer the twice-encrypted lists to 𝑁𝑚. 𝑁𝑚 then performs the function 𝐸𝑞𝑢𝑎𝑙𝐿𝑖𝑠𝑡() as in Algorithm 1. 𝐸𝑞𝑢𝑎𝑙𝐿𝑖𝑠𝑡() evaluates if two lists are equal to each other. It inputs two lists, that is, 𝐸𝑛𝑐(𝐾𝑗,𝐾𝑖)(𝑁𝐻[𝑁𝑚, 𝐹𝑖]) and 𝐸𝑛𝑐(𝐾𝑖,𝐾𝑗)(𝑃𝐻[𝑁𝑚, 𝐹𝑖]), and returns a boolean result, that is, ′𝑡𝑟𝑢𝑒′ or ′𝑓𝑎𝑙𝑠𝑒′. ′𝑡𝑟𝑢𝑒′ is returned as the two encryption lists are equal, and ′𝑓𝑎𝑙𝑠𝑒′ as the two encryption lists are unequal.

More specifically, in the Algorithm 1, 𝑁𝑚 traverses the two lists 𝐸𝑛𝑐(𝐾𝑗,𝐾𝑖)(𝑁𝐻[𝑁𝑚, 𝐹𝑖]) and 𝐸𝑛𝑐(𝐾𝑖,𝐾𝑗)(𝑃𝐻[𝑁𝑚, 𝐹𝑖]) (lines 2,3) to evaluate the equality of elements of two lists by subtract-

ing (or Exclusive-ORing) each element 𝑥 of 𝐸𝑛𝑐(𝐾𝑖,𝐾𝑗)(𝑃𝐻[𝑁𝑚, 𝐹𝑖]) by each element 𝑦 of 𝐸𝑛𝑐(𝐾𝑗,𝐾𝑖)(𝑁𝐻[𝑁𝑚, 𝐹𝑖]) (line 4). Let 𝑐𝑜𝑢𝑛𝑡 be a temporary integer. If the subtraction is equal to an encryption of 0 generated with the public key of 𝑁𝑖 and 𝑁𝑗, i.e., 𝐾𝑖 and 𝐾𝑗, that means 𝑥 is equal to 𝑦, 𝑐𝑜𝑢𝑛𝑡 is increased by 1 (line 5). Then, if 𝑐𝑜𝑢𝑛𝑡 is equal to the sizes of two lists, that is, 𝑠𝑖𝑧𝑒𝑁𝐻 and 𝑠𝑖𝑧𝑒𝑃𝐻 (lines 9, 10, 11), the functions return ′𝑡𝑟𝑢𝑒′ (line 12), it means two lists are equal, otherwise false is returned (line 14). In case the two lists are equal, it also indicates that the coding condition is met. Sequentially, the other coding condition can be continued to be evaluated.

8.2 Secure Payload Coding

The fact that COPE header are protected against attacks of observing the flow of packet and intervening the packets’ routines is protecting coding conditions and operations on them as presented in Section 8.1. Even though that is a meaningful and important security strategy, securing data payload also plays a substantial role since the payload contains several sensitive information of users.
Especially, the coding is done at the intersecting node. As discussed in Section 4, the intersecting node can be an adversary, and the plain data can reveal the personal information to the intersecting node. Hence, the payload should be secured. In this work, ECC algorithm is used to encrypt data into the cipher. This solution makes the intersecting node unable to read the data but at the same time still work on the encryption only. Hence, the sending node needs to encrypt the data before propagating the encryption to the intersecting node.

Definition 4. Coded Payload Cipher. Let 𝐾0, 𝐾1, ⋯ , 𝐾𝑛 be public keys of nodes 𝑁0, 𝑁1, ⋯ , 𝑁𝑛. Let 𝐸𝑛𝑐𝐾0 (𝑃0), 𝐸𝑛𝑐𝐾1 (𝑃1), ⋯ , 𝐸𝑛𝑐𝐾𝑛 (𝑃𝑛) be the 𝑛 payload encryptions of packets: 𝑃0 with 𝐾0, 𝑃1

with 𝐾1, ⋯, 𝑃𝑛 with 𝐾𝑛. The coded payload cipher made at 𝑁𝑚 is formulated as follows:

where 𝑟0, 𝑟1, ⋯ , 𝑟𝑛 are random numbers generated at nodes creating the partial encryptions.

Example 7. Let us continue Example 6. It is assumed that 𝑁𝑖 wants to send the packet 𝑃𝑖𝑗 to 𝑁𝑗 through 𝑁𝑚 on flow 𝐹1, so it encrypts the payload of 𝑃𝑖𝑗 into 𝐸𝑛𝑐𝐾𝑗 (𝑃𝑖𝑗) and forwards this encryption to 𝑁𝑚. In the meanwhile, 𝑁𝑗 wants to send the packet 𝑃𝑗𝑖 to 𝑁𝑖 through 𝑁𝑚 on flow 𝐹2, so it encrypts the payload of 𝑃𝑗𝑖 into 𝐸𝑛𝑐𝐾𝑖 (𝑃𝑗𝑖) and forwards this encryption to 𝑁𝑚. At node 𝑁𝑚, after evaluating
the coding condition as in Example 4, 𝑁𝑚 code the two encryptions 𝐸𝑛𝑐𝐾𝑗 (𝑃𝑖𝑗) and 𝐸𝑛𝑐𝐾𝑖 (𝑃𝑗𝑖) by aggregating them, and get 𝐸𝑛𝑐(𝐾𝑖,𝐾𝑗)(𝑃𝑖𝑗 + 𝑃𝑗𝑖) = (𝑟𝑖.𝐵 + 𝑟𝑗.𝐵, (𝑃𝑖𝑗 + 𝑃𝑗𝑖) + (𝑟1.𝐵.𝐾1 + 𝑟2.𝐵.𝐾2)) as the coded payload cipher.

Receiving packets from different neighbor nodes, after evaluating the coding condition, 𝑁𝑚 detaches the encrypted payloads of all packets and code them. Then 𝑁𝑚 puts them into a new packet. Then, 𝑁𝑚 propagates it towards the network. As the receiving node gets the coded packet from 𝑁𝑚, it can assess the coded payload cipher, then decodes and decrypts the cipher to obtain the data. This process is concerned as the coded payload assessment. The decoded payload is defined as in

Definition 5.

Definition 5. Decoded Payload. Let 𝑁𝑛 be the destination node receiving the encrypted coded payload as defined in Definition 4. Let 𝐾0, 𝐾1, ⋯ , 𝐾𝑛−1 be public keys of 𝑁𝑛’s neighbor nodes 𝑁0, 𝑁1, ⋯ , 𝑁𝑛−1. Let 𝐸𝑛𝑐(𝐾0,𝐾1,…,𝐾𝑛) Σ𝑛 𝑖=0(𝑃𝑖) = (Σ𝑛 𝑖=0(𝑟𝑖.𝐵), Σ𝑛 𝑖=0(𝑃𝑖 + 𝑟𝑖.𝐵.𝐾𝑖)) be the coded payload cipher of packets from 𝑁0, 𝑁1, ⋯ , 𝑁𝑛 with the random numbers 𝑟0, 𝑟1, ⋯ , 𝑟𝑛 generated by nodes creating the partial encryptions. More formally, the decoded payload by 𝑁𝑛, that is 𝐸𝑛𝑐𝐾𝑛 (𝑃𝑛), is defined as follows:

Example 8.

Let us continue Example 7. 𝑁𝑗 receives the coded payload cipher for it, that is, 𝐸𝑛𝑐(𝐾𝑖, 𝐾𝑗)(𝑃𝑖𝑗 + 𝑃𝑗𝑖) = (𝑟𝑖.𝐵 + 𝑟𝑗.𝐵, (𝑃𝑖𝑗 + 𝑃𝑗𝑖) + (𝑟𝑖.𝐵.𝐾𝑖 + 𝑟𝑗.𝐵.𝐾𝑗)). 𝑁𝑗 still keeps the coded

payload cipher of the packet it wants to send to 𝑁𝑖, that is, 𝐸𝑛𝑐𝐾𝑖 (𝑃𝑗𝑖) = (𝑟𝑖.𝐵, 𝑃𝑗𝑖 + 𝑟𝑖.𝐵.𝐾𝑖) where 𝑟𝑖 is a random number generated by 𝑁𝑗. Hence, the decoded payload is 𝐸𝑛𝑐𝐾𝑗 (𝑃𝑖𝑗) = 𝐸𝑛𝑐(𝐾𝑖,𝐾𝑗)(𝑃𝑖𝑗 +𝑃𝑗𝑖)+𝐸𝑛𝑐𝐾𝑖 (𝑃𝑗𝑖) = (𝑟𝑖.𝐵+𝑟𝑗.𝐵, (𝑃𝑖𝑗 +𝑃𝑗𝑖)+(𝑟𝑖.𝐵.𝐾𝑖 +𝑟𝑗.𝐵.𝐾𝑗))+(𝑟𝑖.𝐵, 𝑃𝑗𝑖 +𝑟𝑖.𝐵.𝐾𝑖) = ((𝑟𝑖.𝐵 + 𝑟𝑗.𝐵 + 𝑟𝑖.𝐵), ((𝑃𝑖𝑗 + 𝑃𝑗𝑖 + (𝑟𝑖.𝐵.𝐾𝑖 + 𝑟𝑗.𝐵.𝐾𝑗 + 𝑃𝑗𝑖 + 𝑟𝑖.𝐵.𝐾𝑖)) = (𝑟𝑗.𝐵, 𝑃𝑖𝑗 + 𝑟𝑗.𝐵.𝐾𝑗). Then, the decryption is executed at 𝑁𝑗 with the private key of 𝑁𝑗 (i.e., 𝐾𝑗), to get the data needed for 𝑁𝑗, i.e., 𝐷𝑒𝑐𝐾𝑗 (𝐸𝑛𝑐𝐾𝑗 (𝑃𝑖𝑗)) = (𝑟𝑗.𝐵).𝐾𝑗 + 𝑃𝑖𝑗 + 𝑟𝑗.𝐵.𝐾𝑗 = 𝑃𝑖𝑗.

8.3 Private Identification

In order to guarantee that the packet is not able to be modified by the malicious adversaries, in this work we do not focus on how to identify the impersonating nodes in the network. Instead, a secure protocol secretly analyzes and reasons if all changes made by a node on a packet are legal. To serve that goal, we ensure that the node can exactly authenticate its collaborative nodes that may be a contact or a source node. More particularly, (1) Contact Signature is used for the receiving node to evaluate a sending node to be exactly its neighbor. This avoids any node which does not meet the connecting conditions before making any transactions with the receiving node. In case the malicious nodes attempt to change the data of the SCOPE header while the packet is coming to the receiving node, the neighbor can be aware of that change based on the contact signature; (2) Source Signature is used for the destination node to check if the received packet is exactly received from the node claimed to be its source node, and the packet content has not been modified during the way to the destination node. This avoids the destination node to collect a fake or amended packet not claimed to be sent to it. Both signatures are generated by the ECDSA algorithm. ECDSA is a digital signature algorithm using Elliptic Curve Cryptography, and behind it, SHA-2 [13] is applied for creating the signature. To be more clearly, definitions and protocols of these identifications will be presented in detailed.

Definition 6. Contact Signature. Let 𝐾𝑛 be the private key of the sending node. Let 𝑆𝑖𝑔𝑛𝐸𝑛𝑐𝑜𝑑𝑒, 𝑆𝑖𝑔𝑛𝑅𝑒𝑝𝑜𝑟𝑡, 𝑆𝑖𝑔𝑛𝐴𝑐𝑘 be respectively the signature set of 𝐸𝑛𝑐𝑜𝑑𝑒𝑑_𝑁𝑢𝑚, the signature set of 𝑅𝑒𝑝𝑜𝑟𝑡_𝑁𝑢𝑚, and the signature set of 𝐴𝑐𝑘_𝑁𝑢𝑚 in the COPE header format. The signature of SCOPE header, denoted as 𝑆𝑖𝑔𝑛𝑆𝐶𝑂𝑃𝐸 at node 𝑁𝑛 is defined as follows: where 𝐸𝑖, 𝑅𝑖, 𝐴𝑖 (with 𝑖 = 0, 1, ⋯ ) are elements of the parts in SCOPE header; the pairs of (𝑟𝑥, 𝑠𝑥) are signatures of the SCOPE header’s fields by using ECDSA with the field order in the part 𝑥.

It is reminded that the fields of SCOPE header are encryptions made by ECC as in Section 8.1. Hence, the hashed values in the SCOPE header signature are made from the encryptions of SCOPE header.

Example 9. It is assumed that 𝑁𝑖 sends a packet to 𝑁𝑚. The SCOPE signature of 𝑁𝑖 is generated with the private key of 𝑁𝑖 and achieve the SCOPE signature as follows: 𝑆𝑖𝑔𝑛𝑆𝐶𝑂𝑃𝐸𝐾𝑛 = {{{(𝑟𝑃𝐾𝑇_𝐼𝐷1, 𝑠𝑃𝐾𝑇_𝐼𝐷1)𝐾𝑛 , (𝑟𝑁𝐸𝑋𝑇𝐻𝑂𝑃𝐸1 , 𝑠𝑁𝐸𝑋𝑇𝐻𝑂𝑃𝐸1 )𝐾𝑛 }, ⋯}, {{(𝑟𝑆𝑅𝐶_𝐼𝑃1 , 𝑠𝑆𝑅𝐶_𝐼𝑃1 )𝐾𝑛 ,

(𝑟𝐿𝐴𝑆𝑇_𝑃𝐾𝑇1 , 𝑠𝐿𝐴𝑆𝑇_𝑃𝐾𝑇1 )𝐾𝑛 , (𝑟𝐵𝐼𝑇𝑀𝐴𝑃1 , 𝑠𝐵𝐼𝑇𝑀𝐴𝑃1 )𝐾𝑛 }, ⋯}, {(𝑟𝑆𝐸𝑄_𝑁𝑈𝑀𝐵𝐸𝑅, 𝑠𝑆𝐸𝑄_𝑁𝑈𝑀𝐵𝐸𝑅)𝐾𝑛 )
{{(𝑟𝑁𝐸𝐼𝐺𝐻𝐵𝑂𝑅1 , 𝑠𝑁𝐸𝐼𝐺𝐻𝐵𝑂𝑅1 )𝐾𝑛 ), (𝑟𝐿𝐴𝑆𝑇_𝐴𝐶𝐾1 , 𝑠𝐿𝐴𝑆𝑇_𝐴𝐶𝐾1 )𝐾𝑛 ), (𝑟𝐴𝐶𝐾_𝑀𝐴𝑃1 , 𝑠𝐴𝐶𝐾_𝑀𝐴𝑃1 )𝐾𝑛 )}, ⋯}}.

Since the SCOPE header is very essential in computing the key sets of next hops and previous hops which are subsequently used for evaluating the coding conditions at the intersecting nodes, node 𝑁𝑖 first has to sign the packet before it transfers a coded or native packet to its neighbors as an warranty of the packet’s integrity. 𝑁𝑖 makes signatures for each value in the SCOPE header using ECDSA. After that, 𝑁𝑖 sends the signed packet to its neighbors. The receiving neighbor needs to evaluate if the integrity of the received packet is still withheld.

Algorithm 2 describes the procedure 𝑒𝑣𝑎𝑙𝑢𝑎𝑡𝑒𝐶𝑜𝑛𝑡𝑎𝑐𝑡() in evaluating the SCOPE header signature. From the received packet, the node reads the SCOPE header to get the encryptions of necessary fields, stored in the set parameters 𝐸𝑛𝑐𝐸𝑛𝑐𝑜𝑑𝑒, 𝐸𝑛𝑐𝑅𝑒𝑝𝑜𝑟𝑡, 𝐸𝑛𝑐𝐴𝑐𝑘, at the same time, gets the hashed values from the SCOPE header signature, stored in the set parameters 𝑆𝑖𝑔𝑛𝐸𝑛𝑐𝑜𝑑𝑒, 𝑆𝑖𝑔𝑛𝑅𝑒𝑝𝑜𝑟𝑡, 𝑆𝑖𝑔𝑛𝐴𝑐𝑘. All are the inputted arguments of 𝑒𝑣𝑎𝑙𝑢𝑎𝑡𝑒𝐶𝑜𝑛𝑡𝑎𝑐𝑡(). The function returns a Boolean value ′𝑡𝑟𝑢𝑒′ or ′𝑓𝑎𝑙𝑠𝑒′ to prove if the sending node is truly the neighbor of the receiving node. If the value ′𝑡𝑟𝑢𝑒′ returns, the sending node is the neighbor claimed to send the packet. Additionally, the packet is still not modified on the way to the receiving node. Algorithm 2 iteratively traverses the two sets 𝐸𝑛𝑐𝐸𝑛𝑐𝑜𝑑𝑒 and 𝑆𝑖𝑔𝑛𝐸𝑛𝑐𝑜𝑑𝑒 (line 1). For each element 𝑒 of 𝐸𝑛𝑐𝐸𝑛𝑐𝑜𝑑𝑒 and each element 𝑓 of 𝑆𝑖𝑔𝑛𝐸𝑛𝑐𝑜𝑑𝑒, the Algorithm 2 hashes e using ECDSA with the

receiving node public key and creates a signature of it, that is, 𝐻𝑎𝑠ℎ𝐸𝐸 (line 2). Then, 𝐻𝑎𝑠ℎ𝐸𝐸 is compared with 𝑓 (line 3). If they are inequivalent, the Algorithm 2 returns the value ′𝑓𝑎𝑙𝑠𝑒′ (line 4). Otherwise, the loop is continued until all elements in 𝐸𝑛𝑐𝐸𝑛𝑐𝑜𝑑𝑒 and 𝑆𝑖𝑔𝑛𝐸𝑛𝑐𝑜𝑑𝑒 are completely traversed. Consequently, the Algorithm 2 does the same steps with the two sets 𝐸𝑛𝑐𝑅𝑒𝑝𝑜𝑟𝑡 and 𝑆𝑖𝑔𝑛𝑅𝑒𝑝𝑜𝑟𝑡 (lines 7-12), then with the two sets, 𝐸𝑛𝑐𝐴𝑐𝑘 and 𝑆𝑖𝑔𝑛𝐴𝑐𝑘 (lines 13-18).

The contact identification aims to prevent any misprocess happening because the packet can be modified when moving to the receiving node. However, it cannot prove the integrity of the payload if any harmful changes come up. Thus, SCOPE is intensified in preventing the destination node to work on the masqueraded packet or the poisonous packet. In this work, the payload after encrypted is sequentially signed with the private key of the source node by using ECDSA. Hence, only the destination node can read the packet payload and authenticate with its private key.

Definition 7. Source Identification. Let 𝐾𝑑 be the private key of the source node used for generating the signatures. The signature of the payload is formulated as follows:

𝑆𝑖𝑔𝑛𝑃𝑎𝑦𝑙𝑜𝑎𝑑𝐾𝑑 = (𝑟𝑚0 , 𝑠𝑚0 )𝐾𝑑 , (𝑟𝑚1 , 𝑠𝑚1 )𝐾𝑑 , ⋯ (2)

where 𝑚0, 𝑚1, ⋯ are the segments of the payload, the pairs of (𝑟𝑥, 𝑠𝑥) are the ECDSA signatures.

Since the ECDSA has a restricted number of bytes to be the input data as it still uses a hash function underlying, say the SHA-2 algorithm, so the payload is divided into multiple data segments. All of them are iteratively hashed then generated the signatures based on those hashed values, and outputs a set of hash values. Algorithm 3 describes a function namely 𝑒𝑣𝑎𝑙𝑢𝑎𝑡𝑒𝑃𝑎𝑦𝑙𝑜𝑎𝑑() that is executed for this purpose. The function return a Boolean value w.r.t. the input data. There are two input data, that is, the set of hash values of payload segments 𝑆𝑖𝑔𝑛𝑃𝑎𝑦𝑙𝑜𝑎𝑑, and the set of encryptions of payload segments 𝐶𝑜𝑑𝑒𝑑𝑃𝑎𝑐𝑘𝑒𝑡. Algorithm 3 traverses the two sets, 𝑆𝑖𝑔𝑛𝑃𝑎𝑦𝑙𝑜𝑎𝑑
and 𝐶𝑜𝑑𝑒𝑑𝑃𝑎𝑐𝑘𝑒𝑡 (line 1). For each element 𝑒 of 𝐶𝑜𝑑𝑒𝑑𝑃𝑎𝑐𝑘𝑒𝑡, Algorithm 3 computes the hash value of 𝑒, that is, 𝐻𝑎𝑠ℎ𝑃𝑀 using ECDSA (line 2). If the corresponding signature 𝑠 is unequal to 𝐻𝑎𝑠ℎ𝑃𝑀, the functions stops and returns the Boolean value ′𝑓𝑎𝑙𝑠𝑒′. It implies that the payload verification fails. Otherwise, the loop continues until all signatures are evaluated to be true, then the function returns the Boolean value ′𝑡𝑟𝑢𝑒′.

9. Experiment

In this work, to prove for effectiveness and efficiency of the proposed secure protocol, experiments on the different amounts of nodes and different key sizes of ECC encryption are done. These

Figure 6: SCOPE scenarios.

experiments are operated on a PC owning the physical resources in terms of CPU 1.8GHz Intel Duo-Core, RAM 4GB, HDD 16GB.

Scenarios and Data. To assess the computing performance of SCOPE, we make a diversity of experiments on different parameters. Particularly, we create four SCOPE scenarios (as in Figures 1, 6-a, 6-b, 6-c), and change the key sizes of additive homomorphic ECC algorithm. Each calculated value in the experiments is the average of 20 times running the same experiments.

Secure aggregation and evaluation time overload. Figures 1 and 6 describes four scenarios, and table 1 presents the number of flows w.r.t. the scenarios. Figure 1 involves 3 nodes and 2 flows. Figure 6-a involves 5 nodes and 4 flows. Figure 6-b involves 7 nodes and 6 flows. Figure 6-c involves 9 nodes and 2 flows. To evaluate the computing performance of SCOPE applied with ECC encryption algorithms, the selected ECC key sizes are varied in 163, 283, 409, 571 bits. These key sizes are guaranteed to be still secure by NIS

First, the time on aggregating the payload ciphers in the four scenarios. These payload ciphers are aggregated using the additive property of homomorphic ECC algorithm. The number of payload cipher aggregation at the intersecting node in the four scenarios are respectively 2, 4, 6, 8 for each flow. In Figure 7-a, with the smallest ECC key size (i.e., 163 bits), the time on aggregating two payload ciphers of Scenario 1 is 26,8ms. In the worst case, that is, the largest key size (i.e., 571 bit), the time computed for aggregating 8 payload ciphers of Scenario 4 is 268,8ms. The times on different scenarios and key sizes are reasonable in the peer-to-peer environment

Figure 7-b is another experiment to compute the time cost for SCOPE transmissions. These time are measured to evaluate the time which a packet moves through a flow from the source node to

Figure 7: Time overload. a) Time on aggregating the payload cipher at the intersecting node (milliseconds or ms) vs ECC key size (bits); b) Time on SCOPE transmission including aggregation time (milliseconds or ms) vs ECC key size (bits); c) Time on evaluating coding condition at intersecting node (milliseconds or ms) vs ECC key size (bits).

the destination node. Hence, these times include the payload cipher aggregating times (as in the experiment of Figure 7-a) and transmission times. In this experiment, the number of payload cipher aggregations at the intersecting nodes are similar to the previous experiment. The ECC key sizes mare also varied in 163, 283, 409, 571 bits. In the case of smallest ECC key size, that is, 163 bits, in
scenario 1 involving 2 payload cipher aggregations, the time cost is 260,8ms. Whereas, in the case of largest ECC key size (i.e., 571 bits) and Scenario 4 involving 8 payload cipher aggregations, the time costs is 2.5s. The time overheads in this experiment in both cases are reasonable and prove that SCOPE is effective and efficient.

In order to evaluate the cryptographic process of evaluating the coding conditions of SCOPE, we measure the time SCOPE spent on this evaluation (Figure 7-c). The key sizes are selected in the range 163, 283, 409, 571 bits. The number of coding conditions for Scenarios 1, 2, 3, and 4 are respectively 4, 20, 30, 32 conditions. The time on evaluating the coding conditions in Scenario 1 (i.e., with the lowest number of conditions, that is, 4) with the smallest key size (i.e., 163 bits) is 6.8ms. In the meanwhile, the time on coding conditions evaluation in Scenario 4 (i.e., the highest number of condition, that is, 32) with the largest ECC key size (i.e., 571 bits) is 115,2 ms. In the both cases of the smallest parameters and the largest parameters, the time overheads are still reasonable and prove the effectiveness and efficiency of SCOPE.

Private identification time overload. Moreover, for the private identification in the robust SCOPE, we made many experiments applying ECDSA on the packets. The selected ECDSA key sizes have 384 bits and 521 bits. First, the experiment on ECDSA are to consider how effective the ECDSA works (see Figure 8). We execute ECDSA to create a different number of signatures in the range of 5, 10, 15, 20. In the worst case with the maximum number of signatures (i.e., 20 signatures) and the largest ECDSA key size (i.e., 512 bits), the generation time is 1.8 seconds. In the best case with the minimum number of signatures (i.e., 8 signatures) and the smallest ECDSA key size (i.e., 384 bits), the generation time is 220ms.

The following experiments are done on combining ECC and ECDSA algorithms in the SCOPE protocol with the different number of signatures needed to be generated. In these experiments, ECC key sizes are in the range 163, 283, 409, 571 bits, ECDSA key sizes are in the range 384, 521 bits. The number of signatures need to be generated are in the range 5, 10, 15, 20. Figure 9-a presents experiments of encrypting pieces of data in the SCOPE header and payload, then generating signatures of their outputted encryptions. For each ECC key size and the 384-bit ECDSA

key size, the time consumption is affected by the number of signatures too. In the worst case with the largest ECC key size (i.e., 571 bits) and 20 signatures, the time overload is 1.48 seconds. In the best case with the smallest ECC key size (i.e., 163 bits) and 5 signatures, the time overload is 270 milliseconds. Figure 9-b describes the time consumption for invoking the data encryption and generating the signature of the encryption using the 521-bit ECDSA key size. In the worst case with the largest ECC key size (i.e., 571 bits) and 20 signatures, the time overload is 2.4 seconds. In the best case with the smallest ECC key size (i.e., 163 bits) and 5 signatures, the time overload is 500 milliseconds.

Figure 8: Signature Generation Time (ms) with different ECDSA key size bits.

 

Figure 9: Time of executing data encryption by ECC and generating the signature of the encryption
by ECDSA (ms).

10. Security Property

In this section, a security proof is presented. More specifically, the expression how the proposal can cope with risks of honest-but-curious attack and malicious attack as in Section 4, as well as how the proposal meets the security requirements as in Section 5.

Packet data security. The ECC homomorphic encryption is adopted to cipher the content of the data payload of packets. The payload then gets into a secret writing, i.e., unreadable. As a result, this carries the COPE packets a shield to deter adversaries from inferring any information inside the payload. Particularly, the ECC public key used for encrypting the payload is kept by only the destination node of the packet, so the other nodes cannot read the packet anyway. Only the destination node of the packet has the private key which can be used for decrypting the payload, then the payload can be read. Hence, both honest-but-curious and malicious adversaries cannot read the packet data.

Information inferring protection. The addition property of the homomorphic encryption ECC is exploited for coding multiple packets into one packet at the intermediate node before the aggregate

packet is propagated to the next hop of the intersecting node. More specifically, the public key of the destination node of the packet is used for this secret aggregation phase. The intersecting nodes just aggregates the encryptions without being aware of the packets’ content. This point helps the data safe from the intersecting node. They cannot read the data inside and cannot infer the information as they do not have the private key of the destination node. This point thus help the data safe from both honest-but-curious and malicious adversaries.

Coding condition evaluation security. The coding conditions involve encryptions of the node IDs as presented in Section 8.1. The comparisons are executed on these encryptions. Thus the intermediate nodes cannot learn the node IDs inside the thresholds and operands. Additionally, we also protect the neighbor nodes by encrypting their IDs, and only their direct neighbors can know their IDs, but the two-hop nodes cannot know their IDs. The comparative results are also not recognized by the nodes. Hence, the coding conditions are secured during the evaluation phase.

Packet and node authentication. The digital signature algorithm based on Elliptic Curve Cryptography, namely ECDSA, is adopted in this work to intensify SCOPE against the malicious attack. This work focuses on authenticating the sending node and the original packet to avoid the malicious adversaries impersonating the sending node, or modifying the packet before reaching its destination node. For those purposes, the encryptions of SCOPE header fields are signed with its public key of the receiving node. So the receiving node can evaluate the SCOPE header fields’ encryption before deciding to evaluate the coding conditions. This feature also helps SCOPE not let the packet go in case the packet meets the coding conditions and is coded then propagated to the destination node. Moreover, the source node in SCOPE makes the signature of the payload encryption with its private key of the source node. Hence, the destination node can use the public key of the source node to evaluate the signature to guarantee the integrity of the packet. It means that the packet payload is not changed by attackers on the channel from the source node to the destination node.

Performance optimization. In this work, we empower our proposal’s security with the ECC and ECDSA algorithms. The both algorithms are invoked based on the binary field with the binary operators. This point reduces much the time consumption, and meets the computing performance requirements. Additionally, the ECC is still guaranteed to be secure by NIST. So, the proposal can ensure the computing performance to be optimized.

11. Conclusion

In this work, we propose a cryptographic approach, namely SCOPE, which is able to support nodes secretly executing the COPE protocol against the honest-but-curious attack and the malicious attack, at the same time, consumes less time cost and get an effective computing performance due to the secure and lightweight ECC and ECDSA algorithms. The proposal is also proved to be effective and efficient through the different experiments on a variety of ECC and ECDSA key sizes for several scenarios. This work will be improved to fit with more network coding protocols, such as, BEND, DCAR, etc. in the future work.

Acknowledgement

This work is funded by the PSSG project at the Vietnamese-German University, Vietnam.

References

[1] S. Katti, H. Rahul, W. Hu, D. Katabi, M. Mdard, and J. Crowcroft, “Xors in the air: Practical wireless network coding,” in Proc. ACM SIGCOMM, 2006, pp. 243–254. Cited on page(s): 1, 6

[2] V. Katiyar, K. Dutta, and S. Gupta, “A survey on elliptic curve cryptography for pervasive computing environment,” International Journal of Computer Applications, vol. 11, no. 10, pp. 41–46, 2010. Cited on page(s): 2

[3] N. F. 186-4, “Elliptic curve digital signature algorithm (ecdsa),” NIST, Tech. Rep., 2013. Cited on page(s): 2, 7

[4] N. Cai and R. Yeung, “Network coding and error correction,” in Proceedings of the 2002 IEEE Information Theory Workshop, 2002, p. 119–122. Cited on page(s): 2

[5] V. Talooki, R. Bassoli, D. Lucani, J. Rodriguez, F. Fitzek, H. Marques, and R. Tafazolli, “Security concerns and countermeasures in network coding based communication systems: A survey,” Computer Networks, vol. 83, pp. 422–445, 2015. Cited on page(s): 2

[6] N. Cai and R. Yeung, “Secure network coding,” in IEEE International Symposium on Information Theory, 2002, p. 323. Cited on page(s): 2
[7] Y. Fan, Y. Jiang, H. Zhu, J. Chen, and X. Shen, “Network coding based privacy preservation against traffic analysis in multi-hop wireless networks,” IEEE Transactions on Wireless Communications, vol. 10, no. 3, pp. 834–843, 2011. Cited on page(s): 2

[8] P. Paillier, “Public-key cryptosystems based on composite degree residuosity classes,” in Eurocrypt, vol. 99, 1999, pp. 223–238. Cited on page(s): 2.

[9] A. Esfahani, G. Mantas, V. Monteiro, K. Ramantasy, E. Datsikay, and J. Rodriguez, “Analysis of a homomorphic mac-based scheme against tag pollution in rlnc-enabled wireless networks,” in IEEE 20th International Workshop on Computer Aided Modelling and Design of
Communication Links and Networks (CAMAD), 2015, pp. 156–160. Cited on page(s): 2

[10] X. Li, F. Fu, X. Zhao, and G. Wang, “Two improved homomorphic mac schemes in network coding,” in IEEE Fuzzy Systems and Knowledge Discovery (FSKD), 2015, pp. 2214–2219. Cited on page(s): 2

[11] A. Esfahani, G. Mantas, J. Rodriguez, A. Nascimento, and J. Neves, “A null space-based mac scheme against pollution attacks to random linear network coding,” in IEEE Communication Workshop (ICCW), 2015, pp. 1521–1526. Cited on page(s): 2

[12] C. Li, L. Chen, R. Lu, and H. Li, “Comment on ”an efficient homomorphic mac with small key size for authentication in network coding”,” IEEE Transactions on Computers, vol. 64, no. 3, pp. 882–883, 2015. Cited on page(s): 2

[13] F. .-. with Change Notice 1, “Sha-2,” NIST, Tech. Rep., 2008. Cited on page(s): 13