CONTROLLER PILOT DATA LINK COMMUNICATION SECURITY:A PRACTICAL STUDY

André Lehto, Isak Sestorp, Suleman Khan, Andrei GurtovDepartment of Computer and Information Science, Linköping University, Sweden

AbstractController-Pilot Data Link Communication, a

technology that has been introduced to help offloadthe congested VHF voice communication in largerairports, is being questioned on its sufficiency insecurity. As the traffic load in air traffic com-munication keeps demanding more reliable andsecure systems, we in this paper look at how widelyCPDLC is actually used in practice in Europe. Byusing the newly introduced technology in softwaredefined radios, we show that it is possible tocapture and decode CPDLC messages to readableplain text. Furthermore, we discuss which typeof attacks could be possible with informationretrieved from CPDLC communication.

I. IntroductionAs the air traffic load and air traffic communi-

cation at larger airports keeps expanding, a technol-ogy to unburden the traditional Very High Frequency(VHF) voice communication has become necessary. Itis estimated that the world-wide aerial traffic will dou-ble until 2037, with big European airports handling upto 3000 daily take-offs and landings [1]. Meanwhile,the Unmanned Aircraft (UA) are predicted to out-number traditional air traffic, congesting the airspaceand making reliable and secure systems a necessity[2]. To solve the overload in air traffic communi-cation, Controller-Pilot Data Link Communication(CPDLC) was introduced. CPDLC complements VHFradio voice communication by handling non-criticalcommunication and has since its introduction reducedmiscommunications and increased communication ef-fectiveness [3].

In recent years, the question if the security inCPDLC is suitable for its use has arisen [4]. His-torically, security has not been a consideration whendesigning communication systems and was insteadbuilt around the procedural measures and vigilanceof aircraft crew and air traffic controllers [5]. This

demands situational awareness of the anticipated airtraffic at any given time, where the security lies inthe trust between the Air Traffic Control (ATC) andpilot. ATCs are then relying on pilots to not divertfrom instructions and pilots trusting the ATC to notgive them instructions that will divert them from theirintended destination. CPDLC suffers from this typeof lack of security, which according to [6] makesCPDLC insecure on a conceptual level.

At the same time, lightweight, easily purchasablehardware such as the software-defined radios hasentered the market. This has given common peopleaccess to sophisticated radio manipulation tools andtaken away the technical advantage that used toprotect aviation communication. With the increasingaerial traffic, this has raised the question of whetherCPDLC, a system that has not been designed consid-ering security, can withstand the security risks today.

This article focuses on demonstrating how secureCPDLC is by proving whether data can be capturedusing a Realtek-Software Defined Radio (RTL-SDR)of model R820T2 RTL2832U with limited capa-bilities in terms of range and reception. The testsdescribed in the paper are proof of concept and arefor this reason limited in the number of attemptsand locations. Of the two CPDLC implementationsATN-B1 and FANS 1/A, ATN-B1 is looked at in thispaper whereas FANS 1/A has been excluded. Thisis a deliberate decision, since tests will take placein Sweden, where ATN-B1 is used exclusively. Inthe paper, possible attacks that could be performedon CPDLC are discussed but without suggesting howthis would be done in reality which would encouragesomething illegal.

II. Related WorkThe security in the CPDLC standard has been

questioned by several researchers and there is someconsensus on that the security is insufficient. In [5]Stromheimer accentuates the lack of security in most

systems used in aviation communication, CPDLCincluded. Di Marco et al. investigated the possibilityof carrying out injection and manipulation attacks onCPDLC in [7], where they simulated attacks in acontrolled environment, using free and open sourcesoftware. By showing that it is possible to performattacks on CPDLC, their work demonstrated that thestandard is insecure. The insecure state of CPDLCis further investigated by Wernberg in [8]. Wernbergidentifies threats, possible attacks and ways of mit-igating these. In gurkan Gurtov et al. expands onWernbergs work and discusses how improvements inCPDLC security are constrained by how the standardis put together.

III. BackgroundThe primary means of communication between

