Cosmian KMS

The Cosmian KMS is a high-performance, source-available FIPS 140-3 compliant server application written in Rust.

Online documentation.

Built-in Web UI for administration and operations.

The Cosmian KMS presents some unique features, such as:

• large-scale encryption, decryption of data see this documentation
• support for signature at scale, including the Bitcoin curve secp256k1 (non-FIPS mode)
• the ability to confidentially run in a public cloud, or any zero-trust environment, using Cosmian VM. See our cloud-ready confidential KMS on the Azure, GCP, and AWS marketplaces our deployment guide
• support of state-of-the-art authentication mechanisms (see authentication)
• out-of-the-box support of Google Workspace Client Side Encryption (CSE)
• out-of-the-box support of Microsoft Double Key Encryption (DKE)
• out-of-the-box support of AWS External Key Store (XKS) v2 — Cosmian KMS acts as an XKS proxy; key material never enters AWS
• out-of-the-box support of Azure External Key Manager (EKM) — Cosmian KMS acts as an Azure EKM proxy with mTLS authentication
• out-of-the-box support of Microsoft SQL Server External (EKM) — Cosmian KMS acts as a SQL Server EKM provider backend over mutual TLS
• support for the CardContact SmartCard, Nitrokey HSM 2, Proteccio, Crypt2pay, Utimaco and other HSMs with KMS keys wrapped by the HSM
• Veracrypt and LUKS disk encryption support
• Synology DSM NAS volume encryption via KMIP
• FIPS 140-3 mode gated behind the feature fips
• a binary and JSON KMIP 1.0-1.4 and 2.0-2.1 compliant interface
• MongoDB
• Mysql Enterprise
• Oracle DB TDE support
• Percona Postgresql DB
• VMWare vCenter Trust Key Provider integration
• User Defined Functions for Big Data including snowflake
• a full-featured client command line and graphical interface
• a high-availability mode with simple horizontal scaling
• integrated with OpenTelemetry

The Cosmian KMS is both a Key Management System and a Public Key Infrastructure. As a KMS, it is designed to manage the lifecycle of keys and provide scalable cryptographic services such as on-the-fly key generation, encryption, and decryption operations.

The Cosmian KMS supports all the standard NIST cryptographic algorithms as well as advanced post-quantum cryptography algorithms such as Covercrypt. Please refer to the list of supported algorithms.

As a PKI it can manage root and intermediate certificates, sign and verify certificates, use their public keys to encrypt and decrypt data. Certificates can be exported under various formats, including PKCS#12 modern and legacy flavor, to be used in various applications, such as in S/MIME encrypted emails.

The Cosmian KMS has extensive online documentation.

🚀 Quick start

Pre-built binaries are available for Linux, MacOS, and Windows, as well as Docker images. To run the server binary, OpenSSL must be available in your path (see "building the KMS" below for details); other binaries do not have this requirement.

Using Docker to quick-start a Cosmian KMS server on http://localhost:9998 that stores its data inside the container, run the following command:

docker run -p 9998:9998 --name kms ghcr.io/cosmian/kms:latest

Then, use the CLI to issue commands to the KMS. The CLI, called cosmian, can be either:

• installed with cargo install ckms

• downloaded from Cosmian packages

• built and launched from the GitHub project by running

  cargo build --bin ckms

▶️ Example

1. Create a 256-bit symmetric key

   ➜ ckms sym keys create --number-of-bits 256 --algorithm aes --tag my-key-file
   ...
   The symmetric key was successfully generated.
     Unique identifier: 87e9e2a8-4538-4701-aa8c-e3af94e44a9e
   
     Tags:
       - my-key-file

2. Encrypt the image.png file with AES GCM using the key

   ➜ ckms sym encrypt --tag my-key-file --output-file image.enc image.png
   ...
   The encrypted file is available at "image.enc"

3. Decrypt the image.enc file using the key

   ➜ ckms sym decrypt --tag my-key-file --output-file image2.png image.enc
   ...
   The decrypted file is available at "image2.png"

See the documentation for more.

⭐ Why Cosmian KMS

