Securing ADS-B Data on the DeFli Blockchain with Format Preserving Encryption.
As many a follower knows, at DeFli Network we propose that ADS-B and ADS-C data are adopted as the integration model for combining unmanned aircraft in to traditional airspace management. Indeed we are at the forefront of producing SDR and interface based technologies that enable automated conversion of RemoteID packets and data obtained from passive radar in to ADS-B format packets. The below article describes how we are utilizing our own blockchain in conjunction with SDR Receivers within our “DeFli Devices” to solve the issues associated with the low-level of security found in ADS-B. We utilize Format-preserving (F), Feistel-based encryption (F), with multiple implementation variances (X) (FFX) algorithms, for enhancing ADS-B’s security. The offered solution is implemented in a standard software-defined radio (SDR) ADS-B to be utilized in real-time applications. Furthermore, the DeFli blockchain scheme is used as a secured database to manage the cipher key.
ADS-B
The ADS-B system broadcasts an aircraft’s identification, position, velocity, and intent to other aircraft and ground stations. However, the introduction of these new technologies in the aviation industry has introduced new network weaknesses linked to their internet connection and the compatibility between systems.
Certain technological advancements, particularly the introduction of Software-Defined Radio (SDR) systems, enable attackers to utilize low-cost RF transmission and receiving. ADS-B transmits data in an open, unencrypted format to allow other aircraft to be informed of the sender’s location via receiver relay or direct messaging. On the other hand, accessibility had been a safety requirement. Therefore, it lacks protection features, rendering it susceptible to a variety of assaults, these are outlined below:
Passive Attacks: Eavesdropping and Jamming
Active Attacks: Message Injection, Message Deletion & Message Modification
This article covers the design and implementation of our secured ADS-B (DeFli ADS-B) system using a software-defined radio (SDR) architecture as found in our DeFli Devices (https://www.defli.xyz/defli-device). It highlights the hardware architecture and configuration, the format-preserving encryption (FPE) scheme, and shows how our blockchain technology can be used for leveraging ADS-B security and how our DeFli Device functions as a receiver with extension to ADS-C (DELINK) devices acting as proxy transceivers.
Design and Implementation
(DeFli ADS-B) offers a solution for key exchange. Format-preserving (F), Feistel-based encryption (F) with multiple implementation variances (X) is referred to as FFX. The FFX algorithm, DeFli ADS-B implementation, and blockchain-based key exchange solution are described below.
FFX Algorithim
The Feistel structure serves as the foundation for all FFX algorithms, including FF1 and FF3–1, which have been established as the US National Institute of Standards and Technology (NIST) standard.
A Feistel structure is created when reversible transformation is repeated numerous times, known as “rounds”. The transformation is divided into three phases. First, data is divided into two segments, and a keyed function named the round function is applied to one segment of the data. For the next round, the roles of the two parts are switched to alter another segment of the data. The function F generates a repeatable hash-like value by using a user-specified symmetric block cipher.
Two strings of characters serve as the input (and output) data for each round; for FF1 and FF3–1, these strings will be numerals. The two strings are equal in length, and n represents the overall number of characters. The round function, denoted by FK in Round i, is applied to one of the input strings, marked by Bi, with the extra inputs of length n, tweak T, and round number i. By applying modular addition — indicated by the plus sign ⊕ — on the numbers the strings stand for, the result is utilized to change the other string, denoted by Ai. A temporary variable called Ci is used to name the string that represents the outcome number. For the following round, the names of the two components are switched, resulting in the modified Ai, or Ci, becoming Bi + 1 and Ai becoming Bi + 1.
The Feistel structure for encryption and decryption is nearly interchangeable. There are three variations:
I.
The order of the round indices is changed;
II.
The roles of the two components of the data in the round function are switched, so that, in addition to n, T, and i, Ai + 1 (instead of Bi) is used as the input to FK, and Bi + 1 (instead of Ai) is combined with the output to produce Ai (instead of Bi + 1)
III.
Modular addition is changed to modular subtraction (the output of FK from Bi +1).
The solution outlined employs the NIST standard format-preserving encryption techniques FF1 and FF3–1.
FFX Scheme Implementation
The below image illustrates the structure of the airborne position message. The downlink format (DF), capability (CA), ICAO address, payload, and parity identity (PI) are the five fields that make up the 112 bits (14 bytes). The DF field, which has a constant value of 17, describes the message format (10001 in binary). These bits do not undergo encryption, allowing position reports to be recognized in every message. The other fields may be secured. To make it simpler to provide byte-aligned input, the downlink format and capability fields remain unencrypted, since they are constant in airborne model. Fifty-two (52) bits are equally distributed across the A and B parts of the message and can be used as a Feistel-based encryption function. However, encrypting the ICAO address field is also proposed as a possible solution to conceal information by disconnecting the link between the ICAO address field and other fields.
FFX encryption and decryption functions must be added in the ADS-B In systems. The image below illustrates DeFli ADS-B In subfunction blocks. ADS-B Out signals are the input of the message receiver function (DeFli Device). After demodulation, preamble pulse detection and enhanced bit detection blocks detect preamble pulse and data bits, respectively. In this phase, the detected burst of data is decrypted by using the FFX algorithm and the symmetric key. It should be noted that the data input of the FFX algorithm is one of the above test scenarios for 14, 13, and 8 bytes. The 112 bits of data can thus be verified as CRC error, and in case of error, the corresponding correction is applied. The message is ultimately decoded and displayed.
Blockchain Based Key Exchange
The below image shows the blockchain network topology for key and data exchange. Node 1 is considered as the validator and thus can add each node to the network and assign private and public keys to each node for data exchanges. Other nodes use the public key of node 1 to encrypt data based on the RSA scheme and publish it via the MQTT protocol to the validator, Node 1, which receives the information and decrypts the data via an RSA private key, and then the data is stored in the blockchain nodes. In addition, an FFX encryption/decryption key is encrypted by admin node according to each node’s corresponding public key, and it is published to the node. Thus, every node receives the key via a secured channel.
The DeFli ADS-B blockchain model is used to share the encryption key among nodes (ADS-B systems), and the frequency of the key updating will secure the system confidentiality and integrity. In addition, the blockchain system provides a data repository in order to update information for each ADS-B Out data, and the receiver can verify the received data from the air with blockchain data and perform authentication. Therefore, the proposed model addresses the confidentiality, integrity, and authenticity concerns.
The network topology for the DeFli ADS-B Blockchain is as follows:
Light Nodes- Acquire Time-Series Data from DeFli Device Ground Stations with Celestia DA acting as the oracle. These nodes encrypt the data via RSA scheme and publish via MQTT. Light nodes perform encryption using PoS mechanism with $FLI token acting as the stake.
Validator Nodes- decrypts the data sent via an RSA private key, and then the data is stored in the blockchain nodes.