ATC and aircraft is voice-communication over VHF,which is an analogue technology and is limited to anumber of frequencies. Since voice communicationalways has a risk of misunderstandings, e.g. frompronunciation differences, the high level of usage to-gether with the limited frequency band and necessityof reliable communication led to the introduction ofthe CPDLC standard. CPDLC is a message-basedAir Traffic Network (ATN) between aircraft and AirTraffic Services Unit (ATSU). The aircraft and ATCsend predefined messages (e.g. clearances and re-quests) using terminals, which could be compared tosending SMS with cellphones. As with SMS, CPDLCis primarily used for non-critical communication.Examples also exist where a human error has beenremoved altogether by automating clearance and start-up CPDLC messages. The introduction of CPDLChas reduced traffic on the VHF voice band and hasthereby also reduced the miscommunications due tospeech misunderstandings. Even though CPDLC is in-tended to use predefined messages, the terminals havethe capability to send messages that are formulated infree text. In addition, CPDLC features accountabilityby logging messages that are exchanged [5].

IV. CPDLC Working ProceduresThis section describes the two key procedures

in CPDLC communication, which are logon andhandover between ATSUs, as well as how messagesare formatted. Figure 1 depicts a generic CPDLC

communication flow with the procedures explainedin this section.

Figure 1: Example of communication in a CPDLCconnection [3].

1) Initial logon requestAn initial logon request (CMLogonRequest) is

used in multiple instances of CPDLC procedures. Thesimplest being the aircraft preparing for departure, inwhich the aircraft remain stationary. Other reasons tomake a logon request includes an aircraft in motion,either an aircraft entering an area that supports datalink services from an area where no such supportexists or by the instruction by ATC in case of a faileddata link transfer. To be able to set up a data link,the Data Link Initiation Capability (DLIC) is used.It provides the necessary information used to set upa data link. After DLIC has been executed, the logonprocess of CPDLC can execute, which is illustratedin the first part of Figure 1.

For an initial logon request (CMLogonRequest)to be made, the flight crew has to enter a four-character identifier code, representing the ATSU towhich the logon request is to be sent.

It is paramount that the flight crew ensure thatthe information entered into the aircraft system isequivalent to the details in the flight plan of theaircraft. When the logon request is being performedby the flight crew, the logon information is beingtransmitted to the specified ATSU in a logon requestmessage as seen in Table I [3].

2) Logon responseWhen the ground system receives a logon re-

quest it automatically responds with a logon response

message as seen in Table I. The message containswhether the logon request was successful or not. Alogon request is denied by the ATSU if:

• There is no flight plan for the flight.• The aircraft registration/address does not match

the aircraft registration/address in the logon re-quest message.The message also contains information about the

ATS data link applications that the ATSU supports.[3]

Table I: Air-ground data link messages for DLIC[3].

Generic Message Name Purpose ATN B1 MessagesAir-ground logon procedure

Logon request

Used to confirm the identity of theaircraft and its data link capabilities,as well as notifying the ATSU aboutthe flight crew’s intention to use datalink services.

CM_LOGON_REQUEST

Logon ResponeA reply to the aircraft containing thestatus of its logon request. CM_LOGON_RESPONSE

Air-ground address forwarding procedure

Contact Request To instruct the aircraft to send alogon request to the specified ATSU. CM_CONTACT_REQUEST

Contact CompleteTo provide the initiating ATSUwith the status of the logon requestsent to the specified ATSU.

CM_CONTACT_RESPONSE

3) Active and inactive connectionWhen discussing CPDLC connections, active

and inactive connections are two central concepts.A CPDLC connection is either active or inactivedepending on whether it is designated for communi-cation or not. Where an ATSU and an aircraft uses theCPDLC connection to communicate, the connectionis referred to as an active connection and the ATSUbecomes the Current Data Authority (CDA), i.e. theground system through which the CPDLC dialogue isauthorized to take place. A CPDLC connection thatis not used for communicating is referred to as aninactive connection and the ATSU is then referred toas Next Data Authority (NDA) [3].

4) Establishing a connectionAfter an ATSU has successfully correlated an

aircraft with an associated flight plan and the aircraftis logged on, a CPDLC connection can be established.An active CPDLC connection can be established ifthere is no existing connection to an aircraft whereasan inactive connection can be established if there isa previous connection. This is illustrated in Figure 1,before the first Exchange of CPDLC messages.

How a CPDLC connection is established de-pends on whether there is a connection or not, in otherwords, if an active or inactive CPDLC connection is