• Performance: built in Rust for low-latency crypto and high throughput.
• Trust by design: FIPS 140-3 mode by default; non-FIPS for broader algorithm access when needed.
• Interoperable: full KMIP 1.0–2.1 support, PKCS#11 integrations, and rich client tooling.
• HSM-first: optional HSM key-wrapping and vendor modules (Utimaco, SmartCard-HSM, Proteccio, Crypt2pay…).
• Cloud-native: official Docker image, simple horizontal scaling, and OpenTelemetry observability.
• End-to-end: server, CLI, and web UI for a complete developer and operator experience.

🎯 Top Use Cases

• Application‑level encryption at scale (files, objects, datasets) with centralized key lifecycle.
• Database TDE and integration (Oracle TDE, Percona PostgreSQL, MongoDB, MySQL) via KMIP/PKCS#11.
• Enterprise integrations: Google Workspace CSE, Microsoft DKE, Microsoft SQL Server External (EKM), AWS XKS v2, and Azure EKM.
• HSM-backed key protection and policy‑driven access controls.
• PKI operations: issue, sign, validate, and automate certificate lifecycles.

🔒 Security & Compliance

• FIPS 140-3 mode on by default; switch to --features non-fips for extended algorithms.
• Reproducible builds via Nix; release artifacts ship with SHA-256 checksums.
• Software Bill of Materials (SBOM) and vulnerability reports:
  • CycloneDX: sbom/bom.cdx.json
  • SPDX: sbom/bom.spdx.json
  • Vulnerabilities: sbom/vulns.csv
  • Overview: sbom/README.md
• Observability built-in with OpenTelemetry metrics/traces. See OTLP_METRICS.md.

[TOC]

🔗 Integrations

Legend: ✅ implemented · 🚧 not yet implemented

☁️ Cloud Provider — External Key Management

Cloud providers offer mechanisms that let you hold cryptographic keys outside their infrastructure. There are three distinct delegation models:

Term	Meaning
XKS	AWS External Key Store — every encrypt/decrypt is proxied live to your KMS; the key material never enters AWS.
EKM	GCP External Key Manager — same live-proxy model; Google never holds the key material.
DKE	Microsoft Double Key Encryption — one key lives in Azure/M365, the second key lives exclusively in your KMS; both are required to decrypt.
HYOK	Hold Your Own Key (Oracle) — OCI Vault External KMS; every encrypt/decrypt is proxied live to your KMS; the key material never enters OCI.
BYOK	Bring Your Own Key — you generate key material and import it into the provider's KMS; the provider then holds a copy.
CMK	Customer-Managed Key — the provider generates and stores the key in their KMS, but you control lifecycle (rotate, disable, delete).

Amazon Web Services (AWS)

AWS XKS is a single proxy API that AWS KMS calls on behalf of every service — S3, EBS, RDS, DynamoDB, Secrets Manager, etc. all route through the same endpoint. Implementing the XKS Proxy API once gives Cosmian KMS live-proxy coverage for all XKS-capable AWS services with no per-service work.

Delegation model	Description	Status
XKS (live proxy)	Key material never enters AWS; every encrypt/decrypt is proxied to Cosmian KMS — covers all AWS services that support KMS encryption (S3, EBS, RDS, DynamoDB, Secrets Manager, SQS, SNS, Redshift, OpenSearch, EMR, Glue, Lambda…) — docs	✅
BYOK	Key material generated by you and imported once into AWS KMS; AWS holds a copy	✅
CMK	Key generated and stored inside AWS KMS; you control lifecycle only	🚧

Microsoft Azure

Unlike AWS XKS or GCP EKM, Azure has no single proxy gateway — each service integrates with Azure Key Vault independently. Both EKM and DKE are live-proxy models where key material never leaves Cosmian KMS; DKE is unique in requiring both your key and Microsoft's key to decrypt.

Delegation model	Description	Status
EKM (live proxy)	Key material never leaves Cosmian KMS; Azure services proxy encrypt/decrypt operations to Cosmian KMS via mTLS — docs	✅
DKE (live proxy)	Key material never leaves Cosmian KMS; M365 / Purview requires both your key and Microsoft's key to decrypt	✅
BYOK	Key material generated by you, imported once into Azure Key Vault; Azure holds a copy — applies to Azure Information Protection (AIP)	🚧
BYOK / CMK	Key imported or generated inside Azure Key Vault; applies to all remaining Azure data services (Storage, Disk Encryption, SQL/Managed Instance TDE, Cosmos DB, Synapse, Databricks, Container Registry, Monitor, Service Bus, ASK etcd, Backup…)	🚧

