This is the second part of Building secure connected devices. The first is available here.
In the first part we looked at the typical attack vectors for remotely accessing connected Wi-Fi devices in the smart home. These attacks could let an attacker control any device half way across the globe. In this part, we will consider the common attack vectors for the (a) local network access and (b) physical access of connected devices.
Local Network Access
Most connected devices offer a local network API for smartphones/laptops to use. The smartphone can query and configure the connected device using these APIs. This allows super fast exchange of information without having to go through the cloud.
Typically, for most homes, the Wi-Fi Access Point enforces a MAC-level security like WPA/WPA-2. This ensures that a phone/laptop cannot get on the Wi-Fi network or read/write packets unless it has a correct secret, passphrase / key, for the network. Since this secret is handed over by the home owner to other persons, it is assumed that anyone getting access to the Wi-Fi network is a trusted person.
This level of security works for most products. It relies on the the Access Point to identify authorized accesses, thus exposing these APIs to anybody as long as they are on the local network.
Additional Cryptography Layer
Some IoT products/ecosystems, like Apple HomeKit, go one step further and implement an additional cryptography layer on top. With this method, the APIs exposed on the local Wi-Fi network are also secure. A client smartphone/tablet requires an additional device secret for it to interact with the device, even though it is on the local Wi-Fi network.
Once this cryptography layer is established, a role based access control could also be implemented. With this you could define what the kids in the house can control as opposed to you or your wife.
Connected devices that implement this should note that it does affect the user experience, particularly for novice users with multiple devices, multiple clients and their differing roles. Care should be taken to expose it intuitively such that it doesn’t become too complex for users to not use it, or misuse it.
Reset Network Settings
The above mechanisms protect the device as long as it is connected to the home Wi-Fi network. Given the above, an attacker might try to force the device to forget its network configuration settings. If the connected device forgets the configuration of the home network, it will typically enter into a configuration mode where it lets a user configure the home network (we will discuss this soon in the next subsection).
Hence, care should be taken to ensure that any action that makes the device forget the home network settings is a deliberate action taken by an authorized user.
New Device Setup
When an end-user brings a smart device home, say a connected light bulb, the first thing that the user has to do is configure it so it can connect to the home Wi-Fi network. Since most of the ‘things’ in IoT are headless, this implies that the user cannot simply enter the network name and its passphrase into the device using the device’s keyboard or touch-screen.
There is a wide variance in the methods for performing this network provisioning step for IoT. This uses some communication mechanism between the user and the smart device to securely transfer the home Wi-Fi network’s credentials. There are many communication mechanisms for this transfer, using NFC, IR, light among others.
The thing to remember in new device setup is to always authenticate the other endpoint
The most common mechanism, that I have seen, is where the smart device hosts its own temporary wireless network. A user’s smartphone can then connect to this temporary wireless network, and then transmit the information over this network.
Given the above, can a malicious user configure the smart device to connect to a malicious Wi-Fi network? Or can a neighbor configure my grandfather’s thermostat to connect to her Wi-Fi network?
Can a fake device be created to deceive the real owner to configure the fake device to their home network? Can my grandfather accidentally configure my neighbor’s fake thermostat to connect to his Wi-Fi network. In the process revealing his Wi-Fi network credentials to the neighbor?
The thing to remember in implementing new device setup is to always authenticate the other end point.
The smart device, being configured, should only let the real owner of the device configure it. This can be done by using some kind of proof of possession, like a secret on the box, or press of a button, or a state of the device. This allows the user to prove that she really owns the device that she is configuring.
On the other hand, the app (smartphone/laptop) that configures the smart device should ensure that it is talking to a genuine smart device that is owned by the user, and not a fake one. This can be done by using some kind of PKI or a challenge-response mechanism.
The final way of interacting with the device is physically accessing it, the old non-IoT way. Physical access is often used for establishing proof of possession and ownership for the local and remote accesses.
Now let’s look at attack vectors where an attacker tampers with a connected device, and then gives the device to the unsuspecting end-user. The goal of the tampering is to eventually either snoop data from the connected device, or write data/commands to the connected device, or perform a DOS.
From an attack point of view, this requires physical presence around the device, it isn’t possible to execute this kind of an attack remotely. Either the attacker’s presence in the home, or his access to the device before it is brought in the home, is required for such an attack. The effort required for such an attack may probably justify a relatively high-profile target, but as IoT penetrates deeper into our surroundings and becomes a norm, this isn’t unthinkable.
If any embedded developer is asked to hack open a device, the first thing he would do is try to get access to the device console or the debugger interface (JTAG/SWD). These should definitely be disabled in production.
Also to note is that any data or firmware on the device flash can be read or modified by removing the flash parts. Security researches frequently do that for analysis [pdf]. Hence, any sensitive data stored on the flash should be encrypted.
If data can be written to flash, an attacker could modify the firmware that is stored on the flash. An attacker could, for example, simply change the server URL and server certificates in-place to those of a malicious server. With such a change the connected device may start reporting data and accept commands from a malicious server without the user ever realizing it.
Many micro-controllers, and most processors, offer trusted boot execution. With such a mechanism, only the firmware that is encrypted and signed with a valid set of keys is executed on the device. The keys are private to the device maker. With trusted boot, if the firmware is maliciously modified as described above, the processor will simply not load the firmware, thus thwarting the attack.
All these precautions could be taken, but what if someone builds a clone of your device, with exactly the same look and feel, but with an altogether different firmware.
For most home devices, the first use of the device starts with phone applications. The phone applications should validate the genuineness of the device. The PKI mechanisms that are used for validating that the remote servers are genuine can also be used for validating that the device is original.
A big advantage of connected devices, over standalone devices, is they can be automatically upgraded to provide newer features. From a security standpoint, as newer attack vectors or vulnerabilities are detected, this allows the manufacturer to fix the issues in the field and provide customers with a more robust product. As Wi-Fi connected devices can directly talk to a remote server, they can periodically look for these upgrades, and automatically download and install these upgrades themselves.
Interestingly, the firmware upgrade mechanism can also be misused to deploy malicious firmware across all your products deployed in the field.
As with the remote access scenario, do ensure that the servers, that the firmware upgrade will be fetched from, are authenticated with TLS (certificates).
As an additional layer of security, also sign and encrypt your upgrade images. Using different keys for different product lines should also be helpful. This additional layer of security ensures that even if the cloud services are compromised for some reason, the connected devices reject the firmware images that may be tampered with.
That concludes this two part series about Building Secure Connected Devices. If you are building a Wi-Fi enabled devices, these articles hopefully serves as a good reference to influence your product implementation.