to be established. To establish an active or inactiveCPDLC connection, an ATSU sends a connectionrequest to the aircraft. The recipient aircraft can thenestablish an active or inactive CPDLC connection bysetting the requested connection as active or inactive.For an inactive CPDLC connection, an aircraft alsoverifies that the sender ATSU is specified as NDA.Lastly, an aircraft responds with a CPDLC connectionconfirmation. An aircraft also has the possibility toreject a CPDLC connection by sending a connectionreject message. [3]

5) Address forwardingWhen an aircraft is leaving an area that the

ATSU controls, the ATSU can forward the air-groundaddress and instruct the aircraft to initiate a logonrequest to another ATSU. This is done automaticallyby the ATSU, without the involvement of the flightcrew. The CDA usually initiates the forwarding topermit a downstream or adjacent ATSU to establishan inactive CPDLC connection. The forwarding isdone by sending a contact request message. Whenreceived, the aircraft automatically sends a logonrequest to the next ATSU using the address specifiedin the contact request message. If the forwarding issuccessful, the initiating ATSU also receives a contactcomplete message. The forwarding procedure can,if functionality allows, also be done between twoATSUs. The information sent in this case is the sameas within air-ground address forwarding [3].

Figure 2: Connection forwarding [3].

6) Transferring a connectionSince aircraft are not stationary and VDL2 has a

limited transmission range, CPDLC connections needto be transferred between ATSUs. In Figure 1 this pro-cess is illustrated, beginning after the first Exchangeof CPDLC messages. This is managed by the ATSUsto ensure that the ATSU with control over an aircrafthas an active connection. By transferring an active

CPDLC connection, control is transferred betweenATSUs, as seen in Figure 2. A transfer is initiatedby the CDA which sends a NDA message containingthe identity of the ATSU that is to be transferredto. The CDA then initiates address forwarding withthe ATSU that the aircraft is transferring to. Whenthe aircraft is in the proximity of the ATSU it istransferring to, the CDA sends a CPDLC terminationrequest terminating the active CPDLC connectionto the aircraft. A termination request containing aCONTACT or MONITOR message element is repliedto with a WILCO (Will Comply) message element toterminate a connection. The passive connection to thenext ATSU is then changed to active and that ATSUbecomes CDA [3].

7) Message formatThe messages sent in a CPDLC connection fol-

low a specified format and consist of a number ofmessage elements for message types, identification,responses, and ordering. The number of messageelements are ranging from one to five, making it eithera single or multi-element. Each message element iscomposed of a number of attributes. Currently, a typeidentifier attribute and a response attribute is used buturgency and alert attributes also exist. The uplink anddownlink message elements are prefixed as UM andDM respectively, followed by a number. The com-binations are standardized and have predeterminedmeanings.

CPDLC messages also contain a response at-tribute that specifies if a response is required. InUM this attribute furthermore specifies what typeof response that is required. Multi-element CPDLCmessages can have multiple response types but arelimited to a single response. The type of responseis determined by precedence of response types withhigher giving priority.

CPDLC uses two identification numbers anddialogues to relate CPDLC messages. Every UM andDM is assigned a Message Identification Number(MIN) that is used to identify individual CPDLCmessages. The number is an integer within 0-63 thatis incremented independently for up- and downlinkmessages. CPDLC messages related to each otherare grouped into dialogues where messages are refer-enced in responses using Message Reference Numbers(MRN). In a dialogue, MRN of a response is the sameas the MIN of the message it responds to.

A CPDLC message is open if it requires but hasnot yet received a response. When a response hasbeen received or no response is required the CPDLCmessage is closed. A CPDLC dialogue that has anopen message is also open. In other cases than this,a dialouge is closed.

8) SecurityCPDLC data is not encrypted but still not com-

pletely unprotected. In the current implementation ofCPDLC, referred to as a protected mode, a 32-bitCyclic Redundancy Check (CRC) called ApplicationMessage Integrity Check (AMIC) is used to ensurethe integrity of the messages [9].

9) Cyclic Redundancy Check (CRC)CRC checks integrity by using checksums that

are calculated by sending and receiving nodes using apredetermined algorithm. The sending node calculatesit using known values and adds it to the data thatis sent. Since the checksum does not change thedata it is added to, it is said to add redundancy.The receiving node then performs a check, wherethe received checksum is compared to a checksum ithas calculated, using known values. If the receivedchecksum and the one calculated by the receivingnode are equal, the same parameters have been usedin the calculations and the message data is unchanged[10].

