Welcome to another post in a series of articles written by the Citrix Labs R&D staff on the topic of the Internet of Things (IoT). If you haven’t discovered the previous posts, you can catch up here and read about how we defined the role of IoT in the Citrix software defined workplace, identified potential security challenges, described a simple IoT framework, and focused on securing the device layer.
In this installment, we move up the IoT stack and examine the gateway layer.
As you can see in the simplified IoT model illustrated below, the gateway layer serves the important role of connectivity and messaging between things, people, and cloud services. In most cases today, the primary function of the IoT gateway is protocol translation from low power sensor networks to the Internet or LAN.
However, all the big names in the industry predict massive numbers of IoT devices arriving in the enterprise over the next 5 years.
So in addition to simple protocol translation, intelligent IoT gateways are required in the enterprise to handle the sheer volume of IoT devices and the messages communicated between them. The gateways will also provide local processing of automation rules closer to the network edge, device management functionality, and enforcement of network access control polices. Just by connecting sensors and IoT devices to your network, you also enable the potential of merging information about the physical world (from sensors) and the ability to interact with the world (through connected devices) with the critical enterprise applications on which you run your business.
For example, when fully realized, the Internet of Everything will enable any business to integrate real-time tracking of their vehicle fleet with their dispatch and logistics software or use automated warehouse inventory tracking with their asset management solution. Of course all this functionality must be performed securely and this article delves into some important security requirements of the IoT gateway.
Gateway Layer Security
Communications in the IoT usually take place over a combination of private and public networks, so securing the network protocols is obviously important and the first thing you should consider. When thinking about security for this layer, recall the basic CIA security triad. Communications between the things, the gateway, and the cloud service must be cryptographically secured to preserve confidentiality, integrity, and authenticity. Securing network communications in this way, with technology like AES cipher suites and TLS/SSL encryption, is probably the most understood area of IoT security since we’ve been doing it for years for applications like e-commerce over the Internet.
Even with mature technology for securing network communications, the Internet of things is different than the Internet of servers and PCs and so poses some unique security challenges. Many of these challenges relate to the fact that IoT devices have limited computing power and no graphical user interface for easy configuration.
As stated above, a primary role of the gateway layer is bridging lower power sensor networks, usually from a low power radio standard like ZigBee or Z-Wave, to Wi-Fi or Ethernet. This is a critical function since we expect many devices, from many manufactures, speaking several different protocols to appear in the enterprise. The IoT gateway serves as the common point of communications and control amongst the myriad of devices.
One challenge for the IoT gateway is maintaining confidentiality while preforming this protocol translation. Although both ZigBee and Z-Wave protocols support encryption, the gateway must generally decrypt and re-encrypt the payload when translating from one network protocol to another. This protocol translation makes it more difficult to maintain confidentiality because it is not true end-to-end encryption; communication between intermediaries is protected, but not the intermediary itself. If an attacker were to compromise the IoT gateway, not only the data passing through the gateway is at risk, but control of the physical things connected to it are at risk as well.
For example, research conducted by Veracode on 6 common home gateways found:
“…widespread problems securing communications between connected devices and the vendor’s management servers in the cloud. Five of the six devices tested were vulnerable to so-called “man in the middle” attacks that would allow an attacker on the same network as a device to intercept, modify and forward traffic between the device and its cloud based service. Many of the devices tested failed to properly validate the TLS or SSL certificate used to encrypt that traffic, Creighton said.”
One way to mitigate this problem is to implement true end-to-end, application layer security. Using this strategy, messages are encrypted in a way that allows only the unique recipient of the message to decrypt it, and not anyone in-between. In other words, only the IoT device and receiving cloud service hold the cryptographic keys and the gateway acts as an illiterate messenger, passing along messages that it can’t decipher. The gateway is still performing its protocol translation duties, it just can’t read the messages as it routes them from one network to another.
Secure onboarding is the process of configuring an IoT device for the first time and enrolling it for management. In the Resurrecting Duckling security model for IoT devices, this is the process of imprinting the duckling (device) with a cryptographic key generated by the mother duck (IoT management service). The IoT gateway plays an important role in the onboarding process because it is the intermediary between the IoT device and managing service. When installing a device for the first time, all communications and encryption keys pass through the gateway and must be protected from eavesdropping and man-in-the-middle attacks.
We know that encryption effectively addresses IoT communications confidentiality, however the weak link in the encryption security chain is often around key management practices and how keys are exchanged during the device onboarding process. A research paper titled Security Evaluation of Z-Wave Wireless Protocol illustrates how, even though the underlying Z-Wave protocol features strong 128-bit AES encryption, improper implementation by device manufactures can lead to serious vulnerabilities.
“Using this tool, we have demonstrated an implementation vulnerability in Z-Wave key exchange protocol that could be exploited to take full control of a target Z-Wave door lock by only knowing the Home and node IDs of the target device, both of which can be identified by observing the Z-Wave network traffic over a short period of time.”
The good news from this particular report is,
“We have communicated the details of this vulnerability to the vendor who has conducted a security review of Z-Wave specification and SDK to ensure that they cover correct handling of the discovered vulnerability. Finally, Sigma Designs has taken action to prevent such implementation flaws to reach the market in the future by adding additional security test cases to the certification test suite.”
The Z-Wave implementation vulnerability in the IoT device referenced above exemplifies the need to perform firmware updates on IoT devices in the field. Since many IoT devices gateway don’t have much in the way of UI or internal storage, an external application and gateway is often required to retrieve and apply firmware updates. To update firmware securely, the system should record current version and new version of the firmware, check for a valid signature on the downloaded firmware upon receipt, and check firmware integrity before firmware installation.
An important strategy when implementing security by design is to minimize the attack surface. In other words, an IoT gateway manufacturer should only implement the protocols and interfaces required to deliver the intended functionality and nothing more. This includes restricting services and interfaces that are running on the device for debugging purposes, but not intended for use by end-users. While these “hidden” interfaces are invaluable for manufacturing, development, and testing purposes, they are often vectors for information leakage and authentication backdoors. In addition to restricting debugging interfaces, all open interfaces should be designed to prevent a legitimate user from running arbitrary code on the gateway device.
The previously quoted research conducted by Veracode on 6 common home IoT gateways found that:
“Many of the most serious flaws revealed a kind of sloppiness in the design and production of the devices… For example: [two of the] devices left debugging interfaces exposed and unsecured in their shipped product. That could provide an avenue for attackers who had access to the same network as the device to steal information or bypass other security controls.”
“The point about the debugging interfaces is that it sounds obscure, but it really isn’t. All you need to do is go to the Android developer site, download a toolkit and within five minutes have full access to the [IoT gateway] device,” he said.
Will your Wi-Fi AP become the only gateway you need?
As more efficient Wi-Fi implementations, like the forthcoming 802.11ah standard, become more prevalent and is built-in to IoT devices, the IoT gateway function will eventually merge into the Wi-Fi access point, rather than being a separate device. That puts a lot more security demands on a network device which already has a history of vulnerabilities in the consumer space and re-enforces the need for a hardened IoT Gateway with enterprise-class security built-in from the start.
- 300,000 Compromised SOHO Gateways
- Virgin Media Router Snafu
- Asus and Linksys Router Vulnerabilities
- Linksys Router Worm
The Intel IoT Gateway
To fill the need for a secure IoT gateway for the enterprise, Intel is developing the Wind River Intelligent Device Platform. This device is positioned to connect both legacy industrial devices and emerging intelligent infrastructure to the IoT. It is designed to integrate protocols for networking, embedded control, security and manageability and provides a platform on which 3rd party applications can run. The Intel IoT Gateway whitepaper outlines the following security features of the device:
- Secure Boot – ensure only authorized and trusted software can run on the device when it is booted up.
- GRSecurity – set of free software patches released under GNU GPL to secure the Linux kernel. GRSecurity is a set of configurable role-based access control (RBAC) policies that allows collections of programs or processes to run with least-privilege.
- McAfee Embedded Control – provides system integrity by only allowing authorized software to run, validating system changes, tracks file system changes, and protects critical data files from tampering.
- Integrity Management Architecture – detects if files are maliciously or accidentally altered, both locally and remotely.
Given the Intel IoT Gateway’s focus on security and extensibility as a platform, Citrix is experimenting with running the entire Octoblu IoT stack on the device with great results, read more about it here: /blogs/2015/05/08/octoblu-intel-industrial-iot/.
The primary role of the IoT gateway is connecting low power sensor networks to private Ethernet LANs and to the Internet. As the number of devices proliferate in the enterprise, the role of the gateway will grow to handle the increased network traffic and include functionality like local processing of device automation, device management, and network access policies. It’s not hard to see that the gateway plays a vital role in the IoT, but to be included in the enterprise, it must be secure. In this article we presented a number of security requirements for the gateway device. These include:
- Encryption – Cryptography is an important component of securing communications through an IoT gateway, but it must be implemented properly to be effective. End-to-end, application layer encryption is one strategy to prevent the gateway from being the weak link in the security chain.
- Secure onboarding – Even with state-of-the-art cipher suites available, we’ve shown that secure device on-boarding and key exchange is a critical aspect of security in-depth at the gateway layer.
- Firmware updates – When security issues are found, you have to patch the devices in the field and it is largely the gateway’s role to deliver the firmware, especially low power sensors that lack a direct connection to the Internet.
- Interface minimization – Since the IoT gateway serves as an aggregation and control point for multiple devices, it is a high value target for malicious attacks. For this reason, manufacturers must take extra care to ensure only interfaces required to deliver the intended functionality are implemented and nothing more.
- Hardened Wi-Fi access points – In time, we expect the IoT Gateway role to merge with the Wi-Fi access point, but with the unique challenges of securing tiny IoT devices, gateways with enterprise-class security like the Intel Wind River IoT Gateway are required.
In the next and final post in this IoT security series we will look at how to secure and maintain customer privacy in IoT cloud services.