#rC3 - Exposure Notification Security

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!