10) Application Message Integrity Check(AMIC)

AMIC, used in CPDLC protected mode, usesCRC to verify message delivery. This verifies thatmessages are sent to the correct recipient and sentby the intended sender. The locally known valuesused to calculate the AMIC checksums are a 24-bitICAO address, Aircraft Flight ID and Ground FacilityDesignator (GFD) [11].

11) AttacksThe lack of security measures in CPDLC leaves

it at risk of attacks exploiting the system. In [12]Gurtov et al. describe six types of attacks that CPDLCcould be exposed to, briefly explained in the bulletpoints below.

• Eavesdropping is listening in on communicationwithout being authorized to do so. Hardware toreceive a signal and software to decode dataare the only things required to eavesdrop andthis type of attack is therefore regarded as verysimple. There are no direct effects besides broken

confidentiality caused by eavesdropping. Sensi-tive information could be extracted and be usedto carry out more complex attacks.

• Jamming denies a user correct service. By fillinga channel with noise the channel’s capacity isreduced and data sent to a receiver becomesincomprehensible.

• Flooding also denies a user correct service butdoes it by "flooding" a receiver with data. Thisoverfills the user’s receiving queue and makes itunable for the user to timely handle incomingtraffic.

• Injection is where unauthorized data is sent.The data is sent by an unauthorized source andinjected into the network where it is delivered.

• Masquerading is impersonating an authorizeduser to gain privileges. Conducting a full con-versation is possible if the masque remains un-detected.

V. Legacy vs Software-Defined Radio

A. Aircraft Communications Addressing andReporting System

Aircraft Communication Addressing and Report-ing System (ACARS) is a digital data link systemdeveloped in the 1970s, used to send short and simplemessages in communication to and from aircraft. Thesystem has a known lack of security and uses astandardized solution and is as of now an availablestandard [8].

B. Realtek Software Defined Radio (RTL-SDR)

Realtek-Software Defined Radio, or RTL-SDR,is an affordable USB dongle that can be used asa computer-based radio scanner for receiving liveradio signals in your area without the involvementof internet connection.

The software-defined radio technology is a solu-tion to replace conventional hardware used in radioby building a software-based radio system with func-tional modules such as modulation, demodulation,signal generation, coding and link layer protocols.Since the technology changes an initial hardwareproblem into a software one, the architecture is highlyadjustable and re-programmable [13].

VI. Experimental SetupIn this section, we will describe the method cre-

ated and used to capture CPDLC data. The requisitesfor the method are explained and lastly, the methodis evaluated.

A. Implementation and VerificationIn our experiments, a setup consisting of a

RTL-SDR dongle of model R820T2 RTL2832U, anantenna and a Chromebook running Crouton wasused, as can be seen in Figure 3. RTL-SDR isa light-weight, software-based radio solution withfunctional modules that can be used to receivinglive radio signals. In our experiment, we used thecommunity-created software dumpvdl2, created byTomasz Lemiech. dumpvdl2 is a lightweight decoderthat decodes VDL2 data sent on the VHF radio-band. It has originally been used to capture ACARSmessages in applications such as PlanePlotter but hasin recent time started supporting decoding of theCPDLC protocol [14].

Figure 3: Picture of the setup used in the tests tocapture CPDLC data.

B. Installation and configurationThe installment of dumpvdl2 was done on the

Crouton Linux extension for ChromeOS following theREADME file from Tomasz Lemiech GitHub project[14]. The necessary dependencies for dumpvdl2 arethe following:

• gcc• make

• cmake• pkg-config• git• glib2• libacars

Dependencies such as gcc, are already includedin linux OS by standard, but some has to be addedmanually. We add required dependencies for cmakeand pkg-config using:$ sudo apt-get install build-essential cmake git libglib2.0-dev pkg-config

Another necessary dependency is libacars, whichalso has to be manually installed. We can do this bycloning the project from GitHub, compile and buildit:$ cd

$ git clone https://github.com/szpajder/libacars

$ cd libacars

$ mkdir build

$ cd build

$ cmake ../

$ make

$ sudo make install

$ sudo ldconfig

When all dependencies have been installed, wego on to install dumpvdl2 by cloning the project fromGitHub and configuring the build using:$ cd

$ git clone https://github.com/szpajder/dumpvdl2.git

