*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!