Admin Login

Create ERS Encryption Key

Generate the ERS RSA key pair before wallet install

Overview

The Emergency Recovery System (ERS) uses an RSA key pair that you control outside Institutional Vault. Policy nodes encrypt master-key backup material with the ERS public key you provide at install time. Only the holder of the matching private key can decrypt that backup later.

You must generate this key pair before wallet installation. The base64-encoded public key is supplied when you populate deployment secrets (for example ers_public_key in customer-secrets.yml on AWS installs). The private key stays offline and is used only during emergency recovery.

For what happens after install (downloading the encrypted backup and running recovery), see Emergency Recovery and Back Up Master Key.

Public key format

Institutional Vault accepts an RSA public key in PKIX / SubjectPublicKeyInfo (SPKI) DER form, supplied as a base64-encoded string.

At runtime, policy nodes decode the string and parse it as DER-encoded SPKI. The key must be RSA; other algorithms are rejected.

RequirementDetail
AlgorithmRSA
EncodingDER (SPKI / PKIX SubjectPublicKeyInfo)
Install-time valueSingle-line base64 string (no PEM headers)
Recommended key size3072 bits for new deployments
📘

Note:

PEM-wrapped public keys (-----BEGIN PUBLIC KEY-----) are not accepted in install secrets. Export DER and base64-encode the result.

Sandbox and non-production

For sandboxes, labs, and other non-production environments, generating a software RSA key pair with OpenSSL is sufficient. It is recommended to maintain a system test environment that mirrors production as closely as practical. Use that environment to validate ERS key generation, encrypted backup download, and recovery workflows before production go-live.

Generate the private key

openssl genrsa -out ers-private-key.pem 3072

Securely store the private key (ers-private-key.pem) offline in your secrets manager or vault so it remains available for the recovery process. Retain it for the life of the deployment; without the matching private key, encrypted backup material cannot be decrypted. Do not commit it to source control or place it on shared install hosts.

Derive the install-time public key

openssl rsa -in ers-private-key.pem -pubout -outform DER | base64

Copy the command output (one line, no line breaks) into your install secrets as ers_public_key.

Verify the public key (optional)

echo "<your-base64-public-key>" | base64 -d | openssl rsa -pubin -inform DER -text -noout

Confirm the output shows an RSA public key of the expected size.

⚠️

Warning:

OpenSSL file-based keys are appropriate for sandboxes and test environments only. Do not use this pattern for production mainnet or other high-value deployments.

Production and mainnet

For production, generate and protect the ERS private key using your organization's key-management standards:

  • Hardware Security Module (HSM) or cloud HSM (for example Azure Dedicated HSM, AWS CloudHSM, or equivalent)
  • Hardware security modules / smart cards with PKCS#11 support where applicable
  • Dual control, split custody, and documented key ceremonies aligned with your security policy

In production:

  1. Generate the RSA key pair inside the HSM (or import under your ceremony rules).
  2. Export only the public key in SPKI DER form, then base64-encode it for install secrets.
  3. Ensure the private key never leaves the HSM or approved offline storage.
  4. Document who can authorize use of the private key during recovery drills and real incidents.

Blockdaemon recommends following established key-ceremony guidance (for example the Crypto Valley Association Trusted Key Ceremony Guidelines) when defining production procedures.

HSM recovery and ertool

At install time you only register the public key. During disaster recovery, the matching private key decrypts the encrypted master-key backup.

Blockdaemon ships ertool, a helper CLI for offline key recovery within your Emergency Recovery System (ERS). It supports:

  • recover pem when the private key is in a PEM file (typical for sandbox keys).
  • recover p11 when the private key is protected by a PKCS#11 HSM library (typical for production).

See Emergency Recovery for the full ertool reference, command flags, HSM (recover p11) examples, and derivation-path guidance.

Provide the key at install time

During deployment secret population, set ers_public_key to the base64 SPKI DER string from the steps above. On AWS self-installed deployments, this value is written when you run make populate-secrets-* after editing customer-secrets.yml.

Policy nodes load the public key from deployment configuration before the wallet creates its master key. After the wallet is running, users download encrypted backup material that can only be opened with your ERS private key.

📘

Note:

Generate and validate the ERS key pair before creating production accounts or moving funds. Changing the ERS public key after backup material exists requires a coordinated operational change; plan the key at initial install.

Responsibilities

ItemYour responsibility
ERS RSA key pairGenerate, protect, and lifecycle-manage outside Institutional Vault
Public key at installSupply base64 SPKI DER in deployment secrets
Private keyStore offline or in HSM; use only for recovery
Encrypted backup blobDownload and store separately after first wallet backup (see Back Up Master Key)
Recovery executionRun ertool (or equivalent) on an isolated system using private key + backup blob

Anyone who holds both the ERS private key and the encrypted backup can reconstruct the wallet master key. Treat the pair with the same rigor as root custody material.

🗣️We Are Here to Help!

Please contact us via email or support chat if you encounter an issue, bug, or need assistance. Don't forget to include any relevant details about the problem. To request a wallet form and Institutional Vault Approver form, please click here or contact our sales team.