Requirements for a KMS
The BSI Requirements Catalog for Key Management Software (KMS) defines the mandatory and recommended security functions that a KMS must implement in order to be considered suitable for protecting classified information (up to VS-NfD). It covers aspects such as cryptography, key handling, authentication, access control, logging, updates, and system integrity.
The following table provides a comparison between the BSI requirements and the current implementation state of the Securosys Key Manager UI. It indicates whether each requirement is fully met (🟩), partially supported (🟨), or not applicable (🟥).
| Requirement (BSI) | Description | Securosys Key Manager UI |
|---|---|---|
| Anf.Crypto | Only BSI-approved algorithms; correct implementation; crypto-agility recommended. | 🟩 Uses HSM crypto (FIPS-certified, BSI algorithms available) |
| Anf.Keys | Key lifecycle: generate, import, export, distribute, renew, revoke, delete; no plaintext storage outside HSM. | 🟨 Functionality supported via UI (except revoke, or activation / deletion time) |
| Anf.Certificates | Use of X.509/CVC according to TR-02103/TR-03110; verify signatures/validity. | 🟨 Certificate management integrated, validation of certificate path not available |
| Anf.Authentication | Authentication of all roles; reaction to failed attempts (lockout, alarm); re-authentication for long uptime. | 🟨 User login with roles (read/write, not the roles BSI specifies) + HSM policies (4 hour session rollover, failed login attempt, block user); |
| Anf.Updates | Secure update mechanism; authenticity/integrity checks; patching concept. | 🟨 Updates by pulling a new Docker container image. Image signing and verification possible but not implemented. |
| Anf.Logging | Audit logging of security-relevant events (auth, self-tests, changes, key ops). | 🟩 Event logs available (HSM + UI); export possible |
| Anf.Selftests | Startup and runtime self-tests of security functions; safe state on failure. | 🟨 HSM runs self-tests; UI does not display status |
| Anf.Residual | Cryptographic deletion of sensitive objects, including in virtual environments. | 🟩 Guaranteed by HSM hardware mechanisms |
| Anf.Password | Strong password policies; secure storage (hashing). | 🟥 UI password policy not configurable; hashing not implemented in the UI |
| Anf.RoleConcept | Roles: Operator, Auditor, Administrator; no overlapping roles allowed. | 🟨 REST API provides these roles, Identity Provider Integration does not enforce group & roles (single group can be configured) |
| Anf.TwoFactorAuthentication | 2FA (e.g., smart card + PIN), at least one hardware-based factor. | 🟥 Currently username/password; 2FA not possible |
| Anf.StorageEncryption | Keys stored in HW-SiA/HSM or key hierarchy; backups encrypted. | 🟩 Fully implemented by HSM |
| Anf.UsePlatform | Use platform security features (RNG, secure time source, HW-SiA). | 🟩 Uses HSM RNG & secure time |
| Anf.Random | RNG according to BSI AIS 20/31 (PTG.3/DRG.4). | 🟩 HSM RNG certified |
| Anf.MaintainIntegerKMS | Integrity protection, platform hardening, self-tests. | 🟨 HSM checks in place, UI Checks not in place. |
| Anf.Communication | Secure channels with mutual authentication; TLS. | 🟥 TLS/HTTPS, mutual authentication via REST API possible, currently not supported in the UI |
| Anf.AccessControl | Role-based access control (RBAC), tenant separation, optional four-eyes principle. | 🟨 Roles & policies available in HSM & Rest API, not in UI (LDAP) |
| Anf.Management | Admin functions (installation, configuration, backups, accounts). | 🟩 Supported via Identity Provider Integration. Keystore backups can be taken on HSM. |