Simulating ADS-B and CPDLC messages with SDR

(1)

Linköpings universitet

Linköping University | Department of Computer and Information Science

Bachelor thesis, 16 ECTS | Information Technology

2020 | LIU-IDA/LITH-EX-G--20/037--SE

Simulating ADS-B and CPDLC

messages with SDR

Simulering av ADS-B- och CPDLC-meddelanden med hjälp

av SDR

Sofie Eskilsson

Hanna Gustafsson

Supervisor : Andrei Gurtov Examiner : Marcus Bendtsen

(2)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

©Sofie Eskilsson Hanna Gustafsson

(3)

Students in the 5 year Information Technology program complete a semester long software development project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor setting, currently a search and rescue scenario. In parallel they study several topics relevant to the technical and ethical considerations in the project. The project culminates by demonstrating a working product and a written report documenting the results of the practical development process including requirements elicitation. During the final stage of the semester, students form small groups and specialise in one topic, resulting in a bachelor thesis. The current report represents the results obtained during this specialization work. Hence, the thesis should be viewed as part of a larger body of work required to pass the semester, including the conditions and requirements for a bachelor thesis.

(4)

Abstract

Several studies have shown insufficient security in air traffic communication. The increase in air traffic in recent years also increases the need for improved security. CPDLC is used to communicate in text over the data link and ADS-B determines the position of an aircraft. These techniques are looked upon and simulated in the thesis. By proving that ADS-B and CPDLC messages can be transmitted and received with cheap and easy access equipment we want to show the simplicity in performing an attack. The thesis state a foundation to simulate attacks in the future so further work concerning the lack of security can be done.

(5)

Acknowledgments

We would like to thank our supervisor, Andrei Gurtov, for all the help and support we have received. Additionally, we wish to thank Robin Ellgren for his support. An extra thank you to Tomasz Lemiech for enlightening us in the world of CPDLC.

(6)

2.5 ASN.1 Studio . . . 13 2.6 Attacks . . . 13 3 Method 14 3.1 Pre-study . . . 14 3.2 Implementation of ADS-B . . . 15 3.3 Implementation CPDLC . . . 17 4 Results 20 4.1 Pre-study . . . 20 4.2 ADS-B . . . 21 4.3 CPDLC . . . 22 5 Discussion 24 5.1 ADS-B . . . 24 5.2 CPDLC . . . 25 6 Conclusion 26 Bibliography 27 A Appendix 30

(7)

(8)

List of Figures

2.1 The system architecture of ADS-B technology. . . 6

2.2 ARINC-622 ATS message structure. . . 8

2.3 Empty flight plan. . . 10

2.4 CPDLC Initial Connection Establishment. . . 11

2.5 CPDLC connection transfer. . . 11

3.1 The set up of the equipment. . . 15

3.2 Picture of the hardware. . . 15

3.3 Implementation of ADS-B. . . 16

3.4 Implementation of FANS-1/A. . . 17

3.5 Transmitting a FANS-1/A message with GNU Radio. . . 18

3.6 Receiving a FANS-1/A message with GNU Radio. . . 19

4.1 Graphical view of flight "FIN7WG" in Flightradar24. . . 20

4.2 Decoded ADS-B message in the terminal from real-time aircraft. . . 21

4.3 Received ADS-B message in the terminal. . . 21

4.4 The graphic user interface of ADS-B message using dump1090. . . . 21

(9)

List of Tables

2.1 Format of a 1090 Extended Squitter Message. . . 7

2.2 Example of ADS-B Data of airborne position. . . 7

2.3 Type of message given by Type Code. . . 7

2.4 Examples of down-link messages. . . 9

2.5 Down-link responses. . . 9

2.6 Up-link responses. . . 9

3.1 Explanation of flags used when encoding using ADSB-out. . . . 16

(10)

Abbreviations

ACARS Aircraft Communications Addressing Reporting System. ADS-B Automatic Dependent Surveillance-Broadcast.

AFN ATS Facilities Notification. ASN.1 Abstract Syntax Notation One. ATC Air Traffic Control.

ATCO Air Traffic Control Operator.

ATN-B1 Aeronautical Telecommunications Network - Baseline. ATS Air Traffic Service.

CC1 Connect Confirm.

CPR Compact Position Reporting Algorithm. CR1 Connect Request.

CRC Cyclic Redundancy Check. dM Down-link message.

DR1 Disconnect Request. ERP Effective Radiated Power. ES Extended Squitter.

FANS-1/A Future Air Navigation System. GNSS Global Navigation Satellite System. ICAO Airport Code.

(11)

Abbreviations

IDE Integrated Development Environment. IMI Imbedded Message Identifier.

LDACS L-band Digital Aeronautical Communication System. PDU Protocol Data Unit.

PTS Post- och Telestyrelsen.

RTL-SDR Realtek-Software Defined Radio. SDR Software Defined Radio.

TC Type Code. uM Up-link message.

VDL2 VHF Data Link Version 2. VHF Very High Frequency.

(12)

1 Introduction

1.1 Motivation

Air Traffic Control (ATC) is the backbone of the world’s air transport and as traffic load continues to grow dramatically [1], ATC has to handle more and more aircraft.

To unburden the traditional voice communication, a new technique has become necessary. As a standard method of communicating between ATC and pilot, the voice radio, Very High Frequency (VHF) is used for short-distance communication.

As a solution to the high demand in air traffic communication, data link-based commu-nication was introduced. By increasing the effective capacity of the commucommu-nication channel, the technology can be used more efficiently. This technique, called Controller Pilot Data Link Communications (CPDLC), complements VHF radio communication, and take care of the non-critical communication. Since the introduction, it has reduced accidents and increased communication effectiveness.

To determine an aircraft’s position, ground-based radar was previously used. Due to the extraordinary growth rate of the aircraft traffic volume [1], the limits of the current system were approached and the implementation of a new one was crucial. The technology devel-oped, Automatic Dependent Surveillance-Broadcast (ADS-B), utilizes the Global Positioning System (GPS) to determine the exact coordinates of the aircraft. The coordinates are then automatically transmitted via air-to-ground and air-to-air data communication links at a fixed rate, depending on the aircraft’s current phase. Like any new technological advancement, se-curity may not always be at the forefront of the system’s development, something we will take a closer look at.

In thesis, we will investigate how to simulate ADS-B and CPDLC messages to build a foundation for future work that investigates the vulnerability in aircraft communication.

1.2 Aim

This thesis aims to utilize HackRF SDR to transmit CPDLC and ADS-B messages at very low power in a closed environment for testing. To capture the messages an RTL-SDR dongle with an antenna will be used.

(13)

1.3. Research questions

1.3 Research questions

1. How can Software Defined Radio be utilized to transmit CPDLC and ADS-B messages? 2. What kind of delimitation could be experienced using Software Defined Radio when

transmitting CPDLC and ADS-B messages?

1.4 Delimitation

CPDLC is currently available in two formats; FANS-1/A and ATN-B1. This thesis primarily focuses on FANS-1/A where all experiments are performed in a closed environment using the license-free frequency band. We want to create a method to encode and decode ADS-B and FANS-1/A message, to see if it’s possible to transmit and receive them. The thesis highlights the problems and will not instruct how an attack could be performed.

1.5 Related work

Several studies discuss the uncertainty in aviation communication. In [2], Gurtov et al. high-light the lack of security regarding CPDLC. In [3] McCallie et al. analyzed the security vulnerability associated with ADS-B and executed a security analysis. Sestorp and Lehto [4] show that it is possible to capture and decode CPDLC messages. All these papers discuss the possibility to possess cheap radio equipment, such as SDR, to access and monitor data link communications and decode these.

(14)

2 Theory

2.1 Air Traffic Control

