Hi there, welcome back to this course, I will talk in this lesson about Bluetooth Low Energy security
assessment.
Let's see first an introduction to Bluetooth Low Energy. Bluetooth 4
specifications allow devices to implement both BLE and classic Bluetooth, that is Bluetooth Base
Rate / Enhanced Data Rate. BLE uses the same frequencies as Bluetooth BR/EDR that are between
2.4 gigahertz and 2.4835
gigahertz. Operating systems that support BLE are iOS five and above Android 4.3
and above, Windows 8 and above, Linux 3.4 and above.
Let's see some technical features of BLE protocol: instead of the classic 79 1 megahertz
Bluetooth channels, Bluetooth Low Energy has 40 2 megahertz channels. Within a channel, data
is transmitted using Gaussian Frequency Shift
Keying, similar to the classic Base Rate of Bluetooth. The bitrate is 1 megabits per second and
the maximum transmission power is 10 milliwatt.
Bluetooth Low Energy uses frequency Hopping to counteract narrow band interference problems.
And if you want further technical details you can obtain it from the official specifications published
by Bluetooth SIG
Special Interest Group.
The BLE protocol is used innumerous Iot devices to handle short distance data transmissions.
The slide provides a short list of such devices for example, smartwatches, wearables, smart locks,
smart lighting, consumer electronics, fitness trackers, etc..
Let's see a simple introduction to the BLE stack.
First of all, the Generic Access Profile (GAP) controls the state of the device,
that could be one of these: stand by, advertising, scanning, initiating, connected. Advertisers transmit
data without connecting, while scanners scan for advertisers.
An Initiator is a device that responds to an advertiser with a request to connect.
If the advertiser accepts the connection request, both the advertiser and initiator enter a connected
state.
When a device is connected, it connects as either master or slave. The device
initiating the connection becomes the master and the device accepting the request becomes the slave.
The HCI layer provides communication between the host and the controller through a standardised interface.
The L2CAP layer provides data encapsulation services to the upper
lawyers, allowing for logical end-to-end communication of data.
The security manager layer defines the methods for pairing and key distribution, and provides functions
for the other layers of the protocol stack to securely connect and exchange data with another device.
The Generic Access Profile (GAP) layer directly interfaces with the application and the profiles, to
handle device discovery and connection-related services for the device.
Gap handles the initiation of security features.
The ATT layer allows a device to expose certain pieces of data or attributes to another device.
The Generic Attribute Profile (GATT) layer is a service framework that defines the sub-procedures for using
ATT. Data
communications that occur between two devices in a Bluetooth low energy connection are handled through
GATT sub-procedures.
The application and/or profile will directly use GATT.
These graphics represent the state diagram of a BLE device.
And this shows the structure of a typical BLE packet format, also showing the two detail cases
relating to data packet and an advertisement packet.
This graphic represents a data structure managed by a GATT server and can be interrogated in read/wright mode
by GATT clients. GATT establish a strict hierarchy to organize attributes, allowing the access and retrieval
of information between client and server to follow a set of rules that together constitute the framework
used by all
GATT-based profiles.
For connecting two devices (an advertisers and an initiator), BLE provides 4 pairing mechanisms:
the first is "Just Works", one of the most common pairing modes used by devices without display, and
that uses a pairing key of six zeros.
"Passkey" uses a six digit passkey, then "Numeric comparison" shows same number on both devices, asking
the user to confirm whether the numbers match. "Out-of-band" shares the pin using an out-of-band channel
such as NFC (near field communication).
Let's see some command line tools, useful for verifying the security of Iot devices.
Let's consider an analysis environment with a Linux operating system.
First of all, the Bluez Linux kernel modules must be installed, if not already present, essential
in order to use Bluetooth devices such as a Bluetooth USB dongle and the command line tools that we
will see.
Next the Bluetooth service must be started.
hciconfig is used to configure Bluetooth devices. Without parameters
It prints basic information on a device, that is the interface type, the Bluetooth device address and
other flags such as the state of the interface, up or down,
if it is enabled, the scan, authentication type, encryption, etc..
Another tool that you can use is the hcitool that's used to configure Bluetooth connections and
send some special command to Bluetooth devices, for example, with the lescan command hcitool
inquire remote BLR devices and for each discovered device
It prints the device name. In recent version of Linux, the command may not work.
Another useful tool is gatttool that's a tool that can be used to manipulate attributes with a Bluetooth
low energy device.
And as an alternative to using the hcitool and gatttool command in recent versions of the Linux kernel,
it is possible to use the utility bluetoothctl.
It allows to initiate a scan of BLE devices, connect to them and perform attribute read and write
operations and many more other operations.
The slide show the gatt menu of bluetoothctl, along with all the commands that you can use
after a connection to a BLE device.
Has been discovered several security vulnerabilities of a system on a chip devices from
various manufacturers in the implementation via BLE SDK, collectively referred to as a "SweynTooth".
According to the researchers, hackers in close physical proximity to vulnerable devices can abuse this
vulnerability to remotely trigger deadlocks, crashes and even bypass security in BLE products,
allowing them to arbitrarily access device, read or write functions that otherwise they may only be
accessible by an authorised user.
Countermeasures for BLE vulnerabilities are to update always device firmware with
vendor-released security patches whenever possible.
In order to check, in a vulnerability assessment of a BLE device, the mandatory presence of authentication
(requests for an authentication key) during connection, and the presence of encryption on data transmission, it is
possible to use packet sniffing and analysis tools.
The slide shows a couple of hardware devices useful for Bluetooth sniffing.
For example, with the use of Ubertooth One tool, it is possible to use the command ubertooth-btle
that can sniff BLE connections and save the data traffic in a file for subsequent inspection with
a packet analyzer such as Wireshark.
There are more advanced than performing tools on the market for acquisition and analysis of BLE data traffic,
such as the Ellisys Bluetooth Vanguard tool, that is a Bluetooth protocol analyzer.
OK, the lesson ends here.
Thank you for your attention bye.