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!