The Secure Remote Access Challenge for IoT Cloud

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:

• Server side validation (e.g., server must be sure that the client is an approved device).
• Client side validation (e.g., client must be sure it connects with the right server).
• Client side security materials should not be accessible by the manufacturer.

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.

In summary:

• All clients should have pre-programmed security materials containing unique ID for each client that should be updated as soon as the device is installed.
• Server should have validation scheme for each client. Something simple like white list is more than enough.
• Separate validation service should be implemented to allow clients to at least detect that the server has been compromised.
• Note that for better security, it may be reasonable to set the lifetime of the security materials used for access of the validation service to a reasonably short value. For example, instead of years usually used for main services, use 20-30 days.

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.

Sample Security Solution

Note that the scheme above is just a sample solution; the services can be replaced with some custom implementation or appropriate analogs.

• Root CA - In Public Key Infrastructure (PKI) acts as Root Certificate Authority - it signs certificates for Manufacturer, OpenVPN server, and OCSP responder. In addition, you should maintain the list of compromised and expired server certificates as part of the Root infrastructure Certificate Revocation List (CRL).
• openvpn-server.com – machine (or number of machines) that runs OpenVPN server and Application Server.
• OpenVPN Server handles VPN connections from devices. Optionally, it can check if device ID extracted from the certificate is listed in the known device list. The device list is provided by the Manufacturer and contains IDs of issued devices. This list can be used to control number of devices issued by the Manufacturer.
• Note: Server always “knows” if the certificate is issued by the Manufacturer or by the Root CA and can replace certificate on the device after the first successful connection.
• Manufacturer – 3rd party in the PKI acts as an intermediate Certificate Authority - it issues certificates for devices. In addition, Manufacturer should maintain the list of IDs for all issued devices and provide this list back.
• Field device - runs different applications. Application sends the gathered info to Data Server performing the following steps:
• establishes tunnel to OpenVPN server using OpenVPN client
• checks (using request to OCSP server) that OpenVPN server certificate was not revoked
• sends data using VPN tunnel to Data Server
• closes VPN tunnel
• ocsp-server.com – Instance of OCSP Server.
• OCSP Server - Online Certificate Status Protocol responder. This is the special service that can be used to check if the OpenVPN server certificate was revoked.
• Note that the OCSP certificate is equally important as the Root CA certificate since it can be used to block all VPN connections. So it is good idea to run the OCSP service on a separate machine where no additional services are running.