Background
We're developing an open receipt format for cryptographic attestation of physical-world events (cold-chain readings, physical-AI actuator decisions, supply-chain provenance), specified at the IETF as draft-farley-acta-signed-receipts-01. The format uses Ed25519 or ECDSA P-256 over RFC 8785 JCS canonicalization, and is currently implemented by four independent software runtimes that cross-verify at exit 0 against the same reference CLI.
The receipt format is a natural fit for ATECC608 as the hardware-bound signer in sensor-side deployments, where the signing key must be non-exportable and per-device distinct. Pharma cold-chain compliance (FDA 21 CFR Part 11 electronic signatures), premium supply-chain provenance, and physical-AI governance (Microsoft's Agent Governance Toolkit PR #1168 extends this to the software side) are the initial buyer categories.
Proposal
I've prepared a reference example implementation showing the ATECC608B + JCS + ECDSA P-256 flow end-to-end: ScopeBlind/examples#1 — atecc608-ecdsa-jcs-receipt/.
I'd like to offer this to the cryptoauthlib repo as a new app/signed_receipt/ entry if the maintainers find it useful. Before opening a PR here:
- Is the
app/ folder the right home for a teaching example of this shape? The existing entries (tng, secure_boot, ip_protection, wpc) are each a cohesive use-case. signed_receipt/ would follow that pattern: one folder, one use case, a README + minimal C + sample fixtures.
- License alignment. The CONTRIBUTING.md notes that contributions to cryptoauthlib go under Microchip's license terms. I'm willing to contribute under those terms for the C portions that link against cryptoauthlib; the host-side Python reference can stay under MIT in its own repo and be linked rather than upstreamed. Happy to adapt if there's a cleaner split.
- Scope. The example I've prepared is intentionally minimal: thin wrapper (init / sign 32-byte digest / read pubkey / release), example CLI that takes a digest from argv, and a host-side Python companion that handles canonicalization. Would this level of scope fit? Or would you prefer I include full firmware integration for a specific target (e.g. SAMD21 with I2C HAL) to match the style of
app/secure_boot/?
What the example teaches
Cleanest breakdown between host and device:
- Host (Python / Node / whatever your gateway runs): builds the receipt envelope, JCS-canonicalizes, SHA-256 hashes. Produces a 32-byte digest.
- Device (ATECC608B via cryptoauthlib): receives the digest, calls
atcab_sign_ext (or atcab_sign), returns 64-byte raw ECDSA r||s.
- Host: assembles the final receipt JSON with signature, ready for offline verification.
This matches real cold-chain firmware architecture: sensor-side crypto + gateway-side assembly. Keeps the secure element surface at "sign this digest" rather than "parse JSON."
Honest note on capability
I want to flag what ATECC608 does NOT do: it doesn't support Ed25519, the IETF draft's mandatory-to-implement algorithm. The example is ECDSA P-256 for that reason. For Ed25519-native hardware, TA100 is the next step up in the same repo's device enum (though I note the TA command implementation isn't in the public repo, which I understand is by design). An Ed25519 companion example against TA100 would be a natural sibling in the future if the TA portions of cryptoauthlib become more openly contributable.
Cross-ecosystem context (in case it's useful for triage)
Receipts produced by this example are format-compatible with:
- Mission Control's signed audit logs (protect-mcp integration)
- Microsoft AGT's Cedar-based decision receipts (PR #667)
- Google ADK's BasePlugin-driven receipt signing (protect-mcp-adk on PyPI)
- Agent Passport System's governance attestations (aeoess/agent-passport-system, v2.0-beta)
All four verify at exit 0 against npx @veritasacta/verify. This ATECC608-based example would be the first hardware-signer reference in that set.
Ask
If the maintainer team confirms the three questions above (right folder, acceptable license, right scope), I'll open a PR against this repo with the C portions (app/signed_receipt/{README.md,signed_receipt.{c,h},example_main.c,Makefile}) under Microchip's standard contribution terms. The Python host companion stays in ScopeBlind/examples under MIT and the cryptoauthlib example links to it rather than vendoring.
Happy to adjust scope, split differently, or discuss the licensing question in more detail. Thanks for maintaining this library; it's the foundation layer for a meaningful chunk of secure-element-based IoT crypto.
/cc the Microchip security team if anyone's watching this queue.
Background
We're developing an open receipt format for cryptographic attestation of physical-world events (cold-chain readings, physical-AI actuator decisions, supply-chain provenance), specified at the IETF as draft-farley-acta-signed-receipts-01. The format uses Ed25519 or ECDSA P-256 over RFC 8785 JCS canonicalization, and is currently implemented by four independent software runtimes that cross-verify at exit 0 against the same reference CLI.
The receipt format is a natural fit for ATECC608 as the hardware-bound signer in sensor-side deployments, where the signing key must be non-exportable and per-device distinct. Pharma cold-chain compliance (FDA 21 CFR Part 11 electronic signatures), premium supply-chain provenance, and physical-AI governance (Microsoft's Agent Governance Toolkit PR #1168 extends this to the software side) are the initial buyer categories.
Proposal
I've prepared a reference example implementation showing the ATECC608B + JCS + ECDSA P-256 flow end-to-end: ScopeBlind/examples#1 — atecc608-ecdsa-jcs-receipt/.
I'd like to offer this to the cryptoauthlib repo as a new
app/signed_receipt/entry if the maintainers find it useful. Before opening a PR here:app/folder the right home for a teaching example of this shape? The existing entries (tng,secure_boot,ip_protection,wpc) are each a cohesive use-case.signed_receipt/would follow that pattern: one folder, one use case, a README + minimal C + sample fixtures.app/secure_boot/?What the example teaches
Cleanest breakdown between host and device:
atcab_sign_ext(oratcab_sign), returns 64-byte raw ECDSA r||s.This matches real cold-chain firmware architecture: sensor-side crypto + gateway-side assembly. Keeps the secure element surface at "sign this digest" rather than "parse JSON."
Honest note on capability
I want to flag what ATECC608 does NOT do: it doesn't support Ed25519, the IETF draft's mandatory-to-implement algorithm. The example is ECDSA P-256 for that reason. For Ed25519-native hardware, TA100 is the next step up in the same repo's device enum (though I note the TA command implementation isn't in the public repo, which I understand is by design). An Ed25519 companion example against TA100 would be a natural sibling in the future if the TA portions of cryptoauthlib become more openly contributable.
Cross-ecosystem context (in case it's useful for triage)
Receipts produced by this example are format-compatible with:
All four verify at exit 0 against
npx @veritasacta/verify. This ATECC608-based example would be the first hardware-signer reference in that set.Ask
If the maintainer team confirms the three questions above (right folder, acceptable license, right scope), I'll open a PR against this repo with the C portions (
app/signed_receipt/{README.md,signed_receipt.{c,h},example_main.c,Makefile}) under Microchip's standard contribution terms. The Python host companion stays in ScopeBlind/examples under MIT and the cryptoauthlib example links to it rather than vendoring.Happy to adjust scope, split differently, or discuss the licensing question in more detail. Thanks for maintaining this library; it's the foundation layer for a meaningful chunk of secure-element-based IoT crypto.
/cc the Microchip security team if anyone's watching this queue.