Embedded and OEM platforms
A no_std Rust leaf that speaks real MLS on a Cortex-M class part, beside the radio stack you already ship. Integrate the platform once, qualify identity, delivery, and recovery across device classes, then carry it through every product line.
Diagram: a phone running OfflineID and a lock built on the leaf profile, with no hub in reach. The phone sends an unlock command over Bluetooth in four fragments. The lock opens it inside an MLS session, verifies the signature and freshness, persists its state before replying, and seals an acknowledgment.
No hub in reach. The lock opens the command inside its own MLS session and verifies it on the part.
Why the leaf is a real peer
Constrained parts get a reduced peer. A lock or a sensor usually gets a proprietary link to a hub, and the hub holds the real keys. When the hub is unreachable, the device cannot prove anything, exactly where the product is most valuable.
The device holds its own key. The leaf mints and signs its key package, joins an MLS session from the phone's welcome, and verifies every control frame by signature, address, and a two-day freshness window. A stale or replayed command is refused on the part.
Persist before emit. Every operation that advances the ratchet writes to storage before a frame leaves, because a state rolled back by a power cut would reuse a nonce. The crate enforces the order instead of documenting it.
What you can build on constrained silicon
Each of these runs on the shipped leaf crate and the platform layer above it.
The leaf holds its own identity key and a session with the phone. A command is opened and verified on the part, and a stale or replayed one is refused, whether or not the cloud is up.
Key packages are minted with a backdated validity start and a supplied timestamp, so a device with no time source still pairs, and re-pairs after a power cycle from persisted state.
Integrate once beside your radio stack, validate identity, delivery, and recovery across device classes, then carry it through every product line without re-qualifying the protocol.
What the crate provides, and what you do
The qualification suite
An OEM integration is measured against acceptance criteria agreed up front. These are targets, not current results.
The flash figure on this page is measured on the Cortex-M33 target with size optimisation, link-time optimisation, and panic-abort, from the footprint harness in the SDK repository. It excludes the vendor radio stack, RTOS, bootloader, your application, and runtime heap. The receive-only protocol core alone is about 95 KiB.
How an engagement runs
Scoped up front, measured against the suite, then licensed across the portfolio.
- IntegrateA paid integration evaluation for one product line, beside your existing radio stack. Integration effort and time to a shipping device are the measured result.
- ValidateIdentity, delivery, and recovery re-qualified across device classes and operating environments with reference ports and an acceptance-test harness.
- ExpandAn annual platform license with minimums, then per-device royalties as the integration ships across the portfolio. See pricing.
The engineering record
- The leaf crate
- offline-protocol-leaf on crates.io, dual-licensed, compiled for bare-metal targets and gated in CI for Cortex-M33.
- Why a leaf speaks MLS
- ADR 0021: the decision, and the 400 KiB gate it set.
- Provisioning
- The provisioning spec: time, entropy, storage, and authorization, and what the crate cannot supply.
- Footprint
- The footprint harness: how the flash and wire figures above are measured.
- Audit status
- The leaf uses mls-rs, pinned to an exact version, with its bare-metal crypto provider. This stack has not had a third-party security audit. An interop harness drives a real OpenMLS phone against the leaf in CI.
Embedded and OEM FAQ
What is the leaf profile?
A no_std Rust crate, offline-protocol-leaf, that lets a constrained device such as a lock, a sensor, or a mains-powered relay speak the protocol as a real peer. It runs RFC 9420 MLS as a never-committing member: the phone or gateway creates the group and issues every commit; the device joins, opens what arrives, answers, and persists.
How big is it?
The complete leaf protocol image measures 449.5 KiB of flash on a Cortex-M33 target, a little over a quarter of a 1,536 KiB part. That covers the protocol layer and MLS only; it excludes the vendor radio stack, RTOS, bootloader, your application, and runtime heap. The receive-only protocol core alone is about 95 KiB.
What does a message cost on the radio?
A representative encrypted message packages into 472 bytes, which crosses BLE in four fragments at the 185-byte MTU floor. The compact binary wire format brought that down from 1,342 bytes and ten fragments.
Does it run on my silicon?
The crate compiles for bare-metal targets and is gated in CI for the Cortex-M33 target. It sits above whatever link layer your part already has: Bluetooth, Thread, Zigbee, Z-Wave, Wi-SUN, or IP. It does not replace your radio stack, RTOS, or bootloader.
What does the integrator have to provide?
Four things the crate cannot supply: a time source at pairing, real hardware entropy, durable atomic storage for session state, and authorization, because a session proves who a peer is and never that the owner meant them.
Has the MLS implementation been audited?
The leaf builds on mls-rs, the open-source RFC 9420 implementation from AWS Labs, pinned to an exact version with its bare-metal crypto provider, and every CI run drives a real OpenMLS phone against the leaf in an interop harness. The SDK's architecture record states that mls-rs has had no third-party security audit and accepts that risk explicitly, so your qualification plan can account for it.
How does an OEM engagement work?
A scoped, paid integration evaluation for one product line beside your existing radio stack, measured against agreed qualification targets, then an annual platform license with minimums and per-device royalties as the integration ships across your portfolio. Contact us to scope it.
