A Security Authentication Protocol for Trusted Domains in an Autonomous Decentralized System

Software Defined Network (SDN) architecture has been widely used in various application domains. Aiming at the authentication and security issues of SDN architecture in autonomous decentralized system (ADS) applications, securing the mutual trust among the autonomous controllers, we combine trusted technology and SDN architecture, and we introduce an authentication protocol based on SDN architecture without any trusted third party between trusted domains in autonomous systems. By applying BAN predicate logic and AVISPA security analysis tool of network interaction protocol, we can guarantee protocol security and provide complete safety tests. Our work fills the gap of mutual trust between different trusted domains and provides security foundation for interaction between different trusted domains.


Introduction
Autonomous decentralized systems (ADS) have been extended and applied to a variety of domains [1][2][3][4][5][6].The main extension in ADS is to implement the dynamic management and to optimize the allocation of virtualized computing, storage, device controllers, and cyber resources.The current major platforms are mature in management and optimization of traditional computing and storage resources.However, the dynamic management and the allocation of ADS devices as cyber resources are a new problem which has not been studied thoroughly.The problem is mainly from network architecture design.The traditional TCP/IP architecture cannot meet the increasing demands, especially the virtualized network and ADS services.Thus, ADS needs new network architecture and techniques with flexibility, robustness, security, and credibility to solve the problem.
In the next generation network architecture design, many experts and scholars have completed a series of remarkable research work.Specifically, OpenFlow [7], introduced by Nick McKeown, gave researchers a way to run experimental protocols in the networks.Based on Software Defined Network (SDN) and OpenFlow protocol, researchers implemented network management and security functions mainly in the aspects of control, traffic forwarding, and load balancing.But the security issue in OpenFlow design should be thoroughly concerned, especially the security interaction function between different controllers' nodes.The problem of security certification issues between the different single controllers limits the interaction range of a SDN architecture, which is only used in a single domain with a single controller, such as the Data Center.
In order to solve secure interaction issues, experts and scholars have completed a series of research work.Reference [7] proposed the SANE network architecture in which logic controllers could provide secure authentication for device access and loading strategy.Moreover, [8] further extended SANE network architecture with data forwarding strategy 2 International Journal of Distributed Sensor Networks by using core controller method.The improved architecture implemented with data forwarding function, in a certain extent, could solve the security threats between controller layer and data forwarding layer.
Reference [9] implemented a new network architecture GENI and recognized that a large number of malicious attacks and flood attacks can be easily spread through logic control layers and data forwarding layers and lead to corresponding secure issues, for instance, DDoS attack.
Reference [10] evaluated the weakness of OpenFlow protocol.The author thought OpenFlow had an accurate secure certification method between controllers and switches, but this method did not provide security mechanisms under transport layer.
Based on SDN architecture, [11] did a comprehensive analysis for evaluating NOX, POX, Ryu, and Beacon [12][13][14][15] controllers in compatibility, reliability, security, and processing capacity.Focusing on the aspect of security, the authors pointed out that the reason to most controllers' security problems was forged stream message length, protocol version, or wrong type of message flow.
Besides, in [16], the authors analyzed the entire SDN security issues and pointed out that the new network architecture with a rapid response and antithreatening security mechanism was needed to be reestablished, especially in the differences of security threats between controllers and traditional network.
Based on the above issues, one of the key features of ADS is to allow content-based message broadcasting.In order to ensure the real-time system, message package could not be encrypted.The receiver node does not check whether the source address is valid or not, and whether the message package has been tampered or not.It means that an attacker can set up the entire attack in essentially one operation.While the security for ADS is drawing attention, it is an indisputable fact that there is a lack of effective methods to support those frameworks.The contributions of our paper are as follows: (1) Our paper introduces a new architecture to increase the probability of guaranteeing the credibility for future network architecture by applying the ideas of trusted network to ADS.The new architecture with trusted function modules can measure sensitive information and provide a security interaction function between different SDN domains.
(2) Based on the new architecture with trusted function modules, we propose a trusted domain authentication protocol that protects controllers' credibility among entire network architecture when communicating with a nontrusted third party.(3) We demonstrate security of our trusted domain authentication protocol by BAN logic and AVISPA security analysis system and perform a comparative analysis of our trusted domain authentication protocol against some prevalent protocols, namely, IKEv2 [17], IDAKE-MA, and SKAP [18], in performance analysis.We believe that the protocol performance, including calculating consumption and storage consumption, is an index which can give us obviously evidence to prove advantage of our protocol.
This paper is organized as follows.Section 2 introduces a SDN trusted domain network architecture and describes our trusted domain authentication protocol.In Section 3, we demonstrate security of our protocol by the BAN logic [19].In Section 4, we analyze security of our protocol with different malicious test scenarios by AVISPA security analysis system [20].Section 5 performs an analysis between our protocol and some authentication protocols.

