DEF CON 27 - DAMIEN CAUQUIL - defeating bluetooth low energy 5 prng for fun and jamming

ra
Defea ng Bluetooth Low
Energy PRNG
for fun and jamming
Damien ”virtualabs” Cauquil | DEF CON

ra
Who am I ?
• Security Evangelist @ digital.security
• Senior Security Researcher
• Main developer of BtleJack (a BLE swiss-army tool)
virtualabs
/

ra
Bluetooth Low Energy Protocol
Origins
Bluetooth Low Energy has been introduced in as Bluetooth
Smart, in Bluetooth Core Speciﬁca ons version . .
Evolved since then: version . ( ), version . ( ), version
( ) and version . ( )
/

ra
Security mechanisms
• Pairing: key exchange with PIN code, OOB or ECDH
• Secure connec ons: encrypted and authen cated
communica on
• Channel Selec on Algorithm: not a security mechanism, but
makes sniﬃng complicated
/

ra
Known a acks (BLE <= . )
• Sniﬃng: stealing secrets sent through non-secure and secure
BLE connec ons
• Jamming: disrup ng an exis ng BLE connec on
• Hijacking: taking over an exis ng BLE connec on
/

ra
Required hardware
/

ra
BtleJack
• Swiss-army knife to perform Bluetooth Low Energy a acks
• Compa ble with Micro:Bit and other nRF boards
/

ra
New features introduced in BLE
• Be er throughput (up to Mbps)
• Be er range (up to feet – meters)
• Improved coexistence
/

ra
Be er throughput / be er range
BLE adds two new PHYs:
• Mbps uncoded PHY: twice the speed of BLE .x
• LE Coded PHY: range × ( kbps) or range × ( kbps)
/

ra
LE Coded PHY vs LE uncoded PHY
/

ra
Improved coexistence
BLE also adds a new Channel Selec on Algorithm (CSA # )
• Designed to replace the old algorithm:
Channeln+ = (Channeln + hopInc) mod
• PRNG-based: more ”random” than CSA #
/

ra
Improved coexistence
BLE adds a ChSel bit in the adver sing channel PDU header:
/

ra
Consequences regarding known a acks
• A completely diﬀerent hopping pa ern ( -hop instead of
-hop sequence) is used
• We won’t be able to sniﬀ, jam or hijack BLE devices
• We need a new hardware that supports BLE new PHYs
/

ra
BLE PRNG overview
• It uses a channel iden ﬁer as a seed
• It relies on basic opera ons (add, mul ply, xor, bit
permuta ons)
• Channel remapping is performed if not all channels are in use
/

ra
BLE PRNG overview
Channel Iden fier
Channel iden fier is first computed from Access Address, as
described in the specs:
/

ra
BLE PRNG overview
MAM
This PRNG relies on a basic rou ne called MAM:
/

ra
BLE PRNG overview
Random number genera on
It generates a random number based on channelIden ﬁer and a
counter:
/

ra
BLE PRNG overview
Channel Selec on Algorithm #
Based on the output of this PRNG, it selects a speciﬁc channel:
/

ra
Breaking this PRNG
I see some ﬂaws in here ...
• channelIden ﬁer is computed from Access Address ... which
is PUBLIC !
/

ra
Breaking this PRNG
I see some ﬂaws in here ...
• channelIden ﬁer is computed from Access Address ... which
is PUBLIC !
• Next value is generated from a COUNTER, not from some
previous internal state !
/

ra
Breaking this PRNG
From unknown bits to , easy peasy
Access Address is broadcasted in every packet!
/

ra
Breaking this PRNG
PRNG ? really ?
prn_e = PRNG(channelIdentifier, counter)
• channelIden ﬁer is constant
• it generates a ﬁxed sequence of values, indexed by
counter
/

ra
Breaking this PRNG
Waht do we need to break it ?
• Consider channelIden ﬁer as known
/

ra
Breaking this PRNG
• We are le with an unknown -bit counter
/

ra
Breaking this PRNG
• We are le with an unknown -bit counter
• If we can ﬁgure out where we are in the sequence of
values, we would ﬁnd out this counter value
/

ra
Ge ng informa on from RF
As an a acker, we can only monitor an exis ng BLE connec on and:
• determine WHEN a packet is sent over a speciﬁc channel
• determine the me spent between two packets transmi ed
on two channels
/

ra
Ge ng informa on from RF
Channels are not -bit values
If all data channels are used:
channel = prn_e mod
else:
channel = remappingIndex[ (N×prn_e)
]
/

ra
First approach: using a sieve
• Pre-requisite: we know the hopInterval used for the target
connec on (i.e. me spent between two hops)
• Our goal: to eliminate every possible candidate in the
smallest number of rounds
/

ra
How it works
Considering a counter of , we compute channel C from PRNG
with this candidate counter, and wait for a valid packet
/

ra
How it works
Once a valid packet received, we compute the next channel (C )
and we wait for a valid packet again:
/

ra
How it works
We deduce the me spent between these two packets:
/

ra
How it works
And we convert it into a number of hops:
/

ra
How it works
We then sieve the sequence of channels to only keep poten al
candidate indexes:
Sequence = {..., C , ..., C
N hops
, ...}
And we end up with a list of candidate counter values at T
(between and , most of the me)
/

ra
How it works
Then, we consider the ﬁrst candidate and:
• we compute C and C
/

ra
How it works
• we wait for a packet on channel C
/

ra
How it works
• we wait for another packet on channel C
/

ra
How it works
• we deduce the number of hops
/

ra
How it works
• we deduce the number of hops
• we sieve our list of candidates to only keep the matching ones
/

ra
How it works
Repeat un l one candidate le !
(This is the counter value at T )
/

ra
Implementa on (video)
Since I did not have a BLE compa ble device, I simulated this
a ack:
-> Attacker waited 21 hops until a packet arrived on channel 0
>> Filtering candidates ...
-> Candidate 20476 removed
-> Candidate 45108 removed
-> Remaining candidates: 22967
>> Found initial counter: 22967
INFO: Attack required 209 hops
/

ra
Guessing the hop interval
Using our previous measures
hopInterval = GCD(δT , δT , δT , ...)
/

ra
Simula ng (again)
$ python3 csa2-hopinter-simulate.py
[system] Hop interval: 2220
Deduced hop interval after 2 deltas: 8880
[...]
/

ra
Eﬃciency
# of measures approx. success rate Max. me required (s)
%
%
%
%
%
%
/

ra
From theory to prac ce:
breaking CSA # on the ﬁeld

ra
I bought some BLE compa ble devices
/

ra
Improving Btlejack
Channel map and hopInterval recovery
• Btlejack can do the job but only for Mbps uncoded PHY
• I modiﬁed Btlejack to compute hopInterval while mapping
channels
• This GCD-based technique works pre y well =)
/

