Entrust KeyControl is a proprietary KMS which KES supports using for storing secrets. K E S C l i e n t K E S S e r v e r E n t r u s t K e y C o n t r o l Prerequisites This procedure was written and tested against Entrust KeyControl v10.1. The provided instructions may work against other KeyControl versions. This procedure assumes you have prior experience with Entrust products and have followed their documentation, best practices, and other published materials in deploying the KeyControl service.

Overview Use the kes identity commands to generate the API key of an PEM key file. In addition, you can use subcommands to temporarily manage the identities that access the KES server. Use the subcommand to display, create, or remove identities. All changes made by kes identity subcommands are lost when the KES server restarts. To make persistent changes to KES identities, modify the Policies and Identities section of the KES configuration file. Specifically, for each policy.policyname to modify, add/remove the identities to/from the policy.policyname.identities array.

Overview Starts a stateful KES server or cluster. Syntax kes init \ --config <PATH> \ --force, -f Parameters --config Path to the configuration file to use for the server or cluster.

This section provides reference documentation for the AIStor Key Encryption Service (KES). This KES is distinct from the AGPL3.0-licensed community KES.

Overview Return the name, ID, and creation information about a cryptographic key. Output resembles the following: Name my-key ID 14eb17aec10cd31a6bc006ba81d63589 Created At 2023-03-09 18:16:11 Created By 3ecfcdf38fcbe141ae26a1030f81e96b753365a46760ae6b578698a97c59fd22 Syntax kes key info \ <name> \ [--color <string>] \ [--insecure, -k] \ [--json] Parameters name Required

Overview Decrypt the contents of a data encryption key and return the plaintext value. Use the plaintext value for encrypting or decrypting data using the DEK. Avoid storing the plaintext value of a DEK on disk, as it allows decryption of data without requiring access to the secret key used to generate the DEK. Syntax kes key decrypt \ <name> \ <ciphertext> \ [<context>] \ [--insecure,-k] Parameters name Required

Overview Add a new cryptographic key and store it in the configured Key Management System. KES never returns the generated secret to clients. Syntax kes key create \ <name> \ [--insecure, -k] Parameters name Required

Overview The kes migrate command supports migrating master keys from one KMS instance to another KMS instance. For example, you can use the command to migrate a Hashicorp Vault instance to another Hashicorp Vault instance. Or, kes migrate can migrate a Hashicorp Vault instance to or from an AWS Secrets Manager KMS.

AIStor Key Manager is a robust key management server designed to securely store cryptographic keys and other sensitive data. Key Manager provides similar functionality to third-party Key Management Services (KMS), such as an HTTP API for en/decrypting operations, scalable design, high availability, high performance, and low latency. Architecture A Key Manager cluster consists of at least one server or host. Each node in the cluster consists of a full replica that can service read and write operations.

The Key Manager supports a YAML-formatted configuration file for specifying startup options and settings. The file has the following format: # Config file version # REQUIRED # version: v1 # System admin configuration # Optional # #admin: # Identity with sysadmin privileges. # Generate a new identity using `minkms identity` # Use the corresponding secret `k1:KEY` when authenticating as a client to # perform operations with this identity # If you omit this value, MinKMS generates and emits the root credentials # to the systemlog on startup. # identity: h1:Rvxa7nj8zkL48CeDkN6LhpX-K7KK6uhIhpBOcTHNhWw # Interval in which the cluster leader sends heartbeats to all its followers # OPTIONAL # # If 0, a reasonable default is selected automatically. It should be # at least twice the network latency between any two KMS cluster nodes. # Reasonable values are between 50ms and 1s for most clusters. # # Very low (below 50ms) or high (above 1.5s) values should only be set # under special circumstances. For example, a stretch cluster spawned # across geographic regions may demand larger heartbeat intervals due to # higher network latency. # # A too low value may cause sporadic leadership losses similar to a flaky # or unreliable network. A too high value may cause delayed detection of # node failures and longer write-quorum recovery after node failures. # However, it does not affect the strict consistency guarantees or # correctness of state changes. # # The default setting is typically sufficient # # heartbeat: 500ms # TLS configuration # Required # # Key Manager requires TLS for encrypting and protecting all connections. # tls: certs: # You must specify *at least* one TLS keypair. # # You can specify multiple key-cert pairs to MinKMS to cover multiple # hostnames if necessary. # # MinKMS must have read access to the specified paths to start. # - key: /etc/minkms/private.key # Path to the server's TLS private key cert: /etc/minkms/public.crt # Path to the server's TLS certificate # A folder containing one or more CA root certificates # MinKMS uses this for validating TLS certificates for a remote system # This is optional and typically not required during normal installations # ca: /etc/minkms/CAs