By Kim Rowe
This article is the first in a two-part series. Read the second part here.
Securing today’s devices, which are scattered across the globe yet connected over the Web is a challenge that must be met. It must start with a firm foundation grounded in proven protocols, interfaces and design practices that can assure safe and secure operation.
The rapid expansion of the Internet of Things has become so pervasive that it is difficult even for those deeply involved in the industry to fully appreciate its impact and reliably predict its future. Estimates of 50 billion connected devices by year X or 100 billion become equally difficult to grasp. In contrast, the general public is largely unaware of its existence let alone its impact on our daily lives and at the same time most people simply interact with this vast array of connected devices and expect them to work satisfactorily on their smartphones. They also expect them to include safety for their operations
While reliability and safety are things a consumer can rightfully expect, they also depend on an element that is not so readily apparent and that is security. Security is vital and indispensable to a society that has become dependent on a universe of connected things for manufacturing, commerce, medical systems, agriculture, entertainment, and social interaction . . . the list goes on.
Paradoxically, this huge connected universe is built on relatively small and inexpensive, if not simple, embedded devices that have size, power and cost constraints. Those constraints also apply to the time and cost of development. Therefore, security measures must be as effective and fool-proof as possible while at the same time easy and inexpensive to implement. They therefore adhere to a large part to industry standards and many of their tools and mechanisms are open source. Perhaps amazingly, these apparent paradoxes can be resolved using strategies and design methods that start at the very foundation of these devices—the platform of processor, the operating system and its components and reach up into the application code.
However, even at the most basic level, security is a multi-faceted issue that requires attention to different aspects, chief among which is that these devices are connected. Without connectivity they would be quite secure but not of much use. First there is the normal traffic of email and data transfers. Beyond that is the need to manage devices remotely, which means accessing their internal operation. Then there is the need for layers of security within a device to prevent mischief. There are issues regarding the security of the coded components and also properly connecting the security features of the platform with the operation of the application.
An RTOS that can offer a rich selection of security mechanisms in terms of communication protocols, functional modules and an inherently secure design helps implement security from the ground up and will be oriented toward system security and not just device security. Devices based on a platform that supports such implementation across a hardware/software family are more conducive to system security than trying to connect diverse elements across what is often an autonomous machine-to-machine (M2M) environment.
Devices in M2M configurations mostly send data as messages rather than files—e.g., short bursts of data from sensors, or commands, which are also short. The basis for securing such communication is the Transport Layer Security (TLS) protocol. While TLS itself does not perform encryption and decryption, it works by using a handshake session between client and server in which the client requests identification and is sent a certification that includes the server’s name and its public encryption key. The client sends a list of cipher suites it supports and the server picks one. The server also sends its public encryption key, which the client uses to encrypt a random number. That number is used by both parties to generate a unique session key. The session key is used for encryption and decryption between the parties for that session only. For short email-type messages, TLS can work with the Simple Mail Transfer Protocol (SMTP). The actual encryption and decryption are accomplished using the specific underlying crypto algorithms that the TLS version supports (Figure 1).
Figure 1: SMTP transmission using TLS ensures that only authorized users use the email server and that the data is sent privately. If the message is encrypted and signed before being sent, the message can be authenticated and ensured to be private to those that have the correct keys for the message.
Of course, IoT devices also exchange files to share data and this requires a separate but somewhat similar protocol to TLS—the Secure File Transfer Protocol (SFTP). SFTP does not rely on TLS, but is a secure version of the older File Transfer Protocol (FTP). It uses a Secure Shell (SSH), which is a cryptographic protocol and interface for executing network services, shell services and secure network communication with a remote computer. SFTP encrypts its messages prior to transmission and it encrypts both passwords and data to protect sensitive information. Since files are also transferred via email, SFTP must be able to work with TLS as well as support certain file system operations such as directory listings, remote file deletion and resumption of interrupted file transfers.
Securing Device Management
The main point of the Internet of Things is the ability to monitor and control devices deployed across the net and to allow them to exchange information. Central to this is the Simple Network Management Protocol (SNMP), which provides a means to not only communicate with devices attached to the Web, but also to look inside them, set variables, retrieve data and logs, execute commands and even to reconfigure devices. This could open connected devices to all kinds of malicious hacking, so it is perhaps surprising to learn, but until the relatively recent introduction of Version 3 (SNMPv3) there was no secure version available to accomplish this.
SNMP uses a computer called a master, which communicates with programs called agents. An agent runs constantly on each managed system or device and communicates with the master over a secure Internet connection. It is through the agent that the master gains control of the managed system and accesses its data. The agent also translates the managed devices’ internal data variables and commands to and from an SNMP-specific format (Figure 2).
Figure 2: An SNMP-managed network consists of three key components: the managed device, a software agent that runs on each managed device, and the network management station software running on the manager.
SNMPv3 now provides three security features: encryption, message integrity and authentication. It has retained the underlying protocol, yet has a different look and feel from previous versions due to different terminology and concepts. Each SNMP entity has a unique identifier and communication is only possible between known peers. Users can select an optional packet replay protection mechanism. In many cases, the implementation of SNMP is treated as an added feature. For truly secure device management, however, it is especially important that it be fully integrated and verified as part of the underlying operating system.
Kim Rowe is the CEO and founder of RoweBots.
