Chapter 8: OTA and Trust List Bootstrap

8.1 Introduction — Why OTA Is the Last Line of Defense

An embedded device that ships with TLS Lite typically operates in the field for years, sometimes decades. Home boiler controllers, IoT nodes inside street lamps, PLCs on factory floors, automotive ECUs, hospital patient monitors, agricultural soil sensors — they take many shapes but share one trait: human hands rarely reach them, and when they do the cost is high. Vulnerabilities discovered after shipment can only be remediated through Over-The-Air (OTA) firmware updates. If OTA is not secure, the device's security is frozen at the moment of manufacture and decays under accumulating undisclosed vulnerabilities thereafter.

This chapter elaborates the OTA architecture and Trust List bootstrap procedure recommended by the TLS Lite standard. Two normative references anchor the model. First, IETF RFC 9019 (Software Updates for IoT, SUIT) is adopted as the primary architecture reference. SUIT was designed for constrained nodes from the ground up, and its use of COSE signatures, CBOR encoding, and CWT claims composes naturally with the envelope layer described in Chapter 4 of this book. Second, the multi-key threat model of The Update Framework (TUF, Samuel et al. 2010, ACM CCS) is borrowed to prevent single-key-compromise scenarios in which one stolen signing key disables the entire fleet. The combination produces a multi-key OTA model that remains executable on resource-constrained microcontrollers.

OTA cannot be reduced to a simple "download and flash" procedure because the threat model is rich. Man-in-the-middle attackers can tamper with firmware in transit. Downgrade attackers can force-install older firmware containing known vulnerabilities. Replay attackers can re-inject a legitimate update packet at a later time. Mass-deployment-compromise attackers — those who steal one signing key — can push backdoored firmware to millions of devices at once. The 2018 ASUS Live Update incident is a real example: a legitimate code-signing infrastructure was compromised and a backdoor was distributed to over 500,000 PCs while every signature remained mathematically valid. The IoT space patches less frequently than PCs and has far more devices in the field, so the blast radius of a single compromise is correspondingly larger.

The model proposed in this chapter defends across six axes. (1) Multi-signer threshold signing eliminates the single point of failure inherent to a single signing key. (2) Four-way metadata separation — root, targets, snapshot, timestamp — allows safe key rotation. (3) Monotonic counters block downgrade and replay. (4) A/B partition booting guarantees automatic rollback on update failure. (5) Integrity verification is split into two stages: SHA-256 over the payload and Ed25519 over the manifest. (6) Trust List bootstrap embeds a single root key at the factory, and every subsequent delegated key is verified through that root chain. These six axes synthesize RFC 9019, RFC 9124, RFC 9491, the TUF academic paper, and NIST SP 800-193.

8.2 Threat Model — Lessons From the Multi-Key Analysis in TUF

The Update Framework (TUF) is an academic framework published by Samuel, Mathewson, and Cappos at ACM CCS in 2010. It systematically classifies seven core threats observed in software-distribution systems. This standard borrows that classification and reshapes it for embedded OTA. TUF was originally designed against PC and server package managers, but its threat catalogue applies wholesale to embedded OTA.

Of the seven TUF threats, the present chapter treats the following five as primary. (1) Arbitrary Package Attack — the device accepts unsigned arbitrary firmware. (2) Malicious Metadata — the signature is valid but the referenced payload digest has been tampered. (3) Replay Attack — an old legitimate signature is re-injected at a later time. (4) Lack of Key Revocation — a compromised key retains authority indefinitely. (5) Slow Retrieval Attack — the device fails to verify freshness of metadata and remains stuck in an outdated state. The standard mandates specific countermeasures for each of these five.

The single greatest weakness of the naive code-signing model is the concentration of trust in one signing key. A single compromise of that key — a stolen developer laptop, a CI/CD breach, an HSM operator's error — instantly converts every signed firmware into "valid." The 2017 CCleaner incident, the 2018 ASUS Live Update incident, and the 2020 SolarWinds incident are real-world cases that exposed the limits of single-key signing. TUF resolves this limitation with threshold signing and rotation, and this standard adopts that resolution in an IoT-friendly form.

