Chapter 5: Constrained Device Crypto

5.1 Design principles for constrained-device cryptography

A constrained device, in the sense of IETF RFC 7228, is a computing unit whose RAM, flash, energy budget, CPU cycles, or wireless bandwidth is at least two orders of magnitude smaller than that of a typical server. RFC 7228 §3 fixes a quantitative classification: Class 0 (less than 10 KiB RAM, less than 100 KiB flash), Class 1 (10 to 50 KiB RAM, 100 to 250 KiB flash), and Class 2 (more than 50 KiB RAM, more than 250 KiB flash). The whole chapter uses this classification consistently across every table, budget, and trade-off discussion that follows. Class 0 is usually a 16-bit microcontroller such as the MSP430 family or AVR ATmega, or an ARM Cortex-M0. Class 1 maps to Cortex-M0+ and Cortex-M3 parts. Class 2 covers Cortex-M4 and Cortex-M7 grade silicon.

Constrained-device cryptography must simultaneously satisfy five constraints. The first is small code size: a fully unrolled AES round function with a pre-computed GHASH multiplication table is fast but consumes between 6 and 10 KiB of flash, which is impossible to fit on Class 0. The second is small RAM working set: holding two concurrent handshake states with X25519 already costs 2.5 KiB of stack, half of the Class 0 budget. The third is small worst-case latency: AES-128-GCM processes a 16-byte block in about 320 cycles on Cortex-M4, while ChaCha20-Poly1305 needs about 220 cycles on the same chip, and both functions are constant-time within a 30-cycle band. The fourth is small energy consumption: a LoRaWAN node may have to live on a 1 mAh battery budget for six months. The fifth is side-channel robustness: Cortex-M0 has no branch predictor, but accelerator IP blocks can leak through cache timing.

TLS Lite stitches the five constraints together explicitly inside the standard. The cipher_suite field of the Phase 1 envelope is not merely an RFC 8446 code point. It is tracked alongside a matrix that records, for every code point, whether it fits the RFC 7228 Class 0, Class 1, or Class 2 budget. When an operator chooses a cipher_suite from a Phase 1 envelope, the same act selects a five-axis budget line for RAM, flash, cycles, energy, and side-channel posture.

Consider an embedded-firmware engineer who maintains the wireless temperature sensor of a residential boiler. The sensor must run from a single CR2032 coin cell for five years and emits a 4-byte temperature reading every thirty minutes to its gateway. A single wrong cipher_suite choice (say, P-384 instead of X25519) adds roughly 140,000 cycles per ECDH and exhausts the coin cell within one year. The cipher_suite choice is therefore not only a security decision but also a physical battery-life decision.

5.2 Elliptic-curve cryptography — octets and verification cycles per curve

The elliptic curves available to constrained devices are NIST P-256 and P-384 (NIST SP 800-186, IETF RFC 6090) plus the Curve25519/Curve448 family (IETF RFC 7748 and RFC 8032). RFC 8446 TLS 1.3 registers five normative supported_groups extension values: secp256r1, secp384r1, secp521r1, x25519, and x448. Of these, secp256r1 and x25519 are the de-facto constrained-device default pair. Ed25519 and Ed448 (RFC 8032) carry the signature algorithm identifiers 0x0807 and 0x0808 in the TLS 1.3 signature_algorithms extension.

The first axis of curve selection is octet length. P-256 has a 64-byte public key, a 64-byte signature, and a 32-byte private key. X25519 has a 32-byte public key, a 32-byte private key, and a 32-byte shared secret. The average wireless payload of a Class 0 device on LoRaWAN SF12 DR0 to DR2 sits between 51 and 127 bytes per frame; the 32-byte X25519 public key fits inside one frame, whereas the 96-byte P-384 public key forces fragmentation across two frames.

The second axis is verification cycle cost. On Cortex-M0 (Class 0), an X25519 point multiplication needs about 2.8 million cycles, whereas P-256 needs about 9.5 million. On Cortex-M4 (Class 2), the same operations drop to about 0.78 million and 2.5 million cycles respectively. A 16 MHz Cortex-M0 takes about 175 ms for one X25519 operation and about 590 ms for one P-256 operation; the latter risks tripping the watchdog timer on systems that fire it at 500 ms.

