Validator Key Custody
Select practical key protection without weakening operational boundaries.
Validator key custody without an expensive HSM
ROKO operators can get meaningful hardware-assisted protection without a datacenter network HSM. The right device depends on which key is being protected and whether the node can ask the device to sign directly.
Key types are not interchangeable
| Material | Needed online? | Main concern |
|---|---|---|
| funding/bonding account | rarely | theft of stake/funds |
| validator session keys | while validating | unauthorized consensus actions or downtime |
| temporal/PTP² key | while advertising | false/unauthorized time announcements |
| libp2p node identity | while networking | peer identity stability/impersonation |
| disk/credential unlock | at boot/service start | offline theft of the keystore |
Keep funding/account keys offline or on a transaction-signing hardware wallet whenever the network workflow permits. Session keys and the libp2p identity have different availability and rotation requirements.
Practical protection tiers
| Option | What it can do well | Important limit |
|---|---|---|
| encrypted software keystore plus offline encrypted backup | baseline confidentiality and recovery | keys are usable in host memory while the node runs |
| TPM 2.0 plus LUKS/systemd encrypted credentials | bind disk/credential release to measured host state | not automatically a Substrate session signer |
| FIDO2/YubiKey-class token | operator MFA and LUKS/credential unlock | a security token is not automatically a direct validator HSM |
| YubiHSM 2 | PKCS#11, wrapping, attestation, compatible Ed25519/secp256k1 operations | no documented sr25519; ROKO has no documented PKCS#11 session-signer adapter |
| Nitrokey HSM 2 | low-cost PKCS#11 smart-card HSM for supported RSA/ECC schemes | no documented sr25519; integration must be implemented and tested |
| network/cloud HSM | centralized policy, audit, HA at organizational scale | cost/latency/vendor integration; optional, not a prerequisite |
ROKO/Substrate session keys use more than one cryptographic scheme, including sr25519. Vendor algorithm lists for YubiKey PIV, YubiHSM 2, and Nitrokey HSM 2 do not establish sr25519 support. The current ROKO node uses its software keystore and does not document a PKCS#11 session signer.
Therefore:
- do not claim that these devices keep every validator session key permanently
inside hardware;
- use them today for operator authentication, encrypted-volume/credential
unlock, backup wrapping, compatible account keys, and other supported roles;
- claim direct in-device session signing only after a signer adapter and every
required key scheme pass integration, restart, throughput, failover, and rotation tests.
“Hardware unlocks an encrypted software keystore” is valuable, but it is not the same as “the private signing key never leaves hardware.”
A sensible low-cost design
1. Enable secure boot and a TPM 2.0 when the host supports them. 2. Put chain identities/keystore on encrypted storage. 3. Bind unattended unlock to a reviewed TPM policy, or require a FIDO2 token when attended recovery is acceptable. 4. Keep a second enrolled unlock/recovery method offline and physically separate. 5. Store funding keys on a separate hardware wallet/offline signer. 6. Restrict USB devices with physical controls or allowlisting. A USB port is also an attack surface. 7. Back up encrypted key material and test restoration on an isolated host. 8. Rotate by activating a replacement before retiring the old key.
Never make a single USB device, TPM-bound blob, motherboard, or passphrase the only recovery path.
Secret handling
- Do not pass seed phrases or node keys as command-line flags.
- Do not put them in environment variables captured by service managers,
diagnostics, or crash reports.
- Prefer an interactive prompt, restricted credential file, encrypted systemd
credential, or local signer API.
- Decrypt only at service start into a root/service-readable runtime location,
not a persistent world-readable file.
- Disable local unsafe key-management RPC after provisioning.
- Sanitize support bundles and monitoring labels.