Cosmian KMS

Note: Cosmian has become part of Eviden. The Cosmian KMS is now the Eviden 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:

• Use cases: large-scale encryption/decryption, client-side/application-level encryption, and data anonymization/tokenization, with support for signature at scale (including secp256k1 in non-FIPS mode).
• Cloud and enterprise integrations: AWS XKS v2, Azure EKM, Google Workspace CSE, and Microsoft 365 DKE.
• Databases: Oracle Database TDE, Microsoft SQL Server External (EKM), MongoDB, MySQL Enterprise, PostgreSQL Percona, and EDB Postgres Advanced Server TDE.
• Disk encryption: Veracrypt, LUKS, and Cryhod.
• Big Data: Snowflake Native App and PySpark/Databricks Python UDF for large-scale data encryption.
• Storage integrations: VMware vCenter Trust Key Provider, Synology DSM, VAST Data, and Veeam Backup & Replication.
• Other integrations: OpenSSH, S/MIME email encryption, and FortiGate / FortiOS.
• Security and standards: FIPS 140-3, KMIP 1.0-2.1 binary and JSON TTLV support, state-of-the-art authentication mechanisms, and native compatibility with network appliances such as FortiGate / FortiOS.
• HSM support: Utimaco, SmartCard-HSM/Nitrokey HSM 2, Proteccio, Crypt2pay, and others, with KMS keys wrapped by HSMs.
• Operations: full-featured CLI and graphical clients, high-availability mode, confidential cloud deployment, OpenTelemetry integration, OpenAPI 3.1 spec with Swagger UI for interactive API exploration, and scheduled key auto-rotation.

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, and FF1 format-preserving encryption in non-FIPS mode. 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

  sh cargo build --bin ckms

▶️ Example

1. Create a 256-bit symmetric key

   ```sh ➜ 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

   sh ➜ 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

   sh ➜ 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, rich client tooling, and a built-in OpenAPI 3.1 spec with Swagger UI.
• 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 for server and CLI (ckms):
  • CycloneDX (server): sbom/server/fips/static/bom.cdx.json
  • SPDX (server): sbom/server/fips/static/bom.spdx.json
  • Vulnerabilities (server): sbom/server/fips/static/vulns.csv
  • CycloneDX (ckms CLI): sbom/ckms/fips/static/bom.cdx.json
  • Overview: sbom/README.md
  • Cryptography Bill of Materials (CBOM): full inventory of cryptographic assets (algorithms, libraries, parameters) in CycloneDX 1.6 format.

    - cbom/cbom.cdx.json — generated by .mise/scripts/sbom/generate_cbom.py

    Observability built-in with OpenTelemetry metrics/traces. See OTLP_METRICS.md.

[TOC]

🔐 HSM support

🔗 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:

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.