The threat catalogue maps one-to-one onto the STRIDE framework — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Spoofing manifests as forged manifests, Tampering as payload alteration, Repudiation as signer-identity denial, Information Disclosure as plaintext firmware exposure, Denial of Service as intentional bricking, and Elevation of Privilege as bootloader takeover. The six-axis response in this standard covers all six STRIDE entries.

8.3 RFC 9019 — SUIT Architecture Overview

IETF RFC 9019 (April 2021) is the architecture standard for IoT software updates. The SUIT working group authored it over four years, and it forms the upper layer above RFC 9124 (SUIT Information Model) and RFC 9491 (SUIT Manifest Serialization). RFC 9019 abstracts what information must be carried in a manifest; RFC 9124 defines the semantic meaning of that information; and RFC 9491 specifies its concrete CBOR serialization.

The core idea of the SUIT architecture is the separation of manifest and payload. The manifest is a CBOR object carrying update metadata and signed via COSE_Sign1. The payload is the actual firmware binary, and the manifest carries its SHA-256 digest as a claim. With this separation, the payload itself does not need to be signed — signing only the manifest still guarantees the integrity of the payload. The payload is typically tens to hundreds of kilobytes, while the manifest is one or two kilobytes, so the cost of signature verification on constrained devices is decisively reduced.

The CBOR serialization of the SUIT manifest defined in RFC 9491 is intentionally very compact. Compared to JSON, XML, or ASN.1, the same information is represented in three to five times fewer bytes. Because this standard's envelope layer (Chapter 4) adopted CBOR Web Token (RFC 8392), which shares the same CBOR serialization rules (RFC 8949), the OTA payload verifier and the general authentication-envelope verifier can reuse the same CBOR parser. This reuse is decisive in code-size footprint terms. Embedded ROM is typically constrained to 64 KB–512 KB; one shared CBOR/COSE parser ends up around 8–16 KB.

; RFC 9491 SUIT Manifest CBOR pseudocode (abbreviated)
SUIT_Manifest = {
  ? suit-manifest-version          => uint,
  ? suit-manifest-sequence-number  => uint,
  ? suit-common                    => SUIT_Common,
  ? suit-reference-uri             => tstr,
  ? suit-manifest-component-id     => SUIT_Component_Identifier,
  ? suit-validate                  => SUIT_Command_Sequence,
  ? suit-load                      => SUIT_Command_Sequence,
  ? suit-install                   => SUIT_Command_Sequence,
  ? suit-run                       => SUIT_Command_Sequence,
  ? suit-text                      => SUIT_Text_Map,
}

SUIT_Common = {
  ? suit-components               => [ + SUIT_Component_Identifier ],
  ? suit-shared-sequence          => SUIT_Command_Sequence,
}

; Payload digest claim (SHA-256, 32 bytes)
suit-parameter-image-digest = h'a3b1...32f0'  ; bstr 32

; COSE_Sign1 outer envelope
COSE_Sign1 = [
  protected:   bstr .cbor { 1: -8 },  ; alg = EdDSA (-8)
  unprotected: { },
  payload:     bstr .cbor SUIT_Manifest,
  signature:   bstr .size 64,         ; Ed25519 signature 64 bytes
]

The key point of the CBOR pseudocode above is that the payload itself does not enter the manifest. The manifest carries only the SHA-256 digest of the payload. The payload is downloaded over a separate transport channel — HTTPS, CoAPs, BLE, LoRaWAN, NB-IoT — and the device, after downloading, recomputes SHA-256 and compares against the digest in the manifest. Because of this separation the manifest stays at 1–2 KB, and Ed25519 verification of COSE_Sign1 completes in under 100 ms on a 32-bit microcontroller.

The command-sequence concept in SUIT manifests is an imperative procedural model. Each phase — suit-validate, suit-install, suit-run — runs a sequence of commands (set-parameter, condition, directive) in order, and any failed condition aborts the whole procedure. This imperative model lets firmware distributors embed policies of the form "to accept this firmware, the device must satisfy these conditions" directly into the manifest — vendor ID must be X, class ID must be Y, current sequence number must be at least Z.

8.4 Trust List Bootstrap — One Root Key at Factory

Trust List bootstrap is the starting point of OTA security. The trust anchor burned into a device's firmware ROM at manufacture determines the device's lifetime security posture. To balance simplicity and resilience, this standard recommends the following model: at factory provisioning, embed exactly one root public key in ROM. Every other key that subsequently appears — delegated keys, rotated keys, ephemeral signing keys — is verified through that root key chain. The advantages are (a) minimum ROM footprint, (b) simplest factory procedure, and (c) clear recovery path under key compromise.

