Secure Software Defined Networks Controller Storage using Intel Software Guard Extensions

The SDN controller is the core of the softwaredefined network (SDN), which provides important network operations that needs to be protected from all type of threats. Many researches have been focusing on different layers of security regarding the SDN controller such as Anti-DDOS system or enforcement of TLS connection between the controller and the Open-vswitches. One of the major security threats targeting any program is the environment execution itself (e.g. Operating system and the hardware itself). Intel's Software Guard Extension (SGX) offers a sloid layer of security applied to applications by creating a Trusted execution environment. SDN controller relay on a storage module to keep sensitive data such as Flow Rules, users’ credentials and configuration files. Protecting this side of the SDN controller is a must in term of security. To date, no work has been conducted considering SDN controller storage security using Intel SGX. This paper introduces an SGX enabled SDN controller. The new controller ensures the integrity and the confidentiality in a trusted execution environment by leveraging a recent hardware technology called intel SGX. This technology provides a trusted and secure enclave. Enclaves are sealed and unsealed by intel SGX attestation mechanisms to protect the executed code and data inside live memory and disk from being altered by any unauthorized access. High privileged codes such as the OS itself is kept from altering data inside enclaves. We implemented the Intel SGX using the Floodlight SDN controller running a real enabled Intel SGX hardware. Our evaluation shows that the SGX enabled SDN controller introduces a slightly observable performance overhead to the floodlight controller compared to advantages in term of security. Keywords—Software defined networks; software guard extensions; storage; integrity; confidentiality


I. INTRODUCTION
In recent years, the network research community has experienced a period of intense activity that has led to the emergence of different architectures or paradigms such as the SDN. The centralization (logical or physical) of the control plan, had to bring the expected flexibility to the network applications and allow to respond to many concrete use cases.
Software-Defined Network is a new paradigm of network architecture that aims to design a data plane that is fully programmable and separated from the control plane [1]. The Control Plane manages decisions about how and where to transmit network traffic through system configuration, management and exchange of routing table information. The Data/Forwarding Plane manages the actual transmission of packets to the destination network according to the logic of the control plan. Behind this separation, there are three main objectives:  The separation of network intelligence (control plan) from equipment (data plan).
 The provision of a logically centralized view of the global physical network.
 Providing an abstraction of programmable network equipment using Interfaces of application programming (API).
Among the innovations of this new paradigm is the programmability of network equipment and applications. New network applications can be transparently programmed and deployed using standard APIs. However, its implementation in the data plane remains one of the greatest challenges for research.
Protecting sensitive data from been altered or access gained by any authorized manner is present since the beginning of the programming time, a challenge that many have taken the race to solve it [2]. SDN technology has been introduced to solve the complexity of configuring network hardware. SDN enabled networks relay on a central decision making called the SDN controller to handle request coming from network devices such as switches and routers [3], [4]. Those requests are transported via API's using open flow protocol [5] and optionally secured using TLS.
The SDN controllers represent the most delicate part of the SDN architecture as it consists of the brain of the network, making it vulnerable to all sort of attacks [6], [7]. Security issues may vary depending on the level of interest targeted by a malicious person; it goes from Denial of service to traffic redirection and flow rules modification [8]. The SDN controller software is run on vast untrusted platforms, including operating systems, hypervisors, firmware, and hardware. This large machine base is growing complex and difficult to verify. For e.g., an OS such as Linux has 17 million line of code, however 662 vulnerabilities related to CVE have been recorded in 2019, such as memory corruption, transverse directory, unauthorized code execution. Execution 476 | P a g e www.ijacsa.thesai.org of normal and security-critical applications running on shared resources controlled by untrusted computing machines raises security threats. Running the SDN programs in such environments represent a considerable threat to its normal operations.
To solve the issue, one of the solutions is Trusted execution environments (TEE). TEE guarantee security by relying on less hardware and software computing base. Hardware is commonly considered to be a stable base since the cost and sophistication of hardware attacks usually are high. This has lead to the development of a secure running environment by industrial hardware companies for a safety-critical application that maintains little reliance or less dependency upon the operating system and hypervisor. Up to today, we found two main technology which are ARM Trust Zone Technology, Intel Software Guard Extensions (SGX) [9][10].
The objective of this work is to propose a secure architecture by programming new modules and adding security functions at the control plan storage based on Intel SGX. Then, evaluate the impact of SDN architectures at the performance level.
The rest of the paper is organized as follow. The next section will include a background and related works followed by the proposed model to secure SDN controller storage using Intel SGX, then we present the results of the implementation with discussion. Finally, we conclude this work with a conclusion and perspectives for future work.