$ cd dumpvdl2

$ mkdir build

$ cd build

$ cmake ../

After making the configuration, the process willdisplay a message with a short configuration summaryusing:-- dumpvdl2 configuration summary:

-- - SDR drivers:

-- - librtsdr: requested: ON enabled: TRUE

-- - mirisdr: requested: ON enabled: TRUE

-- - sdrplay: requested: ON enabled: FALSE

-- - soapysdr: requested: ON enabled: TRUE

-- - Other options:

-- - Etsy StatsD: requested: ON enabled: FALSE

-- Configuring done

After the configuration is complete, we can com-pile and install the program using:

$ make

$ sudo make install

The last install-command will install a binarynamed dumpvdl2 in the default directory, /usr/lo-cal/bin on Linux. By using the following commandwe can display a list of available command lineoptions.$ /usr/local/bin/dumpvdl2 --help

C. UsageThe tests using dumpvdl2 was conducted at

Stockholm Arlanda Airport. The antenna was placedwithin a kilometer of the ATC and dumpvdl2 wasstarted, collecting and decoding radio traffic on fre-quencies 136,725, 136,975, 136,955, 136,775 and136,975 MHz. The test lasted one hour, divided in10-minute intervals, and the decoded data was savedinto text-files as plain text using the command:$ dumpvdl2 --rtlsdr 0 --output-file <'name of output-file'>

--raw-frames --gain 48 136725000 136975000 136955000 136775000 136975000

D. EvaluationThe method we have presented should, given the

prescribed requisites, successfully capture and decodeCPDLC. The software used in our tests are publicallyavailable and easily accessible, which promotes thereplicability of our tests. Since the results of our testswould classify as qualitative, the length of the testcould have been shorter, but the intention was to haveenough data collected to be able to continue our workwithout having to redo the test.

VII. ResultsThis section presents the results achieved from

investigating the usage of CPDLC and from the teststo capture CPDLC data.

A. CPDLC elementsIn total one hour of traffic was captured corre-

sponding to logs with over 65 thousand lines of data.In Figure 5, we present a comparison of the number ofACARS and CPDLC messages sent during the tests.The output logs are therefore a selection from thetests, exemplifying sequences relevant to the aim ofthis paper. The logs present the CPDLC messages

Table II: Flight details for tracked flight betweenStockholm Arlanda (ARN) and Paris Charles deGaulle (CDG) (Flightradar24, 2019).

Date From To Flight ID Departure ArrivalApril 5th 2019 Stockholm (ARN) Paris (CDG) SK571 09:00 UTC 11:17 UTC

that could be filtered out between a ground stationand aircraft with addresses 119AAA and 47BB0Arespectively. The logs also show that the AircraftIdentification is SAS571, which correlates with thescheduled flight between Stockholm Arlanda Airport(ARN) and Paris Charles de Gaulle Airport (CDG)[15]. In Figure 4 and Table II details for the trackedflight are presented.

Figure 4: Aircraft details for tracked flightbetween Stockholm Arlanda (ARN) and ParisCharles de Gaulle (CDG) (Flightradar24, 2019).

Figure 5: ACARS and CPDLC data traffic.

The logs captured contain elements used inCPDLC processes.

VIII. DiscussionIn this section, we will discuss the method and

the results from the tests. The discussion of themethod can be found in Section VIII.A and the resultsare discussed in Section VIII.B.

A. MethodIn the method used, traffic was captured in

intervals of 10 minutes and repeated six times. Thereasoning behind this was to make the recorded logssmaller and more manageable. Another reason wasthat we were unsure of how rapidly the amount of datawould add up in the test and came to the conclusionthat 10-minute intervals was the best approach. Thismade it possible for us to continuously check the logswhile capturing more data. The disadvantage of thisapproach was that we got discontinuation betweenthe intervals where messages might have been lost.In hindsight, the tests could have been recorded ina single file, which would have removed the risk oflosing messages in the downtime of the test.

Since a third-party application was used to cap-ture and decode the data, there is an uncertaintyin validity of the results. In addition, the decoderthat was used seems to be the only open-sourceapplication that is available for SDRs as of now,which deny us the opportunity to compare the resultswith another method.

In terms of replicability, the tests performed areeasily repeated. The hardware used is cheap andeasily acquired and the software open-source andavailable online. The only limitation in replicabilityof the tests is the necessity of being in proximity ofan airport that supports CPDLC.