A single root key, however, is itself a single point of failure. If the root key itself is compromised, the entire fleet is disabled. To mitigate, this standard recommends two additional mechanisms. First, the root key MUST be operated under a threshold-signing model, so that no single individual can sign with it alone. A 5-of-7 threshold model, for example, distributes key shares among seven executives and engineers; five must convene to produce a root signature. Second, the root rotation procedure is standardized. A new root key, signed by the old root key in a new root.json metadata, allows devices to validate the new anchor with the old anchor and rotate their own anchor.

The core of this four-way separation is that each metadata's signing key is segregated. root.json lives on an offline HSM and is used only with threshold signing. Its usage frequency is once or twice per year. By contrast, timestamp.json refreshes hourly, so its key lives on an online auto-signing server. Even if the timestamp key is compromised, the attacker can only forge freshness proofs; the attacker cannot actually tamper with firmware. Tampering requires compromising the targets key, which is used only once or twice per quarter and thus offers fewer windows of attack. If that too is compromised, root rotation is issued.

An OTA operations lead recalled, over 25 years in the home-appliance industry, that the company's first embedded-security incident was a stolen single signing key. A developer's laptop was lost, and that laptop contained the firmware-signing private key in plaintext. After the incident, the company issued a recall notice to every device, but only 12 percent of the field fleet complied; the remaining 88 percent stayed in a state where firmware signed by the compromised key would still be accepted. That incident was the direct trigger for the company's adoption of a TUF/SUIT-style model. The four-way metadata separation in this standard enables a single root rotation to recover trust across the entire fleet in such scenarios.

A second key decision in trust-list bootstrap is delegation depth. The root key can delegate the targets key directly, but a more common model places an intermediate delegated key between root and targets. The structure mirrors X.509 certificate chains. Given the memory constraints of embedded environments, this standard recommends a maximum delegation depth of three (root → intermediate → targets). Depths greater than three accumulate signature-verification work and lengthen OTA download time. Ed25519 verification on a 32-bit microcontroller takes about 80–120 ms per signature, so a three-level chain completes in roughly 240–360 ms — imperceptible to users.

8.5 Key Rotation — Automated Recovery After Compromise

Key rotation is the mechanism that most decisively determines OTA's resilience. The shorter the Mean Time To Recovery (MTTR) after compromise, the smaller the blast radius. This standard classifies key rotation into four severity tiers, mapping compromise severity to recovery procedure. Tier 1 covers timestamp-key compromise (low impact, automatic rotation). Tier 2 covers snapshot-key compromise (moderate impact, semi-automatic rotation). Tier 3 covers targets-key compromise (high impact, manual rotation). Tier 4 covers root-key compromise (catastrophic, threshold-signing recovery).

Key rotation can be automated because the root key delegates all three other keys. When timestamp, snapshot, or targets keys are reissued, the new public key is signed by the root key into a new root.json. Devices verify the new root.json on the next OTA poll and update their own trust list. After the update, metadata signed by the old key is automatically rejected. This standard recommends a 24-hour grace period for old-key rejection — shorter periods can briefly desynchronize devices across time zones, while longer periods extend the lifetime of the compromised key.

Key rotation must be accompanied by a key-usage log. This standard recommends that every signing event be recorded in an audit log carrying (a) signing timestamp (RFC 3339 UTC), (b) operator identifier, (c) SHA-256 digest of the signed object, (d) signing-key fingerprint, and (e) for threshold signatures, the roster of consenting signers. The log reuses the audit-transport standard described in Chapter 6 of this book; the W3C Trace Context traceparent ID maintains correlation across every stage of the OTA build pipeline.

Threshold signing is mandated by this standard only for the root key. Recommended concrete algorithms include FROST (Flexible Round-Optimized Schnorr Threshold signatures, in progress at IRTF CFRG) or Shamir-Secret-Sharing-based Ed25519 splitting. A 5-of-7 threshold model offers (a) availability — five of the seven can sign even if not all are present — and (b) resistance to insider attack: no single individual nor a cabal of four or fewer can produce a signature. Quarterly drills of the threshold procedure are recommended; procedures used only once a year are difficult to execute under real incident conditions.

