Last week, the Bluetooth SIG announced an update to the Bluetooth specification in response to a security vulnerability related to Secure Simple Pairing and LE Secure Connections.

According to the SIG, researchers at the Israel Institute of Technology identified that the specification recommends, but does not require, that a device supporting these features validate the public key received over-the-air when pairing with a new device. The Bluetooth SIG has now updated the Bluetooth specification to require the validation of such keys.

At initial connection, when pairing Bluetooth devices, the devices use mutual authentication to securely connect. The SIG has discovered the security vulnerability in the reference implementation of the public key validation during this mutual authentication (https://www.bluetooth.com/news/unknown/2018/07/bluetooth-sig-security-update).

This means that an adversary could perform a man-in-the-middle attack during the pairing process, even for authenticated pairing schemes like numeric comparison or passkey entry. This allows the adversary to listen to and/or modify all the communication on the paired connection.

Our Wireless Gecko products (Blue Gecko and Mighty Gecko) are not affected by this issue because they leverage the mbedTLS ECDH implementation that does not have this vulnerability. The BLE112, BLE113, BLE121LR and BLED112 modules are also not affected because they do not implement the feature that contains the vulnerability. Our BT Classic products, which include the BT111 and WTxx modules, are not affected.

Our BT121 Bluetooth dual mode module is vulnerable to this issue. We expect to release a patch that protects against this vulnerability within 17th August 2018.

Last week, the Bluetooth SIG announced an update to the Bluetooth specification in response to a security vulnerability related to Secure Simple Pairing and LE Secure Connections.

According to the SIG, researchers at the Israel Institute of Technology identified that the specification recommends, but does not require, that a device supporting these features validate the public key received over-the-air when pairing with a new device. The Bluetooth SIG has now updated the Bluetooth specification to require the validation of such keys.

At initial connection, when pairing Bluetooth devices, the devices use mutual authentication to securely connect. The SIG has discovered the security vulnerability in the reference implementation of the public key validation during this mutual authentication (https://www.bluetooth.com/news/unknown/2018/07/bluetooth-sig-security-update).

This means that an adversary could perform a man-in-the-middle attack during the pairing process, even for authenticated pairing schemes like numeric comparison or passkey entry. This allows the adversary to listen to and/or modify all the communication on the paired connection.

Our Wireless Gecko products (Blue Gecko and Mighty Gecko) are not affected by this issue because they leverage the mbedTLS ECC implementation that does not have this vulnerability. The BLE112, BLE113, BLE121LR and BLED112 modules are also not affected because they do not implement the feature that contains the vulnerability. Our BT Classic products, which include the BT111 and WTxx modules, are not affected.

Our BT121 Bluetooth dual mode module is vulnerable to this issue. We expect to release a patch that protects against this vulnerability within 17th August 2018.

Hi,

Check out our recent press release:

http://news.silabs.com/press-release/product-news/silicon-labs-and-arm-collaborate-drive-future-low-power-arm-mbed-iot-devi

Not only are the Giant, Leopard, Wonder and Zero Gecko STKs released as mbed platforms on April 20th, we have also implemented mbed low power APIs to make our platforms inherently low power!

Cheers

Hi,

We all agree that mbed support is a great eco-system, and that is would be beneficial to have EFM32 support mbed.

For the time being, Silicon Labs is offering a free IDE in Simplicity Studio. Porting a project into Simplicity Studio IDE and C is probably less effort than mbed enabling EFM32.

Cheers!