Google Cloud Platform (GCP)

GCP EKM is a single proxy gateway — like AWS XKS, implementing EKM once covers all CMEK-capable GCP services automatically (Cloud Storage, BigQuery, Cloud SQL, GKE, Pub/Sub, Spanner, Vertex AI, Cloud Functions, Artifact Registry, Secret Manager, Cloud Logging…). Workspace CSE uses the same live-proxy model.

Delegation model	Description	Status
EKM (live proxy)	Key material never enters GCP; every encrypt/decrypt is proxied to Cosmian KMS — covers all CMEK-capable GCP services	✅
Workspace CSE (live proxy)	Google Workspace Client-Side Encryption; keys held exclusively in Cosmian KMS	✅
BYOK	Key material generated by you and imported into Cloud KMS; Google holds a copy — supported by a subset of services (Cloud Storage, BigQuery, Cloud SQL)	🚧
CMK	Key generated and stored in Cloud KMS; you control lifecycle only	🚧

Oracle Cloud Infrastructure (OCI)

OCI Vault External KMS (HYOK) is a single proxy gateway — implementing it once covers all OCI services that support customer-managed keys (Block Volumes, Object Storage, File Storage, Autonomous Database, Oracle Database Service, Kubernetes Secrets in OKE, Streaming, Functions…).

Delegation model	Description	Status
HYOK / External KMS (live proxy)	Key material never enters OCI; every encrypt/decrypt is proxied to Cosmian KMS — covers all OCI services that support Vault External KMS (Block Volumes, Object Storage, File Storage, Autonomous DB, OKE secrets…)	🚧
BYOK	Key material generated by you and imported once into OCI Vault; Oracle holds a copy	🚧
CMK	Key generated and stored in OCI Vault; you control lifecycle only	🚧

---

🗄️ Database & Storage Integrations

Product	Integration	Status
Oracle DB	TDE via PKCS#11 (docs)	✅
MongoDB	CSFLE / Queryable Encryption via KMIP	✅
MySQL Enterprise	TDE via KMIP (docs)	✅
Percona PostgreSQL	TDE via KMIP (docs)	✅
VMware vCenter	Trust Key Provider (docs)	✅
VeraCrypt	Virtual disk encryption via PKCS#11 (docs)	✅
LUKS	Linux disk encryption via PKCS#11 (docs)	✅
Synology DSM	NAS volume encryption via KMIP (docs)	✅
Snowflake	UDF-based column encryption (docs)	✅
Big Data / Python UDFs	Bulk encrypt/decrypt (docs)	✅
HashCorp Vault	Key transit / secrets engine via KMIP	🚧
CockroachDB	TDE via KMIP	🚧

---

🔐 HSM Integrations

HSM	Status
Proteccio (Bull Atos)	✅
Crypt2pay	✅
Utimaco SecurityServer	✅
CardContact SmartCard-HSM / Nitrokey HSM 2	✅
SoftHSM2 (testing)	✅
AWS CloudHSM	🚧
Azure Dedicated HSM	🚧
GCP Cloud HSM	🚧

---

KMIP support by Cosmian KMS

This page summarizes the KMIP coverage in Cosmian KMS. The support status is derived from the actual implementation in crate/server/src/core/operations.

Cosmian KMS Server supports KMIP versions: 2.1, 2.0, 1.4, 1.3, 1.2, 1.1, 1.0

Legend:

• ✅ Fully supported
• ❌ Not implemented
• 🚫 Deprecated
• N/A Not applicable (operation/attribute not defined in that KMIP version)

KMIP Baseline Profile Compliance

Baseline Server: ✅ Compliant (all 9 required + 18/18 optional)

The Baseline Server profile (defined in KMIP Profiles v2.1 Section 4.1) requires:

• Required operations: Discover Versions, Query, Create, Register, Get, Destroy, Locate, Activate, Revoke
• Optional operations: Many additional operations for extended functionality

KMIP Coverage

Messages

Message	Support
Request Message	✅
Response Message	✅

