Crate rusty_esp_mid 

rusty_esp_mid — MATA mID on the chip: a device DID with its key at rest in encrypted NVS/eFuse, signed assertions, capability verification, owner adoption (bind-to-this-hub as a signed grant) and a signed capability manifest. Replaces vendor provisioning and cloud claiming. Memory safe, no_std core.

This is the facade: it re-exports the no_std core and exposes the chip backends under esp. Depend on this crate; reach into the sub-crates only when you are building a backend.

Part of Janus (Remade With Rust). Plan: docs/plans/rusty_esp_mid.md.

Modules

adoption

Adoption — the owner-signed grant that tells a device who it belongs to and who it may talk to. It is the Pi-mission bind record, signed.

cap

Capability matching with mata-cap semantics, over borrowed strings.

did

did:mata — the self-certifying identifier.

esp

Chip backends (esp-hal for Track B, esp-idf for Track A).

esp_core

rusty_esp_core — the shared vocabulary of the Janus ESP family.

jws

JWS compact form for ES256, as mid-issuer builds it.

key

The device key: generated once from the chip’s TRNG, persisted through the Kv seam, never leaving the process in plaintext except to that seam.

kms

The gateway handshake: a server-issued NonceEnvelope, signed by the device into a SignedAssertion. Byte-identical to kms-types.

manifest

Signing the rusty_esp_core capability manifest.

nonce

A bounded single-use nonce window: the replay defence for control frames that arrive with a nonce (adoption tickets, local control, signal-session handshakes). Fixed capacity, no heap; the oldest entry is evicted.

prelude

The names a sketch or firmware wants in scope.

roster

The self-signed genesis roster — the identity proof embedded in a self-issued mID token. Types, field names and the canonical byte form are those of mid-issuer; the device’s genesis roster has exactly one verification method: itself.

signer

The signing seam — upstream mid-signer’s DeviceSigner, re-exported, plus the family’s verifier.

token

The self-issued mID token: what a device presents to any relying party that runs mid-verify — including the home computer’s sign-in kit.

Structs

Adoption

A decoded, signature-carrying adoption.

AdoptionFields

The fields of an adoption, over borrowed strings. Used both to encode (the owner’s tooling) and as the decoded view (the device).

DeviceId

A short, stable, ASCII identifier for the signing device — the string DeviceSigner::device_id returns and the roster lists.

DeviceKey

The device’s P-256 signing key and its id.

Did

A did:mata identity: the compressed public key, validated on the curve.

NonceWindow

Remembers the last N nonces seen.

OwnerPin

The owner pin a device stores after its first adoption.

Constants

VERSION

Crate version, for capability manifests and logs.

VM_TYPE_ECDSA_P256

The verification-method type string mID uses for every P-256 key.

Traits

DeviceSigner

The abstract capability a device’s signing key provides.

Functions

sha256

SHA-256 of data, the prehash every signature in this crate is over.

verify_prehash

Verify a 64-byte r || s P-256 signature over prehash under a 33-byte compressed public key, rejecting high-s — the malleability defence every Janus verifier applies (they all route through here; the plan’s M4 audit table lists them). Upstream mid-verify verifies the scalars as given today; the oracle test pins that so the difference is never silent.