The third axis is side-channel robustness. X25519 uses Montgomery-ladder scalar multiplication, and RFC 7748 §5 states normatively that the implementation is constant-time and independent of secret bits. P-256 implementations in Jacobian coordinates can still leak through branch timing, and additional masking is required to achieve comparable side-channel posture. This is one of the strongest reasons constrained devices prefer X25519.

The cycle counts above are medians of GitHub regression benchmarks for mbedTLS 3.5, WolfSSL 5.6, and MIRACL Core 4.0. For the same curve, the figures swing by approximately plus-or-minus 15 percent depending on the compiler (GCC 12 vs Clang 16), optimization level (-O2 vs -Os), and header alignment flags.

The TLS Lite cipher_suite envelope encodes the curve identifier with the RFC 8446 supported_groups normative code point. The same envelope additionally carries a boolean flag that records whether the curve fits the Class 0 budget. When an operator selects cipher_suite=TLS_CHACHA20_POLY1305_SHA256 and group=X25519, the envelope attaches the metadata fits_class_0=true, which the firmware builder consumes to compile that combination only for Class 0 device builds.

5.3 Authenticated encryption — AES-GCM vs ChaCha20-Poly1305

TLS 1.3 (RFC 8446 §B.4) registers five normative authenticated-encryption code points: TLS_AES_128_GCM_SHA256 (0x1301), TLS_AES_256_GCM_SHA384 (0x1302), TLS_CHACHA20_POLY1305_SHA256 (0x1303), TLS_AES_128_CCM_SHA256 (0x1304), and TLS_AES_128_CCM_8_SHA256 (0x1305). Of these, TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are the de-facto IoT defaults, while TLS_AES_128_CCM_8_SHA256 sees independent adoption inside wireless-mesh frameworks (LoRaWAN, Zigbee, Thread) that operate outside the TLS record layer.

AES-128-GCM is fast on Cortex-M3/M4 chips equipped with hardware acceleration (ARM CryptoCell, ST32 Crypto). Such implementations sustain about 1.2 bytes per cycle of throughput, processing a 1.6 KiB payload in about 1.3 ms. The weakness of software-only AES-128-GCM is that GHASH multiplication needs a 256-byte precomputed table, holding 250 bytes of RAM resident for the duration of a session, and the 96-bit nonce is unsafe once it crosses 2^32 messages per key.

ChaCha20-Poly1305 (RFC 8439) is built entirely from add-rotate-xor (ARX) primitives, which makes its software implementation naturally side-channel robust. Throughput is about 0.45 bytes per cycle on Cortex-M0 and about 1.6 bytes per cycle on Cortex-M4. Without AES-NI, ChaCha20-Poly1305 is two to three times faster than AES-GCM, a result normatively reported in RFC 7905 Appendix A. The shared weakness with AES-GCM is the 96-bit nonce; otherwise ChaCha20-Poly1305 has almost no operational gotchas at the constrained-device scale.

AES-128-CCM_8 (8-byte tag) is adopted in wireless-mesh frameworks to save eight bytes per payload. The cost is that an 8-byte authentication tag offers only a 2^-64 forgery bound. NIST SP 800-38C recommends the 8-byte tag exclusively for scenarios in which the average message is short and 2^-32 forgery probability is acceptable. For medical devices, industrial control, aviation, and safety-restorable automotive contexts, the 16-byte tag remains the recommendation.

Across all four axes (RAM, flash, energy, throughput) of the software-only column, ChaCha20-Poly1305 is the de-facto optimum in Table 5-2. TLS Lite therefore selects TLS_CHACHA20_POLY1305_SHA256 as the default cipher_suite for software-only constrained-device builds and recommends explicit promotion to TLS_AES_128_GCM_SHA256 only when normative hardware acceleration is present.

AES-128-CBC with HMAC-SHA256 was normative under RFC 5246 (TLS 1.2) but is deprecated in RFC 8446. There are two reasons. First, the MAC-then-encrypt construction proved vulnerable to padding-oracle classes of attack such as Lucky 13 (2013) and Bleichenbacher variants (originally 1998). Second, the two-key schedule (cipher plus MAC) is necessarily larger than the single-key schedule of an AEAD. TLS Lite follows RFC 8446 and excludes CBC+HMAC by design.

