Crash all the Flying Things! — Exploiting and Defending Aircraft Collision Avoidance

Okay, good afternoon. Can everyone hear me? Can my mic? Yes. Okay, one person can hear a mic. That's good. Um, so my name is Joe Greenwood as I said. Um, so a brief intro me and then um talk more about why you're here, which is the collision avoidance bit. Um, so what do I do? I'm an aerospace engineering student or was an aerospace engineering student until last Friday um at the University of Bristol um which does aerospace has seen a helicopter. It's aerospace. Um but I'm also a sponsored undergraduate in the Royal Navy going as a pilot flying F-35s a joint strike fighter. Um, and the question that you've probably all got on your minds right now is, oh, sorry. So,

I will be flying joint strike fighter, but at the moment I just run up and down hills with large weights. Um, which isn't exactly great, but the question you have is why am I here? So, why am I here at an infosc conference talking to you about infosc things? Um, and the reason is for the past four years I've done the cyber security challenge UK. Um, and out of that I got a load of crest qualifications and other courses. Um and that allowed me to go away and do an internship with BA systems detica. Um now applied intelligence. So some of you guys in the room at the moment. Um and now at the moment I do consulting with

forearmmed. So I think Mark's in here somewhere. Um and I do pent testing, red teaming and sort of security consultancy on that side. So essentially I took the hacking side because that's what hackers look like, right? Um and the joint strike fight side and the pilot side and the avionics side. Um and that gave me a pretty epic masters project because this is for my university course. U we get to propose our own masters project. So I propose something that took infosc and planes which is always a good start and you can tell it's a good masters project when your risk assessment includes accidentally crashing aircraft. Um so that one was quite interesting to get

past the university risk assessment people. Um but yeah that was quite entertaining. They didn't notice until I pointed it out and then they were like should probably think about that. Um but anyway okay so what we're going to look at um is what is this magic ADSB thing that I'm going to talk about? Um where is that coming? What can we do to it? Um, I mentioned collision avoidance. So, there's a system called TCASS or the traffic collision avoidance system which does what it says on the tin and then overview of all of the complex security mechanisms involved in those two. Um, and then I'm going to explain and demonstrate the attack that I've proposed for it. Um, and I'll have some

live demos if we give an offering to the demo god. We'll see how that goes down. Um, and then shock horror I have some defenses. So, they're not great defenses. I'm going to caveat that. Um, there's not much you can do with legacy protocols in general. Um but I'll sort of explain some of the prototypes and some of the ways you can go through that. Um and then the end we should have some time for questions which should be good. Okay. So the ADSB stands for automated dependent surveillance broadcast system. Um automated and the pilot doesn't have to keep clicking transmit dependent and it's dependent on other sort of systems. So GPS and altitude and all that sort of stuff. Um

and then surveillance because the ground traffic control can use it to surveil aircraft. And then the broadcast bit is self-evident because it transmits. So essentially you have your GPS satellite up here and your aircraft gets its data, its position, its speed, its velocity, its state essentially from that GPS constellation. Then that aircraft formulates a message and then transmits that over 1090 MHz um with a special squitter format to ground stations. So they're beaconing out broadly once or twice a second their position and their state. And then the ground stations can use all this data to use air traffic control data because it's quicker than radar. So radar actually is quite slow to do a complete

cycle. So it's useful for them to have better situational awareness of where the aircraft are. That's that side that is called ADSB out. So that's the aircraft broadcasting out its position. There's another system called ADSB in where other aircraft listen for the ADSB transmissions. So they're taking in the ADSB data and using that to work out where other aircraft are around them. And that's the bit that we're going to be looking at. So, some interesting facts about ADSB. Um, it's mandatory in Australia at the moment. It will be mandatory in Europe for 2017 and it will be mandatory in the US in 2020. Um, and that's part of the uh US's nextG program. And hopefully by the end of this talk,

you'll realize why I laugh when they say it's next generation. So, we'll get to that bit. And the key aim is it aims to replace primary surveillance radar entirely. So, just have this. So bear bear that in mind when we get to the end of the talk. So the collision avoidance bit that everyone was interested in um the traffic collision avoidance system to tass aims funnily enough to stop aircraft colliding which is always a good thing we'd hope. So this was brought in in 1978 because a an airliner I think it was an A320 um impacted with a light aircraft over San Diego and at that point for some reason it was that collision ram all the other air traffic

