RC3 preroll music Jiska: Hello, everyone, and welcome to my talk, which is about Bluetooth exposure notification security. This talk could also be summarized as follows: So first of all, exposure notifications as in the Google/Apple API are very secure and battery friendly. And please, just use the Corona Warn App. This might be very confusing to most of you, who are listening and know me since a while because I have been working on Bluetooth exploitation in the past and always thought everyone, like, Bluetooth is insecure. So you might wonder: How does this align? Why am I now here telling you that Bluetooth exposure notifications are secure? So well it's a pandemic, so instead of just criticizing solutions, we should also look for solutions that work. So instead of ranting, work on something that helps everyone! So the first question that many people asks are, do we even need a smartphone app to fight a pandemic? What we can say, well, it's December exposure notifications were introduced in June and we still have Corona, it still exists. So it didn't help to fully fight them and probably it won't stop Corona. But let's look at this from another perspective. So first of all, if you have an app and get the warnings, we can do more accurate testing and that's very important because even now we are still low on tests. We cannot test everyone. We only test people with symptoms. And that's really an issue because people can, infect other people prior to symptoms and they could even infect others without having symptoms or they're asymptomatic cases. And these can be found with the Corona Warn App. And also this can encourage manual contact tracing because official health authorities, they are not able to make physical, manual contact tracing any more. So you need to ask your friends and so on if your app turns red, and then you might find cases, even if they forgot to tell you. Of course, this all doesn't replace washing your hands, wearing a mask, physically distancing and so on. So, of course, you still need to take these measures. But even if you just inform a few people, every prevented infection actually saves lives. So it's very important to have an app like this. And the next question is, well, is there something better than Bluetooth? So if we want to look for a solution to build an app that supports exposure notifications and prevent infections, how could we build it? So we actually need something that somehow measures proximity or location and in a smartphone, we have various technologies that support that. So there is GPS, there's Bluetooth, there's LTE and 5G, there's Wi-Fi, there is Ultra- wideband, you probably never heard of this. There's audio. There is a camera. You could use all of this. And the reason why you can use this to measure a distance or a direction is that on the physical layer you have a wave form. And this wave form, first of all, has an amplitude and with the distance, this amplitude gets lower. So this also means that the signal strength is lower and you also have a phase that is changing with the distance. So these are properties that you can measure on the physical layer, on a raw wave form. And some of this information is also sent to upper layers. And the most obvious one is the signal strength, so it's a physical layer property that you can measure, and it's also sent to the upper layers on most protocols for simple things like determining how strong the WiFi is, so that your device can actually pick the strongest Wi-Fi access point and so on. So the signal strength is very essential and sent to upper layers in most protocols. You could actually even do a precise distance measurement, but for this, you need the raw wave form and that's not supported by most chips. There are a few chips that can do that. So for the precise distance measurement, you actually need to send a signal and send it back and measure the round trip time of this signal. And this is, for example, done to determine if your Apple Watch can unlock your MacBook. And the third option is that you can even measure a signal direction. This actually needs multiple antennas to do some sort of triangulation of the signal. And this is not supported by most chips because you not just need the support in the chip, but also the multiple antennas. But with this, you can, for example, do things like on some iPhones, you'll get some AirDrop direction of the other iPhone and so on, so you can have a direction shown on your device, of a signal. When it comes to location, the most obvious choice for many people, or the intuitive choice, would be GPS and GPS, well, the signals are sent by satellites and they orbit earth at more than 20.000 km, so they are, like, very, very distanced. And until the signal arrives on your smartphone, there is a lot of attenuation. So even if there are, like, just a few buildings or if you are indoors or something, but already a few buildings are sufficient to make the location imprecise and indoors, it doesn't work at all. But indoors we have the highest risk of infections. So GPS is not really helpful here. The next option would be signals from LTE, 5G and so on. So here you have some senders and you actually change cells with your smartphone. So, here we have one cell and while you move, you move to another cell and this is some movement that you do and you can measure the changes between the cells. And this actually has been used by phone providers in Germany to determine how effective the lockdown rules are. So with this, you can actually see if people move more or less than prior to the pandemic and so on, or how effective the rules are and so on. These are not very precise statistics, so this is nice to have those very broad statistic for a lot of people, but it's not useful to determine who you were meeting. And another option is Wi-Fi, but for Wi-Fi you have another issue. So Wi- Fis depend on access points and so on, and you can scan for access points. And of course, most smartphones also support, that you spawn your own Wi-Fi access point. and then you could scan for this, but then you can no longer use your Wi-Fi because you can only join one Wi-Fi or spawn one Wi-Fi access point and so on. And this really doesn't work. There are some vendor specific additions that would allow distance measurement, but it's not in most devices, it's not accessible through APIs and stuff like this. So you cannot use Wi-Fi because of how it works and how it is build into smartphones. The best option for precise measurement is audio, because even if you don't have access to the chip or any API, what you have here is that you have a sender or like a speaker and microphone and they send a wave and you can measure this wave. So even without any lower layer access to some firmware, to some chip, you can have this very precise measurement. But here the issue is that it means that you need access to the microphone. So an app would need to run and foreground with a microphone all the time. This drains battery and even worse, it means that you have a permanent spy in your pocket. So you have a governmental app that would listen to your microphone all the time. And many people don't want this. Then there is some option that you probably have never heard of, Ultra-wideband, so that's coming to the newest generation of iPhones and so far it's not used for many features. It's just something that can also determine the direction of signal because it's using multiple antennas and, so it can show you in which direction another devices is. But since it's only in a few devices, it's nothing that's useful for the general public. So it's a nice feature, but we are just a few years too early for it. And of course, you could use a camera similar to the microphones, you could, of course, record everything with the camera, but that's probably not the solution that you want. So more likely you could actually use it to lock into locations. So you scan a QR code and then register that you are in a restaurant or that you are meeting friends. So this is what the camera ideally should be used for and that would be a nice addition to the warning apps. And what's left, well, there is Bluetooth. Bluetooth actually sends signals at 2.4 GHz, like Wi-Fi , and 2.4 GHz has a very big issue because it's attenuated by water and humans are 60% water. So the measurement is a bit imprecise. But I mean, 40% of the human are stupidity. And that's also an issue because humans are not using the Corona Warn App at all. That's even worse. And what else is there? The next issue is that the chips vary and the antenna position varies and so on. So you actually have the issue that the measurements are not the same on each smartphone model. So it might be the same signal, but different measurement. And for this first issue with the different measurements of the same signal, we already have something that's built into the API, the official Google/Apple API, and they include the transmit power per device model and so on, which is a slight risk for privacy. But overall, it has a very good compensation here. So, they said that this is better to use and have a little bit less privacy. Something else that you could use are active data connections over time to track the average signal strength. But that's worse because the active data connection means that you have data that's being exchanged between two devices and this is a risk for exploitations. So exploits need some exchange of data and this would be a risk for security. And another thing that you could add is the accelerometer. So depending on how you hold your smartphone, you can actually determine, by the accelerometer, if it's in your hand, in your pocket and so on, and then compensate for this in the measurements. But the issue here is that the accelerometer also is able to determine if you are running, walking, how many steps you're walking and so on. So it's a huge privacy impact to access the accelerometer. And last but not least, there's the angle of arrival, and that's something that's supported since Bluetooth 5.1 but it's an optional feature in the Bluetooth specification, so no smartphone has it yet. So you cannot actually do a specific measurement of the angle of another device. So that's pretty sad. And, well. So everything that improves those measurements on Bluetooth is always at the cost of privacy, security and battery life. So just considering how it's currently done in the API, it's pretty good. And to sum this technology rant a bit up, well. So even though Bluetooth is not perfect, Bluetooth Low Energy, it's really the best technology that we have in all smartphones or all recent smartphones. And with this, we can build exposure notifications. So, yeah, even though Bluetooth might not be optimal, it is still a winner. Yeah, yeah, yeah, I know Bluetooth is dangerous and so on, so let's discuss this a little bit. So actually during 2020, a lot of newspapers were trying to reach me and said, like: "Hey, jiska, you have been working on Bluetooth security, so please, please tell us how bad the current state of Bluetooth security is." And I was like, yeah, I don't really want to tell this because, you know, Bluetooth is a wireless protocol that transmits data and that has certain risks, but so has everything else. So, yeah. And then they didn't print this. I mean, it's really not a nice headline to print, "Bluetooth is a wireless protocol that transmits data." Yeah. And then they were like: "You know, I'm not using the exposure notifications because I'm using an outdated smartphone that does no longer receive security updates." And then I'm like, huh yeah. So I mean, no security updates - that's not just an issue for Bluetooth. That's an issue for everything, like if you browse unicorn pictures on the Internet or receive mail, So I don't know what, maybe just get a new smartphone if you're very concerned about the data on your smartphone. And also something that you shouldn't do to a journalist when they ask you this, is tell them: "So you have an outdated smartphone? Are you just calling from a number that belongs to the smartphone?" But, yeah. So just don't discuss this because it's a very general issue that's not specific to Bluetooth. And something that's a bit more specific to Bluetooth is that, well, you can build worm swifties. So a device can be a master or a slave in the Bluetooth terminology. And so a master can connect to slaves, and a smartphone can switch roles, which means that it can receive a worm and then become the master and transmit of worm to another slave and the slave then becomes a master and so on. So it's wormable. But to have a very good worm, you would actually need an exploit that runs on a recent iOS and a recent Android version and that is very reliable, so it should be a very good exploit on all platforms. And if someone had such an exploit, they would probably not use it to destroy exposure notifications, but they would sell it for the price that is currently available on the market. The highest price, of course, because probably you don't have that many ethical concerns, instead of reporting it. But, yeah. So that would be more of the scenario here. Then also people say: "I turn my Bluetooth off because Bluetooth drains battery". But, you know, Bluetooth doesn't drain a lot of battery, especially Bluetooth Low Energy. So Bluetooth Low Energy is a technology that can power even small devices like item finders of this size. So if you have a battery, button cell of this size and then have like a device, slightly larger, like a Bluetooth Finder, of this size, they can run with this button cell for a year. And you charge your smartphone daily, your smartphone has much more battery capacity than just one button cell. So, yeah, go for it. It really doesn't drain battery, especially because you also have combo chips and if you have Wi-Fi enabled, then Bluetooth really doesn't add anything to this. Another argument might be that Google and Apple are always stealing our data, and if they now do the contact tracing, this means that they are stealing data. But in fact, the exposure notification API was renamed because it really is just about exposure notifications. It's not about a contact log. And this means that this API is not collecting any data about your contact trace and well, it's good and bad in terms of, they are preventing a centralized collection by everyone. So not just by health authorities, they just prevent it by everyone and including themselves. So there is just no data collection. So you cannot complain about this. So, yeah, after saying this, you might ask me if I had now just said like that Bluetooth is not dangerous at all. But, you know, Bluetooth is still a wireless protocol that transmits data. So, yeah, maybe it's still somewhat dangerous. So if you look at the Apple ecosystem, what you have is a feature set called Continuity Framework and this does a lot of things like some copy-paste AirDrop hand-off, whatsoever. So data that's being exchanged. And all of this continuity part here, it all works with BLE advertisements and then actually Wi-Fi or AWDL for the data transfer. So you have a lot of BLE advertisements going on if you already are using iOS and other Apple devices. And exposure notifications - they really are just a tiny additional thing here. So it's just yet another feature that's based on BLE advertisements. So it's nothing that adds a lot. And you also need to know that the exposure notifications don't have a lot of logic, so you just receive them, you don't answer to them and so on. So it's, really, a very harmless feature on top, compared to the other services running. Now, let's look into an Android example, which is a recent Bluetooth exploit. So bugs like this exist, and this is not just specific to Android, it can also be on iOS and it's also not specific to Bluetooth because we have bugs all the time. So if you are using software, if you are not updating it, there might be bugs in it or there might also be bugs in it that have not been seen for a while. So despite they should have been fixed and so on. So this just exists whenever you're using software. And also those bugs often depend on certain hardware and software versions. So, for example, this exploit only works on Android 9 and older because it requires a very specific implementation of memcopy, because the memcopy is called with an length argument of -2, and it has different behavior on different systems. And last but not least what this exploit actually needs to run for something like 2 min because you need to bypass ASLR over of the air. So you need to be in proximity of a vulnerable device for a while if you are an attacker. And now people say: "Yeah, but it's special because this kind of bug, it's wormable". Yeah, that's true. So you could build a Bluetooth worm with this, but what does it look like? So first of all, the devices are losing connection. So you don't have a full mesh, but you have like some connections here and there and you have a worm spreading somewhere and so on and so forth. But the attacker actually needs some control server. So no matter what the attacker wants to achieve, like steal data or do some Bitcoin mining or something, in the end you need to have some feedback and control server in the Internet to have a communication or also if something goes wrong with your exploit to stop it or something, you need this back channel, despite you have a wireless channel because your wireless channel is not permanent. And the next challenge here is that your exploit needs to be very reliable, so it means that if you actually produce a crash and if you have a worm that spreads very fast and that spreads a lot, then you have the problem that if it's not 100% reliable, you would get crashes and that are reported to Apple or to Google. And this is an issue because once a bug is detected, it means that Apple and Google will update their operating system and your bug is gone. So all your exploit development was just for nothing, your exploit is gone. And well, that actually means that if an attacker would want to build a worm, they would probably just use some outdated bug. And as I said, bugs happen so they are there every few months or years, it depends. You would have a bug that works for a worm and then the attacker does not have the risk of losing a very, like, unique bug that is worth a lot of money if they use an old one. But it also means that all the devices that get updates are safe from this worm. So it really depends on what the attacker wants to do. So what I think is more likely so instead of building a worm - what are attack scenarios? Well, if you think about Bluetooth exploits, the worm needs a lot of reliability and so on. And you have this risk of losing the exploit. So probably the attacks are a bit more targeted and require the physical proximity of those targets. So stuff that I would say is very realistic would be like if you have some airport security check or if, like an attacker is close to certain buildings, like company buildings or your home or something, to steal certain secrets or also from the government, if there are protests and the government does not want them or wants the identities of the protesters or something, this would be an option. But the worm, as I said, is, yeah, a bit, let's say, not so plausible. And the next thing is so exploit development means that if you want to develop and exploit for recent iOS and Android, then this is a lot of work and well, your enemy might be able to afford this. And in this case, they can also use it multiple times for as long as the bug does not leak and it's not fixed, they can reuse to exploit. So it's a one time development cost. But if you think you have enemies like this, then probably use a separate smartphone for exposure notifications and keep your smartphone up to date and so on. Or if you are very, very, very afraid of attacks and maybe just don't use a smartphone because Bluetooth is really not the only way to hijack your smartphone. So you could still be attacked just by a messengers, browsers, other wireless technologies, like LTE, and so on. So it's just a risk that you have and that happens. And that's not specific to Bluetooth. Anyway, let's go to a few implementation specific details, so if you want to understand the exploitation background and why I think that the Bluetooth Exposure Notification API, as it is, is very secure. So first of all, the API does Bluetooth address randomization, so that means these addresses are randomized and not connectable and you cannot connect to them as an attacker. And also, there is no feedback channel because of this non-connectable property. And it means that usually your smartphone is configured in a way that it doesn't announce any connectable addresses, it only has these random addresses. And this is really hard for exploitations. So you need to know the correct address of a smartphone to send an exploit to it. And it's not send over the air. So you need to decode packets, for example, if you're in parallel listening to music or something, you could extract the address from this, but it's very hard to achieve this. And another part is, that especially Apple is tremendously restricting their Bluetooth interfaces. So smartphone apps cannot use Bluetooth for arbitrary features that are available within the Bluetooth specification. And this means, that this is good for your privacy. So, for example, it's hard to build something like a spy in your pocket on iOS because there it's hard to run an app in the background that does all the tracking via Bluetooth and so on. And the other way around it means that if there are apps that do exposure notifications or contact tracing and they are not based on the official API, actually these apps are very exploitable because they use active connections. They run in the foreground. They actually are logging stuff that should not be logged, so I probably don't do this and don't trust those apps that are not using the API. Another issue might be privacy. So first of all, there's a random identifier that stays the same for a while, but as I said, on iOS you have the Continuity framework and it does the same, so at least on Apple devices this really doesn't make a big difference. And if you think a bit broader than Apple. Well, first of all, there's the signal strength and if you compare this like to other technologies that are wireless, like Wi-Fi and LTE, there you also have signals with a signal strength and maybe changing addresses and so on. You can always triangulate signals. So if you don't want to be tracked, you would also need to disable Wi-Fi and LTE. Another very important part about the security assumptions is the server infrastructure, so there are two types of server infrastructure and first of all, you have one for the centralized approach, which is also known as contact tracing, and in the centralized approach the server knows everything. So the server knows who was in contact with whom and for how long. So, for example, Alice met Bob for 15 min, but also Alice met 10 other people on Tuesday or something so that they actually have a record log of who met whom. And now the server can actually tell specific people after someone got a positive test and so on, for how long this was, the server can still censor some of the information it sends out to specific persons, but it has a lot of information internally. So this means if this server is run by some governmental health authority, that all the users have to trust this authority, a lot, with their contact history. And the other approach are decentralized exposure notifications, so the server has a list of pseudonyms and positively tested users, but these are just pseudonyms, not the exact times and exposures. And everyone can download this list and compare it to a local list. So you just have a local list on your smartphone of who you met. And you can compare the lists with pseudonyms that are on the server. And this means that everyone could even opt-out to publish these pseudonyms. And you don't share your list to anyone. So why is this good or bad? Well, the governmental health authorities don't get any contact tracing info in the decentralized approach, and this might be an issue because this means that the government does not have any statistics about spreaders or effectiveness of the app. They cannot measure how much the app actually helped. They cannot measure how many infections were prevented by telling people to go into quarantine or to get a test and so on. But on the other hand, it means nobody is getting this data. So neither Apple nor Google nor governments, nobody is getting the data and there is no gain from attacking the servers because they don't have any private information. And there's also no privacy impact from using the app. And in the end, if you get a positive test, even then you can choose to not share the result if you think it's an issue to disclose your pseudonyms. And I mean, ideally, many people should share their result, but you don't have to. And I want to show you a few attacks on exposure notifications, because some people said, like exposure notifications are very, very, very insecure. So let's look into attacks that have been publicly discussed on those exposure notifications as they are implemented now. And please note that many of these attacks are not specific to Bluetooth, but they are specific to everything that's somehow wireless and somehow a notification. So let's look. Let's take a look. So the time machine attack. This one is quite interesting. The assumption here is that someone can change the time on your smartphone and then replay outdated tokens, so that you would think, like you met pseudonyms in the past that were already known to be tested positive and because your smartphone also is in the past, it would accept those tokens and log them and then if you compare them to the server later on, you think that you were positive, in contact with positive users and so on. But please note that spoofing time is very, very hard. So if someone can spoof time, it means they can also break other things like TLS. And I mean, if I had a time machine and I would just travel back to a time prior to 2020 or something, instead of faking a few exposure notifications. The next attack is the wormhole attack. So imagine that like this one would be one shopping center, then another shopping center and maybe up there a police station or something like this. How does that work? Well, if you wormhole them and put them together, then the chance of getting positive exposure notification in the end is very high. So you increase the chance of having positive exposure. And this exposure, of course, was not real. So it's forwarded exposure. And because of this, in the worst case, you would do more physical distancing, more testing, maybe you also start to distrust the app a little bit, but it doesn't really harm the overall system. So the amount of record on the server with the positive tests, it's not increased because, only confirmed positive cases are uploaded to the pseudonym list and those who are just here and get a notification are not uploaded. And also to have such a deployment so to have this wormhole and the wormhole that scales, you need a lot of devices that forward the notifications and in public spaces so it's not that easy to implement this. The last attack is the identity tracking attack, so let's say you have those pseudonyms. The pseudonyms, they change over time and you are moving through a city and there are multiple devices that are observing your pseudonym changes. So, of course, you can then start tracking users. This, again, requires a very large scale installation. And the issue is also that if you are scared of this type of attack, then you would also need to disable Wi-Fi and LTE and so on, because you can always triangulate signals. So ideally, if you don't want to be tracked, turn off wireless technology, this is really not specific to Bluetooth at all. So, yeah, all those attacks, they are valid, but to deploy them, like, to have records of exposure notifications that you can then replay with time travel or a wormhole or also some tracing of IDs, you really need a large scale installation of something like Raspberry Pis throughout a city and many, many, many devices. So this would also work in any other wireless ecosystem. But OK, but if you would roll out such an installation, also, keep in mind that you could instead just deploy something like a lot of devices that have microphones or cameras and Wi-Fi and so on and track a lot of other things. This needs to happen in public spaces, so I don't know, next to bus stations, shopping centers and so on. And well, if you have such an installation, then really just tampering with exposure notifications of Bluetooth is not your main concern. The sad reality might actually be that we already have a lot of surveillance everywhere, so we have a lot of cameras in public spaces. So this is not the part that I would be afraid of. I mean, I would be afraid of public surveillance, obviously, but not about Bluetooth surveillance in particular. So let me conclude my talk. The BLE advertisements are really the most suitable technology that we have in a smartphone to implement exposure notifications, and they are available on recent smartphones, on iOS and Android. They are very secure, privacy preserving, battery friendly, and also scalable. And, keep in mind, every prevented infection saves lives and also prevents long term disease. So this is really a thing to use, even if it does not work 100%. And with this, let's start the Q&A and discuss whatever you like, Bluetooth worms and so on. Thanks for listening. Herald: All right, thank you, jiska, for your talk. I hope you have time for some Q&A. J: Yeah, let's go. H: Awesome. J: Oh, I think that was Ollies Internet connection, was it? Yeah. So I might just decide on my own until he reconnects. Ah, here you are! H: I'm so sorry. The question was why would the angle of arrival be interesting for an attacker or J: Not for, for an attacker. But like from the technology, it would be interesting to have it in Bluetooth because then you could do some direction estimation. And I mean, if people move, you could also get a direction and maybe location via this or assist this. But yeah, I mean, it's not in any chip yet except from some evaluation kits. H: All right. Thank you. Is there any studies that proves or disproves the efficiency of contract tracing apps in general? I mean, like the use case? J: I mean, the issue is because we have the exposure notification framework that we do not have any statistics. So the good and the bad thing about privacy is that we cannot have such a study except from if people would provide their data in, I don't know, a questionnaire or something. But at least I know people who have been warned by the app and got the test and so on. So it seems to work from the people I know. Yeah. And I mean, every life that it saves counts in the end. So, I mean, nothing is perfect, right? H: True very much. Thanks for your answer. But user triplefive would like to know: "Why would you think the accelerometer would be a data privacy issue, isn't it up to how the sensor data is processed, i.e. stays on the device, is not stored and so on and so forth." J: Yeah, of course. But I mean, once you give that permission to the app, you need to trust the app, which is first of all a binary that you download. I mean, maybe it's open source like our German app, but you never know. And then it could process this data. And actually from an accelerometer, there have been studies that you not can just, like, do step counts, but even stuff like someone turned to the left, to the right, and from this, if you have an overlay to a map, you can even reconstruct the path that you moved through a city, for example. So that's a big issue, I think. H: Alright. Thank you. There's one more question here. Have any of the theoretical or possible exploits been tried in practice? To the best of your knowledge, that is? J: To my knowledge, not. I mean, I think it would only be visible once someone does such an attack, large scale, and then they need to manage to have a large deployment of such an attack without being caught. So, yeah, nobody did this so far. Yeah. H: OK, makes sense. And there's one person who had a comment. They pointed out that there is an open implementation for the framework if the user wants to go without Google or Apple at all and still take part in exposure notifications. I think it's a fairly recent development. J: Yeah, exactly. So I had my slides already finished when that came out. So it's on the F-Droid store and it uses, I think, yeah, just like an open source implementation so that you can now use it even on your Lineage phone for example. H: OK, thank you. J: OK, any further questions? H: Yeah, one last question just bumped in here, surfaced over there. Has anyone tried to crack the verification server by brute force? The person asking did a back on the envelope calculation, back in time. And it seemed possible to just try out all possible Tele-TANs at some point. J: All possible Tele-TANs, I mean, so that would be like really a brute force that you see in the back-end, right? So that's something that you can't just rate limit. And that's probably the only thing that you can brute force because all the comparison and so on is done locally on the smartphone. So the TANs would be the only weak point in the system. And if someone tries to brute force all TANs that, yeah, it's a very obvious attack. H: You know, makes sense. All right. Thanks a lot for the talk. Thank you for your patience in answering all the questions. I believe that's actually our time slot exactly. And with that, I hand over to the news show from Dublin this time. Thanks a lot. postroll music Subtitles created by c3subtitles.de in the year 2020. Join, and help us!