# Cloud Based Data Protection in Anonymously Controlled SDN

Authors: Jian Shen; Jun Shen; Chin-Feng Lai; Qi Liu; Tianqi Zhou
Journal: Security and Communication Networks
 (2018)

---

## Abstract

Nowadays, Software Defined Network (SDN) develops rapidly for its novel structure which separates the control plane and the data plane of network devices. Many researchers devoted themselves to the study of such a special network. However, some limitations restrict the development of SDN. On the one hand, the single controller in the conventional model bears all threats, and the corruption of it will result in network paralysis. On the other hand, the data will be increasing more in SDN switches in the data plane, while the storage space of these switches is limited. In order to solve the mentioned issues, we propose two corresponding protocols in this paper. Specifically, one is an anonymous protocol in the control plane, and the other is a verifiable outsourcing protocol in the data plane. The evaluation indicates that our protocol is correct, secure, and efficient.


---

## Body

## 1. Introduction

Nowadays, as cloud computing develops rapidly [1–6], an increasing number of applications and services are transplanted to the cloud to satisfy the requirements of cloud clients. As time goes by, the burden on the cloud and the management of services and applications become heavier. In addition, the cloud is not flexible enough for the reconfiguration of the underlying networking when facing different applications. Therefore, SDN is proposed, which has caught the attention of a large number of researchers [7, 8].SDN originates from the Clean Slate research project of Stanford University in 2006. Three years later, professor Nick McKeown proposed the specific definition of SDN. Since the data plane and the control plane of network are separated, which differs from the cloud, SDN is equipped with unprecedented flexibility [9–12]. As a breakthrough, SDN will never suffer from the reconfiguration of the underlying networking when facing different applications. The network devices named “SDN switches” form the data plane, which are responsible for the transmission of data packets merely. Since data transmission is an uncomplicated work and these switches should carry nothing else, the data packets on transmission can be dealt with substantially quickly, which is more suitable for the popularized network. The control plane consists of the controller, and this plane holds the global information of the whole network and controls SDN switches in the data plane. There is a unified interface named south-bound API between the control plane and the data plane, which realizes the interaction between the two planes. In a word, the management of the network can be well-bedded and convenient with the proposal of SDN.Although SDN brings benefits to network, there are still some problems impeding its development. On the one hand, there is only one controller in the control plane of the conventional SDN model, and the single controller is the core of the whole network. Once the only controller is attacked or corrupted, the network will be imploded. In this paper, we aim to involve more than one controller in SDN, and the data transmission commands will be sent from a random and anonymous controller. On the other hand, when more and more applications are deployed in SDN, the information in the data plane will be more. Since the storage space of SDN switches is limited, the burden on these switches will be heavier as time goes by. Compared with the limited storage space in SDN switches, the space in the cloud is almost endless. Moreover, cloud storage is equipped with on-demand outsourcing function, ubiquitous network access, and location-independent resources. Hence, we aim to employ the cloud for data storage in this paper.The main contributions of the paper are summarized as follows:(1)
We propose an anonymous control protocol in the control plane. The threats on a certain controller can be relieved and SDN will be substantially more secure by the design of this protocol.(2)
We design a verifiable outsourcing protocol in the data plane. Through the protocol, SDN switches with limited space can employ the cloud for data storage. In addition, the outsourced data can be verified for security.The remainder of the paper is organized as follows. In Section2, we present the system and security model. In Section 3, we introduce some preliminary works to allow the reader to obtain better understanding of the topic. In Section 4, we describe the two protocols in this paper in detail, including the anonymous control protocol and the verifiable outsourcing protocol. In Section 5, we present the correctness analysis, security analysis, and cost analysis of our protocols. The conclusion is drawn in Section 6.


## 2. Problem Statement

### 2.1. The System Model

In the application plane, there are many software applications, and we define the number of them asn. As time goes by, the applications will be more for the popularity of SDN. In the control plane, there is traditionally one controller in the system merely. However, the network will be paralyzed when the only controller is attacked or corrupted. Therefore, we aim to deploy more than one controller in our system, the number of which is not confined to “4” in Figure 1. With several controllers, the data transmission instructions will be commanded by a random controller anonymously and the threats on a certain controller will be relieved. Suppose that there are one hundred controllers in the system; then the possibility of attacks on a certain controller can be relieved from 100% to 1%. There is a north-bound API between the application plane and the control plane, which is used for information interactions. Through north-bound API, the network can be customized by the actual requirements of each application. In the data plane, there are a large number of SDN switches, which are responsible for data transmission. Controllers command the process of transmission through the interface between the control plane and the data plane called south-bound API. Generally, the functions of south-bound API are realized through OpenFlow, which is a standardized protocol. Moreover, since we consider the limited storage in SDN switches, we introduce an additional plane—the storage plane consisting of one or more cloud service providers (CSPs). CSPs provide SDN switches with storage services in the cloud.Figure 1
The system model.


### 2.2. The Security Model

