0:00:00.000,0:00:16.720
RC3 preroll music
0:00:16.720,0:00:19.670
Jiska: Hello, everyone, and welcome to my[br]talk, which is about Bluetooth exposure
0:00:19.670,0:00:25.470
notification security. This talk could[br]also be summarized as follows: So first of
0:00:25.470,0:00:30.720
all, exposure notifications as in the[br]Google/Apple API are very secure and
0:00:30.720,0:00:36.190
battery friendly. And please, just use the[br]Corona Warn App. This might be very
0:00:36.190,0:00:39.420
confusing to most of you, who are[br]listening and know me since a while
0:00:39.420,0:00:43.710
because I have been working on Bluetooth[br]exploitation in the past and always
0:00:43.710,0:00:47.710
thought everyone, like, Bluetooth is[br]insecure. So you might wonder: How does
0:00:47.710,0:00:53.127
this align? Why am I now here telling you[br]that Bluetooth exposure notifications are
0:00:53.127,0:00:59.860
secure? So well it's a pandemic, so[br]instead of just criticizing solutions, we
0:00:59.860,0:01:06.170
should also look for solutions that work.[br]So instead of ranting, work on something
0:01:06.170,0:01:14.790
that helps everyone! So the first question[br]that many people asks are, do we even need
0:01:14.790,0:01:21.750
a smartphone app to fight a pandemic? What[br]we can say, well, it's December exposure
0:01:21.750,0:01:26.063
notifications were introduced in June and[br]we still have Corona, it still exists. So
0:01:26.063,0:01:35.379
it didn't help to fully fight them and[br]probably it won't stop Corona. But let's
0:01:35.379,0:01:41.340
look at this from another perspective. So[br]first of all, if you have an app and get
0:01:41.340,0:01:45.859
the warnings, we can do more accurate[br]testing and that's very important because
0:01:45.859,0:01:50.820
even now we are still low on tests. We[br]cannot test everyone. We only test people
0:01:50.820,0:01:56.840
with symptoms. And that's really an issue[br]because people can, infect other people
0:01:56.840,0:02:01.789
prior to symptoms and they could even[br]infect others without having symptoms or
0:02:01.789,0:02:07.569
they're asymptomatic cases. And these can[br]be found with the Corona Warn App. And
0:02:07.569,0:02:11.470
also this can encourage manual contact[br]tracing because official health
0:02:11.470,0:02:17.310
authorities, they are not able to make[br]physical, manual contact tracing any more.
0:02:17.310,0:02:22.860
So you need to ask your friends and so on[br]if your app turns red, and then you might
0:02:22.860,0:02:28.280
find cases, even if they forgot to tell[br]you. Of course, this all doesn't replace
0:02:28.280,0:02:33.790
washing your hands, wearing a mask,[br]physically distancing and so on. So, of
0:02:33.790,0:02:39.970
course, you still need to take these[br]measures. But even if you just inform a
0:02:39.970,0:02:44.739
few people, every prevented infection[br]actually saves lives. So it's very
0:02:44.739,0:02:53.070
important to have an app like this. And[br]the next question is, well, is there
0:02:53.070,0:02:57.110
something better than Bluetooth? So if we[br]want to look for a solution to build an
0:02:57.110,0:03:03.410
app that supports exposure notifications[br]and prevent infections, how could we build
0:03:03.410,0:03:09.730
it? So we actually need something that[br]somehow measures proximity or location and
0:03:09.730,0:03:13.940
in a smartphone, we have various[br]technologies that support that. So there
0:03:13.940,0:03:19.571
is GPS, there's Bluetooth, there's LTE and[br]5G, there's Wi-Fi, there is Ultra-
0:03:19.571,0:03:23.620
wideband, you probably never heard of[br]this. There's audio. There is a camera.
0:03:23.620,0:03:31.260
You could use all of this. And the reason[br]why you can use this to measure a distance
0:03:31.260,0:03:36.980
or a direction is that on the physical[br]layer you have a wave form. And this wave
0:03:36.980,0:03:41.540
form, first of all, has an amplitude and[br]with the distance, this amplitude gets
0:03:41.540,0:03:45.230
lower. So this also means that the signal[br]strength is lower and you also have a
0:03:45.230,0:03:49.651
phase that is changing with the distance.[br]So these are properties that you can
0:03:49.651,0:03:54.120
measure on the physical layer, on a raw[br]wave form. And some of this information is
0:03:54.120,0:04:00.070
also sent to upper layers. And the most[br]obvious one is the signal strength, so
0:04:00.070,0:04:04.260
it's a physical layer property that you[br]can measure, and it's also sent to the
0:04:04.260,0:04:10.320
upper layers on most protocols for simple[br]things like determining how strong the WiFi
0:04:10.320,0:04:14.540
is, so that your device can actually[br]pick the strongest Wi-Fi access point and
0:04:14.540,0:04:19.139
so on. So the signal strength is very[br]essential and sent to upper layers in most
0:04:19.139,0:04:25.479
protocols. You could actually even do a[br]precise distance measurement, but for
0:04:25.479,0:04:30.240
this, you need the raw wave form and[br]that's not supported by most chips. There
0:04:30.240,0:04:34.460
are a few chips that can do that. So for[br]the precise distance measurement, you
0:04:34.460,0:04:39.080
actually need to send a signal and send it[br]back and measure the round trip time of
0:04:39.080,0:04:43.800
this signal. And this is, for example,[br]done to determine if your Apple Watch can
0:04:43.800,0:04:49.289
unlock your MacBook. And the third option[br]is that you can even measure a signal
0:04:49.289,0:04:53.939
direction. This actually needs multiple[br]antennas to do some sort of triangulation
0:04:53.939,0:04:59.460
of the signal. And this is not supported[br]by most chips because you not just need
0:04:59.460,0:05:03.930
the support in the chip, but also the[br]multiple antennas. But with this, you can,
0:05:03.930,0:05:09.199
for example, do things like on some[br]iPhones, you'll get some AirDrop direction
0:05:09.199,0:05:14.349
of the other iPhone and so on, so you can[br]have a direction shown on your device, of
0:05:14.349,0:05:21.770
a signal. When it comes to location, the[br]most obvious choice for many people, or
0:05:21.770,0:05:27.120
the intuitive choice, would be GPS and[br]GPS, well, the signals are sent by
0:05:27.120,0:05:32.300
satellites and they orbit earth at more[br]than 20.000 km, so they are, like, very,
0:05:32.300,0:05:36.680
very distanced. And until the signal[br]arrives on your smartphone, there is a lot
0:05:36.680,0:05:42.360
of attenuation. So even if there are,[br]like, just a few buildings or if you are
0:05:42.360,0:05:45.960
indoors or something, but already a few[br]buildings are sufficient to make the
0:05:45.960,0:05:52.099
location imprecise and indoors, it doesn't[br]work at all. But indoors we have the
0:05:52.099,0:06:01.360
highest risk of infections. So GPS is not[br]really helpful here. The next option would
0:06:01.360,0:06:08.979
be signals from LTE, 5G and so on. So here[br]you have some senders and you actually
0:06:08.979,0:06:13.590
change cells with your smartphone. So,[br]here we have one cell and while you move,
0:06:13.590,0:06:18.889
you move to another cell and this is some[br]movement that you do and you can measure
0:06:18.889,0:06:25.020
the changes between the cells. And this[br]actually has been used by phone providers
0:06:25.020,0:06:30.300
in Germany to determine how effective the[br]lockdown rules are. So with this, you can
0:06:30.300,0:06:36.931
actually see if people move more or less[br]than prior to the pandemic and so on, or
0:06:36.931,0:06:41.400
how effective the rules are and so on.[br]These are not very precise statistics, so
0:06:41.400,0:06:49.650
this is nice to have those very broad[br]statistic for a lot of people, but it's
0:06:49.650,0:06:59.969
not useful to determine who you were[br]meeting. And another option is Wi-Fi, but
0:06:59.969,0:07:05.309
for Wi-Fi you have another issue. So Wi-[br]Fis depend on access points and so on, and
0:07:05.309,0:07:09.559
you can scan for access points. And of[br]course, most smartphones also support,
0:07:09.559,0:07:13.759
that you spawn your own Wi-Fi access[br]point. and then you could scan for this,
0:07:13.759,0:07:18.259
but then you can no longer use your Wi-Fi[br]because you can only join one Wi-Fi or
0:07:18.259,0:07:24.309
spawn one Wi-Fi access point and so on.[br]And this really doesn't work. There are
0:07:24.309,0:07:28.469
some vendor specific additions that would[br]allow distance measurement, but it's not
0:07:28.469,0:07:33.999
in most devices, it's not accessible[br]through APIs and stuff like this. So you
0:07:33.999,0:07:41.169
cannot use Wi-Fi because of how it works[br]and how it is build into smartphones. The
0:07:41.169,0:07:45.439
best option for precise measurement is[br]audio, because even if you don't have
0:07:45.439,0:07:52.949
access to the chip or any API, what you[br]have here is that you have a sender or
0:07:52.949,0:07:58.879
like a speaker and microphone and they[br]send a wave and you can measure this wave.
0:07:58.879,0:08:04.479
So even without any lower layer access to[br]some firmware, to some chip, you can have
0:08:04.479,0:08:09.379
this very precise measurement. But here[br]the issue is that it means that you need
0:08:09.379,0:08:13.960
access to the microphone. So an app would[br]need to run and foreground with a
0:08:13.960,0:08:18.069
microphone all the time. This drains[br]battery and even worse, it means that you
0:08:18.069,0:08:21.770
have a permanent spy in your pocket. So[br]you have a governmental app that would
0:08:21.770,0:08:28.409
listen to your microphone all the time.[br]And many people don't want this. Then
0:08:28.409,0:08:31.770
there is some option that you probably[br]have never heard of, Ultra-wideband, so
0:08:31.770,0:08:36.450
that's coming to the newest generation of[br]iPhones and so far it's not used for many
0:08:36.450,0:08:40.850
features. It's just something that can[br]also determine the direction of signal
0:08:40.850,0:08:46.040
because it's using multiple antennas and,[br]so it can show you in which direction
0:08:46.040,0:08:51.180
another devices is. But since it's only in[br]a few devices, it's nothing that's useful
0:08:51.180,0:08:56.440
for the general public. So it's a nice[br]feature, but we are just a few years too
0:08:56.440,0:09:03.190
early for it. And of course, you could use[br]a camera similar to the microphones, you
0:09:03.190,0:09:08.060
could, of course, record everything with[br]the camera, but that's probably not the
0:09:08.060,0:09:13.880
solution that you want. So more likely you[br]could actually use it to lock into
0:09:13.880,0:09:19.140
locations. So you scan a QR code and then[br]register that you are in a restaurant or
0:09:19.140,0:09:23.710
that you are meeting friends. So this is[br]what the camera ideally should be used for
0:09:23.710,0:09:31.580
and that would be a nice addition to the[br]warning apps. And what's left, well, there
0:09:31.580,0:09:38.380
is Bluetooth. Bluetooth actually sends[br]signals at 2.4 GHz, like Wi-Fi , and 2.4
0:09:38.380,0:09:44.600
GHz has a very big issue because it's[br]attenuated by water and humans are 60%
0:09:44.600,0:09:51.590
water. So the measurement is a bit[br]imprecise. But I mean, 40% of the human
0:09:51.590,0:09:55.910
are stupidity. And that's also an issue[br]because humans are not using the Corona
0:09:55.910,0:10:02.910
Warn App at all. That's even worse. And[br]what else is there? The next issue is that
0:10:02.910,0:10:08.160
the chips vary and the antenna position[br]varies and so on. So you actually have the
0:10:08.160,0:10:12.780
issue that the measurements are not the[br]same on each smartphone model. So it might
0:10:12.780,0:10:18.820
be the same signal, but different[br]measurement. And for this first issue with
0:10:18.820,0:10:23.090
the different measurements of the same[br]signal, we already have something that's
0:10:23.090,0:10:29.240
built into the API, the official[br]Google/Apple API, and they include the
0:10:29.240,0:10:37.380
transmit power per device model and so on,[br]which is a slight risk for privacy. But
0:10:37.380,0:10:44.880
overall, it has a very good compensation[br]here. So, they said that this is better to
0:10:44.880,0:10:49.120
use and have a little bit less privacy.[br]Something else that you could use are
0:10:49.120,0:10:54.854
active data connections over time to track[br]the average signal strength. But that's
0:10:54.854,0:10:58.570
worse because the active data connection[br]means that you have data that's being
0:10:58.570,0:11:05.790
exchanged between two devices and this is[br]a risk for exploitations. So exploits need
0:11:05.790,0:11:11.900
some exchange of data and this would be a[br]risk for security. And another thing that
0:11:11.900,0:11:17.060
you could add is the accelerometer. So[br]depending on how you hold your smartphone,
0:11:17.060,0:11:19.971
you can actually determine, by the[br]accelerometer, if it's in your hand, in
0:11:19.971,0:11:24.990
your pocket and so on, and then compensate[br]for this in the measurements. But the
0:11:24.990,0:11:30.864
issue here is that the accelerometer also[br]is able to determine if you are running,
0:11:30.864,0:11:35.590
walking, how many steps you're walking and[br]so on. So it's a huge privacy impact to
0:11:35.590,0:11:42.920
access the accelerometer. And last but not[br]least, there's the angle of arrival, and
0:11:42.920,0:11:47.940
that's something that's supported since[br]Bluetooth 5.1 but it's an optional feature
0:11:47.940,0:11:52.060
in the Bluetooth specification, so no[br]smartphone has it yet. So you cannot
0:11:52.060,0:11:59.100
actually do a specific measurement of the[br]angle of another device. So that's pretty
0:11:59.100,0:12:05.120
sad. And, well. So everything that[br]improves those measurements on Bluetooth
0:12:05.120,0:12:12.240
is always at the cost of privacy, security[br]and battery life. So just considering how
0:12:12.240,0:12:19.030
it's currently done in the API, it's[br]pretty good. And to sum this technology
0:12:19.030,0:12:23.670
rant a bit up, well. So even though[br]Bluetooth is not perfect, Bluetooth Low
0:12:23.670,0:12:27.620
Energy, it's really the best technology[br]that we have in all smartphones or all
0:12:27.620,0:12:34.261
recent smartphones. And with this, we can[br]build exposure notifications. So, yeah,
0:12:34.261,0:12:41.870
even though Bluetooth might not be[br]optimal, it is still a winner. Yeah, yeah,
0:12:41.870,0:12:47.394
yeah, I know Bluetooth is dangerous and so[br]on, so let's discuss this a little bit. So
0:12:47.394,0:12:52.520
actually during 2020, a lot of newspapers[br]were trying to reach me and said, like:
0:12:52.520,0:12:56.530
"Hey, jiska, you have been working on[br]Bluetooth security, so please, please tell
0:12:56.530,0:13:01.190
us how bad the current state of Bluetooth[br]security is." And I was like, yeah, I
0:13:01.190,0:13:05.500
don't really want to tell this because,[br]you know, Bluetooth is a wireless protocol
0:13:05.500,0:13:11.660
that transmits data and that has certain[br]risks, but so has everything else. So,
0:13:11.660,0:13:15.300
yeah. And then they didn't print this. I[br]mean, it's really not a nice headline to
0:13:15.300,0:13:21.154
print, "Bluetooth is a wireless protocol[br]that transmits data." Yeah. And then they
0:13:21.154,0:13:25.970
were like: "You know, I'm not using the[br]exposure notifications because I'm using
0:13:25.970,0:13:30.670
an outdated smartphone that does no longer[br]receive security updates." And then I'm
0:13:30.670,0:13:35.010
like, huh yeah. So I mean, no security[br]updates - that's not just an issue for
0:13:35.010,0:13:39.180
Bluetooth. That's an issue for everything,[br]like if you browse unicorn pictures on the
0:13:39.180,0:13:45.920
Internet or receive mail, So I don't know[br]what, maybe just get a new smartphone if
0:13:45.920,0:13:50.570
you're very concerned about the data on[br]your smartphone. And also something that
0:13:50.570,0:13:55.330
you shouldn't do to a journalist when they[br]ask you this, is tell them: "So you have
0:13:55.330,0:13:59.390
an outdated smartphone? Are you just[br]calling from a number that belongs to the
0:13:59.390,0:14:07.400
smartphone?" But, yeah. So just don't[br]discuss this because it's a very general
0:14:07.400,0:14:14.050
issue that's not specific to Bluetooth.[br]And something that's a bit more specific
0:14:14.050,0:14:20.241
to Bluetooth is that, well, you can build[br]worm swifties. So a device can be a
0:14:20.241,0:14:27.140
master or a slave in the Bluetooth[br]terminology. And so a master can connect
0:14:27.140,0:14:32.490
to slaves, and a smartphone can switch[br]roles, which means that it can receive a
0:14:32.490,0:14:36.050
worm and then become the master and[br]transmit of worm to another slave and the
0:14:36.050,0:14:41.950
slave then becomes a master and so on. So[br]it's wormable. But to have a very good
0:14:41.950,0:14:46.727
worm, you would actually need an exploit[br]that runs on a recent iOS and a recent
0:14:46.727,0:14:52.600
Android version and that is very reliable,[br]so it should be a very good exploit on all
0:14:52.600,0:14:57.790
platforms. And if someone had such an[br]exploit, they would probably not use it to
0:14:57.790,0:15:02.870
destroy exposure notifications, but they[br]would sell it for the price that is
0:15:02.870,0:15:06.910
currently available on the market. The[br]highest price, of course, because probably
0:15:06.910,0:15:13.440
you don't have that many ethical concerns,[br]instead of reporting it. But, yeah. So
0:15:13.440,0:15:19.950
that would be more of the scenario here.[br]Then also people say: "I turn my Bluetooth
0:15:19.950,0:15:24.230
off because Bluetooth drains battery".[br]But, you know, Bluetooth doesn't drain a
0:15:24.230,0:15:28.420
lot of battery, especially Bluetooth Low[br]Energy. So Bluetooth Low Energy is a
0:15:28.420,0:15:36.120
technology that can power even small[br]devices like item finders of this size. So
0:15:36.120,0:15:41.510
if you have a battery, button cell of this[br]size and then have like a device, slightly
0:15:41.510,0:15:46.590
larger, like a Bluetooth Finder, of this[br]size, they can run with this button cell
0:15:46.590,0:15:51.190
for a year. And you charge your smartphone[br]daily, your smartphone has much more
0:15:51.190,0:15:57.280
battery capacity than just one button[br]cell. So, yeah, go for it. It really
0:15:57.280,0:16:01.540
doesn't drain battery, especially because[br]you also have combo chips and if you have
0:16:01.540,0:16:08.150
Wi-Fi enabled, then Bluetooth really[br]doesn't add anything to this. Another
0:16:08.150,0:16:12.681
argument might be that Google and Apple[br]are always stealing our data, and if they
0:16:12.681,0:16:17.750
now do the contact tracing, this means[br]that they are stealing data. But in fact,
0:16:17.750,0:16:22.900
the exposure notification API was renamed[br]because it really is just about exposure
0:16:22.900,0:16:28.150
notifications. It's not about a contact[br]log. And this means that this API is not
0:16:28.150,0:16:34.970
collecting any data about your contact[br]trace and well, it's good and bad in terms
0:16:34.970,0:16:39.710
of, they are preventing a centralized[br]collection by everyone. So not just by
0:16:39.710,0:16:43.750
health authorities, they just prevent it[br]by everyone and including themselves. So
0:16:43.750,0:16:52.799
there is just no data collection. So you[br]cannot complain about this. So, yeah,
0:16:52.799,0:16:58.730
after saying this, you might ask me if I[br]had now just said like that Bluetooth is
0:16:58.730,0:17:03.960
not dangerous at all. But, you know,[br]Bluetooth is still a wireless protocol
0:17:03.960,0:17:14.669
that transmits data. So, yeah, maybe it's[br]still somewhat dangerous. So if you look
0:17:14.669,0:17:20.949
at the Apple ecosystem, what you have is a[br]feature set called Continuity Framework
0:17:20.949,0:17:26.120
and this does a lot of things like some[br]copy-paste AirDrop hand-off, whatsoever.
0:17:26.120,0:17:32.929
So data that's being exchanged. And all of[br]this continuity part here, it all works
0:17:32.929,0:17:40.580
with BLE advertisements and then actually[br]Wi-Fi or AWDL for the data transfer. So
0:17:40.580,0:17:45.990
you have a lot of BLE advertisements going[br]on if you already are using iOS and other
0:17:45.990,0:17:51.440
Apple devices. And exposure notifications[br]- they really are just a tiny additional
0:17:51.440,0:17:55.419
thing here. So it's just yet another[br]feature that's based on BLE
0:17:55.419,0:18:03.759
advertisements. So it's nothing that adds[br]a lot. And you also need to know that the
0:18:03.759,0:18:07.919
exposure notifications don't have a lot of[br]logic, so you just receive them, you don't
0:18:07.919,0:18:12.720
answer to them and so on. So it's, really,[br]a very harmless feature on top, compared
0:18:12.720,0:18:19.360
to the other services running. Now, let's[br]look into an Android example, which is a
0:18:19.360,0:18:26.029
recent Bluetooth exploit. So bugs like[br]this exist, and this is not just specific
0:18:26.029,0:18:31.019
to Android, it can also be on iOS and it's[br]also not specific to Bluetooth because we
0:18:31.019,0:18:36.110
have bugs all the time. So if you are[br]using software, if you are not updating
0:18:36.110,0:18:40.340
it, there might be bugs in it or there[br]might also be bugs in it that have not
0:18:40.340,0:18:46.820
been seen for a while. So despite they[br]should have been fixed and so on. So this
0:18:46.820,0:18:52.450
just exists whenever you're using[br]software. And also those bugs often depend
0:18:52.450,0:18:57.320
on certain hardware and software versions.[br]So, for example, this exploit only works
0:18:57.320,0:19:02.940
on Android 9 and older because it requires[br]a very specific implementation of memcopy,
0:19:02.940,0:19:08.080
because the memcopy is called with an[br]length argument of -2, and it has
0:19:08.080,0:19:14.330
different behavior on different systems.[br]And last but not least what this exploit
0:19:14.330,0:19:19.929
actually needs to run for something like 2[br]min because you need to bypass ASLR over
0:19:19.929,0:19:25.081
of the air. So you need to be in proximity[br]of a vulnerable device for a while if you
0:19:25.081,0:19:32.210
are an attacker. And now people say:[br]"Yeah, but it's special because this kind
0:19:32.210,0:19:36.309
of bug, it's wormable". Yeah, that's[br]true. So you could build a Bluetooth worm
0:19:36.309,0:19:41.380
with this, but what does it look like? So[br]first of all, the devices are losing
0:19:41.380,0:19:46.570
connection. So you don't have a full mesh,[br]but you have like some connections here
0:19:46.570,0:19:51.390
and there and you have a worm spreading[br]somewhere and so on and so forth. But the
0:19:51.390,0:19:54.520
attacker actually needs some control[br]server. So no matter what the attacker
0:19:54.520,0:20:00.840
wants to achieve, like steal data or do[br]some Bitcoin mining or something, in the
0:20:00.840,0:20:07.049
end you need to have some feedback and[br]control server in the Internet to have a
0:20:07.049,0:20:11.210
communication or also if something goes[br]wrong with your exploit to stop it or
0:20:11.210,0:20:15.750
something, you need this back channel,[br]despite you have a wireless channel
0:20:15.750,0:20:20.568
because your wireless channel is not[br]permanent. And the next challenge here is
0:20:20.568,0:20:28.740
that your exploit needs to be very[br]reliable, so it means that if you actually
0:20:28.740,0:20:32.419
produce a crash and if you have a worm[br]that spreads very fast and that spreads a
0:20:32.419,0:20:37.220
lot, then you have the problem that if[br]it's not 100% reliable, you would get
0:20:37.220,0:20:44.330
crashes and that are reported to Apple or[br]to Google. And this is an issue because
0:20:44.330,0:20:48.450
once a bug is detected, it means that[br]Apple and Google will update their
0:20:48.450,0:20:54.049
operating system and your bug is gone. So[br]all your exploit development was just for
0:20:54.049,0:21:00.179
nothing, your exploit is gone. And well,[br]that actually means that if an attacker
0:21:00.179,0:21:06.202
would want to build a worm, they would[br]probably just use some outdated bug. And
0:21:06.202,0:21:12.380
as I said, bugs happen so they are there[br]every few months or years, it depends. You
0:21:12.380,0:21:18.639
would have a bug that works for a worm and[br]then the attacker does not have the risk
0:21:18.639,0:21:26.330
of losing a very, like, unique bug that is[br]worth a lot of money if they use an old
0:21:26.330,0:21:30.029
one. But it also means that all the[br]devices that get updates are safe from
0:21:30.029,0:21:36.344
this worm. So it really depends on what[br]the attacker wants to do. So what I
0:21:36.344,0:21:40.810
think is more likely so instead of[br]building a worm - what are attack
0:21:40.810,0:21:45.830
scenarios? Well, if you think about[br]Bluetooth exploits, the worm needs a lot
0:21:45.830,0:21:52.238
of reliability and so on. And you have[br]this risk of losing the exploit. So
0:21:52.238,0:21:56.470
probably the attacks are a bit more[br]targeted and require the physical
0:21:56.470,0:22:02.320
proximity of those targets. So stuff that[br]I would say is very realistic would be
0:22:02.320,0:22:08.259
like if you have some airport security[br]check or if, like an attacker is close to
0:22:08.259,0:22:12.309
certain buildings, like company buildings[br]or your home or something, to steal
0:22:12.309,0:22:16.919
certain secrets or also from the[br]government, if there are protests and the
0:22:16.919,0:22:23.580
government does not want them or wants the[br]identities of the protesters or something,
0:22:23.580,0:22:35.059
this would be an option. But the worm, as[br]I said, is, yeah, a bit, let's say, not so
0:22:35.059,0:22:41.940
plausible. And the next thing is so[br]exploit development means that if you want
0:22:41.940,0:22:49.780
to develop and exploit for recent iOS and[br]Android, then this is a lot of work and
0:22:49.780,0:22:55.139
well, your enemy might be able to afford[br]this. And in this case, they can also use
0:22:55.139,0:22:59.529
it multiple times for as long as the bug[br]does not leak and it's not fixed, they can
0:22:59.529,0:23:05.440
reuse to exploit. So it's a one time[br]development cost. But if you think you
0:23:05.440,0:23:09.150
have enemies like this, then probably use[br]a separate smartphone for exposure
0:23:09.150,0:23:14.820
notifications and keep your smartphone up[br]to date and so on. Or if you are very,
0:23:14.820,0:23:18.720
very, very afraid of attacks and maybe just[br]don't use a smartphone because Bluetooth
0:23:18.720,0:23:24.149
is really not the only way to hijack your[br]smartphone. So you could still be attacked
0:23:24.149,0:23:28.659
just by a messengers, browsers, other[br]wireless technologies, like LTE, and so
0:23:28.659,0:23:34.460
on. So it's just a risk that you have and[br]that happens. And that's not specific to
0:23:34.460,0:23:43.230
Bluetooth. Anyway, let's go to a few[br]implementation specific details, so if you
0:23:43.230,0:23:47.830
want to understand the exploitation[br]background and why I think that the
0:23:47.830,0:23:55.299
Bluetooth Exposure Notification API, as it[br]is, is very secure. So first of all, the
0:23:55.299,0:24:00.690
API does Bluetooth address randomization,[br]so that means these addresses are
0:24:00.690,0:24:06.450
randomized and not connectable and you[br]cannot connect to them as an attacker. And
0:24:06.450,0:24:11.349
also, there is no feedback channel because[br]of this non-connectable property. And it
0:24:11.349,0:24:16.802
means that usually your smartphone is[br]configured in a way that it doesn't
0:24:16.802,0:24:22.559
announce any connectable addresses, it[br]only has these random addresses. And this
0:24:22.559,0:24:26.470
is really hard for exploitations. So you[br]need to know the correct address of a
0:24:26.470,0:24:32.169
smartphone to send an exploit to it. And[br]it's not send over the air. So you need to
0:24:32.169,0:24:36.470
decode packets, for example, if you're in[br]parallel listening to music or something,
0:24:36.470,0:24:43.360
you could extract the address from this,[br]but it's very hard to achieve this. And
0:24:43.360,0:24:47.639
another part is, that especially Apple is[br]tremendously restricting their Bluetooth
0:24:47.639,0:24:55.320
interfaces. So smartphone apps cannot use[br]Bluetooth for arbitrary features that are
0:24:55.320,0:25:02.989
available within the Bluetooth[br]specification. And this means, that this
0:25:02.989,0:25:08.650
is good for your privacy. So, for example,[br]it's hard to build something like a spy in
0:25:08.650,0:25:16.450
your pocket on iOS because there it's hard[br]to run an app in the background that does
0:25:16.450,0:25:22.200
all the tracking via Bluetooth and so on.[br]And the other way around it means that if
0:25:22.200,0:25:26.309
there are apps that do exposure[br]notifications or contact tracing and they
0:25:26.309,0:25:33.600
are not based on the official API,[br]actually these apps are very exploitable
0:25:33.600,0:25:40.779
because they use active connections. They[br]run in the foreground. They actually are
0:25:40.779,0:25:45.499
logging stuff that should not be logged,[br]so I probably don't do this and don't
0:25:45.499,0:25:53.554
trust those apps that are not using the[br]API. Another issue might be privacy. So
0:25:53.554,0:25:58.809
first of all, there's a random identifier[br]that stays the same for a while, but as I
0:25:58.809,0:26:02.600
said, on iOS you have the Continuity[br]framework and it does the same, so at
0:26:02.600,0:26:07.199
least on Apple devices this really doesn't[br]make a big difference. And if you think a
0:26:07.199,0:26:11.270
bit broader than Apple. Well, first of all,[br]there's the signal strength and if you
0:26:11.270,0:26:16.789
compare this like to other technologies[br]that are wireless, like Wi-Fi and LTE,
0:26:16.789,0:26:21.669
there you also have signals with a signal[br]strength and maybe changing addresses and
0:26:21.669,0:26:28.380
so on. You can always triangulate signals.[br]So if you don't want to be tracked, you
0:26:28.380,0:26:38.029
would also need to disable Wi-Fi and LTE.[br]Another very important part about the
0:26:38.029,0:26:42.019
security assumptions is the server[br]infrastructure, so there are two types of
0:26:42.019,0:26:46.629
server infrastructure and first of all,[br]you have one for the centralized approach,
0:26:46.629,0:26:50.410
which is also known as contact tracing,[br]and in the centralized approach the server
0:26:50.410,0:26:55.309
knows everything. So the server knows who[br]was in contact with whom and for how long.
0:26:55.309,0:27:00.430
So, for example, Alice met Bob for 15 min,[br]but also Alice met 10 other people on
0:27:00.430,0:27:09.409
Tuesday or something so that they actually[br]have a record log of who met whom. And now the
0:27:09.409,0:27:13.509
server can actually tell specific people[br]after someone got a positive test and so
0:27:13.509,0:27:20.170
on, for how long this was, the server can[br]still censor some of the information it
0:27:20.170,0:27:26.570
sends out to specific persons, but it has[br]a lot of information internally. So this
0:27:26.570,0:27:31.049
means if this server is run by some[br]governmental health authority, that all
0:27:31.049,0:27:39.459
the users have to trust this authority, a[br]lot, with their contact history. And the
0:27:39.459,0:27:44.820
other approach are decentralized exposure[br]notifications, so the server has a list of
0:27:44.820,0:27:51.509
pseudonyms and positively tested users,[br]but these are just pseudonyms, not the
0:27:51.509,0:27:56.230
exact times and exposures. And everyone[br]can download this list and compare it to a
0:27:56.230,0:28:00.330
local list. So you just have a local list[br]on your smartphone of who you met. And you
0:28:00.330,0:28:06.038
can compare the lists with pseudonyms that[br]are on the server. And this means that
0:28:06.038,0:28:11.659
everyone could even opt-out to publish[br]these pseudonyms. And you don't share your
0:28:11.659,0:28:19.240
list to anyone. So why is this good or[br]bad? Well, the governmental health
0:28:19.240,0:28:23.640
authorities don't get any contact tracing[br]info in the decentralized approach, and
0:28:23.640,0:28:28.409
this might be an issue because this means[br]that the government does not have any
0:28:28.409,0:28:31.806
statistics about spreaders or[br]effectiveness of the app. They cannot
0:28:31.806,0:28:36.580
measure how much the app actually helped.[br]They cannot measure how many infections
0:28:36.580,0:28:41.009
were prevented by telling people to go[br]into quarantine or to get a test and so
0:28:41.009,0:28:48.590
on. But on the other hand, it means nobody[br]is getting this data. So neither Apple nor
0:28:48.590,0:28:53.470
Google nor governments, nobody is getting[br]the data and there is no gain from
0:28:53.470,0:28:57.989
attacking the servers because they don't[br]have any private information. And there's
0:28:57.989,0:29:03.399
also no privacy impact from using the app.[br]And in the end, if you get a positive
0:29:03.399,0:29:07.999
test, even then you can choose to not[br]share the result if you think it's an
0:29:07.999,0:29:13.919
issue to disclose your pseudonyms. And I[br]mean, ideally, many people should share
0:29:13.919,0:29:23.240
their result, but you don't have to. And I[br]want to show you a few attacks on exposure
0:29:23.240,0:29:26.630
notifications, because some people said,[br]like exposure notifications are very,
0:29:26.630,0:29:33.249
very, very insecure. So let's look into[br]attacks that have been publicly discussed
0:29:33.249,0:29:38.239
on those exposure notifications as they are[br]implemented now. And please note that many
0:29:38.239,0:29:42.619
of these attacks are not specific to[br]Bluetooth, but they are specific to
0:29:42.619,0:29:48.880
everything that's somehow wireless and[br]somehow a notification. So let's look.
0:29:48.880,0:29:54.340
Let's take a look. So the time machine[br]attack. This one is quite interesting. The
0:29:54.340,0:29:58.990
assumption here is that someone can change[br]the time on your smartphone and then
0:29:58.990,0:30:06.940
replay outdated tokens, so that you would[br]think, like you met pseudonyms in the past
0:30:06.940,0:30:10.960
that were already known to be tested[br]positive and because your smartphone also
0:30:10.960,0:30:15.981
is in the past, it would accept those[br]tokens and log them and then if you
0:30:15.981,0:30:21.659
compare them to the server later on, you[br]think that you were positive, in contact
0:30:21.659,0:30:26.659
with positive users and so on. But please[br]note that spoofing time is very, very
0:30:26.659,0:30:31.570
hard. So if someone can spoof time, it[br]means they can also break other things
0:30:31.570,0:30:36.360
like TLS. And I mean, if I had a time[br]machine and I would just travel back to a
0:30:36.360,0:30:43.799
time prior to 2020 or something, instead[br]of faking a few exposure notifications.
0:30:43.799,0:30:50.980
The next attack is the wormhole attack. So[br]imagine that like this one would be one
0:30:50.980,0:30:54.710
shopping center, then another shopping[br]center and maybe up there a police station
0:30:54.710,0:31:00.429
or something like this. How does that[br]work? Well, if you wormhole them and put
0:31:00.429,0:31:08.090
them together, then the chance of getting[br]positive exposure notification in the end
0:31:08.090,0:31:17.478
is very high. So you increase the chance[br]of having positive exposure. And this
0:31:17.478,0:31:23.809
exposure, of course, was not real. So it's[br]forwarded exposure. And because of this,
0:31:23.809,0:31:28.270
in the worst case, you would do more[br]physical distancing, more testing, maybe
0:31:28.270,0:31:33.580
you also start to distrust the app a[br]little bit, but it doesn't really harm the
0:31:33.580,0:31:38.220
overall system. So the amount of record on[br]the server with the positive tests, it's
0:31:38.220,0:31:43.559
not increased because, only confirmed[br]positive cases are uploaded to the
0:31:43.559,0:31:48.749
pseudonym list and those who are just here[br]and get a notification are not uploaded.
0:31:48.749,0:31:52.950
And also to have such a deployment so to[br]have this wormhole and the wormhole that
0:31:52.950,0:31:58.750
scales, you need a lot of devices that[br]forward the notifications and in public
0:31:58.750,0:32:06.190
spaces so it's not that easy to implement[br]this. The last attack is the identity
0:32:06.190,0:32:10.350
tracking attack, so let's say you have[br]those pseudonyms. The pseudonyms, they
0:32:10.350,0:32:14.809
change over time and you are moving[br]through a city and there are multiple
0:32:14.809,0:32:20.039
devices that are observing your pseudonym[br]changes. So, of course, you can then start
0:32:20.039,0:32:26.200
tracking users. This, again, requires a[br]very large scale installation. And the
0:32:26.200,0:32:30.979
issue is also that if you are scared of[br]this type of attack, then you would also
0:32:30.979,0:32:35.427
need to disable Wi-Fi and LTE and so on,[br]because you can always triangulate
0:32:35.427,0:32:42.259
signals. So ideally, if you don't want to[br]be tracked, turn off wireless technology,
0:32:42.259,0:32:49.149
this is really not specific to Bluetooth[br]at all. So, yeah, all those attacks, they
0:32:49.149,0:32:55.919
are valid, but to deploy them, like, to[br]have records of exposure notifications
0:32:55.919,0:33:02.970
that you can then replay with time travel[br]or a wormhole or also some tracing of IDs,
0:33:02.970,0:33:06.909
you really need a large scale installation[br]of something like Raspberry Pis throughout
0:33:06.909,0:33:12.906
a city and many, many, many devices. So[br]this would also work in any other wireless
0:33:12.906,0:33:18.489
ecosystem.[br]But OK, but if you would roll out such an
0:33:18.489,0:33:23.220
installation, also, keep in mind that you[br]could instead just deploy something like a
0:33:23.220,0:33:28.935
lot of devices that have microphones or[br]cameras and Wi-Fi and so on and track a
0:33:28.935,0:33:34.299
lot of other things. This needs to happen[br]in public spaces, so I don't know, next to
0:33:34.299,0:33:39.689
bus stations, shopping centers and so on.[br]And well, if you have such an
0:33:39.689,0:33:45.580
installation, then really just tampering[br]with exposure notifications of Bluetooth
0:33:45.580,0:33:51.429
is not your main concern. The sad reality[br]might actually be that we already have a
0:33:51.429,0:33:56.334
lot of surveillance everywhere, so we have[br]a lot of cameras in public spaces. So this
0:33:56.334,0:34:01.639
is not the part that I would be afraid of.[br]I mean, I would be afraid of public
0:34:01.639,0:34:10.119
surveillance, obviously, but not about[br]Bluetooth surveillance in particular. So
0:34:10.119,0:34:14.440
let me conclude my talk. The BLE[br]advertisements are really the most
0:34:14.440,0:34:17.570
suitable technology that we have in a[br]smartphone to implement exposure
0:34:17.570,0:34:23.980
notifications, and they are available on[br]recent smartphones, on iOS and Android.
0:34:23.980,0:34:29.179
They are very secure, privacy preserving,[br]battery friendly, and also scalable. And,
0:34:29.179,0:34:33.139
keep in mind, every prevented infection[br]saves lives and also prevents long term
0:34:33.139,0:34:41.579
disease. So this is really a thing to use,[br]even if it does not work 100%. And with
0:34:41.579,0:34:46.689
this, let's start the Q&A and discuss[br]whatever you like, Bluetooth worms and so
0:34:46.689,0:34:54.519
on. Thanks for listening.[br]Herald: All right, thank you, jiska, for
0:34:54.519,0:34:59.299
your talk. I hope you have time for some[br]Q&A.
0:34:59.299,0:35:05.829
J: Yeah, let's go.[br]H: Awesome.
0:35:05.829,0:35:11.719
J: Oh, I think that was Ollies[br]Internet connection, was it? Yeah. So I
0:35:11.719,0:35:15.470
might just decide on my own until he[br]reconnects. Ah, here you are!
0:35:15.470,0:35:21.110
H: I'm so sorry. The question was why[br]would the angle of arrival be interesting
0:35:21.110,0:35:26.230
for an attacker or[br]J: Not for, for an attacker. But like from
0:35:26.230,0:35:31.680
the technology, it would be interesting to[br]have it in Bluetooth because then you
0:35:31.680,0:35:37.030
could do some direction estimation. And I[br]mean, if people move, you could also get a
0:35:37.030,0:35:43.471
direction and maybe location via this or[br]assist this. But yeah, I mean, it's not in
0:35:43.471,0:35:47.810
any chip yet except from some evaluation[br]kits.
0:35:47.810,0:35:55.010
H: All right. Thank you. Is there any[br]studies that proves or disproves the
0:35:55.010,0:35:59.520
efficiency of contract tracing apps in[br]general? I mean, like the use case?
0:35:59.520,0:36:06.289
J: I mean, the issue is because we have[br]the exposure notification framework that
0:36:06.289,0:36:11.970
we do not have any statistics. So the good[br]and the bad thing about privacy is that we
0:36:11.970,0:36:17.609
cannot have such a study except from if[br]people would provide their data in, I
0:36:17.609,0:36:21.980
don't know, a questionnaire or something.[br]But at least I know people who have been
0:36:21.980,0:36:26.324
warned by the app and got the test and so[br]on. So it seems to work from the people I
0:36:26.324,0:36:33.289
know. Yeah. And I mean, every life that it[br]saves counts in the end. So, I mean,
0:36:33.289,0:36:39.890
nothing is perfect, right?[br]H: True very much. Thanks for your answer.
0:36:39.890,0:36:44.989
But user triplefive would like to know:[br]"Why would you think the accelerometer
0:36:44.989,0:36:49.950
would be a data privacy issue, isn't it up[br]to how the sensor data is processed, i.e.
0:36:49.950,0:36:54.430
stays on the device, is not stored and so[br]on and so forth."
0:36:54.430,0:36:58.670
J: Yeah, of course. But I mean, once you[br]give that permission to the app, you need
0:36:58.670,0:37:02.960
to trust the app, which is first of all a[br]binary that you download. I mean, maybe
0:37:02.960,0:37:07.390
it's open source like our German app, but[br]you never know. And then it could process
0:37:07.390,0:37:11.810
this data. And actually from an[br]accelerometer, there have been studies
0:37:11.810,0:37:16.670
that you not can just, like, do step[br]counts, but even stuff like someone turned
0:37:16.670,0:37:20.040
to the left, to the right, and from this,[br]if you have an overlay to a map, you can
0:37:20.040,0:37:24.660
even reconstruct the path that you moved[br]through a city, for example. So that's a
0:37:24.660,0:37:32.920
big issue, I think.[br]H: Alright. Thank you. There's one more
0:37:32.920,0:37:38.869
question here. Have any of the theoretical[br]or possible exploits been tried in
0:37:38.869,0:37:42.312
practice? To the best of your knowledge,[br]that is?
0:37:42.312,0:37:47.970
J: To my knowledge, not. I mean, I think[br]it would only be visible once someone does
0:37:47.970,0:37:53.309
such an attack, large scale, and then they[br]need to manage to have a large deployment
0:37:53.309,0:38:02.980
of such an attack without being caught.[br]So, yeah, nobody did this so far. Yeah.
0:38:02.980,0:38:11.000
H: OK, makes sense. And there's one person[br]who had a comment. They pointed out that
0:38:11.000,0:38:15.210
there is an open implementation for the[br]framework if the user wants to go without
0:38:15.210,0:38:20.380
Google or Apple at all and still take part[br]in exposure notifications. I think it's a
0:38:20.380,0:38:24.030
fairly recent development.[br]J: Yeah, exactly. So I had my slides
0:38:24.030,0:38:29.049
already finished when that came out. So[br]it's on the F-Droid store and it uses, I
0:38:29.049,0:38:33.690
think, yeah, just like an open source[br]implementation so that you can now use it
0:38:33.690,0:38:43.260
even on your Lineage phone for example.[br]H: OK, thank you.
0:38:43.260,0:38:47.920
J: OK, any further questions?[br]H: Yeah, one last question just bumped in
0:38:47.920,0:38:54.119
here, surfaced over there. Has anyone[br]tried to crack the verification server
0:38:54.119,0:39:01.140
by brute force? The person asking did a[br]back on the envelope calculation, back in
0:39:01.140,0:39:06.700
time. And it seemed possible to just try[br]out all possible Tele-TANs at some point.
0:39:06.700,0:39:11.490
J: All possible Tele-TANs, I mean, so that[br]would be like really a brute force that
0:39:11.490,0:39:16.252
you see in the back-end, right? So that's[br]something that you can't just rate limit.
0:39:16.252,0:39:19.480
And that's probably the only thing that[br]you can brute force because all the
0:39:19.480,0:39:25.660
comparison and so on is done locally on[br]the smartphone. So the TANs would be the
0:39:25.660,0:39:30.740
only weak point in the system. And if[br]someone tries to brute force all TANs
0:39:30.740,0:39:36.530
that, yeah, it's a very obvious attack.[br]H: You know, makes sense. All right.
0:39:36.530,0:39:39.849
Thanks a lot for the talk. Thank you for[br]your patience in answering all the
0:39:39.849,0:39:46.230
questions. I believe that's actually our[br]time slot exactly. And with that, I hand
0:39:46.230,0:39:51.720
over to the news show from Dublin this[br]time. Thanks a lot.
0:39:51.720,0:39:57.100
postroll music
0:39:57.100,0:40:32.000
Subtitles created by c3subtitles.de[br]in the year 2020. Join, and help us!