Application Layer Security#

Relying entirely on Bluetooth security features also means relying on the security of the peer device’s Bluetooth stack. Doing so introduces additional unknowns. As well as the potential of unpatched vulnerabilities in an unknown stack, the remote device may share the Bluetooth connection with multiple applications. This can lead to compromised integrity and/or confidentiality. The solution to this problem is for the application to form a secure link on top of the Bluetooth connection by establishing an authenticated, shared secret key and encrypting data with that key before sending it over the Bluetooth connection. This section discusses the key components involved in using application layer security: authentication, key agreement, key derivation, and encryption.

Secure Identity#

A common problem with small IoT devices is that they have no user interface to authenticate the device’s identity, such as entering or confirming a passkey. A device that cannot be authenticated is unable to take advantage of man-in-the-middle (aka machine-in-the-middle) protection. One solution to this problem is to use secure identity certificates to uniquely identify a device. A signed certificate chain, along with the corresponding private signing key, is stored on the device. The device’s certificate chain can be sent over the Bluetooth LE GATT to the peer device to authenticate its identity. More information on secure identity certificates is available in Authenticating Silicon Labs Devices Using Device Certificates. The communication flow is illustrated in the following figure.

Key Agreement#

An important step in securing data at the application is for the two peer devices is to establish a shared secret. The accepted method for doing so is by ECDH as mentioned earlier. A brief description is found at https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman. To perform ECDH over Bluetooth Low Energy, GATT characteristics can be set up to store the public key for each device and then the keys exchanged like any other data. To ensure that keys have come from a trusted source, they can be signed with the sender’s secure identity key. Once the public keys have been exchanged, a shared secret can be computed. A key derivation function is usually applied rather than using the shared secret directly.

Key Derivation Function#

A key derivation function takes a shared secret and transforms it to introduce some additional entropy, or randomness. A typical method for deriving keys is by using a cryptographically-secure hash such as SHA-2/256. Silicon Labs series 2 devices also provide hardware acceleration for other key derivation functions such as PBKDF2 and HKDF. Derived keys with persistent storage should be stored using the most secure method available. Secure Vault High parts can wrap, or encrypt, keys. See Secure Key Storagefor more information on this topic.

Application Layer Encryption#

This section describes the encryption of user data before it is passed to the Bluetooth stack to be sent to a peer device.

Encrypting and Authenticating Data#

Once a shared secret has been established and symmetric keys derived, sensitive data can be encrypted/decrypted and authenticated. Several cipher modes are accelerated in hardware.

Counter with Cipher Block Chaining Mode (CCM). This cipher mode combines a counter with CBC-MAC to provide several benefits. It is possible to authenticate both encrypted and unencrypted data in the same message, known as authenticated encryption of associated data (AEAD). A unique initialization vector is required for each message sent. A brief description is found at https://en.wikipedia.org/wiki/CCM_mode. When this mode is used, the data, initialization vector and authentication tag can be sent together in a single block

Galois Counter Mode (GCM). This cipher mode is like CCM described above but uses a different method for authenticating data and lends itself to parallelization. A brief description is found at https://en.wikipedia.org/wiki/Galois/Counter_Mode. As with CCM, the initialization vector, data and authentication tag can be sent together in a single block.

Encryption-Only Cipher Modes#

Encryption-only cipher modes are also supported in Silicon Labs series 2 devices in case authentication is not desired. The reference manual for your chosen device documents all cipher modes accelerated in hardware.

Application Layer Encryption Example#

The example accompanying this application note, available on https://github.com/SiliconLabs/bluetooth_applications , demonstrates a method for implementing application layer encryption with authenticated key exchange using device identity certifications. Two projects are included: one for the client and the other for the server. The communication flow is summarized in the following table.

The characteristics used in this communication flow are summarized the following table.

Other Application Security Concerns#

Beyond using the security features incorporated into the Bluetooth specification itself, an application can take several steps to implement higher security.

A common type of attack relies on buffer overflows. For this reason, it is highly recommended that applications validate the size of data being received before attempting to store it. Whether a block of data is received through a notification/indication, write or a response to a read request, the size of the data received is always reported by the stack. The size parameter must be used to determine if the application has reserved sufficient space to store it.

Secure Boot#

The ability to ensure that authentic firmware is running on the device is possibly one of the most valuable security features available. Many attacks rely on the attacker’s ability to gain control of the device by some method such as remote code injection. Silicon Labs’ secure boot with root of trust secure loader (RTSL) provides additional security by verifying the authenticity of the firmware using an ECDSA digital signature and an immutable public key stored on the device. See Series 2 and Series 3Secure Boot with RTSL for specifics on using secure boot.

Signed and Encrypted Firmware Updates#

One concern with over-the-air (OTA) updates is that the firmware could be stolen by sniffing the Bluetooth connection, since the Silicon Labs AppLoader does not support encrypted connections. The solution is to encrypt the firmware image itself and allow the bootloader on the device to be updated to perform the decryption. Firmware images can also be signed to prevent inauthentic images from being flashed into active memory in the first place. The signature of the update images is verified using the device public signing key.

Subscribe to Security Advisories#

Silicon Labs recommends that all customers subscribe to security advisories to be aware of the latest threats and mitigations. See www.silabs.com/security for instructions.

Additional Reading#