Securing the lnternet of Things

Ensuring security in a world of connectivity.

wireless design product development hardware design circuit design
By now most people involved in the electronics industry have heard of the onslaught of Internet-connected devices that will become part of our lives over the next several years. It is not hard to conceive of a day in the not too distant future where connectivity for all personal devices, vehicles, and commercial equipment will be the rule as opposed to the novel exception. With this, the moated castles of devices that exist today within homes, industrial plants, and commercial operations will become interconnected in ways that people can't even imagine. This connectivity will bring unprecedented productivity, new business models and efficiency never thought possible. The future will also offer tantalizing targets for a new breed of criminals looking to break into virtual back doors that never existed before the castle's moat became so shallow. With this foresight, it's not hard to understand that tomorrow's interconnected devices must be designed from the ground up with security in mind.

Hardware and software engineers have become increasingly attuned to the need for security in their products over the past several years. But more often than not, the solutions have been rooted in software or in hastily crafted hardware solutions. Probably the most broadly used hardware security device utilized in the industry, the Trusted Platform Module (TPM), has shipped more than two billion devices to date. Even with security rooted in hardware, less than one-tenth of one percent are likely even activated. Those that are, are leveraged to a fraction of their potential. While National Institute of Standards and Technology (NIST) guidelines for signed BIOS (SP800-147) have existed since 2011, the related guidelines for BIOS integrity measurement have languished. This has relegated one of the main benefactors of the TPM, remote attestation, to custom home-brewed implementations of measurement and reporting. Hardware Design read more....

Now, what does this have to do with the Internet of Things (IoT)? It's difficult to imagine, for example, how factory automation or fleet of commercial vehicles could resemble the corporate sea of cubicles filled with tablets, smart phones, and laptop computers. Upon deeper inspection into the new world order of connected-everything, it's plausible to consider that every node on the distributed network is a computing device and to promote and ensure proper security each computing device must be managed. After all as they say, it does no good to lock and dead-bolt the front door of a house if the back door is wide open. If tomorrow's castles of connected devices each provide a wireless entry point across the moat, the king better be sure that each of his subjects are conforming to the rules of the castle. Product Development read more....

But how many embedded connected devices are being designed today with the equivalent of the PC's "signed BIOS" and integrity measurement? How many of these devices will be remotely and centrally verified that they have not been compromised before they come alive on the Internet? And when one considers the actual brains and nervous system of each connected device, the code which it runs, how exactly is this code protected?

One of the key tenants set forth by the Trusted Computing Group and most others in the security  industry is the concept of "trusted" or "measured" boot. The idea being that a computing device at its core is really the software in which it is executing so this code must be verified to be good. At the  earliest phase of the device boot, its code will measure itself and then measure other code modules before transferring control to them. If each ,subsequent measurement is deemed correct and therefore trusted, then the device progresses through its boot process in a trusted manner and  eventually becomes a trusted connected device. Prototype development read more...

So to answer a question previously set forth, measurement of code before it is executed is the industry's answer to code protection. The problem with this answer is that it's very much like getting sick and confirming the origin of the ailment with a throat swab or blood test. Although it's nice to  confirm being sick and medicine exists to improve the condition, a person can't help but think that they would rather have prevented the whole ordeal in the first place. But wait, skeptics will say, there are plenty of ways to protect the Internet-connected device's code and the memory in which it resides. After all, devices most certainly have an MMU, a privileged based operating system, and possibly  even special Purpose cryptography hardware such as the aforementioned TPM or some other similar trusted execution environment for code. These things surely provide all the code and memory protection needed, right?

The problem is that none of these techniques specifically protect the memory device and its contents either by physical access, exploiting known hardware or software security vulnerabilities, or even through zero day attacks, malware can infest today's most protected code storage devices. It's true that many memory devices today include a variety of data protection features. such as block locking, write protection, and one time programmability. The problem with all of these techniques is that they are not cryptographic in nature. With access to a datasheet and the appropriate level of system access, a would-be attacker can easily circumvent most of today's flash memory protection. If the aforementioned trusted boot techniques are correctly applied, these breaches will very likely be detected. Wouldn't it be better to avoid getting a case of strep throat all together than to go through a 10-day regimen of antibiotics?

What the industry needs is the equivalent of a flu shot to protect its memory-hungry embedded devices. Each of the future nodes within the connected castle needs to be immunized against attacks before they can happen. This can only happen with more robust security capabilities within the memory device itself. Doing so will not only protect the computing device in the network, but at all points prior to the network from its inception through the supply chain. Manufacturing Sourcing read more....

Better memory security will in no way obviate the need for the sound practices of code signing and measurement. After all, good security is always based on multiple layers of security. The ultimate goal should be to protect the memory along with the system logic, and as a result the computing device as a whole will become much more resilient to attack.

Posted from: ECN magazine, december 2014 edition

Author: Lance Dover, Amit Gattani

11 Flora Spgs,
Irvine, CA 92602
U.S.A. Map


Email Us

Follow on Social

For Customer Support,
please visit our help center

Help Center