B2-Definition-of-Terms
B2 Definition of Terms
The job of an IoT device supply chain is to deliver devices into an application in a known, trustworthy, and trusted state. As well as delivering hardware and software, an IoT device supply chain must establish trust relationships. This characteristic is not shared by ICT supply chains in general.
Each component of an IoT device is the product of a preceding design and production process. It is more accurate to think of the supply “chain” as a supply “network”. Anyone in the supply network with access to unprotected assets becomes part of the trust base of that device. Producers of key components such as embedded operating systems, cryptographic libraries and ICs carry a significant burden of trust and must demonstrate that they deserve it. But, as the designer of the production process, it is the device OEM who chooses whom to trust and is responsible for securing it overall.
The supply network is comprised of four basic types of operation: hardware assembly, which progressively integrates components and subassemblies into complete devices, programming, which installs logical assets onto those devices, personalisation, which generates a unique identity for each device, and on boarding, which places those devices into trust relationships with other systems. Programming, personalisation and on boarding together comprise the provisioning process, by which hardware is put into a functioning state.
While device hardware is undoubtedly important, it isn’t likely to be attacked in the supply chain. In any case by far the biggest hardware determinant of devices’ behaviour is the processor IC, the design and manufacture of which is outside of device OEMs’ control. For most OEMs the main hardware risk is the use by Contract Electronics Manufacturers (CEMs) of grey market parts, which have been known to include manufacturing discards, recycled parts and counterfeits1. Much more vulnerable to cyber-attacks are the various provisioning operations (Table 6).
| Operation | Description |
|---|---|
| Programming | Programming is always performed via a programming interface exposed by the target. Programming operations place software and configuration assets onto devices. These can include assets such as: - software images and server certificates, which are the same for every device - manufacturing data and customer-specific settings, which change per batch - identity secrets and device certificates, which are individually personalised for each device. Device operators rely on the authenticity and integrity of all these assets - and, in the case of identity secrets, also their confidentiality. Device OEMs and ODMs on their part often have an interest in maintaining the confidentiality of their software IP. Secure programming is rarely as straightforward as installing a binary image. Sometimes binaries are rebuilt per device to check for a specific IC hardware ID, as a defence against cloning. In other cases, configuration data is installed as late as possible in production, or even deferred into distribution. Device identities might be generated externally and programmed individually. Programmed assets must be protected not just in the programming environment but on the target IC. Because of this, ICs entering a secure programming environment must be authentically what they are believed to be, and they must be configured to prevent unauthorised readout or modification of assets before they leave. |
| RoT Establishment | With no identity or correspondent software already present, ICs fresh off the wafer typically expose a hardware-level programming interface. This channel is necessarily unencrypted and unauthenticated. The first programming step, RoT establishment, must therefore take place in a secure facility. RoTs once established can expose secure interfaces for provisioning subsequent assets. Examples of this pattern include secure boot managers which can detect and install new valid software images and secure programming interfaces. Both are often found as features of RoTs installed by IC vendors. |
| Claiming | An OEM making use of a secure boot manager established by the IC vendor must claim it by programming it with a trust anchor with which to validate the next software in the boot chain. Like ROT establishment, this is a special case of programming. Claiming is a key moment in the life of an IoT device because whoever installs that trust anchor chooses what software runs and thereby takes full control of the behaviour of the device. |
| Personalisation | Every connected device requires a unique, authenticable identity. Ideally devices should generate asymmetric identity key pairs internally, so the private key need never be exposed externally. Most modern microcontroller RoTs are able to generate high quality key pairs. Older or smaller microcontrollers may lack robust sources of high-quality entropy. Their private keys must be generated externally. Ideally this is done as close to the target device as possible to limit the potential exposure of those keys. The provisioning tool is an ideal place to accomplish this. Personalisation can also include serial numbers and other public identifiers. |
| Onboarding | IoT devices are useless until they are connected into larger applications. Those applications need to be told which devices to trust and how to authenticate them. There are various ways of doing this, but all involve telling the central application to trust devices which can prove possession of specified secret keys. This is called on boarding. The act of on boarding is a major trust decision. When a device operator makes a decision to trust an IoT device they’re making a decision to trust it, and the supply chain that delivered it to them, including everyone who has had access to the device and its components. For a device with a RoT those components include I. The initial bootloader, on which the operator is relying to ensure only properly signed code runs, II. The RoT runtime services, on which they are relying to provide unimpeachable security services, and III. The embedded software developed by the device OEM or ODM, which the operator is expecting to behave exactly according to specification. Device operators unfortunately are not usually in a position to determine for themselves whether an IoT device has been provisioned into a known, trusted, functional initial state. Instead they must rely on someone else’s assurances. Someone they trust, often the OEM, needs to assert “this device is in a known trusted state”. Where devices are identified using asymmetric (private and public) keys this is accomplished by on boarding the public key to central services. This can be done in several ways. The simplest method is to take a copy of each devices’ public key on the production line and upload it to the central service. The copy should be taken when the device is fully provisioned, but before it leaves the trusted manufacturing environment. A more powerful and flexible method is to sign each device’s public key into a certificate chain on the production line and load that certificate chain back into the device. The device can later deliver its public key to the central service itself, as part of a TLS handshake. Central services can on board that key on the authority of any Certificate Authority (CA) certificate in the chain. Because this allows large volumes of devices to be on boarded in a single operation it is convenient for device operators to have their devices signed into their own certificate chain of trust. In each case, whether keys are on boarded directly to the central service from the production line or signed into certificate chains of trust, it is essential that only trusted parties perform that operation. The fewer entities involved the better. Signing devices into chains of trust offers a distinct advantage over other on boarding methods in this respect, because the CA keys can be stored in an onsite HSM or secure element, or offsite in a secure facility, where they can be used without ever being exposed in manufacturing environments. It is important to note that the private keys of all the CAs in the chain of trust must be similarly protected, because an attacker gaining the use of any of them gains the ability to on board any device they choose [2]. |
Table 6: Provisioning operations
To reach a known functional initial state, devices must be provisioned with many software and data assets and into many trust relationships, often in a sequence of provisioning steps that begins with a blank IC and ends with a fully functional and secured device. Each step may be performed by a different actor, each provisioning the device into an intermediate state. The process may begin upstream of the OEM, with IC vendors provisioning naked dies, and it may extend to as late as immediately before devices’ live deployment, with installers commissioning devices on site.
IoT OEMs already design provisioning sequences and create or specify provisioning tools (Figure 3) for each step of those sequences, as part of their device development. Because manufacturing environments have generally been assumed secure it has been rare to give further consideration to protecting these tools and processes against deliberate attack. In essence though security is just another design goal. OEMs can use their control of this process to allocate key steps to more-trusted suppliers. Alternatively, they can engineer provisioning tools to keep assets out of harm’s way in untrusted environments.
-
2015, Rob Wood, NCC Group, Secure Device Manufacturing: Supply Chain Security Resilience
-
2021, Michael Richardson, IETF, A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors