Bluetooth Low Energy (LE) - Security Fundamentals#

Texas Instruments

2 - 3 hours read

Introduction#

This module will cover the security fundamentals of Bluetooth Low Energy (LE), which includes pairing, bonding & privacy. We will discuss why you might want to add these features in your application and cover the basic related principles.

The lab activities will walk you through pairing & bonding using the basic_ble example and how to enable privacy features. After completing this lab, you will be able to pair and bond to a mobile device and resolve the peer’s identity address.

It is recommended to review the Privacy Chapter and the GAP Bond Manager and LE Secure Connections Chapter of the TI BLE5-Stack User’s Guide alongside this lab for details and further information. Some references will also be made to this document.

Prerequisites#

Hardware#

For this lab, you need two Bluetooth-enabled development boards. Supported devices are:

Software and Tools for Development#

SIMPLELINK-LOWPOWER-F3-SDK Software Development Kit (SDK)
Code Composer Studio CCS / CCS Cloud or IAR
- See Dependencies section of SDK release notes for required version.

Security Overview#

Terminology#

Term	Description
Pairing	The process of generating & exchanging keys. Not to be confused with forming or establishing a Bluetooth LE connection between two devices.
Encryption	Data is encrypted after pairing, or re-encryption (a subsequent connection where keys are looked up from non-volatile memory).
Association	The pairing method used based on the I/O Capabilities of both devices. For LE devices, Just Works, Numeric Comparison, Passkey Entry and Out-Of-Band are supported.
Authentication	The pairing process using an association method that supports MITM (Man in the Middle) protection.
Bonding	Storing the keys generated during the pairing process in non-volatile memory to use for the next encryption sequence
Authorization	An additional application level verification in addition to authentication.
Out-of-Band (OOB)	Pairing keys are not exchanged over the air, but rather over some other sources such as serial port or NFC. This provides MITM protection.
Man in the Middle protection (MITM)	Provides authentication during the pairing process which helps prevent a malicious attacker from impersonating the peer device during the key exchange.
Just Works	Unauthenticated pairing association method where keys are exchanged without MITM protection.
Nonce	An arbitrary number used just once.
Long-Term Key (`LTK`)	Used for long term encryption in both LE Legacy and LE secure connections.
BDA	Bluetooth device address
Identity Address	An address associated with an RPA that does not change over time. An IRK is required to resolve an RPA to its Identity Address.
Identity Resolving Key (IRK)	Key used for Address Resolution (resolves an RPA).
Privacy	Ability to use new device addresses generated on a regular basis for the purpose of obscuring your identity address from untrusted devices.
Resolvable Private Address (RPA)	Bluetooth Device Address that changes periodically.
Short-Term Key (`STK`)	Used in LE Legacy pairing for initial encryption.
Temporary Key (`TK`)	A temporary key used only in the pairing phase.

Pairing#

Passive Eavesdropping Protection#

In Bluetooth LE, information that is shared over the air can be seen by nearby devices other than the intended recipient. Although this interception of packets cannot be avoided, encryption can be used to prevent over the air messages from being understood by unknown devices. In order to use encryption, the devices involved must agree on the encryption keys used.

Pairing is the procedure used to create an encrypted link with a peer device in order to prevent passive eavesdropping. In Bluetooth LE, there are 2 main types of pairing: LE Legacy and LE Secure Connections. LE Legacy pairing was added in Bluetooth Core Specification v4.0. LE Secure Connections Pairing was added in Bluetooth Core Specification v4.2. If two devices are paired using LE Legacy pairing and either Just Works or Passkey entry as association models, the connection is not protected from passive eavesdropping. However, if the LE Legacy pairing is not captured by a listener, the encryption will be secure.

Man-in-the-Middle (MITM) Attacks#