collisions and they decided you know what we should do something about this. So they invented this system where um TAS takes in data and then it works out whether there's going to be a collision with another aircraft based on that data. If the aircraft, so this is our intruder aircraft, is within 40 seconds, it gives the pilot a warning. So a traffic advisory or TA and that basically it goes off in the cockpit, you get display, it goes traffic, traffic, and that tells the pilot to begin looking visually to see if he can see the aircraft. Useful. Then however, if the aircraft comes within 25 seconds of collision, you get a resolution advisory or an RA. And that's normally

given with an order. So it would be climb or climb now. And the idea is that both aircraft will negotiate which one goes up and which one goes down, which is a good thing because if you both pull up, you still crash, which isn't great. Um, and there's some protocols behind how all of this works. Um, on the back end, this is the actual display the pilot gets. So, you can see here, these are two non-threatening aircraft just display for traffic information. The orange circle is the TCAST T8, the traffic advisory, and the red square is the resolution advisory, the RA. So remember these symbols for later when we have a look at those exact um

displays. So the overview. So like I said there's multiple data sources. So there's active modes and that uses the um mode s transponders. So they talk to each other and trying to work out the range and the bearing and that sort of stuff. But they're also bringing in using ADSB in to give traffic data. And the exact extent to which that works isn't entirely certain. So my project was trying to look at whether you could use that to do something interesting. So some of you will have already spotted the problem with ADSB in and TCAS but we'll get on to that later. So again some interesting facts about TCAS just to bear in mind for the

rest of the talk. TAS has a higher priority than air traffic control. So if you get a TAS RA you ignore air traffic control while you're responding to that RA. That's an interesting thing to quote. Pilots are mandated to respond to it within two and a half seconds. There's not an amazing amount of thought time in this. You see the red blip, you do what the red blip says. essentially and the last thing on modern Airbus aircraft autopilot is slave to tass. So as soon as that thing goes climb the aircraft will be climbing. So again those are three things to to bear in mind for the rest of this talk. So the security this is the part

of um every conference presentation where I sit here and I talk through the labyrinth and complexity of the security how I used wit and guile to bypass it all and get an exploit at the end. Um but Morpheus has something to say about this. Um, so actually there is no security on ADSB whatsoever. There's nothing. There's no encryption. There's no authentication. There's no integrity checking the message. Okay. It just blindly assumes that anyone who's transmitting is an aircraft and that they don't actually have to be wherever they can. So obviously, as the most interesting man of the world says, if you want to get rid rid of radar, you obviously make sure that your protocol

allows anyone to be wherever they are or wherever they want to be rather for this. So there is no security and my project supervisor um initially he's a crypto expert at Bristol he was like no there must be some security there must be something something on there someone will put something and it was only when I showed him this is flight radar 24 where you can view all of the aircraft transmitting ADSB so this is essentially an ADSB in receiver for all of the ADSB that the aircraft are transmitting and as you can see you can pretty much get all of them so there's already ignoring everything else there's a surve surveillance risk with ADSB that anyone

can tell where an aircraft is because it's required by law or will be required by law to transmit its location. So if you for instance wanted to sit at the end of a runway and work out exactly where an aircraft was going to be and you happen to have a surface to air missile then who knows maybe you could do something interesting with that. So there's a whole issue to that that I'm not really going to cover but I'm sure you can see where the issues going. So the exploit pathway for one of a better word um for what my project intended to do um was we'd have an attacker system and we generate these

ADSP messages to try and pretend to be an aircraft in front of another aircraft and at that point hopefully the tcash should go mental. Um so we generate messages for a software radio. Um and then we transmit these over the air. The ADSB receiver then decodes these messages. It doesn't do any checking on them because it just decodes messages. That's what it does. It then passes them to the Tcast system and then depending on what the Tcast system will do um we'd like it or rather we wouldn't like it to alert the pilot with a a resolution advisory and tell them to climb. So this attack in general so obviously avionics hardware is quite expensive and uh I don't know if you've

seen the state of academic funding at the moment but it's not great um and it certainly doesn't stretch to buying an aircraft. So when I went to my supervisor and said, "Can I buy an entire ADSB and TCAST system?" He said, "No, quite flatly." Um, he did however have a load of software defined radios floating around. So we got to use those. Um, so I created or I put together an ADSB and TCAST test bed um using software defined radios and GNU radio. So the idea is we listen on 1090 MHz or whatever we're listening on. Um and then we have an RTL SDR dongle which are really cheap, really easy to get hold of, well within the academic budget. Um