B. ResultsIn this section we will discuss our results in

terms of what the usage of CPDLC is like and thesecurity of the standard by looking at its CIA (confi-dentiality, integrity and availability). This is then usedto discuss attacks on CPDLC.

C. CPDLC usageEven though there was legislation saying that all

air traffic services within the European Union shoulduse CPDLC by 2013, not all member nations havecurrently implemented it. It is however apparent thatthe implementation of this is progressing, lookingat the increase in implementation made in severalcountries from 2017 to 2018. This also coincides withthe use of CPDLC becoming mandatory for GATflights above FL 285 by 2020. In Sweden, where thetests for this paper were conducted, CPDLC is fullyoperational but only broadcasted from Stockholm and

Malmö. The immediate switch from Stockholm toMalmö by the aircraft analyzed in section VII indicatethat these stations together provide the entire countrywith CPDLC coverage. It would therefore also bereasonable to say that the same applies to othercountries where CPDLC is implemented.

D. CIA in CPDLCBy looking at the implementation of security in

CPDLC, we can discuss weaknesses in the system inperspective of confidentiality, integrity and availabil-ity (CIA).

• Confidentiality: Since CPDLC does not utilizeencryption of data, messages that are sent are un-protected. AMIC offers protection against noisebut does not prevent data from being cap-tured, decoded and read. This leaves informa-tion exchanged in CPDLC open to anyone withequipment to capture and decode CPDLC data.CPDLC is used to transmit sensitive informationthat could be considered confidential. In thiscase, the classification of what information isconfidential and not depends on how the datacan be used. Information that can be used togain access to a data link between an aircraft andATC creates a gateway where attacks with moresevere consequences could be performed. Datawith that kind of information could therefore beclassified as confidential. In spite of confidentialCPDLC data not being protected, real-life attacksexploiting this have not yet been reported.

• Integrity: CPDLC does to some extent pro-vide protection towards the integrity of its data,with the implementation of CRC technology inAMIC. However, the technology only correctserrors upon delivery of the information and se-cures the communication against noise. There iscurrently no way of ensuring the authenticity norintegrity of a message, and information manipu-lation can go unnoticed if done properly. Instead,the validation of a message lies in the humanvigilance, which could easily be surpassed if theinformation appears legitimate. For informationto be considered false, it would therefore haveto be in clear contradiction to the message’soriginal intention.

• Availability: In the event of an attack with theaim at causing damage on availability, such as

jamming or flooding, there are no defense mech-anisms implemented in CPDLC. Depending onthe objective of the attack, the severity can vary.An attack targeting a single aircraft would beless severe than one targeting a ground station.A comparison to this could be made to attacks di-rected towards client and servers, where the con-sequences of attacks against clients usually areless severe than attacks against servers. Since theknowledge of how procedures within the aero-nautical community are handled are transparent,the attack can be made more sophisticated byfocusing the attack on certain weak spots of theprocedures such as logon and termination of aconnection.

E. AttacksThe CPDLC elements contains information that

can be considered sensitive by affecting the confi-dentiality, integrity and availability of CPDLC andultimately be used in attacks [16].

• Eavesdropping: The results prove that it is pos-sible to eavesdrop on CPDLC communication,given the right conditions. With the RTL-SDRsetup and requisites described in Section V, wecaptured CPDLC data at Stockholm ArlandaAirport. This demonstrated that CPDLC data canbe captured using readily available hardware andsoftware at a location accessible to the generalpublic.We cannot make any real claim on how theimplementation at Stockholm Arlanda airportrelates to Malmö or airports in other Europeancountries, but we can argue that they wouldfollow a similar implementation. The fact thatCPDLC is a standard implicates that how itis implemented should be the same or at leastsimilar in different geographic regions, whichfurther implicates that eavesdropping should bepossible with the same type of RTL-SDR setupand requisites that we used in our tests. Thisgives an indication of the difficulty level ofeavesdropping on CPDLC. As we managed tofind all information required and create a func-tional RTL-SDR setup, with some trial and error,this can be considered moderately difficult. Sinceeavesdropping on CPDLC communication doesnot affect the communication, the consequences

of this are modest and could be said to be inproportion to the difficulty of doing so. If infor-mation extracted from CPDLC by eavesdroppingis combined it could however be used in attackswith more severe consequences.

