Vitrinode-HSM is a purpose-built signing device designed to hold one secret — Vitrinode's SSH user certificate authority key — on dedicated hardware, so it never sits in plaintext on the server. It is a separate project, developed alongside Vitrinode. This page describes what it is designed to do and states plainly how much of that is built.
On this page: Why hardware·What it is·What it won't do·How issuance is bounded·Threat model·Status·Beyond v1
Vitrinode's planned SSH access (Phase 8) issues short-lived OpenSSH user certificates from an internal certificate authority. If that CA's private key lives on the server, then a full server compromise is a full CA compromise — the attacker can mint certificates for any principal, for any lifetime, indefinitely.
Vitrinode-HSM moves that one key onto a dedicated device that generates it on-board, never releases it, and will only issue OpenSSH user certificates that fall inside a fixed policy — principals, validity, extensions. A compromised server can ask for a certificate; it cannot obtain the key, and it cannot obtain a certificate outside the envelope the device enforces.
Built on a Raspberry Pi Pico 2 (RP2350). It is not a general keystore or a smart card — v1 holds exactly one key, the SSH user CA, and exposes a handful of semantic operations: report identity, return the CA public key, and issue an SSH user certificate under policy. A separate provisioning workflow for persistent CA identity is in development.
The RP2350's Arm TrustZone-M is used to separate the code that touches the key from the code that talks to the host. The Secure world holds the key, re-validates every request field on its own copy, checks policy, and performs the Ed25519 signature. The Non-secure world does USB and message framing only, holds no secrets, and can reach the Secure world only through a thin, typed gateway. A memory-safety bug in the USB or parsing code cannot reach key material.
Signing, hashing and random-number generation use a pinned build of a well-known verified cryptography library (HACL). The on-die hardware RNG is run through standard health tests and conditioning before seeding an HMAC-DRBG. Consistent with the rest of the project: no invented cryptography.
The production design includes a battery-backed real-time clock inside a sealed enclosure, providing a time source independent of the host. The prototype RTC has passed hardware bring-up; trusted time is not yet implemented. Certificate validity is designed to be bounded by the time the device holds, plus a monotonic floor it will not go behind — not by whatever clock value the host sends.
The production device is designed to ship sealed, exposing only USB and a status LED — no debug header, no boot-override, no re-key path once locked. The host link is a framed binary protocol (VNHSM/1) over a USB vendor interface, one request in flight at a time.
These are permanent properties of the design. Later phases do not add them back.
The design assumes the host asking for certificates may itself be compromised, and constrains what a valid request can achieve. These mechanisms are specified; see Status for how much is implemented.
Every request is checked against a fixed policy — which principals are permitted, the maximum validity, which certificate extensions and critical options are allowed. A request outside the envelope is refused.
Certificate lifetimes are bounded by the device's own clock and a monotonic floor, so a compromised host cannot future-date a certificate or stockpile long-lived ones by lying about the current time.
Each issuance is recorded in a hash-chained log on the device, which the server reconciles against its own record — so issuance during a compromise is visible after the fact, not silent.
When Vitrinode is configured to use the HSM, there is no software fallback. If the device is missing, or its identity does not match what was recorded when it was commissioned, SSH certificate issuance stops rather than quietly falling back to a server-held key.
Stated by adversary, strongest first — this is the design's intent; see Status for how much is built. The motivating case is the middle one.
Fully in scope. The device is only reachable over local USB and only performs typed, policy-checked operations.
The case this exists for. The attacker cannot extract the key. They can request certificates, but only inside the policy envelope, rate-limited by design, and with every issuance logged on the device — and a routine CA rotation ends their access.
In scope. Debug and boot-override paths are designed to be fused off on the production device; the external flash holds only wrapped data.
Partially addressed — fault-injection hardening and silicon choice raise the cost, but a single-fault bypass is not fully excluded.
Out of scope. Physical de-capping and chip-level attacks are assumed to recover on-device secrets; this is mitigated operationally — short certificate lifetimes, routine CA rotation, and noticing a device has gone missing.
Vitrinode-HSM has completed end-to-end certificate signing and OpenSSH authentication on physical RP2350 hardware. Persistent CA storage is in development: the keystore codec has passed validation, and flash operations and CA loading across reboots have been exercised on the device. Hardware acceptance for this stage remains incomplete. Provisioning, production sealing, audit and rate limiting remain future work. Verified on hardware means run and checked on a physical device. In development means implementation has started but acceptance is incomplete. Bring-up only means the hardware responds but nothing depends on it. Not started means specified but not implemented.
| Area | Status | Detail |
|---|---|---|
| Specification | ||
| VNHSM/1 protocol specification | Frozen | Architecture and protocol frozen at revision R4. |
| Byte-level wire contract & test vectors | Frozen | Frozen Phase 2 wire contract and golden binary vectors, with a separate Phase 3 amendment and provisioning vectors for persistent CA identity. |
| Firmware — verified on real RP2350 silicon | ||
| Secure / Non-secure isolation boundary | Verified on hardware | TrustZone-M split, the typed Secure gateway, and Secure-side fault handling. |
| SSH user-CA signing core | Verified on hardware | Builds and signs a real [email protected] user certificate from typed parameters; a device-issued certificate successfully authenticated against stock OpenSSH as part of Phase 2 acceptance; an out-of-policy principal is refused and consumes no serial. |
| USB transport | Verified on hardware | Vendor-interface USB with automatic WinUSB binding on Windows. |
| VNHSM/1 end to end over USB | Verified on hardware | Report-identity, get-public-key and issue-certificate requests round-trip over the framed protocol; malformed frames are rejected without reaching the Secure gateway (2026-09-02). |
| External real-time clock | Bring-up only | The RTC part responds on the Secure bus and its oscillator advances. It is not yet a trusted time source; no security decision depends on it. |
| In development | ||
| Persistent CA key & encrypted storage | In development | Phase 3a keystore codec validation is complete. Phase 3b has exercised flash operations and loading a stored CA across boots; its acceptance gate remains incomplete. The completed Phase 2 firmware still uses a per-boot ephemeral CA. |
| Not started | ||
| Trusted time | Not started | Monotonic time floor and rollback protection. Certificate start times currently come from an untrusted host-supplied value used for development only. |
| Production provisioning, sealing & secure boot | Not started | The one-way factory-to-locked lifecycle, one-time-programmable fuse use, secure-boot policy and firmware anti-rollback. |
| Tamper-evident audit log | Not started | Current firmware has only an in-memory per-boot counter. |
| Rate limiting | Not started | Specified; not implemented. |
| Vitrinode server integration | Not started | The hsm signing mode, the host-side client, and commissioning-pin checks on the server do not exist in the Vitrinode codebase yet. |
Phase 3 uses a development storage root, not production key protection. Its encryption and authentication checks validate the storage format and device binding, but someone with the firmware and a flash dump, or debug access, can recover the CA key. Production OTP-backed storage and debug locking are later work.
Vitrinode-HSM is a separate hardware project in active development. It is not part of the deployed system, and the SSH certificate authority it is built to protect is itself still on the Vitrinode roadmap. The completed Phase 2 firmware proves the security boundary and certificate path on real silicon. Phase 3 adds persistent identity, with acceptance still in progress. The device is not sealed or integrated with a Vitrinode server. Nothing on this site should be read as a claim that Vitrinode currently uses a hardware security module.
v1 does one job so the security boundary can be proven before the design widens. Directions past it — signed device attestation and a recovery-device workflow, an SSH host CA, signed audit checkpoints, then a small multi-key store with a name-constrained device CA, and eventually server-TLS issuance — are design intent, not commitments or dates.