SECURITY CONSIDERATIONS FOR

BLUETOOTH SMART DEVICES

Ravikiran HV

Technical Lead, PathPartner Technology Pvt. Ltd.

Revision - 0.8

Contents Introduction: ............................................................................................................... 5

Low energy, Low security: ........................................................................................ 5

Threats for Bluetooth Smart: ..................................................................................... 6

Passive Eavesdropping: ......................................................................................... 6

Man in the Middle (MITM): .................................................................................. 7

Identity Tracking: ................................................................................................... 8

Duplicate device:.................................................................................................... 8

Security architecture: ................................................................................................. 9

Security in Host:..................................................................................................... 9

Security manager: .................................................................................................. 9

LE security modes:...............................................................................................10

LE security mode 1: .........................................................................................10

LE security mode 2: .........................................................................................10

Securing Bluetooth Smart: .......................................................................................11

Pairing: .................................................................................................................11

Phase-1 (capability exchange): ........................................................................12

Phase-2 (Secure Key Generation): ...................................................................12

Phase-3 (Transport Specific Key Distribution): ..............................................13

Bonding: ...............................................................................................................13

Key Generation: ...................................................................................................14

Encryption: ...........................................................................................................14

Signed Data: .........................................................................................................14

Privacy feature: ....................................................................................................14

Static device address: .......................................................................................15

Private address: ................................................................................................15

Directed advertising: ........................................................................................15

Authentication over proximity: ............................................................................16

Hidden MAC: .......................................................................................................16

Security re-establishment: ........................................................................................16

Security regulations: ................................................................................................17

Conclusion: ..............................................................................................................17

BLE Expertise in PathPartner: ..............................................................................17

References: .............................................................................................................17

Table of Figures FIGURE 1 – LE DEVICES WITHOUT PRIVACY ................................................................................................................... 6 FIGURE 2 – MITM .......................................................................................................................................................... 8 FIGURE 3 – SECURITY MANAGER ................................................................................................................................... 9 FIGURE 4 - PAIRING PROCESS ....................................................................................................................................... 11

Introduction: Bluetooth smart (also known as Bluetooth low energy or BLE) is introduced

in the legacy Bluetooth 4.0 specification by Bluetooth special interest group.

Bluetooth smart is primarily designed for low power embedded devices with

limited computation capabilities. With expeditious growth in the IoT technology,

BLE has become substantiate criterion for the smart devices.

Bluetooth specification supports the asymmetrical architecture of the LE

devices. Memory and processing power requirements of peripheral devices are

much lower than the central. This will be a great advantage in case of single mode

- peripheral only devices. Device that acts always as peripheral can be designed

with low memory, longer battery life and low power consumption. Low power

smart wearable devices available in market such as heart rate monitors, blood

pressure monitors, fitness kit, smart watches etc run on a small coin cell battery for

years.

Low energy, Low security: Like any other wireless technology, BLE is no exception from security

threats. While Bluetooth smart technology and beacons bring lots of potential in

the IOT design, security threats such as device tracking, eaves dropping, man in

the middle attack etc are increasing significantly. BLE devices are designed to

broadcast MAC, UUID and service information’s at a predefined interval. Due to

continuous advertisement, hackers can easily track the device and decode the

broadcasting information using a sniffers or even smart phone. Below Figure-1

indicates how a LE device can be tracked by the hacker and steal sensitive data

over a period of time across various geographical locations.

With hacking and cybercrime reported enormously all over the world, people are

extremely concerned about the privacy. Sensitive data getting in to the hands of the

wrong people without user consent may lead to significant damages. For example,

if such devices with serious security flaws are deployed in military, then military

personnel can be tracked by the foe and also it can reveal the secrets to rivalry.

Figure 1 – LE devices without privacy

Threats for Bluetooth Smart: Bluetooth Low Energy standards are vast, complex and enable various

profiles to support a huge number of applications. Bluetooth Low Energy is a peer-

to-peer design without any centralized infrastructure to monitor and maintain each

device securely. Due to limited infrastructure and the nature of the operation, smart

connectable devices are facing security threats in various levels of the user

operations including pairing, connection and data exchange. A malicious attacker

can get access to the insecure BLE device and modify the data to mislead the

recipients, deny the services or restrict the services to the limited users. He may

also opt to drain out the battery by changing the software configuration and attempt

to make it permanently unusable. A security compromised device poses risk of

