ADS-B has emerged in recent years as a viable alternative to current radio and RADAR standards in Aircraft signaling. Its advantages include superior location accuracy due to the use of Global Position System (GPS), ease of deploying and maintaining ADS-B stations compared to traditional RADAR
stations, and lower purchasing costs. Software-defined radio (SDR) is a technology that migrates hardware components to software, which enables developers to customize the desired functionality a radio should have. This technology has been applied to various fields and its use in air traffic control (ATC) research is causing the emergence of new promising protocols, including in ADS-B applications. Piracci et al. [21] describe the technical and hardware challenges to build an SDR device dedicated to ADS-B. However, these benefits did not eliminate ADS-B’s vulnerabilities related to its open clear-text broadcasting of messages. Several research efforts [1], [3], [18] demonstrated in a controlled and simulated environment that it is possible to launch attacks on ADS-B. These efforts were focused in demonstrating the vulnerabilities, and did not provide a systemic approach to detecting the attacks and focused instead on specific types of attacks. Few researchers aimed at proposing a comprehensive approach to thwart ADS-B attacks from a cyber-security view, such as in [4] and in [17]. Unfortunately, as we discuss below, neither approach is currently implementable. In previous work [6], [8], [9], we proposed different variants of a cyber-security module that verifies the authenticity and integrity of transmitted ADS-B messages. The module thwarts several message-injection attacks by using keyed-hash message authentication code (HMAC). The difference between the versions is the way the HMAC digest is generated and used to create the security metadata in place of the Cyclic Redundancy Check (CRC) field. The latter is used for biterror verification and can be easily broken. Also, in [7], we proposed a mechanism to securely exchange the keys used for the HMAC algorithm. We leveraged the fact that aircraft need to obtain authorizations from the entities governing the ATC zones included in its flight path before taking off. We made a simplifying assumption that these entities are referred to as the ATC centers. Then, we delegate the key negotiation to source ATC center, which initiates secure handshakes with the ATCs that control other zones in the flight path to exchange the secret keys over public key infrastructure (PKI) schemes. In this paper, we propose an Intrusion Detection System (IDS) for ADS-B signals by combining above described previous work with new techniques acting both at the ADS-B sender and receiver in order to strengthen the attack detection. This is achieved by assessing the cyber-physical environment of supposedly signaling aircraft. This IDS detects potential attacks and provides as a result artifacts that could be used for digital forensic analyses. The rest of the paper is organized as follows. Section II discusses the related work while section III describes the background information in ADS-B. Section IV describes the details of our proposed intrusion detection system. Section V provides experimental evaluation of our IDS system.
ADS-B BACKGROUND
ADS-B operates in two modes, namely, ADS-B Out and ADS-B In as shown in Figure 1. The former is deployed on aircraft that gets its location from the nearby satellite to make an ADS-B messages, modulate it using Pulse Position Modulation (PPM) before broadcasting it every second in the 1090 MHz band. ADSB-In is mostly deployed on ground components, i.e. ADS-B stations and ATC centers, that receive ADS-B messages from air crafts that are within transmission range, which is in the order of 150 nautical miles [12]. In practice, 1090 Mode S Extended Squitter is an implementation that supports ADS-B, where ADS-B data is encapsulated in Mode S frames as shown in Figure. The preamble is used for synchronization and the DF Format field indicates the protocol being used, where the 17 decimal represents ADSB. The capability bits indicate the sub-protocol in use and the International Civil Aviation Organization (ICAO) identifier uniquely identifies each aircraft. The CRC field is used for bit error verification. The ADS-B data occupies 56 bits of the 112 bits of Modes S frames and provide several information such longitude, latitude, altitude, velocity, etc. Each GPS location is encoded using two ADS-B messages: even and odd. This is due to the use of the Compact Position Reporting (CPR) [2] in order to encode and decode latitude and longitude using an optimal number of bits (17 bit for longitude and 17 bits for latitude, where 23 bits owuld be needed if plain binary encoding is used). The even/odd parity is used to divide the earth in longitudinal and latitudinal lines to determine the exact location. However, due to clear-text ADS-B messages broadcast, it is possible to use cheap hardware and launch ADS-B attacks. It is possible to download an open-source ADS-B receiver and relatively inexpensive radios to at least eavesdrop on air traffic. Besides, if the attacker has the ability to craft ADS-B messages and broadcast them on the 1090 MHz band, this can cause injection attacks that would create more problems.We developed an attack taxonomy to study the threat model of ADS-B, where we used two classification criteria: the difficulty of implementation of the attack and the location of the radio used for the attack. Therefore, we concluded that there are three categories:
• Medium-level attacks: includes most traditional message injection attacks where the geo-location information used to create the ADS-B message is randomly generated and the radio used for the attack is immobile.
• Advanced-level attacks: the geo-location is generated from a flight simulator program which creates realistic trajectories while the radio is also immobile.
• Expert-level attacks: with proliferation of manned and unmanned aerial vehicles, the radio used for the attack could be located on an aircraft or drone.
ADS-B IDS FRAMEWORK
A. Overview
An overview of the proposed ADS-B IDS. First, at the sender, the goal is to craft secure ADS-B
messages based on valid location data. Therefore, the aircraft passes the obtained GPS location at time t along with the corresponding predicted one. The latter is obtained from the aircraft prediction module [11] that computes the flight path in term of series of GPS locations every second by leveraging the Base of Aircraft Data (BADA) that defines specific parameters for each aircraft according to its make and model. Then, the security analysis module at the sender compares both location to check if there is an inconsistency, and if the pilot is very far from its supposed flight path it could indicate a GPS spoofing attack. Consequently, the result is the location that would be used to generate and send the secure ADS-B message. At the receiver, the goal is to verify the integrity and
authenticity of the transmitted ADS-B messages, double-check that with data obtained from the physical environment of the aircraft and finally locate the attacker and create a corresponding
entry in the quarantine.
B. Security Analysis Module at the Sender
Once the aircraft obtain its GPS location from nearby satellite, the security analysis module at the sender checks for conformity of the position with regards to the flight path that is generated by the aircraft prediction module [11] before takeoff. This module generates a series of geo-coordinates
for a specific make and model of an aircraft by leveraging parameters from BADA. If the GPS location deviates, at a time t, from the corresponding predicted one beyond a certain threshold, this
indicates that the reported position is not within the aircraft safe zone at time t. In the next subsection, we describe how we defined this safe zone. In this case, there could be a potential GPS spoofing attack or inappropriate maneuver by the pilot.
C. Safe Zone of an Aircraft
This subsection describe the safe zone of an aircraft, that sets the upper and lower bounds for
a reported position in the sender or receiver. We define this safe as a sphere having as diameter the overall length of the aircraft. For a reported position to be valid, its distance from the predicted position at an instant t, is less than or equal to the diameter of the sphere. In order to compute this distance between two points in the geographic coordinate system, we use the Haversine formula stated in Equation 1, where Δ Lat, Δ Lon, Δ Alt correspond, respectively, to the difference between the reported and predicted latitude, longitude and altitude :
and can be gotten from BADA database.
D. Secure ADS-B Message Generator
After the security analysis module checks the validity of the location to be used, the secure message generator encodes it into the two corresponding even and odd ADS-B messages. However, in order to enforce authenticity and integrity of these messages, there is a challenge of fitting the HMAC-based
metadata without changing the packet format or adding extra messages because the smallest size of HMAC is 128 bits which is greater than the whole Mode S frame. Algorithm 2 describes the process of generating secure ADS-B messages from plain ones. In line 1, we present the initial conditions stating that the GPS position to use have already been validated by the security analysis module and
the HMAC key to use in the zone where the aircraft flies is available. In line 2−3, we generate the plain ADS-B messages, i.e. the even and odd ones, to encode a GPS position. In line 4, we run the HMAC algorithm based on the two ADS-B messages in question and the key before splitting the resulting digest in multiple of 8. For example, we split a 128 bit digest into 8 portions and we split a 256 bit digest into 16 portions. Then, in lines 6 − 7, we makes two even-sized sets out
the portions before running several rounds of a chosen bit manipulation algorithm to each set in lines 8−12. The number of rounds is basically half of the set’s size. Then, we delete the previous elements from each set and we replace then by the output of this algorithm for each set after running all the
rounds. In lines 13−14, we generate the metadata for the even and odd messages based on the content of set1 and set2. Each metadata has 8 bits sequence number and 16 bits resulting
from the bit manipulation algorithm.
E. Secure ADS-B Message Receiver
Once ADS-B messages are received, they need to be checked for integrity and authenticity before further checks are performed by the security analysis module. Algorithm 3 describes the process of validating incoming messages that are first grouped according to their ICAO identifier then to their sequence number. Thus, we used a doubly nested hashmap to that effect which facilitates the
computation of the HMAC digest. In line 1, of Algorithm 3, several variables are initialized.
Line 2 marks the start of the while loop checking for incoming ADS-B messages. Line 3 extracts the ICAO identifier and the sequence number while lines 4 − 7 checks for existence of the hashmaps and create them accordingly. The first hashmap bucket has as key the ICAO number and the second hashmap sequence as mapped content. This latter has the sequence number as key and a queue containing the ADS-B messages as mapped content. Line 8 enqueues each message in the
corresponding queue’s hashmap. In line 9, we check the size of the queue for a given ICAO
and sequence number. If it is equal to 2, that means we can start verifying the HMAC. Lines 10 − 14 extract parts of the metadata to assemble the HMAC digest while computing the HMAC based on the payloads and the used key. In lines 15−18, we check if the computed versus assembled HMACs
match and we store the result in a binary variable which we pass to the security analysis module, in line 19, along with miscellaneous information about the aircraft and ADS-B messages involved. In lines 20 − 21, we resolve the case where the size of the hashmap is less than 2 meaning that one or both messages are not received. Therefore, in lines 22 − 26, we apply a 30 seconds timeout and if the messages are received we return to line 9 to check the HMAC. Otherwise, we pass the result to the security analysis module that can determine if this is due to transmission power such as weak signal power. This cannot undue the failure to compute the safe zone but can solve this problem with the next transmission by ordering the aircraft to apply some adaptation mechanisms such as increasing its
signal power or avoiding a zone where risk factors affect ADSB transmissions.
F. Security Analysis Module at the Receiver
The objective of this module is to run another check on received messages regardless whether their HMAC verification failed or succeeded. Therefore, it computes the location encoded by the ADS-B messages in question and checks if it is within the safe zone, according to guidelines defined in
subsection IV-C. Algorithm 4 describes the logic of this component. Line 1 defines the initial conditions assuming that most of ADS-B are received and that the flight path is already known. Lines 2−5 extract from the ADS-B message and the BADA database, respectively, the ICAO number, the sequence number, the queue corresponding to an ICAO and a sequence number, and the make and model of the aircraft. Lines 6 − 7 compute the predicted position, at a instant t, based on the flight path of the aircraft in question and the declared position based on decoding the ADS-B messages in question. Line 8 calculates the distance between both positions using the Haversine formula defined in subsection IV-C. Line 9 computes the threshold which determines the final decision if the ADS-B position is really valid or not. This is obtained by extracting the overall length of the aircraft. For a ADS-B position to be valid, its distance from the corresponding one at a time t has to be within the safe zone, i.e. less than the threshold. In lines 10 − 13, explore the cases where the measured distance is less than the threshold. Therefore, we validate he position report. In addition, if the HMAC verification failed, we conclude it is due to risk factors affecting ADS-B broadcast. Therefore, we initiate some adaptation techniques to fix that according to [9]. Conversely, in lines 14−19, we explore the cases where this distance is greater than the threshold. In this case, we confirm the existence of message injection attack. Therefore, we create an entry for the message(s) in question specifying its time of arrival, the type of attack and we leverage multilateration techniques to determine the real location of the attacker. This is done by computing the time difference of arrival from different sensors at the ATC center such as in [10].
G. Quarantine
The quarantine is a database where artifacts, related to attacks or isolated ADS-B messages, are stored. These artifacts can serve as input for digital forensics experts to bridge the gap between ADS-B vulnerabilities and ADS-B attacks. The structure of the quarantine is as follows:
• ADS-B Message: the message to be stored in quarantine.
• Timestamp: time of arrival of the ADS-B message.
• Type of Attack: specifies the type of suspected attack if applicable.
• Sender’s Position: specifies the longitude, latitude and altitude of the attacker if any, which is obtained by leveraging multilateration techniques such as in [10].
0 comments:
Post a Comment