Internet of Things
Engineering the root of trust for optimum IoT security
By Bart Stevens, senior director, product marketing, cryptography, Rambus
S
ecurity threats to electronic systems grow with each passing day. The recent discoveries of the Spectre, Meltdown and Foreshadow vulnerabilities in popular processors have revealed long-hidden opportunities for side-channel attacks that are causing some to suggest an important shift is needed in the way processors are designed to deliver both performance and security. Spectre, Meltdown and Foreshadow
refer to techniques that could be used to manipulate a CPU’s speculative execution processes to bypass normal checks on the memory-access privileges of applications. Speculative execution is an aspect of out-of-order processing (OoOP) and a pillar of the acceleration techniques employed in several generations of processors including the x86 and Arm devices that underpin much of today’s online and connected world. The performance gains associated with OoOP are too valuable to forego. However, the recently discovered vulnerabilities could allow malicious processes to access protected data despite not having the right credentials. Processor designers are working to patch them, and it is true that not all architectures suffer from these three weaknesses in particular. However, other vulnerabilities are sure to be around the corner. A more rigorous approach is needed to protect general-purpose CPUs against devious attacks that aim to exploit internal architectural weaknesses.
Protect against the inevitable Any connected device can be expected to become the target of cyberattacks that aim to steal personal data or intellectual property, steal authorisation credentials for accessing connected servers or systems, or corrupt its functionality; this may be done covertly, such as in the Stuxnet attack – which intended to sabotage uranium refining by subtly changing centrifuge speeds whilst falsifying instrument readings – or in more overt ways such as shutting down essential infrastructures or interfering with the controls of a connected car.
30 March 2020
Moreover, in the age of the IoT, any network can expect to be attacked by hackers seeking to gain access using credentials stolen from legitimate devices
secure functionality in the main application processor or custom ASIC can deliver superior security performance. In particular, isolating execution of sensitive code from the primary CPU helps avoid vulnerabilities like Meltdown, Spectre and Foreshadow. This also permits the primary CPU to be optimised for high performance, low power consumption, or other desired
Figure 1. Root of Trust IP integrated in the SoC/ASIC provides services to the application processor
on the network, by taking over authorised devices, or by intercepting or eavesdropping on communications to gather confidential information. Devices can also be subjected to insider attacks within the facilities where they are manufactured or personalised, before they are deployed in the field. After being deployed, connected devices can be subjected to man-in-the-middle attacks and replay attacks, and attempts to take advantage of the firmware- update process to load malicious code.
Architectural options for securing connected devices In end devices, the immutability of hardware, as opposed to software or firmware that are frequently updated and patched, provides a firm basis for identifying the device, securing the boot process, validating firmware updates received across the network, and securely storing, encrypting and decrypting data using industry-standard cryptographic algorithms executed in dedicated accelerators. This helps establish a root of trust in the device and in the data supply chain. Hardware security can be
implemented in a dedicated integrated circuit (IC), also called a secure element, acting as a companion chip to the main processor. However, embedding the
Components in Electronics
characteristics, without risk of exposing sensitive data. Rambus created the CryptoManager Root of Trust Core as a set of programmable, secure silicon IP cores including hardware crypto engines and a secure RISC-V CPU (figure 1) to provide security services to the main SoC or ASIC application processor. These services include secure boot and runtime integrity checking, remote authentication and attestation, and symmetric and asymmetric cryptographic algorithms. The CryptoManager Root of Trust restricts access to cryptographic accelerators, keys, memory ranges and I/O pins at the silicon level. The
hardware also performs key derivation, which enables key strengthening and improved secrecy. Proper protection at the silicon level must also include anti-tamper mechanisms to block attacks such as bus probing, fault injection, and over- clocking. The CryptoManager Root of Trust Core incorporates logic and crypto redundancy, secure-state encoding, and ephemeral keys that are generated on the fly from multiple splits and flushed immediately after use. In addition, CryptoManager Root of Trust cores feature an optional entropic array with a proprietary logic structure that provides robust protection against emulation and reverse engineering. Resistance to Differential Power Analysis (DPA) is also available in some configurations. DPA, which involves analysing the chip’s power usage when performing cryptographic calculations, can capture enough information for hackers to recover the secret key value. DPA-resistant cryptographic cores, embedded in the RT-660 CryptoManager Root of Trust Core, include features to thwart key-correlation analysis.
Multiple roots of trust With the ability to isolate resources, keys, and security assets needed by various entities in the supply chain, such as the chip vendor, OEM, and third-party service providers, multiple roots of trust can be supported (figure 2). Each entity can use its own root and derived keys, and access specific features such as OTP, debug, and control bits on a siloed basis with no need to trust the other entities. Permissions can be assigned at any point in the device lifecycle, and signed secure
Figure 2. Support for multiple roots of trust containerises resources available to mutually untrusted entities
www.cieonline.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48