Operations by KMIP Version

The following table shows operation support across all KMIP versions.

Operation	1.0	1.1	1.2	1.3	1.4	2.0	2.1
Activate	✅	✅	✅	✅	✅	✅	✅
Add Attribute	✅	✅	✅	✅	✅	✅	✅
Archive	❌	❌	❌	❌	❌	❌	❌
Cancel	❌	❌	❌	❌	❌	❌	❌
Certify	✅	✅	✅	✅	✅	✅	✅
Check	✅	✅	✅	✅	✅	✅	✅
Create	✅	✅	✅	✅	✅	✅	✅
Create Key Pair	✅	✅	✅	✅	✅	✅	✅
Create Split Key	N/A	N/A	N/A	❌	❌	❌	❌
Decrypt	N/A	✅	✅	✅	✅	✅	✅
Delete Attribute	✅	✅	✅	✅	✅	✅	✅
DeriveKey	✅	✅	✅	✅	✅	✅	✅
Destroy	✅	✅	✅	✅	✅	✅	✅
Discover Versions	✅	✅	✅	✅	✅	✅	✅
Encrypt	N/A	✅	✅	✅	✅	✅	✅
Export	N/A	N/A	N/A	N/A	✅	✅	✅
Get	✅	✅	✅	✅	✅	✅	✅
Get Attribute List	✅	✅	✅	✅	✅	✅	✅
Get Attributes	✅	✅	✅	✅	✅	✅	✅
Get Usage Allocation	❌	❌	❌	❌	❌	❌	❌
Hash	N/A	✅	✅	✅	✅	✅	✅
Import	N/A	N/A	N/A	N/A	✅	✅	✅
Join Split Key	N/A	N/A	N/A	❌	❌	❌	❌
Locate	✅	✅	✅	✅	✅	✅	✅
MAC	N/A	✅	✅	✅	✅	✅	✅
MAC Verify	N/A	✅	✅	✅	✅	✅	✅
Notify	❌	❌	❌	❌	❌	❌	❌
Obtain Lease	❌	❌	❌	❌	❌	❌	❌
Poll	❌	❌	❌	❌	❌	❌	❌
Put	❌	❌	❌	❌	❌	❌	❌
Query	✅	✅	✅	✅	✅	✅	✅
RNG Retrieve	N/A	✅	✅	✅	✅	✅	✅
RNG Seed	N/A	✅	✅	✅	✅	✅	✅
Re-certify	❌	❌	❌	❌	❌	❌	❌
Re-key	✅	✅	✅	✅	✅	✅	✅
Re-key Key Pair	N/A	N/A	✅	✅	✅	✅	✅
Recover	❌	❌	❌	❌	❌	❌	❌
Register	✅	✅	✅	✅	✅	✅	✅
Revoke	✅	✅	✅	✅	✅	✅	✅
Set Attribute (Modify)	N/A	N/A	✅	✅	✅	✅	✅
Sign	N/A	✅	✅	✅	✅	✅	✅
Signature Verify	N/A	✅	✅	✅	✅	✅	✅
Validate	✅	✅	✅	✅	✅	✅	✅

Methodology

• Operations marked ✅ are backed by a Rust implementation file under crate/server/src/core/operations.
• Operations marked ❌ are defined in the KMIP specification but not implemented in Cosmian KMS.
• Operations marked N/A do not exist in that particular KMIP version.
• This documentation is auto-generated by analyzing source code and KMIP specifications.

If you spot a mismatch or want to extend coverage, please open an issue or PR.

Managed Objects

The following table shows managed object support across all KMIP versions.

Managed Object	1.0	1.1	1.2	1.3	1.4	2.0	2.1
Certificate	✅	✅	✅	✅	✅	✅	✅
Symmetric Key	✅	✅	✅	✅	✅	✅	✅
Public Key	✅	✅	✅	✅	✅	✅	✅
Private Key	✅	✅	✅	✅	✅	✅	✅
Split Key	❌	❌	❌	❌	❌	❌	❌
Template	🚫	🚫	🚫	🚫	🚫	🚫	🚫
Secret Data	✅	✅	✅	✅	✅	✅	✅
Opaque Data	✅	✅	✅	✅	✅	✅	✅
PGP Key	N/A	N/A	N/A	N/A	N/A	N/A	N/A