Another attack Bluetooth LE devices can be vulnerable to is a Man-in-the-Middle (MITM) attack (also called active eavesdropping). A MITM attack occurs when a malicious device connects to two unsuspecting devices and intercepts messages sent between the devices. The attacking device can inject its own data before passing the message along, making the two devices think they are communicating securely with each other while the attacker controls the communication. The Out-of-Band (OOB), Passkey Entry, and Numeric Comparison pairing methods provide protection against MITM attacks. But for LE Legacy Pairing the two association models Just Works and Passkey Entry do not provide any passive eavesdropping protection.

LE Legacy vs LE Secure Connections Pairing#

LE Legacy Pairing provides little to no protection against passive eavesdropping during the pairing process except when the Out-of-Band (OOB) association model is used. However, it ensures privacy between sessions as the Short-term key (STK) is pseudo-random, meaning that if someone finds out the STK, they will not be able to decrypt the data in previous sessions.

In Bluetooth Core Specification v4.2, LE Secure Connections Pairing was introduced. This pairing procedure uses Elliptic Curve Diffie-Hellman cryptography together with the security mechanisms found in LE Legacy pairing. This provides protection against passive eavesdropping. The LE Secure Connections feature also added the Numeric Comparison association model. By default, the TI BLE-Stack will request a Secure Connections pairing but will accept a LE Legacy pairing if necessary. The TI BLE-Stack can also be configured to accept exclusively LE Legacy or LE Secure Connections pairings. See TI BLE5-Stack User’s Guide (GAP Bond Manager and LE Secure Connections) for more details.

LE Legacy Pairing

Pairing Phase 1: Pairing Feature Exchange

The pairing process begins when the Central device sends a Pairing Request command to the Peripheral, or when a peripheral sends a Security request.

Note

The Central device can choose whether or not to initiate pairing after receiving a Security Request. Not all mobile devices support the Security Request command so it is always best to check with the Android and iOS development guidelines before relying on the Security Request command to initiate pairing or encryption.

../../_images/ble_pairing_phase_1.png — Pairing Phase 1: Pairing Feature Exchange#

A Pairing Request command contains information about the types of pairing supported by the Central device. The Peripheral will respond with a Pairing Response command containing the security features it supports. The combination of supported features will determine what pairing association models are used to generate the encryption keys in Pairing Phase 2.

../../_images/ble_pairing_req.png — Pairing Request Command Format#

../../_images/ble_pairing_rsp.png — Pairing Response Command Format#

../../_images/ble_security_req.png — Peripheral Security Request Command Format#

Association Models	Conditions for Use
Just Works	This model is used when there is no Out-of-Band (OOB) data available and neither device has input capabilities.
Passkey Entry	This model is used when there is no OOB data available, at least one device has the I/O capability to enter a passkey, and the other device has the capability to display a passkey.
Out-of-Band	If OOB data is available on both devices, this model will be chosen.

The models here are ranked by perceived level of security. Just works is the least secure and OOB is the most secure. The most secure model supported by both devices will be chosen. For full Association Model requirements, refer to Table 2.7 & Table 2.8 in the Bluetooth Core Specification v5.3 [Vol 3] Part H, Section 2.2.6

In this module, we will cover Just Works and Passkey Entry pairing. The other two models cannot be easily demonstrated with mobile devices.

Pairing Phase 2

During the second phase of pairing, keys are generated and shared in order to encrypt the connection. After the Pairing Response has been received by the Central device, pairing confirm values are exchanged. Each device generates a random number (LP_RAND_I and LP_RAND_R –Legacy Pairing initiator and responding random numbers, respectively), which goes into the confirm value-generating function together with the Temporary Key (TK). Confirm values are generated in accordance with the Bluetooth Core Specification. The LE Legacy Confirm Value Generation Function is described in [Vol 3] Part H, Section 2.2.3.

After the Central receives the Pairing Confirm command from the Peripheral device, the Central will send a Pairing Random command to the Peripheral device with the random number that was used to calculate the Pairing Confirm value in the previous step. The Peripheral will respond with the random number it used for its confirm value. The two devices will check the random number against the confirm values previously exchanged and, if the values match, the pairing will continue. This will verify that they both are using the same TK. If the check fails, a Pairing Failed command will be sent. Pairing Failed commands contain the reason that the pairing failed and can be extremely useful for debugging.

