Sealedge (formerly TrustEdge): Provenance for Edge Data and Supply Chains (Rust)

GitHub Repo | Updated: November 2026

Sealedge provides cryptographic chain of custody for edge device data and software supply chains: sign at the source, verify with an independent service, and get a cryptographic receipt as proof. It started as TrustEdge, a personal learning project, and now lives under TrustEdge-Labs. I renamed it Sealedge in April 2026 for trademark reasons; TrustEdge Labs stays as the name of the organization behind it. The current release is v6.2.0 (September 2, 2026).

Tech Stack: - Rust (workspace of 9 crates: core library with thin CLI and WASM shells) - seal CLI - Ed25519 signing over BLAKE3 hashes - X25519 and HPKE (RFC 9180) key wrapping, XChaCha20-Poly1305 content encryption - YubiKey PIV hardware-backed signing - Platform verification service with PostgreSQL and a SvelteKit dashboard - Docker Compose (full stack demo) - GitHub Action for CI attestation

License: Mozilla Public License 2.0 (MPL-2.0). Commercial licenses are available.

Why I Built This

Edge devices generate data: video, sensor readings, audio, logs. There is no built-in way to prove that data has not been tampered with between capture and consumption. Software teams have the same problem with SBOMs: they generate them, but can't cryptographically prove the SBOM matches the actual binary. Sealedge is a cryptographic chain of custody for both.

How It Works

Sealedge has two attestation modes.

Point attestation covers single artifacts such as SBOMs, firmware, and documents. seal attest-sbom takes BLAKE3 hashes of a binary and its SBOM and signs them with Ed25519, along with a timestamp and a random nonce. The result is a lightweight .se-attestation.json document that any third party can verify with only that document and the embedded public key. The platform can also issue a JWS receipt proving verification happened at a specific time.

seal keygen --out-key build.key --out-pub build.pub --unencrypted
seal attest-sbom --binary target/release/myapp --sbom bom.cdx.json \
  --device-key build.key --device-pub build.pub --out attestation.se-attestation.json
seal verify-attestation attestation.se-attestation.json --device-pub "$(cat build.pub)"

The sealedge-attest-sbom-action does the same in one line of CI, and verifies the seal binary's SHA256 before running it. Sealedge also attests its own releases: every GitHub release includes seal.se-attestation.json and build.pub.

Stream attestation covers continuous data such as video, audio, and sensor readings. seal wrap signs data at capture with an Ed25519 key (or YubiKey ECDSA P-256), encrypts the chunks under a per-archive random content key with XChaCha20-Poly1305, wraps that key to one or more recipients with HPKE, and packages chunks, manifest, and signature into a .seal archive with a BLAKE3 continuity chain. An independent verification service checks the signature, chain integrity, and manifest, and issues a receipt. seal unwrap only recovers the original data after signature and chain verification pass.

Archives can also form a device chronicle: a hash-linked, sequence-numbered chain that seal verify-chronicle checks for gaps, reordering, and broken links. A device can submit its latest tip to the platform for a signed, timestamped witness receipt, which catches deletion of the newest archives. seal rekey handles key rotation, signed by both the old key and the new one.

Recent Releases

  • 6.1 (August 6, 2026) came out of an external review that found four critical issues. The fixes included a content-encryption redesign: the Ed25519 key is now signing-only, and each archive's content key is HPKE-wrapped with ephemeral sender keys for forward secrecy. It also added the device chronicle, key rotation, and revocation.
  • 6.2 (September 2, 2026) hardened custody and recovery: zeroized key material on import and export, key files created owner-only from the start, all-or-nothing seal unwrap, streaming wrap with size-capped reads, and an encrypted platform signing key.

The full story is in Sealedge 6.1 and 6.2: What an External Review Changed.

What I Learned

The review was worth more than any feature I could have shipped instead. Four criticals sounds bad. It is much better than four criticals that nobody found. The fixes also made the design simpler: separate keys for separate jobs, one canonical set of bytes to sign, one definition of what a receipt means.

Sign at the source, verify independently, keep the receipt.