Abstract
Compared with the classical structure with only one controller in software-defined networking (SDN), multi-controller topology structure in SDN provides a new type of cross-domain forwarding network architecture with multiple centralized controllers and distributed forwarding devices. However, when the network includes multiple domains, lack of trust among the controllers remains a challenge how to verify the correctness of cross-domain forwarding behaviors in different domains. In this paper, we propose a novel secure multi-controller rule enforcement verification (BlockREV) mechanism in SDN to guarantee the correctness of cross-domain forwarding. We first adopt blockchain technology to provide the immutability and privacy protection for forwarding behaviors. Furthermore, we present an address-based aggregate signature scheme with appropriate cryptographic primitives, which is provably secure in the random oracle model. Moreover, we design a verification algorithm based on hash values of forwarding paths to check the consistency of forwarding order. Finally, experimental results demonstrate that the proposed BlockREV mechanism is effective and suitable for multi-controller scenarios in SDN.
1. Introduction
Software-defined networking (SDN) is more agile by means of network programming [1]. With the development of edge computing and artificial intelligence (AI) technology, AI-enabled SDN provides users with a variety of applications [2]. Compared with the classical SDN network with only one controller, multi-controller framework can provide a new type of cross-domain forwarding network architecture with multiple centralized controllers and distributed forwarding devices and has more benefits of flexibility and scalability. It can overcome some drawbacks of classical SDN, such as weak computing power, limited scalability, and high load of the single controller. Clearly, it is very important to verify the correctness of cross-domain forwarding rule execution by using cryptology primitives or statistical knowledge, which is referred to as rule enforcement verification. It ensures the validity of cross-domain forwarding behaviors and maintains perfect network status, so as to offer better service-level agreements (SLAs) for clients and meet the needs of customized services.
However, multi-controller rule enforcement verification technology still faces some security challenges. First, it lacks the trust among controllers. Forwarding verification in each domain is managed by its own controller. If the controller is compromised, the entire network will be subject to single-point failure attack. Adversaries can issue false messages to deceive the controllers in other domains [3]. Second, it has less privacy protection for entities on the forwarding path. For example, the public identities of switches are easy to be selected and determined as attack targets (e.g. middle-man attack). Lack of index value protection for a forwarding path can lead to the disclosure of the switches' forwarding order [4], and the path deviation attack [5]. Third, controllers need to collect outcomes of rule enforcement generated by switches in its domain and maintain traceability, which require more storage space [6]. These operations cause heavy load and high communication consumption to controllers [7]. Execution result of cross-domain forwarding functionality in SDN is a critical factor determining the quality of service (QoS), which motivates us to study multi-controller rule enforcement verification in SDN in this paper.
Recently, some verification schemes in SDN have been proposed in [8–10]. These schemes mainly focused on the verification algorithms to verify dynamic flow policies and analyze service vulnerabilities. Every change of forwarding behaviors will be checked in the real-time verification process, which increases network computing overhead. Many cryptographic techniques are used in authentication schemes [3, 5, 11, 12], such as message authentication code, hash function, and Merkle hash tree. However, these schemes increase the relative latency of the network and the overhead between switches and controllers. Moreover, they are based on the assumption that the controller is trustworthy, which is not practical in the multi-controller network.
Blockchain technology provides a decentralized and distributed network, in which nodes that do not trust each other can still interact successfully [13, 14]. Many schemes [15–17] have applied blockchain technology into SDN, such as Cochain-SC scheme adopting smart contract technology in multi-domain SDN to resist against DDoS attacks. Although the existing studies in [18–20] resorted to the blockchain technology to record all network events, the design of multi-controller rule enforcement verification models still has some challenges when we combine SDN with cryptography and blockchain technology: (i) how to improve the synergistic effect between centralization in SDN and decentralization on blockchain network to optimize network efficiency and security; (ii) how to design the verification scheme to be more efficient and accurate; and (iii) how to protect the privacy of entities and flows on the forwarding path.
To address the above challenges, we propose a novel secure multi-controller rule enforcement verification (BlockREV) mechanism in SDN to guarantee the correctness of cross-domain forwarding. We first leverage blockchain technology to reduce controllers’ load and provide privacy protection for controllers and switches by broadcasting transactions with their addresses rather than real identities. Moreover, we use tags as flows’ pseudonyms so that the real information of flows can be hidden. A provably secure aggregate signature scheme is designed by cryptography primitive technology to guarantee the effective verification accuracy of multi-controller rule executions. Furthermore, we present a verification algorithm to ensure the correct index of forwarding nodes in each domain through checking the address sequence of switches. The nested hash method of forward paths is used to verify the correct order of operations among domains.
The main contributions are summarized below.(i)We propose a novel blockchain-enabled multi-controller rule enforcement verification mechanism in SDN, named BlockREV. We adopt the consortium blockchain technology to provide traceability and privacy protection for forwarding operations and solve the problem of mistrust among controllers.(ii)We provide an address-based aggregate signature scheme on cryptography primitives which is provably secure in the random oracle model. Only designated verifiers can verify signatures signed by switches on the path, so as to provide protection of entities’ privacy and index privacy.(iii)We present a verification algorithm based on forwarding path hash values to check the consistency of forwarding order by means of comparing index values of switches in actual path with that in the configured path.(iv)The security analysis shows that BlockREV is secure and can resist many kinds of attacks. Performance evaluation demonstrates that our proposed scheme is effective and suitable for multi-controller scenarios in SDN.
The rest of this paper is organized as follows. Section 2 presents some related works on rrule enforcement verification schemes and aggregate signature algorithm. In Section 3, we describe the problem statement. The construction of BlockREV is shown in Section 4, and security analysis is given in Section 5. Section 6 provides the performance evaluation and result analysis. Section 7 concludes this paper.
2. Related Work
In this section, we review the related works, which can be summarized into the following three aspects: rule enforcement verification schemes in SDN, rule enforcement verification schemes on blockchain, and applications of aggregate signature algorithm.
2.1. Rule Enforcement Verification Schemes in SDN
Rule enforcement verification process is an important stage to confirm on the correctness of the rule execution and guarantee the quality of the forwarding service in SDN. Accordingly, there are many works on the rule enforcement verification. A forwarding path verification mechanism was proposed to flag forwarding path by the controller with a custom probe packet [12]. In [10], a validation scheme, named TrustTopo, was used to analyze service vulnerabilities. Furthermore, it adopted the technology of asynchronous rollback to verify a host location and the chaotic model for link verification. In [9], the layer design between controller and network devices, called VeriFlow, achieved the real-time verification of potential violation of key network invariants with a novel incremental algorithm to verify dynamic flow policies. In [3], a multi-controller architecture was proposed with distributed rule store for SDNs with Merkle hash tree to detect rule modifications. However, these schemes increase the relative latency and overhead of controllers. In particular, checking each change of forwarding behaviors in real time results in a large amount of network computation overhead.
2.2. Rule Enforcement Verification Schemes on Blockchain
Blockchain is a decentralized and distributed peer-to-peer network. There are some research studies which integrate blockchain technology and SDN. In [7], the authors introduced a distributed cloud architecture based on blockchain and SDN to provide secure and low-cost computing infrastructure in IoT, in which end-to-end delay is minimized between computing resources and IoT devices. In [21], a new authentication approach was proposed using blockchain and SDN techniques to remove unnecessary re-authentications in repeated handover which is appropriate for 5G network among heterogeneous cells. In [22], a new model, called SDIoBoT, was presented leveraging SDN architecture and the blockchain technology in 5G network, in which an elliptic curve digital signature algorithm was designed to ensure non-repudiation and integrity of the communications in the model. In [17], a blockchain-enabled architecture of controllers was proposed with an efficient authentication method to eliminate the overheads of the traditional blockchain, in which the cluster structure with a new routing protocol was designed to optimize energy consumption and enhance security in IoT. However, these existing research studies do not fully consider energy consumption issues; furthermore, the security proof of cryptographic primitive algorithms needs to be supplemented.
2.3. Applications of Aggregate Signature Algorithm
An aggregate signature scheme compacts a signature set into one short signature to reduce the overhead of verifiers. In [23], an aggregate signature scheme based on bilinear maps was proposed firstly to reduce the size of certificate chains and message size. In the literatures on the improvements of aggregate signature schemes, there are two types: certificate-based schemes [24–26] and certificateless schemes [27–30]. In [31], the authors proposed a certificate-based sequential aggregate signature scheme, in which each node aggregates the previous node’s signature and its own information to obtain a new signature. Aggregate signature is aggregated by signers in the specified order, and the order of signers is the key factor for validation. In [32], an aggregate signature scheme based on bilinear pairings with only one designated verifier was proposed to provide privacy protection for signers, which is a certificateless scheme that does not need certificate storage and public key verification. However, sequential aggregate signature scheme is not suitable for the scenario with multiple controllers because it will expose the information of all the previous forwarding nodes and the index value of the paths. Furthermore, we need more designated verifiers in the process of cross-domain forwarding.
3. Problem Statement
In this section, we outline the system model, adversary model, and security assumption. For convenience, some important notations used in the paper are summarized in Table 1.
3.1. System Model
Traditional cross-domain verification solutions may result in single-point failure, high-level overhead, and high maintenance cost. Our new verification model has the following characteristics: unforgeability (compromised entities cannot cheat others by means of blockchain technology), anonymity (entities publish transactions using pseudonymous address), security (the scheme is robust for various attacks), and efficiency (compared with related verification methods, it is more effective).
In this paper, our proposed verification mechanism is inspired by Bitcoin system [33] and the aggregate signature scheme with only one specified verifier [32]. We consider that basic multi-controller architecture is flat, in which each domain decorates only one controller and some switches for its local network. Controllers in different domains intercommunicate through east-west interface, and they are managed by administrator which serves as the master controller. Our proposed decentralized verification system model consists of four parts which are divided into application plane, block-controller plane, data plane, and management layer, as illustrated in Figure 1. Participants involved in the model will be elaborated as follows.(i)Switches: switches in the data plane are controlled only by the controller in its domain. They are lightweight nodes with finite computing power which are responsible for forwarding flows and publishing forwarding transactions with their signatures on the blockchain. Switches are semitrusted nodes, which may be compromised by adversaries to do malicious behaviors.(ii)Controllers: distributed controllers in block-controller plane undertake the function of maintaining the local network in their own domains. They are the core of the architecture linking applications and network hardware equipment. Every controller manages switches by means of standard southbound APIs (e.g., OpenFlow [34]) and communicates with application layer through standard northbound APIs. They act as simplified payment verification (SPV) notes on the blockchain just like that in the Bitcoin network and validate transactions published by switches in their own domains without caring for that in others.(iii)Administrator: administrator node in the management layer is the manager of the block-control plane. It can obtain global information of multi-controller network and customize cross-domain forwarding rules for flows. Administrator node also provides a service of registration for entities and flows in the blockchain network. In addition, it is responsible for verifying the correctness of cross-domain forwarding behaviors, which is the key factor to guarantee the QoS of multi-controller network.(iv)Verichain: Verichain is a consortium blockchain network, which stores forwarding transaction information and verifies the correctness of the enforcement of forwarding rules. It has the following functions. Rule execution message storage—Verichain stores rule enforcement messages broadcasted by entity notes. It is responsible for recording and forwarding transactions generated by switches and confirming forwarding transactions generated by controllers and the administrator. Rule execution verification—administrator and controllers are qualified to verify the correctness of rule execution results on the basis of distributed ledgers. A special design of signature algorithm in this paper ensures the validity of the verification authority. Ledger update—Verichain expands its distributed ledger with blocks and reaches consensus to record the network status of SDN in real time. By updating the ledger to record the operation behaviors of entities, the execution of flow rules in the network can be monitored.
All entities in SDN are the nodes on Verichain. The administrator is a full node and keeps the whole blockchain information. Although controllers and switches are lightweight nodes, their functions are different. Controllers validate forwarding behavior information of switches in its domain, while switches only publish forwarding transactions and are not responsible for the validation.
3.2. Adversary Model
The adversary aims to destroy rule execution behaviors and pass the verification with attacks as follows.
Type 1 (Single-Point Failure Attack). The controller is a key component of the centralized domain, the compromise of which will cause serious interference in forwarding activities and reduce the availability and reliability of services.
Type 2 (Middle-Man Attack). Anonymity easily leads to a middle-man attack in which the adversary may pretend to be a legitimate controller or switch to perform malicious operations.
Type 3 (Path Deviation Attack). Malicious behaviors of attackers make the flows unable to be forwarded according to forwarding rules in many ways, e.g. switch bypass, path detour, and out-of-order traversal [11].
In this paper, we make the following assumptions:(i)The communication channels among entities are secure, and hash functions are one-way and collision resistant.(ii)Administrator is an honest node managing the entire network. Controllers and switches are relatively credible, which might be compromised in a minority. Additionally, no collusion exists between controllers and switchers.(iii)Adversary cannot obtain the master key of the system but can replace the addresses of legal switches.
4. Construction of BlockREV
In this section, we present the construction of BlockREV mechanism. We first briefly overview the designed mechanism. Then, we present system initialization stages and forwarding process in BlockREV, respectively. At last, based on the nested hash value method and aggregate signature theory, we design the verification scheme of cross-domain forwarding.
4.1. Overview
Controllers and switches register through administrator to gain authority for the admittance of consortium blockchain network. They obtain their addresses and partial private keys in the registration process. These entities communicate anonymously with each other using their addresses without revealing their real identity information on Verichain. This anonymous approach provides better privacy protection. After the system initialization phase is completed, flows are forwarded by the relevant switches in the domain. When the destination node receives these flows, it sends a request to the controller for forwarding out of the domain. Then, the controller confirms whether forwarding rules of flows have been executed correctly in its domain; if so, it submits the cross-domain forwarding request to the controller in the subsequent domain. After two controllers communicate with each other, they issue forwarding instructions to the related switches, and a new round of forwarding by switches begins in the subsequent domain. In order to ensure the correctness of forwarding behaviors, the controllers and the administrator are responsible for verifying the forwarding behaviors in the intra-domain and the cross-domain, respectively.
In our system, we suppose that flows will be forwarded between two domains and . Forwarding among more domains can be inferred in the same way. When the flow proposes a cross-domain forwarding requirement, customizes forwarding rules for which will be sent to relative controllers and switches. Verichain network stores every forwarding message in the form of transaction, and the correct forwarding actions are guaranteed by verification schemes with cryptography technology.
4.2. System Initialization
The system initialization process in BlockREV comprises three stages: system parameter setting, entity registration, and flow registration.(i)System Parameter Setting. The administrator node generates system parameters. Let additive group and multiplicative group be two cyclic groups with the prime order , and is the generator of . The bilinear pairing is . The collision-resistant cryptographic hash functions are , , and . chooses a random number , and let be the public key and denote the master key. The system parameter is .(ii)Entity Registration. The SDN structure in this paper includes multiple domains, and the i-th domain includes one controller and several switches , where is the domain serial number and is the index of the switch in the i-th domain. Entities including controllers and switches register on Verichain through administrator node . They are configured with unique partial private key for signing. Specific steps of registration of a switch are shown in Algorithm 1, in which the function is a wallet address generation algorithm which is the same used in Bitcoin network. After that, sends the information to , where is the identity of switch , is the public key of , is the registration timestamp of , is the address of on Verichain, and is the partial private key of generated by . Then, the controller stores and sends this information to switch . The registration process of is similar to that of switches, except for replacing with , and saves into its entity registration list , where is the identity of , is the public key of , is the registration timestamp of , is the address of on Verichain, and is the partial private key of generated by .(iii)Flow Registration. There are two types of flows, single flow and multiflow, which will be configured cross-domain forwarding rules by the administrator node after registering on Verichain. Suppose that source host sends the flow to switch in domain . Switch searches its forwarding list and does not find the flow ’s forwarding rules; then, it sends a cross-domain forwarding requirement to controller . After controller has received this requirement, it sends the information vector , to the administrator node Admin, where Tf is the registration timestamp of f. After accepting , administrator node computes the hash value and gets the tag value and then saves in its flow registration list. According to the global network status, administrator node formulates cross-domain forwarding rules with an ordered set of addresses , where denotes the forwarding rule with an ordered set of switches’ addresses on the forwarding path in .
We assume that the forwarding rules are in and in , and the corresponding set of addresses is , where and , . and are source switches, and and are destination switches in their domains. Administrator node computes , , and . It updates its forwarding list by . Finally, administrator node sends to , and to , respectively. Controllers and then install flow rules at related switches in their own domains through a standard control channel.
When there are flows to be forwarded with the same forwarding rules at the same time, administrator node will compress their tags into a single node in the registration process, and then multiple flows will be forwarded in batch processing.
|
4.3. Forwarding Process in BlockREV
As shown in Figure 2, the forwarding process in BlockREV includes three phases: intra-domain forwarding, cross-domain forwarding, and forwarding to destination host. Specific phases are described as follows.
4.3.1. Intra-Domain Forwarding
In this phase, the flow will be forwarded from source switch to destination switch in domain or from source switch to destination switch in domain . After forwarding rule configuration of the flow by the controller, the related switches start forwarding. After completing the forwarding, switch generates a forwarding transaction with its signature and publishes it on Verichain. An illustration of block data structure and transaction information is shown in Figure 3. The specific verification algorithm of forwarding order and aggregate signature scheme will be described in Section 4.4. When the flow reaches switch , cross-domain forwarding phase will start. After the flow reaches switch , it will be forwarded to the destination host in the last phase.
4.3.2. Cross-Domain Forwarding
In this phase, the flow will be forwarded in cross-domain manner from switch to switch between domain and domain . When the flow arrives at switch in domain , switch sends an out-domain forwarding request to controller . As a domain manager, controller checks whether the flow has been forwarded correctly in its domain or not. It firstly verifies whether the order of switches in is correct in or not. Then, controller checks the validity of signatures signed in forwarding transactions by switches on the forwarding path. The specific validation process will be explained later. If the verification is passed, controller aggregates signatures made by switches in into one signature and sends it to administrator node for the whole path verification. The specific verification scheme will be described later. Controller publishes a confirmed forwarding transaction on Verichain; after that, sends the cross-domain forwarding request of the flow to controller .
When controller receives the request from controller , it searches its forwarding list to find forwarding rules of . If it makes, controller checks transactions published by controller on Verichain to confirm whether forwarding behaviors in domain have been verified by controller . If the confirm information in is Yes, controller gives an affirmative response to controller with the address information of source note and dispenses the forwarding instruction to . Otherwise, rejects and communicates the situation to . If receives the affirmative response from , it responds to that f should be forwarded to . Then, receives and begins a new round of forwarding. The specific cross-domain communication process is shown in Figure 4.
4.3.3. Forwarding to Destination Host
In this phase, will be forwarded from to the destination host. When reaches , sends an out-domain forwarding request to . As a domain manager, verifies rule enforcement just like has done. After receiving the aggregate signatures sent by and , will verify whether the cross-domain forwarding rules have been implemented correctly or not. It first checks the correctness of the forwarding node order and then verifies the validity of two aggregate signatures, respectively, to guarantee the quality of forwarding service. The specific validation process is described later. After that, publishes a confirmed forwarding transaction on Verichain. When the source host or the destination host wants to estimate the correctness of forwarding behaviors in SDN to ensure the security of in the process of transmission, he may look up the confirmed forwarding transaction about published by through any full node on Verichain.
4.4. Validation Process in BlockREV
In this section, we design appropriate forwarding verification schemes for controllers and administrator based on the nested hash value method and aggregate signature theory. The technology of cryptography and blockchain is combined with SDN to ensure the correctness and effectiveness of the verification scheme. We will describe the verification process in two scenarios: intra-domain verification and cross-domain verification.
4.4.1. Intra-Domain Validation
In the intra-domain forwarding phase, controller traces forwarding transactions about on Verichain, which have been published by switches in its domain. First, verifies whether the forwarding order of switches is consistent with that in its memory. It calculates the hash value of the public key in the subsequent transaction in order to compare the result with the output address in the current transaction. If they are equal, it concatenates the output address into . After making sure that the order of switches in all adjacent transactions is correct, calculates the hash value . By comparing it with the hash value , can confirm whether the forwarding order of switches in its domain is correct or not. Specific steps are shown in Algorithm 2. Second, checks individual signatures signed by switches in and then aggregates all signatures into a single one which will be sent to for cross-domain validation. The specific steps of individual signatures verification will be explained in the aggregation signature scheme later.
|
4.4.2. Cross-Domain Validation
In the process of forwarding to destination host phase, looks over the information on Verichain and obtains all forwarding transactions associated with published by switches in different domains. First, judges whether the cross-domain forwarding order of switches is correct. It verifies the forwarding order in and , respectively, and then it verifies whether the equation holds or not according to the information in and . If it holds, calculates the nested hash value . By comparing it with the hash value , can confirm whether the forwarding order of switches in multiple domains is correct or not. Specific steps are shown in Algorithm 3. Second, verifies aggregate signatures from and to effectively ensure the validity of the multi-controller rule enforcement verification.
Our proposed aggregation signature scheme is defined by six polynomial-time bounded algorithms: Setup, Key-Gen, Individual-Sign, Individual-Verify, Aggregate-Sign, and Aggregate-Verify. Specific steps are described as follows:(i)Setup. inputs the security parameter and outputs the system parameter , where is the public key and is the master key.(ii)Key-Gen. In the entity registration process, obtains its partial secret key , and obtains its partial secret key .(iii)Individual-Sign. For , let . chooses a random number and computes , , , and . Then ’s individual signature is .(iv)Individual-Verify. is responsible for verifying signatures in its domain. For signatures , , , performs the following steps:(a)Tracing on Verichain for all operating transactions associated with in and judging whether the order of addresses is the same with that in , as shown in Algorithm 2.(b)Verifying the signature of on . calculates , , and . Checking whether the equation holds or not. If it holds, accepts .(v)Aggregate-Sign. For accepted individual signatures given by distinct switches on , where or , calculates and generates the aggregate signature .(vi)Aggregate-Verify. completes the verification of aggregate signatures which are generated by and , respectively. When receives , it performs the following steps:(a)Tracing all the operating transactions associated with on Verichain and judging whether the order of transactions is the same with , in order to ensure that the sequence of forwarding nodes is correct. The trace process is similar to that in Individual-Verify step, except for the extra validations and needed to be done, as shown in Algorithm 3.(b)Computing , and and checking whether the equation holds or not. If it holds, accepts the aggregate signatures .
Because of the properties of bilinear pairings, we can conclude that the aggregate signature scheme mentioned above is correct.
If multiple flows are assigned with the same forwarding rules simultaneously, the batch verification technique is adopted to improve the efficiency of validation operations in our mechanism. The tag of batch flows is , which will replace in the above scheme to perform batch verification.
|
5. Security Analysis
We adopt the adaptive chosen-message security model to prove our algorithm. In this model, given a designated address, the adversary wants to obtain the existential forgery of an aggregate signature.
Definition 1. Bilinear map: let and be an additive cyclic group and a multiplicative cyclic group, respectively, with the same prime order , and is a generator of . Let be a bilinear map such that which has the following properties:(1)Bilinear: for all and , (2)Non-degenerate: , where is the generator of .(3)Computable: for all , is efficiently computable.
Definition 2. Computational Diffie–Hellman (CDH) problem: Given as input, compute for unknown .
We say that CDH problem is -hard if there is no algorithm that can solve the problem with probability no more than in time at most .
Definition 3. An aggregate signature scheme is existentially unforgeable under an adaptive chosen-message model, if for all probabilistic polynomial-time adversaries , there is a negligible function for the advantage such that wins if his advantage, , is non-negligible. His aggregate signature is valid and non-trivial, i.e., does not inquire about the signatures of at least one message under the designated address.
Definition 4. A forger is an aggregate signature scheme in BlockREV with the adaptive chosen-message model if: makes at most , and queries to the hash function, at most queries to the partial secret key oracle, at most queries to the full secret key oracle, at most queries to the address replacement oracle, at most queries to the signing oracle, runs in time at most with at most users, and is at least .
Definition 5. An aggregate signature scheme in BlockREV is against existential forgery if there is no adversary it in the adaptive chosen-message model.
Theorem 1. If there exists a forger that can the aggregate signature scheme in BlockREV by non-negligible probability , an algorithm can solve an instance of CDH problem in polynomial time with non-negligible probability . Here is the time of a scalar multiplication in , is the time to compute an inverse in , and is the natural logarithm base.
Proof. Algorithm simulates a challenger. Assume that is given an CDH problem instance and will interact with as follows to compute . Let be the target victim, and the detailed process is as follows.
Setup: sets the system parameters—, public key . are three random oracles controlled by . Then, sends to .
Queries: maintains empty list , , , , , , , and simulates the oracle queries in the following types.(i): upon receiving the entry , performs the following:(a) checks whether existing or not. If so, sends to .(b)Otherwise, generates a random coin so that . randomly selects . If holds, computes . If holds, computes . responds to with and saves into the hash list .(ii): upon receiving the entry , checks whether existing or not. If so, sends to ; otherwise, randomly selects , computes , sends to , and saves into the hash list .(iii): upon receiving the entry , checks whether existing or not. If so, sends to ; otherwise, randomly selects , sends to , and saves into the hash list .(iv): upon receiving the entry , performs the following:(a) checks whether existing or not. If so, sends to .(b)Otherwise, makes on . If holds, computes . If holds, computes . responses to and saves into the partial secret key list .(v): upon receiving the address , performs the following:(a) checks whether existing or not. If so, sends to .(b)Otherwise, makes on . If holds, aborts and outputs . If holds, randomly selects and makes on . Then, responses to and saves into the full secret key list .(vi): randomly selects , computes and , and sends to for the replacement of any original legitimate address. saves into the list .(vii): upon receiving the entry , performs the following:(a) checks whether existing or not. If so, computes and sends to .(b)Otherwise, randomly selects and computes and . responds to with and saves into the sign list .Forge. After adaptive queries, outputs the aggregate signature on and , in which the messages are all distinct, and at least one address does not perform the full secret key query; furthermore, does not make sign-query.
If , outputs failure and halts. Otherwise, let , and proceeds only if and for , . Since the aggregate signature is valid, it must satisfy verification equation (2), and we can getThen, outputs as the solution of CDH problem.
Suppose that(1)Event represents that does not output at and stages.(2)Event represents that generates a valid aggregate signature forgery.(3)Event represents that does not abort at the forge stage.The probabilities of solving the CDH problem by are as follows:Therefore,When three events have all happened, algorithm can successfully solve the CDH problem with a non-negligible probability’s extra time cost includes that for computing at most one scalar multiplication in on each , , and and three scalar multiplications on each . After the forgery operation is completed, the time cost should be plus at most the time for computing scalar multiplication in and an inverse computation in . Therefore, can solve an instance of CDH problem in polynomial time .
We have the conclusion that assuming the CDH problem is hard, the proposed aggregate signature scheme in BlockREV is existentially unforgeable against adaptive chosen-message attacks in the oracle model.
We next show security properties of BlockREV mechanism in the context of typical attacks.(i)Resistance to single-point failure attack: the information on blockchain is transparent and tamper resistant. When a controller is compromised, the administrator can still verify the forwarding behaviors by tracing the transactions on the blockchain and determine the reliability of the controller.(ii)Resistance to middle-man attack: due to the cryptography theory, transactions published by malicious switches cannot pass signature verification. Because the controller can only verify signatures of switches in its domain, a malicious controller cannot obtain the information about path index and switches’ identities in other domains.(iii)Resistance to path deviation attack: based on public forwarding address information in transactions, the order of forwarding nodes is verified by controllers to ensure the correct execution of forwarding. Through nesting method of forwarding path hash values, the administrator guarantees the correct index of different domains. In addition, our novel aggregate signature scheme provides the security in cryptography technology.
6. Performance and Evaluation
In this section, we evaluate the performance of our algorithms in terms of computation cost and communication cost compared with other existing schemes.
6.1. Analysis of Computation Cost
We compare the performance of the aggregate signature scheme in BlockREV with two related aggregate signature schemes [27, 35] and adopt the computation evaluation method proposed in [30] using the MIRACL cryptographic library [36], in which the experimental platform is an Intel I7-4770 processor (3.40 GHz) with 4 GB RAM, and the operating system is Windows 7. The aggregate signature scheme in BlockREV is simulated on the elliptic curve , where and are 512 bit and 160 bit prime numbers, respectively.
Some notations about cryptographic operation execution time are listed as follows.(i) denotes the time for a bilinear pairing operation , where , .(ii) denotes the time for a scale multiplication operation in the bilinear pair, where and , .(iii) denotes the time for a point addition operation in the bilinear pair, where , .(iv) denotes the time for a hash-to-point operation in the bilinear pair, which maps a string to a point of , .(v) denotes the time for a general hash function operation, .(vi) is the number of individual signatures.(vii) denotes the length of a group element in , bytes.(viii) denotes the length of element. bytes.
The comparison of computational costs is performed between the related aggregate signature schemes [27, 35] and our scheme in three aspects: Individual-Sign, Individual-Verify, and Aggregate-Verify. The specific comparison results are presented in Table 2.
As shown in Figure 5, for the computation cost of the individual signature algorithm, we can conclude that both Gao et al.'s scheme [35] and Gong et al.'s CAS 2 scheme [27] pay more running time than ours. For the total execution time, the percentage improvement of our algorithm over Gao et al.’s scheme and Gong et al.’s scheme (CAS 2) is about and , respectively. Our individual signature algorithm reduces one hash-to-point operation in the bilinear pair compared with the above two schemes, which takes more than 4 ms to run. Due to the low cost of computing in the individual signing process, BlockREV is feasible for SDN environments in which switches as signers have limited computational ability.
For the execution of the individual verification algorithm, Figure 6 shows that as the number of signatures increases, the computation cost of ours is smaller than that in Gao et al.’s scheme and Gong et al.’s scheme (CAS 2). In the aspect of individual verification algorithm design, Gao et al.’s scheme has one more bilinear pairing operation and one more hash-to-point operation than our scheme, which results in an additional 2.1210 ms for each signature verification. Therefore, BlockREV is more efficient in individual signature verification and will be better suited to the controller which consumes a huge computation cost to manage its domain.
As shown in Table 2, for the execution of the aggregate verification algorithm, the computation cost of our scheme is close to that of Gong et al.’s scheme (CAS 1) [27]. The reason for the above result is that in the process of verifying aggregate signatures in our scheme, the administrator is the only legal verifier with the authority to verify aggregate signatures of different domains. Each signature contains the information about the public key of the administrator, which leads to higher computational overhead. As a manager of the whole network, the administrator has strong computing power and can bear such computing overhead.
Figure 7 shows a comparison between non-aggregate signature and aggregate signature. With the increase of the number of switches, the time of verifying the signature one by one increases rapidly which results in high computation cost. When the number of switches increases to 20, non-aggregate signature verification takes 159.6811 ms more than aggregate signature verification. The aggregate signature scheme can reduce a lot of computing overhead for the verifier; therefore, it is suitable for the administrator node in the case that the cross-domain forwarding path contains a large number of switches.
6.2. Analysis of Communication Cost
Table 3 shows the communication cost of the aggregate signature scheme and related aggregate signature schemes [35, 37]. We can see that the aggregate signature length of all schemes is increased with the number of individual signatures. The length of the aggregate signature in our scheme is less than that in Shim’s scheme and less than that in Gao et al.’s scheme.
As shown in Figure 8, the communication cost of our scheme is obviously smaller than that of the above two schemes; therefore, our proposed aggregate signature scheme can effectively improve the communication efficiency.
7. Conclusion
In this paper, we propose a blockchain-enabled multi-controller rule enforcement verification mechanism in SDN, called BlockREV. The mechanism adopts an address-based aggregation signature scheme with the cryptography technology and can securely store and share forwarding information with the blockchain technology. We also present the implementation results and prove the security in the random oracle model. The BlockREV mechanism can be used in many scenarios in which nodes have limited computation power, such as Internet of things and smart grid. In our future work, we will find more efficient aggregation signature constructions requiring less computation cost and design zero-knowledge proof schemes for forwarding rule verification with perfect privacy protection.
Data Availability
The experimental data used to support the findings of this study are included within the article.
Conflicts of Interest
The authors declare that they have no conflicts of interest.