If the Pairing Random exchange succeeds, the link will be encrypted by the Central using the Short-Term Key (STK). The calculation of the STK uses the Temporary Key (TK) along with the Random Values, and thus the STK is not shared over the air. The process to calculate the STK is described in [Vol 3] Part H, Section 2.2.4 of the Bluetooth Core Specification v5.3.

../../_images/ble_pairing_phase2_legacy.png — LE Legacy Pairing Phase 2: Short-Term Key Generation#

Now that we have looked a little more closely at the pairing process, we will review the association models and their strengths and weaknesses.

Just Works

This method sets the TK to zero. As we know, the input of the function computing the STK is the TK and the Random values. Since the TK is set to zero and the Random values are exchanged unencrypted, calculating the STK is easily accomplished for an attacker, thus enabling passive eavesdropping. Likewise, this method does not offer any way of authenticating the devices that are taking part in the connection, which means that it is possible for an attacker to initiate active eavesdropping (MITM attack). However, given that no one is listening during the pairing process, the random number contributing to the STK ensures that this method is secure.

Passkey entry

The TK is now a 6-digit number, a passkey, that is passed between the devices by the user. An example of this would be if one device displays a randomly generated code, and the user types it in to the other device. The same principle as in Just works applies here as well; if no one is listening in to the pairing process, the method is secure. But if someone listens when the TK is transmitted, the method is compromised. The reason that this method is considered more secure than the seemingly similar Just Works, is because it ensures authenticity and thus protects from MITM attacks. Only the user is able to see the passkey, and thus we know that the first transmission with the right passkey will belong to the correct device.

Out-of-Band (OOB)

This method uses another wireless technology to transmit the TK. If the OOB channel is secure from MITM attacks, then we can safely assume that the Bluetooth LE connection is safe from it as well. At the same time, as long as the OOB channel is secure from eavesdropping, the Bluetooth LE connection will also be secure from eavesdropping. This method is considered to be the most secure by far, but this requires a completely secure OOB channel. A popular choice is the NFC protocol, as a connection is only made if the two devices are physically close together. An attacker’s device would thus be visible quite literally. Using NFC also allows for using a very large TK, and thus enhancing security greatly.

LE Secure Connections Pairing

Pairing Phase 1: Pairing Feature Exchange

The pairing process begins when the Central device sends a Pairing Request command to the Peripheral. Alternatively, a Peripheral can send the Security Request command to request the Central device begin the pairing process. The Central device can choose whether or not to send a Pairing Request after receiving a Security Request. Not all mobile devices support the Security Request command so it is always best to check with the Android and iOS development guidelines before relying on the Security Request command to initiate pairing or encryption.

A Pairing Request command contains information about the types of pairing supported by the Central device. The Peripheral will respond with a Pairing Response command containing the security features it supports. The combination of supported features will determine what pairing association models are used to generate the encryption keys in Pairing Phase 2.

Association Models	Conditions for Use
Just Works	This model is used when there is no Out-of-Band (OOB) data available and neither device has input capabilities.
Passkey Entry	This model is used when there is no OOB data available, at least one device has the I/O capability to enter a passkey, and the other device has the capability to display a passkey.
Numeric Comparison	This model is used if both devices support Secure Connections, can display a yes or no message and have some input capability.
Out-of-Band	If OOB data is available on either device, this model will be chosen.

The models here are ranked by perceived level of security. Just works is the least secure and OOB is the most secure. The most secure model supported by both devices will be chosen. For full Association Model requirements, refer to Table 2.7 & Table 2.8 in the Bluetooth Core Specification v5.3 [Vol 3] Part H, Section 2.2.6

In this module, we will cover Just Works and Passkey Entry pairing. The other two models cannot be easily demonstrated with mobile devices.

Pairing Phase 2

