IoT: Embedded and Secure
OPEN SOURCE WAY BLOG: Last time I wrote about how the Internet of Things (IoT) is impacting the design of military embedded systems; this month, I'd like to address IoT and security. Specifically, I want to address the security processes involved in managing IoT gateways, which are vital to the successful operation of critical applications.
An IoT gateway is a system that connects IoT edge devices (sensors and actuators) with back-end applications running in a data center or in the cloud. An IoT gateway is co-located with edge devices, collects information from them, then processes and reformats it before sending it to back-end applications. In addition to the security of the gateway itself, the gateway must interact with – and be protected from – edge devices and the backend command and control systems that direct and manage the gateway.
IoT gateways increasingly perform data reduction and integration, as well as local processing and decision making. In the case of an unmanned aerial vehicle (UAV), for example, IoT devices would include visual and infrared cameras, GPS, multi-axis accelerometers, engine sensors, engine controls, flight surface controls, and others. In this case this information is a mixture of streaming data (video), regularly updated data (position, engine operating conditions), and events and alerts (engine overheat, loss of oil pressure), as well as commands issued to the UAV. The gateway would be responsible for collecting information from all devices, processing it, and sending a subset of available information out through the uplink to a remote command and control system.
Three questions about interacting with devices
From a security perspective, there are several questions to consider regarding how the Gateway interacts with these devices:
• Is the device available, and can the gateway connect to and interact with the device? In some cases the gateway may need to do device discovery to see what devices are available. In other cases the gateway will already have list of devices to access.
• Is the device who it says it is? The gateway should assume that all devices are untrustworthy and should verify the identity of all devices. All input from devices should be sanitized before it is processed. It shouldn’t be possible for a device to take over the gateway. Flow control and QoS mechanisms should be used to prevent devices from launching denial of service (DoS) attacks. In addition, mechanisms should be used to securely identify each device. Each device can be expected to provide information on itself such as device type, model, capabilities, and serial number. Certificates such as X.509 certificates installed on each device allow the gateway to verify the device identity.
• Has the device been compromised? Techniques such as signed software images, boot time integrity checking in the device (secure boot), and self check mechanisms are needed. Cryptographic signatures, commonly implemented using certificates, should be used to verify all aspects of the device.
Other things to consider
In many cases communications between devices and the gateway should be encrypted. This way, potentially sensitive information is not exposed, a man-in-the-middle attack can’t modify information flowing between a device and the gateway, and the identities of the device and the gateway can be verified. Encrypted communications is commonly done using transport layer security (TLS) which, with the proper choice of ciphers and keys, can provide security even with constrained devices.
The gateway itself should also be hardened by deploying a few proven techniques. First, you should only install the software you need, while uninstalling unnecessary programs and making sure no software development or debugging tools are installed on production gateways. You must also proactively manage, maintain, and update the gateway. In doing so, use Secure Boot, which allows verification of the hardware and low-level software, and trusted processing modules (TPM).
Lean on Linux-based processes, too. For instance, you can proactively employ resource management, such as Linux cgroups, which can help specify the maximum and minimum amount of CPU, memory, and network traffic an application or service may use. Software signing, such as that which is used with Linux RPM packages, is also beneficial for allowing verification of the source of the software and that the software installed on the system has not been modified or corrupted. Utilize access controls, such as SELinux, to control system resources and prevent compromised applications from accessing other parts of the system. And employ domain-based authentication solutions, such as Linux IPA, which can allow centralized management of user accounts and optimal security through multi-factor authentication.
Of course, security is not complete without the appropriate firewalls and scanning solutions in place. Firewalls ensure that only allowed communications occur, and can be configured to only let devices with specific IP addressed “talk” to the gateway. Regular scanning can allow you to check for unpatched security vulnerabilities and secure gateway configurations.
Finally, always actively manage your gateway through regular updates, including security and bug fixes and the addition of new features as appropriate. A mechanism to remotely and securely manage gateways should be used for these tasks.
While effectively securing an IoT gateway involves many different processes and tools, at the end of the day, it boils down a single thing: keeping embedded systems safe. I think we can all agree it’s worth the effort.