Bluetooth Has Become the Standard Wireless Technology for the Internet of Things.
Legacy audio streaming and hands-free applications use Bluetooth Classic. Bluetooth Low Energy (BLE) however took Bluetooth beyond audio and made it the de-facto standard for low-power applications that wanted to exchange data with smartphones. Enhancements, such as the Bluetooth Mesh, promise to make Bluetooth the technology of choice for home/building automation and various industrial applications. Because of Bluetooth’s broad scale adoption, over-the-air security has become a must have to prevent unauthorized
access of personal information. Next generation designs also require device-level security to protect the manufacturer’s firmware IP and prevent accidental/malicious reprogramming.
Over-The-Air Security In Bluetooth
To understand the available mechanisms for over-the-air security, it’s essential to understand the concept of pairing in Bluetooth. Pairing is the process of authentication and key exchange between two devices as shown in the figure below.
As seen above, pairing involves 3 phases. Phase 1 involves the exchange of parameters that specify the capabilities of the devices like the capability to output or take input from users. Phase 2 is where the devices are authenticated.
Authentication involves user interaction like verifying if the same code is displayed on your car’s screen and on your smartphone when connecting your smartphone to your car for the first time. Authentication ensures that a malicious device cannot pair with the initiator by acting as the intended responder since the user verifies both ends of the link. Phase 3 is the exchange of keys
that will later be used to encrypt the communication between the devices. Once the devices complete all 3 phases they are said to be paired. Once the devices store the keys exchanged during pairing they are said to be bonded. Bonding eliminates the need to re-pair the devices for subsequent data exchange. Bonding is why your car automatically pairs with your smartphone every time Bluetooth is turned on.
Over-The-Air Security with AES-Based Symmetric Key Encryption
Once the pairing process is complete, both devices have a key to encrypt and decrypt the data being exchanged over Bluetooth. Since the devices use the same key for encryption and decryption, this is called a symmetric key approach. The Bluetooth
stack uses AES or Advanced Encryption Standard with a 128-bit key for encryption and decryption.
The figure below shows how the AES algorithm encrypts 16 bytes of plain text to generate 16 bytes of cipher text. The encryption is performed iteratively over 10 rounds with each round using a different 128-bit key that is derived from the original 128-bit key (exchanged by the devices during pairing).
The AES algorithm is a proven standard and a brute force attack to crack it would require more than ~1018 years with the world’s fastest supercomputer. Cypress’s EZ-BLE™ modules incorporate a 128-bit AES security engine and provide APIs for the application code to access the encryption/decryption functionality. Modules that provide AES functionality include the CYBLE-022001-00 for space-constrained applications and the CYBLE-224110-00 for longrange applications.
The weakness of the AES approach in Bluetooth 4.1 and earlier core specifications lies in the fact that the 128-bit key must be exchanged over-the-air so that both sides possess the same key. If an attacker intercepts the key when it is being sent out over-the-air, the security is completely neutralized since the attacker can encrypt and decrypt the data using the standard AES algorithm. Applications that need exceptionally strong security, like devices exchanging a user’s payment related information, may require measures to address this vulnerability.
Application Level Security With RSA-Based Asymmetric Key Encryption
One of the ways to avoid the vulnerability of an attacker intercepting the AES key is to use an extra layer of encryption in the device’s application firmware that executes on top of the Bluetooth stack in a Bluetooth device. This layer of encryption can use an asymmetric key algorithm like RSA. RSA uses 2 keys – a public key for encryption and a private key for decryption. Since different keys are used for encryption and decryption RSA is an asymmetric key algorithm. A high level view of how RSA would be used with Bluetooth to provide security at an application level is provided below.
As seen above with RSA, both devices generate public and private key pairs. Each device uses the peer’s public key to encrypt information and its own private key to decrypt information. Only the public keys are shared over-the-air. So an attacker that intercepts the public keys over-the-air can encrypt information to send to either device, however it will be unable to decrypt any information since it does not have the private keys of the devices. The asymmetric nature of RSA makes it more secure than the AES-based security built into the Bluetooth stack.
RSA is not part of the Bluetooth specification. Therefore application level firmware needs to rely on manufacturer specific firmware libraries for Bluetooth devices to leverage this feature.
Cypress’s CYW20737 BLE SoC, CYW20737S and CYW20737L EZ-BLE modules provide RSA libraries as part of the WICED SDK (IDE for CYW20737 devices).
The RSA algorithm is not as efficient as AES in terms of processing times. This leads to longer latencies when using RSA with Bluetooth. Since RSA is not part of the Bluetooth specification, Bluetooth devices using RSA can only interoperate with devices from other manufacturers that also provide RSA libraries. RSA is a standard and some Bluetooth SoC/module manufacturers do provide RSA libraries. However, applications that need interoperability with any Bluetooth-based smartphone/PC may choose to avoid RSA-based encryption/decryption.
Enhanced Security With Bluetooth 4.2
The new Bluetooth 4.2 core specification is no longer vulnerable with respect to the AES key being exchanged over-the-air and being intercepted by attackers. Bluetooth 4.2 introduced the LE Secure Connections optional feature that uses the Elliptic-Curve Diffie-Hellman (ECDH) algorithm for key exchange. ECDH eliminates the need to send the keys over-the-air. Instead it derives 256-bit keys on both sides of the Bluetooth link using the Diffie-Hellman algorithm. The figure below uses a simple numerical example to demonstrate how the Diffie-Hellman algorithm establishes a shared secret key between two Bluetooth devices without revealing the key to an attacker.
Since the LE Secure Connections feature is optional, not every Bluetooth 4.2 qualified SoC/module in the market supports it. Cypress’s new CYBLE-222014-01 EZ-BLE module incorporates all the new Bluetooth 4.2 features including LE Secure Connections in a small form-factor for space constrained applications.
Going Beyond Over-The-Air Security
New IoT applications need device-level security measures to protect the manufacturer’s firmware IP residing in the non-volatile memory within the Bluetooth SoC/module. Cypress’s nextgeneration, ultra-low-power, Bluetooth 4.2 SoC – CYW20719 – has 1 MB of probe-proof flash memory and 512 KB of RAM along with an ARM® Cortex® M4 MCU (with FPU). The probe proof flash ensures that once the manufacturer has programmed the flash with their firmware, the flash cannot be read or rewritten. This prevents hackers from reprogramming the device to gain access to sensitive user data or payment information, and prevents competitors from doing a flash dump to reverse engineer the firmware IP. The CYW20719 also provides software libraries for ECDH, RSA, AES, hashing functions SHA/MD5 and a hardware accelerator to ensure best-inclass encryption for Bluetooth. The CYW20719 features ultra-low current consumption to enable long battery life for trackers/smartwatches. In addition the CYW20719 integrates a MIPI DBI-C interface for e-ink/OLED displays. Cypress is sampling the CYW20719 to lead customers now and will be releasing this to the broad market in the form of SoCs and modules in the 2nd quarter of 2017.
|CYW20737A1KML2||SoC||RSA, AES||4.1||Ultra-small form-factor|
|CYW20737S2||Module||RSA, AES||4.1||Ultra-small form-factor|
|CYW20737L2||Module||RSA, AES||4.1||Ultra-small form-factor, 1.2V operation|
|CYW20736E2||Module||AES||4.1||Ultra-small form-factor, external antenna|
|CYBLE-224110-003||Module||AES||4.1||Extended range and temperature|
|CYBLE-014008-004||Module||AES||4.1||Small form-factor, integrated analog/digital|
|CYBLE-214009-003||Module||AES||4.1||Small form-factor, integrated analog/digital|
|CYBLE-222014-013||Module||ECDH, AES||4.2||Small form-factor|
|CYBLE-214015-013||Module||ECDH, AES||4.2||Integrated analog|
|CYBLE-212006-013||Module||ECDH, AES||4.2||Extended range|
|CYBLE-202007-013||Module||ECDH, AES||4.2||Extended range, external antenna (uFL)|
|CYBLE-202013-113||Module||ECDH, AES||4.2||Extended range, external antenna (solder pad)|
|CYBLE-224116-013||Module||ECDH, AES||4.2||Extended range and temperature|