During the second phase of pairing, keys are generated and shared in order to encrypt the connection. The types of keys that are generated are dependent on whether LE Legacy or LE Secure Connections pairing is used. In LE secure connections a single Long Term Key (LTK) is used, instead of a Temporary Key (TK) and Short-Term Key (STK) used in LE Legacy connections. This LTK is generated using Elliptic Curve Diffie Hellman (ECDH) public key cryptography which offers significantly stronger security compared to the LE Legacy connections.

LE Secure Connections Pairing Phase 2

If LE Secure Connections pairing is used, the devices will exchange their Public Keys next. The Public Keys are part of an ECDH public-private key pair. The public keys are exchanged using the Pairing Public Key command. After the public keys are exchanged, each side will compute the Diffie-Hellman Key (DH key) using the Public Key of the peer device and the Private Key of the local device.

../../_images/ble_pairing_phase2_secconn.png — Pairing Phase 2: Secure Connections Key Generation#

Next, the devices each calculate a cryptographic nonce (an arbitrary number used just once). These nonces are then combined with values determined through the association rules to create confirm values. Next, these confirm values are exchanged. Confirm values are generated in accordance to the Bluetooth Core Specification and sent using the Pairing Confirm command. The LE Secure Connections Confirm Value Generation Function is described in greater detail in [Vol 3] Part H, Section 2.2.6 of the Bluetooth Core Specification v5.3.

After the Central receives the Pairing Confirm command from the Peripheral device, the Central will send a Pairing Random command to the Peripheral device with the random number that was used to calculate the Pairing Confirm value in the previous step. The Peripheral will respond with the random number it used for its confirm value. The two devices will check the random number against the confirm values previously exchanged and, if the values match, the pairing will continue. If the check fails, a Pairing Failed command will be sent. Pairing Failed commands contain the reason that the pairing failed and can be useful when debugging.

The next step in LE Secure Connections Pairing is the Diffie-Hellman Key Check. The Key Check values are generated using the LE Secure Connections Check Value Generation Functions described in [Vol 3] Part H, Section 2.2.8 of the Bluetooth Core Specification v5.3. Each device contains a key from the first step which is a combination of their private key and a public key. When they exchange these keys, no passive listener will be able to resolve either of the private keys, and thus not be able to resolve the Diffie-Hellman key which is a combination of the private and public keys.

Finally, the Long Term Key (LTK) will be generated in order to encrypt the link. The LTK Generation is performed using the LE Secure Connection Key Generation function which also computes the Message Authentication Code (MAC) Key. The LTK is not shared over the air in Secure Connections.

Now that we have looked a little more closely at the technicalities surrounding the pairing process, we will review the different association models.

Just works

Here, the values for ra and rb are set to zero. The confirm value is calculated using the public key of device A and the public key of device B together with each individual random nonce. For an attacker, all of these values would be known. The key distinction from LE Legacy pairing, is that the connection is not encrypted only using values that an attacker can sniff out. In the last stage of the pairing process, the Diffie-Hellman key, which by design is impossible to know for a passive eavesdropper, is used to generate the LTK used for encryption. This means that this method is substantially more secure against passive eavesdropping than the same method in LE Legacy connections. However, there are no mechanisms for authentication in this method, and therefore it is vulnerable to MITM attacks.

Passkey Entry

This time, the confirmation value is calculated using the public keys of the devices together with the Random Nonce of each device and the 6-digit passkey entered by the user. The confirmation value is calculated bit by bit for every bit of the passkey, and transferred consecutively to the other device for checking. This method provides the authentication that Just Works passkey entry lacks, making it resilient to MITM attacks.

Numeric Comparison

This method follows the same procedure as Just Works numeric comparison, but adds an extra step at the end to fix the vulnerability to MITM attacks. Once the confirmation values match on both the devices, both devices will independently calculate a 6-digit confirmation value using both of the random nonce values. They both display this value to the user, so the user can authenticate the connection. This fixes the vulnerability to MITM attacks.

Out-of-Band (OOB)