• Jamming/flooding: In the results, we can seethat certain CPDLC messages require logical ac-knowledgements as a response to verify that therequest has been received. By jamming or flood-ing the communication medium, these types ofresponses could be interrupted causing the com-munication to slow down, which would counter-act the intention of why CPDLC was introducedand has been implemented. Especially severedamage could be caused if the attack were to bedirected towards a ground station rather than anaircraft, since blocking out communication fromthe ground station would impair communicationto multiple rather than a single aircraft. If such anattack would be carried out in an airspace withhigh air traffic, the consequences could rise to bebigger than just an inconvenience. As CPDLC isa necessity to manage traffic loads today, it isquestionable whether there is capacity in otheraeronautical communication systems to handlethe load.

• Masquerading/Injection: With CPDLC lackingencryption and with AMIC as its only imple-mentation of security, the possibility of attacksas sophisticated as masquerading and injectionincrease significantly. As AMIC is a type ofCRC, a hashing defense mechanism based oncertain predetermined parameters, it is possibleto compute the AMIC. The fact that we in our re-sults see that we can find most of the parametersused in the AMIC algorithm as plain text, greatlyincreases the chance of a successful attack. Ifan attacker wanted to pose as a participant inthe CPDLC communication, all that would berequired would be to send a message requestinga logical acknowledgement. If the message isreceived and accepted by the recipient, and alogical acknowledgement was to be received bythe attacker, the attacker would know that theAMIC sequence had been found. From here, theattacker could continue posing as either partic-ipant of the communication, possibly causingsevere damage by giving false instructions. Even

though this attack in theory is possible, thesecurity lies in the vigilance of the participantsof the communication. Any instruction with evilintent would realistically be detected if it devi-ates to much from the original plan. With thatsaid, since actually posing as either participantin the communication being feasible, an attacknot deviating much from the original plan, hencenot being detected, could still cause potentialdamage.

IX. Conclusions and Future WorkThe introduction of CPDLC, made to reduce

the traffic load on VHF, has led to improvements incommunication effectiveness. However, this has notcome without complications. Prior to CPDLC, largeairports using were congested due to the high usageof voice communication, something that CPDLC hasrelieved and made more reliable by minimizing mis-understandings and automating parts of the communi-cation. As the results presented in this paper show, theCPDLC standard lacks sufficient security measures toprotect the data that is being sent over VDL2. Thelogon process and AMIC provides CPDLC with themeans to verify the origin and integrity of data butdoes not protect the standard from external influence.Currently, CPDLC is implemented in most of theEuropean Union and to be fully operational by thefirst quarter of 2020. Usage is, however, only bemandatory for GAT flight above FL 285.

By successfully capturing and decoding CPDLCdata, we have proven that it is possible to eavesdropon CPDLC. The data that we have captured andinterpreted into the results, presented in Section VII,contains CPDLC elements with sensitive informationthat could be utilized to carry out attacks with severeconsequences to air traffic. The consequences of theseattacks would be especially noticeable at larger air-ports, that rely on CPDLC to handle the high commu-nication traffic loads, but also to air traffic in general.If a jamming or flooding attack would target CPDLC,the communication might have to revert to voice,which could be speculated whether large airports arecapable of handling today. If the function used tocalculate hashes in AMIC is discovered, data could beinjected into CPDLC communication. Masquerading,by infiltrating the logon process of CPDLC, couldenable an attacker to gain ATC privileges to for

example send instructions to aircraft. The attacks that have been described target each and every confidentiality, integrity and availability in the CIA triad, arguing that CPDLC as of today is not secure. Despite CPDLC being used widely today and is expected to increase in the years to come, there is relatively little research about the technology. This report has merely scratched the surface of what can be done within CPDLC and leaves room for future work. The price and availability of an aircraft CPDLC unit could be explored for simulating attacks in a closed environment. This would also include looking into hardware and software to transmit CPDLC data. As of now, software that captures and decodes communication data is available publicly as open source. Software to encode and as well as to transmit and receive fake CPDLC messages in a safe environment was already demonstrated [16].

The technology can also be approached with an ethical viewpoint, with communication secrecy laws and integrity laws such as GDPR in mind. With the introduction of software-defined radio, the availabil-ity of capturing sensitive radio communication has greatly increased. Is it however legal and ethically right to capture and use this data without permission?

