Secure BLE Pairing for IoT

Published on June 19, 2015

Archived Notice

This article has been archived and may contain broken links, photos and out-of-date information. If you have any questions, please Contact Us.

Secure BLE Pairing for IoT

Privacy and security are critical in wireless designs and should always be top concerns. With the release of Bluetooth v4.2, which the Bluetooth SIG says is the ideal technology for the IoT, internet connectivity for a Bluetooth v4.2 device is much easier and more secure resulting in more and more wireless designs being embedded with BLE. Here’s a look at the level of security in the pairing procedure for Laird’s BL6x0 Series and BT900, winner of ECN’s impact awards.

Privacy and security are critical in wireless designs and should always be top concerns. With the release of Bluetooth v4.2, which the Bluetooth SIG says is the ideal technology for the IoT, internet connectivity for a Bluetooth v4.2 device is much easier and more secure resulting in more and more wireless designs being embedded with BLE. Here’s a look at the level of security in the pairing procedure for Laird’s BL6x0 Series and BT900, winner of ECN’s impact awards.

Pairing Procedure Phases

Phase 1 (no encryption): Request for Pairing-Exchange I/O capabilities, Authentication requirements, maximum link key size negotiation, and Bonding.

Phase 2 (no encryption at beginning and encrypted data at the end of the phase): Random and Confirm values are exchanged (association model based on I/O and Authentication requirements for both devices) and used to generate short term key (STK) along with the ‘secret’ Temporary Key which NEVER appears on air. At the end of phase 2, the connection is encrypted using the STK with EDIV and RANDOM values set to 0.

Phase 3 (encrypted using the STK from Phase 2): Optional phase, invoked only if bonding requirements exchanged during Phase 1. Encrypted connection established using STK

​During this phase, keys and values for identity/encryption/authentication are exchanged between Master/Slave.

The Identity Resolving Key IRK (128 bit) is also optionally exchanged during this phase which is used, along with a 24-bit random number to resolve the Random Private Resolvable address if the peer is going to use resolvable addresses. For example, iOS devices that use resolvable addresses by default.

The Connection Signature Resolving Key (CSRK) is also optionally exchanged if signed data in attributes need to be exchanged.

The Public IEEE or Random Static address is exchanged during this phase if requested and it is highly recommended if the IRK has been supplied and resolvable addresses are going to be used in communications.

*Note: This section was previously published in EE Catalog, August 2014

BL6x0 and BT900 Pairing Procedure

In addition to supporting the Passkey Entry and Just Works Association Models (Out of Band (OOB) to be exposed in a later firmware release), Laird’s BLE modules increase security and limit MITM attacks (eavesdropper protection) via Whisper Mode Pairing. Whisper Mode pairing reduces the transmit power during the pairing procedure and effectively limits the “bubble” in which eavesdroppers would be able to “listen in” on the public key exchange (STK) in Phase 2. This in turn increases the chances for completely secure key and value exchanges in Phase 3.

The function BleTxPwrWhilePairing(nTxPower) sets the transmit power for ALL packets transmitted while the Pairing Procedure is in progress. nTxPower can be any signed integer value but the actual value chosen by the BL600 will be chosen by scanning through the value list: (4, 0, -4, -8, -12, -16, -20, -30,-55) and choosing the highest value in the list which is less than the desired (nTxPower) value selected when issuing the function/command. At a nTxPower== -55, the “bubble” of influence is reduced to a 30cm radius which can be reduced further with device enclosures.

The BL600 smartBASIC programming language includes additional cryptographic functions that can be used to encrypt/decrypt data in addition to any crypting applied at the transport layer. The BL600 supports three block cipher modes of operation:

ECB- Electronic Codebook (Simplest encryption mode)

ECB-XOR- Electronic Codebook w/XOR using Initialization Vector (IV)

CBC- Cipher Block Chaining (Most commonly used encryption mode)

Since each of the supported modes uses the same encryption key for both encryption and decryption, they are all “Symmetric Algorithms”. There are three smartBASIC cryptographic functions:

AesSetKeyIV(mode, blocksize, key$, initVector$)

AesEncrypt(inData$, outData$); Since the BL600 includes AES 128 encryption hardware assist, this function has been timed to take ~125us

AesDecrypt(inData$, outData$); Since the BL600 does NOT include AES 128 decryption assist hardware, this function has been times to take ~570us

See the smartBASIC User Guide for details about these functions and further information.

For more technical information, download the BLE and Laird's BL6x0 Series & BT900 Modules: A Guide to Security and Privacy white paper.