The Internet of Things (IoT) often brings us convenience, economy, fun, and security, but it’s also a source of numerous challenges for developers, installers, and maintainers. In this article, we are talking about one facet of the global IoT challenge – secure remote access.
Every small piece of a Smart Home, be it a Thermostat, a Security Sensor, or a Light bulb, has direct, or more often indirect, access to the Internet. Local or near-field security is a very important topic – but its meaning can’t be compared with security of access to the Cloud services responsible for configuring, notification, alarms, and all other things that make our homes smart. Personal computers, smartphones, printers, NAS have network connectivity that lasts a very long time, but we should not forget that compromising some of the small home devices mentioned above would allow an attacker some control over the physical world, which is definitely a different type of risk than associated with a personal computer.
For example, imagine an attacker has access to notifications from the home’s Thermostat. He can’t control the Thermostat, however, he has access to current mode and temperature. And using this harmless data he not only violates the abstract privacy, but most likely also knows the schedule of the house occupants, as well as if someone is home at that particular moment.
The recent research published by Symantec shows the following vulnerabilities are common for almost all Smart Home Solutions.
While passwords, encryption, account enumeration, and supply chain attacks are more or less obvious and are usually related to the user experience or the corresponding standards, attacks and issues on remote access security (including web vulnerabilities, mitm attacks, and firmware tampering) should be mitigated during design and development.
So yes – it’s recommended to have secure access from Smart Home devices or Gateways. And of course there are dozens of solutions suitable and secure, at least at the current technical level. However, sometimes even a security professional asking, “what to secure?” forgets about the “when.”
What percent of devices in the field are manufactured inside a vendor’s own facilities and prototyping factories? It’s hard to know the exact answer without using floating-point operations. And even the best scheme following all standards and guidelines can be compromised during manufacturing. So here’s where the challenge becomes really intriguing.
This leads to the following requirements:
With server side validation, everything is more or less standardized. The only thing required to add to the common pattern is custom security materials for each client for the purpose of client identification.
From the client side the solution is trickier – tens of thousands of devices are in sleep mode in a warehouse somewhere when it is discovered that the server is compromised, and, as a consequence, they can’t be reprogrammed. This leads to an additional server validation service. It can be, for example, a dedicated OCSP server or some custom solution with only one function – inform the device that the server’s security materials are compromised.
When talking about compromising during manufacturing, there’s another well known, but not so widely used option – updating security materials when the device is installed. It may be manual activation via the web or just an update on first connection.
These 3 simple principles make the entire system much more secure and, as a bonus, this scheme can be implemented using open-source software as described below.
Note that the scheme above is just a sample solution; the services can be replaced with some custom implementation or appropriate analogs.