Controller: Hardware Controller used for low-level communication
Host: The computer that uses the Controller to communicate with a Bluetooth device
HCI: Host<>Controller Interface
Communication between controllers: LMP and LL
base-band link layer protocols (LMP: for ‘normal’ Bluetooth, LL for BLE)
Communication between Hosts: ACL and SCO
logical transmport protocols
ACL: Asynchronous Connection-Less
SCO: Synchronous Connection-Oriented
typically implemented as fixed time ACL slots
Data Link Layer: L2CAP
only for ACL. The focus of this protocol is to add protocol multiplexing capability, segmentation and reassembly operation and group abstractions.
provides different channels (CID — channel identifier)
PSM: second-layer for connection multiplexing
Bluetooth LE connection modes?
define encryption and authentication requirements
authentication in LE Security Mode 1 is achieved by enabling encryption
data signing in mode 2
authorization through user interaction can be requested
Bluetooth Security Controls
Information Gathering
check the lifecycle status of the used bluetooth controller
known bluetooth controller vulnerabilities
bluetooth host stack vulnerabilities
known bluetooth standard version vulnerabilities
Discovery
check if device is advertising on BR/EDR and/or BLE
check if the advertised modes fit the device’s use-case
adequate device signal → more strength means longer attack distances
information disclosure through announced bluetooth device name
Check for sensitive data in device announcements
BLE: AdvData fields
BR/EDR: Extended Inquery Results
Device discoverability: is the device broadcasting discovery frames all the time?
use random mac addresses
Random MAC addresses: two groups, those that allow connection to the device and those that do not
first group: allows calculation of mac from random-mac
Pairing
how is trust between devices created
some user interaction/supervision should be mandatory
It must be proven that it is only possible to pair with the device by changing its status to pairable. The change of mode to pairable mode must require user intervention to be enabled. Pairable mode must be enabled for a limited time, until a pairing is performed, or the user manually deactivates the status.
Input and Output Capabilities
DisplayOnly, DisplayYesNo, KeyboardOnly, NoInputNoOutput, KeyboardDisplay → check if set correctly (according to the device’s physical capabilities)
Bluetooth OOB channel security (e.g., NFC or Wireless based bluetooth key exchange)
check if the Pairing Request/Pairing Response has a field OOB Data
dont’t allow legacy pairing
during pairing there is a Pairing Feature Exchange→ Short Term Keys (STK) indicate legacy pairing and should not be used (check for Secure Connections subfield, this should not be 0)
pairing should mandate some user interaction
check IO Capability field →No Input, No Output would e bad
the Just Works pairing scheme should be avoided
test for known PIN codes (or if PIn codes are not newly generated for each pairing request)
also test for predictable PIN codes
also test for minimum PIN length (8 digits in BR/EDR or 6 digits in BLE)
prevent easy bluetooth link removal
attacker could break up the bluetooth connection and then perform a brute-force attack against the PIN
this might lead to a compromised link or to a denial-of-service attack
verify local storage of Bluetooth Link Keys (on the Host system/Controller)
Authentication
most of these are performed through LMP and needed special firmware
role switch (master/slave) before authentication
the initiating device automatically becomes the master
in legacy authentication, only requires the master device to authenticate the slave, but not the other way around
check if the devices perform mutual authentication (esp. when using Legacy Authentication)
check if a third device can force a disconnect of already paired other devices
Encryption
role switch (master/slave) before encryption
check if the use of encryption is enforced
check encryption key size (and its entropy)
Services
check for hidden SDP services (why are there hidden services in the first place?)
capturing traffic, performing brute-force attacks, etc.
check for hiden GATT bluetooth services
for each exposed service
GATT: check if attributes can be read/written or notified
RFCOMM: check if user can read/write
SDP: access without authentication/encryption?
SMP: access without authentication/encryption?
Application
are there update capabilities?
for the firmware
for the bluetooth stack
for the application itself
are updates signed?
check for replay attacks
checkf or packet forging/injection attacks
secure services
assume all data to be not trustworthy (within the application)