Backend Key Storage
This page explains how Wultra backend components keep their long-term signing keys in the keystore’s HSM instead of in their own databases.
This is the target design; the /v1/backend endpoints are not implemented yet.
Today, PowerAuth Server keeps its long-term private keys in its database, encrypted under a database master key, and diw-gateway keeps its keys as JKS blobs. Both decrypt the keys into memory to sign. All these keys should be stored in an HSM instead.
With the keystore, the keys are generated and used only inside the HSM. A backend component keeps only a key id (for a resident key) or a wrapped key, and receives signatures. The API (/v1/backend/...) is generic: a component names a domain, a key type and the data to sign. Nothing in it is specific to PowerAuth or EUDI.
Keys Moved to the HSM
| Component | Key | Algorithm | Storage mode | Domain |
|---|---|---|---|---|
| PowerAuth Server | v4 application master keys, one set per application | EC P-384, ML-DSA-65, ML-DSA-87 | resident | powerauth-master-ecdsa, powerauth-master-mldsa |
| PowerAuth Server | v4 activation server keys, one set per activation | EC P-384, plus ML-DSA-65 or ML-DSA-87 when hybrid | wrapped, owned by the activation id | powerauth-activation-ecdsa, powerauth-activation-mldsa |
diw-issuer |
credential-signing key, access-certificate key | EC P-256 | resident | diw-issuer-ecdsa |
diw-connector |
access-token signing key | EC P-256 | resident | diw-connector-ecdsa |
diw-verifier |
relying-party-instance keys (access, registration) | EC P-256 | resident | diw-verifier-ecdsa |
What Stays in Software
Two kinds of keys stay in software:
- Short-lived keys, such as temporary keys and per-transaction decryption keys.
- Symmetric secrets, such as activation shared secrets and the factor keys derived from them, application and token secrets, and database master keys.
Only long-term private keys used for signing move into the HSM.
API Summary
| Action | Method | Path | Storage mode |
|---|---|---|---|
| Create a key | POST | /v1/backend/keys |
resident or wrapped |
| Read a key | GET | /v1/backend/keys/{keyId} |
resident |
| Revoke a key | POST | /v1/backend/keys/{keyId}/revocation |
resident |
| Sign 1 to 4 signing inputs | POST | /v1/backend/signatures |
resident or wrapped |
Details: Backend Keys API.
PowerAuth Server Integration
The HSM integration is enabled per PowerAuth Server deployment. PowerAuth Server then creates its v4 keys through POST /v1/backend/keys and signs through POST /v1/backend/signatures, instead of storing private keys in its database.
- Master keys (per application) are resident. The database keeps only their key ids and public keys.
- Activation server keys (per activation) are generated in the HSM and stored wrapped by PowerAuth Server.
- Hybrid signatures (ES384 and ML-DSA) are supported.
- Existing keys created before the integration stay in software.
diw-gateway Integration
These diw-gateway keys are resident:
diw-issuer: the credential-signing key (SD-JWT VC) and the access-certificate key (signed metadata);diw-connector: the access-token key;diw-verifier: the relying-party keys (request objects, certificate signing requests).
The three services sign their JWS and certificates through the keystore’s Backend Keys API.