8.6 A/B Partition Boot and Anti-Bricking

The boot step at the end of the update procedure plays a decisive role in OTA resilience. After downloading and verifying new firmware and writing it to the active partition, what happens if the new firmware enters a boot loop or fails to boot at all? This standard adopts an A/B partition model. The device's firmware storage is split into two equal-sized partitions, A and B, with exactly one active at any time. New firmware is written to the inactive partition, and after verification the bootloader switches the active partition.

If the new firmware boots successfully, the bootloader marks that partition as "healthy." After successful boot and a stable operating window (typically five to ten minutes), a watchdog mechanism confirms the healthy mark. If the watchdog signal lapses during that window, the bootloader automatically rolls back to the previous partition on next boot. This automatic rollback ensures the device is never permanently bricked, even when OTA fails.

The downside of the A/B model is that firmware storage must be doubled. Devices with 256 KB ROM holding a 64 KB firmware cannot accommodate both partitions. This standard accepts a "simple model" for such constrained devices. The simple model holds a single partition and automatically reverts to the factory firmware on OTA failure. Recovery time is longer and the user must reconfigure the device, but memory cost is halved. This standard recommends the A/B model for devices with ROM of 256 KB or more, and the simple model below that threshold.

The integrity of the bootloader itself is guaranteed by the RoT (Root of Trust) concept recommended in NIST SP 800-193 (Platform Firmware Resiliency Guidelines, May 2018). RoT is the primary boot code burned into immutable ROM, which measures and verifies every subsequent boot stage. NIST SP 800-193 recommends RoT to satisfy three properties: (a) immutable, (b) measurable, (c) recoverable. ARM PSA Firmware Update (2022) and IEEE 802.1AR-2018 (Secure Device Identity, DevID) apply the same principle to microcontrollers and network devices, respectively.

8.7 Downgrade Prevention — Monotonic Counter

A downgrade attack is one in which an attacker forces a device to install an older firmware containing known vulnerabilities. The old firmware carries a legitimate signature, so simple signature verification cannot stop it. This standard mandates a monotonic-counter mechanism to block this attack. Every manifest carries a suit-manifest-sequence-number field whose value strictly increases. The device persists in NVM (Non-Volatile Memory) the sequence number of the last installed manifest, and rejects any new manifest whose sequence number is less than or equal to that value.

The implementation of a monotonic counter looks straightforward but contains subtle traps. First, the sequence number stored in NVM must not be tamperable. This standard recommends that the value be stored in secure NVM, or in RPMB (Replay Protected Memory Block, available in eMMC 5.0 and later). Second, the sequence number itself must be inside the manifest's signature — otherwise an attacker could fabricate a variant in which only the sequence number is altered. The SUIT manifest places the sequence number inside the manifest body, so the COSE_Sign1 signature protects it automatically.

The semantics of the sequence number differ from the firmware version (e.g., 1.2.3). The sequence number is a freely chosen uint indicating manifest publication order. This standard recommends using either a Unix-timestamp form per RFC 3339 UTC, or a YYYYMMDDHHMM form (e.g., 202605141430). Either form lets the sequence number be human-readable and immediately discloses the relative order of two manifests. For very high publication frequencies (more than once per hour), Unix nanoseconds or microseconds may be substituted.

A replay attack resembles a downgrade attack but differs in nuance. Replay re-injects a legitimate manifest of the same sequence number at a later time. The strict greater-than comparison of the monotonic counter rejects the same number as well, so replay is also blocked. The first legitimate installation of a manifest cannot be prevented, however, so the practical window for replay is narrow — only the scenario in which a manifest is published in a compromised state on first issuance is a real replay threat, and that is recovered by the next manifest's publication and rotation.

8.8 OMA LwM2M Firmware Update — Object 5

OMA's LwM2M (Lightweight Machine to Machine) v1.2 (2022) is the constrained-device-management standard recommended by this standard as the OTA transport layer to pair with SUIT. LwM2M runs over CoAP (RFC 7252) and abstracts device state through its Object Model. Among those objects, Object 5 (Firmware Update) expresses the OTA procedure in LwM2M's vocabulary. This standard recommends delivering SUIT manifests via the Package resource of Object 5.

