Security
Objectives of the Project
The purpose of this project is to demonstrate various security protocols that are designed to mitigate a wide range of threats on next-generation networks including 5G. With 5G encompassing a broad area of new use-cases such as vehicular communication, massive machine-to-machine communication in industrial IoT settings, it has become imperative to secure these networks against adversarial threats. In particular, threats on vehicular communication and M2M communication can lead to catastrophic consequences, if not dealt with at the design stage. Thus, as part of this 5G testbed development, we will first demonstrate standard security protocols such as authentication between UE and core network, encryption of payload by using prescribed modules from the standard bodies. Subsequently, we also demonstrate novel security protocols that aid in securing device-to-device communication in next generation networks. All the security protocols have been demonstrated using a network of XBee devices, Raspberry Pis and software defined radios
Demonstration of 5G AKA protocols
Demonstration of Physical- Layer Key Generation using RSSI Data from Devices
Demonstration of Physical-Layer Key Generation using I/Q Data from SDRs
Setup to Demonstrate Network Provenance Protocols
Scope
In order to capture a strong use-case for 5G networks, we have envisaged a vehicular network scenario that apply a 5G based architecture for radio access fronthaul and backhaul. Towards that end we consider a network of UEs that play the role of mobile vehicles in a given geographical area. The backhaul network is such that the core network is connected to several road side units (RSUs) and gateway nodes such that the vehicles within a given area authenticate with the core network through the gateway nodes. Upon authentication the vehicles can exchange messages with the RSU using the 5G architecture. The vehicles can also exchange messages with each other without the intervention of the RSUs thereby providing the much needed low-latency features for communication. For this setup, our project provides a number of security protocols to mitigate several threats. The main security features include
- Secure authentication between the UE and the core network using the 5G AKA protocol
- Secure authentication between the UEs for UE-to-UE communication using public-key cryptography
- Secure key exchange mechanism between the UEs using classical crypto-primitives such as Diffie-Hellman strategy
- Secure key exchange mechanism between UEs using novel physical-layer strategies
- Security against a wide range of integrity threats for multi-hop communication from the UEs to the RSU
Depiction of 5G AKA between the vehicles and the
RSU under the 5G framework
Key generation mechanisms for device-to-device
setting under the 5G architecture
Framework for neighbor discovery and device-to-
device authentication under the 5G architecture
Network provenance module to mitigate integrity
threats in multi-hop communication from the UEs to
the RSU.
Functional Requirements
The main functional requirements are
- A UE that is already registered with the network must be able to connect with the core network. In other words, network access must be available.
- An Adversary must not be able to either impersonate an UE, or eavesdrop on the communication between a UE and the base station.
- An adversary must not be able to execute integrity threats or replay attacks on the messages transmitted between the UE and the base station.
- A UE must be able to successfully authenticate another UE registered in the network through the framework of device-to-device authentication. In other words, an adversary must not be able to impersonate as a UE, eavesdrop on the communication between UEs, or execute integrity threats or replay attacks on the device-to-device communication between the UEs.
- The UEs must be able to generate shared secret keys dynamically using low-computational capabilities. The UEs must be capable of extracting keys from the common randomness in the wireless channel between the other UE. They must posses all the functional blocks to execute advantage distillation, information reconciliation to generate identical keys.
- The UEs must have the capability to communicate with the RSU in a multi-hop manner. In addition, the UEs must be able to deliver the footprint of information-flow to the RSU along with the packet. This feature is needed to mitigate a wide range of integrity threats during the packet flow in the network.
Testbed Description
Our testbed is build using a network of Raspberry Pis, Digi Xbee wireless devices, software defined radios (SDRs) and a few high-performance computing devices. The specific roles of these devices are listed below:
- The role of a UE is played by a combination of Raspberry Pi and a XBee device. The former is used for computing purposes, whereas the latter is used for communication purposes. Although the XBee devices communicate in the ISM band with limited payload capability, we have used these to implement security algorithms that are usually agnostic to the physical-layer architecture. All the protocols implemented on these devices can also be applied on 5G compatible devices in future.
- The role of RSU is played by a high-performance computing device which is again connected to a XBee device for receiving the packets from the UEs. It is given higher computation capability as it has to perform various integrity threats during the provenance recovery process.
- Another combination of XBee device and Raspberry Pi plays the role of gateway unit or a public key infrastructure. This is assumed to be connected to the backhaul in order to facilitate distribution of public and private-keys to the UEs for authentication purposes.
- All the XBee devises are enabled with multi-hop communication so as to demonstrate the provenance embedding and provenance recovery methods.
- In addition to using XBee devices, the UEs in our testbed are also equipped with SDRs so that they can manipulate the physical-layer frame structure for the purpose of key generation algorithms. They have the capability to send signals and extract I/Q samples at the receiver. Subsequently, they have the capability to achieve consensus on the generated key either using the SDRs or using the XBee counterparts for public communication.
System Design
Before giving details on the design of the security modules, we provide the necessary details on Digi XBee devices that are used in the 5G testbed. We have used a family of radios by Digi International that has created an implementation of ZigBee standards on its chipsets called XBee. As the main deliverable, we have deployed all the security protocols by compressing the messages within the payload limit provided by the standard. We highlight that the choice of wireless devices (in terms of using XBee devices) and the radio-frequency band (in terms of using ISM band) are not the focus areas of this demonstration. Instead, the focus is on the implementation of 5G compliant authentication and other security related protocols, which could be seamlessly mounted on any off-the-shelf 5G compliant hardware platform. The XBee devices can be easily operated through standard Python modules as shown in Fig. 1 and Fig. 2. A typical architecture for interfacing a XBee device with a computing machine is also shown in Fig. 3. A sample snapshot of instructions to use the XBee devices for communicating with each other is also presented in Fig. 4 and Fig. 5.
Given that the packet structure of XBee protocol has limitations in the payload size, multiple rounds of packet transmissions were executed when using them for security protocols. The number of rounds of packet transmissions used for communication depends on the specific protocol. Such protocols included
- 5G AKA protocol for authentication between UE and the core network.
- Public-key cryptography-based authentication protocol for device-to-device authentication. RSA has been implemented for the public-key protocol.
- AES encryption methods for the purpose of confidentiality.
- Network provenance algorithms for the purpose of tracking the footprint of information flow.
At a high-level, the main entities of our testbed are (i) UEs, (ii) gateway nodes, and (iii) roadside units (RSUs) that play the role of gNodeBs (or base stations). The functionalities implemented in the devices depend on their roles. For instance, the UE that is capable of implementing the security protocols of the 5G testbed will have all the functional blocks. Similarly, the RSU which is capable of verifying the provenance will have all the required functional blocks. The main functional blocks of a UE include
- 5G AKA block for executing authentication with the core network
- RSA algorithm for executing encryption as well as authentication with the other devices
- AES algorithm for symmetric key encryption to achieve the confidentiality feature
- Consensus module to extract and generate secret keys through physical-layer channel
- Provenance embedding block, both when acting as the source node as well as the forwarding node in the multi-hop network.
- Diffie-Hellman Key exchange mechanism
Fig. 1: XBee devices and their interface through standard Python libraries
Fig. 2: Standard interfaces to work with XBee devices
Fig. 3: A typical architecture for interfacing a XBee device with a computing machine. In our testbed, we
have used Raspberry Pis as well as high-performance computing machines to interface with the XBee
devices.
Fig. 4: Typical instructions to interface with XBee devices for transmitting and receiving packets over the
ISM band
Fig. 5: Typical instructions to interface with XBee devices for transmitting and receiving packets over the
ISM band