Investigating the more technical aspects of CPDLC could provide further insights into what kind of attacks that could be performed. Looking at the throughput of the Medium Access Control could be of interest when designing malicious software that fo-cuses on subduing the availability of communication using CPDLC.

References [1] Boeing, Boeing Current Market Outlook 2018-2037, 2019. [Online]. Available: http://www.boeing.com/commercial/market/. [2] “Unmannd Aircraft System (UAS) Service Demand 2015-2035,” US Department of Transportation, Last accessed 22 Feb 2021. [Online]. Available: https:// fas.org/irp/program/collect/service.pdf. [3] “Global Operational Data Link Document (GOLD),” International Civil Aviation Organization, 2013. [Online]. Available: https://icao.int/APAC/Documents/

edocs/GOLD_2Edition.pdf. [4] A. Gurtov, “Is CPDLC Secure and Can Identity-Defined Networking help?” In Proc. of ATM Seminar, http://www.atmseminar.org/seminarContent/seminar13/ ATM 2019 Keynote Andrei Gurtov.pdf, 2019. [5] M. Strohmeier, “Security in Next Generation Air Traffic Communication Networks,” Ph.D. Dissertation, Dec. 2016. DOI: 10.13140/RG.2.2.21924.48006. [6] M. Strohmeier, M. Schäfer, R. Pinheiro, V. Lenders, and I. Martinovic, “On Perception and Reality in Wireless Air Traffic Communication Security,” IEEE Transactions on Intelligent Transportation Systems, vol. 18, no. 6, pp. 1338–1357, 2016. DOI: 10.1109/ TITS.2016.2612584. [7] D. Marco, A. Manzo, M. Ivaldi, and J. Hird, “Security Testing with Controller-Pilot Data Link Communications,” in Proc. of 11th International Conference on Availability, Reliability and Security (ARES), 2016, pp. 526–531. DOI: 10.1109/ARES.2016.104. [8] M. Wernberg, “Security and Privacy of Controller Pilot Data Link Communication,” 2018. [Online]. Available: http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-156337. [9] V. S. Sudarsanan, M. A. Jacobs, A. Dervisevic, and D. DeLaurentis, “ADS-B and CPDLC Fault Modeling for Safety Assessment in a Distributed Environment,” in Proc. of IEEE Aerospace Conference, 2018, pp. 1–14. DOI: 10.1109/AERO.2018.8396582. [10] T. Ritter, “The Great CRC Mystery,” Dr. Dobb’s Journal, vol. 11, no. 2, pp. 26–34, 1986. [11] P. Sacre and D. Isaac, “Eurocontrol link 2000+ Guidance to Airborne Implementers,” 2014. [Online]. Available: https://www.eurocontrol.int/sites/default/ files / publication / content / documents / nm / link2000 / link-2000-guidance-to-airborne-implementers.pdf. [12] A. Gurtov, T. Polishchuk, and M. Wernberg, “Controller–Pilot Data Link Communication Security,” Sensors, vol. 18, no. 5, p. 1636, 2018. [13] M. B. Sruthi, M. Abirami, A. Manikkoth, R. Gandhiraj, and K. P. Soman, “Low Cost Digital Transceiver Design for Software Defined Radio Us-ing RTL-SDR,” in Proc. of International Mutli-

Conference on Automation, Computing, Communi-cation, Control and Compressed Sensing (iMac4s), 2013, pp. 852–855. DOI: 10 . 1109 / iMac4s . 2013 . 6526525. [14] T. Lemeich, VDL mode 2 message decoder and protocol analyzer, https : / / github . com / szpajder / dumpvdl2, Last accessed 22 Feb 2022, 2017–2021. [15] Flightradar24, Flight History for Aircraft ln-rgl, https://www.flightradar24.com/data/aircraft/lnrgl, Last accessed June 7th 2019, 2019.

[16] S. Eskilsson, H. Gustafsson, S. Khan, and A. Gurtov, “Demonstrating ADS-B and CPDLC Attacks with Software-Defined Radio,” in 2020 Integrated Communications Navigation and Surveillance Conference (ICNS), IEEE, 2020, 1B2–1.

2021 Integrated Communications, Navigation, and Surveillance (ICNS) Conference

April 20-22, 2021