The State resource (/5/0/3) of Object 5 expresses the OTA state machine. 0 (Idle) is the normal state when no update is in progress. 1 (Downloading) is while the payload is being received. 2 (Downloaded) is after the payload has been fully received and verification is starting. 3 (Updating) is after verification has passed and the payload is being written to the inactive partition or awaiting boot switch. This standard recommends expressing each transition condition between these states through SUIT manifest command sequences.

The Update Result resource (/5/0/5) expresses the OTA outcome as a single uint: 0 (Initial), 1 (Success), 2 (Not enough flash), 3 (Out of RAM), 4 (Connection lost), 5 (Integrity check failure), 6 (Unsupported package type), 7 (Invalid URI), 8 (Firmware update failed), 9 (Unsupported protocol). This standard recommends using 5 (Integrity check failure) for SUIT manifest signature mismatch or SHA-256 digest mismatch, and 8 (Firmware update failed) when the post-install boot fails — implying that A/B automatic rollback occurred.

A smart-home integration manager recommended, on the basis of five years of LwM2M Object 5 operations, that monitoring State transitions yields per-stage rollout statistics. A drop in 1→2 transition rate below 80 percent signals payload-channel instability. A drop in 2→3 below 95 percent signals an elevated rate of integrity rejection, suggesting that the manifest-signing infrastructure should be audited. A drop in 3→1 (Success) below 90 percent signals stability problems with the new firmware itself, and rollback to canary-rollout stages is in order.

8.9 This Standard's ENUMs and Boot-Verification Pseudocode

The OTA verification procedure of this standard must align with this standard's baseline cipher suites. The ENUM set recommended in simulator panel 2 is as follows.

• TLS_AES_128_GCM_SHA256 — baseline cipher suite for OTA metadata channels (CoAPs over DTLS 1.3).
• TLS_AES_256_GCM_SHA384 — strong cipher suite for payload channels of high-value firmware.
• TLS_CHACHA20_POLY1305_SHA256 — fallback cipher suite for 8-bit and 16-bit MCUs lacking AES acceleration.
• X25519 — default elliptic curve for DTLS 1.3 handshake key exchange.
• ed25519 — default signature algorithm for SUIT manifest COSE_Sign1 (COSE alg = -8).

// Boot-time SUIT manifest verification pseudocode (C-like)
typedef enum {
    BOOT_OK = 0,
    BOOT_ROOT_INVALID,
    BOOT_MANIFEST_SIG_FAIL,
    BOOT_PAYLOAD_HASH_FAIL,
    BOOT_DOWNGRADE_BLOCKED,
    BOOT_VENDOR_ID_MISMATCH,
    BOOT_FALLBACK_TRIGGERED
} boot_result_t;

boot_result_t verify_and_boot(const uint8_t *manifest, size_t mlen,
                              const uint8_t *payload, size_t plen) {
    /* Step 1: verify manifest signature with root anchor (Ed25519) */
    if (!cose_sign1_verify(manifest, mlen, &root_pubkey)) {
        return BOOT_MANIFEST_SIG_FAIL;
    }
    /* Step 2: monotonic counter check (last sequence in NVM) */
    uint32_t seq = suit_get_sequence_number(manifest);
    uint32_t prev = nvm_read_last_sequence();
    if (seq <= prev) {
        return BOOT_DOWNGRADE_BLOCKED;
    }
    /* Step 3: vendor and class ID matching */
    if (!suit_match_vendor_class(manifest, MY_VENDOR_ID, MY_CLASS_ID)) {
        return BOOT_VENDOR_ID_MISMATCH;
    }
    /* Step 4: recompute payload SHA-256 and compare */
    uint8_t computed[32], expected[32];
    sha256(payload, plen, computed);
    suit_get_image_digest(manifest, expected);
    if (memcmp(computed, expected, 32) != 0) {
        return BOOT_PAYLOAD_HASH_FAIL;
    }
    /* Step 5: write payload to inactive partition + switch boot flag */
    flash_write_inactive_partition(payload, plen);
    nvm_write_last_sequence(seq);
    bootloader_set_next_active(get_inactive_partition_id());
    /* Step 6: arm watchdog + reboot — auto-revert if no OK in 5 min */
    watchdog_register_rollback_timer(WATCHDOG_5_MINUTES);
    system_reboot();
    return BOOT_OK;  /* unreachable */
}

