Q: How can the design of embedded systems be improved to reduce security threats?

Guillaume Crinon, Global IoT 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 reliable certificates.

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.

By 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 designers of these “Internet of Dangerous Things” devices 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 your products:

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 potential attacks.

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.

By Martin Böhner, Head of Product Management Security & OTA, Elektrobit

If we look at typical sources of threats, we see implementation bugs, logical, and design errors or problems arising from incorrect scope settings that do not consider the whole system. On the implementation side, the awareness for security as an integral requirement from the very beginning and a thorough implementation and quality management are key to reducing threats.

One of the most effective measures is to design and keep the system small and simple to reduce the attack surface and manage complexities. I understand that this is not always easy to achieve, but the common practice of adding configuration options to avoid actual decisions is not a good tactic from a security point of view. If the overall system cannot be designed to be small and simple, the goal is then to divide it into manageable subsystems and assign least privilege and privilege separation principles to the parts.

Nevertheless, in automotive we deal with some of the most complex and critical embedded systems today. They are highly connected, consist of up to 100 million lines of code and are implemented by hundreds of suppliers. No one can assume that such systems will be flawless at any given point in time under practical circumstances.

Defense in the depth principles must be applied to sustain the possibility to detect and react if something goes wrong. Collaboration with system engineering plays an important role to ensure security coverage from different angles and a multilayered security approach combined with safety and other aspects by placing the right elements—software or hardware based—at the right place in the system.

So, the answer is, that we have to do everything we can to mitigate the possibility of threats, while on the other hand foreseeing and accepting the challenge to monitor our systems and have the ability to react to emerging threats for systems in the field—as long as a system is operational.

By Scott Jones, Managing Director, Embedded Security, Maxim Integrated

As embedded systems become smarter and connected, they’re more vulnerable to security threats. To reduce security threats, embedded systems designers can employ various techniques. Software-based security is one option, and it’s considered to be relatively cost-effective and easy to implement and update. However, software security can introduce vulnerabilities such as side-channel leakage or susceptibility to malicious modification, which means that malware can easily infiltrate or penetrate the software. A stronger option is hardware-based security, which, if done correctly, provides countermeasures to side-channel analysis and integrates specialized functionality to protect against a broad range of attack threats. A security IC, such as a secure microcontroller, that executes code from an internal, immutable memory guards against attacks that attempt to breach an electronic device’s hardware. Start-up code stored in the microcontroller’s ROM is called the “root of trust” because it cannot be modified. As such, it’s trusted software that can be used to verify and authenticate authority-signed application software. By implementing a root-of-trust approach from the bottom up, designers can close off more potential entry points into their designs. Next-generation secure ICs now provide a more advanced level of cryptographic strength in the form of physically unclonable function (PUF) technology. PUF technology natively generates a digital fingerprint for its associated IC. This fingerprint, or key, supports algorithms for authentication, identification, anti-counterfeiting, hardware-software binding, encryption, and decryption. Because PUF technology is derived from the complex and variable physical and electrical properties of IC devices, it’s virtually impossible to duplicate or clone. Also, the key is generated only when needed and is never stored on the chip. An attempted invasive attack on a PUF-based chip can change the electrical characteristics of the PUF circuit, further impeding such an attack. For designers, PUF technology is another weapon in their arsenal against cybercrime.

By Erez Kreiner, Co-Founder, NanoLock Security

The Meltdown and Spectre security flaws have rattled the tech industry by uncovering fundamental issues with CPU designs spanning the last two decades. While chip vendors have tried to assure the market with software patches, these will have limited efficacy against current and future breaches resulting from internal design flaws, coding errors, and external hacking, all of which will have enormous impact across huge numbers of devices.

The urgency escalates when one considers the billions of IoT endpoint CPUs that will ultimately make up the most functional aspects of society’s crucial infrastructure—sensors, valves, switches, electronic control units, and more. The industry needs an end-to-end solution that secures the entire chain of vulnerability from deeply embedded endpoints, out to the cloud, and up into the enterprise management layer.