It is assumed that the introduced key generation center (KGC) is trustworthy enough and will never attack the system. Although CSPs are curious about the data in the data plane which are outsourced in the cloud, they will never collude with any switch. We say that protocols proposed in this paper are secure if the following conditions hold:(1)
Unforgeability of controllers: the possibility that an adversary can pretend to be any one valid controller in the control plane and hold the public and private key pair (SKi=Pixi,PKi=Qixi) of the controller is negligible.(2)
Unforgeability of BLS-based homomorphic verifiable authenticator: CSPs will never succeed in forging the data tag τ=(h·um)k of any outsourced data m to deceive the challenger.(3)
Resistance of replay attack: it is impossible for CSPs to generate the proof matched with the challenge using the previous proofs (Tpre,Dpre), without retrieving the actual cloud data m.(4)
Resistance of replacement attack: CSPs can never find out another valid proof (Toth,Doth) of data to replace the challenged data proof, when they already discarded or damaged cloud data m.


## 2.1. The System Model

In the application plane, there are many software applications, and we define the number of them asn. As time goes by, the applications will be more for the popularity of SDN. In the control plane, there is traditionally one controller in the system merely. However, the network will be paralyzed when the only controller is attacked or corrupted. Therefore, we aim to deploy more than one controller in our system, the number of which is not confined to “4” in Figure 1. With several controllers, the data transmission instructions will be commanded by a random controller anonymously and the threats on a certain controller will be relieved. Suppose that there are one hundred controllers in the system; then the possibility of attacks on a certain controller can be relieved from 100% to 1%. There is a north-bound API between the application plane and the control plane, which is used for information interactions. Through north-bound API, the network can be customized by the actual requirements of each application. In the data plane, there are a large number of SDN switches, which are responsible for data transmission. Controllers command the process of transmission through the interface between the control plane and the data plane called south-bound API. Generally, the functions of south-bound API are realized through OpenFlow, which is a standardized protocol. Moreover, since we consider the limited storage in SDN switches, we introduce an additional plane—the storage plane consisting of one or more cloud service providers (CSPs). CSPs provide SDN switches with storage services in the cloud.Figure 1
The system model.


## 2.2. The Security Model

It is assumed that the introduced key generation center (KGC) is trustworthy enough and will never attack the system. Although CSPs are curious about the data in the data plane which are outsourced in the cloud, they will never collude with any switch. We say that protocols proposed in this paper are secure if the following conditions hold:(1)
Unforgeability of controllers: the possibility that an adversary can pretend to be any one valid controller in the control plane and hold the public and private key pair (SKi=Pixi,PKi=Qixi) of the controller is negligible.(2)
Unforgeability of BLS-based homomorphic verifiable authenticator: CSPs will never succeed in forging the data tag τ=(h·um)k of any outsourced data m to deceive the challenger.(3)
Resistance of replay attack: it is impossible for CSPs to generate the proof matched with the challenge using the previous proofs (Tpre,Dpre), without retrieving the actual cloud data m.(4)
Resistance of replacement attack: CSPs can never find out another valid proof (Toth,Doth) of data to replace the challenged data proof, when they already discarded or damaged cloud data m.


## 3. Preliminaries

This section presents some preliminaries to facilitate the reader’s understanding, including bilinear pairing [13–16], ring signature, BLS-based homomorphic verifiable authenticator, and computational Diffie–Hellman (CDH) problem.Definition 1 (bilinear pairing).
Suppose thatG1, G2, and GT are multiplicative cyclic groups of a large prime p, and a map function e:G1×G2→GT is a bilinear pairing only if the following properties are satisfied:(1)
Bilinearity: for all the generatorsg1∈G1 and g2∈G2, there always exists e(g1a,g2b)=e(g1,g2)ab, where a,b∈Zp∗.(2)
Nondegeneracy: there existg1∈G1 and g2∈G2 satisfying the equation e(g1,g2)≠1.(3)
Computability: for all the generatorsg1∈G1 and g2∈G2, there exists an efficient algorithm to compute e(g1,g2).Definition 2 (ring signature).
Given a group ofn entities each having public and private key pair ranging from P1,S1 to Pn,Sn, suppose that the ith entity is the signer, and the message is m. Then, the signature σ on m can be computed when m,Si,P1,P2,…,Pn is inputted. Anyone can check the validity of a ring signature when σ, m, and P1 to Pn are given. All the members in the ring can sign a message with their own private keys and the others’ public keys without the agreement of them [17–23]. With ring signature, the message can be transmitted securely and the identity of the actual signer is protected as well.Definition 3 (BLS-based homomorphic verifiable authenticator).
Given two multiplicative cyclic groupsG and GT and a bilinear pairing e:G×G→GT, select random a∈Zp∗ as the private key. The public key is g,v=ga. The BLS-based homomorphic authenticator for some data m is computed as σ=(h(m))a, where h(·) is a one-way hash function. For verification, the verifier will simply check the equality of the equation e(h(m),v)?__e(σ,g) [24–29]. If the equation holds, the verifier will believe that the BLS-based homomorphic authenticator is valid; otherwise, the validity of the authenticator cannot be proved.Definition 4 (CDH problem).
Givenga and gb, where g is a generator of G1 and a,b∈RZp∗, compute gab.


## 4. The Proposed Protocol