disclosing the confidential information and personal data.

Passive Eavesdropping: Passive eavesdropping is secretly listening to the private communication

between two devices in real-time by un-authenticated third party devices. Using a

2.4GHZ channel sniffer, one can listen to all the communication between BLE

devices without the consent of communicating devices. Since eavesdropping does

not affect the normal communication between the devices, chances of user noticing

eavesdropping attempt are extremely low. If unencrypted message or unsigned

messages and used in communication, hacker can get direct access to all the

confidential data exchanged between the devices. Pairing procedures are the well-

known techniques to avoid the eavesdropping issues and encrypt the messages

before exchange. But, if the attacker is listening to the devices during the pairing

process itself, then pairing methods can’t assure the safety against the attack!

Man in the Middle (MITM): In MITM, attacker secretly reads and interprets the messages from the

sender and delivers the message to the reader after interpreting it. Since the

attacker is actively involved in the communication between the devices, this attack

is also known as active eavesdropping. During the course of attack, attacker may

insert his own messages or corrupt the data before delivering it to the reader.

Devices participating in the connection will assume that they are communicating

with each other directly. But an intermediate MITM attacker has complete control

over the communication of these devices. Public key cryptography can provide

needed protection against MITM. But this method will fail, if an active MITM

attacker listens to the shared public key during the initial pairing process and

shares his own public Key instead of actual public key. A device which received

the public key from attacker has no knowledge about the source of the key and

hence it will encrypt and send the next message with the public key shared by the

attacker. Now, the attacker can easily decrypt the messages and interpret it. Also,

he may optionally decide to encrypt the message using the original public key and

deliver to the initiator to keep the communication intact. Below figure-2 indicates

how a hacker can attack the communication between two devices in MITM.

Figure 2 – MITM

Identity Tracking: Bluetooth Low Energy device are designed for periodic advertisement of the

status or its existence. Advertisement packet contains the MAC address of the

broadcaster and unique service formation. It also contains information about the

proximity of the device in terms of the signal strength. Using publicly available

advertisement data and characteristics, attacker can extract large amount of

information and may help him to track the devices based on these unique

information.

Duplicate device: An attacker with the knowledge of MAC address can make a dummy device

with the same MAC address, which runs the dummy service. Such kind of attack is

more dangerous in business and may lead to huge loss since customers will not be

able to get the intended service.

Security architecture:

Security in Host: Unlike classic Bluetooth, Bluetooth low energy device implement the key

management and security manger on host instead of controller. All the key

generation and distributions of key are taken care by SMP running on host. This

approach introduced by Bluetooth specification helps the host to be flexible and

reduces the cost of the LE-only controllers. Host generated Keys are used by the

controllers for data encryption. For any correction of change in need of security

levels, algorithms or methods only host firmware can be upgraded independently

Security manager:

Figure 3 – Security Manager

Bluetooth specification mandates a security manager in the protocol stack

implementation. Security manger defines the authentication, pairing, encryption

Security Manager

and signing between the Bluetooth low energy devices. This is responsible for all

the security and privacy implementations of the BLE stack such as generation and

storing various keys, generating random address and address resolution for the

privacy feature. Security manager uses the services provided by the L2CAP layer

to manage the security. Each device can generate its own key without any external

influence and strength of the key is proportional to the algorithm implemented in

the device.

LE security modes: Security requirements of the device and services are expressed in terms of

security modes and security levels. Bluetooth SIG defines four security modes

namely mode-1 and mode-2. Each service and device may have separate security

requirement. A physical connection between two devices always operates in a

single security mode. With wide adoption of 4.2 specifications, secure simple

pairing methods have become de-facto requirement for the LE device to ensure

security.

LE security mode 1: Security mode-1 defines four different levels of security namely, no security,

unauthenticated pairing with encryption, authenticated pairing with encryption and

authenticated LE secures connection pairing with encryption. Level 3 and level for

provides more security to the system than prior levels. LE secures connection

(Level-4) introduced in Bluetooth SIG 4.2 specifications ensure more security to

the LE communication via Elliptic Curve Diffie-Hellman public key cryptography

technique.

LE security mode 2: Security mode-2 defines two security levels namely unauthenticated pairing

with data signing and authenticated pairing with data signing. Data signing

requirements of mode-2 differentiates it from the prior mode-1 specifications.

Securing Bluetooth Smart: Bluetooth SIG defines various methods to secure the LE communication.