For full-scale embedded security, solutions must be:

  • Hardware and software-based.
  • CPU- and OS-independent.
  • Protecting firmware, particularly during over-the-air updates.
  • Inexpensive, simple and power-efficient, and working with a minimum latency.

CPU and device makers must understand and embrace the challenges facing them today, work with the eco-system to overcome them, and above all, get ready for the next war while defending against the previous one. With the numbers of computer embedded devices growing exponentially, in the coming years we are going to see these types of flaws exposed more and more frequently. It is imperative that we are prepared.

By Mary Ellen Bauchman, Director of Product Marketing, Rutronik Inc.

As in any complex composition of different parts, an embedded system’s reliability requires not only each part to be secure, but the interfaces between these parts as well. It starts with power supply design, since interruption of power could cause data loss and system shutdown, which could be a security issue. Solutions could involve either a redundant power supply and/or an uninterruptible power supply (UPS) to provide back-up power for the system if the power supply fails or if utility power is interrupted.

Another security aspect is establishing safe access to the embedded system. A PIN-code or password is a basic security step, but these entry codes could be discovered by unauthorized persons or stolen data. An RFID transponder provides more security, but could also be lost or stolen. The most secure access is achieved by employing a biometric sensor—a fingerprint sensor, iris sensor, or facial recognition with a 3D camera system.

For secure data storage within an embedded system, it is necessary to encrypt personal data, avoid silent data corruption, prevent the recovery of deleted data, and maintain data integrity over long periods of time. RAID systems of solid state drives (SSDs) with integrated security based on single-level cell (SLC) flash memory technology is an ideal solution; however, there are tradeoffs between technical and financial aspects of security solutions, and the results are often a compromise.

Because there are numerous technical and practical considerations for embedded system security, the best starting point is an individual discussion with application specialists who can recommend a range of hardware, software, and services—usually a distributor or a value-added reseller (VAR) with expertise in embedded systems. Because the requirements of each embedded system are different, it is critical that you consult an experienced team of engineers who are well trained in state-of-the-art solutions.

By Lars Lydersen, Senior Director of Product Security, Silicon Labs

Security is not a binary property or feature of an embedded system. It is first of all a process that must be managed throughout the life of the system, from the architecture to implementation and throughout the system’s lifecycle stages in the field.

An embedded system is only secure against a given adversary at a given time. Typically, the cost of securing a system increases tremendously when considering more capable adversaries. For most embedded designs, it is infeasible to sustain high costs to secure against nation states. Notably, the number of adversaries shrinks tremendously as the security level increases. Hence, to reduce security threats, it is necessary to increase the security level of the system. The good news is that for most systems, there are several inexpensive and simple means that will significantly increase the level of security.

On the device level, it is important to control the software running on the device. This is achieved by controlling the mechanisms of how new software is programmed into the device. In particular, it is necessary to close the JTAG interface and implement a secure bootloader.

On the communication level, it is crucial to turn on security in the communication protocols. All new wireless protocols such as Zigbee, Bluetooth, Thread, and transport layer security (TLS) implement fairly good security and are straightforward to use during development.

On the system level, it is important to enable software distribution mechanisms. This is particularly important since time works against the security of most embedded designs. Adversaries become increasingly more powerful over time. The attacks you can launch today for around $1000 USD are immensely more powerful than the attacks you could launch with the same level of funding ten years ago. Therefore, it is important to take the system’s longevity into account, and the only way to secure against future adversaries is to design the system with upgradable security, and by upgrading the system via over-the-air updates throughout the product lifecycle.

By Richard Hayton, CTO, Trustonic

“Embedded” used to imply isolated systems safe from the prying eyes of hackers and the dangers of open networks. However, few embedded systems are really isolated today due to “full-on IoT” or previously closed systems being opened to new applications (and new attacks).

That means that while security should be top of mind, it’s too often ignored. I believe that this is because embedded security is hard. Unlike in the development of desktop or web applications, the fundamental support is often lacking—simple libraries, developer forums—and a human user to fall back on to answer those “are you sure?” questions.