Air Traffic Control (ATC) protocols enable communication between controllers and pilots [2]. The primary purpose of an ATC is to avoid all kinds of aircraft collisions, organize the flow of air traffic, and provide support for pilots. There are different types of ATC services, that depend on the phase of flight, which is provided by licensed Air Traffic Control Operators (ATCOs). The first type of ATC is provided by the airport control tower and is called Tower Controllers. These are responsible for operating vehicles in the airport’s fields and surround-ings. The second type of ATC is Approach (terminal) Controllers, which may be operated via a control center located at the same location as a planned arrival/departure, but may also be operated from other locations. These are responsible for separating aircraft that are ascending from, and descending to the runway. The last type of ATC is Route Controllers, which is responsible for the movement that takes place in the upper airspace including continental and ocean routes when an aircraft has reached the intended altitude [5]. ATC is a type of Air-craft Communications Addressing and Reporting System (ACARS). ACARS is a digital data link system for the transmission of messages between aircraft and ground stations [6]. Voice communication is the primary means of communication between ATC and an aircraft. It is used to transmit all ATC instructions to the aircraft, which are acknowledged by the pilot, as well as pilots’ reports and requests to ATC. Flight information services, weather reports, and airport information broadcasts can also be provided by voice communication. It is further used for operational communication between the airline operator and the aircraft, as far as the aircraft is in the range of the operator’s transmitter. Voice communication is conducted by analog radio on VHF [7].

2.2 Automatic Dependent Surveillance – Broadcast

The Automatic Dependent Surveillance-Broadcast (ADS-B) technology is used by the equip-ment onboard an aircraft to determine the aircraft position and speed, using satellite navigation to do so automatically.

As stated earlier the A in ADS-B means Automatic and therefore no ATCO input or flight crew is needed as the position and velocity information is automatically transmitted [8]. Even though the transmissions are done automatically, it relies on the Global Navigation Satellite

(15)

2.2. Automatic Dependent Surveillance – Broadcast

System (GNSS) as a primary data source to calculate e.g. aircraft identification, position, altitude, speed. The transmissions is dependent on GNSS receiver and barometric encoder [9]. Information such as the aircraft’s position, velocity and route are surveillance data that is continuously broadcasted. This data is sent to either ADS-B ground stations or satellites, depending on range and broadcast coverage, as well as any other aircraft in the range that have an ADS-B receiver [5, 8].

In ADS-B technology two different types of equipment are distinguished; ADS-B Out and ADS-B In [5]. Signals that are sent by an aircraft to an ADS-B ground station or other ADS-B equipped aircraft are sent from ADS-B Out equipment, in figure 2.1 referred to as ADS-B Message Generation. When those signals have been received from an aircraft, any receiver in the transmission range with ADS-B In equipment gets access to the flight number, latitude, longitude, altitude, and velocity [8]. According to Commission Regulation (EU) No 1207/2011 of 22:nd November 2011, the rules governing ADS-B will be required from 7:th June 2020. From this date, all aircraft in the European airspace that has a maximum cruising speed exceeding 250 knots or with a maximum certified take-off mass exceeding 5 700 kg must be equipped with ADS-B [10]. From this date, ADS-B will be the primary surveillance method used by ATC and will accordingly replace radar-based surveillance [11].

The full system architecture of ADS-B technology is shown in figure 2.1.

Figure 2.1: The system architecture of ADS-B technology. [12]

2.2.1 ADS-B Message

ADS-B messages use a transmission frequency of 1090 MHz, as seen in figure 2.1, and a surveillance transmission mode called Mode S. Mode S transponders will integrate a message called extended squitter (ES). Each 1090ES-message has a total duration of 120 µs and consists of 112 bits and is sent at least once a second [13]. Each message is divided into five fields: Downlink format, Capability, Aircraft Address, ADS-B Data, Parity Check, see table 2.1 [14]. The first field Downlink Format can be in different formats depending on what type of message it is. For example, a squitter message uses format 17. The second field Capability shows the communication capability of the Mode S transponder and the Aircraft Address identifies the sender with a unique 24 bits address [3]. ADS-B Data consists of further segments shown in figure 2.2 and in Parity check any possible transmission error will appear.

The first five bits in ADS-B Data represents the Type Code (TC), shown in table 2.2, where bits convert to decimal indicates the type of message, shown in table 2.3. For example, if TC in table 2.2 holds the binary combination 10011, 19 in decimal, it indicates that the message type is Airborne velocities [13].

(16)

2.2. Automatic Dependent Surveillance – Broadcast Segment Downlink Format Capability Aircraft Address ADS-B Data Parity Check Bits 5 3 24 56 24

Table 2.1: Format of a 1090 Extended Squitter Message.

ADS-B Data

Segment TC SS SAF ALT T F LAT-CPR LON-CPR

Bits 5 2 1 12 1 1 17 17

Table 2.2: Example of ADS-B Data of airborne position.

TC Type of message

1-4 Aircraft identification 5-8 Surface position

9-18 Airborne position with Barometric Altitude 19 Airborne velocities

20-22 Airborne position with GNSS Height 23-31 Reserved for other uses

Table 2.3: Type of message given by Type Code.

2.2.2 Compact Position Reporting Algorithm

The CPR algorithm is responsible for encoding and decoding aircraft position in the ADS-B protocol. If the CPR algorithm is not used, the accuracy of the position would differ with more than 300 meters. Bit 51 in ADS-B Data, frame F, could be either 0 or 1 which indicates an even or odd frame and is needed to find out the latitude and longitude. By merging the frame F with the 17 bits each of latitude and longitude, the CPR algorithm can offer a position accuracy of five meters [14].

The CPR algorithm uses a global coordinate system where latitude and longitude are divided into several zones on earth. Each zone is in turn divided into subdivisions, global or local zones, depending on if the frame F is even or odd. The general idea behind the CPR algorithm is to transmit the least significant bits since it’s inefficient to transmit the entire latitude and longitude. If the position is known, i.e. a previously decoded position, only one type of even or odd frame is used while both of the frames are used if the position is unknown [15].

The CPR algorithm transforms the coordinates expressed in degrees into CPR coordinates with the chosen subdivision (odd or even) taken into account. The encoding translates the latitude and longitude coordinates into a pair of CPR coordinates, called bin indices, now transformed from degrees to binary [15].

When decoding the position, the CPR algorithm calculates which zone the aircraft is located in. The algorithm uses the most recent referenced position through local decoding and looks at a previously known position. A known position corresponds to a previously decoded position and the algorithm can thus execute the decoding correctly as long as the target is close enough to the reference position [15].

(17)

2.3. Controller Pilot Data Link Communications

2.3 Controller Pilot Data Link Communications

CPDLC is a message-based communication between ATC and aircraft. ATC can use CPDLC via a terminal to send clearances or requests. The aircraft can choose between several prede-fined phrases or free texts, to send to the ATC. This technique has several advantages over VHF such as the reduced risk of acoustic misunderstandings. It is also easier and more efficient to transmit and receive longer messages. The VHF is dependent on the controller handling many operations at the same time, while that is not a problem using CPDLC. Some of the bus-iest airports, and all the European, already employ CPDLC for automated clearance delivery and start-up approval [16].

CPDLC uses the VHF Data Link Version 2 (VDL2) as its data link with the frequency band from 118.000 to 136.975 MHz, and a data rate of 31.5 kilobits [2]. VDL2 is an air interface with the means to send information between ATC and aircraft [17].

The system includes airspaces not covered by VHF and ensures availability, even in oceanic airspace, and enables the possibility of connecting through a satellite communications network. CPDLC is currently available in two formats: FANS-1/A (Future Air Navigation System) and ATN-B1 (Aeronautical Telecommunications Network - Baseline 1). FANS-1/A is, despite its name, the old technology and used widely across the world. It is the only CPDLC format that can be carried over any aviation radio link, capable of carrying ACARS messages seen in figure 2.2. ATN-B1 is the new format that is now in operation only in Europe. This format is only supported on the VDL2 radio link [17].