and then we've put that into GNU radio. So there's GR air modes. Um it's something that Nick Foster made. I think it's called Bistromath is his handle. Um which is a modes receiver but done in software defined radio. Um which is quite handy. that then decodes the ADSB messages and then sends it to a flight gear simulator essentially. So flight gear is an open source simulator that happens to have a uh TCAST receiver in it that is compliant with TCAS version two uh version TCAS 2 version 7.1 7.0 sorry um which is the last but one version of TCAS um which is quite handy for me when I'm trying to make it as close to reality as possible. So then we

have our um decoder packets. They go to flight gear and then they trigger something or they should trigger something. So I did this with a real aircraft. So this is listening above my house and this is um an easy jet flight that was flying over me at the time um that caused a TCAST alert to come up on my flight simulator. So from a flight simulator perspective, that's quite cool. But that's not really why we're here. We're here for more the infosc side of it. So we need to generate these messages somehow. So the question you're asking is what does an ADSB message look like? Um you start off with the what's called the DF bit or the down link field

and that's because ADSB is a subset of modes. So there's loads of different types of modes message um of different types and this bit tells it what type it is. Um for ADSB that's um ox17 um and that's ADSB messages. So all ADSB messages will have ox17 in here. Um then you don't need to worry about that. And then you have what's called the eau address. So I is the international civil aviation organization or authority. Um and they manage aviation across the world essentially. Um so every aircraft that gets built above a certain size gets given a unique identifier. Um so if any of you have been on ships, you have the um maritime number registration

number for your ship. Um and you have the eau address for your aircraft which is your unique ID. Um, obviously you want to transmit that with your ADSB messages so that you can tie up your aircraft, your ID and you don't get anything like that. Um, then the next 56 bits, so this is 24 bits by the way, so it's not a large amount of space. Um, 56 bits here are ADSB data of various forms. And then we have a really complex CRC 32 check sum at the end just to make sure everything is all right. So actually I did say there was no integrity. I lied slightly because there is a a CRC parity check, but I wouldn't

really call that proper integrity and it doesn't actually validate who you are, but it makes sure that it gets there in one piece. Okay, so there's three main types of message, so subsets within this ADSB data that we need to send. We essentially need to send our position, pretend to send our position, um our velocity, and we also send an identification packet. Um, and these are all identified by the register that they're stored in in memory um, in the ADSB receiver. Um, and that's called the BDS registers. So position messages are BDS05 messages. Um, so that's the sort of the way we determine where those messages go. Um, so BDS05 messages look like this. So we have our altitude um,

in those bits and then we have our latitude and longitude encoded in something called compact position reporting. Um, and that's a way of compressing the latitude and longitude into a very very small amount of space um, by using longitude zones. And you could do a whole hour presentation on just doing CPR longitude and latitude, but you probably want to kill yourself at the end. It's not very interesting. Um, the thing to take away though is that you do you get very very compressed, but you need two messages to narrow it down to which side of the earth you're on essentially. So if you have just one BDS05 message, you can tell whether you're in one of two places

on the Earth and then you use the second BDS05 message to narrow down to exactly where you are. Um, which is quite handy. So we have two of these messages that gives us our position. So our altitude, latitude and longitude. We then have something called an ident packet or identification which is BDS08. Um, and so the account address I mentioned before isn't really very human readable. Um, it's hexadimal numbers and letters basically. Um, so for air traffic control, they'd like to have a good human readable call sign that they can assign to it. Um, and that's what this packet gives you. So the first thing it has is the aircraft category. Um, that hasn't come out very well, has

it? Um, and that tells air traffic control what type of aircraft you are. So that could be anything from a light aircraft to a heavy aircraft. Um, you can be a parachutist in the spec apparently. Why a parachutist would carry an ADSB transmitter, I've got no idea, but you can do it in the spec. Um, and then the next all of the rest of the bits are the characters in the call sign. So earlier on we had that easy jet flight that was echo zulu yankee 61 golf romeo. So that's these eight characters here which your call sign. So when you look up look up what your flight tail number will be it'll be that call sign there not the account

address. So we've got our ident packet and we have our position packets and now we have our velocity. Um and this will take you back to GCSE maths. Essentially the velocity is given in east west velocity and north south velocity. So obviously to get your heading and your speed you just do trigonometry on those. So it's it's good oldfashioned maths. Um so then with all of that we have our velocity our position and our ident packets. And interesting thing to note actually about these velocity packets is you get to specify what your uncertainty is about your velocity. So obviously all of the fake after our craft we're creating are 100% certain about how fast they're going. They're not uncertain in