In this section, the core part of this paper will be introduced, which consists of two protocols: the anonymous protocol in the control plane for controllers and the verifiable outsourcing protocol in the data plane for data on SDN switches, which are in Sections4.2 and 4.3 separately. Some primary notations are introduced as follows.


### 4.1. Notations

As is shown in Notations section, some primary notations used in protocols are listed.G, GT, G1, and G2 are four multiplicative cyclic groups of a large prime order p. g is the generator of G, and u, g1 are generators of G1. Zp∗ is a set of nonnegative integers less than p. e:G×G→GT and e:G1×G1→G2 are bilinear pairings. H1:0,1∗→Zp∗, H2:0,1∗→G, and H3:0,1∗→G1 are cryptographic collision-resistant hash functions from strings to elements in Zp∗, G, and G1.


### 4.2. The Anonymous Protocol in the Control Plane

In this section, the proposed anonymous protocol in the control plane will be described in detail, which aims to decentralize the power of and the attacks on a certain controller. Specifically, the protocol can be divided into 4 phases: setup phase, key generation phase, sign phase, and verification phase. Note that the second phase consists of 4 algorithms:partial-private-key extraction,secret-value selection,private-key generation, andpublic-key generation. The details of the protocol are shown as follows.


#### 4.2.1. Setup Phase

In this phase, some preparation works are made for system setup. First, the whole network selects a trustworthy third party as a KGC, which is responsible for extracting the partial private keys in key generation phase. Then, the KGC will finish the remaining preparations.Firstly, the KGC selects randoms∈Zp∗ as the master key of the network, which is kept secret by the KGC itself. Secondly, the KGC picks random generator g∈G and computes pk=gs. Consequently, the secret and public key pair of the KGC is (sk=s,pk=gs). Thirdly, the identities of all the controllers are aggregated together as a set ID=IDi∣i=1,2,…,c. Finally, all the public parameters of the system are G,GT,p,g,e,H1,H2,pk.


#### 4.2.2. Key Generation Phase

This phase performs the generation of private and public key pairs of all the controllers, and we define that there are totallyc controllers in our system. In order to decentralize the power of the KGC, we aim to employ the KGC to extract the partial private keys of controllers merely. Therefore, even though the KGC is attacked by hackers or leaks out some secrets, the data and information of the system will keep secure. The detailed design of the four algorithms is shown as follows:(i)
Partial-private-key extraction: this algorithm is performed by the KGC, which takes the public parameters ID and sk as input. The KGC computes Qi=H2(IDi) and Pi=Qisk for all the c controllers as the partial private keys, where i ranges from 1 to c. After that, the KGC sends the pair of Qi and Pi to each controller separately.(ii)
Secret-value selection: for the generation of the complete private and public key pair, each controller selects random number xi∈Zp∗ as the secret value, which is kept secret by the corresponding controller itself.(iii)
Private-key generation: since each controller has selected a secret value and received the partial key pair from the KGC, they will compute SKi=Pixi as the complete private key separately.(iv)
Public-key generation: each controller computes PKi=Qixi as the public key, where i ranges from 1 to c.Finally, the private and public key pairs(SKi=Pixi,PKi=Qixi) for all the controllers are generated.


#### 4.2.3. Sign Phase

Inspired by [30, 31], a certain controller will sign the message sent to SDN switches using the aux information of other controllers. We define that the message is M and the identity of the randomly chosen actual signer is of the identity IDs. In order to reduce the risk of attacks on a single controller, the signer will employ the public keys of all the other controllers to sign the message, which realizes the anonymity.Specifically, the singer picks randomri∈Zp∗(1≤i≤c) and computes Ui=PKiri(i≠s). If there are collisions among Ui, the signer reselects ri∈Zp∗ randomly. Then, the signer computes hi=H1M∥ID∥Ui for i≠s. Through hi, Us can be calculated by Us=PKsrs/PKi∑i≠s(ri+hi). After that, IDs computes hs=H1M∥ID∥Us and S=SKshs+rs. Finally, the signature on the message is σ=(M,U1,U2,…,Uc,S) and it will be sent by the controller which generates the signature to SDN switches through secure channels.


#### 4.2.4. Verification Phase

This phase is designed to check the validity of the signature. First, the verifier computeshi=H1M∥ID∥Ui for 1≤i≤c. Then, it checks the equality of the equation(1)epk,∏1≤i≤cUi·PKihi?__eg,S.If (1) holds, the signature is valid; otherwise, it is not.


### 4.3. Verifiable Outsourcing Protocol in the Data Plane

The second protocol proposed in this paper is designed for the limited storage space in SDN switches. We employ the cloud for data storage in the data plane, which is of great convenience. As for the attacks in the cloud threatening the security of these data, our protocol is designed to be verifiable, so that it can ensure the correctness and integrity of the outsourced data. Specifically, the second protocol can be divided into 2 phases: setup phase and verification phase. The following are the details.


#### 4.3.1. Setup Phase

