Guillaume Crinon, Global Io T Strategy Manager,
Security & Connectivity, Avnet EMEA Embedded systems are the heart and brains of most machines and devices that we use every
day, such as cars, coffee machines, elevators,
factory belts, and robots, to name a few. They are
architected around microcontrollers or larger microprocessors
with external memory (peripherals for the most complex ones),
and sometimes FPGAs, when high-performance, determinism,
and nanosecond real time are required.
All of these systems are therefore programmable, and as such,
exhibit the obvious vulnerability of being reprogrammed with
malware. Therefore, every embedded system should be designed
around processors providing a secure boot capability that is
able to validate the integrity of the software, or firmware it is
running, on a systematic basis. These secure boot routines should
of course not be reprogrammable or bypassed themselves, hence
building their trust on hardware roots in the form of ROMed
code, ROMed root certificates, and non-accessible private keys.
External secure elements providing state-of-the-art anti-tamper
and cryptography mechanisms are often very useful companion
chips to these secure processors.
Beyond the embedded system themselves, software and
firmware distribution should be organized so as to provide
updates with trusted signatures that only the software
editor can produce. This often calls for trusted third parties
capable of emitting certificates, hosting private keys, and
administrating them as a service from their highly secure data
centers for customers.
When embedded systems communicate with remote
servers, which most of them do, their communication should
also be taken as seriously as when we connect our laptops to
the internet—with end-to-end security so that no one can
interfere, and to guarantee authenticity, integrity, and if needed,
confidentiality of the data exchanged. Once again, this can only
be implemented with hardware roots of trust in the embedded
systems themselves and architected around trusted third party
public key infrastructures issuing and administrating unique and
Last but not least, the best systems should be capable of
detecting attacks, reporting them, and upgrading their own
security to keep up with ever-evolving threats.
Andrew Girson, CEO, Barr Group The number and scope of security threats to embedded systems, including exploitable
hardware flaws like Meltdown and Spectre as
well as botnets like Mirai, are rapidly rising. As
professional designers of embedded systems, we all
have an ethical duty to secure our systems better.
We recently completed the Barr Group 2018 Embedded
Systems Safety & Security Survey. Results indicate that
approximately one quarter of all new products with internet
connections could kill or injure one or more people if they fail
or are attacked. Shockingly, 16 percent of these “Internet of
Dangerous Things” devices designers don’t even have security as
a system requirement!
So how can we fix this? I would encourage designers of
embedded systems to follow this six-point plan to better secure
1. Don’t Ignore Security!
Assess the “social consequences” of the systems you design.
The ACM Code of Ethics and Professional Responsibility
emphasizes the importance of using best software practices
and the professional obligation to act when other development
team members or management intentionally neglect to correct a
product’s known safety-related risks.
2. Adopt Proven Industry Best Practices
Use coding standards, code reviews, and static analysis. These
impactful and inexpensive techniques are just three of the many
industry best practices that you can use to develop safer and
more secure devices. Adopt these development process steps to
reduce the number of weak links in the security chain and bugs
in your products.
3. Use Cryptography
Use encryption—it’s a straightforward but important security
technique. More engineers should be using encryption, but
unfortunately, in this year’s survey, we saw that only about 55
percent of those who had security as a design requirement were
encrypting external data.
4. Secure Your Bootloader
Make sure that the part of the firmware that enables future
upgrades is secure and that only authorized firmware upgrades
are loaded into the product’s memory. At a minimum, any
firmware update payload should be digitally signed by the
authors’ private key. These design additions will help prevent
your device from accepting just any download and combat
5. Practice Defense in Depth
Go through the different scenarios of how and why a hacker
may get access to your system. Think about them. Plan for them.
Design to thwart them, with layered defenses.
6. Stay Educated About Security
Pay attention to news of not only attacks in the embedded
space, but also in the desktop and smartphone computing
worlds. Security attacks that eventually compromise
embedded systems are often reported first against desktop
computers and smartphones.