Core specifications provide several techniques for encryption, data integrity and

user data privacy, discussed in detail in below section.

Pairing: The association is done in three phases, which includes device capability

exchange, LTK generation for secure Connection and transport specific key

distribution. For legacy devices, STK is used instead of LTK.

Figure 4 - Pairing Process

Phase-1 (capability exchange): The first step of pairing process is to exchange the identity and capability

information to establish a trusted link between LE devices. Master initiates the

pairing procedure by sending a pairing request to slaves. If security procedures are

not initiated by the master, slave can request master for initiating it. Once the

security requests are received by the slave, master re-initiates the pairing process.

Phase-2 (Secure Key Generation): Selection of pairing method depends on capabilities exchanged in phase-1.

Short Term Keys (STK) are generated based on selected pairing method such as

just works, passkey entry and out of band. Generated secure key pairs (STK) will

be used to establish a secure channel between the participating devices.

In legacy 2.0 standards PIN based pairing method was introduced. In this

method, users must enter the predefined 4-digit PIN code on both the devices.

Devices will be paired on successful authentication of the PIN on both ends. These

predefined PINs cannot be changed unless the next firmware upgrade. Since it is a

fixed number, it is relatively easy for the hackers to interpret the messages and

break the security of the system. Later in 2.1 specifications, Secure Simple Pairing

(SSP) methods introduced to ensure both security and simplicity

Just Works: In Just Work method, no key exchange between the devices and no user

interaction required. This method is well suited if at-least one of the devices

participating in the communication doesn’t have the user interface. This method

provides no MITM protection.

Numeric comparison: If both devices participating in the BLE connection have a display and at-

least has Yes/No Key, then numeric comparison method can be used. A 6-digit

randomly generated code will be displayed on each device. User need to press

Yes/No after manually verifying the key’s displayed.

Pass Key Entry: This method may be used for the devices with a display and other with the

keypad or both devices with at-least numeric keypad. In first case, one device

shows the 6-digit number and other receives the 6-digit input from user and in later

case both devices receives 6-digit numeric input from the user. On successful

authentication devices will be paired and provides MITM protection.

Out of Band: Out of band pairing method is adopted by Bluetooth standards for the

scenarios where both the devices participating in the communication have enabled

out of band communication channel. All secret information’s and cryptographic

keys will be exchanged out of the Bluetooth band. With the rapid growth of the

NFC technology, NFC has become de-facto technology for Bluetooth OOB

communications. Since NFC works at 13.56 MHz, Bluetooth sniffers on 2.4GHz

bandwidth can’t listen to the information exchanged in the pairing process. Also,

NFC is designed to operate over a very small distance up to 10cm, which makes it

more suitable for security critical applications to avoid any MITM attacks.

Phase-3 (Transport Specific Key Distribution): After STK generation and encrypting the links, transport specific keys are

distributed. Keys to be distributed are determined by the parameters of pairing

request and response. Keys exchanged in this phase may include LTK, IRK, the

signature key etc.

Bonding: Bonding is the process of creating the long term trusted relationship between

the devices based on link key generated during pairing process. Long term key’s

(LTK) are generated and stored on both the initiator and responder. These LTK’s

must be used for all the subsequent communication between the same devices to

ensure the data security.

Key Generation: Host implements the necessary API’s on LE devices to generate the keys

such as STK, LTK, IRK, CSRK etc. Unlike classic Bluetooth, controller is not

involved any key generation methods in case of BLE. The host generates Private

and Public key pair and secure connection will be created by taking the factors

from both the devices participating creating the communication. Master and Slave

exchanges Identity resolving Key (IRK) for device Identity and Connection

Signature Resolving Key (CSRK) for Authentication of unencrypted data.

Encryption: LE controller uses the keys generated by the host and encrypts the messages.

Legacy controllers are designed to support to FIPS compliant 128-bit AES. Latest

4.2 LE specifications introduce Elliptic Curve Diffie-Hellman (ECDH) cryptography

over earlier 128-bit AES. ECDH initially exchanges the keys over public insecure

channel and then enables the secure channel communication between the devices

participating in the process.

Signed Data: BLE specification supports sending signed data over an unencrypted channel

with trusted relationship. Even though devices are not paired, BLE devices can

still maintain the privacy of data by signing it. The sender uses CSRK to sign the

data and receiver verifies the signature. On successful verification of the signature,

