Sovereign hardware roots of trust,
on open silicon
RISC-V, post-quantum cryptography, and designs built to be audited.
A hardware root of trust does four things
- Passport. Proves the device is genuine — not a clone, not a swapped board.
- Bouncer. Checks the software before it runs. Wrong signature, the system does not start.
- Safe. Designed to keep keys inside a protected hardware boundary, with resistance to software, fault and physical attack.
- Notary. Signs a statement about what the machine is running, so someone far away can verify it.
Everything above it depends on it being correct — and little else in the system is positioned to check it.
The questions with no settled answer
The interesting part is not what a root of trust does. It is what nobody has agreed on:
- How do you build a monitor that watches a system without becoming part of what must be trusted?
- How do you compose one proof from devices with no reason to trust each other?
- What belongs in fixed logic, and what in firmware? Tape-out freezes the answer.
- How much die area is side-channel resistance worth?
- How do you design something an evaluator can reason about, rather than something that passes tests?
We have opinions on all five. They are why the part looks the way it does.
What we build on
SHAKTI, the RISC-V core from IIT Madras · Tock, a memory-safe embedded OS in Rust · an open root-of-trust silicon foundation · an open post-quantum engine · ML-DSA and ML-KEM · SPDM, DICE, TPM 2.0.
Where the line sits. Open and auditable by anyone: the core, the OS, the cryptographic foundations, and every contribution we make upstream. Ours and deliberately unpublished: the product architecture, the security subsystems we add, the threat model, and the certification evidence. A closed die asks a buyer to trust a vendor; this lets them verify.
Verified in software. Moving to silicon.
Key security properties formally verified. Functional regressions passing in simulation and emulation. Synthesises onto the prototype platform with margin, and prototype bring-up is under way. We are pre-silicon; the detailed schedule is shared under NDA.
Five patches merged upstream
Tock, the SHAKTI C-Class, the PULP platform. Commits in the open, reviewed by maintainers who owe us nothing — every row links to the upstream project’s own repository.
GitHubGitLabOperating systems — Tock OS
| Contribution | Upstream | Status |
|---|---|---|
| RV64 userspace CI test | PR #4880 | MERGED |
| Enable switch_to_process on RV64 | PR #4878 | MERGED |
| running_thread_id() for RV64 | PR #4871 | MERGED |
| RV64 CSR compilation fix | PR #4865 | MERGED |
| SHAKTI C-Class board supportA board and chip crate so Tock runs on the SHAKTI C-Class, an Indian open-source RISC-V core. | PR #5051 | IN REVIEW · CI PASSING |
| 64-bit syscall ABI specification (TRD)Contributed implementation findings and review that shaped the final design, including an explicit address-carrying return type. | PR #4906 | OPEN · 2 APPROVALS |
RISC-V processors — SHAKTI C-Class (IIT Madras)
| Contribution | Upstream | Status |
|---|---|---|
| PMP specification compliance + Smepmp/ePMP | MR !87 | OPEN |
| dcsr.stepie single-step defectReported with reproduction and a one-term fix; implemented upstream by a SHAKTI maintainer. | Report #301 · Fix !231 | ADOPTED |
| RV64 >8 PMP entries fail to build | Issue #7 | OPEN |
| Smepmp core threading | MR !229 | DRAFT |
| Debug-subsystem findings | #298 · #299 · #300 | OPEN |
| CLINT 64-bit timer read | Issue #139 | OPEN |