# A Robust Security Architecture for SDN-Based 5G Networks
## Robust Security Architecture of SDN-Based 5G Networks
### Security Architecture  
In this subsection, we will demonstrate our security architecture, which is illustrated in Figure 3. In this figure, we can see that the authentication process has two ends. The left end is the SDN devices, which is a switch of an SDN control. The secret store in each device consists of three parts: a unique ID, a preload hash table \(H_{i}\) given by the back-end and a synchronized secret \(s_{i}\). The secret is a random number that is changed every time the device requests building a communication channel. During an authentication, the back-end first verifies the device's ID. If this number is valid, the back-end will then check the hash value from \(H_{i}\) by using \(s_{i}\) as hash seed. If this number matches the hash value given by the hash table and seed stored for this device in the back-end, the device passes the authentication and then builds a communication channel. After the authentication, the back-end will generate a new secret and load it into the device. An attacker can pass the authentication only after (1) eavesdropping the secret \(s_{i+1}\) in the former authentication and (2) knowing the hash function preload in the devices. We say that meeting the two requirements is difficult since, if the device has a hash value from an outdated secret, it indicates that this request is from an attacker. Next, we will detail how to add this authentication in the SDN-based 5G architecture. Figure 4 illustrates our security architecture. As we can see, we add the security gateways (SGW) and security entry (SecE) in the SDN architecture. SGW refers to the gateway that serves as the point of decryption and encryption for the network. SGW can relay authentication messages between SE and data plane switch (DPS). SecE refers to the back-end in Figure 3. It will maintain the hash tables and hash seeds of all devices and provide authentication when building the communication channel. Here, we note that we use the SGW to relay the authentication message instead of letting the SecE communicate with the 5G devices directly. This SGW can combine the messages from devices and then transmit these messages to the SecE. In such a way, we can lower the load of SecE, accelerating the authentication process as a consequence. Since we add the SGW, the authentication process is a little different from \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Channel Types** & **IP Spoofing** & **MITM Attack** & **Replay Attack** \\ \hline Control channel & \(\surd\) & \(\surd\) & \(\surd\) \\ Data channel & \(\surd\) & \(\surd\) & \(\surd\) \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Security problems in 5G networks. the basic authentication scheme illustrated in Figure 3. In the following, we will respectively detail the authentication in the control channel and the authentication in the data channel. We first introduce our authentication scheme in the control channel. The authentication process is illustrated in Figure 5. As we can see, the DPS first transmit an authentication request \(M_{1}\) to SGW, M1 consists of two parts: the device's hash value and ID. After receiving \(M_{1}\), the SGW will combine the current authentication requests, and then send the combination \(REQ\) to the SecE. After that, SecE verifies the hash values in \(REQ\) and then sends the authentication messages \(ACK\) to the SGW. Finally, the SGW will relay the authentication messages to the DPS. If the DPS passes this authentication, it will update its secret and build the control channel with SDN controllers. On the contrary, if the DPS doesn't pass this authentication, it will do nothing or request again. We then introduce our authentication scheme in the data channel. The authentication process is illustrated in Figure 6. As we can see, the data channel is built between DPS1 and DPS2. Thus, we need to verify both of them to guarantee the security of this channel. In this figure, DPS1 first sends authentication request \(M_{1}\) to DPS2, and \(M_{1}\) is made up of the device's ID and associated hash value.