Notes:

• Opaque Object import support is present (see import.rs).
• PGP Key types appear in digest and attribute handling but full object import/register is not implemented, hence ❌.
• Template objects are deprecated in newer KMIP versions.

Base Objects

The following table shows base object support across all KMIP versions.

Base Object	1.0	1.1	1.2	1.3	1.4	2.0	2.1
Attribute	❌	❌	❌	❌	❌	❌	❌
Credential	❌	❌	❌	❌	❌	❌	❌
Key Block	✅	✅	✅	✅	✅	✅	✅
Key Value	❌	❌	❌	❌	❌	❌	❌
Key Wrapping Data	✅	✅	✅	✅	✅	✅	✅
Key Wrapping Specification	✅	✅	✅	✅	✅	✅	✅
Transparent Key Structures	✅	✅	✅	✅	✅	✅	✅
Template-Attribute Structures	✅	✅	✅	✅	✅	✅	✅
Server Information	✅	✅	✅	✅	✅	✅	✅
Extension Information	❌	❌	❌	❌	❌	❌	❌
Data	✅	✅	✅	✅	✅	✅	✅
Data Length	✅	✅	✅	✅	✅	✅	✅
Signature Data	✅	✅	✅	✅	✅	✅	✅
MAC Data	✅	✅	✅	✅	✅	✅	✅
Nonce	✅	✅	✅	✅	✅	✅	✅
Correlation Value	✅	✅	✅	✅	✅	✅	✅
Init Indicator	✅	✅	✅	✅	✅	✅	✅
Final Indicator	✅	✅	✅	✅	✅	✅	✅
RNG Parameters	❌	❌	❌	❌	❌	❌	❌
Profile Information	❌	❌	❌	❌	❌	❌	❌
Validation Information	❌	❌	❌	❌	❌	❌	❌
Capability Information	❌	❌	❌	❌	❌	❌	❌
Authenticated Encryption Additional Data	✅	✅	✅	✅	✅	✅	✅
Authenticated Encryption Tag	✅	✅	✅	✅	✅	✅	✅

Notes:

• AEAD Additional Data and Tag are supported in encrypt/decrypt APIs.
• Nonce and RNG Parameter are used by symmetric encryption paths.
• Base objects are fundamental structures present across all KMIP versions.

Transparent Key Structures

The following table shows transparent key structure support across all KMIP versions.

Structure	1.0	1.1	1.2	1.3	1.4	2.0	2.1
Symmetric Key	✅	✅	✅	✅	✅	✅	✅
DSA Private Key	✅	✅	✅	✅	✅	✅	✅
DSA Public Key	❌	❌	❌	❌	❌	❌	❌
RSA Private Key	✅	✅	✅	✅	✅	✅	✅
RSA Public Key	✅	✅	✅	✅	✅	✅	✅
DH Private Key	N/A	N/A	N/A	N/A	N/A	N/A	N/A
DH Public Key	N/A	N/A	N/A	N/A	N/A	N/A	N/A
EC Private Key	✅	✅	✅	✅	✅	✅	✅
EC Public Key	✅	✅	✅	✅	✅	✅	✅
ECDSA Private Key	N/A	N/A	N/A	N/A	N/A	N/A	N/A
ECDSA Public Key	N/A	N/A	N/A	N/A	N/A	N/A	N/A
ECDH Private Key	N/A	N/A	N/A	N/A	N/A	N/A	N/A
ECDH Public Key	N/A	N/A	N/A	N/A	N/A	N/A	N/A
ECMQV Private Key	N/A	N/A	N/A	N/A	N/A	N/A	N/A
ECMQV Public Key	N/A	N/A	N/A	N/A	N/A	N/A	N/A

Note: EC/ECDSA support is present; DH/DSA/ECMQV are not implemented.

Attributes

