What Can You Trust In The IoT?

Most of us on the bleeding edge of technology are aware that the Internet of Things/Everything and the Cloud of Things (IoT/E), (CoT), are slowly becoming less fuzzy. No one knows exactly what the model ultimately will look like, but it is becoming clearer and clearer that it won’t be radically different than the Internet we have today—just more objects, more interconnects, more autonomy, and significantly more opportunities for security breaches.

According to research houses Gartner and ABI Research, there will be somewhere between 25 billion and 30 billion devices on the IoT/E, CoT by 2020. Eventually, everyone and everything will likely have a unique IP address. The fact is that IP addresses are going to be to objects of the IoT what social security numbers are to people today. Yes, in the IoT, everything and everyone will truly be a number – and a possible attack vector.

A TPM module. Courtesy Infineon.

Autonomy and the IoT
Because many of these objects will be autonomous, security must be a default integral rather than an afterthought. There are profound security challenges involved in achieving that.

Widely, cyber-attacks are likely to become an increasingly physical (rather than simply virtual) threat. In a January 2014, Forbes cyber security columnist Joseph Steinberg noted that there are already some, and will be many more, Internet-connected appliances that can “spy on people in their own homes.” These include televisions, kitchen appliances, cameras, and thermostats, just to mention a few.

In addition, the U.S. National Intelligence Council, in an unclassified report, maintains that it would be hard to deny “access to networks of sensors and remotely-controlled objects by enemies of the United States, criminals, and mischief makers.” That open-ended statement can be interpreted in a number of ways, but what it does is point out that once there are a large number of objects on the Internet, it will become problematic.

So the question arises, exactly how do we keep these autonomous objects from becoming autonomous attackers? One solution is trusted platforms.

The elements of trust. Courtesy of IBM.

Enter the trusted platform
The Trusted Platform Module (TPM) and the infrastructure around this component are an industry attempt to build a series of “roots of trust” in the platform. “Early on,” according to Craig Rawlings, senior director of business development at Cryptography Research, a division of Rambus, “Trusted Platform Modules were tied to semiconductor (hardware) architectures only. Things evolved with the invention of Secure Element (SE) devices used in smart card technologies and Trusted Execution Environments (TEE) incorporated into general-purpose processor architectures. What has been missing is an integrated Root of Trust embedded in a system on chip (SoC) that provides silicon-based security for the SoC architecture—in ways that harden the TEE against both software attacks and penetration attacks.”

At a high level, the TPM typically is a microcontroller with integrated flash/storage that is attached to a bus on a computer system. But it also can be a virtual device, or integrated into a chipset. It is based on an international standard for crypto processors — a dedicated microprocessor designed to secure hardware by integrating cryptographic keys into devices. Figure 1 shows a TPM that would be connected to a system via a host I/O interface. If the TPM were integrated into the chip, it would likely be done so as an IP or function block.

A bird’s eye view of the process generally goes as such. Each TPM chip contains an RSA (the acronym RSA is derived from the initials of the developers of the algorithm, Ron Rivest, Aki Shamir and Leonard Adelman) key pair called the Endorsement Key (EK). The pair is maintained inside the chip and cannot be accessed by software. The Storage Root Key (SRK) is created when a user or administrator takes ownership of the system. This key pair is generated by the TPM based on the EK and an owner-specified password.

Components of a TPM.

A second key, called an Attestation Identity Key (AIK), protects the device against unauthorized firmware and software modification by hashing critical sections of firmware and software before they are executed. When the system attempts to connect to the network, the hashes are sent to a server that verifies that they match expected values. If any of the hashed components have been modified since last started, the match will fail, and the system is denied entry to the network.

That is a rather fundamental description, but there is a plethora of data available that dissects the TPM’s code and algorithmic processes.

The root of trust
Trusted platform modules, when combined with a trusted power-on condition, form what is called the root of trust (RoT). Roots of trust are comprised of a set of functions, within the TPM, that are always trusted by the device’s OS. The RoT functions as a separate compute engine that controls the TPM cryptographic processor on the device it is embedded in. The RoT provides the functionality behind trusted computing features including key management, password protection; detection and reporting of unauthorized changes to the operating system, or programs; on the fly drive encryption; rootkit detection; memory integrity: user authentication; network access; data protection; hardware-based digital rights management (DRM) support and more. Once activated, the TPM provides increased security through linkage to other Trusted Computing Group (TCG) specifications that have been developed for networks, such as the Trusted Network Connect (TNC) and self-encrypting drives (SEDs).

This one-two punch provides a level of capability that can manage the security integration of devices. Such devices including desktop PCs, servers, laptops, as well as emerging mobile devices (see Figure 2). Today, the TNC’s set of network capabilities provides users a level of security that was too difficult, too expensive, or otherwise impractical to deliver in earlier implementation.

On the mobility scene, TCG’s Mobile Trusted Module (MTM) is a secure element and specification that was developed for use in mobile and embedded devices. Because of economies of scale, and power and footprint constraints, it has a reduced feature set compared with the TPM developed for a wired computing environment. But it can work cooperatively with TPMs in other devices for complete system security. The effort to develop the complete functionality required for mobile trust continues with the ongoing development of MTM 2.0. With these specifications, network service providers, third-party service providers and end-users all benefit from establishing trustworthy behavior.

And for the embedded systems camp. TCG also has an embedded work group focused specifically on such systems, which will be of significant impact on how objects of the IoT/E, CoT. The workgroup is still in its infancy with one specification out, but it is actively working with the embedded segment to come up with standards and specifications across the industry.

There is one caveat to all of this, however. “It is important to note that ‘trusted’ are not necessarily ‘secure’ platforms,” said Rawlings. “In other words, one may be able to use strong authentication to ensure communications with the intended counterpart, but still not be able to have a private conversation with them.”

The importance of trust and security
While trusted platforms are one of the best firewalls when designing systems, they may not offer as tight a choke point as might be needed for some applications. In many cases, trusted platforms may well suffice. In other situations, they may not. According to Rawlings, “to establish authenticated communication and trust between two or more parties, as well as to protect information both at rest and in motion requires platforms that are both trusted and secure. For information in motion, it is important to lock down the integrity of the information to ensure it is the same at the receiving end as it was at the sending end.”

The TCG Interconnect circle.

As the IoT market picks up steam for use with smart homes, factories, cars, health devices, and countless other objects, robust platform security will become a strong requirement to assure integrity within each of these IoT infrastructures.”

To accomplish all of this, a cornucopia of requirements, standards, certificates, and compliances will be needed. “Today, in most cases, security is designed into software starting with a secure boot, then initializing the operating system’s security features,” Rawlings said. “Security does exist in hardware, but typically is poorly implemented in support of software that is vulnerable by design. Going forward, if security is properly implemented in hardware, such attacks can be restricted to a single device rather than all devices of the same type.”

Conclusion
Trusted platforms are a step in the right direction. It has only been in the last few years that they have come into widespread deployment, and mostly in the computing infrastructure, in the form if encryption keys. They have a lot more potential, and, with IoT autonomous devices, some worth just a few pennies, others worth mega-bucks, trusted and secured platforms will need to evolve.

“From a security standpoint,” notes Rawlings, “addressing security for the system’s host processor, at the design of the SoC, and carrying it through the manufacturing supply chain through to the active life of the product, is essential to establishing robust silicon-based security.”

And that is the bottom line for the billions of expected autonomous objects that, if secure, can make our lives extremely convenient and organized, or, if not, completely tumultuous and chaotic.