5.4 Key derivation — HKDF-SHA256 and HKDF-SHA384

TLS 1.3 (RFC 8446 §7.1) selects HKDF (IETF RFC 5869) as the normative key derivation function for handshake and traffic keys. HKDF is structured in two stages. Extract maps HMAC(salt, IKM) to a pseudo-random key (PRK). Expand iteratively maps HMAC(PRK, info || T_{n-1} || 0x01) to output blocks T_n. TLS 1.3 uses the HkdfLabel structure (length, label, context) from RFC 8446 §7.1 as the info parameter.

// HKDF-Expand-Label (RFC 8446 §7.1)
struct {
    uint16 length = Length;
    opaque label<7..255> = "tls13 " + Label;
    opaque context<0..255> = Context;
} HkdfLabel;

HKDF-Expand-Label(Secret, Label, Context, Length) =
    HKDF-Expand(Secret, HkdfLabel, Length)

One Extract-and-Expand round of HKDF-SHA256 needs about 760 cycles on Cortex-M4. HKDF-SHA384, with its 80-round SHA-384 compression function, needs about 1,180 cycles. A single TLS 1.3 handshake invokes HKDF-Expand-Label roughly twelve times, which translates to about 9,000 cycles of KDF work with HKDF-SHA256 or about 14,000 cycles with HKDF-SHA384. On a 16 MHz Cortex-M0 (Class 0), that is 0.6 ms of KDF work per handshake; on an 80 MHz Cortex-M4 (Class 2), it is 0.18 ms.

BLAKE2s (RFC 7693) is ARX-structured and therefore naturally side-channel robust. However, the only KDFs that TLS 1.3 normatively registers are the SHA-2 family (SHA-256 and SHA-384). BLAKE2s is reserved by TLS Lite for adjacent (non-TLS) KDF contexts such as device bootloader key derivation or firmware signing receipts.

HKDF-Expand-Label iterates HKDF-Expand to extend output length, but in most TLS 1.3 invocations the output fits inside one block (32 bytes for SHA-256 or 48 bytes for SHA-384) and only a single HMAC operation runs. When an operator chooses KDF=HKDF-SHA256 in the TLS Lite cipher_suite envelope, that single choice fixes the Extract and Expand parameters and the HkdfLabel length normatively at once.

5.5 RFC 7228 Class 0/1/2 — device budget matrix

The RFC 7228 classification is not a mere memory partition. It is the operational unit of decision. Two devices with the same cipher_suite but different Class assignments differ in handshake frequency, session-resumption policy, certificate caching strategy, ALPN feasibility, and OCSP stapling availability. TLS Lite gives the Phase 1 envelope an explicit device_class field, so the envelope itself declares the device budget.

Adopting X.509 certificates on Class 0 already needs 4 to 5 KiB of flash just for the ASN.1 DER encoder, and one X.509 chain verification holds 1.8 KiB of RAM resident. RFC 7250 Raw Public Keys normatively address the problem: RPK transmits only the SubjectPublicKeyInfo structure, and an X25519 RPK is about 44 bytes in total.

An embedded-firmware engineer migrating Class 0 from X.509 to RPK typically goes through three steps. The first is to advertise only X25519 in the supported_groups extension. The second is to fix the cipher_suite to TLS_CHACHA20_POLY1305_SHA256 so that devices without GCM acceleration still work. The third is to enable the client_certificate_type extension from RFC 7250 so that RPK both ways becomes normative. The full three-step migration reclaims about 18 KiB of flash and about 1.5 KiB of RAM.

5.6 Lightweight block ciphers — PRESENT, SIMON, SPECK, ASCON