Setup phase is for some preparations of the protocol, which consists of two algorithms:key generation andtag generation. The public and private parameters are generated inkey generation, and the tag for the outsourced data is computed intag generation. The designs of the two algorithms are shown below.(i)
Key generation: the SDN switch which wants to outsource data in cloud selects random a∈Zp∗ as the private key k and keeps it secret. Then, it generates v=g1a. Finally, the outputs of the algorithmkey generation are the private and public key pair k=a,g1,u,v=g1a.(ii)
Tag generation: it is obvious that the data outsourced in the cloud should be encrypted. We define that the time point to outsource the data m is t and the identity of the switch is the concatenation of its latitude lat and longitude lon, which is unique enough. First, the switch computes h=H3t∥lat∥lon. Then, the tag is calculated as τ=(h·um)k. Finally, the switch uploads the data and the corresponding tags to the cloud for storage.


#### 4.3.2. Verification Phase

The second phase performs data verification, which enables switches that outsource their data to ensure the correctness and completeness of these data. Specifically, the switch asks the cloud for the proof which indicates the integrity of the outsourced data, and the cloud should respond with the corresponding valid proof. If the proof is invalid, it will never pass the verification equation. This phase includes two algorithms:proof generation and verification proof. The details are as follows:(i)
Proof generation: upon receiving the challenge request from a certain switch, the cloud should generate the corresponding data proof to claim that these data are correctly and completely stored in cloud services. Specifically, the cloud generates the tag proof T=τr and the data proof D=m·r, where r is randomly picked from Zp∗. Then, the cloud sends the proof (T,D) to the switch (challenger).(ii)
Verification proof: when the switch receives the proof, it will check the validity of the proof. Specifically, the switch checks whether the equation(2)eT,g1?__eh·uD,vholds. If (2) holds, the outsourced data in the cloud proves to be correct and complete; otherwise, the data is corrupted.


## 4.1. Notations

As is shown in Notations section, some primary notations used in protocols are listed.G, GT, G1, and G2 are four multiplicative cyclic groups of a large prime order p. g is the generator of G, and u, g1 are generators of G1. Zp∗ is a set of nonnegative integers less than p. e:G×G→GT and e:G1×G1→G2 are bilinear pairings. H1:0,1∗→Zp∗, H2:0,1∗→G, and H3:0,1∗→G1 are cryptographic collision-resistant hash functions from strings to elements in Zp∗, G, and G1.


## 4.2. The Anonymous Protocol in the Control Plane

In this section, the proposed anonymous protocol in the control plane will be described in detail, which aims to decentralize the power of and the attacks on a certain controller. Specifically, the protocol can be divided into 4 phases: setup phase, key generation phase, sign phase, and verification phase. Note that the second phase consists of 4 algorithms:partial-private-key extraction,secret-value selection,private-key generation, andpublic-key generation. The details of the protocol are shown as follows.


### 4.2.1. Setup Phase

In this phase, some preparation works are made for system setup. First, the whole network selects a trustworthy third party as a KGC, which is responsible for extracting the partial private keys in key generation phase. Then, the KGC will finish the remaining preparations.Firstly, the KGC selects randoms∈Zp∗ as the master key of the network, which is kept secret by the KGC itself. Secondly, the KGC picks random generator g∈G and computes pk=gs. Consequently, the secret and public key pair of the KGC is (sk=s,pk=gs). Thirdly, the identities of all the controllers are aggregated together as a set ID=IDi∣i=1,2,…,c. Finally, all the public parameters of the system are G,GT,p,g,e,H1,H2,pk.


### 4.2.2. Key Generation Phase

This phase performs the generation of private and public key pairs of all the controllers, and we define that there are totallyc controllers in our system. In order to decentralize the power of the KGC, we aim to employ the KGC to extract the partial private keys of controllers merely. Therefore, even though the KGC is attacked by hackers or leaks out some secrets, the data and information of the system will keep secure. The detailed design of the four algorithms is shown as follows:(i)
Partial-private-key extraction: this algorithm is performed by the KGC, which takes the public parameters ID and sk as input. The KGC computes Qi=H2(IDi) and Pi=Qisk for all the c controllers as the partial private keys, where i ranges from 1 to c. After that, the KGC sends the pair of Qi and Pi to each controller separately.(ii)
Secret-value selection: for the generation of the complete private and public key pair, each controller selects random number xi∈Zp∗ as the secret value, which is kept secret by the corresponding controller itself.(iii)
Private-key generation: since each controller has selected a secret value and received the partial key pair from the KGC, they will compute SKi=Pixi as the complete private key separately.(iv)
Public-key generation: each controller computes PKi=Qixi as the public key, where i ranges from 1 to c.Finally, the private and public key pairs(SKi=Pixi,PKi=Qixi) for all the controllers are generated.


### 4.2.3. Sign Phase

Inspired by [30, 31], a certain controller will sign the message sent to SDN switches using the aux information of other controllers. We define that the message is M and the identity of the randomly chosen actual signer is of the identity IDs. In order to reduce the risk of attacks on a single controller, the signer will employ the public keys of all the other controllers to sign the message, which realizes the anonymity.Specifically, the singer picks randomri∈Zp∗(1≤i≤c) and computes Ui=PKiri(i≠s). If there are collisions among Ui, the signer reselects ri∈Zp∗ randomly. Then, the signer computes hi=H1M∥ID∥Ui for i≠s. Through hi, Us can be calculated by Us=PKsrs/PKi∑i≠s(ri+hi). After that, IDs computes hs=H1M∥ID∥Us and S=SKshs+rs. Finally, the signature on the message is σ=(M,U1,U2,…,Uc,S) and it will be sent by the controller which generates the signature to SDN switches through secure channels.