any way, shape or form. So obviously then the easiest way to make something trivial is to make a Python library for it. So uh I wrote up a Python library called lib ADSB that you give it some data and it gives you out a nice ADSP message here. So for this one the address is beef 11 because you can do that with hex why not um and but it makes it really really easy to generate lots and lots of different messages which is what we need to do later. So we have our messages generated now we need to transmit them. So I used a hack RF because that's what the university had lying around as you do.

Um we didn't have the budget for any of the um ETIS radios which ideally we' used but we had one of those. So and then using new radio you create blocks to your diagram. Um so this block diagram is lifted nearly exactly from some research done by the US Air Force over at AFIT. It's the Air Force Institute of Technology um in 2008. Um where they did some work on false traffic injection of ADSB. Um and essentially you have your binary message encoded in the form that you want to transmit it in. Um you unpack it and then you just transmit it. It's very very simple, very easy to do. However, um it turned out that it didn't actually

work. And quite why it didn't work. I I don't actually have any idea why it didn't work. So, this is the transmitting side. This is the pulses that I'm transmitting. And this is what came out on the other end on the receiver. So, as you can notice, they're not actually the same at all. Um and this didn't trigger GR air mode to do anything. Um so, that didn't work. And I spent a long long time trying to get it to work, but it didn't work. The interesting thing to note is I wasn't transmitting on 1090 MHz because obviously that's illegal. Um, I was transmitting on 433 MHz, which is the International Scientific and Medical band, um, which is free for anyone to

transmit on. So, I was doing at a lower frequency. And one of the possible reasons this didn't work is that there's a lot more noise on 433 MHz than there is at 1090 because hopefully hopefully there's only aircraft on 1090 MHz, whereas every man and his dog is transmitting on 433. Um, the other potential issue is because I wasn't at 1090 megahertz, my encoding of the actual message wouldn't possibly be right. Um, so the sample rates might be mismatched between the RTLSDR and the hack RF. Um, and then there's just the issue that the RTLR it cost 5 quid off eBay. I think it's not exactly high-end equipment. So it might be that it's just not doing the

precision I need. Um, so this could be fixed if I did actually transmit at 1090 MHz, but obviously I'd need a Faraday cage or something to do that in. However, there's a good reason why I didn't is that if you can't do something here, there's probably someone in China who's done it in legally dubious circumstances. Um, so there's this gentleman um over in China um who's done exactly what I was trying to do um but on 1090 MHz. So that's interesting. Um see if I can get that to play. So he's got his hack RF um wired up with his laptop. Um, he's transmitting the messages using the identical GNU radio blocks that I had.

Um, here's his software SDR, RTLSDR even. And then you can see the aircraft just at the bottom there going sideways in a square shape. And um, as someone who's done four years of fluid dynamics, that's not normally how aircraft fly. Um, I'm sure maybe you picked that up, but yeah. So, here's him moving his aircraft around quite happily. Um, and if there was another aircraft there, they probably got quite confused by this aircraft moving around in a a square pattern. But maybe they don't have laws against that in China. I don't know. Um but there so he's done it. So it's not that that can't be done. It's how that links to the rest of it. So that wasn't

really the important bit of the project because people have been injecting ADSB for quite some time. Um and if we could do that, we have a YouTube video of someone doing it. So we can we can show that that's an issue. So at this point it was time to simulate it all. So we just skipped ahead doing the RF bit and just cut that down to software. Um because that's what you do in academia, right? You simulate all. So at this point um glue radio has quite an interesting feature uh or GR air mode sorry has an interesting feature where you can specify multiple other radios and send messages into a central server over zero MQ sockets. Um so essentially

you could have a farm of distributed sensors and then bring in all of the ADSB data into one. But that also means it's quite useful for us because we can write a little Python script that injects messages into the message Q to be decoded. Um, so it quite happily bypasses all of the RF injection stuff and we get to go straight into here. Um, and that's probably a valid assumption to make because it's exactly the same message. It's just not getting transmitted over RF. So win for simulation there. So obviously if you want to be a hacker, you have to write something of green text because that's how it works. Um, so we had a a console