2.3.1 CPDLC messages

The transactions between aircraft and ATC are encoded information. There are regulations for how a CPDLC message should be structured and how it should be encoded. Abstract Syntax Notation One (ASN.1) defines the structure of the message. CPDLC shall use ISO/IEC 8825-2:1996 Packed Encoding Rules (PER) - Basic Unaligned, to encode/decode the ASN.1 [18]. To transmit the PER encoded CPDLC message as an ACARS message, it has to be encapsulated into an ARINC-622 Air Traffic Service (ATS) message.

Figure 2.2: ARINC-622 ATS message structure.

The ACARS address is a specific 7-character address based on the 4-character airport code (ICAO-code), unique for each aircraft. The Imbedded Message Identifier (IMI) could be AT1, CR1, or DR1 for up-link communication and shows what kind of connection that is established, see section 2.3.3 [18, 19]. The following seven characters are the aircraft registration number; the first one, two or three characters refer to the origin nation and the subsequent characters are a unique combination within the nation [20]. The next part of the message is the PER-encoded CPDLC message as a byte string, see section 2.3.2. The last four characters are hex digits are calculated by a cyclic redundancy check. Cyclic Redundancy Check (CRC) is used to detect errors in data storage or transmission. Blocks of data entering these systems get a short check value attached, based on the remainder of a polynomial division of their contents. This simple detection mechanism works if an odd number of bits in a byte changes, but an even number of false bits in one byte will not be detected by the parity check. The CRC in ARINC - 622 ATS message is called a 16-bit CRC with polynomial coefficients of x16+x12+x5+1 [21].

(18)

2.3.2 CPDLC message types

At CPDLC connections, exchanges of CPDLC messages is made between aircraft and ATC-facilities. CPDLC messages are divided into two categories; up-link message (uM) and down-link message (dM). Up-down-link message refers to communication going from ground to air and a down-link message refers to communication going from air to ground. Every down-link and up-link messages contain an element ID which represents a unique type of message, examples of down-link messages can be seen in table 2.4. To each element ID, a response type is linked, and depending on the message type, dM or uM, there are different response types. As can be seen in table 2.5 down-links are binary, Yes or No, either requiring a response or not. Down-link, on the other hand, can be either W/U, A/N, R, or NE, shown in table 2.6. All response have an inherent precedence [18].

ID Message element Resp

0 WILCO N 1 UNABLE N 2 STANDBY N 3 ROGER N 4 AFFIRM N 5 NEGATIVE N

9 REQUEST CLIMB TO [altitude] Y

29 CLIMBING TO [altitude] N

56 MAYDAY MAYDAY MAYDAY N

67 Free Text N

68 Free Text Y

Table 2.4: Examples of down-link messages.

Type Description Precedence

Y Response required 1

N Response not required 2

Table 2.5: Down-link responses.

Type Description Precedence W/U Wilco, Unable, Standby, Error, Not Current Data Authority 1

A/N Affirm, Negative, Standby, Error, Not Current Data Authority 2

R Roger, Standby, Error, Not Current Data Authority 3

NE Wilco, Unable, Affirm, Negative, Roger, Standby, Not Current Data Authority 4 Table 2.6: Up-link responses.

(19)

2.3.3 Initial CPDLC Connection Establishment

To establish an initial logon between aircraft and an ATC, a flight plan is required, seen in 2.3.

Figure 2.3: Empty flight plan. [2]

Subsequently, an ATS Facilities Notification (AFN) logon message (FN_CON) is created which contains information about the aircraft registration number, flight identifier, and the communication system used by the aircraft e.g. ATS application control numbers. The ATC-facility ensures that the aircraft registration number and flight identifier in the FN_CON matches that in Item 18 and 7 of the associated aircraft, seen in figure 2.3. If the fields don’t match, the logon request will be denied. Lastly, the four last hex digits (CRC) will be checked to detect errors in the transmission.

With this information, ATC can establish contact with an aircraft and send an AFN Acknowledge Message (FN_AK) back to the aircraft crew, which provides information whether the FN _CON was successful or not. Without the AFN logon, no contact can be established, and it is also required that a reply must be given to FN_CON within 10 minutes. If an FN _AK with a reason code not equal to 0 is sent, the response will be considered as a negative response. After receiving a FN_AK, CPDLC up-link Connect Request (CR1) can be sent from ATC facility to the aircraft. The request contains the message uM163 which indicates an up-link message (uM) with the element ID 163, a system management message. Afterward, the aircraft sends a down-link message (dM) to the ATC facility as the final step before the CPDLC message can be sent. This answer is called a down-link Connect Confirm (CC1) consisting of the system management message dM73 holding the aircraft version number [18]

(20)

Figure 2.4: CPDLC Initial Connection Establishment. [18]

2.3.4 CPDLC connection transfer

Every ATS facility controls a demarcated area, which means that when an aircraft leaves the active ATS facility’s area, a connection transfer to a new ATS facility is required. The active ATS facility appoints the new ATS facility and relays the aircraft address information provided at the initial AFN login. The transfer takes place through a FN_CAD up-link message and does not require any interaction by the aircraft crew. The aircraft automatically sends a FN_RESP down-link message back to the active ATS facility, and a FN_COMP is sent to the engaging ATS facility. A new log on the process can start and when the aircraft sends a disconnect request (DR1) to the first ATS facility, the old connection can be considered terminated [18].

Figure 2.5: CPDLC connection transfer. [18]

(21)

2.4. Software Defined Radio

2.4 Software Defined Radio

Software Defined Radio (SDR) technology is used to both transmit and receive radio signals. Unlike traditional radio communication where the components, such as modulators and tuners, are implemented in analog hardware, these radio components are implemented in software [22, 23]. The traditional radio can be replaced by SDR since the software makes it possible to create programmed solutions [24].

2.4.1 HackRF One

HackRF One is hardware for SDR that is capable of transmission or reception of radio signals. HackRF One connects to the computer via USB and allows signals from the frequency between 1 MHz to 6 GHz. It provides a software-controlled antenna port power of 50 mA at 3.3 V and output power of 16.5 mW. It is compatible with Linux, macOS, and Windows [25].

2.4.2 Realtek-Software Defined Radio

Realtek-Software Defined Radio (RTL-SDR) is a USB dongle used for receiving live radio signals. The RTL-SDR v.3 is based on the RTL2832U chipset with an R820T2 tuner. It can receive frequencies between 500 kHz – 1766 MHz with bandwidth up to 2.4 MHz. It is compatible with Linux, macOS, Windows, and Android [26].

2.4.3 License free radio frequencies

Post- och telestyrelsen (PTS) is a Swedish government authority for post and telecommunica-tion, responsible for setting up rules for electronic communication and reviewing the market actors [27]. According to PTS’s regulations of license-free frequencies, Cha. 3 §99, frequen-cies between 868,0–868,6 MHz can be used for transmitting radio signals for an unspecified application. The frequency span is limited to 25 mW effective radiated power (ERP) and a transmission duty cycle of ď 1 % [28]. Anyone using license-free radio frequencies in Sweden does not require permission from PTS [27].

2.4.4 GNU Radio

GNU Radio1is an open-source software development toolkit for creating signals and processing functions. The software provides the user with a graphical interface called flow graph, for easy interaction. A flow graph allows the user to visually control the operation of the program, by choosing blocks which have different functionalities. The blocks can be adjusted depending on the desired design of the software radio and have blocks for both HackRF One as well as RTL-SDR. The blocks then generate python code when execute is pressed [29].

In the experiment, to transmit the CPDLC messages, the following blocks are used [30]: • The Packet Encoder is a very simple block used to show how to packet size data. It