ra
Improving Btlejack
Example output
# btlejack -f 0x9af4493f -5 -d /dev/ttyACM2
BtleJack version 2.0
[i] Using cached parameters (created on 2019-07-23 00:47:59)
[i] Detected sniffers:
> Sniffer #0: fw version 2.0
[i] Synchronizing with connection 0x9af4493f ...
✓ CRCInit: 0x6f1c40
✓ Channel Map = 0x0774ea8a3c
✓ Hop interval = 160
/

ra
Improving Btlejack
Implemen ng our sieve a ack on counter
I implemented this algorithm and tested it:
• First round went pre y well: I got about candidates
ﬁltered
/

ra
Improving Btlejack
I implemented this algorithm and tested it:
• First round went pre y well: I got about candidates
ﬁltered
• Next rounds messed up: I was not able to guess the counter
value
/

ra
Improving Btlejack
Filter out candidates took a hell of a me, thus inducing
a delay !
(Sor ng algorithms did not help)
/

ra
Improving Btlejack
Re-designing our sieve a ack
To solve this problem, I moved from a sieve to a pa ern-matching
algorithm:
• Measure ﬁrst (number of hops between diﬀerent
consecu ve channels)
/

ra
Improving Btlejack
algorithm:
• You end up with δT values (δT to δT )
/

ra
Improving Btlejack
algorithm:
• You end up with δT values (δT to δT )
• Look for this hopping pa ern in our sequence and deduce
counter
/

ra
counter guessing is now working, YAY !
/

ra
Improving Btlejack
hops why
Pa ern matching took about hops to complete !
/

ra
Sniﬃng a BLE connec on with CSA #
[i] Synchronizing with connection 0x31204f95 ...
✓ CRCInit: 0x40d64f
✓ Channel Map = 0x1fffffffff
✓ Hop interval = 160
✓ CSA2 PRNG counter = 5137
[i] Synchronized, packet capture in progress ...
LL Data: 0e 08 04 00 04 00 52 10 00 01
LL Data: 02 08 04 00 04 00 52 10 00 00
LL Data: 02 08 04 00 04 00 52 10 00 01
LL Data: 0e 08 04 00 04 00 52 10 00 00
LL Data: 0e 08 04 00 04 00 52 10 00 01
/

ra
Jamming a BLE connec on with CSA #
# btlejack -f 0x91a7471f -m 0x1fffffffff -p 160 -5 -j
BtleJack version 2.0
[..]
[i] Synchronizing with connection 0x91a7471f ...
✓ CRCInit: 0x21a31e
✓ Channel map is provided: 0x1fffffffff
✓ Hop interval is provided: 160
✓ CSA2 PRNG counter = 1199
[i] Synchronized, jamming in progress ...
[!] Connection lost.
[i] Quitting
/

ra
Btlejack version .
https://github.com/virtualabs/btlejack
/

ra
Conclusion
Bluetooth Low Energy CSA # PRNG is weak:
• It is not really a PRNG
• bits out of can be easily guessed from a public value
• The last bits compose a counter that is periodically
incremented
/

ra
Conclusion
This PRNG:
• is thought to improve coexistence, not security
• is designed to be easily implemented on low-power devices
/

ra
Conclusion
• We should use Nordic’s nRF rather than the old
nRF
• S ll a lot of work to port BtleJack to this pla orm
• But luckily, Marcus Meng has done a great job with nRF
/

ra
Research materials
Python scripts and notes
https://github.com/virtualabs/ble5-research
/

ra
Thank you !
Ques ons ?
 @virtualabs
 damien.cauquil@digital.security
/

ra
Further readings
• https://virtualabs.fr/defcon26/
DC26-DamienCauquil-YoudBetterSecureYourBLEDevices.pdf
• https://www.alchemistowl.org/pocorgtfo/pocorgtfo17.pdf
• https://github.com/mame82/misc/blob/master/logitech_vuln_
summary.md
/

DEF CON 27 - DAMIEN CAUQUIL - defeating bluetooth low energy 5 prng for fun and jamming

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to DEF CON 27 - DAMIEN CAUQUIL - defeating bluetooth low energy 5 prng for fun and jamming

Similar to DEF CON 27 - DAMIEN CAUQUIL - defeating bluetooth low energy 5 prng for fun and jamming (20)

More from Felipe Prado

More from Felipe Prado (20)

Recently uploaded

Recently uploaded (20)

DEF CON 27 - DAMIEN CAUQUIL - defeating bluetooth low energy 5 prng for fun and jamming