program or I wrote a console program um that allows you to specify all the different things. So the call sign you want, the latitude, longitude, speed, all this stuff. Um, and then obviously have help. Um, and then this generates it all in the background. It transmits it into the GR air modes thing and then it gets decoded. So this gives us a nice front-end interface that we can then type in change the last due to this and then we can mess around with putting aircraft in front of them and moving them dynamically which is quite useful. Did it work? Yeah, it worked in my simulator. So this is the aircraft UOB hack. Um, sitting there in front of

my aircraft in quite a threatening position. um injected into it and that is the TCAST display with a resolution advisory shown. So, at this point, TAS was saying climb, climb or end, I can't remember which. Um, and at that point in real life, if this all worked as expected, um, then the pilot would probably be having a small and pulling up. But if we can do one, we can do loads of aircraft, right? So, like I said, you because you can pretend to be an aircraft, there's nothing nothing stopping one aircraft pretending to be hundreds of aircraft in lots of different locations. Um, so I think this is 30 aircraft all clustered around. Um, and at this point, it's

quite interesting actually. My Tcast receiver didn't know what to do at that point if there's aircraft above and below it. So every half a second it would change between telling you to climb and descend. So you get climb, descend descend climb climb descend now, and all this sort of stuff going on. So if you were a pilot in that position, you'd probably know something wasn't right because you couldn't see all of those aircraft out the window. But by law, you'd be mandated to do something. what that thing was. I don't think anyone could probably guess and that'd be up to the lawyers to decide. Um, but it's not a great position to be in if you imagine you're on the approach

at Heathrow and that's what your display looks like. Okay, so now we pray to the demo gods and we see if it actually works on screen. So, we'll have a go at this.

So while that's starting up, we've got our this is our injection program. So our console um and then over here is our um GR air modes transmitter. So that's going to decode the messages. And then the multiplayer server for flight gear is running on this K Linux box as well. And then our front end whenever it loads decides to load um connects to that multiplayer server and then gets all the data out of that. But it's loading the scenery apparently which obviously something we're interested in. So that's going well.

Somewhere in the states

apparently for reference. This is not how I fly planes. It'll it'll sort itself out. up.

Up. I think the autopilot has an interesting opinion about where we're going.

Okay. So, eventually it's going to turn around back to the course I originally told to go on. Um, but we're just going to put this up here. So, over here in our um console program over here. So, if I go help, we get a list of commands which are very helpful um about all the different things we can set. Um, and then if I go shot options, we get a nice little picture of um all the different things that we can set for the different places. So, it's really small, is it? Um, so we're going to set the longitude to 2.9. And these are just some pre-worked out values that should possibly um put it in vaguely the right place to trigger

a um advisory. But it depends on where the aircraft decides to put itself.

Okay, so our Oh no, I

forgot. There we go. So over here in our Tcast receiver, we have the um it's for some reason it's not saying climb, but it's a pretty buggy simulator anyway. Um but there's our resolution advisory showing up on the screen. So, um, because I can just arbitrarily do whatever I want to it, I'm going to move that back. So, we're going to set the longitude to minus 3.1. And over here, you should be able to see the it magically disappeared. And now it reappeared again because it's just further away in front. Um, and like I said, obviously, if we can do one, we can do multiple of them. So, we're going to set the path to swarm, which is

randomly generated something around a point. Um, let's put 10 aircraft in. So let's see if we can do this at the same time for maximum effect. So there's our one aircraft and now that's become 10 aircraft with all with traffic advisories. Um and then like I said it's if if it's within 40 seconds you get a TA and then those will slowly turn into red dots. There we go. So now there's a small swarm of unidentified aircraft coming straight towards you or causing resolution advisories which isn't a great position for a pilot to be in. So amazingly that worked right. Okay. So that's that's the demo of that side. So obviously as inf professionals we do all this sort of

attacking stuff and we demonstrate the exploits but ideally we'd like to have some defenses against that particular stuff as well. Um so the second half of my project once got all of that done was trying to implement some defenses to stop people being able to arbitrarily inject like packets um into ADSB. So trying to put the confidentiality, integrity and sort of encryption on it that you'd expect to see in most safety critical systems ideally. It is an interesting trope as an aside that the systems that we rely on for the be the most secure and the most safety critical ironically have the least security. If you look at your iPhone for instance and the security on

that compared to the security on most scarda systems and on this it I don't understand who decided to put the money in which particular location there but that's another issue entirely. So um the first thing we try to look at is symmetric encryption. So if both parties have a secret key and they share the secret key and then encrypt their data with that and decrypt it at the other end. Um ideally no one should be able to decrypt that traffic to work out where the aircraft is. Um or make false traffic by injecting data. Um so we tried we used or I used um AES and Blowfish and tried all those different combinations out. Um but there's some

