Where most IoT products fail?

The Sacrifice of the Queen

Most of the IoT products are very small in size, and some of them may not have an interface at all – maybe just a push button. They are tiny with small battery hence are low-powered devices. A low power consumption is needed. And that’s their challenge. Often, the products needs to communicate either to their gateway or to a mobile application. That’s where often the mistake happens. They do sacrifice the wireless security for the sake of simplicity and cost.

The Wireless Medium

In this article we are going to talk about Bluetooth-Low-Energy communication and discuss some vendor implementations mistakes while discussing best practices.

Most of the products we see communicate with a mobile application which allows the user to tune some parameters of the device. Such parameters however, may be critical for the lifetime of the device, its availability or the compromise of sensitive user data.

In the next chapter we’ll analyze how the vendors fail to secure their communication, in which part of the communication most products fail and what can you do for your own product – so you can make sure this won’t happen to you.

The Failure

Authorization Bypass

Don’t be surprised. You may have seen this vulnerability class in your web application tests, but this class also tend to appear in BLE products too.

For those who are unaware about this vulnerability class, it happens when a functionality of the device should be reached only by authenticated users but because of the vulnerability unauthenticated users are able to use it as well.

We tested a particular lock which didn’t prevent the unauthorized user to unlock it. Here is the packet sent to unlock the lock:

Client >> Device(ffe9) : 0100
Client >> Device(ffe1) : ff01000011

The communication of the application layer is found to be encrypted. The first packet enables the device to be able to send us back messages where the second packet contains the preamble and suffix bytes (0xff and 0x11) as well as the main data package (0x010000). The first byte is used for unlocking the device (0x01). Sending directly such a packet and encrypting the packet using the encryption key found in the application. It turns out anyone can unlock the lock. Therefore, the authentication of the lock has been bypassed.

To address this vulnerability, the developers must make sure the user of the current session has been authenticated before giving access to the unlock functionality. This is possible as many BLE vendors permit to install callbacks to any attribute read or write operations.

Encryption using a Static Key

We’ve found a lot of devices using application-layer encryption. We are unsure if this is even necessary as the BLE protocol supports encryption on its own. However, no BLE encryption is enforced. Beside that mistake the whole custom communication protocol is encrypted using insecure cipher modes and static keys. Mainly the developer’s idea is to transfer the app data via an insecure channel and provide encryption to the data using a key burred into the app with the hope that nobody is going to find it.

This is a misconception and an excuse based on the minor difficulty needed to make a proper protocol and properly configure the device to support modern pairing methods. Also, is a factor of cost, and often low-cost products can’t afford the luxury of security, and thus users may suffer.

Here is an example of a decompiled code of a BLE mobile app, that contains the encryption method and the key at the same class. The code is not stripped either.

public class AES {
    ...SNIP...
    static byte[] sKey = new byte[]{(byte) -41, (byte) -7, (byte) -13, (byte) , ...SNIP...};
  
    public static byte[] Encrypt(byte[] bArr) throws Exception {
        Key secretKeySpec = new SecretKeySpec(sKey, "AES");
        Cipher instance = Cipher.getInstance(MOD);
        instance.init(1, secretKeySpec);
        bArr = instance.doFinal(bArr);
        return bArr;
    }
    ...SNIP...

The above method “Encrypt” is used to encrypt the communication using the key stored in the variable “sKey”, which is a static key and anyone can find it, if able to dig enough into the application.

To remediate the issue, the vendor must transfer the encryption from the application layer to the lower layers such as SMP (Security Management Protocol) which is a layer of the BLE responsible for handling the encryption process.

Pairing Parameters & Configuration of the peripheral

Almost all of the BLE system-on-chip solutions offer a way to fine-tune the proper parameters and have provide to the user a secure session. Even though this is true, many choose not to follow the general guidelines and walk toward the easy path. A BLE have many pairing methods, however, if the device doesn’t have any interface or physical user input (such as a button) it’s like a dead-end. The device has no choice but to pair with the peer device in the “most” secure way possible. However, when no user intervention, no authentication is possible, and so the session can be spoofed or interrupted by a Man-in-the-middle.

The remediation is not an easy step, but is a step forward to success, as you go forward to secure the connection by unloading everything to the SMP. If you don’t have any way for the BLE SoC to accept any input, so the user can confirm or deny the PIN, you are heading to an insecure configuration.

Would you like to learn more? Do you develop any product and need help securing its BLE setup and the communication protocol? Contact us, we can help you out!

Summary

The BLE protocol is evolving faster than anyone expected. If you develop any BLE product you must make sure you cover at least the basic security configurations to protect your users from any kind of attack. In this article we didn’t even scratched the surface of the BLE security area. However, if you like to learn more, we offer a comprehensive training kit that teaches everything about BLE security. Follow us on our social media to benefit from our free webinars.