12/2014 • www.ECNmag.com
By Lance Dover, Director of Product Architecture for Micron’s
Embedded Business Unit, and Amit Gattani, Senior Director, Seg-
ment Marketing for Micron’s Embedded Business Unit
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 efficiencies 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.
Now, what does this have to do with the Internet of Things
(Io T)? 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
Securing the Internet of Things
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.
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’s 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.
So to answer a question previously set
forth, measurement of code before it is ex-
ecuted 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 de-
vice’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 cryptographic hardware such as the
aforementioned TPM or some other similar trusted execution environ-
ment 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 phys-
ical access, exploiting known hardware or software security
Ensuring security in a world of connectivity.