problems because it's a really really small amount of space. It's smaller than the block size for most block ciphers. So you end up having to use a stream cipher which isn't ideal. Um but you can use a a deterministic nons or initialization vector. So that's not really an issue. Um, interestingly, um, about five years, six years ago, um, someone wrote a military paper about using this sort of symmetric encryption for a military ADSB system. Um, where you have symmetric encryption on it, um, and then you detect whether the pl the plain text is meaningful because obviously if you don't have the secret encryption key, you can still make a message and it will get decrypted, but

it will be garbage. So the question is, can you work out if that's garbage or is your ADSB receiver just going to go, "Yep, there's an aircraft there." and just blindly accept it. Um so at this point you have to put some sort of huristics in to try and work out does that make any sense? Is that meaningful plain text and then do something based on that. Um whether the actual military system works like that I don't know because they don't publish it. But uh that's an interesting idea put forward to sort of provide some authentication via just a single secret key and stream ciphers. Um so an interesting question for us as um aviation people is does

that slow it down? So if you put encryption on it, it's going to slow down, but by how much? Um, so compared to the solid lines are um just normal ADSB and then the dotted lines on the top are encrypted with AS CFB. Um, there actually wasn't that much of an increase in time. So it's aboutund 150 120% extra time um over just normal plane ADSB. Um, and the reason that matters, if I put that in context, is if you're an airliner traveling at sort of 900 km an hour, if you have a delay of 1 second, that equals 265 m that you've closed between your target. So, if your thing takes 1 second longer to decode

something, that means that you're a quarter of a kilometer closer to hitting the other plane, which isn't great. So obviously there's some issues with that in that um if one person finds out the key that you don't want to find out the key, you then have to change the encryption key on every single aircraft in the world um which is a lot of aircraft. So Airbus has 15,000 372 aircraft on order alone at the moment. So if you then had to change all of that aircraft, all the keys on the aircraft that you haven't built yet because someone found out the key or probably someone at this conference found out this the one secret key to your device

and that's not going to work. In the military it sort of works because you've got a smaller number of aircraft. You can just go on and plug a USB stick into each one and do that. But that doesn't really it's not really distributed enough for a civil aviation solution. Um the rest of the solutions I used um because of the we have um this really really small amount of data there's no extra room to put stuff on. It's not like you can suddenly add another 128 bytes on the end. There's just nowhere for it to go. So you have to have a second channel to put data inside. So luckily there's a sort of workaround for

that in that um like I said at ADSB is type 17. Um there are type 24 type 24 messages um that are defined where you put 24 at the beginning and then you can have 80 bits of arbitrary data and then you can like smush eight of those together to get 1,620 bits I think um of data in a block. So you transmit eight of these messages in a block and you get that large amount of data out at the end. Um so I define a sort of custom protocol based on that where you tie it in with the eau address of the aircraft you're transmitting. you have your data block of generic data, whatever it might

be. Um, and then at the end, rather than doing a parity check of this data, um, you put the CRC of the message that you're referring to. So, say you want to sign another ADSB message, you take the CRC of that message and put it at the end. And then you can reference all of this to that one particular message. So, there's two schemes that I developed to use this. Um, the first of these is an authenticated encryption and decryption. So, like I said with symmetric, you don't get authentication automatically. you have to sort of put the um heristics on top of it to make sure that that works. Um but if you use an AAD scheme

then you get authentication. So you can tell using this tag whether the person actually had the right key to make the message. Um so essentially you have your ADSB message at the top and you put it into the encrypter with your secret key which is symmetric again unfortunately. Um and a nons value um and out of that you get an encrypted ADSV message. So that's stream ciphered encrypted um and an authentication tag which is essentially an MD5 hash of that sort of length. Um and then you can split that between three type 24 messages and then transmit those. So you get one of ADSB message and then three other messages for each one. Then at the other end you

receive all of those and you put them into a message queue and once all four of those messages are received you can then put them into a decoder with the secret key and the deterministic nons that you can work out and then you get a decrypted validated ADSB message. So win. However, it's still symmetric. So you need the key on both sides. The other disadvantage is for every one ADSB message, you need three type 24 messages to make that work. Now remember when I said the smallest number of messages you could have was two BDS05, one ident packet, and one velocity packet. That means you need 12 messages then just to transmit those four messages. So you're

