This project is designed to evaluate the protocol provided in "Ambit of Data Integrity- A Hierarchical Approach for the Internet of Things". It introduces 4 levels of data integirity and proposed a method based on contextual data integirty to choose between layers based on the verification requirements and contextula attrebiutes. The framework uses a combination of SDN and SDP. The protocol flow is desxribed below:
We discuss a framework to gather context variables, select the required ADI layer and store data and meta data in the cloud server(s) securely. We integrate SDN and SDP~\cite{sallam2019security,al2015sdsecurity,ekrebe2020security,singh2020multilevel} to meet the framework requirements. We chose Software Defined Networks (SDN) to allow us to partition and gather information to select the ADI layer appropriate for incoming data from a device. An SDN decouples the control plane from the data plane, pushes network management, policy application, decision making, security, routing and other services to the programmable controller software. Switches and routers are now simple forwarding devices that receive instructions from the controller, which has the global view of the network status. When a switch receives a flow, it compares the flow header against the flow table inside the switch -- if there is a match, it forwards the flow based on the matched rule; otherwise, it forwards the flow to the controller. The controller with a global view routes the flow and installs the proper rule in the corresponding switches. This advantage of SDN, that we require in the integrity verification process, is the flexibility of the rules in the flow table. The rules include two parts: match and action. The match part is compared with the flow header. For storing/retrieving data we need the ADI layer information in the header. The action part in the typical SDN network includes forward, drop, quarantine, etc. Here, to store/retrieve data we have to specify the correct verification process. %Therefore SDN is the environment that can addresses the distinct needs of integrity verification.
Devices, data owners, third party entities need authentication for access to the cloud servers; therefore, we chose the SDP~\cite{moubayed2019software,bilger2014sdp} as the architecture to authenticate users, devices and services. SDP creates an exclusive secure channel (e.g., Virtual Private Network (VPN)) between the communicating parties. In SDP, there are 3 main modules: SDP Initiating Host (IH), SDP Accepting Host (AH) and SDP controller (CTRL). The IH is typically installed on a client. The AH is installed on an SDP gateway and manages the communication between AH and CTRL, while CTRL is authenticating the user and creating a secure channel between the user and the service. The combination of SDN and SDP in IoT~\cite{sallam2019security} can address the security requirements for implementing ADI.
In our architecture, we integrate both SDN and SDP controllers and implement all of their required functionality in a single SDP-SDN controller. The \textit{SDP-SDN controller} authenticates the users, devices, services and creates a secure exclusive channel (e.g., VPN) between them and SDP-SDN switch (as in SDP controller) and also is responsible for partitioning the network, routing the packets and providing required services to the network elements using SDN applications (as in SDN controller). A partition can include: \textit{IoT devices} (devices that belongs to one user, devices in a residence, devices for monitoring an infrastructure). An \textit{SDN application} selects the suitable integrity verification process based on the security policies and contextual information. The \textit{SDP-SDN switch} forwards the packet based on its flow/policy table. If the host is not authenticated (matching rule for a packet does not exist in the table) the switch drops the packet, unless it is a valid SPA (Single Packet Authentication)\footnote{SPA requests authentication and connection, contains information such as host ID, requested service ID, gateway IP, timestamp, randomized data.}; the switch forwards the SPA to the controller to authenticate host, make a decision about the packet forwarding, install routing rule in the tables, share updated authorized host and services with switches and provide requested services such as deciding about the ADI layer. The \textit{Owner Gateway (OG) and Server Gateway (SG)} are both SDP-SDN switches (Fig.\ref{SDN-SDP}). It can simply be a residential SDN switch or it can even be a mobile phone with OVS and AH installed on it\cite{poularakis2017bringing}. An agent installed on the OG performs partially the functions of the controller. It gathers information and monitors the changes in the integrity ambit. The ADI layer (from Section~\ref{build-sec}) is defined by the cross-tabular set of parameters (from Section~\ref{idea-sec}). When a user wants to store new type of data in the \textit{cloud server}, the OG uses this context in the packet header, and sends it to the controller. The controller uses the flow header information and sends user defined policy" and ADI layer information" to the integrity verification application to select the suitable integrity verification process. The controller installs a new rule in the user gateway that defines the routing path to the cloud and the ADI is recorded.
When the network and devices are initially setting up, the gateways and servers and services are sending SPA and network access request and are being authenticated and registered in an SDP-SDN controller (steps 0-1,through 0-8 shown by dashed arrows and gray text). Each device generating data first communicates with the owner's gateway (SDP-SDN switch called OG here). 1) SPA (single packet authorization – used for identifying clients in SDP), data and meta data (update frequency, lifetime, tolerable latency and ID of the destination cloud server) reach the OG. 2) based on requested services in SPA, a questionnaire may be sent to the owner to gather information about owner (in the cased of ADI: permissions, data merit and storage affordability). 3) The owner responds. 4) OG Sends SPA, data and meta data to the SDP-SDN controller. 5) The SDN controller authenticates the owner and forwards the information to an ADI application. The ADI application uses the decision tree (Fig.~\ref{decision-tree}) to choose the suitable ADI layer. 6) The application responds with the required ADI level. 7) The controller provides information about authorized services and connection to the OG. The controller also installs the proper rules (includes the required level of ADI and route to SG) in the corresponding SDP-SDN switches (e.g., OG, SG ,etc.). 8) OG sends SPA to the SG and request connection to the cloud server(s). 9,10) SG opens the connection to the cloud server and responds to OG. 11,12) OG and cloud server(s) can now exchange information for the session (13). The data retrieval process is pretty much the same; however, when a third party wants to retrieve the data (user gateway - UG instead of OG) the SDP-SDN controller should communicate with the OG (and owner) to request permission to share the information with the UG. Once the third party retrieves the data, the OG has to verify the integrity using the correct ADI.
pox-messenger folder: This folder includes all the files in the pox/messenger directory in pox controller. It implements "ADI application". The decision tree is implemented in "MessageReceived class" in "init.py".
startl2.py calls the required modules form pox controller and also run pox messanger. The applictaion is implemented on pox messanger and is exchanging messages with SDN swicth through pox controller.
test_s1.py is implementing the controller agent on SDN switch. It is run by the switch to send contextual information to the ADI application through pox controller.
ADI.ipynb is a jupyter notebook file for analysing the dataset and choose a proper verifictaion method using ADI decision tree. The data set is provided by Zhongheng Zhang et al. and is available at: https://physionet.org/content/heart-failure-zigong/1.2/
Install POX controller https://github.com/noxrepo/pox
Install mininet
Copy the file "startl2.py" in pox/ext folder
Replace the files in folder messenger in pox/pox with the files inside pox-messeenger folder.
Run pox as ./pox.py startl2
Run mininet as sudo mn --topo linear,4 --controller remote
In mininet run s1 xterm, it will open another terminal for you. download the test_s1.py file and run it in this xterm terminal as python3 test_s1.py.