Attribute	Current
Activation Date	✅
Alternative Name	✅
Always Sensitive	✅
Application Specific Information	✅
Archive Date	✅
Attribute Index	✅
Certificate Attributes	✅
Certificate Length	✅
Certificate Type	✅
Comment	✅
Compromise Date	✅
Compromise Occurrence Date	✅
Contact Information	✅
Critical	✅
Cryptographic Algorithm	✅
Cryptographic Domain Parameters	✅
Cryptographic Length	✅
Cryptographic Parameters	✅
Cryptographic Usage Mask	✅
Deactivation Date	✅
Description	✅
Destroy Date	✅
Digest	✅
Digital Signature Algorithm	✅
Extractable	✅
Fresh	✅
Initial Date	✅
Key Format Type	✅
Key Value Location	✅
Key Value Present	✅
Last Change Date	✅
Lease Time	✅
Link	✅
Name	✅
Never Extractable	✅
Nist Key Type	✅
Object Group	✅
Object Group Member	✅
Object Type	✅
Opaque Data Type	✅
Original Creation Date	✅
PKCS#12 Friendly Name	✅
Process Start Date	✅
Protect Stop Date	✅
Protection Level	✅
Protection Period	✅
Protection Storage Masks	✅
Quantum Safe	✅
Random Number Generator	✅
Revocation Reason	✅
Rotate Date	✅
Rotate Generation	✅
Rotate Interval	✅
Rotate Latest	✅
Rotate Name	✅
Rotate Offset	✅
Sensitive	✅
Short Unique Identifier	✅
State	✅
Unique Identifier	✅
Usage Limits	✅
Vendor Attribute	✅
X.509 Certificate Identifier	✅
X.509 Certificate Issuer	✅
X.509 Certificate Subject	✅

Notes:

• GetAttributes returns a union of metadata attributes and those embedded in KeyBlock structures.
• "Vendor Attributes" are available via the Cosmian vendor namespace and are accessible via GetAttributes.
• A ✅ indicates the attribute is used or updated by at least one KMIP operation implementation in crate/server/src/core/operations, including attribute handlers (Add/Delete/Set/Get Attribute).
• Most attributes are present across all KMIP versions with some additions in newer versions.

🗄️ Repository content

The Cosmian KMS is written in Rust and organized as a Cargo workspace with multiple crates. The repository contains the following main components:

🧰 Binaries

• KMS Server (cosmian_kms) - The main KMS server binary built from crate/server

🧱 Core Crates

🖧 Server Infrastructure

• server - Main KMS server implementation with REST API, KMIP protocol support, and web UI
• server_database - Database abstraction layer supporting SQLite, PostgreSQL, MySQL, and Redis
• access - Permission and access control management system

Cosmian-only crate dependencies for the server crate (crate/server):

flowchart TD
    server[server]

    server --> access
    server --> base_hsm
    server --> server_database
    base_hsm --> hsm_loaders

    hsm_loaders --> smartcardhsm
    hsm_loaders --> crypt2pay
    hsm_loaders --> proteccio
    hsm_loaders --> softhsm2
    hsm_loaders --> utimaco
    hsm_loaders --> other

    server_database --> kmip
    server_database --> crypto
    server_database --> interfaces

Loading

🧑‍💻 Client Libraries

• kms_client - High-level Rust client library for KMS server communication
• client_utils - Shared utilities for client implementations
• wasm - WebAssembly bindings for browser-based clients

🔐 Cryptographic Components

• crypto - Core cryptographic operations and algorithm implementations
• kmip - Complete implementation of the KMIP (Key Management Interoperability Protocol) standard versions 1.0-2.1
• kmip-derive - Procedural macros for KMIP protocol serialization/deserialization

🔐 Hardware Security Module (HSM) Support

• hsm/base_hsm - Base HSM abstraction layer
• hsm/smartcardhsm - Nitrokey HSM 2 resp. CardContact SmartCard-HSM
• hsm/crypt2pay - Crypt2pay HSM integration
• hsm/proteccio - Proteccio HSM integration
• hsm/softhsm2 - SoftHSM2 integration for testing and development
• hsm/utimaco - Utimaco HSM integration
• hsm/other - Other HSMs support

🗄️ Database Interfaces

• interfaces - Database and storage backend abstractions

🧪 Development and Testing

• test_kms_server - Library for programmatic KMS server instantiation in tests
• cli - Legacy CLI crate (now primarily used for testing)

📁 Additional Directories