the receiver assumes that a message has arrived from a trusted source.

Privacy feature: Devices are identified by a 48-bit MAC address compliant to IEEE. It is optional

for the devices to implement either or both public address and private address.

Public device address is broadcasted by the BLE device and hence increases the

risk of security. Bluetooth devices provide the privacy feature to reduce the risk of

device tracking based on identifier of the device. In legacy BLE systems, host

implements the address generation and resolution. According to BLE 4.2

specification, private address generation and resolution are implemented in the

controller. Privacy enabled devices are expected to support at-least one of the

static device address or private address.

Static device address:

The static device address is randomly generated 48-bit address compliant to

Bluetooth SIG specifications. Static address will be changed on every power cycle,

and hence reduced the risk of tracking over power cycles. But the devices which

are not power cycled for the long time, risk of attacker tracing the devices is still

higher.

Private address:

Bluetooth SIG compliant private address is the recommended way of

providing security to BLE devices. BLE specification supports resolvable private

address and non resolvable private address. Only requirement to have the non

resolvable private address is address shall not be equal to public address of the

device. Non resolvable private addresses are typically used for beacons. To

generate resolvable private address, devices needs to be paired, exchange the

private address and IRK during the pairing process. Only paired devices can

resolve this random address and thus possibilities of tracking the device over

period of time is nullified. Private address is changed periodically based on a timer

event and only a trusted device can resolve this address.

Directed advertising: In directed advertising devices indicates both MAC address of the

advertising device and MAC address of the devices it is advertising to. Advertiser

invites the specific trusted device to re-connect, if required. Address used by the

advertiser a special private address called as reconnect address. In legacy

Bluetooth standards, reconnect address can be changed only based on user actions

such as connect, disconnect, device power cycle etc. Latest 4.2 specifications

supports timer based update of the reconnect address.

Authentication over proximity: Received Signal Strength Indicator (RSSI) is the indication of beacon signal

strength observed by the receiver. RSSI is a factor of transmitting power of

broadcaster and the distance between broadcaster and receiver. As an additional

safety measure for the BLE devices, signal strength monitor can be used to extract

the distance between the broadcaster and the receiver and BLE devices with

predefined range of RSSI only can be selected for communication. This method

will reduce the risk of a being tracked or monitored or misleading by a hacker over

a long distance. Since RSSI can vary greatly depending on the usage conditions

and environment, this method is specific to the usage conditions and deployment of

the products.

Hidden MAC: Bluetooth SIG introduced 4.2 standards with improved data exchange rate as

well as security. Most of the major security features of the classic Bluetooth are

adapted to Low Energy specifications. This specification hides the unique MAC

address of the devices. Advertising LE devices need not broadcast their MAC

address for identification purpose.

Security re-establishment: The device may re-establish the security using previously generated LTK.

Master device initiates the encryption. So, security re-establishment can be of two

types namely, master initiated or slave requested. In master initiated security re-

establishment procedure, there is no security manager signaling is involved.

Master initiates link layer encryption only. Slave can also request the master to

initiate the security procedures and in response, master implements the Link Layer

encryption.

Security regulations: US federal security regulations ensure that all Bluetooth devices are capable

of exceeding strict government security regulations. Majority of the LE products

vendors today ensure that they are compliant to Federal Information Processing

Standards (FIPS). These standards are developed and certified by National Institute

of Technology (NIST).

Conclusion: Compare to Legacy LE standards, 4.2 specifications introduce a new

security model along with Secure Simple pairing. Security techniques like MAC

address hiding, Elliptic Curve Diffie-Hellman based key exchange and LE secure

connections have ensure the industry standards security for the LE device. Thus

Bluetooth SIG 4.2 specifications ensured the smarter privacy approaches for the

LE devices and now Bluetooth smart is highly secure than ever.

Bluetooth Expertise in PathPartner: PathPartner provides wide range of services in Bluetooth and Bluetooth smart

technology including platform integration, in house product design and protocol

development. We offer stack integration, porting the software across platform and

operating systems and in house product development, validation and testing.

Having extensive hands-on experience in Bluetooth smart and classic Bluetooth,

we have delivered various promising solution to our global customers. Our

Industry standard FIPS compliant solution for Bluetooth smart and Bluetooth smart

ready are already deployed in various end user premises successfully.

References: https://www.bluetooth.org/en-us/specification/adopted-specifications

https://developer.bluetooth.org/