Here the public keys, nonces and confirmation values are all exchanged via a different technology than Bluetooth LE. A popular choice is [NFC]{Near Field Communication}, as it requires the two devices to be physically close to work. As with LE Legacy pairing, OOB pairing only provides protection from passive eavesdropping and MITM if the OOB channel is secure.

Bonding#

Bonding is the process of storing the keys that were generated during the pairing process for the purpose of quickly restoring encryption in a future connection. Bonding information is stored in a bond record in non-volatile flash, and it can be restored when the devices connect again.

Privacy#

Anti-Tracking#

Bluetooth devices are identified by their Bluetooth device address (BDA). This address is necessary for interacting with other Bluetooth devices and is appended in many of the packets the device sends out. However, since this address can be seen by any other nearby Bluetooth device, it could be used to collect information about a given device over time. In order to prevent this tracking, Bluetooth LE devices can enable privacy features. This is done by generating a new address at a given interval instead of using a fixed address. This hides the Identity Address from untrusted peers.

Bluetooth Address Types#

Bluetooth address types as defined by the Bluetooth Core Specification Version 5.3 are given below. In the BLE-Stack, these are defined in gap.h with the defines given in parenthesis.

Public Address - Use the Identity Address. (The BDA never changes.) (ADDRMODE_PUBLIC)
Random Static Address - Generate a random address per power cycle. The address cannot be regenerated at any other time. Can be used as an Identity Address. (ADDRMODE_RANDOM)
Resolvable Private Address (RPA) - Generate a random address with a given time interval. Generated using Identity Resolving Key (IRK) which can also be used by trusted peers (bonded devices) to resolve the Random Address to the Identity Address. A device with a Resolvable Private Address must also have an Identity Address.(ADDRMODE_RP_WITH_PUBLIC_ID)
Non-resolvable Private Address - Generate a random address with a given time interval. Generated randomly. Cannot be resolved to an Identity Address. (ADDRMODE_RP_WITH_RANDOM_ID)

Generating & Resolving Private Addresses#

In order to generate Resolvable Private Addresses, a device will use its Identity Resolving Key (IRK) as an input to the Bluetooth defined Random Address Hash function. The output of this function is used as part of the Resolvable Private Address (RPA). A peer without the IRK will be able to determine that the device is using a Resolvable Private Address, but will be unable to determine the identity address of the device.

Task 1 – Enable Just Works Pairing#

Before beginning, import basic_ble into your workspace. For a refresher on how to import, build and flash basic_ble, please see the Bluetooth LE 5 Fundamentals lab. As a best practice, you should build basic_ble and verify functionality before making any changes.

To configure Pairing, open the SysConfig file → BLE → Bond Manager

1. To start, enforce Just Works pairing by unchecking the MITM Protection box, and set IO Capabilities to No Display or Input Device. We will also uncheck Bonding for now.

../../_images/enable_just_works_paring2.png — Enable Just Works#

2. Build and flash your LaunchPad with your modified basic_ble project then follow the instructions below for your selected peer.

Task 2 – Add Encrypted Characteristic#

There may be some characteristics whose values we are unwilling to share with a peer device over an unencrypted link. In order to protect this data, we will require peers to establish an encrypted link before allowing GATT Reads and Writes to the String Characteristic in the Data Service. This can be implemented with the GATT Characteristic permits.

1. Open simple_gatt_profile.c (located in the Profiles folder in the project)

2. Find the Simple Profile Char 3 in the attribute table and change GATT_PERMIT_WRITE to GATT_PERMIT_ENCRYPT_WRITE.

simple_gatt_profile.c :: simpleGattProfile_attrTbl – Set String Characteristic Value permits to encrypted.#

   // Simple Profile Char 3
   GATT_BT_ATT( simpleGattProfile_char3UUID,  GATT_PERMIT_ENCRYPT_READ | GATT_PERMIT_ENCRYPT_WRITE,    &simpleGattProfile_Char3 ),

3. Rebuild and flash basic_ble.

Task 3 – Enable Passkey Entry Pairing#

