DeFli Blockchain Protocol: FFX Based Encryption & Format Preserving Protocol for Air Traffic Data.

We covered the types of attack that the ADS-B messaging protocol is susceptible to in our last story. What follows here is our network design that offers enhanced security and privacy for ADS-B messaging through th use of FFX cryptography, our node/ receiver network and cipher keys. We also show how the UAS industry can use this methodology for safely merging in to traditional ATC via ADS-B without overloading the network.

At present, all commercial and freight aircraft are fitted with ADS-B transceivers, this allows for ADS-B out and ADS-B in transmissions. As things stand, ADS-B is an unencrypted broadcast protocol and as such the message transmissions can be captured and/or targeted by simple ground based equipment (think of elonjet or the Taylor Swift- superbowl frenzy).

Our proposal is to use FFX encryption (Format-preserving, Feistel-based encryption of multiple instances) to encrypt the ADS-B out messages broadcast by aircraft. This would be delivered by a simple python script incorporated in to the ADS-B transceiver units.

Messages would continue to be broadcast using the same metric methodology and packet formation over the 978 and 1090MHz frequencies as per current requirements. This ensures no hardware changes are required for manufacturers.

The fundamental difference is that whilst these packets can still be received by the thousands of hobbyist receivers, they will be in an encrypted format and therefore rendered unreadable.

One of the benefits of FFX encryption is that it is reversible providing the node performing the decryption has the correct cipher key.

We propose that DeFli Devices operating on the DeFli Network are equipped with the cipher key required to decrypt the ADS-B packets.

As FFX retains the original packet format and structure, the decrypted packets will be identical to the original ADS-B message and therefore easily readable by ATC and their traditional systems (ARCTIC etc).

The DeFli Device will decrypt the ADS-B packet and place it’s contents on a private blockchain where it will be readable by any party who has acquired the rights to view from DeFli Network.

To ensure transmission continuity we propose the following:

A unique validation method known as “Proof of RSSI”. In layman’s terms, the DeFli Device with the highest RSSI between itself and each individual aircraft earns the right to place the transaction on chain and earn the associated reward. An aircraft switches between DeFli Devices autonomously based on it’s signal strength (RSSI) with secondary and tertiary DeFli Devices acting as back-up if a device is unable to process the transaction on our L3 blockchain. This allows the protocol to leverage the long range of the 1978–1090MHz spectrum whilst ensuring strong coverage, globally.

Data rights can be acquired based on specific filters such as ICAO numbers, aircraft type, operational area and altitude.

Incorporating UAS

UAS can be incorporated in to the above protocol in different ways depending on their broadcast type.

If the UA is broadcasting packets on Rf (Enhanced WiFi, Occusync, LTE, Zigbee, C-Band, BLE etc) then DeFli Devices are able to obtain the message packets directly and convert them in to an ADS-B format. Operators could choose if to encrypt their messages at source via the same python script. The DeFli Device would then perform the encryption protocol before passing the packet on to a validator node that would perform the decryption and post to blockchain for reading by verified sources. One core consideration for this would be to allow each UA to obtain their own flight specific ICAO reference under the PIA protocol with the PIA database for UA’s being managed by DeFli under an encryption protocol delivered again by FFX.

If the UA is broadcasting “dark” i.e. not by Rf then the DeFli Device and it’s incorporated CCN Forward Scatter Analysis is able to deduce enough information about the UA to populate an ADS-B packet, this will include the assignation of an ICAO reference under PIA to the UA (allowing for on-going tracking).

Congestion

To mitigate any potential issues with network congestion by incorporating UA’s in to ADS-B we propose a methodology that limits the broadcast frequency of UA’s when operational conditions specified by the DeFli UTM C2 protocol dictate. This is in conjunction with our AI processes for prediction of flight paths and movements based on the information obtained from either the Rf message packets or the forward scatter analysis. Under this protocol, UA’s would be tracked only by forward scatter analysis providing they had already been identified at least once under the ADS-B protocol at an earlier stage. Again “Proof of RSSI” would be utilized to determine the processing node.

Further Implementation

We are currently testing the migration of this model to ADS-C which would see aircraft and UA’s issued with “challenges” created by smart contracts on our blockchain and deployed by our C-Band DeLink station’s.

Contact us

Whether you have a request, a query, or want to work with us, use the form below to get in touch with our team.