 Hi, thank you so much for coming. My name is Joshua Smales. I'm a researcher at the University of Oxford Today I'm going to be talking about The CPDLC protocol used in aviation looking at attacks on the protocol and how to prevent them This talk is based on the work in the paper You talking to me exploring practical attacks on control pilot data link communications Which was done in collaboration with Daniel Moser, Matthew Smith, Martin Strohmeyer, Vincent Lenders and Ivan Martinovich This was presented at the CPSS workshop at AGCCS You can find the paper at this link or on Google Scholar So in this talk, we're first going to Introduce the CPDLC protocol then look at attacks on the protocol argue for their feasibility by looking at the message diagrams of the proposed attacks and through data collection and Then look at some countermeasures which might fix the attacks So first things first, let's look at some background of air traffic control and CPDLC So traditionally air traffic control is voice-based using a radio system It's used to direct aircraft within an airspace pilots communicate their intent and Air traffic controllers issue other commands the issue with this system is that it has a Low band width and is half duplex meaning only one Device can communicate at a time up or down Which means it's frequently congested especially as the number of aircraft in an airspace increases The CPDLC protocol that is controller pilot data link communications Attempts to fix some of these issues by replacing the traditional voice air traffic control with a text-based data link this has the benefits of reducing ambiguity due to the clear text messages much shorter communications which reduces the risk of a link becoming saturated and Allows parts of the system to be automated such as control handovers as we'll see soon It also allows for the opportunity to provide flight crew with additional useful information such as Maps built directly into the unit So here we have an example CPDLC message exchange in which an ATSU that is air traffic service units the air traffic controller tells the aircraft to climb to flight level 350 using the Climb to this altitude message identifier The aircraft responds with Wilco indicating that it will comply with the request Which follows the same format as voice air traffic control Except that we add these unambiguous identifiers onto the start of the message so that the system knows what type of message it is CPDLC doesn't have much security built-in and instead aims to focus on guaranteeing Availability and integrity as much as possible much like its voice-based predecessor We use checksums to reduce the impacts of noise But there is no guarantee of confidentiality with messages being transmitted in plain text and we rely on human operators to guarantee authenticity rather than some kind of authentication exchange All right, so now that that's out of the way. Let's look at a threat model for this system So we assume that any attacker has the following hardware a software-defined radio which can transmit in the VHF that is very high frequency band used by CPDLC a Suitable antenna and an amplifier We also assume that they have an encoder and decoder for the CPDLC protocol the dump VDL to Decoder is free and open source, but there is no Encoder freely available yet. However, the specification for CPDLC is published online So it should not be difficult to put one together We then assume that with this hardware an attacker is able to read all CPDLC communications within the radio horizon We also assume they can inject arbitrary messages and block and alter arbitrary messages through destructive interference We also operate on the assumption that they are unable to touch any Ground-based communication between ground stations as these are over wires And so more difficult to interfere with than radio communication So now that we've got that ground workouts of the way we can start looking at attacks on the protocol So the most basic form of attack is a message injection in which we set up our antenna between the ground station and the aircraft and we inject a Crafted message appearing to come from the legitimate ground station in this case we Injects the same climbs flight level 350 message that we saw in the earlier slide and The aircraft receives this command as legitimate and returns a will co-command to the ground station This alerts the ground station to the attack. So it is Unlikely that the attack would be very long-lived. So we need to look at More advanced attacks if we want to have more of an effect Before we start looking at these more advanced attacks I need to first introduce the concept of a control handover in CPDLC So much like voice-based air traffic control CPDLC is splits into control regions each of which is controlled by one ATSU as an aircraft moves between these control regions the ground stations need to Handover control and that's done through this message exchange So first log-on forwarding messages sent between the ground stations and then a Next data authority message is sent to the aircraft indicating the identifier of the new ATSU that it should connect to Another message is then sent over the ground To the new ground station indicating that the aircraft has been sent this message and then the new ATSU Sends a connection request to the aircraft which is confirmed occasionally there is a Termination request confirm handshake from the old ATSU under certain implementations of the protocol So we can use this handover to construct an attack in which we simply Inject the messages relevant to the handover Telling an aircraft to connect over to this ATSU X which is a Legitimates identifier for a ground station but one which is out of range So we can pose as that ground station without causing any issues So this exactly follows the CPD LC handover process So everything appears to be legitimate from the perspective of the aircraft And it will hand over to ATSU X without any issue The one problem that we run into is this termination confirm message Which will be returned to the old ATSU upon Completion of the handshake this will alerts the air traffic controller to the attack and Potentially cause them to reverse it We can get around this by Introducing message jamming to our attack. So we do this by Reactively emitting a burst of destructive interference to block specific messages from reaching the aircraft or the ground station This has been shown in other papers to be possible even reactively So we should be able to put together attacks that use this which are feasible in practice So one approach we can take is to block the termination confirm message we see here and that would result in a Handover attack which would Be hard to detect until the ATSU one attempts to issue a new command At which point the aircraft wouldn't respond because it had already handed over We can also put together this attack which is a little more complicated. So I'm just going to Walk us through it. So At its heart this is taking a legitimate handover between ATSU one and ATSU two and blocking and injecting the relevant messages to Make it appear to the aircraft that they are not in fact handing over to ATSU, but instead to ATSU X which is again controlled by our attacker We can see that this attack works by looking at it from the perspective of each of the involved parties So if we first look at it from the perspective of ATSU one by Blocking out all the messages which ATSU one would not see then we can see that it appears for all intents and purposes to be a legitimate handover to ATSU two and Then if we look at it from the perspective of the aircraft then it doesn't see any of the messages that we block and it only sees the injected messages with ATSU X and This this appears to be a legitimate handover to ATSU X And finally if we look at it from the perspective of ATSU two It again appears to be a legitimate handover between ATSU one and ATSU two so the result of this attack is that The legitimate ATSU studies one and two think that the aircraft is connected to ATSU two the aircraft is Instead connected to ATSU X which is controlled by our attacker So the impact of this attack is that we can inject arbitrary CPDLC commands to the aircraft from our ATSU X with a much lower risk of detection since any Wilco messages will be received by ATSU X and not the Legitimate ATSU this allows us to do things like direct the aircraft off of its intended flight path We can tell it's to switch frequencies for voice air traffic control We can instruct it to ascend or descend and we can do a number of other things such as declaring emergencies and more to detect this attack the human operators need to be able to either Detect unexpected or out-of-sequence messages such as the Such as the termination confirmed message that we saw in the first handover attack or notice a loss of voice communications or see that the Aircraft is moving Unexpectedly with no commands indicating that it was going to do so Or finally they can notice that the CPDLC communication has been Unusually quiet for some time However, all of these require the operator to be especially on ball in terms of looking for these attacks or in the case of aircraft movements It requires that the attack has already succeeded, which is Not what we want. We want to be able to detect attacks Before an attacker is able to tell an aircraft to move off its path We also did some data collection to assess the impact of these attacks So we set up a sensor collecting CPDLC messages above ETH Zurich overlooking the Zurich Airport we used a Raspberry Pi running the free dump VDL2 decoder and this map shows the Messages that we were able to detect so as you can see we were able to find messages up to hundreds of kilometers away So we assume that the attacker will be able to Detect messages within this range and perform attacks within this range So this gives the attacker a huge range within which they can perform the attacks This graph shows the number of CPDLC messages that we saw over time So across the 49 day collection period we saw 57,000 CPDLC messages And saw approximately one handover every six minutes within the range that we were collecting so This means that the attacker Doesn't need to do huge amounts of planning ahead of time to execute these attacks They can simply set up their antenna wait for a handover to occur attempt the attack if it fails Then they simply wait a bit for the next handover and attempt another attack shortly afterwards So we've made the case that this is a problem. So what are we going to do about it? Well, we've proposed a number of countermeasures to the attacks described Some of which are easier to implement than others. Some of which are more effective than others so the first of these countermeasures involves building a Graph of connections between the airspace regions. So this diagram on the right represents a potential map of adjacent airspace regions We draw an edge on the graph whenever airspaces are adjacent to one another so it's feasible for an aircraft to hand over between those two airspaces Whenever the aircraft receives a message instructing it to hand over between airspace regions it checks it against the graph and In the case of this handover, which we outline in red The edge doesn't exist on the graph. So we know that something is up In this case we propose the following exchange of messages In which the aircraft Tells the ATSU that it's unable to fulfill the handover and requests a fallback on voice communications This means that the pilots can Confirm that the handover is legitimate with the air traffic controller over voice This is really easy to implement in a backwards compatible manner because it doesn't require Any hardware changes other than a minor addition to the cpdlc units on board the aircraft and doesn't require enrollments across multiple devices however, it won't stop message injection attacks and it will only stop the handover attack in the case that's the Attack controlled ground station that we specify in our injected message is sufficiently far away from the airspace that the aircraft is currently in Another potential counter measure that we looked at was The idea of interference alerts so the cpdlc protocol is built into the cpdlc units, which means that we can check message exchanges against the understanding of the protocol To look for suspicious or non-standard message exchanges, which might indicate message injection or a man-in-the-middle attack We can also look for bursts of high Noise that is a low signal-to-noise ratio, which in which could indicate potential destructive interference And in each of these cases we once again reverts to voice communications using the same message exchange we looked at earlier This is backwards compatible and indeed it is compatible with the other counter measure that we just looked at but it may not catch very many attacks and It in particular may not catch the man-in-the-middle attacks that we looked at earlier Since as we discussed these appear to be entirely legitimate handover exchanges to both the aircraft and the air traffic controller A more robust counter measure that we propose Involves adding a public key infrastructure or pki system to the cpdlc protocol So this comes in the form of an additional box between the cpdlc unit and the radio antennas This box stores a private public key pair for the aircraft or atsu in question Alongside the public keys of other units in the network This unit insets any cpdlc messages before they are sent by the aircraft or atsu and adds a signature Along with additional information such as the sender recipients time stamp and what we call the home atsu of the unit in question Which we'll discuss in a moment Upon receiving a message the recipients pki units will Again inset the message check the message against the signature to Make sure that it's legitimate and then pass on the message to the cpdlc units This provides a guarantee of authenticity of origin which was not Not the case previously and we Don't encrypt messages to provide a safe fallback in the case that a key is not available Or that the unit in question doesn't have pki implemented So the diagram here shows a typical connection request confirm handshake, which is already in cpdlc But with these additional units so as you can see the The aircraft's message is signed by its key and the atsu's messages signed by its key And these are verified by the units before they're passed on In the case that the signature is not legitimate. We still pass the message onto the cpdlc units, but we alert the pilots in some way to Tell them that the message might be the results of an attack We also add the following message exchange to acquire and distribute keys So as mentioned a moment ago Um Each aircraft and atsu is designated a home atsu which is guaranteed to hold its public key This means that if an aircraft does an atsu doesn't recognize Sends a message then it can perform a key request response handshake as shown here to acquire the key in a secure way And then confirm the message so this um This here shows a connection request confirm handshake, but um The atsu doesn't know the key. So it verifies it before it confirms the cpdlc connection This results in a system which is more robust than the previous cpdlc system But is not backwards compatible since it requires both parties to be enrolled in order to perform the message exchange This um, this system has a number of Impacts the first being that it Prevents the basic message injection attacks that we saw at the start. So here we see the same attempted message injection attack as we saw at the beginning Except that the attacker does not have the key for the atsu so it's unable to provide the signature So this means the flight crew would still see the message But they would know that it might not be legitimate And so they could fall back on voice communications or attempts to verify the legitimacy in some other way It also prevents any message replay attacks thanks to the inclusion of timestamps So here we see an attempted message replay attack in which the atsu sends a legitimate Climb to flight level 350 instruction to the aircraft and then the attacker Captures this message and attempts to replay it However, thanks to the inclusion of this timestamp The message will be seen as being old and the aircraft can alert the flight crew that the message has probably been replayed This system is still potentially vulnerable to downgrade attacks in which the attacker sends a message claiming to not have yet implemented this system and um Asks the flight crew to downgrade to the unsigned variants of cpdlc However, this um This becomes much more difficult as more devices become enrolled onto this system as it becomes more and more Suspicious for an aircraft or atsu to ask for a downgrade so the flight crew will be able to um monitor for potential rogue commands However, this system may suffer from difficulties with enrolment as it requires additional hardware on both the atsu and the aircraft and getting new hardware in aviation through um approval and getting Manufacturers to get on board may be quite a challenging prospect So there are a number of directions which we can take this work in the future So firstly a um further security analysis of cpdlc would be incredibly useful to understand the full range of attacks beyond the ones that we've looked at here Um, there's certainly potential for larger scale attacks involving multiple attack control antennae to um Potentially attack multiple aircraft or ground stations at once It would also be useful to demonstrate the attacks that we've um looked at here on actual cpdlc hardware, which we have been unable to get our hands on just yet And similarly, uh, it would be useful to concretely implement some of the countermeasures that we've looked at here So there are a number of key takeaways from the work here The first thing is that cpdlc is fundamentally insecure. Um Of course, this was already a known issue since um messages aren't signed and there is no guarantee of authenticity However, we um in this work also showed that it is not sufficient to trust that the human operators Will be able to verify the system's security since the attacks that we looked at Look like entirely legitimate message exchanges to the human operators We show that attacks on cpdlc can cause significant disruption and delays And finally we showed that it was difficult but possible to fix some of the problems with cpdlc through um the countermeasures that we discussed Thank you so much for listening. There will be a q and a in the def con discord following this talk If you'd like to see more of this, um, please read the paper linked here And um, if you have any more questions, feel free to shoot me an email. Thank you