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