reducing the bandwidth of the ADSB system by 75% pretty much. And at the moment, ADSB is operating at nearly max capacity around Heathrow and places like Los Angeles. So reducing it by 75%. If you turn around to Heathrow and said, "Sorry, um you can have security um but you'll have to fly a quarter of the aircraft that you're flying at the moment, they're probably not going to take you up on that." So that's a massive downside for this. Um, an alternative to that is, um, if you just use the hash message authentication code, so like an MD5, HMAC, um, you'd get the three type 24 messages, um, but you wouldn't get the encryption. And that's a plus and a negative. So the

plus is that you wouldn't have to change any of the ADSB hardware. So that would be an enormous cost reduction because you're just sending ADSB messages, but the downside is you wouldn't get the encryption. So you still have the surveillance risk even though you validated all of those original messages. Um, so there's ups and downs for all that different stuff. The second side of it is I look at some research done by some guys on vehicle automotives. So putting um authorization and signing on the canvas um and they used um um elliptic curve cryptography to do signatures because they're very very small signatures essentially get out at the end. Um so I use this NIST um

192P curve and again so the idea is you have your set of four messages that you need to send. That's your block of state data basically. um you take all of the data from that and then you then sign it with an aircraft private key that you sort of burn into the firmware of the receiver. Then you get a 384-bit signature. Now in the grand scheme of computing that's tiny, right? So that's nothing. You could send that over thing. However, in this protocol you need seven type 24 messages to send that 384 bit signature. Um so you can see at the moment working with these sort of legacy protocols is sort of um very tiresome

when you're like how do I fit all of this into the smallest amount of p space possible because there's nowhere left for it to grow. So at the other end you get your four ADSB messages and your seven type 24 messages. Um and then you look up in a public key database what the aircraft public key that it's saying it is via the eau address. Um and then you get the payloads and you reconstruct the signature by putting all type 24 messages together. Um and then you can put it into a verifier with a public key and say yes those five messages or four messages rather were sent by the aircraft with that public key. So then

you've validated that set of messages. So that works in that sense. So the advantage of that is you have validation and it's scalable. So you can have a database somewhere of private and public keys um and then you can validate that all the aircraft are there. However on the downside um you need a database of aircraft public and private keys um and you need to protect that. So that becomes a more infosc problem and then you have all sorts of issues about revocation. What happens if someone like um pretends or steals an aircraft private key? Can you revoke that across all of the databases in the world and that sort of fun stuff. Um but another

upside is you could just have this whole side um as a separate box basically rather than doing anything to the ADB receiver. So you have a crypto bolt-on basically that signs everything and transmits it. So again, there's ups and downs to all the different sides of it, but it's it's managing that risk and doing that. An improvement over the symmetric authentication as well is that what it's only seven messages for every four messages. So it's not a 75% reduction, it's a 58% reduction. Um, but still, if you said to Heathrow, sorry, you I know we said a quarter last time, you can fly 50% of your aircraft, that's better. They're still that's still not going to cut it really. So you need to

find some sort of outofband channel to send that information down. So, some other defenses that I didn't really do, but you could do um is you could do more sort of what active tcast does, but better because that's still pretty awful. Um you can do distance bounding protocols where you send a message and then see what the delay is between the two um to work out the range and that gives you sort of a circle of range within which the aircraft could be and then use that to validate whether the ADSP data is right. Um some University of Cambridge guys did some work um on this for ARID. So we all do um long range offid attacks and that

sort of stuff. So sniffing badges or replaying it over a long distance. So using distance pounding, you could work out whether that badge is actually anywhere near the reader and whether it should talk to it or not, which is quite interesting. Um but it does need a completely new radio and a completely new transmission system and all of this inordinate amounts of money. Um another small change that you could do is a policy change. So at the moment the FAA's response to ADSB injection is it's fine. We we accept that because the ground station, we have lots of ground stations. So, we can triangulate where the transmitter is and say that it's not where it says it is. And you're sitting

there going, "Okay, so that's fine." So, the air traffic control can tell where the aircraft is. But the aircraft in the air has one antenna, so it can't tell whether that aircraft is where it says it is. It just knows that something's talking to it. Um, and maybe if you had a directional antenna, you could tell where the bearing is, but still, if you have the bearing, it doesn't matter where along you are, you could be right up in front of it. Um, so that's not really a great defense. So making just a simple policy change to the way TCAST works is you could say um air traffic control has a special code word or