### 4.2.4. Verification Phase

This phase is designed to check the validity of the signature. First, the verifier computeshi=H1M∥ID∥Ui for 1≤i≤c. Then, it checks the equality of the equation(1)epk,∏1≤i≤cUi·PKihi?__eg,S.If (1) holds, the signature is valid; otherwise, it is not.


## 4.2.1. Setup Phase

In this phase, some preparation works are made for system setup. First, the whole network selects a trustworthy third party as a KGC, which is responsible for extracting the partial private keys in key generation phase. Then, the KGC will finish the remaining preparations.Firstly, the KGC selects randoms∈Zp∗ as the master key of the network, which is kept secret by the KGC itself. Secondly, the KGC picks random generator g∈G and computes pk=gs. Consequently, the secret and public key pair of the KGC is (sk=s,pk=gs). Thirdly, the identities of all the controllers are aggregated together as a set ID=IDi∣i=1,2,…,c. Finally, all the public parameters of the system are G,GT,p,g,e,H1,H2,pk.


## 4.2.2. Key Generation Phase

This phase performs the generation of private and public key pairs of all the controllers, and we define that there are totallyc controllers in our system. In order to decentralize the power of the KGC, we aim to employ the KGC to extract the partial private keys of controllers merely. Therefore, even though the KGC is attacked by hackers or leaks out some secrets, the data and information of the system will keep secure. The detailed design of the four algorithms is shown as follows:(i)
Partial-private-key extraction: this algorithm is performed by the KGC, which takes the public parameters ID and sk as input. The KGC computes Qi=H2(IDi) and Pi=Qisk for all the c controllers as the partial private keys, where i ranges from 1 to c. After that, the KGC sends the pair of Qi and Pi to each controller separately.(ii)
Secret-value selection: for the generation of the complete private and public key pair, each controller selects random number xi∈Zp∗ as the secret value, which is kept secret by the corresponding controller itself.(iii)
Private-key generation: since each controller has selected a secret value and received the partial key pair from the KGC, they will compute SKi=Pixi as the complete private key separately.(iv)
Public-key generation: each controller computes PKi=Qixi as the public key, where i ranges from 1 to c.Finally, the private and public key pairs(SKi=Pixi,PKi=Qixi) for all the controllers are generated.


## 4.2.3. Sign Phase

Inspired by [30, 31], a certain controller will sign the message sent to SDN switches using the aux information of other controllers. We define that the message is M and the identity of the randomly chosen actual signer is of the identity IDs. In order to reduce the risk of attacks on a single controller, the signer will employ the public keys of all the other controllers to sign the message, which realizes the anonymity.Specifically, the singer picks randomri∈Zp∗(1≤i≤c) and computes Ui=PKiri(i≠s). If there are collisions among Ui, the signer reselects ri∈Zp∗ randomly. Then, the signer computes hi=H1M∥ID∥Ui for i≠s. Through hi, Us can be calculated by Us=PKsrs/PKi∑i≠s(ri+hi). After that, IDs computes hs=H1M∥ID∥Us and S=SKshs+rs. Finally, the signature on the message is σ=(M,U1,U2,…,Uc,S) and it will be sent by the controller which generates the signature to SDN switches through secure channels.


## 4.2.4. Verification Phase

This phase is designed to check the validity of the signature. First, the verifier computeshi=H1M∥ID∥Ui for 1≤i≤c. Then, it checks the equality of the equation(1)epk,∏1≤i≤cUi·PKihi?__eg,S.If (1) holds, the signature is valid; otherwise, it is not.


## 4.3. Verifiable Outsourcing Protocol in the Data Plane

The second protocol proposed in this paper is designed for the limited storage space in SDN switches. We employ the cloud for data storage in the data plane, which is of great convenience. As for the attacks in the cloud threatening the security of these data, our protocol is designed to be verifiable, so that it can ensure the correctness and integrity of the outsourced data. Specifically, the second protocol can be divided into 2 phases: setup phase and verification phase. The following are the details.


### 4.3.1. Setup Phase

Setup phase is for some preparations of the protocol, which consists of two algorithms:key generation andtag generation. The public and private parameters are generated inkey generation, and the tag for the outsourced data is computed intag generation. The designs of the two algorithms are shown below.(i)
Key generation: the SDN switch which wants to outsource data in cloud selects random a∈Zp∗ as the private key k and keeps it secret. Then, it generates v=g1a. Finally, the outputs of the algorithmkey generation are the private and public key pair k=a,g1,u,v=g1a.(ii)
Tag generation: it is obvious that the data outsourced in the cloud should be encrypted. We define that the time point to outsource the data m is t and the identity of the switch is the concatenation of its latitude lat and longitude lon, which is unique enough. First, the switch computes h=H3t∥lat∥lon. Then, the tag is calculated as τ=(h·um)k. Finally, the switch uploads the data and the corresponding tags to the cloud for storage.