TLS 1.3 cipher_suite identifiers cover only AES and ChaCha20 as normative AEADs. However, the TLS-adjacent space (LoRaWAN payload encryption, Zigbee NWK keys, BLE LL encryption, firmware-image decryption, OTA update envelopes) commonly applies lightweight block ciphers such as PRESENT, SIMON, SPECK, and ASCON. ISO/IEC 29192-2:2019 normatively registers PRESENT as the international standard lightweight block cipher, and ISO/IEC 18033-3:2010 (amended 2020) registers PRESENT and HIGHT as annexed lightweight ciphers.

The NIST Lightweight Cryptography (LWC) standardization process opened in 2018 and concluded in 2023 by selecting ASCON (designed at TU Graz, Radboud University, and Infineon) as the winner — see NIST IR 8454. The ASCON family includes ASCON-128, ASCON-128a, ASCON-Hash, ASCON-Xof, and ASCON-Mac, and the family is being published normatively as NIST SP 800-232. ASCON-128 (128-bit key, 128-bit nonce, 128-bit tag) provides side-channel robustness comparable to ChaCha20-Poly1305 together with a code size smaller than PRESENT.

SIMON and SPECK were published by the United States National Security Agency (NSA) in 2013. The ISO standardization process considered them in 2018 as candidates for the ISO/IEC 29192-2 annex, but a majority of national standards bodies opposed adoption on transparency grounds and the ISO ballot failed. NIST SP 800-185 does not register SIMON or SPECK. The two families are nevertheless used in closed networks (closed industrial control, military) where the operator's threat model differs.

TLS Lite envelopes restrict the AEAD inside TLS messages to AES-GCM and ChaCha20-Poly1305. However, payload regions outside the envelope class (for example, OTA update payloads carrying firmware images or LoRaWAN ApplicationData payloads) may normatively adopt ASCON-128 as a TLS Lite recommended auxiliary AEAD. Envelopes that adopt this option carry the metadata cipher_inner=ASCON-128 so that audit transports can reconstruct the inner-AEAD trace independently.

5.7 Hardware security modules — TPM 2.0, SE050, ATECC608, ARM CryptoCell

Storing keys in plain software memory on a constrained device exposes two risks. The first is a flash-dump attack that exfiltrates the private key in plaintext. The second is a cold-boot RAM attack that lifts secrets from volatile memory. Both risks are normatively addressed by a hardware security module (secure element or secure enclave). This section compares the four hardware security modules most frequently adopted in the constrained-device space.

TPM 2.0 (Trusted Platform Module 2.0, ISO/IEC 11889:2015) is standard on desktops, laptops, and servers. In the embedded space, embedded TPM chips such as the Infineon SLB 9670, Nuvoton NPCT75x, and ST33TPHF2 appear on Class 2 devices. The strength of TPM 2.0 is that Platform Configuration Registers (PCRs), measured boot, the AIK/SRK key hierarchy, and NVRAM are all standardized. The weakness is that peak draws of 100 mA or more and response times above 100 ms make it impractical on coin-cell devices.

The NXP SE050 is an IoT-oriented secure element with an I2C interface, 1.6 mA active current, and JIL High (Common Criteria EAL 6+) certification. It accelerates ECC P-256, X25519, Ed25519, and AES-128/256, exposes 50 key slots, and supports direct RFC 7250 RPK issuance. Weaknesses include a unit cost roughly three times that of the ATECC608 and a mandatory NXP toolchain for firmware management.

The Microchip ATECC608A/B is the most widespread secure element, with a unit cost of about 0.6 USD, an I2C or SWI interface, support for ECC P-256 only (X25519 not supported on the A variant), 16 key slots, and 1.7 mA active current. It is the de-facto secure element for AWS IoT, Azure IoT, and Google Cloud IoT. The weakness is the lack of X25519 support, which blocks the migration path; ATECC608B adds partial X25519 support but with weaker constant-time guarantees.

The ARM CryptoCell-3xx family (for example CC312) is not a discrete chip but an IP block integrated into SoCs such as Nordic nRF5340, Renesas RA6M5, and Silicon Labs EFR32. ECC P-256 and X25519, AES-128/256, SHA-256/512, a TRNG, secure boot, and life-cycle state management are normatively combined inside a single IP block. The ARM PSA Crypto API (IETF draft and ARM PSA Certified) is its normative interface.

