1 00:00:00,000 --> 00:00:16,720 *RC3 preroll music* 2 00:00:16,720 --> 00:00:19,670 Jiska: Hello, everyone, and welcome to my talk, which is about Bluetooth exposure 3 00:00:19,670 --> 00:00:25,470 notification security. This talk could also be summarized as follows: So first of 4 00:00:25,470 --> 00:00:30,720 all, exposure notifications as in the Google/Apple API are very secure and 5 00:00:30,720 --> 00:00:36,190 battery friendly. And please, just use the Corona Warn App. This might be very 6 00:00:36,190 --> 00:00:39,420 confusing to most of you, who are listening and know me since a while 7 00:00:39,420 --> 00:00:43,710 because I have been working on Bluetooth exploitation in the past and always 8 00:00:43,710 --> 00:00:47,710 thought everyone, like, Bluetooth is insecure. So you might wonder: How does 9 00:00:47,710 --> 00:00:53,127 this align? Why am I now here telling you that Bluetooth exposure notifications are 10 00:00:53,127 --> 00:00:59,860 secure? So well it's a pandemic, so instead of just criticizing solutions, we 11 00:00:59,860 --> 00:01:06,170 should also look for solutions that work. So instead of ranting, work on something 12 00:01:06,170 --> 00:01:14,790 that helps everyone! So the first question that many people asks are, do we even need 13 00:01:14,790 --> 00:01:21,750 a smartphone app to fight a pandemic? What we can say, well, it's December exposure 14 00:01:21,750 --> 00:01:26,063 notifications were introduced in June and we still have Corona, it still exists. So 15 00:01:26,063 --> 00:01:35,379 it didn't help to fully fight them and probably it won't stop Corona. But let's 16 00:01:35,379 --> 00:01:41,340 look at this from another perspective. So first of all, if you have an app and get 17 00:01:41,340 --> 00:01:45,859 the warnings, we can do more accurate testing and that's very important because 18 00:01:45,859 --> 00:01:50,820 even now we are still low on tests. We cannot test everyone. We only test people 19 00:01:50,820 --> 00:01:56,840 with symptoms. And that's really an issue because people can, infect other people 20 00:01:56,840 --> 00:02:01,789 prior to symptoms and they could even infect others without having symptoms or 21 00:02:01,789 --> 00:02:07,569 they're asymptomatic cases. And these can be found with the Corona Warn App. And 22 00:02:07,569 --> 00:02:11,470 also this can encourage manual contact tracing because official health 23 00:02:11,470 --> 00:02:17,310 authorities, they are not able to make physical, manual contact tracing any more. 24 00:02:17,310 --> 00:02:22,860 So you need to ask your friends and so on if your app turns red, and then you might 25 00:02:22,860 --> 00:02:28,280 find cases, even if they forgot to tell you. Of course, this all doesn't replace 26 00:02:28,280 --> 00:02:33,790 washing your hands, wearing a mask, physically distancing and so on. So, of 27 00:02:33,790 --> 00:02:39,970 course, you still need to take these measures. But even if you just inform a 28 00:02:39,970 --> 00:02:44,739 few people, every prevented infection actually saves lives. So it's very 29 00:02:44,739 --> 00:02:53,070 important to have an app like this. And the next question is, well, is there 30 00:02:53,070 --> 00:02:57,110 something better than Bluetooth? So if we want to look for a solution to build an 31 00:02:57,110 --> 00:03:03,410 app that supports exposure notifications and prevent infections, how could we build 32 00:03:03,410 --> 00:03:09,730 it? So we actually need something that somehow measures proximity or location and 33 00:03:09,730 --> 00:03:13,940 in a smartphone, we have various technologies that support that. So there 34 00:03:13,940 --> 00:03:19,571 is GPS, there's Bluetooth, there's LTE and 5G, there's Wi-Fi, there is Ultra- 35 00:03:19,571 --> 00:03:23,620 wideband, you probably never heard of this. There's audio. There is a camera. 36 00:03:23,620 --> 00:03:31,260 You could use all of this. And the reason why you can use this to measure a distance 37 00:03:31,260 --> 00:03:36,980 or a direction is that on the physical layer you have a wave form. And this wave 38 00:03:36,980 --> 00:03:41,540 form, first of all, has an amplitude and with the distance, this amplitude gets 39 00:03:41,540 --> 00:03:45,230 lower. So this also means that the signal strength is lower and you also have a 40 00:03:45,230 --> 00:03:49,651 phase that is changing with the distance. So these are properties that you can 41 00:03:49,651 --> 00:03:54,120 measure on the physical layer, on a raw wave form. And some of this information is 42 00:03:54,120 --> 00:04:00,070 also sent to upper layers. And the most obvious one is the signal strength, so 43 00:04:00,070 --> 00:04:04,260 it's a physical layer property that you can measure, and it's also sent to the 44 00:04:04,260 --> 00:04:10,320 upper layers on most protocols for simple things like determining how strong the WiFi 45 00:04:10,320 --> 00:04:14,540 is, so that your device can actually pick the strongest Wi-Fi access point and 46 00:04:14,540 --> 00:04:19,139 so on. So the signal strength is very essential and sent to upper layers in most 47 00:04:19,139 --> 00:04:25,479 protocols. You could actually even do a precise distance measurement, but for 48 00:04:25,479 --> 00:04:30,240 this, you need the raw wave form and that's not supported by most chips. There 49 00:04:30,240 --> 00:04:34,460 are a few chips that can do that. So for the precise distance measurement, you 50 00:04:34,460 --> 00:04:39,080 actually need to send a signal and send it back and measure the round trip time of 51 00:04:39,080 --> 00:04:43,800 this signal. And this is, for example, done to determine if your Apple Watch can 52 00:04:43,800 --> 00:04:49,289 unlock your MacBook. And the third option is that you can even measure a signal 53 00:04:49,289 --> 00:04:53,939 direction. This actually needs multiple antennas to do some sort of triangulation 54 00:04:53,939 --> 00:04:59,460 of the signal. And this is not supported by most chips because you not just need 55 00:04:59,460 --> 00:05:03,930 the support in the chip, but also the multiple antennas. But with this, you can, 56 00:05:03,930 --> 00:05:09,199 for example, do things like on some iPhones, you'll get some AirDrop direction 57 00:05:09,199 --> 00:05:14,349 of the other iPhone and so on, so you can have a direction shown on your device, of 58 00:05:14,349 --> 00:05:21,770 a signal. When it comes to location, the most obvious choice for many people, or 59 00:05:21,770 --> 00:05:27,120 the intuitive choice, would be GPS and GPS, well, the signals are sent by 60 00:05:27,120 --> 00:05:32,300 satellites and they orbit earth at more than 20.000 km, so they are, like, very, 61 00:05:32,300 --> 00:05:36,680 very distanced. And until the signal arrives on your smartphone, there is a lot 62 00:05:36,680 --> 00:05:42,360 of attenuation. So even if there are, like, just a few buildings or if you are 63 00:05:42,360 --> 00:05:45,960 indoors or something, but already a few buildings are sufficient to make the 64 00:05:45,960 --> 00:05:52,099 location imprecise and indoors, it doesn't work at all. But indoors we have the 65 00:05:52,099 --> 00:06:01,360 highest risk of infections. So GPS is not really helpful here. The next option would 66 00:06:01,360 --> 00:06:08,979 be signals from LTE, 5G and so on. So here you have some senders and you actually 67 00:06:08,979 --> 00:06:13,590 change cells with your smartphone. So, here we have one cell and while you move, 68 00:06:13,590 --> 00:06:18,889 you move to another cell and this is some movement that you do and you can measure 69 00:06:18,889 --> 00:06:25,020 the changes between the cells. And this actually has been used by phone providers 70 00:06:25,020 --> 00:06:30,300 in Germany to determine how effective the lockdown rules are. So with this, you can 71 00:06:30,300 --> 00:06:36,931 actually see if people move more or less than prior to the pandemic and so on, or 72 00:06:36,931 --> 00:06:41,400 how effective the rules are and so on. These are not very precise statistics, so 73 00:06:41,400 --> 00:06:49,650 this is nice to have those very broad statistic for a lot of people, but it's 74 00:06:49,650 --> 00:06:59,969 not useful to determine who you were meeting. And another option is Wi-Fi, but 75 00:06:59,969 --> 00:07:05,309 for Wi-Fi you have another issue. So Wi- Fis depend on access points and so on, and 76 00:07:05,309 --> 00:07:09,559 you can scan for access points. And of course, most smartphones also support, 77 00:07:09,559 --> 00:07:13,759 that you spawn your own Wi-Fi access point. and then you could scan for this, 78 00:07:13,759 --> 00:07:18,259 but then you can no longer use your Wi-Fi because you can only join one Wi-Fi or 79 00:07:18,259 --> 00:07:24,309 spawn one Wi-Fi access point and so on. And this really doesn't work. There are 80 00:07:24,309 --> 00:07:28,469 some vendor specific additions that would allow distance measurement, but it's not 81 00:07:28,469 --> 00:07:33,999 in most devices, it's not accessible through APIs and stuff like this. So you 82 00:07:33,999 --> 00:07:41,169 cannot use Wi-Fi because of how it works and how it is build into smartphones. The 83 00:07:41,169 --> 00:07:45,439 best option for precise measurement is audio, because even if you don't have 84 00:07:45,439 --> 00:07:52,949 access to the chip or any API, what you have here is that you have a sender or 85 00:07:52,949 --> 00:07:58,879 like a speaker and microphone and they send a wave and you can measure this wave. 86 00:07:58,879 --> 00:08:04,479 So even without any lower layer access to some firmware, to some chip, you can have 87 00:08:04,479 --> 00:08:09,379 this very precise measurement. But here the issue is that it means that you need 88 00:08:09,379 --> 00:08:13,960 access to the microphone. So an app would need to run and foreground with a 89 00:08:13,960 --> 00:08:18,069 microphone all the time. This drains battery and even worse, it means that you 90 00:08:18,069 --> 00:08:21,770 have a permanent spy in your pocket. So you have a governmental app that would 91 00:08:21,770 --> 00:08:28,409 listen to your microphone all the time. And many people don't want this. Then 92 00:08:28,409 --> 00:08:31,770 there is some option that you probably have never heard of, Ultra-wideband, so 93 00:08:31,770 --> 00:08:36,450 that's coming to the newest generation of iPhones and so far it's not used for many 94 00:08:36,450 --> 00:08:40,850 features. It's just something that can also determine the direction of signal 95 00:08:40,850 --> 00:08:46,040 because it's using multiple antennas and, so it can show you in which direction 96 00:08:46,040 --> 00:08:51,180 another devices is. But since it's only in a few devices, it's nothing that's useful 97 00:08:51,180 --> 00:08:56,440 for the general public. So it's a nice feature, but we are just a few years too 98 00:08:56,440 --> 00:09:03,190 early for it. And of course, you could use a camera similar to the microphones, you 99 00:09:03,190 --> 00:09:08,060 could, of course, record everything with the camera, but that's probably not the 100 00:09:08,060 --> 00:09:13,880 solution that you want. So more likely you could actually use it to lock into 101 00:09:13,880 --> 00:09:19,140 locations. So you scan a QR code and then register that you are in a restaurant or 102 00:09:19,140 --> 00:09:23,710 that you are meeting friends. So this is what the camera ideally should be used for 103 00:09:23,710 --> 00:09:31,580 and that would be a nice addition to the warning apps. And what's left, well, there 104 00:09:31,580 --> 00:09:38,380 is Bluetooth. Bluetooth actually sends signals at 2.4 GHz, like Wi-Fi , and 2.4 105 00:09:38,380 --> 00:09:44,600 GHz has a very big issue because it's attenuated by water and humans are 60% 106 00:09:44,600 --> 00:09:51,590 water. So the measurement is a bit imprecise. But I mean, 40% of the human 107 00:09:51,590 --> 00:09:55,910 are stupidity. And that's also an issue because humans are not using the Corona 108 00:09:55,910 --> 00:10:02,910 Warn App at all. That's even worse. And what else is there? The next issue is that 109 00:10:02,910 --> 00:10:08,160 the chips vary and the antenna position varies and so on. So you actually have the 110 00:10:08,160 --> 00:10:12,780 issue that the measurements are not the same on each smartphone model. So it might 111 00:10:12,780 --> 00:10:18,820 be the same signal, but different measurement. And for this first issue with 112 00:10:18,820 --> 00:10:23,090 the different measurements of the same signal, we already have something that's 113 00:10:23,090 --> 00:10:29,240 built into the API, the official Google/Apple API, and they include the 114 00:10:29,240 --> 00:10:37,380 transmit power per device model and so on, which is a slight risk for privacy. But 115 00:10:37,380 --> 00:10:44,880 overall, it has a very good compensation here. So, they said that this is better to 116 00:10:44,880 --> 00:10:49,120 use and have a little bit less privacy. Something else that you could use are 117 00:10:49,120 --> 00:10:54,854 active data connections over time to track the average signal strength. But that's 118 00:10:54,854 --> 00:10:58,570 worse because the active data connection means that you have data that's being 119 00:10:58,570 --> 00:11:05,790 exchanged between two devices and this is a risk for exploitations. So exploits need 120 00:11:05,790 --> 00:11:11,900 some exchange of data and this would be a risk for security. And another thing that 121 00:11:11,900 --> 00:11:17,060 you could add is the accelerometer. So depending on how you hold your smartphone, 122 00:11:17,060 --> 00:11:19,971 you can actually determine, by the accelerometer, if it's in your hand, in 123 00:11:19,971 --> 00:11:24,990 your pocket and so on, and then compensate for this in the measurements. But the 124 00:11:24,990 --> 00:11:30,864 issue here is that the accelerometer also is able to determine if you are running, 125 00:11:30,864 --> 00:11:35,590 walking, how many steps you're walking and so on. So it's a huge privacy impact to 126 00:11:35,590 --> 00:11:42,920 access the accelerometer. And last but not least, there's the angle of arrival, and 127 00:11:42,920 --> 00:11:47,940 that's something that's supported since Bluetooth 5.1 but it's an optional feature 128 00:11:47,940 --> 00:11:52,060 in the Bluetooth specification, so no smartphone has it yet. So you cannot 129 00:11:52,060 --> 00:11:59,100 actually do a specific measurement of the angle of another device. So that's pretty 130 00:11:59,100 --> 00:12:05,120 sad. And, well. So everything that improves those measurements on Bluetooth 131 00:12:05,120 --> 00:12:12,240 is always at the cost of privacy, security and battery life. So just considering how 132 00:12:12,240 --> 00:12:19,030 it's currently done in the API, it's pretty good. And to sum this technology 133 00:12:19,030 --> 00:12:23,670 rant a bit up, well. So even though Bluetooth is not perfect, Bluetooth Low 134 00:12:23,670 --> 00:12:27,620 Energy, it's really the best technology that we have in all smartphones or all 135 00:12:27,620 --> 00:12:34,261 recent smartphones. And with this, we can build exposure notifications. So, yeah, 136 00:12:34,261 --> 00:12:41,870 even though Bluetooth might not be optimal, it is still a winner. Yeah, yeah, 137 00:12:41,870 --> 00:12:47,394 yeah, I know Bluetooth is dangerous and so on, so let's discuss this a little bit. So 138 00:12:47,394 --> 00:12:52,520 actually during 2020, a lot of newspapers were trying to reach me and said, like: 139 00:12:52,520 --> 00:12:56,530 "Hey, jiska, you have been working on Bluetooth security, so please, please tell 140 00:12:56,530 --> 00:13:01,190 us how bad the current state of Bluetooth security is." And I was like, yeah, I 141 00:13:01,190 --> 00:13:05,500 don't really want to tell this because, you know, Bluetooth is a wireless protocol 142 00:13:05,500 --> 00:13:11,660 that transmits data and that has certain risks, but so has everything else. So, 143 00:13:11,660 --> 00:13:15,300 yeah. And then they didn't print this. I mean, it's really not a nice headline to 144 00:13:15,300 --> 00:13:21,154 print, "Bluetooth is a wireless protocol that transmits data." Yeah. And then they 145 00:13:21,154 --> 00:13:25,970 were like: "You know, I'm not using the exposure notifications because I'm using 146 00:13:25,970 --> 00:13:30,670 an outdated smartphone that does no longer receive security updates." And then I'm 147 00:13:30,670 --> 00:13:35,010 like, huh yeah. So I mean, no security updates - that's not just an issue for 148 00:13:35,010 --> 00:13:39,180 Bluetooth. That's an issue for everything, like if you browse unicorn pictures on the 149 00:13:39,180 --> 00:13:45,920 Internet or receive mail, So I don't know what, maybe just get a new smartphone if 150 00:13:45,920 --> 00:13:50,570 you're very concerned about the data on your smartphone. And also something that 151 00:13:50,570 --> 00:13:55,330 you shouldn't do to a journalist when they ask you this, is tell them: "So you have 152 00:13:55,330 --> 00:13:59,390 an outdated smartphone? Are you just calling from a number that belongs to the 153 00:13:59,390 --> 00:14:07,400 smartphone?" But, yeah. So just don't discuss this because it's a very general 154 00:14:07,400 --> 00:14:14,050 issue that's not specific to Bluetooth. And something that's a bit more specific 155 00:14:14,050 --> 00:14:20,241 to Bluetooth is that, well, you can build worm swifties. So a device can be a 156 00:14:20,241 --> 00:14:27,140 master or a slave in the Bluetooth terminology. And so a master can connect 157 00:14:27,140 --> 00:14:32,490 to slaves, and a smartphone can switch roles, which means that it can receive a 158 00:14:32,490 --> 00:14:36,050 worm and then become the master and transmit of worm to another slave and the 159 00:14:36,050 --> 00:14:41,950 slave then becomes a master and so on. So it's wormable. But to have a very good 160 00:14:41,950 --> 00:14:46,727 worm, you would actually need an exploit that runs on a recent iOS and a recent 161 00:14:46,727 --> 00:14:52,600 Android version and that is very reliable, so it should be a very good exploit on all 162 00:14:52,600 --> 00:14:57,790 platforms. And if someone had such an exploit, they would probably not use it to 163 00:14:57,790 --> 00:15:02,870 destroy exposure notifications, but they would sell it for the price that is 164 00:15:02,870 --> 00:15:06,910 currently available on the market. The highest price, of course, because probably 165 00:15:06,910 --> 00:15:13,440 you don't have that many ethical concerns, instead of reporting it. But, yeah. So 166 00:15:13,440 --> 00:15:19,950 that would be more of the scenario here. Then also people say: "I turn my Bluetooth 167 00:15:19,950 --> 00:15:24,230 off because Bluetooth drains battery". But, you know, Bluetooth doesn't drain a 168 00:15:24,230 --> 00:15:28,420 lot of battery, especially Bluetooth Low Energy. So Bluetooth Low Energy is a 169 00:15:28,420 --> 00:15:36,120 technology that can power even small devices like item finders of this size. So 170 00:15:36,120 --> 00:15:41,510 if you have a battery, button cell of this size and then have like a device, slightly 171 00:15:41,510 --> 00:15:46,590 larger, like a Bluetooth Finder, of this size, they can run with this button cell 172 00:15:46,590 --> 00:15:51,190 for a year. And you charge your smartphone daily, your smartphone has much more 173 00:15:51,190 --> 00:15:57,280 battery capacity than just one button cell. So, yeah, go for it. It really 174 00:15:57,280 --> 00:16:01,540 doesn't drain battery, especially because you also have combo chips and if you have 175 00:16:01,540 --> 00:16:08,150 Wi-Fi enabled, then Bluetooth really doesn't add anything to this. Another 176 00:16:08,150 --> 00:16:12,681 argument might be that Google and Apple are always stealing our data, and if they 177 00:16:12,681 --> 00:16:17,750 now do the contact tracing, this means that they are stealing data. But in fact, 178 00:16:17,750 --> 00:16:22,900 the exposure notification API was renamed because it really is just about exposure 179 00:16:22,900 --> 00:16:28,150 notifications. It's not about a contact log. And this means that this API is not 180 00:16:28,150 --> 00:16:34,970 collecting any data about your contact trace and well, it's good and bad in terms 181 00:16:34,970 --> 00:16:39,710 of, they are preventing a centralized collection by everyone. So not just by 182 00:16:39,710 --> 00:16:43,750 health authorities, they just prevent it by everyone and including themselves. So 183 00:16:43,750 --> 00:16:52,799 there is just no data collection. So you cannot complain about this. So, yeah, 184 00:16:52,799 --> 00:16:58,730 after saying this, you might ask me if I had now just said like that Bluetooth is 185 00:16:58,730 --> 00:17:03,960 not dangerous at all. But, you know, Bluetooth is still a wireless protocol 186 00:17:03,960 --> 00:17:14,669 that transmits data. So, yeah, maybe it's still somewhat dangerous. So if you look 187 00:17:14,669 --> 00:17:20,949 at the Apple ecosystem, what you have is a feature set called Continuity Framework 188 00:17:20,949 --> 00:17:26,120 and this does a lot of things like some copy-paste AirDrop hand-off, whatsoever. 189 00:17:26,120 --> 00:17:32,929 So data that's being exchanged. And all of this continuity part here, it all works 190 00:17:32,929 --> 00:17:40,580 with BLE advertisements and then actually Wi-Fi or AWDL for the data transfer. So 191 00:17:40,580 --> 00:17:45,990 you have a lot of BLE advertisements going on if you already are using iOS and other 192 00:17:45,990 --> 00:17:51,440 Apple devices. And exposure notifications - they really are just a tiny additional 193 00:17:51,440 --> 00:17:55,419 thing here. So it's just yet another feature that's based on BLE 194 00:17:55,419 --> 00:18:03,759 advertisements. So it's nothing that adds a lot. And you also need to know that the 195 00:18:03,759 --> 00:18:07,919 exposure notifications don't have a lot of logic, so you just receive them, you don't 196 00:18:07,919 --> 00:18:12,720 answer to them and so on. So it's, really, a very harmless feature on top, compared 197 00:18:12,720 --> 00:18:19,360 to the other services running. Now, let's look into an Android example, which is a 198 00:18:19,360 --> 00:18:26,029 recent Bluetooth exploit. So bugs like this exist, and this is not just specific 199 00:18:26,029 --> 00:18:31,019 to Android, it can also be on iOS and it's also not specific to Bluetooth because we 200 00:18:31,019 --> 00:18:36,110 have bugs all the time. So if you are using software, if you are not updating 201 00:18:36,110 --> 00:18:40,340 it, there might be bugs in it or there might also be bugs in it that have not 202 00:18:40,340 --> 00:18:46,820 been seen for a while. So despite they should have been fixed and so on. So this 203 00:18:46,820 --> 00:18:52,450 just exists whenever you're using software. And also those bugs often depend 204 00:18:52,450 --> 00:18:57,320 on certain hardware and software versions. So, for example, this exploit only works 205 00:18:57,320 --> 00:19:02,940 on Android 9 and older because it requires a very specific implementation of memcopy, 206 00:19:02,940 --> 00:19:08,080 because the memcopy is called with an length argument of -2, and it has 207 00:19:08,080 --> 00:19:14,330 different behavior on different systems. And last but not least what this exploit 208 00:19:14,330 --> 00:19:19,929 actually needs to run for something like 2 min because you need to bypass ASLR over 209 00:19:19,929 --> 00:19:25,081 of the air. So you need to be in proximity of a vulnerable device for a while if you 210 00:19:25,081 --> 00:19:32,210 are an attacker. And now people say: "Yeah, but it's special because this kind 211 00:19:32,210 --> 00:19:36,309 of bug, it's wormable". Yeah, that's true. So you could build a Bluetooth worm 212 00:19:36,309 --> 00:19:41,380 with this, but what does it look like? So first of all, the devices are losing 213 00:19:41,380 --> 00:19:46,570 connection. So you don't have a full mesh, but you have like some connections here 214 00:19:46,570 --> 00:19:51,390 and there and you have a worm spreading somewhere and so on and so forth. But the 215 00:19:51,390 --> 00:19:54,520 attacker actually needs some control server. So no matter what the attacker 216 00:19:54,520 --> 00:20:00,840 wants to achieve, like steal data or do some Bitcoin mining or something, in the 217 00:20:00,840 --> 00:20:07,049 end you need to have some feedback and control server in the Internet to have a 218 00:20:07,049 --> 00:20:11,210 communication or also if something goes wrong with your exploit to stop it or 219 00:20:11,210 --> 00:20:15,750 something, you need this back channel, despite you have a wireless channel 220 00:20:15,750 --> 00:20:20,568 because your wireless channel is not permanent. And the next challenge here is 221 00:20:20,568 --> 00:20:28,740 that your exploit needs to be very reliable, so it means that if you actually 222 00:20:28,740 --> 00:20:32,419 produce a crash and if you have a worm that spreads very fast and that spreads a 223 00:20:32,419 --> 00:20:37,220 lot, then you have the problem that if it's not 100% reliable, you would get 224 00:20:37,220 --> 00:20:44,330 crashes and that are reported to Apple or to Google. And this is an issue because 225 00:20:44,330 --> 00:20:48,450 once a bug is detected, it means that Apple and Google will update their 226 00:20:48,450 --> 00:20:54,049 operating system and your bug is gone. So all your exploit development was just for 227 00:20:54,049 --> 00:21:00,179 nothing, your exploit is gone. And well, that actually means that if an attacker 228 00:21:00,179 --> 00:21:06,202 would want to build a worm, they would probably just use some outdated bug. And 229 00:21:06,202 --> 00:21:12,380 as I said, bugs happen so they are there every few months or years, it depends. You 230 00:21:12,380 --> 00:21:18,639 would have a bug that works for a worm and then the attacker does not have the risk 231 00:21:18,639 --> 00:21:26,330 of losing a very, like, unique bug that is worth a lot of money if they use an old 232 00:21:26,330 --> 00:21:30,029 one. But it also means that all the devices that get updates are safe from 233 00:21:30,029 --> 00:21:36,344 this worm. So it really depends on what the attacker wants to do. So what I 234 00:21:36,344 --> 00:21:40,810 think is more likely so instead of building a worm - what are attack 235 00:21:40,810 --> 00:21:45,830 scenarios? Well, if you think about Bluetooth exploits, the worm needs a lot 236 00:21:45,830 --> 00:21:52,238 of reliability and so on. And you have this risk of losing the exploit. So 237 00:21:52,238 --> 00:21:56,470 probably the attacks are a bit more targeted and require the physical 238 00:21:56,470 --> 00:22:02,320 proximity of those targets. So stuff that I would say is very realistic would be 239 00:22:02,320 --> 00:22:08,259 like if you have some airport security check or if, like an attacker is close to 240 00:22:08,259 --> 00:22:12,309 certain buildings, like company buildings or your home or something, to steal 241 00:22:12,309 --> 00:22:16,919 certain secrets or also from the government, if there are protests and the 242 00:22:16,919 --> 00:22:23,580 government does not want them or wants the identities of the protesters or something, 243 00:22:23,580 --> 00:22:35,059 this would be an option. But the worm, as I said, is, yeah, a bit, let's say, not so 244 00:22:35,059 --> 00:22:41,940 plausible. And the next thing is so exploit development means that if you want 245 00:22:41,940 --> 00:22:49,780 to develop and exploit for recent iOS and Android, then this is a lot of work and 246 00:22:49,780 --> 00:22:55,139 well, your enemy might be able to afford this. And in this case, they can also use 247 00:22:55,139 --> 00:22:59,529 it multiple times for as long as the bug does not leak and it's not fixed, they can 248 00:22:59,529 --> 00:23:05,440 reuse to exploit. So it's a one time development cost. But if you think you 249 00:23:05,440 --> 00:23:09,150 have enemies like this, then probably use a separate smartphone for exposure 250 00:23:09,150 --> 00:23:14,820 notifications and keep your smartphone up to date and so on. Or if you are very, 251 00:23:14,820 --> 00:23:18,720 very, very afraid of attacks and maybe just don't use a smartphone because Bluetooth 252 00:23:18,720 --> 00:23:24,149 is really not the only way to hijack your smartphone. So you could still be attacked 253 00:23:24,149 --> 00:23:28,659 just by a messengers, browsers, other wireless technologies, like LTE, and so 254 00:23:28,659 --> 00:23:34,460 on. So it's just a risk that you have and that happens. And that's not specific to 255 00:23:34,460 --> 00:23:43,230 Bluetooth. Anyway, let's go to a few implementation specific details, so if you 256 00:23:43,230 --> 00:23:47,830 want to understand the exploitation background and why I think that the 257 00:23:47,830 --> 00:23:55,299 Bluetooth Exposure Notification API, as it is, is very secure. So first of all, the 258 00:23:55,299 --> 00:24:00,690 API does Bluetooth address randomization, so that means these addresses are 259 00:24:00,690 --> 00:24:06,450 randomized and not connectable and you cannot connect to them as an attacker. And 260 00:24:06,450 --> 00:24:11,349 also, there is no feedback channel because of this non-connectable property. And it 261 00:24:11,349 --> 00:24:16,802 means that usually your smartphone is configured in a way that it doesn't 262 00:24:16,802 --> 00:24:22,559 announce any connectable addresses, it only has these random addresses. And this 263 00:24:22,559 --> 00:24:26,470 is really hard for exploitations. So you need to know the correct address of a 264 00:24:26,470 --> 00:24:32,169 smartphone to send an exploit to it. And it's not send over the air. So you need to 265 00:24:32,169 --> 00:24:36,470 decode packets, for example, if you're in parallel listening to music or something, 266 00:24:36,470 --> 00:24:43,360 you could extract the address from this, but it's very hard to achieve this. And 267 00:24:43,360 --> 00:24:47,639 another part is, that especially Apple is tremendously restricting their Bluetooth 268 00:24:47,639 --> 00:24:55,320 interfaces. So smartphone apps cannot use Bluetooth for arbitrary features that are 269 00:24:55,320 --> 00:25:02,989 available within the Bluetooth specification. And this means, that this 270 00:25:02,989 --> 00:25:08,650 is good for your privacy. So, for example, it's hard to build something like a spy in 271 00:25:08,650 --> 00:25:16,450 your pocket on iOS because there it's hard to run an app in the background that does 272 00:25:16,450 --> 00:25:22,200 all the tracking via Bluetooth and so on. And the other way around it means that if 273 00:25:22,200 --> 00:25:26,309 there are apps that do exposure notifications or contact tracing and they 274 00:25:26,309 --> 00:25:33,600 are not based on the official API, actually these apps are very exploitable 275 00:25:33,600 --> 00:25:40,779 because they use active connections. They run in the foreground. They actually are 276 00:25:40,779 --> 00:25:45,499 logging stuff that should not be logged, so I probably don't do this and don't 277 00:25:45,499 --> 00:25:53,554 trust those apps that are not using the API. Another issue might be privacy. So 278 00:25:53,554 --> 00:25:58,809 first of all, there's a random identifier that stays the same for a while, but as I 279 00:25:58,809 --> 00:26:02,600 said, on iOS you have the Continuity framework and it does the same, so at 280 00:26:02,600 --> 00:26:07,199 least on Apple devices this really doesn't make a big difference. And if you think a 281 00:26:07,199 --> 00:26:11,270 bit broader than Apple. Well, first of all, there's the signal strength and if you 282 00:26:11,270 --> 00:26:16,789 compare this like to other technologies that are wireless, like Wi-Fi and LTE, 283 00:26:16,789 --> 00:26:21,669 there you also have signals with a signal strength and maybe changing addresses and 284 00:26:21,669 --> 00:26:28,380 so on. You can always triangulate signals. So if you don't want to be tracked, you 285 00:26:28,380 --> 00:26:38,029 would also need to disable Wi-Fi and LTE. Another very important part about the 286 00:26:38,029 --> 00:26:42,019 security assumptions is the server infrastructure, so there are two types of 287 00:26:42,019 --> 00:26:46,629 server infrastructure and first of all, you have one for the centralized approach, 288 00:26:46,629 --> 00:26:50,410 which is also known as contact tracing, and in the centralized approach the server 289 00:26:50,410 --> 00:26:55,309 knows everything. So the server knows who was in contact with whom and for how long. 290 00:26:55,309 --> 00:27:00,430 So, for example, Alice met Bob for 15 min, but also Alice met 10 other people on 291 00:27:00,430 --> 00:27:09,409 Tuesday or something so that they actually have a record log of who met whom. And now the 292 00:27:09,409 --> 00:27:13,509 server can actually tell specific people after someone got a positive test and so 293 00:27:13,509 --> 00:27:20,170 on, for how long this was, the server can still censor some of the information it 294 00:27:20,170 --> 00:27:26,570 sends out to specific persons, but it has a lot of information internally. So this 295 00:27:26,570 --> 00:27:31,049 means if this server is run by some governmental health authority, that all 296 00:27:31,049 --> 00:27:39,459 the users have to trust this authority, a lot, with their contact history. And the 297 00:27:39,459 --> 00:27:44,820 other approach are decentralized exposure notifications, so the server has a list of 298 00:27:44,820 --> 00:27:51,509 pseudonyms and positively tested users, but these are just pseudonyms, not the 299 00:27:51,509 --> 00:27:56,230 exact times and exposures. And everyone can download this list and compare it to a 300 00:27:56,230 --> 00:28:00,330 local list. So you just have a local list on your smartphone of who you met. And you 301 00:28:00,330 --> 00:28:06,038 can compare the lists with pseudonyms that are on the server. And this means that 302 00:28:06,038 --> 00:28:11,659 everyone could even opt-out to publish these pseudonyms. And you don't share your 303 00:28:11,659 --> 00:28:19,240 list to anyone. So why is this good or bad? Well, the governmental health 304 00:28:19,240 --> 00:28:23,640 authorities don't get any contact tracing info in the decentralized approach, and 305 00:28:23,640 --> 00:28:28,409 this might be an issue because this means that the government does not have any 306 00:28:28,409 --> 00:28:31,806 statistics about spreaders or effectiveness of the app. They cannot 307 00:28:31,806 --> 00:28:36,580 measure how much the app actually helped. They cannot measure how many infections 308 00:28:36,580 --> 00:28:41,009 were prevented by telling people to go into quarantine or to get a test and so 309 00:28:41,009 --> 00:28:48,590 on. But on the other hand, it means nobody is getting this data. So neither Apple nor 310 00:28:48,590 --> 00:28:53,470 Google nor governments, nobody is getting the data and there is no gain from 311 00:28:53,470 --> 00:28:57,989 attacking the servers because they don't have any private information. And there's 312 00:28:57,989 --> 00:29:03,399 also no privacy impact from using the app. And in the end, if you get a positive 313 00:29:03,399 --> 00:29:07,999 test, even then you can choose to not share the result if you think it's an 314 00:29:07,999 --> 00:29:13,919 issue to disclose your pseudonyms. And I mean, ideally, many people should share 315 00:29:13,919 --> 00:29:23,240 their result, but you don't have to. And I want to show you a few attacks on exposure 316 00:29:23,240 --> 00:29:26,630 notifications, because some people said, like exposure notifications are very, 317 00:29:26,630 --> 00:29:33,249 very, very insecure. So let's look into attacks that have been publicly discussed 318 00:29:33,249 --> 00:29:38,239 on those exposure notifications as they are implemented now. And please note that many 319 00:29:38,239 --> 00:29:42,619 of these attacks are not specific to Bluetooth, but they are specific to 320 00:29:42,619 --> 00:29:48,880 everything that's somehow wireless and somehow a notification. So let's look. 321 00:29:48,880 --> 00:29:54,340 Let's take a look. So the time machine attack. This one is quite interesting. The 322 00:29:54,340 --> 00:29:58,990 assumption here is that someone can change the time on your smartphone and then 323 00:29:58,990 --> 00:30:06,940 replay outdated tokens, so that you would think, like you met pseudonyms in the past 324 00:30:06,940 --> 00:30:10,960 that were already known to be tested positive and because your smartphone also 325 00:30:10,960 --> 00:30:15,981 is in the past, it would accept those tokens and log them and then if you 326 00:30:15,981 --> 00:30:21,659 compare them to the server later on, you think that you were positive, in contact 327 00:30:21,659 --> 00:30:26,659 with positive users and so on. But please note that spoofing time is very, very 328 00:30:26,659 --> 00:30:31,570 hard. So if someone can spoof time, it means they can also break other things 329 00:30:31,570 --> 00:30:36,360 like TLS. And I mean, if I had a time machine and I would just travel back to a 330 00:30:36,360 --> 00:30:43,799 time prior to 2020 or something, instead of faking a few exposure notifications. 331 00:30:43,799 --> 00:30:50,980 The next attack is the wormhole attack. So imagine that like this one would be one 332 00:30:50,980 --> 00:30:54,710 shopping center, then another shopping center and maybe up there a police station 333 00:30:54,710 --> 00:31:00,429 or something like this. How does that work? Well, if you wormhole them and put 334 00:31:00,429 --> 00:31:08,090 them together, then the chance of getting positive exposure notification in the end 335 00:31:08,090 --> 00:31:17,478 is very high. So you increase the chance of having positive exposure. And this 336 00:31:17,478 --> 00:31:23,809 exposure, of course, was not real. So it's forwarded exposure. And because of this, 337 00:31:23,809 --> 00:31:28,270 in the worst case, you would do more physical distancing, more testing, maybe 338 00:31:28,270 --> 00:31:33,580 you also start to distrust the app a little bit, but it doesn't really harm the 339 00:31:33,580 --> 00:31:38,220 overall system. So the amount of record on the server with the positive tests, it's 340 00:31:38,220 --> 00:31:43,559 not increased because, only confirmed positive cases are uploaded to the 341 00:31:43,559 --> 00:31:48,749 pseudonym list and those who are just here and get a notification are not uploaded. 342 00:31:48,749 --> 00:31:52,950 And also to have such a deployment so to have this wormhole and the wormhole that 343 00:31:52,950 --> 00:31:58,750 scales, you need a lot of devices that forward the notifications and in public 344 00:31:58,750 --> 00:32:06,190 spaces so it's not that easy to implement this. The last attack is the identity 345 00:32:06,190 --> 00:32:10,350 tracking attack, so let's say you have those pseudonyms. The pseudonyms, they 346 00:32:10,350 --> 00:32:14,809 change over time and you are moving through a city and there are multiple 347 00:32:14,809 --> 00:32:20,039 devices that are observing your pseudonym changes. So, of course, you can then start 348 00:32:20,039 --> 00:32:26,200 tracking users. This, again, requires a very large scale installation. And the 349 00:32:26,200 --> 00:32:30,979 issue is also that if you are scared of this type of attack, then you would also 350 00:32:30,979 --> 00:32:35,427 need to disable Wi-Fi and LTE and so on, because you can always triangulate 351 00:32:35,427 --> 00:32:42,259 signals. So ideally, if you don't want to be tracked, turn off wireless technology, 352 00:32:42,259 --> 00:32:49,149 this is really not specific to Bluetooth at all. So, yeah, all those attacks, they 353 00:32:49,149 --> 00:32:55,919 are valid, but to deploy them, like, to have records of exposure notifications 354 00:32:55,919 --> 00:33:02,970 that you can then replay with time travel or a wormhole or also some tracing of IDs, 355 00:33:02,970 --> 00:33:06,909 you really need a large scale installation of something like Raspberry Pis throughout 356 00:33:06,909 --> 00:33:12,906 a city and many, many, many devices. So this would also work in any other wireless 357 00:33:12,906 --> 00:33:18,489 ecosystem. But OK, but if you would roll out such an 358 00:33:18,489 --> 00:33:23,220 installation, also, keep in mind that you could instead just deploy something like a 359 00:33:23,220 --> 00:33:28,935 lot of devices that have microphones or cameras and Wi-Fi and so on and track a 360 00:33:28,935 --> 00:33:34,299 lot of other things. This needs to happen in public spaces, so I don't know, next to 361 00:33:34,299 --> 00:33:39,689 bus stations, shopping centers and so on. And well, if you have such an 362 00:33:39,689 --> 00:33:45,580 installation, then really just tampering with exposure notifications of Bluetooth 363 00:33:45,580 --> 00:33:51,429 is not your main concern. The sad reality might actually be that we already have a 364 00:33:51,429 --> 00:33:56,334 lot of surveillance everywhere, so we have a lot of cameras in public spaces. So this 365 00:33:56,334 --> 00:34:01,639 is not the part that I would be afraid of. I mean, I would be afraid of public 366 00:34:01,639 --> 00:34:10,119 surveillance, obviously, but not about Bluetooth surveillance in particular. So 367 00:34:10,119 --> 00:34:14,440 let me conclude my talk. The BLE advertisements are really the most 368 00:34:14,440 --> 00:34:17,570 suitable technology that we have in a smartphone to implement exposure 369 00:34:17,570 --> 00:34:23,980 notifications, and they are available on recent smartphones, on iOS and Android. 370 00:34:23,980 --> 00:34:29,179 They are very secure, privacy preserving, battery friendly, and also scalable. And, 371 00:34:29,179 --> 00:34:33,139 keep in mind, every prevented infection saves lives and also prevents long term 372 00:34:33,139 --> 00:34:41,579 disease. So this is really a thing to use, even if it does not work 100%. And with 373 00:34:41,579 --> 00:34:46,689 this, let's start the Q&A and discuss whatever you like, Bluetooth worms and so 374 00:34:46,689 --> 00:34:54,519 on. Thanks for listening. Herald: All right, thank you, jiska, for 375 00:34:54,519 --> 00:34:59,299 your talk. I hope you have time for some Q&A. 376 00:34:59,299 --> 00:35:05,829 J: Yeah, let's go. H: Awesome. 377 00:35:05,829 --> 00:35:11,719 J: Oh, I think that was Ollies Internet connection, was it? Yeah. So I 378 00:35:11,719 --> 00:35:15,470 might just decide on my own until he reconnects. Ah, here you are! 379 00:35:15,470 --> 00:35:21,110 H: I'm so sorry. The question was why would the angle of arrival be interesting 380 00:35:21,110 --> 00:35:26,230 for an attacker or J: Not for, for an attacker. But like from 381 00:35:26,230 --> 00:35:31,680 the technology, it would be interesting to have it in Bluetooth because then you 382 00:35:31,680 --> 00:35:37,030 could do some direction estimation. And I mean, if people move, you could also get a 383 00:35:37,030 --> 00:35:43,471 direction and maybe location via this or assist this. But yeah, I mean, it's not in 384 00:35:43,471 --> 00:35:47,810 any chip yet except from some evaluation kits. 385 00:35:47,810 --> 00:35:55,010 H: All right. Thank you. Is there any studies that proves or disproves the 386 00:35:55,010 --> 00:35:59,520 efficiency of contract tracing apps in general? I mean, like the use case? 387 00:35:59,520 --> 00:36:06,289 J: I mean, the issue is because we have the exposure notification framework that 388 00:36:06,289 --> 00:36:11,970 we do not have any statistics. So the good and the bad thing about privacy is that we 389 00:36:11,970 --> 00:36:17,609 cannot have such a study except from if people would provide their data in, I 390 00:36:17,609 --> 00:36:21,980 don't know, a questionnaire or something. But at least I know people who have been 391 00:36:21,980 --> 00:36:26,324 warned by the app and got the test and so on. So it seems to work from the people I 392 00:36:26,324 --> 00:36:33,289 know. Yeah. And I mean, every life that it saves counts in the end. So, I mean, 393 00:36:33,289 --> 00:36:39,890 nothing is perfect, right? H: True very much. Thanks for your answer. 394 00:36:39,890 --> 00:36:44,989 But user triplefive would like to know: "Why would you think the accelerometer 395 00:36:44,989 --> 00:36:49,950 would be a data privacy issue, isn't it up to how the sensor data is processed, i.e. 396 00:36:49,950 --> 00:36:54,430 stays on the device, is not stored and so on and so forth." 397 00:36:54,430 --> 00:36:58,670 J: Yeah, of course. But I mean, once you give that permission to the app, you need 398 00:36:58,670 --> 00:37:02,960 to trust the app, which is first of all a binary that you download. I mean, maybe 399 00:37:02,960 --> 00:37:07,390 it's open source like our German app, but you never know. And then it could process 400 00:37:07,390 --> 00:37:11,810 this data. And actually from an accelerometer, there have been studies 401 00:37:11,810 --> 00:37:16,670 that you not can just, like, do step counts, but even stuff like someone turned 402 00:37:16,670 --> 00:37:20,040 to the left, to the right, and from this, if you have an overlay to a map, you can 403 00:37:20,040 --> 00:37:24,660 even reconstruct the path that you moved through a city, for example. So that's a 404 00:37:24,660 --> 00:37:32,920 big issue, I think. H: Alright. Thank you. There's one more 405 00:37:32,920 --> 00:37:38,869 question here. Have any of the theoretical or possible exploits been tried in 406 00:37:38,869 --> 00:37:42,312 practice? To the best of your knowledge, that is? 407 00:37:42,312 --> 00:37:47,970 J: To my knowledge, not. I mean, I think it would only be visible once someone does 408 00:37:47,970 --> 00:37:53,309 such an attack, large scale, and then they need to manage to have a large deployment 409 00:37:53,309 --> 00:38:02,980 of such an attack without being caught. So, yeah, nobody did this so far. Yeah. 410 00:38:02,980 --> 00:38:11,000 H: OK, makes sense. And there's one person who had a comment. They pointed out that 411 00:38:11,000 --> 00:38:15,210 there is an open implementation for the framework if the user wants to go without 412 00:38:15,210 --> 00:38:20,380 Google or Apple at all and still take part in exposure notifications. I think it's a 413 00:38:20,380 --> 00:38:24,030 fairly recent development. J: Yeah, exactly. So I had my slides 414 00:38:24,030 --> 00:38:29,049 already finished when that came out. So it's on the F-Droid store and it uses, I 415 00:38:29,049 --> 00:38:33,690 think, yeah, just like an open source implementation so that you can now use it 416 00:38:33,690 --> 00:38:43,260 even on your Lineage phone for example. H: OK, thank you. 417 00:38:43,260 --> 00:38:47,920 J: OK, any further questions? H: Yeah, one last question just bumped in 418 00:38:47,920 --> 00:38:54,119 here, surfaced over there. Has anyone tried to crack the verification server 419 00:38:54,119 --> 00:39:01,140 by brute force? The person asking did a back on the envelope calculation, back in 420 00:39:01,140 --> 00:39:06,700 time. And it seemed possible to just try out all possible Tele-TANs at some point. 421 00:39:06,700 --> 00:39:11,490 J: All possible Tele-TANs, I mean, so that would be like really a brute force that 422 00:39:11,490 --> 00:39:16,252 you see in the back-end, right? So that's something that you can't just rate limit. 423 00:39:16,252 --> 00:39:19,480 And that's probably the only thing that you can brute force because all the 424 00:39:19,480 --> 00:39:25,660 comparison and so on is done locally on the smartphone. So the TANs would be the 425 00:39:25,660 --> 00:39:30,740 only weak point in the system. And if someone tries to brute force all TANs 426 00:39:30,740 --> 00:39:36,530 that, yeah, it's a very obvious attack. H: You know, makes sense. All right. 427 00:39:36,530 --> 00:39:39,849 Thanks a lot for the talk. Thank you for your patience in answering all the 428 00:39:39,849 --> 00:39:46,230 questions. I believe that's actually our time slot exactly. And with that, I hand 429 00:39:46,230 --> 00:39:51,720 over to the news show from Dublin this time. Thanks a lot. 430 00:39:51,720 --> 00:39:57,100 *postroll music* 431 00:39:57,100 --> 00:40:32,000 Subtitles created by c3subtitles.de in the year 2020. Join, and help us!