something that if they say this code word then the resolution advisory doesn't apply anymore. It's false. We know it's false and we'll tell you that because at the moment there's no way for air traffic control to tell them that that RA is malicious because of the way the RA system is set up. However, and we have another downside here. Um, as soon as you start telling pilots that they can ignore resolution advisories, more pilots ignore resolution advisories and crash into other planes. Um, so there is an enormous amount at the moment, you do a lot of research about pilots who, in fact, if you watch air crash investigation, most of the time it's the pilot has ignored the bleeping bit of

hardware that says there's an aircraft coming and just goes, "No, that must be wrong." And just plows straight on into it. I mean, go go go away and look it up. Go away and look at aircraft investigation. Most of the accidents will be the pilot plowing it into something rather than the computer doing something wrong. So again, when you tell pilots, "Oh, it's fine. You can just ignore resolution advisories," you open up a whole new can of worms and pilot training. Um, which isn't necessarily where you want to go. But if it's the only thing that stops people injecting stuff, then you might want to do that. So, as with all research, there are some caveats and there's some places

you go further with and some future work. Um, so the first caveat is this isn't actually a real aircraft because our budget didn't stretch to getting a real aircraft. Um, this is just a simulator and I've done what I've done in the simulator. So any extrapolation of that to an actual aircraft, you have to take it with a pinch of salt because it's not an actual aircraft. It's software running on my laptop. Um, so the exact ADSB in interface with TAS might not do a resolution advisory. It might just display it as traffic without having an aircraft, you can't really tell, which unfortunate. However, and I have some caveats to my caveats, um, active TCAST doesn't have any security

either. There's no encryption or authentication on that. And that's a whole new category that you can play around with injecting into. If you've clouded a TCAST display with non-threatening traffic, you're still increasing the pilot workload. And the pilot has to do a lot of things on an airliner as his normal job. So if you distract him away from that, you raise the risk of there being an instant. And in the aviation in industry, we're not very risk tolerant. We don't like risks because a risk means that your multi-million pound aircraft with hundreds of people on board could go plowing into a mountain and that's not a great thing. So if even if the likelihood of it is small, it's still a

fairly major risk overall. And the next point that I want to bring on to is there have been people saying, "Oh, you can't do it. TAS doesn't work that way." But in the future, they're bringing something called AAS X, which is the automated collision avoidance system X because the FAA is like that, aren't they? Um, and this is part of that whole nextg, next generation. So the improvement on this system where my attack might not work is that my attack is guaranteed to work because the only input to the system for this particular branch of AAS will be ADSB. So this is a new system where you take just ADSB data and you bring it in

and then you do collision avoidance based purely on that. That is the reaction I had. But yeah, so if you want to go and read up on that um you can copy that later or I'll try and tweet and put this um presentations out. They're bringing in this new nextgen system and they want all of this stuff with no security, no authentication, nothing on it. So, in conclusion, ADSP is flawed. It's legacy. Um, it was legacy when it was invented in 2008 because it had nothing and now it's next generation. Apparently, anyone can listen into traffic. So, there's that whole can of worms that we haven't opened. Ground stations can filter out ghost aircraft, but the aircraft themselves, which are,

remember, the important bit in this equation, can't do any of that. Anyone can pretend to be in a collision and the aircraft itself will believe them regardless of what air traffic control says. So you have mitigations but they either reduce the bandwidth or they have other knock-on effects or there's a whole other can of worms associated with them. So really you need this it's the truism of information security. You need to combine technical and a policy situation. So you need to get the managers and the FBA to sit down with the techy people and go right let's hash out a way of dealing with this so that we don't make this mistake in the future

when we go to things like AAS X and all this sort of fun stuff. So, I'd like to leave you on one final note. Um, this is a laptop on eBay. You can buy a laptop really, really cheaply. Everyone knows how cheap laptops are. Hack RFS. They're around $300 at the moment. So, if you make a conservative estimate, that's about $31 um to cause massive disruption and flight safety risk at Heathrow or JFK or any of these places. Um, and that's with zero attribution as well. So, there's no one can work out where you are. You could put a Raspberry Pi with a hack RF and dump it next to an airport and cause a huge amount of damage.

On the eve of the attacks in America, al-Qaeda was running a $30 million annual budget according to the CIA. So when you sit and imagine how many of these systems they can put together, it doesn't take a large amount of like imagination to see where that could go. Thank you very much. That's been my talk. If there are any questions, I'll be happy to take them. [Applause]