The cipher_suite choice and the hardware security module choice are entangled. A device that adopts the ATECC608A cannot normatively use X25519, so its cipher_suite is locked to TLS_AES_128_GCM_SHA256 with group=secp256r1. A device with SE050 or ARM CryptoCell does support X25519 normatively, which unlocks the software-friendly combination TLS_CHACHA20_POLY1305_SHA256 with group=x25519.

The ARM PSA Crypto API is on the normative standardization path through the IETF draft and ARM Platform Security Architecture (PSA) Certified. The API abstracts key attributes with psa_key_attributes_t, and single calls such as psa_import_key, psa_generate_key, psa_sign_hash, and psa_verify_hash transparently target either a secure-element backend or a software backend. The Phase 2 envelope API of TLS Lite recommends the ARM PSA Crypto API as the normative backend.

// PSA Crypto API — Ed25519 signing example (pseudo code)
psa_key_attributes_t attrs = PSA_KEY_ATTRIBUTES_INIT;
psa_set_key_type(&attrs, PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_TWISTED_EDWARDS));
psa_set_key_bits(&attrs, 255);
psa_set_key_usage_flags(&attrs, PSA_KEY_USAGE_SIGN_HASH | PSA_KEY_USAGE_EXPORT);
psa_set_key_algorithm(&attrs, PSA_ALG_PURE_EDDSA);

psa_key_id_t key_id;
psa_status_t s = psa_generate_key(&attrs, &key_id);
if (s != PSA_SUCCESS) return s;

uint8_t sig[64];
size_t  sig_len;
s = psa_sign_message(key_id, PSA_ALG_PURE_EDDSA,
                     payload, payload_len,
                     sig, sizeof(sig), &sig_len);
return s;

5.8 cipher_suite selection — decision checklist

Selecting a cipher_suite for a constrained device is the composition of seven sub-decisions. Each sub-decision yields a different outcome depending on the RFC 7228 Class assignment.

1. Class assignment: which of Class 0/1/2? Measure RAM and flash, then compare against RFC 7228 §3 Table 1.
2. Hardware security module: TPM 2.0 / SE050 / ATECC608 / ARM CryptoCell / none? Look up the module's supported curves and AEADs in Table 5-6.
3. Curve: X25519 / secp256r1 / secp384r1? The hardware-module constraint dominates first, then the cycle budget in Table 5-1 applies.
4. AEAD: AES-128-GCM / AES-256-GCM / ChaCha20-Poly1305 / AES-128-CCM_8? Hardware acceleration, payload length, and tag length drive the choice.
5. Hash: SHA-256 / SHA-384? This is normatively bound to the cipher_suite code point and is not a free choice, but the KDF round cost from Table 5-3 still applies.
6. Certificate format: X.509 / RFC 7250 RPK? Prefer RPK on Class 0.
7. Session resumption: PSK / 0-RTT? 0-RTT is vulnerable to replay attacks, so it is not adopted outside idempotent GET surfaces.

The safest default composition of those seven decisions is: Class 0 → ARM CryptoCell or SE050 → X25519 → ChaCha20-Poly1305 → SHA-256 → RFC 7250 RPK → PSK only. This is the normative cipher_suite default of TLS Lite, with supported_groups=x25519, signature_algorithms=ed25519, and ALPN=null carried inside the envelope.

Note on Korean Edition — KCMVP and Korean lightweight ciphers

The Korean edition of this chapter normatively maps the cipher_suite envelope to the Korean Cryptographic Module Validation Program (KCMVP) administered by the Korea Internet and Security Agency (KISA) under the National Intelligence Service (NIS) regulations. KCMVP normatively registers SEED (RFC 4269), ARIA (KS X 1213-1), HIGHT (KS X 1213-1 and ISO/IEC 18033-3 annex), and LEA (KS X 3246) as approved algorithms. Korean operators serving public-sector boilers, smart-grid meters, or 5G IoT subscribers must use KCMVP-validated modules. The Korean edition therefore adds LEA-128-GCM as a TLS Lite auxiliary inner AEAD with the envelope metadata cipher_inner=lea-128-gcm and kcmvp_level=1, while preserving the RFC 8446 normative outer AEAD (AES-128-GCM or ChaCha20-Poly1305). Korean readers consult the Korean edition for the KCMVP compliance track in detail.