takes in packet size and wraps it into a packet of a set payload length with a header, access code, and preamble.

• The block GMSK Mod is a Hierarchical block for Gaussian Minimum Shift Key (GMSK) modulation. The input is a byte stream and output is the complex modulated signal. • A Multiply Const multiplies the input stream by a scalar constant.

• The Osmocom Sink is a module that consumes data and the block streams samples to a HackRF One device.

(22)

2.5. ASN.1 Studio

Below the blocks for receiving a message are described [31].

• The RTL-SDR Source block is effectively an Osmocom source block that has been tailored specifically for use with the RTL2832U TV tuner.

• The hierarchical block for Gaussian Minimum Shift Key demodulation, GMSK Demod, has the input of a complex modulated signal. The output is a stream of bits packed 1 bit per byte.

• The decoder, Packet Decoder, looks for the access code with the number of available bits wrong. When it’s found, it reads the header to get the payload length, extracts the payload, and outputs the payload.

• Lastly the File Sink is used to write a stream to a binary file.

2.5 ASN.1 Studio

ASN.1 Studio 2 is an integrated development environment (IDE) used to graphically create ASN.1 values, without writing code. The environment generates code from the ASN.1 speci-fication and includes various protocol data units (PDU) such as ATCdownlinkmessage, ATC-downlinkmsgelementid, and ATCmessageheader. The ATCdownlinkmessage is a Sequence of ATCmessageheader and ATCdownlinkmsgelementid. The data structure is the complete mes-sage that is sent from the ATCComm to the ATC Data Authority. The mesmes-sage consists of a message header, message element identifiers, and any applicable data structures [18].

2.6 Attacks

New technologies have often been deployed with a focus on functionality rather than security, ADS-B, and CPDLC being no exceptions. ADS-B provides broadcasts of aircraft position, identity, velocity, and unencrypted data links. The data transmitted between aircraft and ATC are not protected from any apparent security mechanism. As a result, an injection attack would be possible and such action could have devastating effects on the airspace system [32]. CPDLC also suffers a lack of security which has been recognized in several papers [2, 16, 4].

In this thesis, the main focus will concern the attack injection. An injection is a non-legitimate message planted into the air traffic communication system. Since no authentication measures are implemented at the data link layer, there is no problem for an attacker to build a transmitter that can produce correctly modulated and formatted messages. With limited knowledge and very cheap and simple technological means, an attack can be performed on ADS-B and CPDLC [32].

(23)

3 Method

This chapter describes the method used to encode, transmit, receive and decode ADS-B and FANS-1/A messages. The requisites for the method are explained and lastly, the method is evaluated.

3.1 Pre-study

During the project, a pre-study was executed. The key findings were how the encoding and decoding functioned, for both ADS-B and FANS-1/A messages, as well as to find suitable software to do the operations.

In the research, knowledge was gained from the practical implementation of ADS-B and CPDLC. Since there was a lot of information available online, it was important to choose credible sources and, above all, sources were relatively new. To familiarize with the hardware, HackRF One, the website Great Scott Gadgets 1 was considered as a credible source, since that’s the website where HackRF One was purchased. Through Great Scott Gadgets, we took part in the lessons offered online, which contributed to our first understanding of Software Defined Radio and its implementations.

By setting up the RTL-SDR dongle with the antenna, it was verified that ADS-B messages from aircraft passing by could be captured. The decoding software could be tested by cap-ture ADS-B messages from the aircraft. The messages that were capcap-tured and decoded were compared with the information from an online flight tracking service to verify the method.

During the research, to find an encoder and decoder for the CPDLC, a problem was expe-rienced. There was plenty of software to decode a FANS-1/A message, but none to encode. The problem was solved by modifying existing software to please the needs of the project. The chosen decoder could be verified by a thesis [4] were the same decoder was used to capture and decode CPDLC messages.

The pre-study also included a verification that the setup worked as intended. Each of HackRF One and the RTL-SDR dongle were connected via USB to individual computers. An overall set up can be seen in figure 3.2

(24)

3.2. Implementation of ADS-B

Figure 3.1: The set up of the equipment.

Figure 3.2: Picture of the hardware.

3.2 Implementation of ADS-B

The following section describes how to encode an ADS-B message and transmit a signal with HackRF One. The RTL-SDR dongle will then receive the signal and the message is lastly decoded. The procedure step by step is shown in figure 3.3 and described in the following paragraphs.

(25)

3.2. Implementation of ADS-B

Figure 3.3: Implementation of ADS-B.

3.2.1 Encode and transmit messages

To create and encode the ADS-B message an open-source project was utilized called ADSB-Out2. The desired signal was created by running the script ADS-B _Encoder.py where NameOfFile was added to make it possible to save several signals with different values. Following arguments were used when executing the script:

The example signal named test_sample was created including following information; ICAO abc123, latitude 15.575702, longitude 58.397548 and altitude 975.0. The created file test_sample.iqs was further aligned to 256K buffer size. A execution of ADSB_Encoder.py looks as follows:

1 $ cd Documents/ADSB-out

2 $ python ADSB_Encoder.py 0xabc123 58.397548 15.575702 975.0 test_sample 3 $ dd if=test_sample.iq8s of=test_sample_256K.iq8s bs=4k seek=63

The created signal was encoded with ADSB-Out and transmitted recursive with HackRF One over frequency 868 MHz using sample frequency 2MHz.

1 $ cd Documents/ADSB-out 2 $ hackrf_transfer -t test_sample_256K.iq8s -f 868000000 -s 2000000 -x 47 -R Flag Type -s Sample frequency -t Transmit -f Frequency, Hz -R Recursive signal -x Gain, dB

