Security Considerations For Bluetooth Smart Devices

Ravikiran HV, PathPartner Technology Pvt.Ltd.

Abstract

Bluetooth Smart is an emerging short range wireless technology aimed for low power devices. Bluetooth 4.2 core specification provides various methods to secure the communication between devices and establish trusted connections. This paper describes the design considerations to secure the Bluetooth smart devices.

1. 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, Bluetooth Low Energy Module 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 Bluetooth heart rate monitors, blood pressure monitors, fitness kit, smart watches etc. run on a small coin cell battery for years.

2. Low energy, Low security

Like any other wireless technology, BLE is no exception from security threats. While Bluetooth LE beacons bring lots of potential in the IOT design, security threats such as device tracking, eaves dropping, and man in the middle attack 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, it can reveal the secrets to the rivals.

Figure 1 – LE devices without privacy

3. Threats for Bluetooth Smart

Passive Eavesdropping:

Passive eavesdropping is secretly listening to the private communication between two devices in real-time by un-authenticated third party devices (eavesdropping equipment). 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 are 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 4.0 devices 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 which 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.

4. Security architecture:

Security in Host:

Unlike classic Bluetooth, Bluetooth low energy sensors and devices implement the key management and security manager 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 and complexity of LE-only controllers. Security manager:

Figure 3 – Security Manager

Bluetooth specification mandates a security manager in the protocol stack implementation. Security manger defines the authentication, pairing, encryption 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:

Bluetooth Security requirements of the device and services are expressed in terms of security modes and security levels. 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 level-1 and level-2 in these modes supports LE communication without security and encryption without pairing respectively. Level 3 and level 4 provides more security to the system than prior levels. LE secure connection (Level-4) introduced in Bluetooth SIG 4.2 specifications, brings in high security to the LE communication via Elliptic Curve Diffie-Hellman (ECDH) public key cryptography technique.

LE security mode 2:

Devices conform to security mode-2 supports both authenticated and unauthenticated pairing along with mandatory data signing. Data can be signed using various techniques including public key cryptography to ensure the data integrity and security.

Mixed Security mode:

For the devices which need both mode-1 and mode-2 security shall use mixed security mode. This enables the devices to use combination of multiple security modes such as data signing along with ECDH to provide enormous security to the smart devices.

Secure Connection Only mode:

When LE smart devices operates in secure connection only mode they shall use authenticated connection and pairing with encryption. Device shall only accept outgoing and incoming connections for services that use security mode-1, level 4. With this restriction, devices operating in this mode should use ECDH, introduced in 4.2 specifications.

5. Securing Bluetooth Smart: 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 a long time may face higher security risk.

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.

6. Conclusion

Compared 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 ensures 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 more secure than ever.

7. References:

About 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 solutions to our global customers. Our Industry standard FIPS compliant solutions for Bluetooth smart and Bluetooth smart ready are already deployed in various end user premises successfully.

PathPartner based out of California, USA and Bangalore India is a leading provider of Consulting, Services and Solutions for digital media centric devices market. Our services range from Product Engineering/R&D and System Integration to Middleware, Applications and System solutions.

With an expert management team which has rich experience in Technology, Engineering & Business practices, PathPartner has Sales & marketing presence in USA, Europe, Korea and Taiwan. The company specializes in addressing challenges faced by leading OEMs, Silicon and OS providers in their product development.

www.pathpartnertech.com
sales@pathpartnertech.com
sales.usa@pathpartnertech.com

If you wish to download a copy of this white paper, click here