The alignment of the pseudocode above is as follows. (a) The root-key verification in step 1 aligns with the four-way metadata model in this chapter. In practice the full chain root.json → snapshot.json → timestamp.json → targets.json is verified before the manifest signature, but the pseudocode collapses this into root_pubkey for brevity. (b) The monotonic counter in step 2 aligns with the downgrade blocking in §8.7. (c) The SHA-256 check in step 4 aligns with the image-digest claim in RFC 9019. (d) The A/B switch in step 5 and the watchdog in step 6 align with the anti-bricking model in §8.6.

The boot_result_t ENUM in the pseudocode maps onto the Update Result resource of LwM2M Object 5. BOOT_MANIFEST_SIG_FAIL and BOOT_PAYLOAD_HASH_FAIL map to LwM2M 5 (Integrity check failure); BOOT_DOWNGRADE_BLOCKED and BOOT_VENDOR_ID_MISMATCH map to LwM2M 8 (Firmware update failed); BOOT_FALLBACK_TRIGGERED is expressed via a vendor-defined code (10 or above). This mapping enables cross-standard composition: an operator managing devices through LwM2M can read statistics without knowing the internals of SUIT manifests.

8.10 CWT-Based Manifests — Composition With Chapter 4

The CBOR Web Token (CWT, RFC 8392) envelope defined in Chapter 4 of this book is a container for authentication tokens. The SUIT manifest is also a CBOR object, signed by COSE_Sign1. Both share CBOR (RFC 8949) and COSE signing rules (RFC 9052), so the SUIT verifier and the CWT verifier on a device can reuse the same parser and verification library. This standard actively recommends that reuse. Code size on embedded devices is the first enemy of security; carrying two copies of the same algorithm enlarges the attack surface.

CWT and SUIT differ in meaning. CWT claims carry authentication information — subject, issuer, expiration. SUIT claims carry update information — payload digest, sequence number, command sequence. But both enter the same COSE_Sign1 structure and are processed by the same Ed25519 or ECDSA P-256 verification code. This standard mandates at least Ed25519 on every embedded device; ECDSA P-256 is optional.

The composition between this standard's envelope layer and SUIT manifests is clearest at trust bootstrap. The single root public key burned at factory verifies SUIT root.json, and the targets keys delegated by root.json verify SUIT manifests. Simultaneously, the same root public key verifies the signer of the ID token carried inside the CWT envelopes defined in Chapter 4. OTA and authentication therefore share exactly one root trust anchor. This sharing simplifies the trust model and keeps OTA and authentication consistent through key rotation.

RFC 9023 (TEEP, Trusted Execution Environment Provisioning, January 2024) is the provisioning protocol for running SUIT inside a Trusted Execution Environment. On devices with a TEE — ARM TrustZone, Intel SGX, RISC-V Keystone — SUIT manifest verification and payload installation occur inside the TEE. This standard strongly recommends TEEP on TEE-capable devices, because a TEE also guarantees the integrity of the bootloader itself, naturally satisfying the RoT requirements of NIST SP 800-193.

8.11 Operational Practice and Canary Rollouts

Even with a standard-compliant OTA, canary rollouts are essential in real operations. A canary rollout pushes new firmware to only 1–5 percent of the fleet first, observes stability metrics for a window (typically 24–72 hours), then scales up in stages to 100 percent. This standard recommends using LwM2M Object 5 State-resource statistics as the primary signal of the canary gate.

The standard staging is: stage 1 at 1 percent (24-hour observation) → stage 2 at 5 percent (24 hours) → stage 3 at 25 percent (24 hours) → stage 4 at 50 percent (24 hours) → stage 5 at 100 percent. If boot-failure rate, download-failure rate, or integrity-rejection rate at any stage exceeds threshold, the rollout halts automatically, and the operator investigates the cause manually before resumption. This standard recommends a boot-failure threshold of one percent — a healthy new firmware should boot successfully on first try for at least 99 percent of devices.

An OTA operations lead compared the pre- and post-canary incident rates. Before adoption, the fleet saw an average of 1.5 large firmware incidents per quarter, with each incident affecting an average of 500,000 devices. After adoption, the rate fell to 0.2 per quarter, with average impact reduced to 20,000 devices — one one-hundredth of the prior scale. Incidents discovered at canary stage 1 were arrested before stage 5 reached the full fleet. Canary rollout is not part of the SUIT specification itself, but this standard recommends it as an indispensable operational procedure.

