SOVEX
CBDC Data Centers Sovereign AI Tokenization Deep Tech Architecture About Team Request access
Security & Post-Quantum / Key custody / HSM-backed keys

HSM-backed keys.

Private keys live and sign inside certified hardware and never appear in application memory. The owner's authority is defended by silicon, not by software discipline.

Keys are born in hardware and never leave it in the clear

A hardware security module is the physical container for the owner's signing authority.

01

On-device generation

Signing keys are generated by the HSM's internal entropy source and marked non-exportable, so no plaintext private key ever exists outside the module.

02

In-module signing

The application sends the digest to be signed into the HSM and receives a signature back; the private key never crosses into host memory, disk, or logs.

03

Tamper response

Physical intrusion, temperature, or voltage attacks trigger the module's tamper response, zeroizing sensitive material before it can be extracted.

04

Post-quantum in hardware

ML-DSA-65 signing is anchored in the HSM so the owner's quantum-resistant root benefits from the same hardware isolation as classical keys.

Using a key requires authenticated, quorum-based authorization

Possession of the module is not possession of the authority to sign.

01

M-of-N activation

Bringing a key into a usable state requires a quorum of authorized custodians presenting their factors, so no single administrator can wield the root alone.

02

Role separation

Security-officer, custodian, and operator roles are distinct, so the people who administer the module are not the same people who authorize its use.

03

Per-key policy

Each key carries usage policy — permitted operations, quorum, and rate — enforced by the module itself rather than by the calling application.

04

Session binding

Signing sessions are authenticated and short-lived, and the module drops back to a locked state so a captured session cannot be replayed indefinitely.

HSMs are deployed as a resilient, in-nation cluster

Hardware custody is engineered for availability without compromising isolation.

01

Clustered modules

Signing is served by a cluster of modules so the loss of one unit does not halt issuance, settlement, or weight release.

02

In-nation placement

Modules sit inside sovereign data centers, keeping key material physically within the owner's jurisdiction and residency requirements.

03

Secure replication

Where keys must exist on more than one module, they are replicated only as wrapped material under the cluster's protection, never as exportable plaintext.

04

Offline root tier

The highest-authority root can be held in an offline module and brought online only for ceremonies, minimizing its exposure surface between uses.

The rails talk to hardware through a narrow, auditable interface

Every signature the platform relies on ultimately originates in a module.

01

Standard interfaces

The platform integrates with modules over standard cryptographic interfaces, so owners can bring qualified hardware from their approved vendors.

02

Digest-only exposure

The service hands the HSM only the hash to be signed, never the private key, keeping the attack surface to a single well-defined call.

03

Ledger-anchored signing

Hardware-produced signatures are what get appended to the hash-chained ledger, so the tamper-evident record is rooted in hardware, not host software.

04

DvP settlement signing

Atomic delivery-versus-payment settlements require signatures from the relevant parties' modules, so no leg of a trade commits without hardware-held consent.

Keys are provisioned, rotated, and retired under recorded control

Hardware custody covers the full life of a key, not just its use.

01

Ceremony-based provisioning

Key creation follows a scripted, witnessed ceremony with recorded quorum, producing an auditable origin for every root.

02

Rotation without disruption

New keys can be provisioned and certified while old ones remain valid, allowing rotation without breaking in-flight settlement or issuance.

03

Verifiable destruction

Retiring a key means zeroizing it inside the module and recording the event, so decommissioning is provable rather than assumed.

04

Firmware attestation

Module firmware and configuration can be attested so operators can confirm the hardware serving signatures is in a known, approved state.

Build it sovereign.

Talk to us about hsm-backed keys in a sovereign deployment.