### 4.3.2. Verification Phase

The second phase performs data verification, which enables switches that outsource their data to ensure the correctness and completeness of these data. Specifically, the switch asks the cloud for the proof which indicates the integrity of the outsourced data, and the cloud should respond with the corresponding valid proof. If the proof is invalid, it will never pass the verification equation. This phase includes two algorithms:proof generation and verification proof. The details are as follows:(i)
Proof generation: upon receiving the challenge request from a certain switch, the cloud should generate the corresponding data proof to claim that these data are correctly and completely stored in cloud services. Specifically, the cloud generates the tag proof T=τr and the data proof D=m·r, where r is randomly picked from Zp∗. Then, the cloud sends the proof (T,D) to the switch (challenger).(ii)
Verification proof: when the switch receives the proof, it will check the validity of the proof. Specifically, the switch checks whether the equation(2)eT,g1?__eh·uD,vholds. If (2) holds, the outsourced data in the cloud proves to be correct and complete; otherwise, the data is corrupted.


## 4.3.1. Setup Phase

Setup phase is for some preparations of the protocol, which consists of two algorithms:key generation andtag generation. The public and private parameters are generated inkey generation, and the tag for the outsourced data is computed intag generation. The designs of the two algorithms are shown below.(i)
Key generation: the SDN switch which wants to outsource data in cloud selects random a∈Zp∗ as the private key k and keeps it secret. Then, it generates v=g1a. Finally, the outputs of the algorithmkey generation are the private and public key pair k=a,g1,u,v=g1a.(ii)
Tag generation: it is obvious that the data outsourced in the cloud should be encrypted. We define that the time point to outsource the data m is t and the identity of the switch is the concatenation of its latitude lat and longitude lon, which is unique enough. First, the switch computes h=H3t∥lat∥lon. Then, the tag is calculated as τ=(h·um)k. Finally, the switch uploads the data and the corresponding tags to the cloud for storage.


## 4.3.2. Verification Phase

The second phase performs data verification, which enables switches that outsource their data to ensure the correctness and completeness of these data. Specifically, the switch asks the cloud for the proof which indicates the integrity of the outsourced data, and the cloud should respond with the corresponding valid proof. If the proof is invalid, it will never pass the verification equation. This phase includes two algorithms:proof generation and verification proof. The details are as follows:(i)
Proof generation: upon receiving the challenge request from a certain switch, the cloud should generate the corresponding data proof to claim that these data are correctly and completely stored in cloud services. Specifically, the cloud generates the tag proof T=τr and the data proof D=m·r, where r is randomly picked from Zp∗. Then, the cloud sends the proof (T,D) to the switch (challenger).(ii)
Verification proof: when the switch receives the proof, it will check the validity of the proof. Specifically, the switch checks whether the equation(2)eT,g1?__eh·uD,vholds. If (2) holds, the outsourced data in the cloud proves to be correct and complete; otherwise, the data is corrupted.


## 5. Evaluation

In this section, some analysis concerning the proposed protocols is presented, including correctness analysis, security analysis, and computational cost analysis.


### 5.1. Correctness Analysis

The correctness analysis of the proposed two protocols will be presented. Equation (1) can verify the signatures of controllers and (2) can verify the outsourced data of SDN switches in the cloud. Specifically, the correctness of the two equations will be elaborated separately in the following.If (1) is correct, only the valid signatures generated by controllers can pass the verification of this equation. Otherwise, the invalid signatures can pass the verification as well. The correctness of (1) is demonstrated as follows:(3)epk,∏1≤i≤cUi·PKihi=egsk,Us·PKshs·∏i≠sUi·PKihi=egsk,PKsrsPKi∑i≠sri+hi·PKshs·∏i≠sPKihi+ri=egsk,PKsrsPKi∑i≠sri+hi·PKshs·PKi∑i≠sri+hi=egsk,PKshs+rs=egsk,Qsxs·hs+rs=eg,Qssk·xs·hs+rs=eg,Psxs·hs+rs=eg,SKshs+rs=eg,S.If (2) is correct, only the valid proofs sent from the cloud can pass the verification of this equation. Otherwise, either the cloud or the SDN switches will be cheated by the incorrect check results. The correctness of (2) is proved as follows:(4)eT,g1=eτr,g1=eh·umkr,g1=eh·umr,g1k=eh·um·r,v=eh·uD,v.In summary, (1) and (2) are both correct, which indicates the correctness of our protocols.


### 5.2. Security Analysis