• documentation/ - Comprehensive project documentation built with MkDocs
• examples/ - Code examples and integration samples
• scripts/ - Build and deployment scripts
• test_data/ - Test fixtures and sample data
• ui/ - Frontend web interface source code
• pkg/ - Packaging configurations for Debian and RPM distributions

Note: Each crate contains its own README with detailed information. Please refer to these files for specific implementation details and usage instructions.

Find the public documentation of the KMS in the documentation directory.

🏗️ Building and running the KMS

Two paths are supported:

• For production use, use Nix build: use the unified script .github/scripts/nix.sh for a pinned toolchain, reproducible FIPS builds (non-FIPS builds are tracked for consistency), and packaging.
• For development purpose, use traditional cargo command: cargo build..., cargo test

GLIBC Support

The following table shows the GLIBC versions and distribution support for Cosmian KMS:

Distribution	Version	GLIBC	Support	End of Support
Debian	13 (Trixie)	2.40	✅	TBD
Debian	12 (Bookworm)	2.36	✅	~2028 (LTS)
Debian	11 (Bullseye)	2.31	❌	~2026 (LTS)
Debian	10 (Buster)	2.28	❌	Jun 2024 (LTS)
Debian	9 (Stretch)	2.24	❌	Jun 2022 (LTS)
Rocky Linux	10	2.40	✅	TBD
Rocky Linux	9	2.34	✅	May 2032
Rocky Linux	8	2.28	❌	May 2029
Ubuntu	25.04 (Plucky)	2.40	✅	Jan 2026
Ubuntu	24.04 LTS (Noble)	2.39	✅	Apr 2029
Ubuntu	22.04 LTS (Jammy)	2.35	✅	Apr 2027
Ubuntu	20.04 LTS (Focal)	2.31	❌	Apr 2025
Ubuntu	18.04 LTS (Bionic)	2.27	❌	Apr 2023

Note: Cosmian KMS requires GLIBC 2.34 or higher (available in Debian 12+, Rocky Linux 9+, and Ubuntu 22.04+).

OpenSSL prerequisite

The following table shows the OpenSSL versions used by Cosmian KMS variants:

OpenSSL Linkage	FIPS	Non‑FIPS
Static	Linkage: OpenSSL 3.6.0; runtime loads FIPS provider from OpenSSL 3.1.2	Linkage: OpenSSL 3.6.0; runtime uses default/legacy providers
Dynamic	Linkage: OpenSSL 3.1.2; ships FIPS configs and provider OpenSSL 3.1.2	Linkage: OpenSSL 3.6.0; ships libssl/libcrypto and providers

Notes:

• FIPS builds include fipsmodule.cnf and the FIPS provider

✨ Features

From version 5.4.0, the KMS runs in FIPS mode by default. The non-FIPS mode can be enabled by passing the --features non-fips flag to cargo build or cargo run.

The interop feature enables KMIP interoperability test operations, which are disabled by default for security reasons. These operations should only be enabled during testing: cargo build --features interop or cargo test --features interop.

All builds link against OpenSSL 3.6.0. FIPS variants ship the FIPS provider and fipsmodule.cnf; non‑FIPS variants use the default/legacy providers. For non‑Nix development, ensure OpenSSL 3.6.0+ is available.

🖥️ Linux or macOS

Nix-based (reproducible FIPS builds):

# Run tests (defaults to 'all'; DB backends require services)
bash .github/scripts/nix.sh test

# Package artifacts (Linux → deb+rpm, macOS → dmg)
bash .github/scripts/nix.sh package

Simple (Cargo-only):

cargo build
cargo test --lib --workspace
cargo test --lib --workspace --features non-fips

🪟 Windows

Follow the prerequisites below, or use the provided PowerShell helpers.

Prerequisites (manual):

1. Install Visual Studio (C++ workload + clang), Strawberry Perl, and vcpkg.
2. Install OpenSSL 3.6.0 with vcpkg:

In this project root directory, run:

vcpkg install --triplet x64-windows-static  # arm64-windows-static for ARM64
$env:OPENSSL_DIR=(Get-Item .).FullName+"\vcpkg_installed\vcpkg\pkgs\openssl_x64-windows-static"

For FIPS builds (to build fips.dll):

Copy-Item -Path "vcpkg_fips.json" -Destination "vcpkg.json"
vcpkg install
vcpkg integrate install