5.9 Footprint benchmarks — TinyCrypt, mbedTLS, WolfSSL

The three de-facto TLS libraries for constrained devices are TinyCrypt (Intel, Apache 2.0), mbedTLS (Arm Trusted Firmware project, Apache 2.0), and WolfSSL (WolfSSL Inc., GPLv2 or commercial). Their cipher_suite-restricted build footprints are as follows.

• TinyCrypt 0.2.8: AES-128-CCM, SHA-256, ECDH P-256, ECDSA P-256, and HMAC-SHA256 build in about 16 KiB of flash and 1.4 KiB of RAM. TLS handshakes themselves are not included; the application must assemble its own envelopes.
• mbedTLS 3.5 (PSA Crypto backend): TLS 1.3 with X25519, Ed25519, ChaCha20-Poly1305, and HKDF-SHA256 builds in roughly 55 KiB of flash and 6 KiB of RAM. This is the de-facto default on Class 1 and Class 2 devices.
• WolfSSL 5.6: TLS 1.3 with X25519, Ed25519, ChaCha20-Poly1305, HKDF-SHA256, and OCSP stapling builds in about 48 KiB of flash and 5.5 KiB of RAM. A FIPS 140-3 certified build adds about 12 KiB of flash.

The footprints above assume GCC 12.2 with -Os, -mthumb, and -mcpu=cortex-m4, using the ARM PSA Crypto API backend. For mbedTLS, the PSA Crypto backend and the legacy mbedtls/aes.h backend coexist; the legacy backend adds about 8 KiB of flash on top.

The TLS Lite reference container wia/tls-lite-host:1.0.0 normatively adopts mbedTLS 3.5 with the PSA Crypto backend as its software implementation. The device side calls the same PSA Crypto API entry points while normatively binding the backend to one of ARM CryptoCell, SE050, or ATECC608 as chosen by the operator.

5.10 Operational scenario — one embedded-firmware engineer's path

An embedded-firmware engineer maintains the firmware of a wireless temperature sensor for a residential boiler. The sensor is built around the Nordic nRF52840 SoC (Cortex-M4, 256 KiB RAM, 1 MiB flash, ARM CryptoCell-310 IP integrated). The wireless stack can be either BLE 5.0 or Thread 1.3. The gateway is an ESP32-S3 (Class 2), and the cloud backend is the TLS Lite reference container wia/tls-lite-host:1.0.0.

The engineer's first decision is the Class assignment. The nRF52840 is RFC 7228 Class 2 by silicon, but the coin-cell battery requirement for six months of operation pushes the budget closer to Class 0. The decision is therefore to operate a Class 2 SoC under the Class 1 budget. The cipher_suite is TLS_CHACHA20_POLY1305_SHA256, the group is x25519, the signature algorithm is ed25519, the certificate format is RFC 7250 RPK, and the session-resumption policy is PSK only.

The second decision is the PSA Crypto API backend. Because the ARM CryptoCell-310 IP is integrated, psa_crypto_init() automatically binds CryptoCell as the normative backend. X25519 point multiplication, Ed25519 signing, and ChaCha20-Poly1305 AEAD all execute under hardware acceleration, which roughly quarters the per-handshake energy compared with a software-only build.

The third decision is the OTA-update envelope inner AEAD. TLS Lite recommends ASCON-128 as the auxiliary inner AEAD for the OTA payload region. A Korean public-sector boiler operator who must comply with KCMVP additionally adopts LEA-128-GCM as the envelope auxiliary option. The engineer encodes cipher_inner=lea-128-gcm, kcmvp_level=1, and standard=KS X 3246 into the envelope metadata so that the audit transport can separate the KCMVP compliance trace.

The fourth decision is the cipher_suite envelope's device_class field. Declaring Class 1 instructs the TLS-library builder to compile OCSP stapling as optional, to strip the X.509 chain-validation code path, and to emit an RPK-only build. The final firmware image is about 110 KiB (12 KiB bootloader, 48 KiB TLS library, 50 KiB application), occupying about 11 percent of the nRF52840's 1 MiB flash.

