This file type includes high-resolution graphics and schematics when applicable.
Embedded system designers face a number of threats to the applications that they develop for the IoT. One of the biggest threats comes from IoT subsystems that hackers can access, such as commercial networked HVAC systems, wireless base stations (e.g., small cells), implanted medical devices and their controllers, smart automobiles and the emerging networked transportation infrastructure, home and industrial-infrastructure network gateway systems, and remote industrial sensors. In some cases, the end user may be motivated to attack an IoT subsystem they own or have access to, such as their smart residential electric meter, in hopes of a reduced electric bill; or their connected car, to bypass emissions controls. Other adversaries may be economically motivated, or could be nation states preparing for cyber war.
Factors that make IoT endpoints especially vulnerable to security threats include:
• Networked: IoT endpoints may be remotely accessible from nearly anywhere in the world via the internet or other (e.g., phone) networks. Wireless connections, used in many IoT devices, are especially vulnerable.
• Fielded: IoT devices are often physically accessible, as well as interconnected. This exposes them to additional hardware attacks that do not usually need to be considered for systems that may be networked but are physically protected by “guns, guards, and gates.”
• Available: Samples are often easily available through purchase or theft that can be analyzed at the adversary’s leisure.
There are definite safety aspects to poor security. An example is the aforementioned connected car, including the Advanced Driver Assistance System (ADAS) that encompasses intelligent, interconnected Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) systems. Since vehicles are fielded systems, they are accessible to people with malicious intentions. There can be serious consequences—up to and including loss of life—if, for instance, ADAS systems cannot ensure that V2V and V2I messages originate from a trustworthy source and are not modified between the sender and receiver.Connected medical devices such as pacemakers and insulin pumps, and many industrial systems have obvious safety and even homeland security implications related to security vulnerabilities. This is why recent revisions of functional safety specifications such as IEC 61508 and the latest avionics standards require good security, too. With safety implications comes legal liability. Government regulators such as the FDA are becoming more active in mandating strong security to protect consumers from security-related safety, economic, and privacy threats. More and more, companies are being fined or sued over badly implemented security. One of the casualties can be a company’s hard-earned reputation; and with a loss of revenue, employee job security.
Combining Hardware and Software to Secure the IoT
Software security, alone, has proven relatively unsatisfactory in protecting networked devices against known and freshly discovered threats (so-called “zero day” vulnerabilities), and is totally inadequate for the additional threats posed to fielded systems. What is needed is a combination of software
• Design security: This includes IP protection and ensuring that configuration bit streams and firmware are encrypted and protected. Designs need to incorporate a method to ensure that overbuilding or cloning of the design is not possible. Field updates to processor firmware or FPGA configurations need to be authenticated and the payload kept confidential.
• Hardware security: Designers also need to certify that user-accessible devices are resistant to physical attacks. For example, differential power analysis (DPA) attacks can extract keys and other vital device information. System boot-up needs to be kept secure, not just from remote network-based attacks, but also where the adversary has physical access.
• Data security: This element ensures that communications into and out of the system are authentic and secure, and sensitive data stored in the system cannot easily be extracted.
Embedded-system program managers and development teams must design these types of protections into their products while best leveraging the characteristics of the underlying platform. The result should be a robust protection network with no single point of failure. Key methods for achieving this goal include:
• Risk assessment: Perform a detailed system security evaluation early in the architecture design phase, to assess critical system data/functions, discover vulnerabilities, enumerate threats, and outline the likelihood and consequence of system compromise.
• Protection planning: Using risk assessments and any other compiled data, developers should seek to understand protection implementation costs and design options for mitigating identified system vulnerabilities and ensuring successful system verification and validation.
• Attack scenario testing: This can include a black-box approach, pitting experienced reverse engineers with state-of-the-art attack tools against a system in a deployed setting to reveal vulnerabilities that cannot otherwise be found during most other evaluation exercises.
• Side-channel analysis and mitigation: Side-channel attacks like differential power analysis (DPA) are currently the most practical method for compromising cryptography implementations. It is important to perform measurable, objective, and repeatable testing for resistance to side-channel attacks for applications where adversaries have the ability to observe side channels (i.e., power draw, timing, EM emanations) during on-device cryptographic operations.
Typical Threats to Embedded Systems
The following are common attacks on embedded systems that should be considered during the architecture and design implementation engineering phases (Fig. 1).
• Network attacks: Though fielded systems are subject to new threats, all the existing battery of network attacks still apply, too. Ideally, all network communication is authenticated and encrypted using well-established protocols such as TLS. A public key infrastructure (PKI) can be used by both remote endpoint devices (clients) and servers to ensure that only communications from properly enrolled systems are accepted by the parties to the communication. A strong hardware root of trust can provide this secure “identity” for the system, providing unique-per-device keys linked to the hardware and certified in the user’s PKI.
• Active side-channel attacks: The most common active attack is to use voltage glitches on the power supply of the processor to cause an “interesting” malfunction at a critical juncture in the execution of the embedded program. For example, the infamous attack on the Sony Playstation, which started a chain of events that allegedly cost Sony $1 billion before it all played out, started as a glitch attack that allowed the hacker to enter a privileged processor state where he could then dump all the code, whereupon a cryptographic implementation flaw was found. Game over!
• Memory and bus attacks: If the hardware is physically available and insufficiently protected, it may be possible just to read the contents of memory directly from an external programmable read-only memory (PROM) or external RAM memory chip, or by probing the connecting bus. It is generally good practice, and not that difficult, to encrypt and authenticate all static data such as firmware stored in PROMs. Lack of memory encryption in a smart electric meter design was reportedly a critical factor that led to an estimated $400 million annual loss by a power company.
Another memory attack is the so-called Cold Boot Attack where the memory (a bank of SDRAM chips, for example), is chilled, quickly removed, and read on another system controlled by the attacker. The cold chips hold remnants of the data even during the short interval where they are unpowered. Thus, it is best not to store critical secrets such as cryptographic keys in off-chip memory. In cases where higher levels of security are justified, external volatile memory can be encrypted.
Some memory attacks can be performed remotely, such as with the Heartbleed bug introduced in a 2011 OpenSSL update that at its peak allowed remote reading of RAM working memory in an estimated half million secure web servers worldwide. The Heartbleed bug was discovered and announced publicly by Google and independently by Codenomicon in April 2014. Technologies such as whitebox cryptography can be brought to bear on this type of memory attack.
Reflashing, or changing the contents of memory, either remotely or with physical access can, in what is called a “persistent” attack, bypass any software-based security. Since the malware is installed in non-volatile boot-up memory, even resetting the system does not clear away the malware. It is important to boot the embedded processor securely by verifying the authenticity of all code in rewritable memory, or code loaded from off-chip, including the very first such word executed, so any changes to the memory are detected and an appropriate action taken. An independent hardware-based root of trust can be used to build a secure boot solution.
• Open ports: There really aren’t many good excuses for leaving open ports on your system, yet these attacks remain one of the most common successful embedded system attacks. An open port may consist of, for example, a UART connection left available for easily hooking up a terminal monitor. Unfortunately, this is equally convenient for the hacker. Most software password protection schemes used to prevent logging in via the terminal are just a speed bump to a good hacker.
JTAG test ports can be used to perform boundary scans of the board (including gathering memory contents), and for access to processor debug features meant to be used only during development, but weren’t properly locked.
Another common mistake is to use a single factory password to protect privileged access to the system or a device in it. These have a way of turning up in hacker internet blogs, giving worldwide access to your entire product line free for the asking. A related problem is where users don’t change the default password when they configure the system for themselves.
A secure FPGA can protect debug and other factory test ports from hackers at the hardware level while still providing access to authorized personnel. The access keys can be secured against extraction by the FPGA, providing much better protection than software alone can.
• Passive side-channel attack: Simple and Differential Power Analysis (SPA and DPA), and their electromagnetic equivalents (SEMA and DEMA) can extract secret keys used inside a processor or FPGA, if suitable countermeasures are not implemented (Fig. 2).
In a “differential” side channel analysis, the adversary monitors available inputs or outputs of the system (e.g., encrypted communications), and at the same time also monitors the selected side channel, such as the instantaneous power consumption or electromagnetic emissions, while the key is being used; and then with the application of some straightforward statistical post-processing learns the secret value of the key that was used during the calculations. In a “simple” analysis, step one (monitoring the ciphertext) is not even required as the key can be extracted from just the side-channel information with little or no statistical post-processing required.
SPA and DPA countermeasures are typically found in smart-card ICs with very large minimum-purchase quantities, but not in a standard 32-bit flash-based microcontroller. FPGAs are available with licensed DPA countermeasures that have been certified as effective by an independent third-party laboratory, and include a DPA patent license that allows the user to implement DPA-resistant cryptography running on them without requiring any additional legal work or royalty payments.
Conclusion
Secrets are essential to securing the IoT. In this and other hyperconnected system environments, it takes more to keep up with the bad guys than a fixed factory password and software patches. It is not enough to simply include a crypto accelerator—it must include DPA countermeasures. External assessments as part of a risk-based, multi-layered strategy built from the ground up are essential.
The latest SoC FPGAs embed microcontrollers and security features such as true hardware-based random-number generators and secure key storage so the SoC FPGA can be used to provide a hardware root of trust to an external processor, ensuring it boots securely from the first word of code loaded from off-chip memory. The secret keys and public key certificates pre-installed in the FPGAs and SoC FPGAs from some manufacturers can provide the basis for a strong identification of a networked IoT endpoint, ensuring that no communications can be spoofed. This provides the foundation for a layered technology approach ensuring the highest protection against cyber threats.
In today’s cyber hacking world, it is essential for every public and private organization to proactively address security issues. Embedded system designers can help their customers in this area by creating secure designs that are protected from today’s rapidly evolving threats, including the increasing vulnerability posed by a rapidly growing ecosystem of interconnected, user-accessible subsystems.
Looking for parts? Go to SourceESB.