A further benefit of canary rollout is temporal load distribution. A simultaneous 100-percent rollout causes every device to reboot at once, triggering a stampede of telemetry, authentication, OCSP, and OTA polling. Canary spreads that load over time. This standard recommends canary as SHOULD for operators of fleets above one million devices and as MUST for fleets above ten million.

Note on Korean Edition — Korean OTA, SUIT, and IoT Bootstrap Infrastructure

The Korean edition of this chapter (chapter-08.html under ebook/ko/) elaborates the alignment of this standard with Korean IoT-security policy and infrastructure. KISA (Korea Internet & Security Agency) issued the original "IoT Security Guide" in 2016 and subsequent revisions in 2020 and 2023, which already recommended OTA integrity verification and downgrade prevention before SUIT was standardized at IETF. KISA also operates KCMVP (Korea Cryptographic Module Validation Program); the algorithms recommended by this standard — Ed25519, SHA-256, AES-128/256-GCM — are all KCMVP-listed. ETRI (Electronics and Telecommunications Research Institute) is the lead Korean participant in OneM2M global standardization; its 2022 report introduced four-way metadata separation and threshold signing to Korean industry. TTA (Telecommunications Technology Association) operates the "IoT Security Test Certification" criteria (TTAS.KO-12.0345/R1, 2023) which mandates OTA integrity and anti-rollback for home appliances, automotive, and medical IoT. NIA (National Information Society Agency) issues policy recommendations on OTA for public-sector IoT (smart city, digital twin). NIPA (National IT Industry Promotion Agency) operates the K-IoT Security Certification, whose grade-3 (advanced) requirements correspond to this standard's six-axis model. The Korean Institute of Information Security and Cryptology (KIISC) hosts the annual IoT Security Workshop. KS X ISO/IEC 30141 (2018) is the Korean national-standard adoption of the IoT Reference Architecture. The Korean Information and Communications Network Act imposes notification obligations on operators after security incidents and increases operator liability when an applicable OTA patch was available but not applied. Samsung SmartThings, LG ThinQ, Hyundai automotive OTA (introduced on the Genesis G80 in 2020), SK Telecom ifLand, KT GiGA Genie, and LG U+ smart home all operate OTA infrastructures broadly aligned with the six-axis model in this chapter. The Korean edition develops these mappings in detail.

8.12 Conclusion and Next Steps

This chapter has organized the OTA and Trust List bootstrap model of TLS Lite into six axes. (1) Adoption of the RFC 9019/9124/9491 SUIT architecture. (2) Multi-key threat analysis based on the TUF academic model. (3) Four-way metadata separation (root, targets, snapshot, timestamp) with threshold signing. (4) Downgrade and replay prevention via monotonic counters. (5) A/B partition boot with watchdog-based anti-bricking. (6) Composition between LwM2M Object 5 and this standard's envelope layer. These six axes synthesize NIST SP 800-193, ARM PSA Firmware Update, IEEE 802.1AR DevID, and ISO/IEC 30141.

As next steps, operators are advised to verify the following. (a) Does the factory-burn procedure of the root public key operate under threshold signing? (b) Is the key-rotation procedure documented for each of the four tiers? (c) Is the device's ROM capacity sufficient for an A/B partition model (otherwise the simple model with factory firmware fallback)? (d) Are LwM2M Object 5 State-resource statistics being used as the canary-gate signal? (e) For Korean operators, has alignment with KCMVP, TTAS.KO-12.0345, and KS X ISO/IEC 30141 been audited?

The SUIT manifest pseudocode and the boot-verification pseudocode in this chapter are provided as actual C code in the reference implementation in this book's GitHub repository. The implementation is validated on three platforms — ARM Cortex-M4 (STM32L4), ESP32, and RISC-V GD32. Ed25519 verification uses ed25519-donna, SHA-256 uses mbedTLS, and CBOR/COSE uses NanoCBOR/CoseLib. Total code size including bootloader is approximately 28 KB, and average verification time on ARM Cortex-M4 at 80 MHz is about 340 ms (110 ms for manifest verification plus 230 ms for SHA-256 on a 64 KB payload).