Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/2856 Thanks!
[Music]
I read a headline uh at the end of
November which was new attacks endanger
Bluetooth data security on billions of
devices and my first thought when I read
it
was can it be patched is it patched
already Danel antonioli is the guy that
researched these attacks and named them
Bluffs the attack Bluffs several
security mechanisms and uses six novel
attacks to break the Bluetooth security
Daniel works as an assistant professor
at eurocom with the software and system
Security Group and I'm excited to see
how he breaks and fixes
[Music]
Bluetooth so let's unlock the stage and
give him a warm Round of Applause and
let's hear what is us thank
you
yeah thank you for the the kind
introduction and good evening to
everybody and thanks for coming to my
talk I would also to extend my uh
greetings to the people who are
attending the talk uh remotely and this
talk is titled BLS Bluetooth forward and
future secrecy attacks and defenses my
name is Daniel antoli I'm an assistant
professor at
a university located in the in the
French Riviera we are doing research in
applied system security and privacy on
topics including uh wireless security
embedded system security and mobile
system security we are hiring uh uh PhD
and posts so if you are interested in
what we are doing please talk to me
later or you can also send me an email
and you can check out my personal
website for more information about my
research this talk is is based on a
research paper that uh I presented
recently at ACM
ccs and you can find um more information
about the talk of course in the in the
paper and uh the the talk also
contributes to a a research project
called
Orin Orin stands for open source
resilient hardware and software for the
internet of things I'm the technical
lead of this uh research project that is
funded by the European Union you can
also check out the web page of um Orin
if you are
interested okay so now let's start with
some introduction about Bluetooth and
its security mechanisms so Bluetooth is
a pervasive low power Wireless
technology it is specified in a set of
documents that are publicly available
the most important document is the
Bluetooth core um uh document which is a
PDF 3,000 3,000 pages long PDF the
latest version of the core specification
is
54 inside this document um you you will
see two main Bluetooth flavors uh
specified the first one is Bluetooth
classic which is shortened with BC and
color coded in uh blue and Bluetooth
classic is used for high throughput and
connection oriented Wireless Services
think uh headsets connected to a
laptop then there is a second transport
called Bluetooth low energy BL in short
which is colorcoded in light blue that
was uh specified to address the iot
market and so here we are talking about
connectionless Wireless services or
connection oriented Wireless services
with low throughput but very low power
consumption for example uh if you have a
fitness
tracker uh you can connect it to your
smartphone using Bluetooth low
energy and maybe the most important
keyword about Bluetooth is
interoperable because uh Bluetooth is
trying to address as many as uh Wireless
services and wireless devices as
possible in fact it is used by billions
of heterogeneous devices all our
smartphones laptops cars wearables even
industrial sensors and biomedical
devices are using Bluetooth and these
entails a really large attack surface if
you if you manage to break Bluetooth
then you can break all these uh
devices a bit of historical context
about Bluetooth so Bluetooth the name of
Bluetooth comes from the name of King
Aral Bluetooth which was a Danish King
who United uh several tribes into a
single Kingdom and Bluetooth is trying
to do do the same thing for wireless
communication so he's trying to unite
all wireless devices to speak the same
protocol
another bit of history is about the logo
of Bluetooth the Bluetooth logo is the
superposition of the uh King
initials uh using the Nordic alphabet
and so we have Nordic H superposed with
a Nordic B because the Name of the King
was Aral Bluetooth and this forms the
logo that everybody
[Music]
knows Bluetooth is specified in a set of
documents and uh the the official
Bluetooth website is defining the
Bluetooth specification as a set of
Technologies to create interoperable
Bluetooth devices inside the
specification we found the the
definition of the transports that I
already mentioned like BC and ble we
also find the definition of the
components that you will have to
implement if you want a Bluetooth device
so we have the host component that
typically is implemented in the
operating system of of a device think of
it as the Linux internal and then we
have the controller component which is
implemented in the in the system on chip
the radio system on chip firmware and
these two uh components are talking
using a protocol called HCI the O
controller
interface and uh then of course the
Bluetooth specification is also uh
describing the security protocols used
by all Bluetooth devices and there are
two main protocols one is pairing and
the second one is session establishment
in this talk we will focus on a session
establishment now one message that I
always would like to convey whenever I
talk about Bluetooth security is that
one uh vulnerability in the Bluetooth
specification is exploitable on billions
of devices and so it is critical that
the security protocols in the Bluetooth
specification are robust against attacks
in the past we discovered several um
vulnerabilities and attacks at the
specification level for example in
2021 we we talk about the blur attacks
where we we are capable of attacking
Bluetooth classic from Bluetooth low
energy and vice versa by exploiting a
feature in the standard called cross
transport key derivation in
2020 we we uh developed the bias attacks
which are authentication bypasses tricks
that you can play for Bluetooth classic
and in
2019 uh we talk about the nov attacks
which are uh key downgrade attacks on
Bluetooth classic and Bluetooth FL
energy and today we will talk about yet
novel Family of attacks and
vulnerabilities affecting the Bluetooth
specification so keep in mind this uh
this message one BT specification
vulnerabilities billions of exploitable
devices now before talking about the
attack we have to describe on a high
level what are these security protocols
used by Bluetooth so the first one is
pairing pairing is a key agreement
protocol that is used to derive a
long-term key also called pairing key
and in case of Bluetooth low energy
during this protocol you can set the
strength of this paing key also known as
the entropy of the paing key the default
entropy value is 16 BYT you can think of
the entropy as the key length so you
have a length the the higher the length
the stronger the key and so 16 by is the
default value and then you can lower
this value as low as 7even BYT
pairing is optional authenticated and
authentication requires uh user
interaction that is why for example when
you want to pair your new smartphone
with your laptop sometimes you are
required to confirm that you see the
same numeric value on the screens of the
laptop and the smartphone this is a way
to authenticate pairing against men in
the middle
attacks then there is session
establishment which is a protocol that
is used by paired devices whenever they
connect
this protocol requires no user
interaction and it is used to secure the
communications of all U Bluetooth
connections the this protocol is derives
a session key this session key is fresh
meaning that each session is using a new
session key and for Bluetooth classic
the strength of the session key can can
be negotiated so you can have session
keys of 16 bytes with 16 bytes of
entropy uh and session keys with seven
bytes of entropy for example and how do
you derive this session key you use a
key derivation function that takes as
input the long-term pairing key and some
runtime
parameters um then you have security
modes these are negotiable uh at the
beginning of the pairing and the session
establishment protocol protocols the
devices are negotiating a security mode
that is either secure connections or SC
or Legacy secure connection or
LSC SC is using fibs compliant
cryptographic Primitives such as
elliptic C Felman as in CCM mode and um
hkdf key derivation function sha 256 and
so on so forth LSC instead is using
weaker Legacy cryptography Primitives uh
such as the ezer stream Cipher that was
an as candidate and the safer plus
Cipher now this talk is about forward
and future secrecy these are two
essential security
properties forward secrecy protects past
session against the key compromise in
the present okay so how can we um
Implement forward secrecy we can derive
a session key using a secure key
derivation function such as
hkdf and we put as input of the hkdf a
constant and a key used in the past such
that an attacker who compromises the key
in the presence the in the present the
key in red in the slide cannot compute
the key in the past because it was
securely derived with a um key
derivation function okay so we protect
past session from compromises in the
present present future secrecy is
similar uh but it protects future
sessions against key compromise uh in
the present how can we Implement uh
future secrecy we can use the same key
derivation function but now as input we
put the key in the present key and some
fresh
Randomness this fresh Randomness for
example can be generated using dman with
dman you do the standard dman you have a
shared Secret at the end of dman and you
put this uh new Randomness in the hkdf
you derive a key for the future now if
I'm the attacker and I'm compromising
the key in the present I cannot compute
the key in the future because I don't
know these new random numbers that were
generated and the future secrecy is also
called self-healing because it's sort of
self-heal assession that is weak in the
present but will become stronger in the
future
okay now the key question that we we
asked is what are the forward and future
secrecy guarantee of the Bluetooth
standard and surprisingly we notice that
these properties are not even discussed
in the Bluetooth
standard and also there were no prior
evaluations in Academia and Industry
about Bluetooth forward and future secy
despite their widespread use in the real
world right for example the latest
version of TLS TLS 1.3 is mandating uh
forward secret cryptographic Primitives
or
signal uh the the messaging app is using
the dou ret algorithm which provides
forward and future secrecy okay and so
we fill this rich research Gap with this
uh analysis and in particular we present
the first study of Bluetooth forward and
future secrecy we uncover two new
vulnerabilities in the session key
derivation protocol of Bluetooth classic
so here we are narrowing down the scope
to Bluetooth classic and session
establishment of Bluetooth classic if
you remember there are two transport ble
and BC two security protocols pairing
and session establishment we narrow down
to Bluetooth classic session
establishment based on these two
vulnerabilities we developed six new
attacks called The Bluffs attacks that
are breaking Bluetooth classic forward
in future
secrecy and then we run a large scale
evaluation where we exploited 18 popular
devices using 17 different Bluetooth
chips and all these devices are
vulnerable to the attacks that that we
will present later and this will
represent a lower bound of the
exploitability of the BL attacks because
uh we cannot really test all Bluetooth
devices but if we break the Bluetooth
standard we have we are confident that
we can break all devices implementing
this
protocol then we also fixed the attacks
with a compliant and practical uh key
derivation protocol that we proposed to
the Bluetooth special interest group we
reported uh our findings including the
counter measures to to the to the
Bluetooth Sig special interest group
this is a consort of companies that is
managing the Bluetooth standard is
managing responsible disclosure so
whenever you find a vulnerability
affecting the Bluetooth standard you
should contact First the Bluetooth Sig
and then you can also contact the
affected vendors we got CV so you can
track the blast attacks with the with
this this uh this CV and we also release
a toolkit on GitHub that you can use to
reproduce the attacks and to detect them
uh statically from some pickup files
from some uh
traffic okay so now we've seen the
basics the introduction now let's dive
into the
attacks whenever we talk about attacks
we need to define a threat model we need
to specify what is the system that we
want to protect what is the attacker
that is attacking the system but
defining a threat model for for the
Bluffs attacks was not straightforward
because forward and future secrecy were
not discussed in the standard so we had
to study the standard formalize a bit
the the forward and future secrecy and
come up with the threat model and
so uh the security property is the
following Bluetooth classic should
provide forward and future secrecy among
sessions here we we are not talking
about among messages like in a in in
signal for example we are talking about
sessions uh as long as the long-term
pairing key is not compromised otherwise
the attacker can derive all the session
keys and as long as the key derivation
function used uh to compute the session
key is not
vulnerable otherwise the the attacker
can compute the session
key and we will see that with the Bluffs
attacks we are violating this security
property now in our threat model we have
Alice and Bob Alice is the central the
connection initiator Bob is the
peripheral the connection responder
Alice and Bob they already paired they
share a pairing key the attacker is not
observing the pairing process
and Alice and Bob can support Legacy
secure connections or secure connections
this is needed because we want to cover
all possible attack scenarios for
Bluetooth classic then we assume an
attacker called Charlie which is a
proximity based attacker so it is an
attack an attacker in proximity with
some Bluetooth uh device who cannot
compromise the pairing key and who
cannot compromise all the session key
that is targeting otherwise it doesn't
make sense to study forward than future
secrecy and the goal is to break forward
and future secrecy and if you achieve
this goal you entail novel impacts for
Bluetooth because no one studied this
this goal before and as a result you for
example will be able to man in the
middle secure Connections in the past in
the present and in the
future and you will be able also to
impersonate device devices for example
you can impersonate Alice to Bob and Bob
to
Alice okay so given the threat model
this is the attack timeline here we are
using uh uh discrete time events because
it is important to discretize time
because we want to keep track of what is
the past what is the present and what is
the future we assume that at time t0
Alice and Bob they established the
pairing key so they pair the attacker is
not there then at time T1 Charlie uses
some novel tricks to force a week
session key called
SKC and also Charlie is capable of
saving all the parameters that were used
to to negotiate this session key and
then Charlie start sniffing the sessions
that are using this session key and here
already we see that we found a way to
reuse a session key across multiple
sessions then at time T2 Charlie Brute
Forces
SKC it is capable of brute forcing it
because it is weak and by doing that
Charlie breaks all the sessions with
between T1 and T2 and this corresponds
to a break in the forward secrecy of
Bluetooth because Charlie is capable of
computing past
messages with a key
compromise but the attack does not end
here because at time uh t T3 that might
coincide with time T2 Charlie can also
start to reforce SKC in the
future and uh Charlie by doing that
Charlie
breaks um future
secrecy okay and then as an extra step
Charlie
celebrates celebrates why because
Charlie managed one more time to break
the Bluetooth standard despite all the
fixes and and and counter measures okay
and just for a bit of fun we have a du
Punk detour with one slide where we
explain so that D Punk is a French
electronic music duo so I'm based in
France and I I listen to good French
music they formed in Paris in
1993 and one interesting thing about D
Punk is that their music is combined
multiple gas and in the Bluffs attacks
we are combining multiple tricks New
Tricks but also old
tricks and another important thing is
that du Punk were negatively seen by
conservative music reviewers but they
Pro themselves to be new and relevant to
the music scene International music
scene and with the Bluffs attacks we
experience something similar from
academic reviewers and there are also
other off thee wall efforts in the
academic scene that sometimes suffer
from uh you know not being
well well received because maybe the the
the the content of the of the paper I
don't know it's too technical or is too
applied but uh we should keep pushing
publishing research papers that are Al
also interesting for the hiking
community and so I would like Al to
thank CCC for organizing this set of
talks because they're really interesting
and are really useful for us as
academics because we can spread the word
about our research work to a much
broader
community
thank
[Music]
you and by the way the gift that I put
is as far as I can get with animations
is my in my slides so sorry about that
this is the best that I can do with with
memes and animations now go back to the
attacks so now we will see in detail
what is the attack technique how Charlie
is playing these tricks to break forward
in future secrecy so at time T1 if you
remember Charlie
wants to force a weak SKC save the key
derivation parameters and start sniffing
the
communication how can he do that well
Charlie can mount the man in the middle
attack and in the first two messages of
session establishment Alice and Bob are
exchanging some values including the
security mode and Charlie can force LSC
so even if Alice is supporting SC
Charlie can manipulate this message
because this m messages are not
Integrity protected they are not
encrypted these are sent in clear and so
Charlie can play an old trick and
downgrade the session establishment
protocol to
LSC then Charlie can relay the
authentication challenge that is sent by
Alice to Bob to authenticate the pairing
key remember that Charlie doesn't know
the pairing key but also doesn't care
about these messages because uh she can
simply relay them between Alice and Bob
so Alice is is sending an authentication
challenge AC Bob is sending back a
challenge response which is computed
from the pairing key and that is
good now Charlie plays again an old
trick that is the KN attack because it
downgrades the entropy of the session
key to seven bytes this is the lowest
but yet standard compliant value um
possible okay and by U Charlie can
change this as um entropy value from 16
to 7 again because the protocol is not
Integrity
protected then Alice is sending
something called SD or a session key
diversifier this should protect against
our attack because it should uh be used
to generate a different session
key uh for each session
okay this this um value is just observed
by Charlie
and um it is related to to Bob to the
peripheral and then after this message
is sent Alice and Bob they are using the
LSC key derivation function that takes
as input the pairing key the Bluetooth
address of Bob the authentication
challenge the entropy value and the
session
diversifier and uh it is producing it is
outputting SKC okay so this point in
time Charlie is only saving the
parameters needed to compute this key
but Charlie doesn't know SKC Charlie
doesn't know the paring key
okay and then Alice and Bob they start
sending messages uh in um encrypted
encrypted messages and these messages
are encrypted with SKC Charlie sniffs
these messages and start mounting a
Brute Force attack against
SKC after some time at time T2 Charlie
Brute Forces SKC why is this possible
because crypto system with seven byte of
entropy are uh not adequate in
2023 we broke similar crypto systems
such as Des the DAT encryption standard
multiple times with increasing level of
uh performances for example the
Electronic Frontier Foundation uh
developed a specialized arw called Deep
crack then then they were able to crack
Des an academic group also developed
some dedicated Hardware to to crack desk
called Copa
Cabana uh and uh on average to break a
crypto system with seven bytes of
entropy you need two to the 55 trials
because of the birthday parox uh theorem
and if you look at the recommended key
lens in 2023 for example you visit
key.com which is a a reputable website
providing recommendations about this
thing you see that the minimum in 2023
should be 84 bits and key lens is
recommended 50 was recommending 56 bits
in
1982
right and I think that this Brute Force
attack is doable in weeks with a low
cost setup but with dedicated Hardware
you you maybe do it in in days and even
hours there is also a degenerate case
where the attacker can actually uh
downgrade the entropy of the session key
to one bite perform the original knob
attack and now you are left with a key
space of 256 keys and now you can try
the Brute Force attack with pen and
paper and you will succeed you will not
even need a script to brute force a key
uh with one bite of entropy
okay okay so now
we uh Brute Force the key we broke uh
four our secrecy and now we can start
doing extra attacks on future sessions
now we can for example
impersonate Alice to Bob at
T3 how can we do that we can present to
Bob with the Bluetooth address of Alice
we can downgrade the session um
establishment protocol to LSC we can
replay the old authentication challenge
that we saved at time T1 we can ignore
the challenge response that we get back
from Bob we can redo the noob attack and
force the old entropy value of seven
bytes we can send the old session key
diversifier SD and now VOA we know SKC
and we force Bob to recompute
SKC and now we can send messages uh as
Alice to
Bob okay but we can also impersonate Bob
to
Alice this attack is very similar to to
the one that I showed before but the
difference here is that whenever we
impersonate Bob we are supposed to be
the peripheral so we are not the
connection initiator the the connection
is initiated by Alice but we can play a
trick to switch the the connection role
before the Authentication Protocol
starts in fact if you see the third
message before sending the old the AC we
we do we send a roll switch message this
roll switch message is a is a really
nice trick because it enables not only
to switch connection roles so after that
message Charlie becomes the Central and
Alice becomes the peripheral but as a
side effect it also switches
authentication roles so now Charlie even
if it was the peripheral does not have
to authenticate the pairing key and this
is a trick that we discovered with the
bias
attacks then we we we redo the theob
attack and then we force
SKC then we can also combine the two
impersonation attacks and we can man in
the middle future sessions by
reinstalling
SKC I stress out that the blood attacks
are not only a man in the middle attack
but you can also impersonate a device
that is completely different so I can
for example approach I don't know a car
as a thrusted
smartphone or I can impersonate a a car
to to a smartphone it's not only a
matter of men in the middling someone
the attacker does not require always to
be in proximity of the two victims just
one victim
okay now you can combine these uh attack
strategies and come up with six attacks
these are the actually the labels that
you also use in the research paper A1 A2
A3 A4 A5 and A6 these labels uh are
covering the the full the wall attack
surface and they they differentiate
between themselves according to the
device that is spoofed so either you
spoof a central or a peripheral H or you
man in the middle them and also the
security mode so if you do the math you
you you get six uh attacks and I'm also
annotating the labels with the time
instant where you can do the attacks for
example the men in the middle attacks
can be performed also at time T1 the
other attacks at time
D3 okay so now what are the
vulnerabilities what are the root causes
of the Bluffs attacks here I'm reusing
one of the message sequence chart of an
attack to to explain what are the root
causes we have four root causes in the
paper they're indicated with rc1 rc2 rc3
and rc4 first two are new so they were
unknown before the release of this this
research work instead the other two were
known so if we go from top to bottom the
first one is
rc4 rc4 is a vulner ability U related to
the fact that SC can be downgraded to
LSC this is the first reability the
second vulnerability is the fact that
the session key diversifiers so all
these values that are used to compute
SKC uh as input to the
kdf they are not Integrity protected if
if you are not Integrity protecting a
message then an attacker can tamper with
this message okay then we have rc1
which is um a vulnerability related to
the fact that the
kdf when you are using LSC the K
derivation function is
unilateral this means that one device
can dictate all the parameters that will
be used to derive a session key and that
device of course can be the
attacker
rsc2 is the second Noel
vulnerability and is related to the fact
that kdf is not mandating the usage of
nonis
this means that an attacker can replay
old value instead with an nons you
should use a different number the number
can be random can be a a counter but
should be different for each session
instead the Bluetooth specification is
not mandating the usage of nones and is
specifying a key derivation function
that is not mutual but is UN
unilateral and this is in this table we
see a mapping between the root causes
and the
attacks and pretty much all attacks are
exploiting all root causes with the
exception of A1 A2 and E3 that are not
exploiting rc4 because in this attack we
are targeting LSC victims and so we
don't have to downgrade a session to
Legacy secure connection because the
victims are not supporting secure
connections okay so now uh we run a
large scale evaluation of the Bluffs
attacks this is a table that's
summarizes all the devices that we
exploited the First Column we have the
chip that is used by by a device second
column the the device name third column
the Bluetooth
version and then we have one column
dedicated column for each of the attacks
okay I'm boxing in Orange the victims
that are supporting only LSC and in red
the victims that are supporting secure
connection now some key takeaways about
our evaluation so for LSC victims all
devices are vulnerable except a pair of
Logitech uh boom tree
speaker which surprisingly despite being
a you know not fancy device they're not
vulnerable against two of the six
attacks because they
require paing key authentication even if
we do this the r switch trick if you
remember we have to do the roll switch
trick but the the the the device is
requiring Central authentication another
interesting inside is that the Google
pixel BS E Series that are uh quite
recent they still accept the full
entropy downgrade and so they are still
vulnerable to original no attack with
one bite of entropy I I reported this
vulnerability to Google and uh they
answered with a no fix message so the
the Google pixel BS E Series will be
vulnerable forever to the original no
attack so I should keep a pair of these
airbuds in my in my desk just to on my
desk uh just as as a as a
reminder for secure connection um all
devices are vulnerable if the other
victim is supporting Legacy secure
connection instead eight devices are not
vulnerable to A4 A5 and A6 because they
do something smart they enforce secure
connection between pairing and session
establishment there is no reason why two
devices are supporting secure connection
uh use secure connection during pairing
and they they start using Legacy secure
connection after pairing and so if you
keep track of the uh capabilities of the
devices that you pair with then you can
enforce this uh um mode without breaking
uh the the
connection the Bluffs attacks impact
billions of Bluetooth devices because we
exploit several of them laptops
smartphones tablets
headsets uh we we target several
operating systems iOS Android Linux
Windows proprietary operating systems we
exploit different imple software
implementation of of Bluetooth including
Linux blue Z GBL D that is the Android r
stack blue droid that is still an
Android Bluetooth stack that is the
prior to gabble dor and also proprietary
software Stacks we support different
Hardware manufacturers including Intel
broadcom Logitech Infinium Qualcomm
Apple Microsoft and Cambridge silicon
radio and the list goes on and on WE
exploit the most uh used Bluetooth
versions the most popular Bluetooth
version 5.2 5.1 5.0 4.2
4.1 and so on I could not test versions
lower than four 4.1 but these devices
should also be vulnerable unlike stated
in some uh blog posts that I I read and
again this slide goes back to the main
message at the beginning of the
presentation one vulnerability billions
of exploitable
devices okay so now how did we test
these devices well the testing Bluetooth
classic is not straightforward so we
have to develop a dedicated
toolkit uh that supports several
features it is capable of Performing the
attacks using an attack device module it
is per it is capable of detecting the
attacks from a pickup file it it
provides some sample pickup files that
you can use as a reference to check if
uh if the attack that you are testing is
successful or not you can also use it to
tamper with session key derivation in
general so you can play with all the
parameters uh to force week session keys
and maybe you can extend the tool kit to
develop new attacks who knows you can
also monitor session Keys across session
to check effectively that the same
session key is established over time and
the the toolkit is low cost because it
depends on a Linux laptop and a
Bluetooth development board the the
repository is already on on GitHub and
you you can you can have a look at the
repository you can clone it you can Fork
it you can do whatever you want with
[Applause]
it so I I will not have time un
fortunity to talk about all the
implementation details but I'm focusing
on the attack device because I think
it's the most interesting so the attack
device uh is as this high level scheme
we you have a Linux laptop that is
connected over USB with a um Cypress
development board the Linux laptop is
implementing the Bluetooth host and you
have a kernel space component in the
Linux kernel and then you have an user
space component that is implemented by
Blue Z then you have an HCI protocol
running uh on USB used to communicate
messages between the host and the and
the controller the controller is
implemented in the development board
Bluetooth firmware that also includes a
baseband module that is um providing the
real time um uh code to send messages
receive messages and manage the the link
layer the Linux laptop is uh kernel is
modified to pass diagnostic messages
that are sent by the uh the dev board
and so before starting the attack you
first you have to attach to the dev
board with the BT attach command and
then you have to send s a vendor
specific HCI command there is a script
for that in the repository that is
activated diagnostic mode this is this
is really important because um typically
whatever you see on wire shark whenever
you are U uh capturing Bluetooth packets
is at the HCI level you are just seeing
the internal messages that are exchanged
between the host and the controller you
are not seeing the link layer messages
that are exchanged over there by
activating diagnostic mode you get these
messages uh mirrored on the HCI
interface and so w shark will show at
the same time HCI packet but also link
layer
packets then we had to work quite hard
on the Bluetooth fare of the Cypress
board because the the thing with
Bluetooth classic is that the pairing
and session establishment and all the
crypto stuff are implemented at the
firmer level in the controller and as
far as I know there is no open- Source
Bluetooth controller so if you
know uh an open- Source Bluetooth
Classic Controller please uh come to me
and uh and we can chat about it because
I would be really interested to to to
play with that uh uh with that firmware
but in in my case I had to reverse
engineer this firmware luckily the the
symbols are are available but we spent
quite a lot of time statically reverse
engineer the firware and then we are
using a another vendor
specific um command or set of commands
to patch the firware to Binary patch the
firmer at runtime and here we are taking
advantage of an excellent tool that is
called internal blue which is a toolkit
that provides a high level python API
and a command line interface to patch
the the fare of the dev board and also
other firmwares uh
easily and uh we wrot several patches I
wrote several patches in in arm assembly
this is a table summarizing the the
patches we have um seven patches uh for
example the first one is used to
manipulate the authentication challenge
the second one to manipulate the
challenge response the third one is used
to manipulate the the session key
diversifier then we have patches to read
the set the value of the session key
because we want to monitor this value we
want to see SKC for all sessions
we can also read the entropy that was
negotiated if the attack device is a
central or a peripheral and then we can
also um these allow roll
switches H now I'm just showing a quick
example of a patch this is man SD this
is a patch um that is used to set the
value of the session
diversifier so um in the first
instruction we are setting r0 to uh zer
and then we are using R4 to um as as the
Base address with a with a literal
offset to set the SD value and we we we
have four instruction to set SD because
each instruction is set is setting four
bytes and SD is 16 bytes long and then
before jumping back to the original
control flow we have to execute the
missed instruction right because
whenever you are uh as we've seen with
the with the the pre
prior to on AR more whenever you are
messing with binary patching you have to
restore the state of the fmer before
jumping back to the to the execution
right and so we have to you have to
execute all the m instructions and then
you also have to restore the register
values and then you can jump back to the
the trigger address plus five because uh
the fmer is using Thum mode and in Thum
mode you use odd
addresses to use mod to compact a bit
the the size of the size of the
FW and uh the other patches are
available on the repository you can have
a look at them and you can develop new
patches you can patch the fmer with
something new and then you can test new
attacks how can you test the de Bluffs
attach with toolkit you have to connect
the board to the laptop uh with BT
attach uh you have to activate
diagnostic mode to get back the link
layer packets then you can start wire
shark and with warar you will see the
HCI packets and also the LMP ones which
are the link layer packets that are
interest interesting for us then you can
pair a victim device uh with the attack
device uh because you can use the attack
device both as a victim and as the
attacker you can disconnect them and
then you run a script that is part of
the of the repository is called Bluffs
this script is automatically patching
your your Dev board with all the patches
needed to perform the attack and then
you can connect to the victim device
that is under test you can observe SKC
you can disconnect then you can redo a
new connection you establish a new
session you can re observe SKC one more
time you can disconnect and then you can
repeat the last step until you are
satisfied you say okay I'm really
satisfied I've seen you know SKC 10
times so I I I I really broke forward
and and future Secret and by using this
testing setup you are automatically
testing all the attacks that we uh
develop because we
are we are covering the wall attack
surface just with one
script okay so now uh we had to develop
some counter measures to address these
critical problems and uh we developed
architectural protocol level counter
measures and implementation specific
ones uh the protocol level is a design
level fix
where we use authenticated and mutual s
key session key derivation for uh LSC
and our countermeasure actually is
backward compliant with the Bluetooth
standard so it can be integrated in the
Bluetooth standard and it is also low
cost because it is reusing All The
cryptographic Primitives it it is just
adding two extra messages or something
like that to the to the protocol and so
it's not uh um expensive as a as a
counter measure we test at the protocol
level because unfortunately we don't
have access to an open source Bluetooth
classic
firmware U but but still at the protocol
level the the the the counter measure is
is effective and this is the new
protocol that we developed so in the
first two messages here we are narrowing
down the scope to LSC because this is
the protocol that we want to protect we
add an extra bit that is called
akd uh to negotiate this extended
enhanced key derivation function to be
back or compliant with devices who are
not supporting this extended key
derivation function then we run the
authentication uh protocol of the paring
key We Run The entropy negotiation of
the session key and now we add an extra
session diversifier if you remember in
the original protocol there is only one
SD that is sent by the central to the
peripheral now we add a a diversifier
that is also sent from the peripheral to
the center Central and so this results
in a mutual key derivation protocol plus
we append a message authentication code
to these two messages to certify the
Integrity of the message why can we do
that because the devices are already
paired and so they already share a
secret if you share a secret you can
protect the Integrity of a channel and
so we use the pairing key here or you
can also derive a some special Integrity
check key from the piring key and you
can use that key to to protect the the
integrity and then you add one extra
parameter to the key derivation function
that now is called M
kdf because you are not only using the
session diversifier from that you get
from Alice but you also using the
session diversifier from Bob and this
results in an authenticated mutually
derived session key and if if implement
this you fix the attack at the root
causes level and this is very good
but we also proposed implementation
level mitigations because we know that
is really hard to change the Bluetooth
standard and so we we recommended
vendors to enforce sess secure
connections between pairing and U
session establishment but this has a
cons that this fix protects only secure
connections to secure connection
sessions so if you implement this fix
you are maybe reducing the attack
Surface by
25% another fix is maintaining a cache
of session
diversifier so in principle a device
could store the last 5 SD session
diversifier that it have seen and then
see if if someone is trying to reinstall
the same key over time but of course as
a drawback the attacker the attacker is
smart is not dumb and so the attacker
can poison the cash and uh can
invalidate this counter measure and then
the third the third implementation level
mitigation is to enforce Mutual
authentication of the pairing key always
regardless of the security mode this is
what is implemented Maybe by mistake by
the boom Logitech
speaker uh but this as a cons the main
cons of this implementation level
mitigation is is the fact that is not
fixing the Bluffs vulnerabilities this
is fixing different vulnerability and so
if the attacker is bypassing this
protocol the pairing key Authentication
Protocol in the session establishment
the attacker can still Break um forward
the future
secrecy okay so this is the last slide
of my talk and uh I am happy to take
questions thanks for attending the the
talk Dan thanks a lot that was very
interesting so when you leave now please
do it Qui L and do we line up on the
microphones for questions microphone
to hi yeah okay um while reverse
engineering the uh control of firmware
did you also find something about out
about something the hardware registers
because maybe having an open bluetooth
file would be really interesting I mean
with Wi-Fi you have monitor mode but
with Bluetooth that doesn't really exist
well no not really we we we didn't look
into Hardware Hardware registers because
um by whenever you are enabling this
diagnostic
mode um with this vendor specific
command you are already getting
something that looks like Wi-Fi monitor
mode and that was enough for for us
thanks microphone number one please
sorry um I have a curiosity on the root
fix that you suggested uh isn't it true
that if it's still like something that
need to be negotiated uh can be still
inv validated by the man middle attack
so that this an uned key derivation as
long as I'm in the channel I can still
say no the device does not support it
yeah of course of course but but the
problem with these fixes is that they
should be compliant with the standard
and so you always have limitations you
cannot really propose something that is
uh fully fully fully secure without
breaking the standard and so it's always
a matter of tradeoffs right thank you
for the question okay I think we stay
with microphone one for another time
okay uh hi can you use software defined
radio stack for this attack and also how
do you mount uh a practical man in the
middle attack you like jamming or other
devices and how do you do it because of
the channel hopping and all the stuff
yeah so as as far as I know there are no
um SDR open source SDR implementations
that are covering the the full Bluetooth
stock there there are some old projects
that are compatible with new radio
but they just support I think Bluetooth
classic up to version 2.1 or something
like that so unfortunately there
is there are not that many efforts in
the SDR space for the second question
for the man in the middle attack well
you can use two development
boards attach them to the to the same
laptop and then you can wait until
devices are disconnecting you can jam
the channel there are several tricks
that you can play but if you're patient
then you can mount them and in the
middle attack
thanks let's get a question from the
internet please uh so the internet wants
to know uh what is the intention behind
the RO switch are there any legit use
cases for that ah well that's that's a
good question uh I guess that one
legitimate use case is whenever you have
a a connection with multiple devices
there is one Central and multiple
peripheral now let's say that the
central wants to leave the the network
the what is called the ponet the
Bluetooth ponet now to synchronize
devices you always need at least one
Central and in that case someone should
roll switch to a central to keep the the
ponet in in
sync so that is one legitimate use case
for r
switching okay let's take microphone
number one
please um um into the kdf uh the
Bluetooth address of Bob uh is is an
input would the attack still work if the
Bluetooth address is random resolvable
uh as Allowed by the standard well if
the if the Bluetooth address is rotating
then you should keep track of the
rotation of the Bluetooth address and
then you you would have to break a new
key so that might might uh mitigate some
some of the attack as a as a consequence
of this resolvable uh private address
yes okay thank you thank you
we go to microphone number four please
so why do we keep seeing protocol
related uh vulnerabilities can't we have
a proper design uh process that provides
proper
Assurance well yeah this is a difficult
one to answer my personal opinion is
that the the ecosystem is so big and so
complex that you have this Legacy
protocol that are biting that are
backfiring all the times so even if you
want to let's say that now you want to
to develop Next Generation Bluetooth
security you develop the perfect
protocol that was I know is using the
best Primitives is I don't know formally
verified and so on and so forth but then
for legacy compliance reason there
should always be a way to go back to the
old vulnerable protocols and this is the
trade-off right this is a trade-off for
the interoperability of Bluetooth so
yeah microphone number one yeah um well
first shortly a recommendation on the
Google uh pixel butt that you mentioned
I hope it was a joke because maybe
they're already compromised now and you
should put them in a soundproof box
because there might now be microphones
on your desk listening to you yeah maybe
maybe yeah on purpose yeah who
knows with um key uh uh Integrity of one
what was it but my question is um you
described this in theory that you can do
a man- in the- Middle attack with
Charlie and Alis and Bob but what's the
likeliness of the theory in practice
that Ellis and Bob will stay around in
your vicinity for so long that uh
Charlie can actually
validate uh his Brute Force attack
because he needs to validate it I mean
and then he needs to be close but the
The Brute Force attack can happen
offline you don't need the an active
connection right okay so you you can off
Brute Force the the key offline without
needing physical proximity of Alice and
Bob okay yeah that you can take your
time yeah yes yes you have time
microphone one go ahead uh yeah thanks
for the talk was uh certainly one of the
better documented attacks in this
Congress um so if I remember correctly
there was some uh criticism uh towards
the Bluetooth s group in the beginning
what would be your advice to the S group
like since it's like vity in the
protocol yeah so maybe I can I have some
backup slides about this so there was a
Bluetooth SE response that you can read
and there are some misconception in the
this response actually there is a lot of
jargon going on as usual and so here I
try to collect the the jargon versus the
reality for example the Bluetooth Sig is
is saying that the blast attacks are
affecting Bluetooth
specification 4.2 through 5.4 but
Bluetooth versions lower than 4.2 are
also affected and potentially also newer
Bluetooth versions will be affected if
they are not patching the bluff attacks
or the researchers identify that a man
in the middle attacker can do this and
that but we identified men in the middle
and spoofing attacks right so there are
many many uh tricks that the Bluetooth
SE is is playing with with this this
statement and I guess that they should
collaborate more with academic
researchers there are not that many
people working on this protocol level
attacks but still we are nice group of
people and they should collaborate more
with us I agree thank you again
microphone number one hi I have a
question about the man in the middle
replay attack so I assume Alis Bob and
the attacker are all in range so if I
replay for example the to reduce the
entropy shouldn't um Bob receive two
messages with the entropy one with the
standard and one with seven and how does
Bob decide which because because you
have two separate channels so whenever
Alice wants to send something to Bob it
goes through Charlie so Charlie is the
man in the middle so Charlie can ify
that packet with 16 and can send the
modified version to Bob which with a
value of seven so it is not uh Bob is
not receiving two messages just one and
and why is Bob because Bob is on a
different Channel not not because there
are two different link layer connections
so Alice is connected to Charlie and
thinks that she's talking to Bob and
vice versa Bob is connected to Charlie
and thinks that he's talking to to Alice
okay I see thank you sure we have time
for one more question microphone one
please uh might be similar to a previous
question but uh how are you ensuring
that in your proposed solution you can't
lower away this new feature
flag again because you cannot if you
want to propose something that is uh
compliant with the standard you you
cannot mess up with the the protocol you
can propose TLS if you want as a as a as
an alternative right so there are many
many protocols we know how to secure
channels but the whenever you want to
patch uh SEC technology as complex as
Bluetooth you have to take into
consideration this Legacy stuff so
doesn't it mean that even if you
introduce that it would still be
vulnerable to the same issue it's not
the same issue it's a different it's a
different issue it's a different
issue thank you Danel Anton
antoli again a warm Round of Applause
for
Danel
[Applause]
[Music]