Can you Really Trust the Cloud for Smart Home Devices?

Updated on 31st Aug 2020 20:27 in IoT, Smart

While smart devices become more prevalent in households everywhere, a common concern is the security of it all. Now that WiFi cloud systems are readily available, and are probably the kind of device most people own, the question is, can you trust cloud-based devices? 

The answer is complicated. It depends wildly from one product to another, and even then there's no way to know how a product has been designed, leaving any doubts about its security completely unanswered. First, let's specify that a cloud-based device is any smart device that connects over the internet to a company's server to function. The most common way to identify these is during the setup process. If it requires the use of a smartphone to configure the WiFi details, then just "works" from the app without further configuration - it's probably a cloud device. 

Smart cloud devices. Are they safe?

Are cloud-based smart devices secure?

It depends. As mentioned before there are a lot of different ways a smart cloud system can be implemented, and it would be impossible to test them all. There will be expected variations when comparing a 10$ bulb to a 60$ version, and worst is that while paying more usually gets a better product, there's no guarantee that the security will match the price. 

Why might they not be secure?

In a paper written by Wei Zhou et al. (2019), they discuss the types of attacks that they were able to find in the smart devices they tested. All of the machines were cloud dependant, meaning they could not function without the internet and a remote server which acts as a controller. In their study, they found a variety of possible attacks that can be performed on cloud-bound smart devices. Most of them involve a man in the middle attack (MITM) to figure out information about each device and how it can be hacked.

Wait, what's a Man-in-the-middle attack?

To understand how devices can be vulnerable, it's essential to take a detour to talk about encryption for a moment. Most devices use a protocol called Transport Layer Security (TLS) to secure the connection between two points. It is the same technique used to secure this very website and is recognizable in the browser with the little padlock icon that appears next to a URL to indicate the connection is secure. 

The reason this protocol is so great is that it allows two computers connected via an untrusted (unsecured) network to talk to each other with an encrypted channel. There are many different ways to encrypt data, but the issue is that for a lot of them, the two nodes require knowledge of each other before being able to connect. An excellent example of this is how most WiFI networks are secured. When you type in the password, you are actually providing a key that the device will use to decrypt the information being sent wirelessly.

Hold on, if most encryption requires the involved parties to have shared information before the connection, how does TLS manage to get around this? It's quite complicated, and many sites can explain the procedure much better than I could. The important thing for us is to understand that as a part of this process, the server will present its digital certificate to allow clients to validate who exactly it's connecting to. 

The server's digital certificate is signed by a Certificate Authority (CA) that will vouch for the server's authenticity and that CA signature is what allows a client to know that this server is who it thinks it is. This is key for the process to work correctly - the client must have a copy of the CA's certificate locally installed within its trust store. 

The trust store is what allows this system to work as if a certificate is not signed by a CA in the store the client will refuse the connection, and it will need investigating. Many attacks can be blocked in this way since CAs are unlikely to sign the certificate of imposters. TLS also has a mechanism in place to detect situations where the certificate is trusted but has changed since the last connection, which can help alert users to what might be happening.

So now really, what is a MITM attack?

These attacks work by taking advantage of the fact that a client's connection is only encrypted between itself and the server. The idea is that by pretending to be the server, an attacker can fool all of these security measures as clients will see themselves connected to a server with an encrypted connection, and servers will see the same in reverse. The way these are foiled is by using the previously mentioned trust store. If someone is pretending to be me and has set up a server to act precisely like mine, clients will detect a problem if the attacking server's certificate isn't signed by a CA in the trust store. 

Man in the middle attack diagram
A simple man in the middle attack

As a result, these can only be performed in situations where the client's certificate store can be altered or where a big name CA has made a big mistake. Check out this post where I actually hack a device's CA store on purpose to gain local control of it on my network, effectively disconnecting it from the cloud. 

It is quite unlikely that this is how your device will be hacked, but it's essential to understand because MITM attacks are how attackers gain insight into how these systems work and how they may be vulnerable. So now - onto the actual ways your device could be hacked.

