"The Internet of Things - a techie's viewpoint" by Jan Newmarch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://jan.newmarch.name/IoT/.
The lowest level of a microcontroller or microcomputer is made up of the chips themselves and the systems (SoC, motherboard) they make up. Chips are made up of the digital circuitry, some ROM and RAM, and some code stored on ROM or loaded into RAM. If any of these are perverted, then security at a higher level may be wasted.
The ARM Security Technology document makes several points:
Defending against all possible attacks is an impossible task; there is always someone willing to spend a significant amount of time and money to break any security scheme using very complex attacks.
the security requirements for a design ... should be described in value terms: “attack A on asset B should take at least Y days and Z dollars”. If a set of countermeasures mean that a successful attack will take too long or will cost too much, then the defense is a success.
The document later lists some possible classes of attack:
Lab attacks are likely funded by governments, terrorist organisations or the most sophisticated of the hacker groups. Attempting to defend against these may only be worthwhile for extremely sensitive and valuable data. Defending against the other attacks is much more feasible.
Chips may be tested during the manufacturing process. This only covers a small part of the chip's lifespan: it will be built into a complex system and deployed into some environment. There, it may need to be debugged or re-programmed to improve functionality or remove security problems.
Anything that can be used for good purposes can also be used for bad ones. If the maintenance engineer can upgrade a chip in the field, then a hacker can pervert it to their own purpose. In The IoT, devices are more often likely to be placed into un-attended locations with easy physical access, leaving them potentially much more likely to be physically attacked than, say, a PC in an office.
There are a variety of in-system programming systems: there is no one standard, but some are very common.
From AVR910: In-System Programming
- Complete In-System Programming Solution for AVR Microcontrollers
- Covers All AVR Microcontrollers with In-System Programming Support
- Reprogram Both Data Flash and Parameter EEPROM Memories
- Complete Schematics for Low-cost In-System Programmer
- Simple Three-wire SPI Programming Interface
JTAG ( Joint Test Action Group) was designed for debugging circuits in place, and was later extended to in-system programming. See High-level Guide to JTAG for a positive view of the not-inconsiderable benfits of JTAG.
See Attacks and Defenses for JTAG for a discussion of issues.
See Programming formats for PIC® microcontrollers by Microchip
The Java Card is small: "In 1997, the specification for a smart card that would support was to have at least 64k of ROM, 16k of EEPROM, and 256 bytes of RAM" It can run multipe aplications in multiple security domains. Targetted by GlobalPlatform Card Card Specification - Networked Framework
A simple example would be a smart electricity meter for a home. This has a number of different users: the home owner, the meter owner, the electricity supply company and the communications company linking the meter to the meter's owner. There will be several use cases with the different parties:
These different groups will have access to different parts of the meter's system, all protected by appropriate security. If the electricity supplier changes, then the meter will need to update the supplier.
Global Platform has produced a set of specifications regarding privacy and security concerns. They specify
A secure element is "a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (e.g. key management) in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities."
The intention behind a secure element is that it should provide a stable system that is more difficult to hack into than a normal system. It probably won't be totally resistant, but should be sufficiently so that most attackers will go elsewhere. The applications that run on such a chip should be fairly minimal or they might be subject to bugs which might leak keys or other sensitive data. However, there must be routes whereby sufficiently trusted external applications can interact with the applications on the secure chip.
The security domain will include the storage component of a secure element that guards the private and secret keys for the element. This domain should be careful not to expose these keys on, say, a public bus that can be snooped by other components of a system.
The Global Platform requires a secure element. This may be provided by a separate hardware unit, or by appropriate controls within a single hardware unit. The so-called ARM TrustZone processors have a bus structure that allows a single processor to act in secure or non-secure modes by adding an extra control signal signal on the system bus. This is used to signal secure or non-secure transactions using a single processor with a "secure virtual core" and a "non-secure virtual core". The non-secure virtual core can only see non-secure resources while the secure virtual core can see all resources.
The Memory Management Unit (MMU) is aware of the two modes. The virtual memory tables for each mode are independent. Cache memory is also aware of the two modes using an additional tag bit.
Interrupts are trapped by a monitor which exists outside of the secure and non-secure worlds. This allows it to route interrupts appropriately.
Debugging has also been carried into the TrustZone architecture. There are the following possible views:
When a TrustZone system boots, it starts in the secure world. This allows it to perform integrity checks on any later boot code using the cryptographic keys under its control before switching to that code. This allows the possibility of an authenticated chain leading to secure and non-secure applications being loaded.
Not all ARM processors are enabled with TrustZone. Cortex-A8 onwards may be enabled. Genome Labs in their report on the Exploration of ARM TrustZone Technology states that at the time of their investigations nearly all ARM boards available switched to non-secure mode during bootstrap, so that TrustZone was not available on most boards.
The i.MX6 UltraLite seems to be one of the few publically known SoCs to use the ARM TrustZone technology. The Reference manual states that it contains the following chip security components:
This book does not intend to promote any particular vendor, but this SoC is impressive for its security features not only for its use of the ARM TrustZone capabilities but also for other features such as tamper detection which will be important for exposed IoT devices.
The FBI claim that they were recently able to hack into a particular model of an Apple mobile phone. Despite this, the Apple iOS 9.0 or later Security paper spells out the Apple model in great detail and this should probably be regarded as a model for device security.
The iOS security document does not explicitly state whether or not it uses the ARM TrustZone architecture, but it does mention the "Secure Enclave coprocessor" for ARM A7 or later processors and it is a reasonable assumption that it uses TrustZone.
An iOS device has code laid down in the Boot ROM during chip fabication. This forms the root of trust. This contains the Apple Root CA public key which it uses to check that the next stage Low-Level Bootloader is signed before executing. Similarly, each stage verifies the next stage is signed by Apple before executing it, ending up at the iOS kernel.
Firmware upgrades are sent by an "Authorisation server". This server adds the device's unique identifier to the firmware and signs that so thtat the device can ensure that the firmware is intended for that device alone.
"The Secure Enclave is a coprocessor fabricated in the Apple A7 or later A-series processor. It utilizes its own secure boot and personalized software update separate from the application processor. It provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has been compromised".
It uses encrypted memory and includes a hardware random number generator which is used to generate any needed cryto keys. The secure enclave has its own UUID which is not accessible to other parts of the system and is not known to Apple. This is the key to Apple's stated inability to access the devices. This key is used the encrypt data saved to the file system.
Encrypting the file system in this way makes it impossible to just move memory from one device to another - it is unreadable on any other device.
File are encrypted using a per-file key which is used when the file is written to flash memory. Several other keys are used for additional protection.
This chapter has looked at the lowest levels of security, involving the chips and processing elements used in computing systems. There are a number of potential security holes which can be plugged if the architectural design is done correctly. The later ARM chips have low-level hardware support, but this is not always available. Apple have a well-designed security architecture which may be worth copying.
Copyright © Jan Newmarch, jan@newmarch.name
"The Internet of Things - a techie's viewpoint" by Jan Newmarch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://jan.newmarch.name/IoT/.
If you like this book, please donate using PayPal