We will prove the security of our protocols with proofs of the following several theorems.Theorem 5.
In the anonymous protocol, the adversary can never pretend to be any controller in the control plane to generate a valid signature. In other words, the signature signed by the adversary will never pass verification phase.Proof.
We define that the adversary has not been broken through KGC and has no knowledge about the partial private keys of controllers. In order to forge a valid signature, the adversary should compute the complete private key for a controller. The private key is computed asSKi=Pixi, where Pi=Qisk. Since the adversary has no knowledge of xi and sk, the possibility of generating the correct private key of a controller is negligible. In this theorem, although Pi=Qisk and PKi=Qixi are known to the adversary, it is difficult for the adversary to figure out SKi=Qisk·xi, due to the CDH problem in bilinear groups. Therefore, the adversary will fail to forge a valid signature of any controller.Theorem 6.
In the verifiable outsourcing protocol, the BLS-based homomorphic verifiable authenticator cannot be forged by any adversary if the computational Differ-Hellman assumption in bilinear pairing holds.Proof.
This theorem suggests that forging an BLS-HVA is computationally infeasible. As shown in the security analysis of the protocol in Shen et al. [5], the HVA scheme has been proved to be effectively unforgeable, the reason for which is that BLS is secure when the CDH problem is difficult in bilinear groups. The proof can be found in [5] and is omitted here.Theorem 7.
In the verifiable outsourcing protocol, replay attacks would be never effective. In other words, the cloud can never pass the verification if it responds to the challenges with some previous information.Proof.
We define that in the replay attack game, the cloud does not protect the challenged data of the switch. In order to pass the verification, the cloud finds out a previous version of these data and sends the corresponding proof(Tpre,Dpre) to the switch. Since the verification equation is e(T,g1)=e((H3t∥lat∥lon·um)kr,g1) in theverification proof, where the time to outsource the data is t, obviously, data of different versions are outsourced at different times. Hence, the replay attacks can never succeed under our protocol.Theorem 8.
In the verifiable outsourcing protocol, replacement attacks would never work. In other words, the cloud can never pass verification if it responds the challenges with other switches’ completely preserved information.Proof.
We define that in the replacement attack game, the challenged data in cloud is corrupted for some reasons. In order to pass the verification, the cloud decides to send the perfectly protected data information of some other switches back to the challenger. Consequently, the proof will be(Toth,Doth). Since the equation is e(T,g1)=e((H3t∥lat∥lon·um)kr,g1) in theverification proof, where lat∥lon indicates the unique and specific location of the switch, obviously, though the time to outsource the data is exactly the same, the locations of any two different switches differ from each other. Hence, the replacement attacks will never succeed in our design.


### 5.3. Computational Cost Analysis

The computational cost analysis of the two protocols is presented in this section. In addition, some simulation experiments have been conducted to prove the low cost of our protocols. The experiments were performed by C programming language with the pairing-based cryptography (PBC) library and the GUN multiple precision arithmetic (GMP) library on a VMware workstation machine with Intel Core i5-2450M processors running at 2.50 GHz and 12 G memory, Ubuntu 12.04 × 64.First, the brief descriptions of the cost of the two protocols will be introduced. For simplicity, we denote multiplication asM, modular exponentiation as E, and hash function as H. As for the anonymous protocol in the control plane, it costs 1E in setup phase, cH+3cE in key generation phase, and cE+cM+cH in sign phase, where c is the number of controllers in the control plane. As for the second protocol in the data plane, it costs 1E inkey generation algorithm, 1H+2E+1M intag generation algorithm, and 2E inproof generation algorithm, when an SDN switch outsources its data.Then, the experimental results will be analyzed. In Figure2, the time cost of the system changes with the increase of the number of controllers in the control plane. It is obvious that when there are more controllers, the computational cost of the system will be higher. However, when there are more controllers in the control plane, the system will be more secure in practical terms. Hence, for different applications, there exists a tradeoff between energy and security in the choice of the specific number of controllers. Figure 3 describes the computational cost of each algorithm in the verifiable outsourcing protocol in the data plane. It is clear that outsourcing the data of an SDN switch to the cloud costs about 0.018 seconds. Compared with the limited storage space in these switches, using 0.018 seconds to trade off on-demand and convenient storage service is worthwhile.Figure 2
The time cost of the anonymous protocol in the control plane.Figure 3
The time cost for algorithms of verifiable outsourcing protocol in the data plane.


## 5.1. Correctness Analysis

The correctness analysis of the proposed two protocols will be presented. Equation (1) can verify the signatures of controllers and (2) can verify the outsourced data of SDN switches in the cloud. Specifically, the correctness of the two equations will be elaborated separately in the following.If (1) is correct, only the valid signatures generated by controllers can pass the verification of this equation. Otherwise, the invalid signatures can pass the verification as well. The correctness of (1) is demonstrated as follows:(3)epk,∏1≤i≤cUi·PKihi=egsk,Us·PKshs·∏i≠sUi·PKihi=egsk,PKsrsPKi∑i≠sri+hi·PKshs·∏i≠sPKihi+ri=egsk,PKsrsPKi∑i≠sri+hi·PKshs·PKi∑i≠sri+hi=egsk,PKshs+rs=egsk,Qsxs·hs+rs=eg,Qssk·xs·hs+rs=eg,Psxs·hs+rs=eg,SKshs+rs=eg,S.If (2) is correct, only the valid proofs sent from the cloud can pass the verification of this equation. Otherwise, either the cloud or the SDN switches will be cheated by the incorrect check results. The correctness of (2) is proved as follows:(4)eT,g1=eτr,g1=eh·umkr,g1=eh·umr,g1k=eh·um·r,v=eh·uD,v.In summary, (1) and (2) are both correct, which indicates the correctness of our protocols.