Table 3.1: Explanation of flags used when encoding using ADSB-out. 2_{https://github.com/lyusupov/ADSB-Out}

(26)

3.3. Implementation CPDLC

3.2.2 Receive and decode messages

RTL-SDR dongle received the signal and to decode the example signal, an open-source project was used called dump1090 3. Dump1090 is an ADS-B decoding program that is compatible with the RTL-SDR dongle.

To receive and decode the example signal test_sample the frequency to capture was set to 868 MHz since it was the sending frequency. The interactive flag was added to get a graphic view of the aircraft broadcasting the signal.

1 $ cd Documents/ADSB-out

2 $ sudo ./dump1090/dump1090 --interactive 3 --net --freq 868000000

3.3 Implementation CPDLC

The goal of the experiment was to create a desired FANS-1/A message, encode it, and transmit it with HackRF One. Further, the goal was to receive the signal with the RTL-SDR dongle and decode it. The procedure step by step is shown in figure 3.4. The method describes how a selected message is transmitted and in the end how the same message can be read.

Figure 3.4: Implementation of FANS-1/A.

(27)

3.3.1 Create message

To create a FANS-1/A message the format must be specified in the abstract syntax shown in Appendix 1 (A.1) as described in ARINC 622 Data Communication [18]. To generate the byte string ASN.1 Studio was used due to its possibility to edit ASN.1 schemas and generate sample code to encode and decode ASN.1 data, without actually writing code.

Encoding a message consists of two steps:

1. Assemble the message structure as specified in the ASN.1 module in ARINC 622 Data Communication.

2. Use ASN.1 Studio to pass the structure message into an unaligned PER encoder. It will produce a byte string representing the PER-encoded FANS-1/A message.

As mentioned earlier in section 2.3.1 the last four digits in the FANS-1/A message are the CRC which was calculated by using the IMI, aircraft registration number, and the PER-encoded string. For the encoding of the CRC, parts of an open-source project Libacars 4 was used. Libacars is a library intended for decoding ACARS message contents. In the implementation precomputed lookup tables were used to perform the computation. The IMI was converted to hexadecimal ASCII and then converted to raw bytes. The PER-encoded string was converted from hexadecimal to raw bytes and then merged with the IMI. This generated a byte string that then was inverted to yield a correct CRC. The last step was to convert the CRC back to hexadecimal.

3.3.2 Transmit messages

In this project, HackRF One, with an antenna, was utilized to transmit FANS- 1/A messages. Once the message had been modified into the correct format, GNU Radio was used to generate a signal to enable the message to be sent through Hack RF One. A text file consisting of the FANS-1/A message was added into the software, see figure 3.5, where the component GMSK Mod transform the byte stream input to a complex modulated signal. The output was a complex signal sent with the HackRF One.

Figure 3.5: Transmitting a FANS-1/A message with GNU Radio.

(28)

3.3.3 Decode messages

The antenna connected to the RTL-SDR dongle received the signal. GNU-Radio managed to transform a complex signal and generating an output of a bitstream with the component GMSK Demod. The received message is saved in a file, see figure 3.6.

Figure 3.6: Receiving a FANS-1/A message with GNU Radio.

The software Libacars made it possible to decode the FANS-1/A message. The decoding involved verifying the CRC, decoding the PER-encoded string, and finally pass it into the correct format using ASN.1.

The FANS-1/A message can now be read by the receiver of the message and have the same format and information as the message sent.

(29)

4 Results

This chapter presents the results step by step when transmitting and receiving an ADS-B and a CPDLC message.

4.1 Pre-study

Below the results of the initial tests made to examine the possibilities of decoding ADS-B messages are presented. Figure 4.2 displays the interface of the renowned website Flightradar24

1_{which was used to scout suitable aircraft in real-time, here showing flight FIN7WG heading}

towards London, accompanied by ADS-B data seen bottom left in the figure. As can be seen in Figure 4.2, data from Flightradar24 match the data derived with the decoder, ADSB-out. The first field Hex is the airport code (ICAO-code), Track is the angle of the flight, Messages is the number of messages received and finally Seen is the time at which the last packet was received.

Figure 4.1: Graphical view of flight "FIN7WG" in Flightradar24. 1_{https://www.flightradar24.com/}

(30)

4.2. ADS-B

Figure 4.2: Decoded ADS-B message in the terminal from real-time aircraft.

4.2 ADS-B

In this section, the result is presented from the experiment, where a staged ADS-B signal, named test_sample, was encoded, transmitted, captured, and decoded. By using each step in figure 3.3, the method could be validated and the result is presented below.

The message that was encoded, using the CPR algorithm, in the open-source project ADSB-Out could easily be transmitted over the air with the help of HackRF One and then received with the RTL-SDR dongle while dump1090 was running. The experiment showed that the signal could be transmitted at a maximum distance of 50 meters, using the selected software and hardware. The signal was transmitted over the license-free frequency 868 MHz. The output obtained when sending test_sample are presented in figures 4.3 and 4.4. Figure 4.3 shows the terminal log and how the message test_sample successfully have been received. The first field Hex in the log represents the airport code (ICAO) which contains the same airport code as the sent signal test_sample. Other fields such as altitude, latitude and longitude have also been received and is related to the corresponding part of the example signal.

Figure 4.3: Received ADS-B message in the terminal.

The software dump1090 included a graphic interface, by using the flag - interactive. This made it possible to show the geographic position of the aircraft. As can be seen in figure 4.3 the latitude and longitude are 58.398 and 15.576, the coordinates showing that the aircraft is situated above Linköping University Campus Valla.

(31)

4.3. CPDLC

4.3 CPDLC

In the following section, the reader can follow all steps required to encode, transmit, receive, and decode a FANS-1/A message. To make it clearer for the reader a staged example message will be used carrying the predefined message TEST TEST TEST.

4.3.1 Message creation

Recall the message structure from figure 2.2; the ACARS address was set to AKLCDYA, in this case, the ATS was situated in Auckland. The IMI was set to AT1 to declare a CPDLC message, in an already established contact. The seven characters long registration number of the aircraft was set to .9M-MTB. The following string carried the message element of the signal and the last four digits were the CRC calculated from the test message.

To encode and decode the message element ASN.1 Studio utilizes a predefined ASN.1 structure, see appendix A.1, and a chosen encoding. The free text TEST TEST TEST message correspond to ID 67 in the ATC Downlink Message format, as seen in table 2.4. The program thus returned the string 002186D48B4EA20A9169D441522D3A80 which is the TEST TEST TEST message formatted as an ATC Downlink Message and encoded with Unaligned Packed Encoding Rules (PER).

Figure 4.5: The software ASN.1 Studio. The message obtained looks like following:

AKLCDYA AT1 .9M-MTB 002186D48B4EA20A9169D441522D3A80 XXXX The last thing was to calculate a CRC to have a complete message. The first steps of generating the CRC can be seen in the transformations in table 4.1

Text Hex Raw bytes

IMI AT1.9M-MTB 4154312E39

4D2D4D5442

0x41, 0x54, 0x31, 0x2E, 0x39, 0x4D, 0x2D, 0x4D, 0x54, 0x42

PER String TEST TEST TEST

002186D48B4 EA20A9169D4 41522D3A80

0x00, 0x21, 0x86, 0xD4, 0x8B, 0x4E, 0xA2, 0x0A, 0x91, 0x69, 0xD4, 0x41, 0x52, 0x2D, 0x3A, 0x80

Table 4.1: Calculating CRC.

Merging the raw bytes of IMI and PER-encoded string, run it in the modified version of Libacars, returned the string 320D. Inverting the binary string of 320D yield CDF2. The complete test message was now ready to be transmitted in the following format:

(32)

4.3. CPDLC

4.3.2 Message transmission

Using HackRF, the message was transmitted as a complex signal. To transform the signal, the instrument GNU Radio used different modules to convert the signal. A file containing the correct format of the message was imported to GNU Radio, see figure 3.5, the signal then went into the Packet encoder where it got wrapped into a packet with a header, access code, and preamble. The signal then passed through a block of Gaussian Minimum Shift Key (GMSK) modulation. In the last operation, the complex signal passed to the Osmocom Sink, which sends with HackRF One.

4.3.3 Message decoding

The signal was successfully received by the RTL-SDR dongle within a distance of approximately one meter and brought into GNU Radio once again. Figure 3.6 shows how the RTL-SDR source block picks up the signal and is specifically tailored for the use of the RTL-SDR-dongle. The message is now in the phase of decoding, to see if the message element carries the message TEST TEST TEST. The first row expresses that this is a down-link message (d) with the label AA. The label is used to identify the application carried in the message text.

1 $ decode_acars_apps d AA /AKLCDYA.AT1.9M-MTB002186D48B4EA20A9169D441522D3A80CDF2 ãÑ 2 /AKLCDYA.AT1.9M-MTB002186D48B4EA20A9169D441522D3A80CDF2 3 FANS-1/A CPDLC Message: 4 CPDLC Downlink Message: 5 Header: 6 Msg ID: 0 7 Message data: 8 [freetext] 9 TEST TEST TEST

This is the end operation and the test message returned TEST TEST TEST. As can be seen in figure 4.5, the other data corresponds to the sent.

(33)

5 Discussion

This chapter is divided into the following subheadings; ADS-B and CPDLC. In each subhead-ing, the method, the result, and future work will be discussed.

5.1 ADS-B

The implementation to send and receive an ADS-B signal was relatively painless. An encoder and decoder were found quickly and because of the easy way to monitor a real aircraft, it was easy to verify that the decoder worked as intended. The thorough documentation in the subject helped during the execution of the experiments. Due to the simple implementation together with the systematic documentation, this increases the risk of a possible attack. We had limited prior knowledge of the subject, which means that someone with limited knowledge easily can perform an attack. The relatively inexpensive equipment can also result in an increasing number of people being able to carry out an attack, and the acquisition of more devices can lead to a large-scale attack. The fact that ADS-B does not require a logon is an additional security flaw.

When the setup initially had been verified, a maximum range for sending the signal was tested. The range test was executed in an open field without any distraction to disturb the signal. The measured distance for the signal is approximately 50 meters, which means that an attacker easily can inject messages into the ATC system or nearby aircraft. With an amplifier, an attack could be executed from even further distance. The staged aircraft in the experiments was standing still with no speed or angle. To make the attack more realistic, for future work, a script can with ease be made that stage a moving aircraft.

Delimitation in the experiments was the frequency. Due to regulations, a license is required to transmit over the frequency of 1090 MHz [28] to avoid interference for the air traffic. The frequency used for the experiments was chosen to 868 MHz after some consideration. The choice was between the frequency 433 MHz and 868 MHz, both reserved for Short Range Devices, and are license-free all over EU. 868 MHz is characterized by the power efficiency and ranges from a couple of meters, up to several kilometers. The 868MHz band is more or less interference-free, with great damping in contrast to 433 MHz, which is more cluttered.

(34)

5.2. CPDLC

5.2 CPDLC

During the research, a problem was experienced to find a good way to encode CPDLC messages. There was software to decode a FANS-1/A message, but none to encode. A reason for this could be that the hardware to encode and transmit is way more expensive than the hardware to decode and receive a message. A consequence of this could be that less software for encoding has been developed. This can contribute to making it harder to perform an attack since no complete program for encoding exists.

As mentioned in section 4.3.3, the signal was received at about one-meter distance from the sender. The signal was not successfully received in every attempt because the connection was quite unstable. The hardware’s, HackRF One and RTL-SDR-dongle are capable to transmit and receive on a distance of at least 50 meters. For future work, it is possible to modify and optimize the signal sent with GNU Radio. If a more stable signal were created, it could have been transmitted at a greater distance. In the test executed, it is shown that HackFR One can be utilized to send a file containing a FANS-1/A message. For further work, a script can be created to avoid sending the message over a file.

The section 4.3.3 confirmed that the encoding had been done correctly. The desired mes-sage, in this case, TEST TEST TEST, could be encoded, using the method developed, and then decoded and returned to the recipient. We have established a foundation on how to create messages for FANS-1/A. In the test, pre-defined, and free-text, messages can be sent in a file. But if a real aircraft receives any CPDLC messages without being connected, the aircraft will ignore them. This means that a connection needs to be established, to simulate a real attack. Since CPDLC accepts all requests as long as they contain the correct information, see in section 2.3.3, it means that it does not question the sender and an attack is harder to discover.

As mentioned in delimitation, section 1.4, the focus of this thesis has been to send a message of the format FANS-1/A. The reason why FANS-1/A was chosen over ATN-B1 was that we found more documentation regarding the encoding of FANS-1/A. Similar to FANS-1/A, ATN-B1 messages are also PER-encoded ASN.1 data structures, and the method developed could have been partially used even for the ATN-B1 message. However, the abstract syntax of ATN-B1 is slightly different than the syntax of FANS-1/A.

In the future, ATM communication will move from analog VHF voice and VDL2 com-munication to more efficient digital data comcom-munication [33]. L-band Digital Aeronautical Communication System (LDACS) is a communications system and is intended for operations in the L-band (960-1164 MHz). LDACS will make it possible to communicate IPv6 based air to ground communication related to aviation safety. Since VDL2 was not designed to exchange a larger amount of data, the new technology must be scalable. With LDACS, a larger amount of data can be transmitted at a higher speed [34].

5.2.1 The work in a wider context

The aim of this thesis has all along been to transmit and capture ADS-B and CPDLC messages to demonstrate the lack of security. The purpose has never been to create instructions on how to execute an attack and that cannot be read in the thesis. Due to the ethical dilemma, we have not discussed how an attack can be implemented, only highlight what further work can be done to evolve the experiments.

(35)

6 Conclusion

This thesis aimed to utilize HackRF One and RTL-SDR dongle to transmit and receive CPDLC and ADS-B messages at very low power in a closed environment for testing. The research questions formulated in Chapter 1 were:

1. How can Software Defined Radio be utilized to transmit CPDLC and ADS-B messages? 2. What kind of delimitation could be experienced using Software Defined Radio when

transmitting CPDLC and ADS-B messages?

The methods describing how Software Defined Radio were utilized to transmit ADS-B messages and FANS-1/A can be seen in figure 3.3 and 3.4. By successfully transmitting and capturing ADS-B and CPDLC messages, the experiments indicate that it is possible to inject such messages. The data transmitted and captured contains elements with sensitive infor-mation that could be utilized to carry out attacks with severe consequences to air traffic. The vulnerability of air data communication was confirmed by successful experiments using Software Defined Radio where both CPDLC and ADS-B messages were transmitted. Neither ADS-B messages nor CPDLC messages are encrypted when transmission of messages in the airspace takes place. However, the messages are sent encoded and a message decoding is thus required on the receiver side to read the message in plain text. The surveys have shown the existence of security flaws due to a relatively easy method to encode CPDLC and ADS-B mes-sages. Prominent solutions regarding the encoding for FANS-1/A messages were established, and the experiments show that it is possible to send such messages with relatively inexpensive technology. The experiments also show the delimitation in range for sending messages with SDR and the distance for CPDLC was considerably more limited than for ADS-B. Future work can improve the signal to be able to transmit over a greater distance and stabilize the signal.

(36)

Bibliography

[1] _{Growth in global air traffic. url: https://www.statista.com/statistics/193533/} growth-of-global-air-traffic-passenger-demand/. (accessed: 17.05.2020). [2] Andrei Gurtov, Tatiana Polishchuk, and Max Wernberg. “Controller–Pilot Data Link

Communication Security”. In: Sensors 18.5 (2018), p. 1636.

[3] Donald McCallie, Jonathan Butts, and Robert Mills. “Security analysis of the ADS-B implementation in the next generation air transportation system”. In: International Journal of Critical Infrastructure Protection 4.2 (2011), pp. 78–87.

[4] Isak Sestorp and André Lehto. CPDLC in Practice: A Dissection of the Controller Pilot Data Link Communication Security. 2019.

[5] Margaret Arblaster. Air Traffic Management: Economics, Regulation and Governance. Elsevier, 2018.

[6] _{ACARS. url: https://www.skybrary.aero/index.php/Aircraft_Communications,} _Addressing_and_Reporting_System. (accessed: 24.04.2020).

[7] International Standards and Annex 10: Aeronautical Telecommunications Recommended Practices. 2nd ed. Volume V: Aeronautical Radio Frequency Spectrum Utilization. Inter-national Civil Aviation Organization (ICAO). url: https://www.icao.int/Meetings/ anconf12/Document%20Archive/AN10_V2_cons%5B1%5D.pdf. (accessed: 29.03.2020). [8] William R Richards, Kathleen O’Brien, and Dean C Miller. “New air traffic surveillance

technology”. In: Boeing Aeromagazine 2 (2010).

[9] _{Air Traffic Control. url: https : / / gssc . esa . int / navipedia / index . php / Air _} Traffic_Control. (accessed: 23.05.2020).

[10] European Union. COMMISSION IMPLEMENTING REGULATION (EU) No 1207/2011 of 22 November 2011 laying down requirements for the performance and the interoperability of surveillance for the single European sky. url: https : / / eur -lex . europa . eu / legal - content / EN / ALL / ?uri = CELEX : 32011R1207. (accessed: 31.03.2020).

[11] Yoohwan Kim, Ju-Yeon Jo, and Sungchul Lee. “A secure location verification method for ADS-B”. In: 2016 IEEE/AIAA 35th Digital Avionics Systems Conference (DASC). IEEE. 2016.

(37)

Bibliography

[12] Asma Tabassum, Nicholas Allen, and William Semke. “ADS-B message contents evalua-tion and breakdown of anomalies”. In: 2017 IEEE/AIAA 36th Digital Avionics Systems Conference (DASC). IEEE. 2017.

[13] _{Junzi Sun. ADS-B Basics. url: https://mode-s.org/decode/adsb/introduction.} html. (accessed: 01.04.2020).

[14] Junzi Sun. “The 1090MHz Riddle”. In: An open-access book about decoding Mode-S and ADS-B data (2015).

[15] Aaron Dutle, Mariano Moscato, Laura Titolo, César Muñoz, Gregory Anderson, and François Bobot. “Formal analysis of the compact position reporting algorithm”. In: For-mal Aspects of Computing (2020), pp. 1–22.

[16] Martin Strohmeier. “Security in Next Generation Air Traffic Communication Networks”. An optional note. PhD thesis. The address of the publisher: Kellogg College, University of Oxford, July 2016.

[17] _{FANS-1/A and ATN Implementations. url: http : / / members . optusnet . com .} au / ~cjr / introduction . htm ? fbclid = IwAR0KnyEx1h9FkAbimeRbd3BFoDjHWYth -V3GyNlA3FId0aOhzWGLL150hLg. (accessed: 05.16.2020).

[18] Interoperability Requirements for ATS Applications Using ARINC 622 Data Communica-tion Document. url: http://www.asas-tn.org/library/standardisaCommunica-tionsbodies/ eurocae/g1-019.pdf/view. (accessed: 29.04.2020).

[19] INTERNATIONAL CIVIL AVIATION ORGANIZATION ASIA AND PACIFIC

OF-FICE. url: https://www.icao.int/APAC/Documents/edocs/icd_aidc_ver3.pdf. (accessed: 26.05.2020).

[20] International Civil Aviation Organization. Global Operational Data Link Document (GOLD). 2018. url: https : / / www . icao . int / APAC / Documents / edocs / GOLD _ 2Edition.pdf. (accessed: 27.03.2020).

[21] Tenkasi V Ramabadran and Sunil S Gaitonde. “A tutorial on CRC computations”. In: IEEE micro 8.4 (1988), pp. 62–75.

[22] _{RTL-SDR. What is Software Defined Radio? url:} https://www.rtl-sdr.com/about-rtl-sdr/. (accessed: 26.03.2020).

[23] Alexander M Wyglinski, Robin Getz, Travis Collins, and Di Pu. Software-defined radio for engineers. Artech House, 2018.

[24] MB Sruthi, M Abirami, Akhil Manikkoth, R Gandhiraj, and KP Soman. “Low cost digital transceiver design for Software Defined Radio using RTL-SDR”. In: 2013 inter-national mutli-conference on automation, computing, communication, control and com-pressed sensing (iMac4s). IEEE. 2013, pp. 852–855.

[25] _{Great Scott Gadgets. HackRF One. url: https://greatscottgadgets.com/hackrf/} one/. (accessed: 26.03.2020).

[26] _{RTL-SDR.com. RTL-SDR Blog V3 Datasheet. url: https : / / www . rtl - sdr . com /} wp - content / uploads / 2018 / 02 / RTL - SDR - Blog - V3 - Datasheet . pdf. (accessed: 03.04.2020).

[27] Swedish Post and Telecom Authority. About the Swedish Post and Telecom Authority. url: https://pts.se/globalassets/startpage/dokument/icke-legala-dokument/ faktablad/ovrigt/eng-om-pts-okt-2018-2.pdf. (accessed: 04.04.2020).

[28] _{Post- och telestyrelsens författningssamling. url: https://www.pts.se/globalassets/} startpage / dokument / legala dokument / foreskrifter / radio / ptsfs 2013 _ 4 -undantag-tillstand.pdf. (accessed: 04.04.2020).

[29] _{GNU Radio. What is GNU Radio? url: https://www.gnuradio.org/docs/..} (ac-cessed: 29.03.2020).

(38)

Bibliography

[30] _{GNU Radio Primer. url: https : / / www . blackhillsinfosec . com / gnu radio} -primer/. (accessed: 16.05.2020).

[31] _{GNU Radio Companion. url: https : / / wiki . gnuradio . org / index . php / Guided _} Tutorial_GRC. (accessed: 16.05.2020).

[32] Kayvan Faghih Mirzaei, Bruno Pessanha de Carvalho, and Patrick Pschorn. Security of ADS-B: Attack Scenarios. Tech. rep. Technical Report. EasyChair, 2019.

[33] _{L-band digital aeronautical communication system. url: https://www.eurocontrol.} int / system / l - band - digital - aeronautical - communication - system. (accessed: 25.05.2020).

[34] _{European Aviation Safety Agency. url: https://ec.europa.eu/transport/sites/} transport / files / modes / air / single _ european _ sky / doc / implementing _ rules / 2014-04-23-easa-datalink-report.pdf. (accessed: 26.05.2020).

(39)

A

Appendix

A.1 ASN.1

1 ACTwoWayDataLinkCommunications DEFINITIONS IMPLICIT TAGS ::= BEGIN 2 ATCuplinkmessage ::= SEQUENCE

3 {

4 ATCmessageheader,

5 ATCuplinkmsgelementid,

6 aTCuplinkmsgelementid-seqOf SEQUENCE SIZE (1..4) OF ATCuplinkmsgelementid ãÑ 7 OPTIONAL 8 } 9 10 ATCmessageheader ::= SEQUENCE 11 { 12 Msgidentificationnumber, 13 Msgreferencenumber OPTIONAL 14 Timestamp OPTIONAL 15 } 16 17 Msgidentificationnumber ::= INTEGER (0..63) 18 19 Msgreferencenumber ::= INTEGER (0..63) 20 21 Timestamp ::= SEQUENCE 22 { 23 Timehours, 24 Timeminutes, 25 Timeseconds 26 } 27 28 Timehours ::= INTEGER (0..23)

(40)

A.1. ASN.1

30

31 Timeminutes ::= INTEGER (0..59)

32 --Units = 1 Minute, Range (0..59)

33

34 Timeseconds ::= INTEGER (0..59)

35 --Units = 1 Second, Range (0..59)

36

37 ATCuplinkmsgelementid ::= CHOICE

38 {

39

40

41 -- UNABLE Urg(N)/Alr(V)/Resp(NE )/Rec( )

42 uM0NULL [0] UM0NULL,

43

44 -- STANDBY Urg(N)/Alr(V)/Resp(NE )/Rec( )

46

47 -- REQUEST DEFERRED Urg(N)/Alr(V)/Resp(NE )/Rec( )

49

50 -- ROGER Urg(N)/Alr(V)/Resp(NE )/Rec( )

52

53 -- AFFIRM Urg(N)/Alr(V)/Resp(NE )/Rec( )

55

56

57 -- NEGATIVE Urg(N)/Alr(V)/Resp(NE )/Rec( )

59

60 -- EXPECT [altitude] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

61 uM6Altitude [6] UM6Altitude,

62

63 -- EXPECT CLIMB AT [time] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

64 uM7Time [7] UM7Time,

65

66 -- EXPECT CLIMB AT [position] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

67 uM8Position [8] UM8Position,

68

69 -- EXPECT DESCENT AT [time] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

71

72 -- EXPECT DESCENT AT [position] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

74

75 -- EXPECT CRUISE CLIMB AT [time] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

(41)

A.1. ASN.1

78 -- EXPECT CRUISE CLIMB AT [position] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

80

81 -- AT [time] EXPECT CLIMB TO [altitude] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

82 uM13TimeAltitude [13] UM13TimeAltitude, 83

84 -- AT [position] EXPECT CLIMB TO [altitude] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

85 uM14PositionAltitude [14] UM14PositionAltitude, 86

87 -- AT [time] EXPECT DESCENT TO [altitude] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

90 -- AT [position] EXPECT DESCENT TO [altitude] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

93 -- AT [time] EXPECT CRUISE CLIMB TO [altitude] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

96 -- AT [position] EXPECT CRUISE CLIMB TO [altitude] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

99 -- MAINTAIN [altitude] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC)

101

102 -- CLIMB TO AND MAINTAIN

[altitude] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC) ãÑ

104

105 -- AT [time] CLIMB TO AND MAINTAIN

108 -- AT [position] CLIMB TO AND MAINTAIN

111 -- DESCEND TO AND MAINTAIN

113

114 -- AT [time] DESCEND TO AND MAINTAIN

117 -- AT [position] DESCEND TO AND MAINTAIN

(42)

A.1. ASN.1

120 -- CLIMB TO REACH [altitude] BY

[time] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC) ãÑ

121 uM26AltitudeTime [26] UM26AltitudeTime, 122

123 -- CLIMB TO REACH [altitude] BY

[position] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC) ãÑ

124 uM27AltitudePosition [27] UM27AltitudePosition, 125

126 -- DESCEND TO REACH [altitude] BY

[time] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC) ãÑ

127 uM28AltitudeTime [28] UM28AltitudeTime, 128

129 -- DESCEND TO REACH [altitude] BY

[position] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC) ãÑ

130 uM29AltitudePosition [29] UM29AltitudePosition, 131

132 -- MAINTAIN BLOCK [altitude] TO

133 uM30AltitudeAltitude [30] UM30AltitudeAltitude, 134

135 -- CLIMB TO AND MAINTAIN BLOCK

136 -- [altitude] TO [altitude] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC) 137 uM31AltitudeAltitude [31] UM31AltitudeAltitude,

138

139 -- DESCEND TO AND MAINTAIN BLOCK

140 -- [altitude] TO [altitude] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC) 141 uM32AltitudeAltitude [32] UM32AltitudeAltitude,

142

143 -- CRUISE [altitude] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC)

145

146 -- CRUISE CLIMB TO [altitude] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC)

148

149 -- CRUISE CLIMB ABOVE

151

152 -- EXPEDITE CLIMB TO

[altitude] Urg(U)/Alr(A)/Resp(W/U)/Rec(VC) ãÑ

154

155 -- EXPEDITE DESCENT TO

[altitude] Urg(U)/Alr(A)/Resp(W/U)/Rec(VC) ãÑ

157

158 -- IMMEDIATELY CLIMB TO

[altitude] Urg(D)/Alr(A/D)/Resp(W/U)/Rec(VC) ãÑ

(43)

A.1. ASN.1

161 -- IMMEDIATELY DESCEND TO

163

164 -- IMMEDIATELY STOP CLIMB AT

165

167

168 -- IMMEDIATELY STOP DESCENT AT

170

171 -- EXPECT TO CROSS [position] AT [altitude] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

174 -- EXPECT TO CROSS [position] AT OR ABOVE [altitude] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

177 -- EXPECT TO CROSS [position] AT OR BELOW [altitude] Urg(L)/Alr(V)/Resp( R )/Rec(EC)

ãÑ

180 -- EXPECT TO CROSS [position] AT

181 -- AND MAINTAIN [altitude] Urg(L)/Alr(V)/Resp( R )/Rec(EC) 182 uM45PositionAltitude [45] UM45PositionAltitude,

183

184 -- CROSS [position] AT

187 -- CROSS [position] AT OR ABOVE

190 -- CROSS [position] AT OR BELOW

193 -- CROSS [position] AT AND MAINTAIN

196 -- CROSS [position] BETWEEN [altitude] AND

197 uM50PositionAltitudeAltitude [50] UM50PositionAltitudeAltitude, 198

199 -- CROSS [position] AT [time] Urg(N)/Alr(A)/Resp(W/U)/Rec( ) 200 uM51PositionTime [51] UM51PositionTime,

(44)

A.1. ASN.1

202 -- CROSS [position] AT OR BEFORE

[time] Urg(N)/Alr(A)/Resp(W/U)/Rec( ) ãÑ

203 uM52PositionTime [52] UM52PositionTime, 204

205 -- CROSS [position] AT OR AFTER

206 uM53PositionTime [53] UM53PositionTime, 207

208 -- CROSS [position] BETWEEN [time] AND

209 uM54PositionTimeTime [54] UM54PositionTimeTime, 210

211 -- CROSS [position] AT [speed] Urg(N)/Alr(A)/Resp(W/U)/Rec( ) 212 uM55PositionSpeed [55] UM55PositionSpeed,

213

214 -- CROSS [position] AT OR LESS THAN

[speed] Urg(N)/Alr(A)/Resp(W/U)/Rec( ) ãÑ

215 uM56PositionSpeed [56] UM56PositionSpeed, 216

217 -- CROSS [position] AT OR GREATER THAN

[speed] Urg(N)/Alr(A)/Resp(W/U)/Rec( ) ãÑ

218 uM57PositionSpeed [57] UM57PositionSpeed, 219

220 -- CROSS [position] AT [time] AT

221

222 uM58PositionTimeAltitude [58] UM58PositionTimeAltitude, 223

224 -- CROSS [position] AT OR BEFORE [time] AT

227 -- CROSS [position] AT OR AFTER [time] AT

230 -- CROSS [position] AT AND MAINTAIN [altitude] AT [speed] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC) ãÑ

