|
For the latest version, please use Key Management System 3.12.0! |
System Description
Architecture overview
The following is an abstract overview about the software components of the KMS platform and their communication with each other. Shown here are aspects which are necessary for the understanding of the topic covered in this page.
The main task of the KMS platform is the secure management of key material for tenants in a secure environment. This includes the safe production and storage of key material and the provision of strictly controlled access to it. A KMS tenant is a logical KMS instance, for example the Production-Site or a HES/MDM system. There can be multiple tenants on a KMS. Tenants work in their own area and cannot access the key material of other tenants.
To secure the key material, it is always stored in encrypted form in the KMS database. To encrypt and decrypt the key material, a so-called KEK (key encryption key) is used, which acts as the master key for securing the tenant’s key material in the KMS database. For security reasons, tenants uses their own KEK to encrypt their key material. This guarantees a safe separation of the different tenant areas and ensures that the individual tenants always work within their own scope. Due to the high security requirements for the KEK, it is stored and managed in the secure environment of an HSM. Only the main KMS component communicates with the HSM directly.
| The HSM access data required for the usage or management of KEKs are stored in a so-called HSM-Profile (see Tenant-HSM-Profiles). |
The KMS platform offers the KMS-Tenant operators the possibility to carry out administrative work in their own tenant area via the KMS-Tenant. This includes the generation of KEKs as well as the configuration of KMS-Tenant-Clients. These KMS-Tenant-Clients are intended to communicate with the KMS-Webservices and use the offered (cryptographic) functionalities. The execution of these functions requires the reconstruction (decryption) of the tenant’s key material with the help of the KEK. This process is performed automatically by KMS and is completely transparent for the KMS-Tenant-Client.
In addition to the KMS-Tenant, the KMS platform offers a KMS-Admin for general system configurations tasks such as creating tenants. These tasks are the responsibility of KMS-Admins.
MTG KMS has the following users/roles
| User | Description |
|---|---|
KMS-Admin |
The KMS-Admin is responsible for the general management of the MTG KMS platform. Tasks of the KMS-Admin:
Furthermore, it is the responsibility of the admin to distribute credentials (i.e. credentials of a newly created tenant) to the responsible persons in a secure and confidential manner. |
KMS-Tenant |
Tenants are responsible for managing their own tenant configuration. Tasks of the KMS-Tenant:
Furthermore, it is the responsibility of the operator to distribute credentials (i.e. credentials of a newly created admin account) to the responsible persons in a secure and confidential manner. |
KMS-Tenant-Client |
KMS-Tenant-Clients are applications which accesses the KMS-Webservices on behalf of the tenant and perform cryptographic operations offered by the Webservices. |
HSM-Admin |
Administrators responsible for managing the HSM using the utilities provided by the HSM manufacturer. |
| Table 1 lists the most important roles needed to understand the topic covered in this manual. |
MTG KMS provides the following interfaces:
| User | Description |
|---|---|
KMS-Admin |
The KMS-Admin is the web interface used by the KMS-Admin for general management of the MTG KMS platform. |
KMS-Tenant |
The KMS-Tenant is the web interface used by the KMS-Tenant operator for managing the tenant’s own configuration. |
KMS-Crypto-API (KMIP-API) |
The KMS-Crypto-API is accessed by registered KMS-Tenant-Client users, i.e. the tenant’s applications. Client authentication is performed by jwt amd Keycloak. |
| Table 2 lists the most important interfaces needed to understand the topic covered in this page. |
Authentication and security concepts
Access to the KMS-Admin
Access to the KMS-Admin interfaces is only permitted after successful authentication. The authorization for the KMS-Admin is done via the login data of a KMS-Admin (UserID/Password).
Access to the KMS-Tenant
Access to the KMS-Tenant interfaces is only permitted after successful authentication. The authorization for the KMS-Tenant is done via the login data of a KMS-Tenant user (UserID/Password).
Access to the KMS-Crypto
Access to the KMS-Crypto interfaces is only permitted after successful authentication. The authorization for the KMS-Tenant-Client is done via the login data of a KMS-Tenant-Client user (UserID/Password).
Tenant-HSM-Profiles
HSM-Profiles are used to store the tenant’s HSM credentials AES-encrypted in the KMS database. This access data is required to manage and use the KEKs (Key-Encryption-Keys), which are stored on the HSM and are required to encrypt and decrypt the tenant’s KMS key material. KMS differentiates between two different HSM user types, the "key management" user type and the "key usage" user type:
-
"key management" user: The login as "key management" user is required to perform a key management operation (e.g. create or delete a KEK) on the HSM.
-
"key usage" user: The login as "key usage" user is needed when an existing KEK on the HSM shall be used (e.g. to encrypt or decrypt tenant’s key material stored in the KMS database). This is the case, for example, when a KMS-Tenant-Client uses the KMS-Webservices to perform cryptographic operations. The managed object’s key material must first be decrypted using the tenant’s KEK. For the tenant client, this process is completely transparent, in particular the decryption of the AES-encrypted HSM credentials of the "key-usage" user stored within the HSM-Profile.
The "key management" user and the "key usage" user must first be created for the HSM by the HSM-Admin and specified by the KMS-Admin when the HSM-Profile is created.