Quarc
A secure element built for the post-quantum era.
An open, auditable post-quantum secure element — ML-KEM-768 and ML-DSA-65 on RISC-V, built entirely with open-source tooling.
Every SE shipping today will be broken by quantum computers.
Every Secure Element shipping today relies entirely on classical cryptography — ECC, RSA, AES. Shor's algorithm on a cryptographically relevant quantum computer breaks all of them. NIST finalised post-quantum standards in 2024 (FIPS 203, 204, 205). Regulators in the EU, US and Germany project mandatory PQC adoption in critical infrastructure by 2030.
The IoT devices being deployed today will outlive that window. Quarc closes the gap — ML-KEM-768 and ML-DSA-65 packaged with the full SE feature set IoT silicon vendors expect.
| Classical SE today | Quarc | |
|---|---|---|
| PQC hardware accelerator | None | ML-KEM-768 + ML-DSA-65 |
| Hybrid PQC + classical | No | Yes (v1) |
| Open auditable toolchain | No | Yes — Yosys / nextpnr |
| HDL transparency | Vendor-locked | Verilog 2005 + sv2v |
| Migration path to ASIC | Locked | No RTL rewrite |
| TEE root-of-trust roadmap | No | Yes (v3) |
An FPGA prototype, in two steps.
The full hardware crypto path exceeds current FPGAs, so Quarc v1 splits the work: algorithms in C on a 23k-LE fabric today, crypto controllers back in fabric on the 84k-LE board next.
BeagleV-Fire
Microchip PolarFire MPFS025T · 23k LE
Cape gateware built and flashed; SHA-3 and forward/inverse NTT verified on silicon. ML-KEM-768 runs in C over the SHA-3 + NTT MMIO engines. NTT basemul timing closure is the open blocker.
ULX3S
Lattice ECP5-85K · 84k LUT
Moves the ML-KEM/ML-DSA controllers, KUE, keystore and SPI slave into fabric so the C layer becomes a thin driver. The bitstream builds at 27 MHz.
Built for quantum-safe trust.
Post-quantum cryptography, hardware-enforced key isolation, and open hardware in one auditable secure element.
ML-KEM-768 and ML-DSA-65 (FIPS 203/204) share one constant-time NTT core and Keccak engine, targeting ≥ 3× software PQC on Cortex-M4. Step 1 runs the algorithms in C over MMIO; Step 2 moves them into fabric.
Per-slot policy bits — SIGN_ONLY, DECAP_ONLY, NO_EXPORT, NO_OVERWRITE — enforced in RTL, not software. Key bytes DMA straight into engine registers and never appear on the bus.
An immutable Boot ROM verifies firmware with ML-DSA-65 against a hardware monotonic counter and halts on failure. The rollback counter RTL is in place; secure boot is a Phase 8 deliverable.
Noise Protocol IK over SPI with a hybrid ML-KEM-768 + X25519 key exchange and AES-256-GCM payload encryption. Part of the Phase 7 security stack.
100% open-source toolchain — Yosys, nextpnr, SymbiYosys — and Verilog 2005 only. Formal verification targets cover the bus, Keccak, TRNG health, PMP, KUE policy, and lifecycle FSM.
No FPGA-specific primitives in core logic, so the same RTL ports to 40 nm / 22 nm FD-SOI. v2 targets a Common Criteria EAL4+ path and FIPS 140-3 Level 3.
Crypto-first. CPU-second.
Ibex orchestrates. It does not do crypto. Every heavy operation runs in a dedicated, constant-time hardware accelerator.
Provision. Verify. Trust.
Provision identities
Generate post-quantum keys into isolated hardware-backed storage. Set KUE policy bits per slot — SIGN_ONLY, DECAP_ONLY, NO_EXPORT. Set once, enforced by hardware.
Establish secure channels
Any host MCU connects over SPI. The Noise IK channel opens with a hybrid ML-KEM-768 + X25519 key exchange, giving forward secrecy from the first byte.
Anchor trust at runtime
Verify firmware, sign messages, and decapsulate keys through the encrypted SPI channel. Every operation enforced by the KUE — the CPU never holds key bytes.
Hardware beats software. By a wide margin.
Target performance at 50 MHz on ECP5-85K (Step 2) vs pqm4 on Cortex-M4 at 168 MHz. The current ULX3S bitstream closes at 27 MHz; 50 MHz is the goal once NTT basemul timing is closed.
| Operation | Quarc target | pqm4 · M4 @ 168 MHz | Speed-up |
|---|---|---|---|
| ML-KEM-768 KeyGen | < 0.5 ms | ~1.5 ms | ≥ 3× |
| ML-KEM-768 Encaps | < 0.5 ms | ~1.7 ms | ≥ 3× |
| ML-KEM-768 Decaps | < 0.5 ms | ~1.8 ms | ≥ 3× |
| ML-DSA-65 KeyGen | < 2 ms | ~6 ms | ≥ 3× |
| ML-DSA-65 Sign | < 5 ms | ~12 ms | ≥ 2× |
| ML-DSA-65 Verify | < 2 ms | ~5 ms | ≥ 2× |
Hardware enforces. Firmware orchestrates.
Quarc assumes firmware can fail: security-critical guarantees are enforced directly in RTL rather than in software. The key-store/KUE boundary and host channel land with the Step 2 fabric, and the formal proofs are a Phase 6 deliverable.
Key Usage Enforcer (KUE)
Per-slot policy bits set at provisioning, enforced by hardware on every operation.
| Policy bit | Meaning |
|---|---|
SIGN_ONLY | Slot usable only for ML-DSA signing |
DECAP_ONLY | Slot usable only for ML-KEM decapsulation |
NO_EXPORT | Key bytes never leave the key store |
NO_OVERWRITE | Slot cannot be re-provisioned |
COUNTER_LIMIT | Use-count cap — operation blocked when reached |
Device lifecycle
State transitions are one-way and irreversible. The FSM is implemented in RTL — no firmware path can return to an earlier state.
Every SPI command is permission-gated against the current state.
Where quantum-safe trust matters.
IoT Root of Trust
Quantum-safe device identity, signed OTA updates, secure boot with rollback protection, and fleet attestation.
Industrial & Infrastructure
Energy, transport, and water systems — long-lived devices that will outlive the classical PKI window.
Automotive & V2X
ML-DSA-signed messages, attested firmware, and quantum-safe key provisioning across the OEM supply chain.
Confidential Computing
PQC attestation reports and sealing keys for confidential VMs — anchoring post-quantum trust in cloud and edge platforms.
Built for the next decade of secure computing.
- Step 1 — BeagleV-Fire, crypto in C over SHA-3 + NTT
- Step 2 — ULX3S, ML-KEM/ML-DSA/KUE/keystore/SPI in fabric
- ML-KEM-768 + ML-DSA-65 (FIPS 203/204)
- Key Usage Enforcer (KUE) — RTL
- Device lifecycle FSM (RTL)
- Anti-rollback secure boot
- Noise IK encrypted SPI channel
- 100% open-source toolchain
- Silicon PUF — hardware-rooted identity
- Real OTP / NVM for persistent key storage
- Active tamper detection (voltage, temperature, light, EMP)
- Boolean-masked NTT for side-channel resistance
- SLH-DSA (FIPS 205) hash-based signatures
- Common Criteria EAL4+ certification path
- FIPS 140-3 Level 3
- PQC attestation reports for confidential computing
- Sealing keys bound to firmware measurement
- Quantum-safe key migration between devices
- PCIe or I3C platform interface
- Targets: AMD SEV-SNP · Intel TDX · Arm CCA
Common questions.
What is a post-quantum secure element?
A secure element designed to resist attacks from future quantum computers. Classical SE cryptography — ECC and RSA — is broken by Shor's algorithm on a cryptographically relevant quantum computer. Quarc replaces those with NIST-standardised ML-KEM (FIPS 203) and ML-DSA (FIPS 204) running in dedicated hardware accelerators.
How does the Key Usage Enforcer work?
The KUE is a small RTL policy engine between the key store and the crypto engines. Per-slot policy bits (SIGN_ONLY, DECAP_ONLY, NO_EXPORT, NO_OVERWRITE, COUNTER_LIMIT) are set at provisioning and enforced by hardware on every operation. Key bytes DMA directly into engine registers — they never appear on the main bus. A firmware call requesting DSA_SIGN on a DECAP_ONLY slot is rejected by RTL, not software.
What does 100% open toolchain mean?
Every byte of the Quarc bitstream is produced by open-source tools: Yosys for synthesis, nextpnr-ecp5 for place-and-route, sv2v for Ibex SystemVerilog conversion, SymbiYosys for formal verification, and Icarus Verilog / Verilator for simulation. No proprietary EDA in the synthesis path. The bitstream is reproducible from the published RTL.
What is the current status of Quarc?
Quarc v1 is an FPGA prototype, not production silicon. Phase 1 (Keccak/SHA-3) and Phase 2 (TRNG/DRBG) are verified, including on silicon; the shared NTT engine is sim-verified with basemul timing closure still open; and ML-KEM-768 passes the full NIST KAT on the software path. ML-DSA, the security-policy formal proofs, the Noise IK channel, and secure boot are not started. The full hardware crypto path exceeds both target FPGAs, so v1 is built as a two-step partition.
Is Quarc production silicon?
No. Quarc v1 is an FPGA prototype built in two steps: Step 1 runs on the BeagleV-Fire (PolarFire MPFS025T, 23k LE) with the algorithms in C over SHA-3 + NTT MMIO engines, and Step 2 moves ML-KEM, ML-DSA, the KUE, keystore and SPI slave back into fabric on the ULX3S (ECP5-85K). The v2 roadmap targets an ASIC at 40 nm or 22 nm FD-SOI with no RTL rewrite, and v3 extends to a TEE root of trust for confidential computing.
Can Quarc integrate with existing MCUs?
Yes. Any host MCU — STM32, ESP32, or your own — drives Quarc over SPI. On the BeagleV-Fire the SE is driven by the SoC's own RISC-V cores over an AXI/SPI bridge, replacing the external host of the ULX3S setup. From the host's perspective, Quarc is an SPI peripheral that handles all post-quantum cryptography.
Why does post-quantum security matter now?
Devices deployed today may still be operating when quantum attacks become practical. NIST finalised PQC standards in 2024. EU and US regulators project mandatory PQC adoption in critical infrastructure by 2030. Quarc closes the gap so devices deployed today aren't vulnerable at end-of-life.
Prepare your systems for the post-quantum decade.
Open, auditable, hardware-enforced trust for next-generation connected systems. Talk to us about evaluation kits, ASIC partnerships, and OEM silicon programmes.