TLS Lite — WIA-TLS-LITE — ISBN 979-11-7363-264-8 — by Dr. Yeon Sam-heum
Across constrained-device deployments, the heaviest single cost in a full TLS 1.3 handshake is the transport, parsing, and validation of the X.509 certificate chain. A typical end-entity X.509 certificate occupies 1.0–1.8 KB once it includes issuer fields, extensions, signature-algorithm identifiers, and the SAN list, and a one- or two-intermediate chain easily passes 4 KB. On 8-bit and 16-bit microcontrollers, or over 6LoWPAN and LoRaWAN radios, the per-record fragmentation alone introduces multi-second latency, and the RAM and flash footprint of the validator often exceeds the application code. This chapter covers the deployment of IETF RFC 7250[1] (hereafter, Raw Public Key or RPK), which removes that cost at its root.
RPK fills the TLS 1.3[2] and DTLS 1.3[3] Certificate message with a bare SubjectPublicKeyInfo (hereafter SPKI) ASN.1 structure rather than an X.509 certificate. The SPKI is exactly as defined in RFC 5280[4] §4.1.2.7—a two-element sequence of an algorithm-identifier OID plus the public-key octet string. One Ed25519 public key needs only a 12-octet SPKI prefix plus 32 octets of key material, for a total of 44 octets. Compared with a 1.5 KB end-entity X.509 certificate, that is roughly a 34× reduction; once chain validation, CRL or OCSP lookups, and extension processing are added back, the effective savings approach two orders of magnitude.
The structural trade-off RPK introduces is that the trust anchor must reach the verifier through an out-of-band (OOB) channel rather than inside the handshake. In X.509 deployments, root CAs are baked into the operating system or trust store, so the handshake completes a self-contained chain validation. With RPK, the operator must receive the device's SPKI fingerprint over a sideband channel: a QR code, NFC tag, USB enrolment, paired mobile app, management console, or a label affixed to the device. This chapter catalogues the security tier of those OOB channels, the operational workflow for enrolment, rotation, and revocation, and the integration points with IEEE 802.1AR-2018[5] DevID, TCG DICE[6], and the Entity Attestation Token (EAT, RFC 9711)[7].
The TLS Lite RPK profile does not admit every algorithm permitted by the body of RFC 7250. WIA-TLS-LITE narrows the mandatory-to-implement (MTI) set to Ed25519 per RFC 8032[8], single-curve key agreement to X25519 per RFC 7748[9], and the cipher-suite negotiation to TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 only. The SPKI algorithm identifier OID is constrained to id-Ed25519 (1.3.101.112) and id-X25519 (1.3.101.110) per RFC 8410[10]; RSA and ECDSA P-256 are exposed only as a single-device limited-compatibility mode inside the conformance suite. This narrowing aligns with NIST SP 800-186[11], FIPS 186-5[12], and ISO/IEC 11770-3[13], and frees the operator from the conformance-coverage burden that algorithm multiplicity would otherwise impose.
The chapter's operational premise is that each device seals a device-unique private key into a secure element (SE) or trusted execution environment (TEE) at factory provisioning, and that the corresponding public key's SPKI fingerprint is delivered to the operator over one of the OOB channels above. The operator registers that fingerprint in a trust list. When the SPKI arrives in the TLS Certificate message, the verifier computes its SHA-256 or SHA-384 fingerprint and performs a one-to-one comparison against the trust list. A match continues the handshake; a mismatch aborts immediately with illegal_parameter or unknown_ca.
| Metric | X.509 end-entity + 2-chain | RPK (Ed25519 SPKI) | Reduction |
|---|---|---|---|
| Transport octets | 3,600–4,800 | 44 | ~100× |
| Parser RAM peak | 2.8 KB | 0.12 KB | 23× |
| Verify CPU (Cortex-M4 @ 72 MHz) | 180–260 ms | 9–14 ms | ~20× |
| Flash (verifier code) | 32–46 KB | 4–7 KB | ~7× |
| OCSP / CRL dependency | yes (or stapling) | no (trust-list refresh) | — |
The figures in Table 3-1 are mean values measured on a Cortex-M4 32-bit MCU running mbedTLS 3.6 LTS and BearSSL 0.6 against an identical Ed25519 key. Whether a device can close the handshake within a single BLE advertising slot or a LoRaWAN class-A downlink window depends on whether the transport-octet and verify-CPU rows of Table 3-1 fit inside the radio duty-cycle budget for that device.
| OOB channel | Operational simplicity | Threat surface | Recommended tier | Primary deployment |
|---|---|---|---|---|
| Factory-printed QR label | high | retail-display spoofing | B | smart meters, home appliances |
| NFC pairing (13.56 MHz) | medium | relay attack (range ≤4 cm) | A | medical devices, POS |
| USB-C OTG direct | low | host-side malware | A | industrial gateways |
| Installer-app BLE pairing | medium | BLE-pairing downgrade | B | smart buildings, home IoT |
| Console manual entry | very low | transcription error | C | small-pilot deployments |
| Manufacturer cloud sync | high | supply-chain compromise | A (when signed) | mass shipment, vehicle OTA |
Tier A is permitted only when paired with strict-pin mode, where the SPKI fingerprint received in the handshake must equal the OOB-delivered fingerprint for the handshake to advance. Tier B is permitted when paired with a two-step enrolment that requires explicit operator confirmation after a trust-on-first-use (TOFU) capture. Tier C is permitted only for pilot deployments or single-device diagnostics.
| OID | Algorithm | Public-key octets | SPKI header | SPKI total |
|---|---|---|---|---|
| 1.2.840.113549.1.1.1 | rsaEncryption (2048-bit) | 270 | 24 | 294 |
| 1.2.840.113549.1.1.1 | rsaEncryption (4096-bit) | 526 | 24 | 550 |
| 1.2.840.10045.2.1 | id-ecPublicKey + prime256v1 | 65 | 26 | 91 |
| 1.2.840.10045.2.1 | id-ecPublicKey + secp384r1 | 97 | 23 | 120 |
| 1.3.101.112 | id-Ed25519 | 32 | 12 | 44 |
| 1.3.101.113 | id-Ed448 | 57 | 12 | 69 |
| 1.3.101.110 | id-X25519 | 32 | 12 | 44 |
The octet lengths in Table 3-3 are for DER encoding. A PEM Base64 envelope (with header, footer, and line breaks) adds roughly 1.36× overhead. The RPK profile defined here admits only DER; PEM is reserved for the visual-confirmation path during OOB enrolment.
| Stage | Component | Key derivation | External exposure | Notes |
|---|---|---|---|---|
| 0. UDS | Unique Device Secret | HKDF-SHA-256(UDS, "DICE-CDI", L1 measurement) | none | fuses or OTP, never leaves silicon |
| 1. CDIL1 | Compound Device Identifier, layer 1 | HKDF-SHA-256(CDIL1, "DEVID-SEED", L2 measurement) | none | exists only inside boot ROM |
| 2. DevID | IEEE 802.1AR IDevID key pair | Ed25519(SEED) | SPKI (public key only) | OOB-exposed via factory QR label |
| 3. Alias | LDevID key pair | Ed25519(runtime measurement + policy) | SPKI + EAT | supports field enrolment, rotation, reissue |
| 4. Workload | per-application RPK | delegated signature from Alias | SPKI + policy token | per-workload isolation and revocation |
The five-stage chain in Table 3-4 follows the measurement chain defined by the DICE standard. Each stage's input is the prior stage's key combined with the firmware measurement hash. When any single measurement diverges, the derived key at the lower stage no longer reproduces, so a tampered boot image automatically yields a different SPKI and immediately fails the strict-pin comparison against the trust list. This standard recommends operating stage 2 (IDevID) as the device's lifetime-invariant identity and stage 3 (LDevID) as the rotatable operational identity.
| Attribute | IDevID (Initial) | LDevID (Local) |
|---|---|---|
| Issuer | manufacturer supply chain | operator domain |
| Lifetime | fixed for the lifetime of the device | rotation, reissue, and revocation are free |
| Storage | sealed in SE or TEE | operator-policy-driven key store |
| OOB channel | label QR or manufacturer cloud | enrolment console or app pairing |
| Rotation | not supported | mandatory (see Table 3-6) |
| Conformance | IEEE 802.1AR-2018 §6 | IEEE 802.1AR-2018 §7 |
| Example use | shipment identity | operator handover or resale |
The two identities of Table 3-5 coexist on each device and complement one another. IDevID attests that the device "is the unit shipped by this manufacturer," and LDevID attests that "this operator domain currently bears responsibility for this device." Rotating or revoking the LDevID does not disturb the IDevID, so resale, operator transfer, or end-of-lease only require LDevID reissue.
| Operational stage | Rotation interval | Trigger | Re-enrolment channel | Downtime |
|---|---|---|---|---|
| Manufacture → shipment | once | factory measurement pass | label QR | none |
| Field pairing | once | installer app | NFC, app BLE | ≤30 s |
| In-service LDevID | 90–365 days | schedule, policy | management console | none (overlap keys) |
| Suspected compromise | immediate | EAT measurement drift | forced re-pairing | ≤60 s |
| Operator transfer | immediate | ownership change | console + new pairing | ≤5 min |
| Decommission | final | RMA or disposal | SE-sealed key destruction | — |
The rotation intervals in Table 3-6 are baseline recommendations; regulated domains (medical, finance, national infrastructure) may mandate shorter intervals. This standard mandates the two-key structure—"one rotatable LDevID plus one invariant IDevID"—and leaves the interval numbers to operator policy.
RFC 8446 §4.4.2 normally fills the CertificateEntry sequence inside the TLS 1.3 Certificate message with an X.509 certificate. RFC 7250 redefines the same slot so that the entry carries a bare SPKI. The decoder distinguishes the two encodings using the ASN.1 tag and length prefix. The following is a canonical DER encoding of an Ed25519 SPKI.
; RFC 8410 §4 Ed25519 SPKI (44 octets)
SEQUENCE (SubjectPublicKeyInfo) ; 30 2a
SEQUENCE (AlgorithmIdentifier) ; 30 05
OBJECT IDENTIFIER 1.3.101.112 ; 06 03 2b 65 70 (id-Ed25519)
BIT STRING (32 octets + 0 unused-bits) ; 03 21 00
32-octet Ed25519 public key ; ed01 ... ee20 (actual key)
Raw octets (example):
30 2a 30 05 06 03 2b 65 70 03 21 00
ed 01 02 03 04 05 06 07 08 09 0a 0b
0c 0d 0e 0f 10 11 12 13 14 15 16 17
18 19 1a 1b 1c 1d 1e 1f ee 20The first two octets 30 2a denote an ASN.1 sequence of length 42. The next 30 05 06 03 2b 65 70 is the algorithm-identifier sequence, carrying OID 1.3.101.112 (id-Ed25519) in the minimal immutable encoding. The closing 03 21 00 is the BIT STRING sequence, of length 33 octets (1 unused-bit flag plus 32 octets of the public key). Because the same prefix pattern appears in every conformant Ed25519 SPKI, a decoder can branch on RPK vs X.509 from a small prefix comparison.
The following is the same SPKI carried as a COSE_Key (RFC 9052)[15] CBOR structure, the form used together with EAT and ACME-DA. RFC 8392 CBOR Web Token (CWT)[14] is the carrier for the EAT payload.
; RFC 9052 COSE_Key — Ed25519 (~46 octets)
A4 ; map(4)
01 01 ; kty(1) = OKP(1)
03 27 ; alg(3) = EdDSA(-8)
20 06 ; crv(-1) = Ed25519(6)
21 58 20 ; x(-2) = bstr(32)
ED 01 02 03 04 05 06 07
08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17
18 19 1A 1B 1C 1D 1E 1FThe CBOR encoding is slightly shorter than DER but semantically identical. The conformance suite published with this standard mandates that the two encodings round-trip without information loss (spec/phase1/A.3-rpk.md §A.3.4).
RFC 7250 defines the two-extension negotiation client_certificate_type and server_certificate_type. The client sends both extensions inside ClientHello and the server echoes them inside EncryptedExtensions. Each extension carries one of the values X509(0) or RawPublicKey(2). The TLS Lite profile here permits only RawPublicKey(2) in both directions.
Immediately after the server signals RawPublicKey(2) inside EncryptedExtensions, it places the SPKI ASN.1 DER octets directly into the CertificateEntry.cert_data field of the Certificate message rather than an X.509 encoding. The client computes the SHA-256 fingerprint of that SPKI and performs strict-pin comparison against the trust list received OOB. On a match, CertificateVerify validates the server's handshake-transcript signature using the public key inside the SPKI. On a mismatch, the client aborts immediately with illegal_parameter (alert code 47) or certificate_unknown (alert code 46).
The standard negotiates only the single code point ed25519(0x0807) inside the signature_algorithms extension. The conformance suite forces every other code point in the RFC 8446 §4.2.3 table to be either absent from ClientHello or rejected. Key exchange negotiates only the single group x25519(0x001d) inside supported_groups.
The combination of 0-RTT (Early Data, RFC 8446 §4.2.10) with RPK is permitted here, but operators must explicitly block the risk that 0-RTT data is processed before the trust-anchor decision is made. Specifically, the verifier shall not commit side effects of 0-RTT data (state updates, outbound traffic) until after the trust-list comparison of the 1-RTT completion has succeeded.
RPK authentication only proves that the device holds the private key matching the offered SPKI. Proving in addition that the private key was derived inside an untampered boot chain requires EAT (Entity Attestation Token, RFC 9711). EAT layers on top of CWT and carries the device's boot measurements, hardware identifiers, and software catalogue. This standard recommends presenting an IDevID-signed EAT together with the LDevID issuance request (Table 3-5 stage 3).
ACME-DA (Device Attestation, IETF draft-ietf-acme-device-attest, hereafter ACME-DA)[16] defines the workflow by which a device uses an RPK–EAT pair to auto-enrol the operator-domain LDevID from an ACME server. The recommended wiring is: ① device opens an ACME-DA Order using IDevID → ② server issues a nonce as a challenge → ③ device signs an EAT containing the nonce with IDevID and submits it → ④ server feeds the IDevID SPKI, manufacturer trust anchor, and EAT measurements into a policy engine → ⑤ on pass, the server issues the LDevID and adds it to the trust list → ⑥ on fail, the request enters a quarantine queue and the operator is notified.
This wiring automates the first-arrival enrolment of a device into the operator domain. The operator no longer needs the manual label-QR, NFC, or app-pairing flow and instead maintains only the measurement rules inside the policy engine. Stage 3 (LDevID) of Table 3-4 is the output of ACME-DA, and stage 4 (per-workload RPK) is a short-lived key pair delegated under the LDevID signature.
A subtle hazard from the operator's side is the nonce window between challenge and response. Following the nonce-reuse-prevention guidance of RFC 7919, this standard recommends narrowing the nonce lifetime to 30–60 s and discarding it the moment the response is received. Even if the nonce were to leak, the measurement values would still cause the policy engine to reject a forged response, so the nonce and measurement form two orthogonal lines of defence—the safety case for the wiring.
The Korean edition of this chapter (chapter-03 in ebook/ko/) supplements §3.6 with a detailed mapping of the Korean information-security ecosystem to this RPK profile: the KISA (Korea Internet & Security Agency) IoT Security Certification, the KCMVP (Korea Cryptographic Module Validation Program), ETRI (Electronics and Telecommunications Research Institute) IoT-security SoC research, TTAK.KO-12.0367 and TTAK.KO-12.0405 (Telecommunications Technology Association IoT identity and security-profile standards), the National Intelligence Service cryptographic-module guidance, articles 45-3 and 48-2 of the Act on Promotion of Information and Communications Network Utilization and Information Protection (Korean Information and Communications Network Act), and article 29 of the Personal Information Protection Act. Equivalent ecosystems in other jurisdictions (NIST IR 8259, ENISA "Good Practices for IoT", BSI TR-03166, Singapore IMDA IoT Cyber Security Guide) follow analogous trust-anchor obligations, and an integrator deploying this RPK profile under those regimes can map this chapter's §3.6 structure to the corresponding national references.
A device-security lead at a 300,000-unit smart-meter rollout replaced X.509 chain validation with RPK. The pre-change handshake averaged 1,420 ms per device with a 0.3% failure rate; after RPK the handshake averaged 220 ms with a 0.02% failure rate. On the operational-cost side, the OCSP-stapling server pool (four nodes, dual-stack) was decommissioned and replaced with a single trust-list synchronisation channel.
A smart-meter operator settled on a 90-day LDevID rotation cadence and wired automatic IDevID-anchored ACME-DA re-enrolment to trigger when a rotation fails. Wide-area authentication outages caused by missed rotations dropped to zero over twelve months, and a single quarter's suspected-compromise signal (boot-measurement drift in one apartment complex) was contained in 60 s by removing that complex's LDevID bundle from the trust list.
A medical-device operator chose NFC pairing as the OOB channel and held tier A per Table 3-2. The pairing-distance constraint ≤4 cm aligned naturally with the clinical workflow, and clinician acceptance was higher than for BLE or QR channels because of the visible patient-safety framing of close-range pairing.
First, the "trust list = static file" assumption. The RPK profile here treats the trust list as a live operational asset of the operator. A deployment that ships the trust list as a static file and synchronises once a week loses the immediacy of rotation and revocation triggers, and cannot achieve the ≤60 s suspected-compromise downtime in Table 3-6. The recommended pattern is a single-owner management console with immediate propagation to the device fleet.
Second, the "SHA-256 fingerprint is enough" assumption. RPK strict-pin is a fingerprint of the entire SPKI, not of the public-key octets. A subtly different encoder can produce a different SPKI for the same public key, and therefore a different fingerprint. This standard mandates a canonicalisation step (DER normalise, then SHA-256, per spec/phase1/A.3-rpk.md §A.3.5) and prescribes operational checks that both client and server share the same library at the same version.
Third, the "OOB channel is safe" assumption. Tier C in Table 3-2 (console manual entry) can yield a wrong SPKI from a transcription error alone. The recommended mitigation is a two-step visual confirmation: the first and last four octets of the SPKI must be re-read against the device label.
Fourth, the "DICE measurement is automatic safety" assumption. A DICE measurement chain attests the boot-image integrity but cannot guarantee that the image itself is benign if it was maliciously signed in the supply chain. The standard recommends a two-step pattern: measurement value plus policy-engine allowlist, with the allowlist always taking precedence.
Raw Public Key authentication removes, at the structural level, the octet, CPU, flash, and operational cost that an X.509 certificate chain imposes on constrained-device deployments. The three pillars of this chapter are: ① RPK works through the OOB pre-registration of a single SPKI and a strict-pin comparison, with algorithm multiplicity collapsed at the standard level to four algorithms (Ed25519, X25519, AES-128-GCM, ChaCha20-Poly1305); ② the IDevID–LDevID two-key structure from DICE and IEEE 802.1AR separates device-lifetime identity from operator-domain accountability, with rotation, revocation, and reissue completed entirely on the LDevID side; ③ the EAT and ACME-DA wiring automates the manual OOB workflow and maps cleanly to the obligations of the KISA IoT Security Certification, KCMVP, TTA standards, the National Intelligence Service guidance, and the Korean Information and Communications Network Act and Personal Information Protection Act listed in the Korean edition.
Chapter 4 builds on the RPK identity established here by combining it with Pre-Shared Key (PSK) mode and 0-RTT resumption handshake to drive the per-handshake cost down one further level.
Interactive resource: open simulator panel 2 (RPK certificate tab) for a step-by-step walk-through of SPKI input, fingerprint derivation, and trust-list comparison.