Security Authentication Protocol for ADS Applications
As shown in Figure 1, we propose a SDN trusted domain network architecture which combines SDN and trusted computing.This architecture contains a single controller and a number of network devices.For solving the trust certification problem among trusted domains, we design some modules in SDN controller.TMM, based on TSS [21], is used to measure the sensitive information of SDN controller and connect network devices.Sensitive information includes controller platform hardware information, controller platform OS information, controller software information, and trusted function modules information.Controller Flow Rule (CFR) is trusted policy, including SDN data forwarding strategy and trusted measurement strategy, which was measured by TMM.Controller Communication Module (CCM) ensures controller authentication process between individual trusted domains.
In SDN trusted domain network architecture, we propose a domain secure certificated protocol between SDN trusted domains, and, in particular, our protocol can be utilized on nontrusted third party circumstance.From the viewpoint of the trusted chain [22], we can implement a consistency test of measuring information integrity about controller hardware, operating system, controller software, and CCM for trusted negotiation.After finishing trusted negotiation, we can adopt the method of multilevel authentication to guarantee security.More specific, controller authentication can be divided into two parts, controller platform authentication and controller software authentication, which protects the release of sensitive information and prevents unauthorized users from capturing sensitive information.The combination of sensitive information and random numbers, based on the strong protection of sensitive information, ensures that sensitive information is not being hijacked and not subject to replay attacks by unauthorized users, thereby avoiding the security of sensitive information by refusing the connection of those illegal or security risks.

Protocol Certification Process
Overview.Before we design our security certification protocol, we present the three major aspects of our protocol certification process.
First, in accordance with the trust chain transfer rules in trusted computing, the TMM is based on TSS and will follow the orders by measuring sensitive information of SDN controller hardware, operating system, CCM, and storing measurement results into RTS (Root Trusted Storage) of the PCR register.
Second, the controller platform certification: when implementing different trusted domain controller authentication, authentication requester sends the HMAC calculation results of hardware information, operating system, and random numbers to the receiver, respectively, and expects the identical HMAC result with the receivers.If the controller platform's HMAC result of the receiver is consistent with that of the requester, then we complete the certification process of controller platform.
Finally, the controller software certification: in terms of implementing the trusted authentication of sensitive information in controller software, the requester sends HMAC calculation results, including controller software metrics, core controller module metrics, and random numbers, to the receiver.As shown in the controller platform certification in Figure 1, the receiver will compare the controller software HMAC results with that of the requester.If their results are consistent, we complete the certification of the controller software.

