| Crates.io | cosmian_kms_server |
| lib.rs | cosmian_kms_server |
| version | 5.9.0 |
| created_at | 2025-05-09 06:30:41.966381+00 |
| updated_at | 2025-09-15 16:12:02.208268+00 |
| description | Cosmian Key Management Service |
| homepage | |
| repository | https://github.com/Cosmian/kms |
| max_upload_size | |
| id | 1666288 |
| size | 1,711,288 |
The KMS Server is the main component of the Cosmian Key Management System, providing secure key management, cryptographic operations, and KMIP protocol support.
The KMS server is a high-performance, FIPS 140-3 compliant server application that provides comprehensive key management services. It supports multiple database backends, HSM integration, and offers both REST API and KMIP protocol interfaces.
The KMS server provides several features which can be enabled at compilation time:
| Feature | Description | Development | Production |
|---|---|---|---|
non-fips |
Enable non-FIPS cryptographic algorithms and features | ✅ | |
insecure |
Disable authentication and use HTTP (development only) | ✅ | |
timeout |
Binary stops after 3 months from compilation date |
Legend: ✅ = Recommended for this environment
For development, you can use --features insecure to disable authentication and HTTPS:
cargo build --features insecure
cargo run --features insecure --
This configuration:
Enable additional cryptographic algorithms:
cargo build --features non-fips
cargo run --features non-fips
Create a time-limited binary (stops after 3 months):
cargo build --features timeout
The server configuration can be provided through multiple methods (in order of precedence):
.env file at the location where you start the binaryThe list of parameters, which depends on the compiled features, can be obtained by doing:
cosmian_kms_server -h
A server for development can be quickly run as follow (with sqlite):
cargo run
The KMS server relies on an OAuth2 authentication provided by Auth0 to authenticate the user.
Example of how to run for test authentication:
KMS_JWT_ISSUER_URI="demo-kms.eu.auth0.com" cargo run
This authentication enables the KMS to deal with several users with the same database.
If there is no KMS_JWT_ISSUER_URI provided, the KMS disables the authentication. Only one user is allowed.
If so, admin will be the user id.
The database is made up of two tables: objects et read_access.
objects tableThis table is designed to contain the kmip objects. A row is described as:
id which is the index of the kmip object. This value is known by a user and used to retrieve any stored objectsobject is the object itselfstate could be PreActive, Active, Deactivated, Compromised, Destroyed or Destroyed_Compromisedowner is the external id (email) of the user the object belongs toread_access tableObject's owner can allow any other user to perform actions on a given object.
This table describes those actions a specific user is allowed to perform onto the object:
id which is the internal id of the kmip objectuserid which is the external id of the user: its email addresspermissions is a serialized JSON list containing one or more of the following flags: Create, Get, Encrypt, Decrypt, Import, Revoke, Locate, Rekey, Destroy defining the operation kinds the user is grantedThe userid field will be used to check authorization by matching the email address contained in the authorization JWT.