This file type includes high-resolution graphics and schematics when applicable.
Security is one of the most important aspects for any system that contains a user's private information. Examples range from exchange of health information with a fitness monitor, to exchange of confidential data/passwords in applications like payment solutions. Beyond data privacy concerns, an unsecure communication in the Internet of Things (IoT) space can lead to unintended operation of a system if an unauthorized device injects data into said system.
Two concerns must be addressed when designing a secure wireless system: protection against device tracking and protection against unauthorized over-the-air data access. Bluetooth Low Energy addresses these security concerns to enable the design of wireless systems with sensitive user data, ensuring that the device operates only as intended. Device tracking is addressed by Privacy 1.2, which was reviewed in Part 2 of this article series. Here, we will discuss how Bluetooth Low Energy 4.2 makes it practically impossible for an unauthorized device to have access to data or manipulate the system device.
To protect communications from unauthorized access, wireless-system designers must overcome two challenges:
• Protection against the man-in-the-middle attack
• Protection against passive eavesdropping
Man-in-the-middle attack: The man-in-the-middle (MITM) attack is a scenario where, as two devices try to communicate with each other, a third device inserts itself between them and emulates both devices to the other (Fig. 1).
Now, this third device can listen to private communications as well as change the data being sent from one device to other. The third device can also cause the other two devices to perform unintended functions. For example, if wireless communications is being used in home automation and a man-in-the-middle attacker is present, it can cause a door to unlock when it’s not supposed to. Hence, it’s important in any wireless system to ensure that every communication is only to the intended device.
The mechanism to protect against a MITM attack is called authentication. Authentication is the process where two devices ensure that the other device they’re talking to is the intended device, and not an unauthorized device emulating the intended one. Bluetooth has several association models that are used for authentication, discussed later in this article.
Passive eavesdropping: In passive eavesdropping, a third device quietly listens to the private communication between two devices (Fig. 2). Protection against passive eavesdropping is important in applications like payment solutions where confidentiality of information (e.g., passwords) is of utmost important.
Systems can protect against passive eavesdropping by using a key to encrypt data. A third device that’s listening to the data must not be able to find out or guess this key. In addition, it should not be able to make sense out of the data it’s listening to without having the key.
LE Secure Connections, introduced in Bluetooth Low Energy 4.2, uses the Federal Information Processing Standard (FIPS) compliant Elliptic Curve Diffie-Hellman (ECDH) algorithm for key generation (Diffie-Hellman Key, or DHKey). Later, this key is used to generate other keys (Long Term Key). Since the DHKey is never exchanged over the air, it becomes very difficult for a third device to guess the encryption key. With earlier versions of Bluetooth Low Energy (Bluetooth 4.1 or older), devices used easy-to-guess Temporary Keys (TKs) to encrypt the link for the first time. Long Term Keys (LTKs), along with other keys, were then exchanged between devices over this encrypted but potentially compromised link.
Association Models
An association model is a mechanism used by two devices to authenticate each other and then securely exchange data. In Bluetooth, pairing is the process of key exchange (discussed in detail in the upcoming part 4 of this article series). Before keys are exchanged, both devices share pairing parameters that include authentication requirements. If authentication is required, both devices authenticate each other using one of the association models.
Three parameters determine the association model to use between two devices:
1. Requirements for MITM protection: MITM protection necessitates a method of ensuring that the device used in the exchange of bonding data is the right device, and not a device emulating as the right one. This is done via user inputs or by generating a shared key based on mathematical models that can’t be generated by the unauthorized device.
2. I/O capabilities of devices: “I/O capabilities” means the ability of the device to either receive data from a user (e.g., a button or keyboard) or output data to the user (e.g., an LCD display capable of displaying a six-digit decimal number). If a device has either of these capabilities, then the user can be involved in the pairing process—an important ingredient for the secure transfer of data.
3. OOB data availability with BLE devices that need to communicate: Out-of-band (OOB) data is another good approach for transferring a part of the pairing data to ensure that an eavesdropper can’t make sense of the final data transferred over the communication channel. For example, part of the security key can be transferred between the two devices using near-field communication (NFC), whereby the eavesdropper wouldn’t be able to make sense of the final data.
Four association models are available in Bluetooth 4.2 for Bluetooth Low Energy:
• Numeric Comparison
• Just Works
• Passkey Entry
• Out of Band (OOB)
The table shows the association model that can be used, based on I/O capabilities, when LE Secure Connections is used for pairing. However, I/O capabilities can be ignored when MITM protection isn’t required or OOB data is available with any of the BLE devices.
Before discussing these association models in detail, we need to define a couple of the terms used in conjunction with the models:
• Rand/nonce: Rand or nonce represents the 16-byte random numbers exchanged between pairing devices during the authentication stage of pairing. These random numbers are used to generate confirm values.
• Confirm value: Confirm values, which are 16 bytes in length, are exchanged between pairing devices during the authentication stage of pairing. Confirm values are generated by hashing the values exchanged in pairing packets to that point. This may include entities from a pairing request, pairing response, random numbers (rand), and the public keys.
Numeric Comparison
When using a Numeric Compression association model, both devices display a six-digit number. The user then authenticates by selecting “Yes” if both devices display the same number. Initially, in this association model, confirm values are generated using the AES-CMAC function with the public key of each device, a nonce, and an 8-bit code (8-zero bits for Numeric Comparison). The non-initiating device will then send its confirm value, and the local nonces are exchanged between devices. The locally generated confirm value is compared with the confirm value sent by the peer device to make sure they match.
Then the six-digit number is generated locally by both devices using the AES-CMAC function with the public key of each device, a locally generated nonce, and the nonce received from the peer device in the previous step. The output of this function is shown on both devices. A new nonce is generated during every pairing procedure or if the protocol needs to repeat due to any failure.
This association model is introduced in LE Secure Connections in Bluetooth 4.2. With legacy pairing (Bluetooth Low Energy 4.1 or older), these I/O capabilities would have led to a Just Works association model (unauthenticated).
Just Works
This association model is used when either MITM protection is not needed or devices have I/O capabilities as noted in the table. The Just Works association model follows the same steps as mentioned in Numeric Comparison. However, a six-digit number isn’t generated or displayed.
Passkey Entry
In the Passkey Entry association model, the user either inputs an identical Passkey into both devices, or one device displays the Passkey and the user enters that Passkey into the other device. Both devices calculate a confirm value using the AES-CMAC function with the public key of each device, a locally generated nonce, and one bit of the Passkey. Then both devices exchange their nonce and their confirm value. Following that, they compute the confirm value using the public key of both devices, a nonce received from peer device, and one bit of the Passkey. Then the devices compare both confirm values.
In Bluetooth Low Energy 4.2, the steps to confirm value generation are repeated for the total number of Passkey bits (i.e., 20 times for a six-digit decimal number). Exchange of the Passkey one bit at a time in Bluetooth 4.2 is an important enhancement over the legacy Passkey entry model (Bluetooth 4.1 or older), where the whole Passkey is exchanged in a single confirm protocol data unit (PDU). This bit-by-bit disclosure of the Passkey allows no more than two bits of unguessed Passkey to leak before the protocol fails the pairing procedure.
Out of Band (OOB)
The OOB association model is used regardless of a MITM requirement and/or I/O capabilities if at least one device with OOB capability already has cryptographic information exchanged out of band. During the authentication process, only these values are confirmed using the AES-CMAC function. Here, protection against MITM depends on the MITM resistance of the OOB protocol used to share the information. In BLE 4.1 or older (legacy pairing), both devices needed to have OOB capabilities in order to use the OOB association model.
Conclusion
To summarize, security is an essential requirement for most wireless systems. Designing a secure system requires that two challenges be met: protection against man-in-the-middle attacks and passive eavesdropping. Bluetooth Low Energy 4.2 features three association models that provide protection against man-in-the-middle attacks—Numeric Comparison, Passkey Entry, and Out-of-Band. The Numeric Comparison association model is not available in BLE version 4.1 and older. This leaves only the Passkey entry association model for authenticated pairing if OOB data isn’t available.
The Passkey association model requires a keypad to enter the passkey, which may not be possible in many systems, thus limiting its usage for MITM protection. However, Numeric Comparison can be used when just a yes/no option is available with display capabilities, thus extending MITM protection capability to more applications.
In Part 4 of this series, we will talk about the pairing process used in Bluetooth Low Energy.
Refer to application note AN99209 or the Bluetooth Core Specification (PDF download) for more details on Bluetooth 4.2 features.