Controller Platform Certification Process. Controller platform certification process consists of the following steps.
Step 1 ( (the requesting controller) sends an authentication request to  (the receiving controller)).First,  creates a digital signature for its own controller platform identity information Plat ID  , random numbers Nonce  , and hardware sensitive information  PCR 1 by its own private key.Then, the public key of  is expected to encrypt the HMAC value, and finally  sends the encrypted message to : (1) Step 2 ( receives the authorized information from ).
Step 3 ( receives the authorized information from ).First,  receives the verification feedback from , which is encrypted by the public key of , indicating that there is a trusted negotiation between  and .Second, Plat ID  could similarly implement its negotiated registration.Third, as shown in Step 2,  begins the credible verification with the hardware sensitive information of ; if the results are consistent,  can be trusted in hardware.Finally, if the verification passes,  will generate trust negotiation session random numbers; meanwhile  creates the negotiated private key and implements the next round trust negotiation. will sign sensitive information of controller platform operating system HMAC value and encrypt the sensitive information by session key.The negotiation fails when the verification is not successfully passed: Step 4 ( receives the HMAC sensitive information of the controller platform operating system  PCR 2 and key random numbers of , AK R ).First,  receives  PCR 2 and implements a credible verification, as shown in Step 2, with the operating system measurement result  PCR 2 of its own controller.Second, if the verification passes,  will produce a negotiated private key random number AK  .Then, using AK  , AK  , the pseudo random numbers, and function PRGF,  will create a controller software verification session private key AK, which is bound with the platform information of .Finally, 's platform sends the sensitive information HMAC value of  to .The negotiation fails if the credible verification is not successfully passed: 2.2.2.Controller Software Certification Process.In this subsection, we continue to explain the steps in certification process.These steps are related to the controller software certification process.
Step 5 ( receives the sensitive information HMAC value from the receiving controller platform operating system).First,  receives the operating system sensitive information from the receiving controller platform and implements a (3) {{ {{ ( 7) credible verification, as shown in Step 2, with the operating system measurement result  PCR 2 of its own controller platform.Then, if the credible verification passes, the trust negotiation will enter into the controller software verification process, and, therefore, session private key AK will bind the information of  and also sign the encrypted information through 's private key.Finally,  returns the signed information to .The negotiation fails if the credible verification fails: Step 6 ( receives the controller software verification request from ).First,  decrypts the information by 's public key, proving the existing base of the trust negotiation between  and .Then, using the decryption of the sensitive information HMAC value of the controller software,  implements a credible verification as shown in Step 2. If the credible verification passes,  will proceed a negotiated registration using the controller software information CS ID  of , encrypt the sensitive information HMAC value of controller software and the controller software ID through session private key AK, and sign the encrypted information through 's private key.Finally,  returns the signed information to .The negotiation fails if the credible verification is not successfully passed: Step 7 ( receives the verification information from ).First, as shown in Step 6, using the sensitive information HMAC value of the controller software, the receiving controller implements a credible verification as shown in Step 2.Then, if the credible verification passes,  will implement a negotiated registration using the controller software information of . encrypts the sensitive information HMAC value of  PCR 4 and Nonce  through session private key AK and signs the encrypted information by 's private key.Finally,  returns the signed information to .The negotiation fails if the credible verification is not successfully passed: Step

BAN Logic Security Analysis
According to the BAN logic security analysis, this section analyzes whether our authentication protocol is secure or not.

BAN Logic Security Analysis
. BAN predicate logic is composed of 10 basic syntax and semantic clauses: (1)  |≡   believes that  is credible.
(5) #(): message  is fresh, which means that  is temporary value and not the first to be sent as the information.
International Journal of Distributed Sensor Networks

BAN Logic Inference
Rules.This section describes the four main specific rules of BAN logic to provide a theoretical basis for SDN trusted domains security authentication protocol.⊢ is primitive symbol, such as  ⊢  representing that  derives conclusions . ( Explanation.If  believes that  has sent a (, ), then  believes that  has sent message .

SDN Trusted Domain Security Authentication Protocol's
Formal Presentation.In this section, we formalize SDN trusted domain security authentication protocol: International Journal of Distributed Sensor Networks 7 3.4.BAN Logic Security Goals.For security requirements of SDN trusted domains security authentication protocol, this paper sets up multiple security goals: (1)  |≡  |≡  PCR:  believes that  is credible to believe  PCR.
( model and OFMC system, based on constraint logic, and our protocol was analyzed by 4 states.So, the conclusion of our test is quite convincing.

Performance Analysis
5.1.Calculation Consumption.This section uses the authentication response time defined in [25] to evaluate the calculation overhead of the protocol.The authentication response time () is mainly composed of three parts: the authentication requesting platform computing time (  ), the authentication receiving platform computing time (  ), and the protocol transmission time (  ).The following relationship can be obtained through the above three variables: Thus, we define the authentication requesting platform computing time including operation overhead of HMAC, digital sign, and encryption and decryption.
Similarly, we define the authentication receiving platform computing time including operation overhead of HMAC, digital sign, and encryption and decryption.
In particular, we consider that the ideal transport network excludes the impact of network latency.According to the above definition, the calculation overhead of authentication protocol is mainly composed of HMAC, digital sign, message encryption and decryption, and the network transmission.As shown in Table 2, we make a detailed comparison between IKEv2, IDAKE-MA [26], and SKAP in this paper.
It can be seen in Table 2 that the authentication protocol of this paper has higher calculation consumption compared with other domain protocols.In particular, we propose a no third party certification method.So our approach has advantages in communication frequency, which effectively reduces the total number of communications and network overhead.Furthermore, the authentication protocol is based on trusted computing, which effectively protects the credibility of network domains, and the trusted authentication protocol could make more advantages in security.Last but not the least, the authentication protocol does not have index calculation.Compared with other protocols in Table 2, our approach could significantly improve computational efficiency and reduce the cost of computing.

Storage Consumption.
For the authentication protocol of this paper, we assume that the average frequency of the requester connecting to the receiver under random conditions is 1/ access , and the process of receiving request can be modeled as a Poisson process, where the average frequency is 1/ access .Using the receiver as an example, when the receiver receives a request message, the receiver needs to store the public key of the requester ( public ), the random number of the requester (Nonce  ), and the session key (AK) until the session is completed or the timer is over.We assumed the   time of wait timer is  lifetime , the response time of receiving the message is  req , and the packet loss rate of experiment network is  loss , and we derived that the storage average amount of the receiver is Assuming the time of the latency timer is two times that of the response message time, we can further simplify that the storage average amount of the receiver is  lifetime / access × ( loss + 1).
According to the above formula, on the one hand, if  lifetime and  access remain unchanged, the storage consumption is proportional to the network packet loss rate.If the network is stable and packet loss rate is not high, the authentication protocol of proposed in this paper does not require a low storage space to store data, and the storage consumption is in the ideal range.
On the other hand, as shown in Figure 3, if  loss remains unchanged, the storage consumption is proportional to  lifetime and  access .It means that if controllers' processing time is too long, the controller will continue to receive request, and thus the storage consumption will increase sharply.
So far we assumed that the  loss rate remains unchanged.We further perform a comparative analysis with IKEv2, IDAKE-MA, and SKAP.The results are shown in Figures 4,   5, and 6; our method has more advantages in terms of storage consumption.

Conclusion
In this paper, we introduced and demonstrated a security authentication protocol of SDN trusted domain in ADS applications and designed the trusted domain network architecture to solve the credential problem of SDN architecture.The trust negotiation concept with nontrusted third party is a prerequisite for communication between different SDN trusted domains in ADS applications.

Figure 3 :
Figure 3: The storage consumption of our method.
Plat ID  : authentication requester platform ID, (13)ACK: authentication successful symbol, (14) CS ID  : controller software ID of authentication requester, (15) CS ID  : controller software ID of authentication receiver, will create a digital signature for signing controller platform identity information Plat ID  , random numbers Nonce  , and hardware sensitive information  PCR 1 and correspondingly use the public key of  to encrypt them and send the result to .On the contrary, the negotiation fails: First,  receives the encrypted message including 's ID and  PUB from Step 1.Then,  will implement a negotiated registration by using 's platform identity information.And then, aiming at the hardware sensitive information in the 's platform,  implements a credible verification which uses PCR values of 's hardware sensitive information to make HMAC with Nonce  .If the HMAC result is consistent with  received information in Step 1, 's hardware is trusted.Finally, if the verification is completed, 8. First, receiving controller software application modules HMAC value of ,  implements a credible verification as shown in Step 2.Then, if the credible verification passes,  will encrypt the sensitive information HMAC value of  PCR 4 and Nonce (8)session private key AK and sign the encrypted information by 's private key.Finally,  implements a credible verification on application module sensitive information of , shown in Step 2. If the verification passes, the verification of the controller software will be completed and the controller verification will pass.Otherwise, the negotiation fails: →  : {{HMAC ( PCR 4 , Nonce  ) ‖ ACK} AK}  −1 .(8) Explanation.If  believes that 's public key is , and  has received the message {}  −1 which is encrypted by  −1 , we can infer that  believes message  which was sent by .Explanation.If  believes that  has jurisdiction for message , and  believes that  believes message , we can infer that  believes the message .Explanation.The above theorem states that if a subject has received a formula, and the main part knows the relevant secret key, we can infer that the body has received part of the formula.
Explanation.If  believes that message  is fresh, and  believes that  has sent message , we can infer that  believes that  believes the message .(5) Belief Rules Theorem 7. Consider  |≡  |∼ (, ) ⊢  |≡  |∼ .

Table 2 :
Comparison in the performance of protocols.