Network-connected devices provide many opportunities to improve and enrich people’s lives, but the “Internet of Things” has a range of definitions. A consumer’s experience with the “IoT” may be a wearable computer for fitness tracking. A physician may place a connected heartbeat monitor on a patient. An industrial engineer may see the Internet of Things as thousands of sensor points that provide measurements of temperatures, pressures, or valve states.
Unfortunately, these connected devices also represent individual targets for would-be cybercriminals. The question is: “How do we secure the IoT?”
We are talking about connected things. But the nature of the “thing,” its connection to the sensor network, and the use of the collected data all vary widely from application to application.
In an oil refinery, for example, the crude oil must be heated to specific temperatures in order to separate the different products — diesel, kerosene, and gasoline — through the distillation process. Sensors detect the current temperature, and the sensed values are used to control the heating furnace.
Since this process includes extremely flammable liquids, the ability to alter the reported temperature could result in either a failed cycle (because the crude oil fails to reach the proper temperature for distillation) or an explosion if the furnace temperature gets too high. Without a means to ensure the sensor’s integrity, as well as the reported temperatures, the refinery would need to resort to manual ways of measuring the temperatures, with the resulting delays potentially crippling the refinery’s production capability (see Figure 1).
If a potential interloper could alter the boot cycle of the sensor, modify the algorithm used to measure the temperature, or simply alter the reported value as the sensor’s message transmits, then the refinery could experience a catastrophic failure. Users not only need a method to confirm the sensor’s integrity, but also a means of ensuring that the message traffic from the sensor travels across the communications link unmodified. Additionally, the sensor unit’s software must be able to receive authorized updates, and outsiders must be precluded from manipulating the sensor code.
Sensor connectivity often leads to conflicting goals. On the one hand, a refinery worker may want to ensure that all of the raw sensor data is available for analysis, potentially in the cloud, in order to verify the efficiency of refinery operations. On the other hand, revealing that data to outsiders may allow them to compromise refinery safety, or derive the techniques used for the refining operation’s key processes, thereby resulting in potential lost revenues. Two sensor connectivity models are possible: the cloud model and the fog model (see Figure 2).
The Cloud Model
In the cloud model, each individual sensor is directly connected to the Internet, and directly reports to a centralized service that collects the data. Analytical algorithms, or a data analyst, then collate and filter the raw information to spot trends and determine potential efficiencies for a given process. By accessing all of the collected data, the thought is that subtle features that may not be immediately apparent to a human can be discovered through clever data-analytic techniques. In this model, however, potentially thousands of sensors are exposed to the Internet, creating an enormous cyberattack surface.
The Fog Model
With the fog model, an alternate model for IoT systems, the sensors do not report raw data to the cloud servers. Instead, the sensors send the information to an intermediate device known as a border router or border gateway. The border gateway then collects, filters out bad samples, and collates the data for periodic transfer to the cloud-based servers. In this model, the sensors are not directly connected to the Internet, only the border gateway. The arrangement potentially reduces costs of communications and of storage of noisy, unfiltered data. From a security standpoint, however, the fog model significantly reduces the attack surface by preventing the sensor network from being directly accessed from anywhere on the Internet.
The CIA of the IoT
Many in the cybersecurity business view security as including elements of confidentiality, integrity, and authentication, collectively referred to as “CIA.”
Confidentiality, a guarantee that data is restricted from general access, is often accomplished using technical means such as encryption. Integrity has many dimensions, ranging from proper system booting to ensuring that messages are delivered intact and unmodified. Authentication verifies the identity of the person, device, or process that is attempting to access the data or update device software.
Many of the “CIA” elements of a system can be addressed through the use of encryption technology. Encryption is simply a technique, sometimes referred to as a cipher, which obscures a message or data in some way to prevent access to the contents. Encryption techniques date back to early Roman times, and can range from simple techniques such as substitution ciphers to techniques based on sophisticated mathematical concepts.
Decoding Encryption: The Basics
Without getting into the complicated mathematics of encryption algorithms, encryption is generally divided into either symmetric (private-key) or asymmetric (public-key/two-key) techniques. In the case of a symmetric approach, both the sender and the receiver of the message must have knowledge of the encryption algorithm and the key used to generate the encrypted message (also called the cipher text). The problem with symmetric algorithms: how to communicate the key to both parties, also known as the key exchange problem.
Key exchange is typically accomplished by relaying the key through a separate channel. For example, you might send the key through the mail while delivering the cipher text electronically. Naturally, if the key is somehow compromised or easily guessed, then a third party could obtain the cipher text and decrypt the message. Requiring an out-of-band communications channel for the key exchange adds complexity and potential delays in the message exchange.
Unfortunately, many of the higher-grade symmetric encryption algorithms are quite computationally intensive. The typical, small 8- or 16-bit microcontroller used in many sensor applications often does not have the computational horsepower to perform the encryption while maintaining the line speed and sampling rates of many application scenarios. All hope is not lost, however.
Many silicon manufacturers now incorporate hardware-based encryption engines into their wireless interface circuitry. The encryption, possibly AES-128, is then used as link encryption between the sensors and the data collection facilities (see Figure 3). Given the cost and delay of trying to create a wireless radio (and getting it through the government certification process), it is often the path of least resistance to simply use an off-the-shelf wireless interface that supports link encryption and uses a symmetric crypto-algorithm.
With link encryption, however, only the data traffic is encrypted. The data and applications code running in the sensor itself is unencrypted. If a cyberattacker gains physical access to the sensor, then the data can still be compromised. End-to-end encryption has the application itself perform the encryption operation. The data is encrypted from application-to-application between the sensor and the data collection facility.
Performing real-time end-to-end encryption still requires sufficient CPU capability. Nonetheless, the designer could use a block cipher approach. A hardware-encryption processor could receive the data and encrypt it as a block message rather than a continuous stream. The application could then transmit the data as a packet across the link (via the sockets interface, for example). If the encryption engine is on the same silicon die as the microcontroller, then the potential for compromise of the data — even if the attacker has physical access to the sensor — is somewhat lessened because it is more difficult to tap into the communications between the encryption engine and the microcontroller.
The Keys to Asymmetric Encryption
Asymmetric encryption techniques are designed to address the key exchange problem. In an asymmetric approach, each user generates a pair of keys, known as the public and the private key. These keys are cryptographically related in such a way that anyone with knowledge of the encryption algorithm can encrypt the message with the recipient’s public key; only the holder of the private key, however, can decrypt the message.
Therefore, no symmetric keys need to be exchanged ahead of time. The encryption algorithm is publicly known as is the recipient’s public key, ensuring message confidentiality but not message integrity. Because encryption/decryption is a mathematical operation, the modified cipher text will still decrypt even though it may not make sense. In order to ensure message integrity, designers can use a cryptographic-based message authentication code (MAC) or hashed MAC (HMAC), such as SHA-256, on the message and send the resulting signature to the recipient separately. If even a single byte of the cipher text is modified, the HMAC computation result will not correspond to the hash provided by the sender.
Unfortunately, asymmetric algorithms are often even more computationally intensive than many symmetric algorithms. Additionally, the delays associated with the double encryption/decryption make asymmetric algorithms problematic for resource-constrained platforms. Asymmetric techniques, however, can be extended to apply in certain authentication approaches.
One such extension of the asymmetric concept is embodied in the Diffie-Hellman (D-H) key exchange protocol. In this protocol, two parties (we’ll call them “Bob” and “Alice”) that have no prior knowledge of each other can use an insecure channel to jointly establish a secure link. Through a series of exchanges, using publicly known values and combining them mathematically with their own private values, Bob and Alice simultaneously generate an identical symmetric key on their respective ends of the connection. Then, the resulting key secures the communications channel via a symmetric encryption algorithm. The same concept can be extended to IoT devices, establishing a secure link with the cloud destination machine or the border gateway.
The advantage of the D-H approach is that no predefined secret keys need to be exchanged. The public keys are known to everyone, and may actually be stored in public key servers located around the Internet. Only the respective private keys are stored on the opposite ends of the connection. Since the symmetric key is simultaneously generated on both sides of the link, the key never transits the link. This significantly increases the security of the link, and the use of a symmetric algorithm reduces the computational complexity of the encryption.
As an example, let’s say that the sensor needs to send a set of collected temperatures of the refinery furnace over the past five minutes. The set of values may be from several temperature sensors located in the furnace and throughout the distillation vessel. Rather than setting up a virtual private network (VPN) for a continuous link, perhaps the company opts for periodic transfer of the data to keep communication costs down.
Using an asymmetric approach, the transmitting sensor needs only its own private key and the destination’s public key. Then, using the approach outlined earlier, the sensor performs a double encryption with the destination’s public key and the sensor’s private key. The encrypted block of data can now be communicated to the destination using whatever method is appropriate. The destination then does the double decryption using the sensor’s public key and the destination’s private key. The temperature data is now available as a block of data at the destination, and confidentiality, authentication, and non-repudiation characteristics of the message can be assured (see Figure 4).
Asymmetric encryption techniques can also address authentication via software certificates and secure software updates using code signing approaches. Both practices are significant challenges in today’s world of IoT-connected devices, where cybercriminals could add their own devices to a sensor network or arbitrarily update a sensor’s software. Encryption is only one part of a “CIA” solution, but the encoding technology is at the heart of ensuring security for the IoT in any of its forms.
This article was written by Mike Anderson, CTO and Chief Scientist for The PTR Group, Inc. (Ashburn, VA). With over 35 years in the embedded and real-time computing industry, Mike works with a number of applications ranging from satellites and robotics to SCADA platforms. His recent focus has been the use of Linux and Android in embedded sensor applications and the deployment of the Internet of Things. For more information, Click Here .