PowerShell helpers (non-FIPS by default):

. .github/scripts/cargo_build.ps1
BuildProject -BuildType release   # or debug

. .github/scripts/cargo_test.ps1
TestProject -BuildType release    # or debug

📦 Packaging (DEB/RPM/DMG) and hashes

Use the Nix entrypoint to build packages:

# Linux
bash .github/scripts/nix.sh package           # builds deb + rpm
bash .github/scripts/nix.sh package deb       # build deb only
bash .github/scripts/nix.sh package rpm       # build rpm only

# macOS
bash .github/scripts/nix.sh package dmg

On success, a SHA-256 checksum file (.sha256) is written next to each generated package (.deb/.rpm/.dmg) to ease verification and artifact distribution.

🧪 Running the unit and integration tests

Pull the test data using:

git submodule update --init --recursive

By default, tests are run using cargo test and an SQLCipher backend (called sqlite). This can be influenced by setting the KMS_TEST_DB environment variable to

• sqlite, for plain SQLite
• mysql (requires a running MySQL or MariaDB server connected using a "mysql://kms:kms@localhost:3306/kms" URL)
• postgresql (requires a running PostgreSQL server connected using a "postgresql://kms:kms@127.0.0.1:5432/kms"URL)
• redis-findex (requires a running Redis server connected using a "redis://localhost:6379" URL)

Example: testing with a plain SQLite and some logging

RUST_LOG="error,cosmian_kms_server=info,cosmian_kms_cli=info" KMS_TEST_DB=sqlite cargo test

Alternatively, when writing a test or running a test from your IDE, the following can be inserted at the top of the test:

unsafe {
set_var("RUST_LOG", "error,cosmian_kms_server=debug,cosmian_kms_cli=info");
set_var("RUST_BACKTRACE", "1");
set_var("KMS_TEST_DB", "redis-findex");
}
log_init(option_env!("RUST_LOG"));

⚙️ Development: running the server with cargo

To run the server with cargo, you need to set the RUST_LOG environment variable to the desired log level and select the correct backend (which defaults to sqlite).

RUST_LOG="info,cosmian_kms_server=debug" \
cargo run --bin cosmian_kms --features non-fips -- \
--database-type redis-findex --database-url redis://localhost:6379 \
--redis-master-password secret --redis-findex-label label

🔧 Server parameters

If a configuration file is provided, parameters are set following this order:

• conf file (env variable COSMIAN_KMS_CONF set by default to /etc/cosmian/kms.toml)
• default (set on struct)

Otherwise, the parameters are set following this order:

• args in the command line
• env var
• default (set on struct)

☁️ Use the KMS inside a Cosmian VM on SEV/TDX

See the Marketplace guide for more details about Cosmian VM.

🏷️ Releases

All releases can be found in the public URL package.cosmian.com.

📈 Benchmarks

To run benchmarks, go to the crate/test_kms_server directory and run:

cargo bench

Typical values for single-threaded HTTP KMIP 2.1 requests (zero network latency) are as follows

- RSA PKCSv1.5:
    - encrypt
            - 2048 bits: 128 microseconds
            - 4096 bits: 175 microseconds
    - decrypt
            - 2048 bits: 830 microseconds
            - 4096 bits: 4120 microseconds
- RSA PKCS OAEP:
    - encrypt
            - 2048 bits: 134 microseconds
            - 4096 bits: 173 microseconds
    - decrypt
            - 2048 bits: 849 microseconds
            - 4096 bits: 3823 microseconds
- RSA PKCS KEY WRP (AES):
    - encrypt
            - 2048 bits: 142 microseconds
            - 4096 bits: 198 microseconds
    - decrypt
            - 2048 bits: 824 microseconds
            - 4096 bits: 3768 microseconds
- RSA Keypair creation (saved in KMS DB)
    -  2048 bits: 33 milliseconds
    -  4096 bits: 322 milliseconds

🤝 Community & Support

• Docs: documentation/ and online docs at https://docs.cosmian.com/key_management_system/
• Issues: use GitHub Issues to report bugs and request features
• Contributing: see CONTRIBUTING.md
• Security disclosures: see SECURITY.md
• License: see LICENSE