The fifth decision is the LoRaWAN versus BLE branch. Over BLE 5.0 GATT, TLS 1.3 can be reused directly, but payload fragmentation forces ClientHello to overflow the LL ATT MTU of 247 bytes. The engineer either enables the ClientHello compression extension (IETF draft-ietf-tls-cthello) or switches to DTLS 1.3 (RFC 9147). Over Thread 1.3, CoAP-over-DTLS 1.3 is normative, and the combination of RFC 7252 and RFC 9147 is the de-facto standard.

5.11 Normative references touched in this chapter

• IETF RFC 7748 — Elliptic Curves for Security (X25519/X448)
• IETF RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA)
• IETF RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols
• IETF RFC 5869 — HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
• IETF RFC 7228 — Terminology for Constrained-Node Networks
• IETF RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
• IETF RFC 9147 — The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
• IETF RFC 7250 — Raw Public Keys in TLS/DTLS
• IETF RFC 7252 — The Constrained Application Protocol (CoAP)
• IETF RFC 7693 — The BLAKE2 Cryptographic Hash and Message Authentication Code
• IETF RFC 4269 — SEED Encryption Algorithm (Korea)
• NIST FIPS 197 — Advanced Encryption Standard (AES)
• NIST FIPS 180-4 — Secure Hash Standard (SHS)
• NIST FIPS 202 — SHA-3 Standard
• NIST SP 800-38C — CCM Mode for Authentication and Confidentiality
• NIST SP 800-38D — Galois/Counter Mode (GCM) and GMAC
• NIST SP 800-185 — SHA-3 Derived Functions
• NIST SP 800-186 — Recommendations for Discrete Logarithm-Based Cryptography
• NIST IR 8454 — Status Report on the Final Round of NIST LWC (ASCON winner)
• NIST SP 800-232 (draft) — ASCON Family of Cryptographic Algorithms
• ISO/IEC 29192-2:2019 — Lightweight cryptography — Part 2: Block ciphers (PRESENT)
• ISO/IEC 18033-3:2010 — Block ciphers (AES, SEED, HIGHT)
• ISO/IEC 11889:2015 — Trusted Platform Module Library (TPM 2.0)
• KS X 3246 — LEA Block Cipher (Korean national standard)
• ARM PSA Crypto API — ARM Platform Security Architecture Certified

5.12 Implementation worksheet

1. Read the cipher_suite envelope field definition in spec/phase-1-envelopes.md §5.
2. Walk the CLI helper: ./cli/tls-lite.sh envelope --cipher_suite=TLS_CHACHA20_POLY1305_SHA256 --group=x25519 emits a sample envelope.
3. Launch simulator panel 4 to observe how toggling cipher_suite affects device_class and the plaintext budget.
4. Confirm whether the device uses ATECC608, SE050, ARM CryptoCell, or TPM 2.0, and look up the supported curves and AEADs in Table 5-6.
5. For KCMVP compliance, include cipher_inner=lea-128-gcm and standard=KS X 3246 metadata normatively in the envelope.
6. Run the §5.* items of the conformance suite at https://github.com/WIA-Official/wia-tls-lite-conformance.

5.13 Cross-standard composition recap

The cipher_suite envelope of this chapter composes with the WIA family as follows. WIA-OMNI-API credential storage binds normatively to the PSA Crypto API key_id abstraction used in this chapter, so a single device can store keys for multiple standards in one secure element. WIA-AIR-SHIELD's runtime trust list reuses the RPK issuance trust anchors of this chapter directly, so firmware builders do not maintain per-standard trust anchors. WIA-INTENT's workload intent declaration binds to the device_class envelope field defined here, enabling automatic verification that the intended class matches the actual class.

Devices adopting the Korean KCMVP-compliant envelope carry both the cipher_inner=lea-128-gcm metadata of this chapter and the intent_jurisdiction=KR declaration of WIA-INTENT, which lets the audit transport reconstruct the Korean compliance trace normatively. Even when one operator simultaneously runs global devices and Korean KCMVP devices, the audit transports remain branched and re-joinable inside one W3C Trace Context identifier space.