To enable embedded devices to meet the IoT challenge, security must be made simple. This does not mean importing a web-centric approach, as that would require security tenets that just don’t apply—and, whilst desktops can live with bloat, size really does matter in the embedded space.

Here’s a five-step plan for device security:

  •  Identify the device. There is someone on the other end of the line who needs to know if the caller is a genuine pacemaker or a hacker. If this isn’t done correctly, then the system will be compromised. 
  • Provide message integrity, confidentiality, replay protection, and future security. This stuff is hard to explain, let alone actually do—which is why security libraries are a must.
  • Separate the wheat from the chaff. Software has bugs. Period. Modern MPUs can isolate code regions, meaning a bug in the LCD driver doesn’t need to impact the security of the insulin pump.
  • Keep it small. If a device has 32 kb, and security “costs” 30 kb, it won’t get used.
  • Make security simple. All of the above must be provided

By Scott Phillips, VP of Marketing, Virtium Solid State Storage and Memory

The most pressing challenge industrial-embedded system designers face today is the development of products that achieve their demanding functional objectives, while at the same time maintaining data security. No technology sector is immune to data security threats—including the industrial-embedded space.

Not only do up-front costs from security breaches dramatically diminish return on investment in system designs, but the consequences of that data falling into the wrong hands, cause costs to grow exponentially. 

Embedded system designers for industrial IoT historically take a long-view approach; they place a premium on system reliability, durability, and integrity—attributes that are key to data storage.

Designers selecting Virtium solid-state drives, for example, do so because they understand protecting mission-critical data is paramount, placing durability and data integrity higher on the priorities list than “speeds and feeds.” They also know that because data is prone to security risks, they take measures during the design phase to integrate system access and data-protection schemes such as encrypted SSDs, authentication and virtual private networks (VPNs). Of course, data encryption comes in several “flavors,” so for embedded systems supporting industrial IoT and machine-to-machine applications, the stronger the better.

We at Virtium advocate and provide Self Encrypting Drives (SEDs) that use the Advanced Encryption Standard (AES-256). Regarded as the de facto security standard and strongest encryption option for the U.S. government, AES-256 delivers a 256-bit key size that provides an astounding 1.1 x 1077 number of possible combinations. Additionally, a secure crypto-erase feature ensures the best data protection for the most demanding industrial-embedded designs and applications. We also advocate and support leading authentication technologies including those proposed by the Trusted Computing Group (TCG), as well as in-house developed solutions including hardware and software write protection.

There’s no way for embedded systems to avoid 100 percent of security threats, but a solid security policy and best practices that includes authentication and data encryption built into SSDs helps reduce their likelihood.

By C.S. Lin, Marketing Executive, Winbond Electronics Corporation America

Flash storage is found in virtually every segment of electronics and information technology—from minuscule cameras and digital-music players that clip to our clothing to vast data centers and super-computing systems. What all these applications have in common is that data collected in flash are never 100 percent protected from security threats. Embedded systems are a particularly rich target for such security breaches, due in no small part to how much their organizations rely on the systems’ continuous operation and on the collection of crucial data.

We in the non-volatile flash storage world are highly sensitive to such threats—and have been taking significant steps to counter them. Specifically, at Winbond we’ve integrated security features directly into our flash devices used in embedded systems and other data-centric applications. Of course, achieving that built-in security has challenged our engineers to design a secure flash device without sacrificing cost or performance. 

For background, we all understand the constraints of embedded flash designs: memory scalability, cost, performance, and foundry capabilities. Those factors presented themselves at virtually every step in our quest for optimally secure flash storage, starting at the device architecture through the back-end flow and then during design verification. We adjusted existing methods and invented new ones to meet the primary goal: security.

From that holistic approach to design and methodology came the TrustME Secure Flash architecture, addressing the need for a secure, non-volatile storage, independent of factors such as system-on-a-chip processes and foundry capabilities. The architecture adheres to the ARM Platform Secure Architecture, which clearly outlines a requirement for secure boot, root of trust, and secure storage.

By addressing security early on as we did—at design and methodology phases, and building security features directly into the flash devices—embedded systems can be inherently more secure.