Mobile Technology
Secure memories in a connected world E
Authors: Cliff Zitlaw, Sergey Ostrikov
mbedded systems increasingly allow for cloud-based data collection, event detection and software updates. These
remote IoT devices are largely defined by the firmware stored in either the Host MCU or in the User Array of an attached non- volatile memory. The contents of these non-volatile memories are a primary target for malicious attacks. Countermeasures intended to prevent unauthorized alteration of the non-volatile memory have become a fundamental design requirement for all newly developed IoT devices.
This article describes the cryptographic and security infrastructure beginning to appear in discrete Flash memories and how these new features are used to secure connected IoT devices.
Next Generation Secure NOR Flash Products
NOR Flash manufacturers have developed products that integrate cryptographic infrastructure that can be used to provide a significant level of security. Device pairing
this new infrastructure, a number of security functions can be developed to support cryptographic security. Two features that are receiving a lot of attention in the NOR Flash area are access control of the User Array and layered code validation prior to execution.
Array Partitioning into Secure Regions
The User Flash Array of newer NOR devices can be partitioned into multiple regions with each region individually configured for legacy (non-secure) access or secure access. Regions configured for secure access can specify either controlled read/write access or authenticated access. Secure regions configured for controlled access can independently enable or disable read/write operations. The enable/disable setting is managed by an authentication sequence that requires the Host MCU to prove knowledge of a shared key. The shared key is loaded into both the Host MCU and the memory during
attests to the next layer before relinquishing control. A system level scenario becomes more complicated when Host MCUs are not able to integrate programmable memory. Discrete Flash devices are starting to appear that adopt the DICE strategy starting in the (presumed trustworthy) NOR Flash CPUSS ROM. The NOR Flash CPUSS ROM is executed upon Power on Reset (PoR) and initially validates that its own captive Flash Device Boot Code (in CPUSS Flash, not exposed in the User Array) is intact before allowing code execution to pass to the CPUSS Flash. This DICE Layer 0 Compound Device Identifier (CDI) calculation combines a Unique Device Secret (unique for every flash device) with a measurement of the Flash Device Boot Code resident in Layer 0. NIST SP800-56C describes acceptable cryptographic one-way functions to be used in the CDI calculation. The Unique Device Secret is used for the Layer 0 CDI calculation. Layer 0 CDI validation compares the calculated value with an expected value stored on-chip that has been provisioned by the NOR manufacturer.
Figure 1 - Connected Embedded System as a Leaf Node
(Host MCU and NOR Flash) and authenticated write (program and erase) operations have been implemented using symmetric cryptography. These devices have typically been state machine based using an HMAC engine and non-volatile monotonic counters. During the provisioning process, a symmetric key is loaded into both the Host MCU and the Secure NOR Flash device to be used during normal operations to perform authenticated read and write operations. More recently, internal NOR Flash infrastructure have evolved beyond what can be practically managed by internal state machines. Newer devices have integrated a CPU subsystem (CPUSS) that is able to perform advanced functionality like transparent wear leveling and bad block replacement. Once a CPU subsystem became part of the Flash device infrastructure, it wasn’t long before the idea of adding a crypto hardware block and a packet buffer became reality. With
manufacturing. Reads or writes attempting to access a region in the disabled state will return undefined data during reads and write attempts will be blocked. The power- up read/write access state for regions configured for controlled access is a configuration option. For example, a boot region might be configured to power-up as read-enabled and write-disabled while the remaining regions may have all read/write access disabled. Secure regions can also be configured to only allow authenticated read and write accesses. Authenticated regions do not allow for legacy reads and writes. Authenticated reads and authenticated writes are performed using a packet transfer that includes an HMAC demonstrating knowledge of both a shared key and the value of a non-volatile command counter. The command counter used in the access request protects against replay attacks.
Figure 2- Next Generation NOR Flash Device with Integrated Cryptography (using Serial Peripheral
30 February 2020 Components in Electronics
Security Between Software Layers Validating software in a layered fashion has also become commonplace in a secure environment. The Device Identifier Composition Engine (DICE) Work Group at Trusted Computing Group has published specifications and guidance for architectures in which each layer of code
Once the CPUSS Flash has been confirmed to be valid, code execution passes from the ROM Boot Code to the (Layer 0) CPUSS Flash Device Boot Code. Next, the NOR device validates the System Level Boot Code programmed into the User Array by the system manufacturer. The measurement of the System Level Boot Code is compared against a value that is stored on-chip during device provisioning. These two validation steps occur while the Flash device is performing its PoR sequence before the device is accessible by the Host MCU. Note that during the entire boot process, care must be taken to assure that the CDI values are not exposed to higher layers of code and, of course, malicious actors.
Upon completion of the Flash device PoR sequence, the System Level Boot Code is exposed to the Host MCU for execution. The system boot process can proceed with the
knowledge that the System Level Boot Code is authentic. The layered validation strategy can continue with the Host MCU managing the
Figure 4 - Secure Software Layering
validation of each new layer of software. Figure 4 is drawn as a linear progression
from the Flash Boot Code to a User Application. A real-world scenario is likely much more complicated, especially after program control has passed to the Operating System. Note that once the System Level Boot Code gains program control, each subsequent layer’s attestation value can be compared against either a local value (stored in the Flash device) or preferably to a value residing remotely (perhaps a cloud server). Remote validation may be made more secure with the use of
between the Host MCU and the Flash memory. Unauthorised access is dealt with using array partitioning and configurable access permissions. Maliciously altered code detection and recovery is addressed with the DICE strategy specified by the Trusted Computing Group. While the infrastructure integrated into newer Flash memories has addressed many of the security gaps present in legacy systems, it is probably just as important to recognize that the CPUSS architecture is able to address security issues that may develop in the future.
www.cieonline.co.uk Figure 3 - Secure Partitioning of User Array
Digital Certificates as described in the DICE specification.
Conclusion The security threats that have plagued legacy non-volatile memories are significantly mitigated with on-chip cryptographic infrastructure. Anti-cloning has been addressed with device pairing
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 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76
