For the latest version, please use Key Management System 3.12.0!

System Description

Fix refs , omit completely due to similarities?

Architecture overview

The following figure gives an abstract overview about the software components of the KMS platform and their communication among each other.

For simplification purposes, the overview only shows aspects which are necessary for the understanding of the topic covered by this manual.

Figure 1. Abstract system overview

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 this key material. 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. Each tenant works in his own area and cannot access the key material of another tenant.

To secure the key material, it is always stored in encrypted form in the KMS database. To encrypt and decrypt this 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, each tenant uses his own KEK to encrypt his 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 section Tenant-HSM-Profiles).

The KMS platform offers the KMS-Tenant operator the possibility to carry out administrative work in his own tenant area via the KMS-Tenant (see [User-Manual]). This includes in particular 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 (see [User-Manual]). These tasks are the responsibility of KMS-Admins.

MTG KMS has the following users/roles

Table 1. MTG KMS roles
User	Description
KMS-Admin	The KMS-Admin is responsible for the general management of the MTG KMS platform. Tasks of the KMS-Admin: Manage admin accounts (e.g. add or delete accounts, change own password) Add and configure new tenants Link HSM-Profile for tenants 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. Certain critical tasks must be carried out using a two-man rule (see chapter Authentication and security concepts).
KMS-Tenant	The tenant are responsible for managing their own tenant configuration. Tasks of the KMS-Tenant: Managing Tenant User accounts Managing and generate KEKs Configure new clients 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. Certain critical tasks apply the 4-eye principle (see chapter Authentication and security concepts).
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:

Table 2. Interfaces provided by MTG KMS
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-Webservice (KMIP-API)	The KMS-Webservices are accessed by registered KMS-Tenant-Client users, i.e. the tenant’s applications. Client authentication is performed by Basic-Authentication.

Table 2 lists the most important interfaces needed to understand the topic covered in this manual.

Authentication and security concepts

Access to the KMS-Admin

Access to the KMS 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).

Managing “dual control” orders

Some security-relevant actions require “dual control” (aka. “4-eyes” or “two-man rule”) by at least two KMS-Admins. Examples for such actions are adding/deleting KMS-Admins or deleting a tenant.

“Dual control” orders are entered by the first administrator and stored as a proposal (aka open KMS order). These proposals are shown to the other administrators and can be accepted (voted for) or rejected by the second administrator. Dual control orders require at least two administrators or operators to be created/predefined when the system is commissioned respectively installed.

The following actions can be performed for a proposal:

List of open/uncompleted "dual control" orders (proposals).
Display and edit, accept, reject, complete or postpone an order.
Edit, delete or retract your own proposals that has not yet been completed.

By default, a proposal requires two votes to fulfil the requirements of the dual control principle. The processing of proposals is the subject of chapter [p-kms-adm-05].

Tenant-HSM-Profiles

HSM-Profiles are used to store the tenant’s HSM credentials AES-encrypted in the KMS database. These access data are 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 management operations require the dual control principle and must be requested and confirmed by multiple (usually two) operators via a voting system. See chapter Managing “dual control” orders for details.

"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.