Now that we have gone through a basic pairing exercise and have an encrypted characteristic, we can move on to something more secure. If you want to have an authenticated link, you must add protection against MITM attacks. To do this, we will ask users to enter a passkey before accessing our protected characteristic to make sure we are pairing the right devices.

1. Open SysConfig → BLE → Bond Manager and select Display Only Device under IO Capabilities. Then enable MITM Protection. Please note that enabling MITM Protection is only available when the device has certain IO capabilities.

../../_images/passkey_entry_pairing_sysconfig.png — Enable MITM#

This Bond Manager configuration will result in the Passkey Entry association model when pairing with a smart phone (Since the smart phone has the Keyboard and Display IO Capability).

2. Rebuild and flash basic_ble.

Note

Optional: Change the Passkey code.

To change the default passkey value, look into the Pairing_passcodeHandler() function inside app_paring.c and create a new definition (for example: #define NEW_PIN 987654) to replace B_APP_DEFAULT_PASSCODE.

app_paring.c :: Pairing_passcodeHandler() – Modify Passkey define#

#define NEW_PIN 987654

void Pairing_passcodeHandler(uint32 event, BLEAppUtil_msgHdr_t *pMsgData)
{
    BLEAppUtil_PasscodeData_t *pData = (BLEAppUtil_PasscodeData_t *)pMsgData;

    // Send passcode response
    GAPBondMgr_PasscodeRsp(pData->connHandle, SUCCESS, NEW_PIN);
}

Task 4 – Enable Bonding#

For this exercise, we will continue to use Passkey Entry pairing. Enabling bonding will allow us to bypass the pairing process in future connections. The Controller can use the stored keys supplied by the Host to start encryption.

1. Open SysConfig → BLE → Bond Manager and enable Bonding.

../../_images/bonding_sysconfig.png — Enable Bonding from SysConfig.#

2. Rebuild and flash basic_ble.

Task 5 – Using a Resolvable Private Address#

The addresses we generally use in privacy discussions are Resolvable Private Addresses (RPAs) and Identity Addresses. A device using an RPA periodically changes the address it uses over the air. This happens at a specified time interval. The addresses it uses are generated with an Identity Resolving Key (IRK). This key associates the Resolvable Private Address to the Identity Address. (The Identity Address never changes.)

RPAs help inhibit tracking from untrusted peer devices. However, some devices may need the ability to recognize, and be recognized by, their peer devices even after their RPA has changed. Since RPAs are associated with an identity address, they can be resolved to that fixed address by a peer device who has the right key.

Warning

Most BLE5 projects enable RPA’s by default, so this Task may not be necessary in other BLE5 projects.

Below, we will work on configuring the device to use an RPA and learn how to work with it. To enable RPAs in basic_ble:

1. Open SysConfig → BLE → General Configuration and enable RPAs under Address Mode.

../../_images/setRPA_sysconfig.png — Enable RPA in SysConfig#

2. Rebuild and flash basic_ble. You should now see the RPA address in the terminal window.

../../_images/BLE_Address.png — RPA Address in serial terminal.#

Note

Optional: Change the RPA Interval

To change the timeout value between address changes, use GAP_SetParamValue() right below to set the GAP_PARAM_PRIVATE_ADDR_INT parameter. The value is in minutes:

ble_stack_api.c :: bleStack_initGap() – Modify address change interval#

  if (role & (GAP_PROFILE_PERIPHERAL | GAP_PROFILE_CENTRAL))
  {
    //...
    //Set timeout value to 10 minutes
    GAP_SetParamValue(GAP_PARAM_PRIVATE_ADDR_INT,10);
  }

Congrats! You have created a basic_ble that cannot be tracked except by the phone you have bonded to. Look up device specific instructions to clear Bluetooth LE bonding information from your phone if you wish to try this task again.

References#

TI BLE5-Stack User’s Guide

Bluetooth Core Specification Version 5.3

Apple Bluetooth Accessory Design Guidelines for Apple Products