A summary of security-enabling technologies for IoT devices
Arm Limited
Brendan.Moran@arm.com
Security
IOTOPS
Internet-Draft
The IETF has developed security technologies that help to secure the Internet of Things even over constrained networks and when targetting constrained nodes. These technologies can be used independenly or can be composed into larger systems to mitigate a variety of threats. This documents illustrates an overview over these technologies and highlights their relationships. Ultimately, a threat model is presented as a basis to derive requirements that interconnect existing and emerging solution technologies.
Introduction
This memo serves as an entry-point to detail which technologies are available for use in IoT networks and to enable IoT designers to discover technologies that may solve their problems. This draft addresses.
This draft addresses six trustworthiness problems in IoT devices; expressed simply as six questions:
What software is my device running?
How should my device connect to a network?
With which systems should my device communicate?
What is the provenance of my device's software and corresponding policies?
Who is authorised to initiate a software update and under which conditions?
How should my device trust updates to its software?
Each of these questions is answered by recently developed or developing standards. Each of these questions hides a security threat; so these threats are detailed in a threat model.
Threats and Risks to IoT Deployments
For this threat model to be useful to implementers, there are certain usability requirements that must be included to explain the origin of a threat. These are noted where necessary.
Sections are organised in groups of:
usability requirement (if needed)
threat
security requirement
mitigating technologies
Threat: IoT Network Credential Exposure
Network Credential Exposure describes the potential for exposure of credentials, including cryptographic material, used to access an IoT network. Note that "network" here describes a logical network, such as a LwM2M server and its clients.
Each physical network technology provides its own onboarding techniques. Recommended practice is to follow best practices for the physical network technology in use.
REQ.USE.NET.CREDENTIALS
It must be possible to provide a device with credentials to access a network. This is typically referred to as device onboarding. This may be done by the manufacturer, the supply chain, the installer, or the end user. It may be done by the device or on behalf of the device by a trusted third party.
THREAT.IOT.NET.CREDENTIALS
A threat actor extracts the credentials from a device or by eavesdropping on the credential provisioning flow
REQ.SEC.NET.CREDENTIALS
Network access credentials must be provisioned to a device in a way that secures them against eavesdropping or extraction.
Technologies to Mitigate THREAT.IOT.NET.CREDENTIALS
Several technologies are available for device onboarding:
Lightweight M2M Bootstrap provides a mechanism to provision keying material and configuration of any kind, according to a well-defined data model.
FIDO Device Onboard provides a mechanism to deliver an arbitrary block of data to devices. This block of data can contain trust anchors, cryptographic information, and other device configuration.
BRSKI provides a mechanism for "Bootstrap Distribution of CA Certificates", as described in , Section 4.1.1. In the process, a TLS connection is established that can be directly used for Enrollment over Secure Transport (EST).
Enrollment over Secure Transport (EST) provides a mechanism to deliver certificates and, optionally, private keys to devices.
Threat: Trust Anchor Private Key Disclosure
When a trust anchor of a device is used regularly, the chances of its private key being disclosed increase.
THREAT.IOT.TA.DISCLOSURE
A private key trusted by one or more devices is disclosed. This could be caused by: a threat actor within the organisation, a compromise of a service using the key, etc.
REQ.SEC.TA.ROTATION
It must be possible to deploy new keys to devices in order to update their active trust anchors. This does not mean that the ultimate trust anchor over a device is changed, but that its delegates are changed, enabling infrequent use of the ultimate trust anchor and higher security key management protocols to be deployed, such as key ceremonies and M of N threshold signatures.
Technologies to mitigate THREAT.IOT.TA.DISCLOSURE
Several technologies are available for trust anchor rotation:
Lightweight M2M Bootstrap provides a mechanism to provision keying material and configuration of any kind, according to a well-defined data model.
FIDO Device Onboard provides a mechanism to deliver an arbitrary block of data to devices. This block of data can contain trust anchors, cryptographic information, and other device configuration.
Enrollment over Secure Transport (EST) provides a mechanism to deliver certificates and, optionally, private keys to devices.
Threat: Incorrect Firmware/Version
Incorrect firmware/version can come in two forms.
THREAT.FW.OLD
Old firmware present on device allows compromise of data sent to device, poisoning of data sent to service
THREAT.DEV.ROGUE
Rogue or simulated device emulates a real device, allows compromise of data sent to the device, or poisoning of data sent to service
REQ.SEC.FW.MEASURE
To enable devices to report their current software version and related data securely, devices SHOULD support a support a mechanism to securely measure their firmware. This allows an IoT network to restrict access by non-compliant devices.
Technologies to implement REQ.SEC.FW.MEASURE
The technology used for securely measuring and reporting the firmware of a device is typically called remote attestation. A protocol is under development for conveying remote attestation measurements in a trustworthy way in . Likewise, document format is under development in .
Threat: Vulnerable Firmware
Devices with old firmware might have a known vulnerability. This could allow a threat actor to take over the device.
THREAT.FW.KNOWN.VULNERABILITY
If old firmware with known vulnerability cannot be altered. This allows exploit of known a vulnerability.
REQ.SEC.FW.REMOTE.UPDATE
Software on unattended devices must be remotely-updatable.
THREAT.UPDATE.COMPROMISE
Compromise of the update system is fundamentally equivalent to persistent remote code execution. A threat actor that gains firmware update capability has extensive power over the device.
REQ.SEC.UPDATE.SECURITY
Software update mechanism must be secured (see RFC9124)
Technologies to implement REQ.SEC.UPDATE.SECURITY
To enable devices to be updated securely in the field, they can support a remote update protocol such as . For securely deploying software to Trusted Execution Environments, the a secure Trusted Application delivery protocol should be used, such as .
Threat: Supply Chain Attacks
Software of unknown origin may be used in a device. If an threat actor can gain control over the software supply chain, they may be able to sneak their code onto a device.
RISK.SW.SUPPLY
Software of unknown origin may be used in a device
THREAT.SW.SUPPLY
If software origin is not verified, a threat actor may deliberately and secretly seed the software supply chain with vulnerable code, enabling further compromise.
REQ.SEC.SW.BOM
To prove the provenance of a firmware update, update manifests SHOULD include (directly, or by secure reference) a Software Identifier or Software Bill of Materials,
Technologies to implement REQ.SEC.UPDATE.SECURITY
In order to enable a device to prove provenance of its software, it or its network can use a software identifier such as . Optionally, this software idenifier can be encapsulated in a manifest that includes hardware properties as well, such as .
Risk: Verification Information Supply Chain
Correct values for attestation results may not be known by Verifiers, causing them to log values, but not limit them.
RISK.VERIFIER.DEFAULTS
Without access to a source of verification information such as expected attestation results, a verifier may not be able to make correct decisions about the trustworthiness of a device.
THREAT.TRUST.ELEVATION
A threat actor deploys compromised software to devices; this is detected by monitoring systems, but not identified as an attack. If a threat actor can cause an attestation system to trust a device more than it should, this forms a new class of elevation of privilege: elevation of trust.
REQ.SEC.VERIFIER.DATA
Monitoring systems must know the expected values in Attestation results.
Technologies to implement REQ.SEC.VERIFIER.DATA
To enable a Relying Party of the Remote Attestation to correctly evaluate the Attestation Report, the SBoM (such as ) can contain expected values for the Attestation Report. In addition, the expected information for hardware properties can be contained in another manifest, such as .
NOTE: Remote attestation terminology is fluid on this topic. A "Verifier" can be any system that appraises Evidence in remote attestation. It is expected that "appraisal" will be spread across at least two systems to maintain confidentiality and separation of responsibility: 1) a Verifier that ensures that the attestation Evidence is produced by genuine hardware, not tampered with, and not signed by revoked keys and 2) a monitoring system taking on the role of Verifier and Relying Party that appraises whether a device has the correct software versions and initiates remediation if not.
Threat: Spurious Network Capabilites
Devices may have additional, unneeded capabilites that are detrimental to network security. While the best option is to disable this functionality in software, this is not always practical
THREAT.NET.SPURIOUS.FUNCTIONS
Devices may contain intentional or accidental capabilities to make networks vulnerable or launch attacks on other networks. These capabilities are extremely costly to discover by inspection or audit.
Requirement: Devices (or their supply chains) must advertise their network access requirements and networks must enforce that devices adhere to their stated network access requirements.
REQ.SEC.NET.ACL
To ensure that network infrastructure is configured discern the difference between authentic traffic and anomalous traffic, network infrastructure can implement fine-grained access control over how a device can use a network
THREAT.NET.BAD.ACL
If a service hosting network access requirements documents is compromised, it can be used to enable malicious devices to mount attacks.
REQ.SEC.NET.ACL.SIGNATURE
Network access ACL documents should be signed. Best practice is to use offline keys for signing.
THREAT.NET.WRONG.ACL
If devices are permitted to self-report ACLs without authentication by a trusted party, they can report any ACL recognised by the network. A device can mis-advertise its network access requirements, pretending to be a different, but recognised and more privileged device (potentially cloning MAC addresses, keys, etc.)
REQ.SEC.NET.ACL.TRUST
Network Access Requirements documents must be secured against tampering and misreporting
RISK.NET.ACL.CONFLATION
Network Access Requirements documents embedded in or referenced from device certificates conflate two capabilities for network operators: network access requirement authorship (potentially delegated) and network access requirement audit. While network operators should audit network access requirements, authoring those requirements should be done by the authors of the device behavior.
Failure to separate these capabilities has the potential to lead to failed device behaviour due to wrong Network Access Requirements descriptions, leading to disabling of the network ACL system in the name of expediency.
REQ.SEC.NET.ACL.SEPARATION
Requirement: If Network Access Requirements are embedded in or referenced by device certificates, the responsibility for network access requirement authorship should be delegated to the device application authors. Alternatively, this can be done explicitly by tying device application authorship to device network access requirements authorship.
Technologies to Mitigate Spurious Network Capabilities
THREAT.NET.SPURIOUS.FUNCTIONS can be mitigated by use of Manufacturer Usage Descriptions (MUDs) and a MUD Controller which accepts MUD files in order to automatically program rules into the network infrastructure.
THREAT.NET.BAD.ACL To prevent a threat actor from distributing their own MUD files via a MUD server, these can be signed, preferably with an offline key as described in .
THREAT.NET.WRONG.ACL can be mitigated by using 802.1X, or SUIT to contain a MUD file or MUD file reference and integrity check. Alternatively, the device's RATS attestation results can be compared to a known list of device profiles and a MUD can be applied as a result without intervention from the remote device.
REQ.SEC.NET.ACL.SEPARATION can be mitigated either through key delegation or through the use of SUIT encapsulation of the MUD file. A third option is to use a third-party ACL provider, such as iotopia.
Risk: DoS of ACL server
RISK.NET.ACL.UPDATE
Recently updated devices may incur latency penalties when a new network access requirements reference must be resolved and verified.
THREAT.NET.ACL.DOS
A threat actor may block access to a distributor of network access requirements documents, thus disabling all devices referencing the network access requirements documents it hosts, without any network intrusion necessary against target networks.
REQ.SEC.NET.ACL.LOCAL
Network access requirements documents should be distributed in advance of use by any device because they constitute a non-local software dependency
Technologies to Implement REQ.SEC.NET.ACL.LOCAL
In order for network infrastructure to be configured in advance of any changes to devices, MUD files can be transported (directly or by secure reference) within update manifests.
This allows local infrastructure to delay installation of a firmware update until a new MUD file can be fetched and audited.
Threat: Delays in ACL Remediation
If an ACL is wrong, network operators need it to be fixed quickly.
THREAT.NET.ACL.BROAD
A network access requirements document grants permissions to a device that are too broad, but the provider of firmware updates is slow to respond, meaning that MUD file delivery in SUIT will take too long.
REQ.SEC.NET.ACL.DYNAMIC
It must be possible to distribute reduced permissions to network access controllers to mitigate a wrong ACL. To enable rapid response to evolving threats, the MUD controller SHOULD also support dynamic update of MUD files.
Technologies that implement REQ.SEC.NET.ACL.DYNAMIC
If a MUD file is delivered by SUIT rather than via a remote server, then a secondary delivery channel can be used. This can include manually overriding the ACL in the network infrastructure. It can also include using SUIT to deliver the key that is used to verify signed MUD files from a specific URL, however in this scenario, THREAT.NET.ACL.DOS remains unmitigated.
Threat: Vulnerable Devices
If a vulnerable device is connected to the network, it could be a risk to the whole network.
THREAT.NET.VULNERABLE.DEVICE
Old firmware with known vulnerability allows exploit until it is updated.
REQ.SEC.NET.DMZ
Network infrastructure can apply risk management policy to devices that attest non-compliant configuration. For example, a device with out-of-date firmware may only be permitted to access the update system.
Technologies to Implement REQ.SEC.NET.DMZ
Using MUD and RATS, a network operator can force a device onto a DMZ network containing only attestation and SUIT update services until it successfully attests a correct firmware version.
Manufacturer Usage Description Specification
This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.
Bootstrapping Remote Secure Key Infrastructure (BRSKI)
This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.
Enrollment over Secure Transport
This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.
FIDO Device Onboarding
LwM2M Core Specification
Software Identification (SWID) Tagging
The Entity Attestation Token (EAT)
Security Theory LLC
Qualcomm Technologies Inc.
Qualcomm Technologies Inc.
An Entity Attestation Token (EAT) provides an attested claims set
that describes state and characteristics of an entity, a device like
a phone, IoT device, network equipment or such. This claims set is
used by a relying party, server or service to determine how much it
wishes to trust the entity.
An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
attestation-oriented claims. To a large degree, all this document
does is extend CWT and JWT.
A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest
Arm Limited
Arm Limited
Fraunhofer SIT
Inria
This specification describes the format of a manifest. A manifest is
a bundle of metadata about code/data obtained by a recipient (chiefly
the firmware for an IoT device), where to find the that code/data,
the devices to which it applies, and cryptographic information
protecting the manifest. Software updates and Trusted Invocation
both tend to use sequences of common operations, so the manifest
encodes those sequences of operations, rather than declaring the
metadata.
Concise Software Identification Tags
Fraunhofer SIT
National Security Agency
The MITRE Corporation
National Institute of Standards and Technology
ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an
extensible XML-based structure to identify and describe individual
software components, patches, and installation bundles. SWID tag
representations can be too large for devices with network and storage
constraints. This document defines a concise representation of SWID
tags: Concise SWID (CoSWID) tags. CoSWID supports a similar set of
semantics and features as SWID tags, as well as new semantics that
allow CoSWIDs to describe additional types of information, all in a
more memory efficient format.
Concise Reference Integrity Manifest
Fraunhofer SIT
arm
arm
Intel
Huawei Technologies
Remote Attestation Procedures (RATS) enable Relying Parties to assess
the trustworthiness of a remote Attester and therefore to decide
whether to engage in secure interactions with it. Evidence about
trustworthiness can be rather complex and it is deemed unrealistic
that every Relying Party is capable of the appraisal of Evidence.
Therefore that burden is typically offloaded to a Verifier. In order
to conduct Evidence appraisal, a Verifier requires not only fresh
Evidence from an Attester, but also trusted Endorsements and
Reference Values from Endorsers and Reference Value Providers, such
as manufacturers, distributors, or device owners. This document
specifies Concise Reference Integrity Manifests (CoRIM) that
represent Endorsements and Reference Values in CBOR format.
Composite devices or systems are represented by a collection of
Concise Module Identifiers (CoMID) and Concise Software Identifiers
(CoSWID) bundled in a CoRIM document.
Trusted Execution Environment Provisioning (TEEP) Architecture
Broadcom
Arm Limited
Microsoft
Amazon
A Trusted Execution Environment (TEE) is an environment that enforces
that any code within that environment cannot be tampered with, and
that any data used by such code cannot be read or tampered with by
any code outside that environment. This architecture document
motivates the design and standardization of a protocol for managing
the lifecycle of trusted applications running inside such a TEE.
Remote Attestation Procedures Architecture
Fraunhofer SIT
Microsoft
Sandelman Software Works
Intel Corporation
Huawei Technologies
In network protocol exchanges it is often useful for one end of a
communication to know whether the other end is in an intended
operating state. This document provides an architectural overview of
the entities involved that make such tests possible through the
process of generating, conveying, and evaluating evidentiary claims.
An attempt is made to provide for a model that is neutral toward
processor architectures, the content of claims, and protocols.
Global Platform Iotopia