Navigating the IoT security minefield: Securing device-to-cloud flows
Here we go again — another month, another IoT security issue in the news; this time a report by the BBC about how vulnerable MiSafes child-tracking smartwatches are to hackers. If you are one of the many parents that find comfort in knowing where your child is, you should understand more about the vulnerabilities with products like the MiSafes smartwatch before rushing out to purchase one.
The security issue in the case of the MiSafes device lies in how the watch communicates to the cloud. With this device, the only factor used to authenticate the watch to its cloud platform is a unique ID. Once a malicious user determines how the watch communicates to the cloud, he can easily replicate the authentication flow and then, by changing the ID, can gain access to the personal information of other users. That personal information, in this case, could include details such as the child’s name, gender and date of birth.
In this instance, it appears that the developers didn’t focus on securing the product and instead used one of the easiest and most vulnerable ways to authenticate the device. There are much more robust approaches to security when building an IoT device, especially one tied to a service that will collect and store personal information that could be easily exploited.
Arguably, authentication is the most important part of device-to-cloud API communication. After all, if a hacker can get past authentication, he essentially has the keys to the kingdom. One robust and proven way to achieve strong authentication for IoT devices is using a hardware cryptographic technology like Trusted Platform Module (TPM). TPM, along with private/public key cryptography, provides a highly secure way of authenticating a device.
It’s also important to note that if TPM chips are not built into the IoT system or if the TPM hardware is too expensive relative to the device itself, you can still use private/public key-based authentication. However, a unique key or identifier (private key) will not be as safe, given it would be available to anyone with physical access to the device storage.
Another important factor when communicating between devices and APIs is transport security — only strong crypto protocols, such as the ones included in TLS 1.2, should be used. And, of course, the API security itself is of paramount importance. More about that in the next iteration of this series.
So, the lesson from this MiSafe example is that all IoT devices must prioritize security to avoid vulnerabilities being exploited.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.