Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing...

16
White Paper March 2016 Securing the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff Engineer, Synopsys Abstract The Internet of Things (IoT) is undeniably a hot topic right now, but there are also many definitions of what an IoT device is exactly. One of the common requirements that seems to be universal is the need for security. Although it includes functional aspects, security — or rather, lack of security — is an emerging system property that cannot simply be realized by integrating a single, magic security IP block into your system. This paper provides an overview of security basics, feature requirements, technical solutions, and associated system-level trade-offs for implementing security in IoT devices. Making the required trade- offs is significantly easier by leveraging secure, proven building blocks that were designed with secure systems in mind and optimized for low footprint and energy. Given the insights of this paper, trade-offs for a specific IoT device can be made more easily, the optimal mix of features can be decided on, and the resulting secure architecture can be implemented efficiently. Introduction IoT products like smart home controllers, wearables and smart metering devices bring many benefits such as improved convenience, better health or environmental savings. But the Internet connectivity and massive data collection that enable these benefits also bring threats to the reliable functioning of these products and to the privacy of their users. When architecting a system, trade-offs have to be made. This is especially true with security, as there is no one magic solution that makes a system “secure”. The trade-offs to be made are complex, inter- dependent, and span multiple disciplines. Hardware versus software, throughput versus area and energy consumption, and security level versus cost are some of the decisions to be made. But although the magic IP block that protects a full system does not exist, securing an IoT system is made significantly easier by using building blocks that were designed with secure systems in mind. IoT end-to-end systems can roughly be classified into three groups, as shown in Figure 1: ` The endpoints interacting with the physical world (edge devices) ` Hubs and gateways that connect to edge nodes for data aggregation and that also act as gateway to other, larger area networks ` The cloud with remote (big) data storage and servers for processing the data collected by edge devices

Transcript of Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing...

Page 1: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

White Paper

March 2016

Securing the Internet of ThingsAn Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security

Author

Ruud Derwig

Senior Staff Engineer,

Synopsys

AbstractThe Internet of Things (IoT) is undeniably a hot topic right now, but there are also many definitions of what an IoT device is exactly. One of the common requirements that seems to be universal is the need for security. Although it includes functional aspects, security — or rather, lack of security — is an emerging system property that cannot simply be realized by integrating a single, magic security IP block into your system. This paper provides an overview of security basics, feature requirements, technical solutions, and associated system-level trade-offs for implementing security in IoT devices. Making the required trade-offs is significantly easier by leveraging secure, proven building blocks that were designed with secure systems in mind and optimized for low footprint and energy. Given the insights of this paper, trade-offs for a specific IoT device can be made more easily, the optimal mix of features can be decided on, and the resulting secure architecture can be implemented efficiently.

IntroductionIoT products like smart home controllers, wearables and smart metering devices bring many benefits such as improved convenience, better health or environmental savings. But the Internet connectivity and massive data collection that enable these benefits also bring threats to the reliable functioning of these products and to the privacy of their users.

When architecting a system, trade-offs have to be made. This is especially true with security, as there is no one magic solution that makes a system “secure”. The trade-offs to be made are complex, inter-dependent, and span multiple disciplines. Hardware versus software, throughput versus area and energy consumption, and security level versus cost are some of the decisions to be made. But although the magic IP block that protects a full system does not exist, securing an IoT system is made significantly easier by using building blocks that were designed with secure systems in mind.

IoT end-to-end systems can roughly be classified into three groups, as shown in Figure 1:

`` The endpoints interacting with the physical world (edge devices)

`` Hubs and gateways that connect to edge nodes for data aggregation and that also act as gateway to other, larger area networks

`` The cloud with remote (big) data storage and servers for processing the data collected by edge devices

Page 2: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

2

IoT edge devices Aggregation layers(hubs/gateways)

Remote processing(cloud based)

Things with sensorsthat capture and

transmit data

Connectivity tostore the data in the

cloud securely

Applications to storeand analyze the data andprovide cloud services

Figure 1. IoT end-to-end system overview

IoT systems security should always be considered end-to-end. But since there is a significant data size, speed and power variation across the different devices in the chain, as well as different security threats, technical solutions for the groups of devices differ as well. In this paper we focus mainly on the lines of security defense that are relevant to the edge nodes and peripherally consider aggregation and gateway nodes.

Security BasicsWe’ll start with an overview of general security aspects and some trends. Security is about confidentiality, integrity and authentication. Confidentiality aims to prevent information leakage to parties that should not have access to that information. Integrity is about ensuring that the information itself is original and has not been tampered with. Authentication ensures that the identities of the parties producing and consuming the information are uniquely established. Sometimes two other aspects are added, non-repudiation and availability. Non-repudiation uses cryptographic tools to prove that a unique user has made a transaction request. It must not be possible for the user to refute his or her actions. Availability, strictly speaking, is more of a safety or robustness requirement, but it touches on security as well through denial-of-service attacks that prevent proper functioning of an IoT device, for example.

To achieve the above security properties, over the last decades a number of foundation technologies have been developed that are continuously being enhanced. First of all, there are cryptography algorithms. These are the cornerstone of any secure system and include functions for encryption/decryption (e.g. AES [1] or ECC [2]) and cryptographic hashing (e.g. SHA-2 [3]). Encryption and decryption implement confidentiality, and use (partially) secret keys that should be protected against unauthorized access or use. Cryptographic hash functions are used for message integrity. They compute a checksum that is nearly impossible to reconstruct without the original message. For authentication, typically a combination of hashing and encryption is used with either shared secret keys or using public key infrastructure (PKI) like X.509 certificates [4]. The next foundation technology is built on top of these cryptographic algorithms: higher-level protocols like secure http (https) connections (e.g. using TLS [5], secure payment transactions (e.g. based on EMV standards [7]), but also protocols for secure over-the-air software upgrades (e.g. OMA-DM [8]). The third foundation technology is platform security. Platform security is not about protecting sensitive contents, it is about protecting the actual device or platform that stores and processes these contents so it can be trusted. The protection can range from physical protection, such as a closed box with no external access to memories storing secret keys, to software protection against malware and sandboxing non-trusted applications. Platform security starts with a so called root of trust that provides an identity that cannot be tampered with. Building on this trusted starting point, a processor can securely boot and then load and verify application software before starting to execute it.

When designing secure systems, the first task is to identify the security requirements. A good way to identify these is to perform threat analysis and modeling. By investigating system use-cases, environment, main components and the system interfaces with respect to the information to be protected, a list of potential attacks can be created. For each attack, a number of attributes should be considered in order to assess the risk and reward of the attack and consequently the priority and budget for countermeasures. These attributes may include the cost and availability of the equipment required for the attack (a laptop with Wi-Fi, or a focused

Page 3: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

3

ion beam (FIB) device), the consequences of the attack (a single device compromised, or a full class of devices sharing the same key), but also the scalability of an attack (requiring physical access to the device, or an attack over the Internet).

IoT Security Threats and Attacks“IoT” is not a single system or type of systems and it is therefore impossible to provide a comprehensive list of potential threats that apply to all. The threats to a smart utility metering system are typically different from the threats to a wearable consumer or healthcare device, which differ again from the threats to a sensor network for environmental monitoring or to an Internet connected refrigerator that autonomously orders groceries to keep stocked. Instead of performing a full vulnerability analysis for a single class of devices, this section presents a number of general threats and attacks of which IoT system designers should be aware. The purpose is to provide a starting point for a specific IoT system’s threat modeling, as well as to provide a frame of reference for the next section on potential countermeasures against IoT security vulnerabilities.

From a high-level perspective, the IoT threats are about privacy, information theft, (device) identity theft or impersonation, device cloning or counterfeiting, IPR theft, and denial-of-service. A good security practice is to not re-invent the wheel, but to build as much as possible on well-known, proven solutions. Since IoT systems combine aspects from multiple existing domains, threat models from these domains provide a good starting point. One domain to look at is traditional Internet connected devices; another domain is bank cards and payment terminals, a domain where security requirements and practices are considered highly evolved. Typical security requirements for IoT devices will fall between these two domains, though the trend is that bank card grade security is rippling through to IoT devices as well.

A good source for ‘traditional’ Internet connected device attacks is the Open Web Application Security Project (OWASP [9], [10]). OWASP lists the following as the top 10 vulnerabilities for IoT systems:

`` Insecure Web Interface

`` Insufficient Authentication/Authorization

`` Insecure Network Services

`` Lack of Transport Encryption

`` Privacy Concerns

`` Insecure Cloud Interface

`` Insecure Mobile Interface

`` Insufficient Security Configurability

`` Insecure Software/Firmware

`` Poor Physical Security

A good source for security threat models for higher-end security devices like bank cards are the Common Criteria [11] Protection Profiles [12]. These Protection Profiles are documents that describe the security targets for a class of devices and are used for formal certification of what Evaluation Assurance Level (EAL) implementations are guaranteed to comply with the protection profile security targets. Many protection profiles are published, for example, for ICs, smart cards and smart card-related devices and systems, and for products for digital signatures. Another source would be the Payment Card Industry Security Standards Council (PCI [13]) including a framework of specifications and support resources to help ensure the safe handling of cardholder information at different steps.

Whereas the security threats listed by OWASP focus mostly on communication protocol and software security problems that, in most cases, do not require physical access to the device, the Common Criteria and PCI ones include physical attacks as well. For today’s IoT systems, most security breaches reported are on software/end-to-end system level and often due to negligence. For example, 70% of the devices investigated in a recent study [14] used unencrypted network services. Attacks that could exploit such security issues include eavesdropping and man-in-the-middle attacks that intercept and modify the data being communicated. Other examples of attacks are software buffer or stack overflow attacks that feed a device with out-of-spec inputs like the OpenSSL Heartbleed bug. These types of attacks can leak secure information or could enable running of malicious applications and rooting, obtaining higher level privileges than a user normally would be entitled to. Physical attacks can be split into two categories: invasive and non-invasive. Non-invasive attacks use regular interfaces of a device like USB ports, or relatively easy accessible JTAG debug interfaces that provide access to and control of the IoT device processor and memories. Another type of non-invasive attacks

Page 4: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

4

are side-channel attacks. These exploit information leaked from a device to reconstruct protected secrets by measuring variations in power consumption of a device or variations in the electromagnetic radiation to reconstruct the computations performed and to extract private keys from these. Invasive attacks go a step further by opening up the IoT system and potentially altering it physically. This can be at board level e.g. by tapping into the bus interface between processor and external memory, but also at chip level. Depending on the budget of the attacker, attacks can go as far as de-capping an IC package, removing top layers and then inspecting structures, monitoring signals (by attaching microprobes), or even altering structures with a FIB device.

Given the diversity of all of the potential security threats described above, it is important to perform a specific threat analysis for a specific type of IoT device. In addition to the technical side of the attacks, the likelihood and potential impact of different attacks should also be estimated. Although privacy is at stake when data is leaked from a wearable fitness band, successfully hacking a smart utility meter is likely a more profitable activity and consequently the smart meter would require better protection mechanisms. Good security analysis enables trading off security versus cost, performance, and energy when selecting the potential countermeasures that are described in the next section.

IoT Security CountermeasuresReading the list of potential attacks from the previous section, an IoT system designer might easily get disheartened. There are so many different threats that cover so many different disciplines that it is hard to have sufficient expertise in all of these fields. On the positive side however, many technologies exist to counter the threats. Some of these that have been around for a long time are well-known and proven — just not always applied. And some are more recent or continuously being enhanced. More and more standard security IPs, software, and tools are available on the market, simplifying the task of a system architect to design a secure solution. This section provides a high-level overview of available solutions, the next part of this paper will focus on more recent solutions, and finally a system example will be presented with an emphasis on securing IoT edge nodes.

Figure 2 depicts the high-level overview of security solutions for an IoT edge device. As a good security practice, it presents different classes of solutions in a layered diagram. Layered security is a practice of combining multiple mitigating security technologies to protect resources and data. Each layer addresses a specific security aspect that would need to be breached by an attacker, and the different layers all enhance the combined security strength of the total solution.

Foundation functions

Secure bus/ peripherals

Secure platformand memory

Advanced protection n Tamper detection; reverse engineering/IP theft protection; side-channel protection

AdProvide protected access to core, SoC bus, peripherals

Cryptography Random numbers Identification Key storage

Secure boot and platform security; memory protection

Other IoTdevices,

gateways and the cloud

n Secure IoT interfaces and protocols

Figure 2. Overview of IoT Security Solutions

The inner layer of the security solutions consist of the fundamental foundation functions on which the other layers of defense are based. It contains implementations of cryptography algorithms like the AES symmetric key standard for bulk data encryption, SHA secure hash functions for data integrity checks, and ECC or RSA based asymmetric key algorithms that are used for authentication and secure session key exchange. Furthermore, it provides functions for generation of random numbers. In addition to a statistically uniform distribution, cryptographic random numbers are also non-deterministic. Whereas a pseudo random number

Page 5: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

5

generator ensures lack of correlation between numbers produced from a given seed value, a true random number generator (TRNG) is required to ensure non-determinism. The amount of true randomness is typically measured in entropy (number of bits).

The list of inner-layer foundation functions is completed by secure storage for secret keys and confidential data like a device or platform unique identity. Typically, secure storage is layered itself as well. It starts with one or more root keys, which is used for encrypting other keys and data such that the encrypted keys and data can be stored in unprotected memory accessible to non-trusted parties. The root keys should be protected and bound to a device. One way is to store them in non-volatile memory like One Time Programmable (OTP) memory that is programmed in a secure environment during manufacturing. Another way is the use of Physically Unclonable Function (PUF) technology, which exploits the unique properties of individual ICs due to manufacturing process variations to create a unique identity bound to the silicon that can be used as secret (root) key.

The next two layers in Figure 2 are concerned with platform security and access control to system resources as peripherals and memories. The goal of access control is to prevent unintended, unauthorized access to security sensitive resources. This access control must be implemented on all levels of a system. Access control and authorization at the user level can, for example, be implemented using password or PIN entry, using fingerprint, or other biometrical authentication. But at a system level, the interface between the IoT processor and the keyboard peripheral interface or biometrical sensor interface must be protected as well in order to prevent unauthorized usage like in the case of a malicious phishing application. Controlled access could also be required for other peripherals, as in the case of a crypto engine that has access to sensitive keys. How to implement access control for peripherals depends on the way they are integrated. Processor access to memory mapped peripherals can be implemented with a Memory Protection Unit (MPU). But protecting access from other bus masters would require other means as elaborated in the next part of this paper. For protection of both on-chip and external memories containing (unencrypted) confidential data, similar techniques can be used, either design-time or run-time programmable using a processor or system MPU. The last aspect of platform security is the correctness, integrity and authenticity of the software being executed. As already explained, secure boot is the key technology for this. After the boot stage, additional checks can be performed either for new applications or libraries being loaded, or as revalidation of earlier loaded binaries. The integrity and authenticity checks can be combined with encryption as well. For example, firmware could be stored with strong encryption on background storage like flash memory, and both decrypted and authenticated by the bootloader. Although secure boot guarantees integrity and authenticity of firmware images, it does not imply correctness of the software. Correctness of the software being executed, or more specifically the absence of security bugs and vulnerabilities, is a complex topic. However, there are good practices to minimize the risks. Some of these, including sandboxing of less trusted application software will be elaborated on in the next section.

The outer level depicted in Figure 2 is labeled Advanced Protection and represents a collection of more advanced protection mechanisms that are typically used in high-security applications. However, these are increasingly relevant to IoT devices as well, since high-end requirements ripple down to lower-end systems over time, and since the knowledge and tools required for advanced attacks become more accessible and affordable over time. This collection includes technologies like tamper detection, reverse engineering prevention, IP theft protection, and side-channel attack protection. Tamper detection covers a broad range of different tamper attacks. What kind of detection specifically applies depends on the specific vulnerabilities resulting from a threat analysis. Specific IPs or sensors can detect different types of tampering. A simple switch attached to a GPIO can detect if an enclosure has been opened for example. More advanced attacks like operating out of the recommended temperature or voltage range, or glitch attacks can be detected by temperature and voltage sensors. Other attempts to flip bits in registers or memories can be detected with error checking codes. Reverse engineering prevention and IP theft protection of firmware can be achieved by encrypting the firmware and data memories. For resistance to more advance micro-probing attacks, this encrypted firmware support can be extended from memories to the full processor pipeline, so decrypted instructions are never stored in registers. For side-channel attacks multiple defenses exist as well. These include physical shielding, flattening of power and timing profiles, addition of noise by randomization of timing and power behavior, and solutions on algorithm and protocol level that are resistant to information leakage by using random masking or frequent changes of keys.

Last but not least, the arrow connecting a specific IoT device to the Internet with other ‘Things’ represents interfaces and protocols that ensure secure interactions with the rest of the world. The interfaces in many

Page 6: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

6

cases will be wireless RF solutions as Bluetooth, WiFi, and IEEE 802.15.4 based solutions as Thread, Zigbee and 6LoWPAN. Most of these standards already include secure communication protocol versions supporting confidentiality, integrity, and authenticity. However, traditional internet-based security protocols are in many cases not optimized for ultra-low-power IoT edge node devices or dynamic ad-hoc networks. Secure communication protocol standards are still evolving and are expected to remain in flux for some time. However, most are based on the foundation functions described earlier and software implementations of the higher protocol layers provide future flexibility. Today, the most used and likely candidate for secure Internet connections is Transport Layer Security (TLS) [5] and the datagram version of this, DTLS [6], that uses UDP instead of TCP and better supports dynamic networks with low overhead.

System, Processor and Software Level Protection MechanismsThis second part of this paper details a number of the IoT security countermeasures from the previous section and describes some key architectural decisions to be made. The topics are structured according to the architecture levels of a product: system, processor, and software.

System-level protection mechanismsAt the system level, the main decisions to be made are 1) what to implement in hardware and what in software, and 2) how to guarantee strict separation of secure system resources, software and other secure information so non-authorized entities do not have access.

A first hardware-software tradeoff is the implementation of the foundation functions like cryptography algorithms. These can be implemented fully in software, use hardware to accelerate software, be fully implemented in hardware, or use a combination of those options. Depending on system requirements on throughput and latency on the one hand, and silicon area and power efficiency on the other hand, a choice can be made between different options. Figure 3 shows the relative differences between three options for the SHA-256 secure hash function. As a baseline, on the left a software implementation on a DesignWare® ARC® EM processor is taken. In the middle is an approach that uses hardware to accelerate software known as CryptoPack [15], an option for the ARC EM processor that adds new instructions through ARC Processor EXtension (APEX) technology [16], which accelerate cryptography processing. CryptoPack was designed to achieve significant performance gains at modest area increase.

1

3

5

7

9

11

13

15

1.0

1.1

1.2

1.3

1.4

1.5

1.7

1.8

SHA-256

Software onEM core

CryptoPack(performance)

Hardware SHA

Gate count (ratio)

Performance gain (ratio)

G

Figure 3. Trade-offs between software and hardware crypto implementations

For the SHA-256 algorithm, the CryptoPack implementation is over seven times faster than a plain software implementation and adds less than 10% to the gate count of the baseline ARC EM processor. If higher performance is required, a full hardware crypto engine can be used. The hardware SHA implementation in Figure 3 uses a DesignWare Security IP core [17] that almost doubles performance over the CryptoPack version again, but at a higher area increase. Instead of adding less than 10% gates, almost 70% more gates are required. Similar to the security foundation functions, for other software like higher level communication protocols a similar trade-off can be made. If very high throughput is required, or to free up even more processor resources by off-loading parts of the protocol processing, hardware protocol acceleration as in the DesignWare Security Protocol Processors [18] could be used.

Page 7: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

7

After adding up all the required CPU cycles for both security-related software and other software that needs to be executed for a specific use-case, it becomes clear how many processing resources are required in the system. For a simple IoT edge node, typically a single core is adequate. But for a system with more functionality like a gateway, it could be beneficial to use multiple cores, for example to reduce total system energy by running at a lower frequency and voltage operating point. The other consideration for planning the number of cores in a system is to guarantee strict separation of secure system resources, software and other information. The simplest way to separate trusted, secure software from normal, non-trusted software is to use multiple cores and allocate software to a core according to its security profile. This traditional way is depicted in Figure 4 on the left hand side. A general-purpose CPU runs — optionally on top of a small Real-Time Operating system (RTOS) — normal application software that is not specifically trusted and that could come from any source, including end-user programming. For security related software a second, secure CPU can be used running its own software stack fully isolated from the other processor. Since it does not share resources with the other processor, there is no risk of leaking secrets to or having unauthorized modifications made by the general-purpose CPU. This does require that the memory for each CPU is physically separated by tightly coupling it to the processor, using separate buses, or using other bus and address map protection mechanisms, as will be explained later. An inherent drawback of this strict hardware isolation of normal and secure worlds is that communication between both worlds can become more complex. Either some shared resource like a small shared memory would be required, or a dedicated communication channel should connect both CPUs. If special hardware is available for inter-processor communication, like ARConnect [19] for ARC processors, then this can be used for secure communication between both cores.

Open, normal

software

Closed, trusted

software

Secure HW

Open, normal

software

Closed, trusted

software

RTOS

General CPU Secure CPU

Secure RTOS

Secure HW (keys, ...) (keys, ...)

Combined single core Physically separated secure core

HW SW

Normal Secure

HW SW

Normal Secure

Software/operating system

Single CPU

Figure 4. System processor partitioning options

Alternatively, as depicted in the right of Figure 4, both trusted and normal software could be combined on a single core. In that case, however, mechanisms must be implemented to isolate both worlds. There are several well-known technologies for such separation. A software-only solution, for example, is to run the trusted software inside a Virtual Machine. This is a technology used in smart cards, where a specific, lightweight version of Java called JavaCard [20] is used as secure execution environment for applications. For better performance, instead of using a software implemented virtual machine, processor hardware can be used for switching between multiple execution contexts and controlling access to system resources for each of these contexts. Such protection can be provided by CPUs in the form of multiple privilege levels and a Memory Protection Unit (MPU) as in the case of ARC SecureShield™ Technology [21]. The next section, “Processor Level Protection Mechanisms”, describes these mechanisms in more detail.

At the right bottom of both sides in Figure 4, a block is depicted representing secure, non-CPU system resources that require protection. As described in the previous section, these could include secret keys but also specific peripherals like a fingerprint reader. There are several ways of protecting access to hardware resources. For traditional designs using a bus-based infrastructure, either multiple, isolated buses (secure and non-secure) could be used, or a sideband signal could be added to the bus that indicates whether the bus transaction is considered secure or not. Figure 5 schematically depicts such a scenario. Only when the

Page 8: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

8

‘secure’ sideband signal is active, access to slaves like memory and peripherals is granted. The sideband signal is driven by the master initiating the request and should be trusted. This means not only that a secure CPU processor must truthfully generate this signal, but also that all other masters on the bus, like a normal, open CPU or a DMA capable peripheral controller that is programmable by non-trusted software, should implement these signals.

Secureperipheral ‘Secure’

memory

Regularmemory

SecureShield

CPU

TrustedS

W

No

rmal

SW

Open CPU

Open SW

Secure CPU

Trusted SW

Normalperipheral

Figure 5. Access control with secure bus sideband signal

An alternative way of protecting secure hardware resources is to not access them through a public, shared bus, but to access them directly from the CPU. This ‘closely coupling’ is a feature initially developed for saving area and power [22][23][24]. By leveraging the extensibility of a CPU like ARC with APEX, instead of accessing the control registers of a peripheral controller via a regular bus, these control registers are mapped into the register space of the processor directly. The already existing mechanism of CPU privilege levels controls access to the peripherals in this case. Figure 6 below depicts such a system.

Secureperipheral

Securememory

Regularmemory

SecureShield

CPU

TrustedS

W

No

rmal

SW

Normalperipherals

Figure 6. Access control with tightly coupled memory and peripherals

Besides protecting non-trusted access to peripherals, this technology can be used for secure memory accesses as well when the CPU supports such close coupling for instruction and data memory.

Processor-level protection mechanismsAt the processor level, several security features enhance the protection of a system by implementing access control to critical resources, by tamper and fault detection, by side-channel protection, and by protection against reverse engineering and IP theft. Architecture trade-off decisions for these features are partly determined by the system-level choices — for example combining trusted and normal code on a single processor or using a separate secure processor — and partly determined by security versus performance and area requirements — for example applying memory and pipeline encryption or not.

Page 9: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

9

For controlling access to critical or security-sensitive processor and system resources, a processor can support multiple execution privilege levels and a memory protection unit as introduced in the previous section. The privilege levels control access to certain CPU control registers by only allowing access from higher levels. In combination with software, two privilege levels are enough for building secure systems. When a processor supports more than two privilege levels, more efficient, fine-grain differentiation in access control is possible. The MPU controls access to memory and memory mapped peripherals by checking and enforcing the access attributes that are defined for specific address regions. The combination of both protection mechanisms can be used to securely shield trusted software from non-trusted software. Moreover, as depicted in Figure 7, they can be used to implement multiple isolated execution environments on a single CPU, each with their own trust level and corresponding access rights.

Application 1 trusted code

Application 2 non-trusted

Application n partially trusted

Protected system resources

Figure 7. Multiple trusted execution environments on a single CPU

These multiple trusted execution environments provide a powerful way to securely execute software from different sources and with different trust levels on a single CPU. For further speed-up of context switching between normal and trusted execution contexts, certain CPU resources can be duplicated so that each execution context has its own instance using register banking.

To support tamper and fault detection, a processor can implement features for checking the integrity of memory and processor registers. Using parity bits and Hamming codes, bits that flipped due to tampering using, for example, led or laser flashing, can be detected. On accessing memory or registers that have been tampered with, an exception is raised to the highest, secure execution privilege level so a trusted exception handler can take adequate countermeasures. Depending on the amount and frequency of errors a single transaction could be aborted, or if the attack is considered more severe, all sensitive key data could be deleted from registers and (persistent) memory. For other types of tamper attacks, non-maskable interrupt lines could be connected to tamper-detection sensors that raise an interrupt when the enclosing of a device is opened or the temperature or voltage levels are outside the tolerated range. Finally, a secure watchdog timer can protect against denial-of-service attacks by detecting that a task is taking longer than normal or by detecting that trusted software is not executed at regular intervals. In case of an expiring watchdog timer, a reset signal is generated and, as a result, the processor starts executing the initial, secure root-of-trust software again. On detecting a warm reboot due to the expired watchdog, this trusted software can take countermeasures like disabling a peripheral interface that overloads the device or by restoring a trusted software image when the attack could be caused by a recent insertion of malicious software.

Many technologies to protect against side-channel attacks are on the physical, the system or on the algorithm and protocol level. Examples include the use of additional metal layers for shielding, additional capacitors for masking current variations, using random numbers for masking keys during computations, and changing keys before enough information has leaked through a side-channel to recover the secret. But at the processor level as well, there are a number of technologies for protection against side-channel attacks. During processor design or configuration, care should be taken to avoid instruction timing variations due to data dependencies. Multiplications by zero should take the same amount of time as non-zero multiplications, and taking a branch or not should not influence timing. Furthermore, the power profile of the processor should be flattened as much as possible. However, since flattening of power profiles is not always fully possible, additional countermeasures can be implemented in the processor hardware by randomizing the power and timing behavior of operations with additional computations. Since additional computations consume additional energy, again, power versus security level trade-offs must be made in this case. However, when the randomization can be applied only to critical sections of software, the impact on the overall energy consumption can be minimized.

The final class of countermeasures discussed in this section addresses reverse engineering and IP theft attacks. Encryption and scrambling are the general techniques to protect application code and data. These

Page 10: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

10

techniques should be applied to memories, but can be applied at other elements of a processor too. Figure 8 depicts an example where instruction encryption is integrated into the processor pipeline. Such an encrypted instruction processor pipeline provides a very high level of protection, since decrypted instructions are never stored in memory or in registers and are only decrypted just before they are used.

Instruction memory

Aligner

Instruction predecode

Decrypt

Commit logic

Decrypt Instruction decode

Register file

ALU

Fetch Execute Commit

Figure 8. Pipeline encryption

Figure 8 shows how this can be implemented in a power-efficient three-stage pipeline by including decrypt logic in both the Fetch and the Execute stages. Since the decryption is executed in-line with the processor pipeline, the algorithms used in this case should be of limited complexity and logic depth.

Another element where encryption and scrambling can be used is on data memories. Since data can be both read and written, both encryption and decryption is required. Besides encrypting the data itself, it is also possible to rearrange the location in the memory where the data is stored by permuting the address lines.

When all of these techniques are combined with the access control protection that is provided by an MPU, the techniques enforce each other and a powerful layered security solution results, as depicted in Figure 9.

Application 1 trusted code

Application 2 code

Key 1

Key 2

Physical memory MPU view

Application 2 encrypted

memory region

Application 1 encrypted

memory region

Figure 9. Memory encryption and address scrambling

In the unlikely event of an issue with the MPU protection that may result from a mistake in the trusted, privileged software that configures the MPU, the applications are still securely sandboxed since the encryption for the regions differs. If the region of the non-trusted Application 2 in Figure 9 would incorrectly provide access to addresses of the secure region of Application 1, then Application 2 would need to break the

Page 11: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

11

encryption of both Application 1 and 2 before having access to the data, since it would need to reverse the incorrect decryption with the algorithm or key for Application 2 and then decrypt using the correct algorithm for Application 1. Furthermore, if somehow physical access to the memories would be achieved completely bypassing the MPU, then 2 levels of encryption and scrambling would still remain intact: the memory encryption as well as the address line scrambling.

Software level protection mechanismsSome of the protection mechanisms at the software level have already been discussed or introduced in the previous sections, like cryptography software and MPU protection. In this section a comprehensive list of software technologies that complement the hardware mechanisms is presented, as well as a more detailed description of the ones not covered so far. As depicted in Figure 10, ‘software’ is interpreted in a broad sense, including not only run-time software that is part of a final product, but also a number of software tools that enhance the security of IoT devices.

So

ftw

are

too

ls

Application software

Platform infrastructure SW

Hardware platform

∙ Automated security testing∙ Static and dynamic code checkers∙ Binary image signing and encryption∙ Certificate and key management, provisioning

∙ Communication services∙ Storage services∙ Application sandboxing∙ Software authentication and integrity checking∙ Secure boot and update∙ Crypto library and key management

Figure 10. Software level protection mechanisms

The first software tools required for building secure IoT devices are tools for managing the device specific and product family generic secrets like symmetric keys, device identifiers, and public key certificates. Although for simplicity a single key is often used for protecting all devices from a product family, this practice implies that if the secret for one device is retrieved by an attacker, all devices of the family that share that key are immediately insecure. A better approach is to have device-unique keys, or a combination of device-unique keys and shared platform keys. These keys, device identifiers, and other secret data all need to be generated, managed, as well as provisioned to the devices during manufacturing in a secure way. Standard cryptography tools can be used for key generation. Depending on the specific non-volatile key storage solution chosen for an IoT product family — like secure NVM, fuses, or PUF — specific key injection tools should be used in a secure way, typically by implementing this key provisioning in a trusted, secure environment.

For the memory encryption described in the previous section, as well as for firmware authentication and integrity checking, tools are required to sign and/or encrypt firmware images. These build on the key management tooling for the authentication codes, certificates and encryption keys, and can either operate as a post-processing step on binary images delivered by software build tools, or could be further integrated into the software build environment. In the case of region-based encryption, the tools should apply different algorithms or use different keys for different parts of the binary images.

The last two types of tools prevent and detect potential security flaws in software, either design time by performing source code analysis or during verification by performing automated security testing. There are many software quality tools [25] that help improve general software quality. Fewer bugs mean fewer security risks. But there are also static analysis tools that have specialized support for finding the type of software errors that are typically exploited by attackers in different programming languages, like buffer or stack overruns and null pointer de-references in C code, SQL injection, or cross-site scripting in web languages as JavaScript. An example is the Coverity Static Application Security Testing (SAST, [26]) tools suite. Expanding on the static analysis, another technique can be applied called Interactive Application Security Testing (IAST, [27]). IAST enhances static code analysis with dynamic run-time analysis techniques that inspect code and data flows to better understand vulnerability context. This especially helps prevent false positives and improves analysis efficiency. The final class of software tools focuses on verification. Instead of manual penetration testing by, for example, checking for known exploits, tools like Defensics [28] include the know-how of security experts and can do the testing automatically and systematically. By implementing a technology called fuzzing — sending intentionally invalid data to a product to trigger exploitable faults — this class of tools not only helps preventing known exploits, but also helps preventing unknown exploits.

Page 12: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

12

The Platform Infrastructure Software box in Figure 10 represents all low-level, system software in an IoT device including a (Real-Time) Operating System or minimal baremetal infrastructure, device drivers, boot and other platform initialization software. Furthermore, it includes middleware services like run-time libraries for cryptographic algorithms, protocol stacks for communication, file system or other persistent storage, and web protocol implementations for interaction with other devices and with storage and processing services in the cloud. All of these should provide a high-level, hardware abstracted set of services to application software, while minimizing footprint and other resource usage. Looking at security services provided by the platform software, two types are specifically important for IoT systems that have not yet been addressed: platform security and secure communication protocols.

The platform security features cover services like secure boot, access control, identification & authentication, firmware integrity assurance, runtime protection and application sandboxing, secure storage, secure in-the-field updates, secure provisioning, storage and management of keys, certificates and other data, device and feature activation, revocation and recovery, and personalization. Platform security starts with a — hardware guaranteed — root of trust. The hardware guarantee typically consists of fixed boot ROM software that cannot be tampered with. Alternatively, the processor start code could be placed in reprogrammable non-volatile storage as well, if the hardware supports a form of on-the-fly integrity and authenticity checking or instruction encryption that is strong enough for the specific IoT device and corresponding attack scenarios since in that case the processor hardware will detect tampering of the root-of-trust firmware. Starting from this trusted boot software, further platform infrastructure code as well as application code can be loaded from flash or other background storage, and checked using the hardware and/or software cryptography functions of a device. Often this is implemented in a multi-staged bootloader where both the system resources that can be used for the loading and verification of firmware, as well as the complexity of firmware encryption, grow with each step. The first stage bootloader could, for instance, use a platform key and a keyed hash-based message authentication code (HMAC) from secure storage, whereas a next stage bootloader could use X.509 public key infrastructure and check firmware signatures using certificates. After the secure bootloader has verified the rest of the platform firmware, this software can continue system initialization and set-up the MPU for several securely shielded sandboxes for different applications or secure services, as described in the previous section. One important trusted service implements secure storage of keys and other data. As with the secure boot, for keys a trusted chain can be created starting from one or more platform or device keys in trusted secure, non-volatile storage. Using these keys, other keys and data can be protected (encrypted as well as integrity checked) and stored in larger but less protected non-volatile storage. By executing the secure storage services inside a trusted and shielded environment, other (non-trusted) applications cannot access directly the secrets. When other applications need encryption services, instead of having access to the keys required for encryption or decryption of data, they can be provided an identifier to that key that can be used with the secure data storage services. Besides the encryption/decryption, services should also be provided to create new keys and manage the existing keys.

To secure communications between IoT devices, gateways and cloud services, several solutions can be chosen from. As with cryptographic algorithms, it is highly recommended to use well-known, proven secure communication protocols, given the high complexity of designing protocols that are robust to all known attacks. Unfortunately, many of these existing protocols have been designed for more capable and more power hungry devices than low-power IoT edge nodes and always-on wearable devices. A lot of research, development, and standardization are still ongoing in the area of lightweight but secure communication protocols for IoT applications. Given this evolving landscape, the security options for a few more traditional internet communication protocols are presented as an example for IoT edge nodes. Figure 11 lists IP-based communication protocol stacks for Ethernet, WiFi, and 802.15.4/6LowPan. Since all are IP based, the higher level protocol layers are interchangeable, though typically the 802.15.4 based wireless personal area networking will be used with connectionless UDP instead of the connection-oriented TCP protocol. Furthermore, a special optimized routing protocol for low-power and lossy networks (RPL) can be used for personal area networking.

Page 13: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

13

802.15.4 802.11

WiFi

802.3

ENET

IPv6, RPL

802 11

IPv4

802 3

IPv6

DTLS

HTTP/ REST MQTT

LWM2M XML, JSON

UDP, TCP UDP

CoAP

TLS

808080222.151515 44.46LowPAN

IoT application

Figure 11. IoT communication protocol stack

Table 1 provides a description of the different protocols depicted in Figure 11. Focusing on security, three layers in the stack are highlighted in Figure 11. These correspond with different options for securing communication: either at the application level, the transport layer, or the network/data link layer. Application-specific encryption, authentication, and/or integrity checks could be implemented at the application level. But since protected communication is a requirement shared by all IoT devices, it is more efficient to leverage generic mechanisms from standardized communication protocols. TLS and its datagram version DTLS operate on the transport layer. They provide confidentiality and integrity, and can provide both client and server authentication. Main benefit is that they enable secure communication over non-trusted network and transport layers. The main drawback is that they depend on public key cryptography and infrastructure that require more resources than solutions using only symmetric cryptography with pre-shared keys.

Protocol Glossary

LWM2M Lightweight Machine to Machine protocol

XML, JSON Machine readable representations of structured data (Extensible Markup Language, Javascript Object Notation)

CoAP Constrained Application Protocol; resource optimized alternative to HTTP

HTTP/REST Representational state transfer; stateless client-server communication protocol, used with HTTP

MQTT Message Queuing Telemetry Transport; lightweight publish/subscribe protocol

DTLS Datagram Transport Layer Security; secure communication over UDP

TLS Transport Layer Security; secure communication over TCP

UDP User Datagram Protocol; connectionless

TCP Transmission Control Protocol; connection-oriented

RPL Routing protocol for low-power and lossy networks

IPv4, IPv6 Internet Protocol v4, v6

6LowPAN IPv6 over Low power Wireless Personal Area Network

802.15.4 Short-range wireless network standard

802.11 Wireless LAN standard

802.3 Wired Ethernet standard

Table 1. Glossary of IoT protocols

As an alternative, or in addition to the transport layer security, communication can be protected at the network or data link layer. Well known examples are WiFi Protected Access (WPA) [29] and IPSec [30]. These provide similar protection as (D)TLS, but at the network layer and thus all layers and applications on top benefit. This

Page 14: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

14

can, however, mean that communications by different applications over the same network interface are not protected from each other. Different variants of network and data link layer solutions exists, including efficient versions based on pre-shared keys that do not require the heavier public key algorithms and infrastructure.

Example and ConclusionTo conclude this paper, a system reference architecture that brings together the system, processor and software security technologies is presented. The architecture matches a range of IoT edge node products, from simple connected sensors to more complex wearables. It combines connectivity, sensor processing, application processing and security on a single low-power processor. In Figure 12, modules that specifically address security are colored green. At the bottom, peripheral interfaces are depicted ranging from UART, SPI, and I2C for connecting accelerometer, gyroscope and compass for 9D motions sensing, to an analog interface for smart meter power measurements. Furthermore, with restricted secure access, key storage (NVM, fuses) and other protected peripheral interfaces are included to connect for example a biometric sensor. For efficiency and protection, the peripheral interfaces are closely coupled to the processor and not exposed through the system bus. At the left, connectivity interfaces are placed that typically connect through a system bus due to direct memory (master) access or high bandwidth requirements. At the right of Figure 12, hardware accelerators are depicted for cryptographic algorithms. These could be full offload engines, but also extension instructions speeding up software implementations. A TRNG is included as well.

Sensor and actuator connectivity

Crypto accelerators

JTAG

SHA-2

Timers

Instruction ROM/SRAM

Data SRAM

Execute Commit

Debug

IFQ

Interrupt controller

Memoryprot. unit

ARC EM5D + ESP option

AES

RSA/ECC

TRNG

GPIOUART ADC IF SPI I2C

Hardware (low-power processor with DSP, security and peripheral extensions)

Watchdog

Communication interfaces

USB

BlueTooth LE

AHBbus

Data Memory

ARCv2 DSP ISA

µDMA

Secure peripheralO p

Key storage

Cryptoand key

management

Securecomm.

and storage

Sensorfusion

Power metering

Application software

Cryptoand key

management

Securecomm.

and storage

Sensorfusion

Powermetering

Application software

Platform infrastructure, secure boot and resource management

Software (I/O drivers, host drivers, DSP functions, security software)

Figure 12. Reference architecture for a secure IoT device

The processor is shown in the middle of the figure. In this architecture the low-power Synopsys DesignWare ARC EM5D processor with Enhanced Security Package (ESP) option is chosen [21]. This processor and enhancement package implement regular application and control processing, DSP processing and all the required security features in a single, efficient three-stage pipeline. It includes encrypted instruction and data memories, encrypted pipeline, memory protection unit, address scrambling, and a watchdog timer for security. For high-performance, low-power DSP processing the ARCv2 DSP ISA is supported. Regular timers, interrupt controller, debug interface and an area-optimized DMA engine complete the feature set of the processor.

Page 15: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

15

At the top of the diagram the software modules are depicted, starting with platform infrastructure software that supports secure boot and resource management. It initializes and controls the hardware sandboxing features leveraging the multiple privilege levels of the processor and the MPU. On top of the platform infrastructure, several services and application software run, each in their own securely shielded, trusted execution environment. The services include cryptography and key management, secure communication protocols and storage, signal processing algorithms for power metering and for sensor fusion — potentially from different 3rd party suppliers and protected with different firmware encryption — and the application software that ties everything together and implements the actual functions and use-cases for the IoT device.

When architecting an IoT system, complex, inter-dependent, and multiple disciplined trade-offs have to be made. Security is an emerging system property that should be considered throughout the full design. In this paper security challenges, requirements, and technical solutions have been presented. Making the required trade-offs is significantly easier by leveraging secure, proven building blocks that were designed with secure systems in mind and that were optimized for low footprint and energy. Depending on the specific IoT device threat model and the resulting security requirements, trade-offs can be made and the optimal mix of features can be decided on, resulting in a secure architecture that can be efficiently implemented.

References[1] United States National Institute of Standards and Technology (November 26, 2001). “Announcing the

ADVANCED ENCRYPTION STANDARD (AES)”. Federal Information Processing Standards Publication (FIPS) 197.

[2] IEEE (2000) “1363-2000 - IEEE Standard Specifications for Public-Key Cryptography”. doi:10.1109/IEEESTD.2000.92292. ISBN 0-7381-1956-3.

[3] United States National Institute of Standards and Technology (August, 2015), “Secure Hash Standard (SHS)”, Federal Information Processing Standard Publication (FIPS) 180-4.

[4] ITU-T (October 2012). “Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks”. ITU-T X.509

[5] IETF RFC 5246 (2008). “The Transport Layer Security (TLS) Protocol Version 1.2”. IETF Network Working Group Request for Comments: 5246

[6] IETF RFC 6347 (2012). “Datagram Transport Layer Security (TLS) Protocol Version 1.2”. IETF Network Working Group Request for Comments: 6347

[7] EMCCo (November 2011). “EMV Specification 4.3”. Book 1,2,3,4

[8] Open Mobile Alliance (2008). “OMA Device Management 1.2”. Current Releases.

[9] The Open Web Application Security Project (2015). OWASP website.

[10] OWASP Internet of Things Project (2015). OWASP IoT project.

[11] Common Criteria for Information Technology Security Evaluation (2015). Common Criteria.

[12] Common Criteria Protection Profiles (2015). Protection Profiles.

[13] Payment Card Industry Security Standards Council. PCI website.

[14] Hewlett Packard Enterprise (2015). “Internet of things research study”. HP IoT Research Study.pdf.

[15] Synopsys DesignWare ARC CryptoPack Option (2015). Synopsys website.

Page 16: Securing the Internet of ThingsSecuring the Internet of Things An Architect’s Guide to Securing IoT Devices Using Hardware Rooted Processor Security Author Ruud Derwig Senior Staff

03/30/16.AP_CS7011_ARC Security_WP.

Synopsys, Inc. • 690 East Middlefield Road • Mountain View, CA 94043 • www.synopsys.com

©2016 Synopsys, Inc. All rights reserved. Synopsys is a trademark of Synopsys, Inc. in the United States and other countries. A list of Synopsys trademarks is available at http://www.synopsys.com/copyright.html . All other names mentioned herein are trademarks or registered trademarks of their respective owners.

[16] Synopsys DesignWare ARC Processor Extensions (2015). Synopsys website.

[17] Synopsys DesignWare Cryptographic Cores (2015). Synopsys website.

[18] Synopsys DesignWare Security Protocol Processors and Accelerators (2015). Synopsys website.

[19] Synopsys DesignWare ARConnect Option (2015). Synopsys website.

[20] Oracle (2009). “Java Card Specification”. Oracle website.

[21] Synopsys Enhanced ARC Security Package for ARC EM Cores (2015). Synopsys website.

[22] Jeroen Geuzebroek, Ad Vaassen (2014). “Building an Efficient, Tightly Coupled Embedded System Using an Extensible Processor”. Synopsys Processor Solutions White Paper.

[23] Jeroen Geuzebroek (2014). “Leveraging Processor Extensibility to Build an Ultra Low-Power Embedded Subsystem”. Synopsys Processor Solutions White Paper.

[24] Synopsys DesignWare Sensor and Control IP Subsystem (2015). Synopsys website.

[25] List of tools for static code analysis (2015). Wikipedia website.

[26] Static Application Security Testing (2015). Coverity website.

[27] Interactive Application Security Testing (2015). Coverity website.

[28] Defensics (2015). Codenomicon website.

[29] IEEE (2004). “IEEE Standard for information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 6: Medium Access Control (MAC) Security Enhancements”. 802.11i-2004 standard

[30] IETF RFC 2401 (1998). “Security Architecture for the Internet Protocol”. IETF Network Working Group Request for Comments: 2401.