Attack #1: Phantom device

This attack involves binding a fake device developed by an attacker to the cloud network as if it was your real device. These can be created entirely in software and cause the cloud server to believe it is talking to the device you initially connected to it when, in reality, it's connected to software pretending to be your device. 

This attack can be used to steal personal information, depending on what the device being imitated does. In severe cases, this could be a device like a smart lock or some other security system that can reveal the times you are in or out of the house. Depending on the device, they found that this attack could be performed with very minimal information about the target, such as the MAC address or some other information listed on the label.

An example phantom attack
An example of a phantom attack.

Attack #2: Remote hijacking

This is a continuation of the previous attack, and can effectively be done simply by unbinding the phantom device from the target user's account and rebinding the real device to the attacker's account. The unbind request will be authorized because from the server's perspective, it received it from the actual device. Once the device is bound to the attackers, account they have full control over it and can operate it remotely. 

Attack #3: Denial of Service (DOS)

Denial of service attacks can also be used on smart devices. The study found that some platforms accepted device unbind requests that were maliciously issued by attackers. As a result, the smart device will be unpaired and will not work until the owner repairs it with their account. While this attack is less scary, it is still very inconvenient for the users.

What measures exist to prevent this?

As we saw earlier, most devices make use of a predefined certificated that is installed within each device that allows it to know if the server it's connected to is legit. As a result, traffic between each device and the server will be encrypted and be unreadable to any attackers. Of course, should the company ever be forced to change their server's CA certificate, all the devices you own will become useless unless the stored certificate can be updated.

That's a bit of a doomsday scenario, but it's not impossible. One thing worth thinking about is that even if the device can be updated via something like over the air update (OTA) this actually opens up an additional attack method by maliciously updating devices. As far as I know, this hasn't been done, but it is a possibility with remote updates.

Are hubs any better?

A typical hub, such as Z-Wave or Zigbee, would not be vulnerable to these attacks because the devices do not transmit anything over the internet. Most hubs act as a controller on the local network, and as such any communications a device may require would never leave the safety of your home. The key is that none of this traffic ever leave the local area network, removing the possibility that someone could hijack the connection in the first place. It's worth mentioning that if the hub is internet-connected, to allow remote control, for example, it may be vulnerable to other types of attacks. 

Diagram of a typical smart hub setup
A typical smart hub setup.

Other cloud problems

The cloud is handy mainly for its convenience. Users don't need to buy a particular server or a hub that will control things locally. They don't need to spend time ensuring it's compatible with the system they already have or thinking about what other devices they might want in the future to ensure compatibility. It really does "just work".

All this convenience comes at a cost, though, for one without the internet, most of these devices will simply stop working. If they can't connect to a central server to receive commands, they will simply do nothing and not be operational while there is no connection. This means that I recommend people with a less than ideal internet connection avoid cloud devices.

Furthermore, the continued function of your smart device relies on the 24/7 operation of the company's servers. If the company ever went out of business or shut down the product line, there would be no way to continue using them. They will become obsolete instantly, even if they are brand new. 

DIY platforms

Some DIY platforms like Home Assistant and openHAB offer some degree of protection against these problems. While not all devices support local connection, those that do will connect directly to the Home Assistant server that is running on the local network. Just like with the hubs, this means that by cutting out the internet, we have substantially reduced our attack surface. Unfortunately, some devices still operate via the cloud when using these platforms - they just have HASS or openHab send commands to the cloud server instead of to the device directly.


Overall, cloud devices aren't all bad. They offer fantastic convenience features, and their user experience is truly unparalleled. It's possible to buy stuff from all sorts of different companies without thinking about compatibility because you know that they have an app that you can use to operate it. However, this convenience comes at the cost of placing the security of your devices into the hands of manufacturers.

As we saw, all of the attacks we saw were performed on the cloud service its self, rather than trying to hack individual devices. Even without thinking about security, there are still concerns about the operation of these cloud services, how long will they run for? What if the internet goes out?

So what do you think? Do you use cloud devices in your home? Let me know in the comments below!

Other Posts