231 uM61PositionAltitudeSpeed [61] UM61PositionAltitudeSpeed, 232

233 -- AT [time] CROSS [position] AT AND MAINTAIN [altitude] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC) ãÑ

234 uM62TimePositionAltitude [62] UM62TimePositionAltitude, 235

236 -- AT [time] CROSS [position] AT 237 -- AND MAINTAIN [altitude] AT

[speed] Urg(N)/Alr(A)/Resp(W/U)/Rec(VC) ãÑ

238 uM63TimePositionAltitudeSpeed [63] UM63TimePositionAltitudeSpeed, 239

240 -- OFFSET [distanceoffset] [direction] OF

ROUTE Urg(N)/Alr(A)/Resp(W/U)/Rec( ) ãÑ

241 uM64DistanceoffsetDirection [64] UM64DistanceoffsetDirection, 242

Simulating ADS-B and CPDLC messages with SDR

Linköping University | Department of Computer and Information Science

Bachelor thesis, 16 ECTS | Information Technology

2020 | LIU-IDA/LITH-EX-G--20/037--SE

Simulating ADS-B and CPDLC

messages with SDR

Simulering av ADS-B- och CPDLC-meddelanden med hjälp

av SDR

Sofie Eskilsson

Hanna Gustafsson

Upphovsrätt

Copyright

Acknowledgments

Contents

List of Figures

List of Tables

Abbreviations

1

Introduction

1.1

Motivation

1.2

Aim

1.3

Research questions

1.4

Delimitation

1.5

Related work

2

Theory

2.1

Air Traffic Control

2.2

Automatic Dependent Surveillance – Broadcast

2.2.1

ADS-B Message

2.2.2

Compact Position Reporting Algorithm

2.3

Controller Pilot Data Link Communications

2.3.1

CPDLC messages

2.3.2

CPDLC message types

2.3.3

Initial CPDLC Connection Establishment

2.3.4

CPDLC connection transfer

2.4

Software Defined Radio

2.4.1

HackRF One

2.4.2

Realtek-Software Defined Radio

2.4.3

License free radio frequencies

2.4.4

GNU Radio

2.5

ASN.1 Studio

2.6

Attacks

3

Method

3.1

Pre-study

3.2

Implementation of ADS-B

3.2.1

Encode and transmit messages

3.2.2

Receive and decode messages

3.3

Implementation CPDLC

3.3.1

Create message

3.3.2

Transmit messages

3.3.3