Overview
With millions of Bluetooth Low Energy (BLE) IoT devices deployed per year, comes the responsibility to secure them. BLE was designed for low power personal area networks. Security was not a focus while designing it. But nowadays, BLE devices are an important part of IoT networks where these can be a matter of life and death.
There are two types of IoT architecture using BLE:
1. BLE device sends data to the gateway which is the user's app. The user can see this data and also this data is relayed to the cloud for storage. For example, fit-bit. This architecture can be shown as:
public cloud <--------> smartphone/app <-------------> BLE devices
|____________| |___________________|
Public network Private network
2. BLE device sends data to the gateway which in turn sends this data to the cloud. The user can access this information via an application. For e.g. home automation, medical components etc. A typical route from a BLE device to the user for this type of architecture can be shown like this:
app <----------> public cloud <--------> gateway <-------------> BLE devices
|_________________| |___________________|
Public network Private network
Security
Security has been a great concern for BLE devices in IoT networks because they are connected to public networks via gateways. The data to and from these devices can be modified and disrupted by hackers present in both public network and personal network. Even the devices itself can be controlled by hackers if security is not implemented properly.
With the introduction of new BLE 4.2, security is enhanced between the gateway and the BLE device using stronger encryption algorithms like Elliptic Curve Diffie-Hellman but the other components of the network can still be insecure. So, an end-to-end security approach is needed for this kind of IoT networks.
Vulnerabilities
There are vulnerabilities on the private side of the network i.e. BLE sensors network. Even if the connection between the BLE device and the gateway is encrypted using LE secure connections available in BLE 4.2, the data is decrypted by the Bluetooth stack link layer on the gateway before sending it to the upper layers for processing. This decryption can be a point of vulnerability.
Also, the cloud is on public network which is exposed to hackers. There are many vulnerabilities in this type of structure. Hackers can get access into the cloud itself as evident by the Apple iCloud hack. If the data is sent to cloud via a unencrypted medium, it can be modified in between.
Protecting Data on Gateway
The data sent from the BLE device, should not be decrypted on the gateway side because every decryption is a vulnerability. Unlike IP-based IoT networks, the data sent from the BLE device to the gateway is very small amount of data for e.g. various sensors in smart home systems. The data is sent from these sensors periodically in some KBs only. This data can be sent directly to cloud without any type of aggregation on the gateway.
In BLE 4.2, LE secure connections can be used to transfer packets securely from BLE device to the gateway. But when the gateway receives these packets, they are first decrypted at the link layer and then forwarded to upper layers. Now, these decrypted packets which have user data in plain text is a vulnerability too. If someone hacks into the gateway, then he can see all the sensor data in plaintext and can modify it before sending it to the cloud.
To counter this problem, one option can be to encrypt the user data on BLE device, send it to the gateway, gateway publishes this data directly to cloud and cloud has the key to decrypt this data. But this whole architecture needs a key management mechanism to be implemented by the application itself on the BLE device. Doing these kinds of operations on BLE device are difficult due to low processing, low storage, limited power etc..
This problem can be tackled by doing modifications in the Bluetooth stack on gateway side. Why not directly transfer the data from the physical layer of the Bluetooth stack directly to the cloud? Since the data coming from BLE devices is not a large amount of data, it can be transferred directly. The link layer and rest of the upper layers can be emulated on the cloud which processes the data coming from the gateway side. The data received from the gateway side is raw physical layer data. This solution can be called as a remote Bluetooth stack.
For this solution, customized Bluetooth chipset because vendors ship both physical layer and link layer along with the hardware.
Protecting Data on Cloud
To protect the data on the cloud, the public cloud has to be replaced by a private cloud. But the problem comes is how this cloud would communicate securely with the gateway and the user?
To send data to and from the gateway and the cloud, a publish/subscribe service with end-to-end encryption can be used for e.g. Pubnub. This service will publish the data to the cloud. This service uses end-to-end encryption and also the data inside the encrypted message is also encrypted with Bluetooth LE security, thus providing a two-layer security.
Also, the user can access this data using same publish/subscribe service having end-to-end encryption. Thus, the cloud is not exposed to the public network. The new end-to-end encrypted secure architecture can be shown as:
User/app <----------> public cloud <--------> gateway <-------------> BLE devices
|______________________| |_______________________|
Private network Private network
Secure BLE IoT network architecture
One step further
One more step can be to keep all the key information on the user side instead of a cloud. Thus, mitigating any vulnerability on cloud side too. Only two entities will have the keys: BLE device and the user application. Thus, providing a complete end-to-end encryption architecture.
Disclaimer: The material explained in this blog is patented by Wispero Networks Inc. which is working on IoT Security Management.
Author: Amit Chahar
Organization: Wispero Networks Inc. (http://wispero.com/)
Comments