II. BACKGROUND
Trusted Execution Environment (TEE) is a tamperresistant computing ecosystem that works on a separate kernel. It guarantees the validity of the executed programs, the security of the runtime components (e.g. memory, CPU registers, and critical Input / Outputs) and the secrecy of the executed code, data and runtime states are maintained in nonvolatile memory [11]. In addition, the remote certificate shall be given to show its trustworthiness to third parties. The contents of TEE are not static; they can be changed safely. TEE condemns all software-related threats as well as hardware threats against the main memory of the operating system. Attacks leveraging backdoor authentication bugs are futile. Fig. 1 illustrates the difference between a Trusted execution environment and an ordinary OS.
The most common TEE environments are Intel SGX and ARM TrustZone [12]. Both Intel SGX and ARM TrustZone are hardware TEE environments, but the process behind building a trusted environment with trusted code is distinct. Intel SGX provides a trusted environment for trusted programs that run on top of current untrusted device software. Whereas, ARM TrustZone is building a new, trusted ecosystem for trustworthy applications that operate on trustworthy device software and hardware that are only accessible to the trusted Configuration.
In this paper we focused on intel SGX technology to deploy our secure SDN controller. The Choice of using Intel SGX was taken depending on the much benefit that supersede ARM TrustZone, benefits such as documentation, maturity and the availability of hardware enabled machines. The majority of researchers uses Intel SGX to deploy a trusted execution environment.
Intel Software Guard Extensions (Intel SGX) provides hardware-based memory encryption to isolate portions of code and application-specific data in memory. Intel® SGX allows user-level code to assign private memory regions (called enclaves) designed to be protected against processes running at higher privilege levels. Only the Intel® SGX solution provides such a granular level of control and protection.
Intel SGX has been used to secure flow tables inside Open-Vswitches as mentioned in related works.   (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 11, No. 10, 2020 477 | P a g e www.ijacsa.thesai.org SGX is built to be reliable; this is done in a variety of ways, including robust enclave delivery, sealing and attestation. Intel summarizes SGX's protections [13], [14] as follows;  Memory is secured against observation and modification from outside the enclave, using an in-die Memory Encryption Engine (MEE) [15], with a secret that rotates on every boot. This protection notably works against host hypervisors, other enclaves, and anything running in supervisor mode.
 Enclaves will attest or confirm their identities to a competitor with the aid of a permanent hardware identification key for asymmetric encryption.
 Computer calls are designed to schedule and pass power in and out of the enclave. Arguments are safely mapped according to the concept of a static enclave.
 SGX does not protect itself against reverse engineering or side-channel attacks: to counteract this is the responsibility of the client.

III. RELATED WORKS
There are only a few works in the literature that discuss SDN security using SGX. Intel Software Guard Extensions (SGX) has provided the general purpose of the hardwareassisted TEE referred to as Intel SGX. Intel SGX is an expansion of the x86 architecture with a new range of security-related instructions [16]. These instructions are used by security-critical programs to create a hardware-assisted trust environment referred to as an enclave [17]. Intel SGX enclave maintains secrecy through hardware-maintained data layout and honesty tests by encrypting data and code when it is outside the CPU package [18]. Intel SGX is a centralized security architecture, and the trustworthy TCB computing foundation is known to be a CPU package.
TruSDN is a mechanism for bootstrapping confidence in the technology of SDN [19]. Supports the safe supply of switches in SGX enclaves, a protected communication channel between switches and SDN controllers, and secure communication between endpoints.
Trusted Click [20] investigates the viability of network processing in SGX enclaves. Although none of the above methods discusses the credibility and anonymity of OpenFlow flow tables, they can be complemented by OFTinSGX to accomplish this. SCONE allows operators to protect the secrecy and integrity of computing in containers against host root access adversaries [21]. An alternative approach to securing virtual network functions running in containers, which prevents the unnecessary expansion of the trusted computing foundation, is proposed in [22]. Event Controller Eviction mitigates DoS attacks and OpenFlow Application overflow [23]. This framework uses two different frameworks the learning module and the flow control modulewhile the case handler system prevents overload and DoS attacks, the OpenFlow flow tables have no security guarantees. OFTinSGX maintains the integrity and confidentiality of OpenFlow tables and the reasoning for forwarding and disposal procedures.
TLSonSGX guarantees that OvS authorities retain communication with SDN controllers and the cryptographic material they use [24]. This methodology can be paired with OFTinSGX to provide broader security assurances for OpenFlow switches. Fig. 3 shows the TLSonSGX system design. In recent works OFTinSGX has been proposed by [9], which has four components: SGX OpenFlow table, SGX rule structure, SGX Eviction component, and SGX tables dpif, which helps OvS to delegate its OpenFlow tables and forward logic to enclave memory.
The important limitation of this work is that the abstraction of only the contents of the OpenFlow flow tables does not address all security concerns, as the classifier only includes references to the classification rules. The procedure used to control the OpenFlow flow tables can cover both the contents of the tables and the full description of the rules assigned to the untrusted memory.

A. SDN Storage Module Overview
This section presents the design and the architecture of the proposed model to secure SDN controller storage using Intel SGX.
Generally, the SDN controller is relying on a storage module that handles all sensitive data; controller data are mostly configuration files such as flow rules. In our case, we use the floodlight SDN controller to implement our approach. Fig. 5 illustrates the Floodlight architecture. The proposed model consists of rewriting the storage module code taking into consideration the Intel SGX technology. www.ijacsa.thesai.org The storage module consists of four main modules: link discovery module(responsible for discovering and maintaining the status of links in the OpenFlow network), Device manager module (tracks devices as they move around a network and defines the destination device for a new flow), Static flow entry pusher (allows a user to manually insert flows and groups into an OpenFlow network) module and QOS module(give a user a way to simply push QoS state to switches that support these features) interacting with the primary storage module which is mainly a NoSQL database residing in the random-access memory. Fig. 6 shows the interaction between the four-module and the storage module.
A compromised host can present a huge issue to the NoSQL database making it vulnerable to several attacks such memory dump or memory exhaustion attacks. Our method consists of hardening all the space used by the NoSQL database by implementing the Intel SGX technology to prevent any damage to the RAM area used by the SDN controller.

B. SDN Enabled SGX Architecture
SDN enabled SGX model operates as an intermediate system. Specifically, it executes a process daemon that intercepts all the call made to the ordinary storage module by the controller application. These calls are translated into corresponding functions of the SDN enabled SGX model enclave. For instance, when a new open flow rules need to be inserted, the call is made via our interface and call the corresponding function inside the enclave via a JNI (Java Native Interface). The code residing in the enclave return the right value depending on the result of the function via the interface. In this design, all the data structures related to the file system are continuously kept in the Enclave Page Cache(EPC), which is a subset of DRAM that cannot be directly accessed by other software, including system software and SMM code. The CPU's included memory controllers also reject DMA transmissions targeting the EPC, thus protecting it from access by other peripherals.
The NoSQL database files are maintained by the enclave and protected by the encryption mechanisms of the SGX technology, making a dump of the memory useless as its encrypted and cannot be read.
Data is decrypted by the SGX unsealing mechanism: this process occurs while entering the enclave and is thus secured by the CPU borders. Consequently, a dump of the EPC (enclave page cache) would be captured and blocked by the SGX protection mechanisms.  (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 11, No. 10, 2020 479 | P a g e www.ijacsa.thesai.org

A. Implementation Setup
We implemented the SDN controller enabled SGX on a Linux platform holing an SDN controller named floodlight developed using JAVA programming language. Since intel SGX SDK support only C/C++ language, we used the Java Native Interface (JNI) to make the right call to C functions to handle intel SGX operations. The next scenario demonstrates the different phases of the implementation, this scenario is almost generic to any Intel SGX enabled case:  Step 1: An enclave is created by the untrusted part of the application.


Step 2: The enclave must be initialized via a launch token, fetched and provided by Intel's launch enclave.
 Step 3: Access to the LE and other architectural enclaves, e.g., the quoting enclave (QE) and the provisioning enclave (PE), is provided by the Intel application enclave service manager (AESM). SGX libraries provide an abstraction layer for communicating with the AESM.


Step 4: Execution of a trusted function which executes an ECALL.


Step 5: The ECALL goes through the SGX call interface to bring the executing thread inside the enclave.


Step 6: An OCALL is executed once the execution in the trusted environment completes.


Step 7: Finally giving the control back to the caller.
The program run on HP Proliant gen10 server with the following Configuration: To generate traffic we use mininet simulator [25], mininet was setup and configured on five different computers to be able to generate 2000 request by each one.
The written code mainly focuses on the Storage Source Service, which is the main interface of the storage module of floodlight controller, also some of the dependencies were taken into accounts such as IDebugCounterService and IRestApiService. Table I shows a summary of the code changes made to the storage module inside the floodlight controller. The most significant part of the added code consists of new (JAVA NATIVE INTERFACE) JNI interface and make files, floodlight storage also has been modified to accept the call from OCALL I/O peripherals.

B. Performance Analysis
Our evaluation is based on the scenario that involves a number of nodes making calls to the SDN controller. In this case, the network devices receive various request to dispatch packets from a script that run on several separated machines. Decision making is sent from the data layer represented by the network devices. Next, the controller responds with the corresponding flow rule. Rules present inside the Openvswitches are deleted, so the network devices are forced to make calls to the controller. The script sends over 10000 requests to several separated switches. The generated traffic sent to the controller allows us to take statistics and compare them to the normal scenario. A normal scenario consists of the same use case but with non-modified controller. Table II, Table II shows the Overhead interval between two test cases. The same parameters are kept during the two tests. The deference between the overhead in both runs is due to CPU consumption by the OS itself and other floodlight operations.

VI. CONCLUSION
The concept of SDNs or Software Defined Networks is an architecture that facilitates network management and control, and allows rapid introduction of network services through programming and separation of the control plane from the data plane. With this new architecture, administrators can manage the network in a unified way from the control plane, and can introduce or eliminate any service through the application plane without changing the physical infrastructure. New network applications can be transparently programmed and deployed using standard APIs. Most modern SDN controllers can run on any OS However, its implementation in the data domain remains one of the biggest challenges for storage security at the control plane level.
In this work, we proposed using Intel SGX to provide additional security to the general intent of the Execution Environment of applications.
In order to evaluate the performance impact of our SDN enabled Intel SGX architecture we implemented our SDN controller model enabled SGX on a Linux platform holing an SDN controller named floodlight. The results of our model implementation show the efficiency of our model without any major cost in term of performance.

VII. FUTURE WORKS
As a perspective, we would like to test our model in large test platforms to estimate its capacity and limitations and compare it to the TEE provided by ARM named ARM Trustzone.
Other evolution will be conducted on other point of views such as using intel SGX to build the entire application instead of the storage module alone. Prof. Abdelkrim HAQIQ was a chair and a technical program committee chair/member of many international conferences and scientific events. He was also a Guest Editor and Co-Editor of special issues of some journals, books and international conference proceedings. From January 1999 to December 1999 he had a Post-Doctoral Research appointment at the department of Systems and Computers Engineering at Carleton University in Canada. He also has held visiting positions at the High National School of Telecommunications of Paris, the Universities of Dijon, Versailles St-Quentin-en-Yvelines and LAAS CNRS, Toulouse in France, the University of Ottawa in Canada, the FUCAM in Belgium, the National Engineering School of Sfax, Tunisia, the University of Naples Federico II, Italy and the University of Algarve, Portugal.