[00:05.250 --> 00:10.320] Hello, and welcome to my Aerospace Village talk on wireless privacy issues in aviation. [00:10.320 --> 00:14.540] I really, really appreciate the opportunity to share our research in this area, [00:14.540 --> 00:20.220] even under these fairly unusual circumstances. And I also want to take the time to commend the [00:20.220 --> 00:24.660] organization around the village, which is a great initiative that brings together so many [00:24.660 --> 00:30.320] stakeholders in order to tackle security issues in aviation. If you don't know me, [00:30.320 --> 00:35.440] my name is Martin Strohmeyer. I am working at the Cyber Defense Campus of Armistice Science [00:35.440 --> 00:41.600] and Technology in Switzerland. And I'm also a junior research fellow at the University of Oxford. [00:42.700 --> 00:47.900] So, let's dive in. When we speak about wireless privacy, what do we mean? [00:48.020 --> 00:53.820] The heart of the issue is that we cannot normally prevent access to wireless signals that are being [00:53.820 --> 01:00.120] sent. On a wire channel, if we physically control all of the lines and nodes, the number of possible [01:00.120 --> 01:06.620] adversaries is normally limited. In contrast, the wireless channel is inherently broadcast, [01:06.620 --> 01:12.460] as you can see here. It is typically omnidirectional and there are no physical containment [01:12.460 --> 01:19.020] measures possible. So, sending or receiving messages does not require you to physically tap [01:19.020 --> 01:25.720] into the network infrastructure. Based on this inherent broadcast property, I want to concentrate [01:25.720 --> 01:32.760] on two attack primitives today. The first one is eavesdropping. So, a breach of the confidentiality [01:32.760 --> 01:38.960] of the transmitted data. This is a well-established concept, of course, and can fundamentally be [01:38.960 --> 01:44.640] prevented through the use of encryption. Our phones, laptops do this fairly securely [01:45.560 --> 01:50.220] and hassle-free these days, despite the occasional breakdown. [01:51.580 --> 01:57.560] The second one is location privacy. Often, we do not want to prevent the content of the [01:57.560 --> 02:04.420] communication data being exposed, but also the position of the participants. This gains additional [02:04.420 --> 02:11.060] importance in wireless networks. Users are often mobile and we can track their movements over time [02:11.060 --> 02:17.660] simply by estimating where the signals come from. Such tracking has many positive use cases. [02:17.660 --> 02:23.080] For example, if you're in a museum, standing in front of a painting and a system can deliver [02:23.080 --> 02:30.080] matching information to you. However, tracking also facilitates many high-profile privacy breaches. [02:31.580 --> 02:38.380] So, let's apply these concepts to aviation. Here, we have to understand first that the [02:38.380 --> 02:43.440] threat model of aviation has changed drastically over the past decade or so. [02:44.000 --> 02:49.440] First, aviation is moving away from analog technologies, such as voice or radar, [02:49.440 --> 02:53.840] and increasingly using digital communication networks and automation. [02:54.380 --> 03:01.040] The second aspect is just as important, which is the widespread availability of cheap, [03:01.040 --> 03:07.360] hard, and software, as well as knowledge about aviation protocols. These two developments [03:07.360 --> 03:12.400] combined lead to the fact that many more people are capable of affecting wireless [03:12.920 --> 03:18.900] air traffic communication systems than before, and practically anyone can listen to wireless [03:19.600 --> 03:27.220] aviation communications these days. In short, the threat model has moved from a purely nation-state [03:27.220 --> 03:33.220] actor model to a whole range of groups with different capabilities and motivations. [03:33.830 --> 03:39.210] In today's talk, it is actually sufficient to focus on the purely passive eavesdroppers, [03:39.700 --> 03:45.500] as observing the communication is entirely sufficient to exploit many of the privacy [03:45.500 --> 03:51.220] issues in aviation. Now, let's look at some real-world examples of confidentiality and [03:51.220 --> 03:55.920] location privacy issues in different aviation protocols, which were collected from our own [03:55.920 --> 04:02.060] research over the years. First, we will talk about the data link ACARS, which has been deployed for [04:02.060 --> 04:09.900] decades and is still in use by most larger aircraft around the world. Let me just say at [04:09.900 --> 04:15.620] this point that all of these examples now are, of course, anonymized. Still, you can intuitively see [04:15.620 --> 04:22.380] that this is not good. A lot of very critical data is absolutely sent in the clear, and neither Sally [04:22.380 --> 04:28.100] here nor Tom would be happy if they knew that their medical information is being broadcast, [04:28.100 --> 04:34.320] not only to ground staff, but also to anyone listening in the 300-mile radius of the aircraft. [04:35.600 --> 04:40.700] Further privacy issues in this area include information about personal belongings by crew [04:40.700 --> 04:46.940] that you could just go and collect, and, of course, our favorite example that often serves [04:46.940 --> 04:52.780] to drive the point home, full credit card data for higher value transactions in onboard duty-free [04:52.780 --> 04:59.960] shopping. This credit card thing is indeed still ongoing with some airlines in 2020, despite [04:59.960 --> 05:06.960] notifications provided years ago. Some people in the industry have actually acknowledged that [05:06.960 --> 05:13.340] there's an issue with this, and they came up with what you can see here. If you're watching this [05:13.340 --> 05:18.560] recording, you can maybe take an extended look at these messages and figure out quickly what is wrong [05:18.560 --> 05:26.340] here before I spoil it. But for now, let me tell you. As you may have guessed, this type of ACARS [05:26.340 --> 05:32.720] data link encryption is using a monoalphabetic substitution cipher that is broken in minutes. [05:32.820 --> 05:38.960] It is used by a wide range of private, military, and even government aircraft, and again, this has [05:38.960 --> 05:46.720] been going on for more than a decade now. Still, this data link issue, we could say it is fairly [05:46.720 --> 05:52.020] straightforward, and this could still be solved with better crypto solutions that are standardized [05:52.020 --> 05:59.320] and verified. Honestly, some of them even exist in aviation, but operators of aircraft and airlines [05:59.840 --> 06:07.800] still believe they're too expensive. As a last point on this issue, if you believe that using [06:07.800 --> 06:12.560] satellite communication for your data link will avoid any of these issues with software-defined [06:12.560 --> 06:19.260] radios, then think again. This here is an example of military aircraft using ACARS, which sent out [06:19.260 --> 06:24.820] detailed flight information in advance and regular updates about its movements, which can easily be [06:24.820 --> 06:34.010] received by any third party. This is also a good time to transition to a second topic, location [06:34.010 --> 06:40.770] privacy. We know that everybody is being tracked on the ground using your mobile phone. However, [06:40.770 --> 06:45.630] in the air it is a bit different. With aircraft broadcasting their position to other aircraft [06:45.630 --> 06:50.770] and air traffic control to safeguard themselves and the whole airspace, the communication [06:51.790 --> 06:56.790] is not supposed to be encrypted and anyone can listen to the same information. [06:56.990 --> 07:04.190] So tracking aircraft globally with ease is absolutely a thing. Here we can see that even [07:04.190 --> 07:13.570] the US president is being tracked, in this case during the campaign of the 2016 election. [07:13.810 --> 07:21.430] So let's take a closer look at this problem. First, we need to talk about metadata. Maybe you're [07:21.430 --> 07:26.690] familiar with the MAC address of your network phones and laptops. Well, basically the same thing [07:26.690 --> 07:32.930] exists for aircraft. It is a unique 24-bit identifier which is hard-coded into the transponder [07:32.930 --> 07:40.250] of any aircraft and provided by the International Civil Aviation Organization. This idea is [07:40.250 --> 07:45.790] practically never changed unless the aircraft is sold, making it perfect for any sustained [07:45.790 --> 07:52.050] tracking purposes. To make the connection between this identifier and the owner or operator, [07:52.050 --> 07:57.870] you can employ all sorts of different databases and websites available publicly on the internet, [07:57.870 --> 08:01.670] which is something that we did and you can see here. [08:04.830 --> 08:09.990] So this is a visual representation of all non-European government aircraft visiting [08:09.990 --> 08:15.530] Europe over a single year. You can clearly identify some hotspots, [08:15.530 --> 08:20.750] unsurprisingly in London or Paris, but also in Switzerland or Nice. [08:26.230 --> 08:31.410] From this, we were also able to identify dozens of high-profile multilateral meetings [08:31.410 --> 08:39.130] with five or more attendees during the considered time period. From the World Economic Forum to NATO [08:39.130 --> 08:45.810] summits. This is, for example, Davos, I think one or two years ago, and you can clearly see [08:45.810 --> 08:50.490] all of the different government aircraft landing at Zurich airport. [08:53.360 --> 08:59.800] One striking example of the impact of these issues for governments is provided by two [08:59.800 --> 09:05.080] investigative journalists who have set up a Twitter bot that is connected to a receiver based [09:05.080 --> 09:11.460] at Geneva airport. It tweets out arrivals and departures by a set of aircraft used by authoritarian [09:11.460 --> 09:17.920] governments, and it is known that this is tracked by several organizations watching corruption on [09:17.920 --> 09:23.340] the world. And the public awareness has created formal investigations such as this one, [09:23.340 --> 09:27.690] where the vice president of Equatorial Guinea had some of their assets seized. [09:30.810 --> 09:35.650] However, the lack of privacy actually extends much beyond governments and also affects corporate [09:35.650 --> 09:40.770] activities as well. We took a look at the activities of different corporations in Europe [09:40.770 --> 09:45.730] during a single year by tracking the movements of corporate aircraft and relating them to stock [09:45.730 --> 09:54.430] market moving merchant acquisition activities. And indeed, in six out of the seven cases that we [09:54.430 --> 09:58.970] examined, we could find a decent to really, really good signal with landings in the immediate [09:58.970 --> 10:05.310] surroundings of the target. In five cases, these visits came up to 25 days before, and three even [10:05.310 --> 10:10.870] within a week, with many of these cases exercising significant share price changes on the day of the [10:10.870 --> 10:17.650] announcement. Let's look at one case for illustration. Here we can see the flights of a large [10:17.650 --> 10:22.710] American medical company to the city of Basel in Switzerland, where the headquarter of the takeover [10:22.710 --> 10:29.330] target actually was. This is a zoomed in version of the same image showing the actual dates and [10:29.330 --> 10:35.810] times of the landings at the airport. Indeed, we can see several flights around the end of January, [10:35.810 --> 10:39.430] just before the acquisition was announced, as you can see in this. [10:40.270 --> 10:47.330] We can even go further and look at some later visits to Basel, highlighted here, [10:47.330 --> 10:52.570] which came a day before the acquisition was completed. This illustrates just how much we [10:52.570 --> 10:56.310] can learn about the activities of public corporations through watching their flight [10:56.310 --> 11:03.690] movements. By last year, this was also picked up in the mainstream media, as you can see here, [11:03.690 --> 11:10.930] for example, in this Bloomberg article. So, is there anything that can be done about this? [11:10.930 --> 11:15.350] Surely many people are aware of these tracking issues by now and want to prevent them where [11:15.350 --> 11:21.970] possible. Why are we in this situation in the first place anyway? Well, first I want to spell [11:21.970 --> 11:27.590] out clearly why we don't have any proper security and privacy by design in these technologies. [11:28.350 --> 11:34.270] A good case study is the novel ADS-B protocol, which has only been made mandatory in some [11:34.270 --> 11:40.090] advanced countries just this year, but was actually conceived in the mid-1990s with a [11:40.090 --> 11:46.770] much, much different threat model as discussed before. Why it takes this long is due to a host [11:46.770 --> 11:53.030] of reasons, including strict certification and testing requirements, and a wish for maximum [11:53.030 --> 12:01.310] interoperability across the globe. If we look a bit closer, things get even worse, as ADS-B is [12:01.310 --> 12:07.290] built on hard and software standards developed by Lincoln Labs in the 1970s. Now it should be [12:07.290 --> 12:13.830] very obvious that wireless security has moved much faster outside aviation than inside during this [12:13.830 --> 12:23.190] time. But if we cannot have privacy by design, what is being done? The first and most notable [12:23.190 --> 12:28.630] mitigation is to hide sensitive aircraft from public websites through block lists maintained [12:28.630 --> 12:35.190] by flight authorities. The aircraft are either entirely hidden or they are anonymized as shown [12:35.190 --> 12:41.130] here. Of course, this approach is entirely useless from a security researcher's point of view, [12:41.130 --> 12:47.350] as the data is still all available. It is simply not displayed anymore. So while this [12:47.350 --> 12:53.370] certainly qualifies as security theater, it at least shows that some people do care about their privacy. [12:54.890 --> 13:00.870] The second mitigation approach would be to obscure the ownership within all of the publicly [13:00.870 --> 13:08.070] available records. Private aircraft are often registered via shell companies or bank trusts, [13:08.070 --> 13:12.690] sometimes the whole network of them, which makes it difficult to get all of the information [13:14.390 --> 13:20.070] that you need from the metadata. However, one single slip of the operational security [13:20.630 --> 13:26.690] and the information is out forever, or at least until you buy a new aircraft, which honestly even [13:26.690 --> 13:32.050] the richest of the rich do not do every other week. We can find the data on social media [13:32.050 --> 13:38.950] or dozens of dedicated plane spotting websites, which with a really large community of physical [13:38.950 --> 13:45.670] spotters is super quick and reliable. Of course, when your aircraft's delivery contain your company [13:45.670 --> 13:49.970] logo, there's certainly the question why you're trying to hide your ownership through a shell [13:49.970 --> 13:55.850] company in the first place. If you see your aircraft land at any given airport, we will [13:55.850 --> 14:02.990] immediately know who you are. A third interesting observation is that some military and government [14:02.990 --> 14:10.890] aircraft are clearly aware of the privacy issue of their broadcast and switch them off for takeoff [14:10.890 --> 14:18.410] and landings in order to conceal the origin and the destinations. Unfortunately, this also does [14:18.410 --> 14:24.150] not help against any reasonable competent observer, because the aircraft are still required [14:24.150 --> 14:31.210] to send out their identity and their altitude, which in the end makes it fairly easy to localize [14:31.210 --> 14:36.970] them, for example, using multi-iteration or any really dense sensor network. [14:38.370 --> 14:45.530] That leaves us with one last option. You could simply not use your own private aircraft, but [14:45.530 --> 14:51.550] instead rely on commercial air transport options. Heads of government have been known to fly coach [14:51.550 --> 14:57.290] from time to time, but whatever their motives were, it can certainly not have been for privacy reasons, [14:57.290 --> 15:03.410] as we can see in this excellent example of the then British Prime Minister David Cameron [15:03.410 --> 15:10.090] eating Pringles on an easy jet. This was broadcast all over the internet before he had even landed. [15:12.130 --> 15:19.030] Finally, I want to address a real and effective fix. You could randomize the transponder ID of [15:19.030 --> 15:25.390] sensitive aircraft for each flight, which would stop the trivial tracking of the anonymized [15:25.390 --> 15:32.870] aircraft at least. This one is more or less straightforward in theory. However, the problem [15:32.870 --> 15:39.310] again is in the legacy system and the global compatibility. Oh, and the fact that the flight [15:39.310 --> 15:47.190] authority's security knowledge isn't necessarily the greatest. There was a first deployed attempt [15:47.190 --> 15:54.170] of this about 10 years ago, where researchers were still easily able to correlate the random [15:54.170 --> 16:02.470] identities with the original identity, making the whole thing absolutely useless. To top it off, [16:02.470 --> 16:08.750] the FAA did recommend against using it at the time because of pretty strong safety considerations. [16:09.450 --> 16:17.010] And I think if your regulator recommends against using a system for safety reasons, [16:17.010 --> 16:23.570] that would probably make most people think twice. However, there might be light at the end of the [16:23.570 --> 16:28.810] tunnel because there's a brand new attempt at dealing with aircraft tracking by the FAA, [16:28.810 --> 16:37.010] the so-called privacy ICAO address program. It addresses a few of the issues that we've seen [16:37.010 --> 16:42.810] here, but the jury is still out on the effectiveness of this one. We've actually [16:42.810 --> 16:48.690] now done a preliminary analysis, which I'm not going to spoil here. If you're interested, [16:48.690 --> 16:53.150] watch the dedicated talk by Guillaume Michel here in the aerospace village. [16:53.370 --> 17:00.290] So let me finish my talk with two takeaway lessons. These two lessons are especially for [17:00.290 --> 17:06.210] the aviation community and they're direct results on our research. The first one will not come as [17:06.210 --> 17:13.290] news to any longtime DEF CON attendee, but please do not roll your own crypto. Trying to do that [17:13.290 --> 17:19.410] has resulted in spectacular fails across many industries and aviation is certainly no exception. [17:19.610 --> 17:25.150] The best example is the ACARS disaster, which released recent aircraft with weak proprietary [17:25.150 --> 17:31.290] ciphers and leaking their sensitive data, even though they're actively trying to avoid it. [17:31.290 --> 17:39.170] Get some help, use known secure standards, and then actually also use these systems, [17:39.170 --> 17:44.290] unlike ACARS message security, which has seen virtually no uptake in the wild. [17:45.550 --> 17:51.390] The second lesson is where I really, really hope the aerospace village will help to make [17:51.390 --> 17:56.350] some improvements by bringing together security researchers and aviation stakeholders. [17:56.950 --> 18:03.350] But please, if somebody responsibly discusses security issues in your systems with you, [18:03.350 --> 18:09.610] do not shoot them down by replying that there's nothing to see, like in this nice example. [18:10.850 --> 18:17.210] After contacting the manufacturer, we only received the reply that the malfunction in crypto was not [18:17.210 --> 18:23.130] there to protect anything in the first place and that industry standards or regulations do not [18:23.130 --> 18:31.030] require them to build anything better at all. Indeed, they even went as far as to say that all [18:31.030 --> 18:37.650] of their users are security experts and would know that their crypto system does not protect anything, [18:37.650 --> 18:42.650] which I have a hard time believing, to be honest. In particular, when I take a look [18:42.650 --> 18:47.090] at the software option saying encrypt downlink as seen in this screenshot. [18:50.000 --> 18:58.120] So, to conclude. First of all, we can say that modern software-defined radio technologies have [18:58.120 --> 19:02.680] certainly changed the threat model for wireless aviation networks fundamentally. [19:04.860 --> 19:08.480] The integration of privacy by design, on the other hand, [19:08.480 --> 19:15.400] into legacy aviation systems after this technology step change is super hard. [19:17.080 --> 19:22.120] Combined together, this means that it's trivially possible to track the movements [19:22.120 --> 19:27.580] and the communications of many aircraft, both globally and in real time. [19:28.220 --> 19:32.960] And most concerningly, all of the currently available mitigation options [19:33.780 --> 19:41.960] are absolutely insufficient and more work is needed to find any real fix in this direction. [19:44.280 --> 19:48.380] If you're really interested in our privacy research, you can also check out all of the [19:48.380 --> 19:54.340] references for our talk on this slide, or you can shoot me some questions in Discord later. [19:54.760 --> 19:59.540] Thanks a lot for listening, and I'm really happy to be part of the Aviation Village this weekend.