## 5.2. Security Analysis

We will prove the security of our protocols with proofs of the following several theorems.Theorem 5.
In the anonymous protocol, the adversary can never pretend to be any controller in the control plane to generate a valid signature. In other words, the signature signed by the adversary will never pass verification phase.Proof.
We define that the adversary has not been broken through KGC and has no knowledge about the partial private keys of controllers. In order to forge a valid signature, the adversary should compute the complete private key for a controller. The private key is computed asSKi=Pixi, where Pi=Qisk. Since the adversary has no knowledge of xi and sk, the possibility of generating the correct private key of a controller is negligible. In this theorem, although Pi=Qisk and PKi=Qixi are known to the adversary, it is difficult for the adversary to figure out SKi=Qisk·xi, due to the CDH problem in bilinear groups. Therefore, the adversary will fail to forge a valid signature of any controller.Theorem 6.
In the verifiable outsourcing protocol, the BLS-based homomorphic verifiable authenticator cannot be forged by any adversary if the computational Differ-Hellman assumption in bilinear pairing holds.Proof.
This theorem suggests that forging an BLS-HVA is computationally infeasible. As shown in the security analysis of the protocol in Shen et al. [5], the HVA scheme has been proved to be effectively unforgeable, the reason for which is that BLS is secure when the CDH problem is difficult in bilinear groups. The proof can be found in [5] and is omitted here.Theorem 7.
In the verifiable outsourcing protocol, replay attacks would be never effective. In other words, the cloud can never pass the verification if it responds to the challenges with some previous information.Proof.
We define that in the replay attack game, the cloud does not protect the challenged data of the switch. In order to pass the verification, the cloud finds out a previous version of these data and sends the corresponding proof(Tpre,Dpre) to the switch. Since the verification equation is e(T,g1)=e((H3t∥lat∥lon·um)kr,g1) in theverification proof, where the time to outsource the data is t, obviously, data of different versions are outsourced at different times. Hence, the replay attacks can never succeed under our protocol.Theorem 8.
In the verifiable outsourcing protocol, replacement attacks would never work. In other words, the cloud can never pass verification if it responds the challenges with other switches’ completely preserved information.Proof.
We define that in the replacement attack game, the challenged data in cloud is corrupted for some reasons. In order to pass the verification, the cloud decides to send the perfectly protected data information of some other switches back to the challenger. Consequently, the proof will be(Toth,Doth). Since the equation is e(T,g1)=e((H3t∥lat∥lon·um)kr,g1) in theverification proof, where lat∥lon indicates the unique and specific location of the switch, obviously, though the time to outsource the data is exactly the same, the locations of any two different switches differ from each other. Hence, the replacement attacks will never succeed in our design.


## 5.3. Computational Cost Analysis

The computational cost analysis of the two protocols is presented in this section. In addition, some simulation experiments have been conducted to prove the low cost of our protocols. The experiments were performed by C programming language with the pairing-based cryptography (PBC) library and the GUN multiple precision arithmetic (GMP) library on a VMware workstation machine with Intel Core i5-2450M processors running at 2.50 GHz and 12 G memory, Ubuntu 12.04 × 64.First, the brief descriptions of the cost of the two protocols will be introduced. For simplicity, we denote multiplication asM, modular exponentiation as E, and hash function as H. As for the anonymous protocol in the control plane, it costs 1E in setup phase, cH+3cE in key generation phase, and cE+cM+cH in sign phase, where c is the number of controllers in the control plane. As for the second protocol in the data plane, it costs 1E inkey generation algorithm, 1H+2E+1M intag generation algorithm, and 2E inproof generation algorithm, when an SDN switch outsources its data.Then, the experimental results will be analyzed. In Figure2, the time cost of the system changes with the increase of the number of controllers in the control plane. It is obvious that when there are more controllers, the computational cost of the system will be higher. However, when there are more controllers in the control plane, the system will be more secure in practical terms. Hence, for different applications, there exists a tradeoff between energy and security in the choice of the specific number of controllers. Figure 3 describes the computational cost of each algorithm in the verifiable outsourcing protocol in the data plane. It is clear that outsourcing the data of an SDN switch to the cloud costs about 0.018 seconds. Compared with the limited storage space in these switches, using 0.018 seconds to trade off on-demand and convenient storage service is worthwhile.Figure 2
The time cost of the anonymous protocol in the control plane.Figure 3
The time cost for algorithms of verifiable outsourcing protocol in the data plane.


## 6. Conclusion

In this paper, two protocols are proposed to realize anonymous control and cloud based data protection in SDN. The first protocol in the control plane employs the ring signature technique, which makes the controller anonymously command the process of data transmission over the SDN switches. The second protocol in the data plane employs the storage services in cloud computing, which extends the limited storage space of SDN switches. Moreover, the data outsourcing is secure enough for its verifiability. Finally, the evaluation demonstrates the correctness, security, and efficiency of our protocols.



---

*Source: 9845426-2018-01-29.xml*