Security & Encryption Model
Keeper Secret Manager Security and Encryption Model
Overview
Keeper Secrets Manager is a Zero Knowledge platform. Encryption and decryption of secrets takes place locally on the Client Device running the ksm application, CI/CD plugins or the developer SDK.
One-Time Access Tokens
A One-Time Access Token is a provisioning credential, not an operating credential. It is a 32-byte random value used solely to bootstrap trust between a new client device and a Secrets Manager Application. The client authenticates with an HMAC-SHA512 hash of the token — the raw token value is never used as a bearer credential against the API. The token is redeemed by the client's first API call, after which the server marks it consumed and the client removes it from its configuration. A second redemption attempt fails. Tokens expire and can be locked to a source IP at creation, limiting the exposure window of an unredeemed token.
A One-Time Access Token grants a client device its initial, single-use authentication to a KSM Application. The token secret is a 32-byte random value, encoded as URL-safe Base64 without padding, which always yields exactly 43 characters from the alphabet [A-Za-z0-9_-].
Tokens are prefixed with a Keeper region abbreviation and a colon:
<REGION>:<43-char URL-safe Base64 secret>Example:
US:Vn2tFX0c8xtpBElBiBbzFyDkk8-3zZX90tLal0jzN0UKnown region prefixes: US, EU, AU, CA, JP, GOV, US_GOV.
Note: The token is single-use. It is redeemed (consumed) by the client's first API call, after which it is removed from the configuration.
Configurations
Redeeming a token produces a configuration — the durable identity of a single client device. During the first authentication, the client generates an ECC secp256r1 keypair locally and registers only the public key with Keeper. All subsequent requests are signed with the Client Device Private Key and verified server-side via ECDSA. After the bootstrap, no shared secret exists in the authentication path: the private key never leaves the device and is never known to Keeper, so server-side data cannot be replayed to impersonate a client.
Each configuration maps one-to-one to a client device. If a configuration leaks, the clientId it contains identifies exactly which device to revoke — access is severed immediately without rotating the application or re-keying any records.
All KSM SDKs and integrations share one configuration format. The raw configuration is a JSON object; some integrations accept the same JSON wrapped in Base64.
Example:
Zero-Knowledge Decryption
The configuration also holds the Application Key (AES-256), which anchors decryption. Secrets are protected by a layered key hierarchy: the Application Key decrypts Shared Folder and Record Keys, which decrypt individual record contents. All decryption occurs locally on the client device. The Keeper cloud stores and transmits only ciphertext and never possesses the keys required to read the secrets it serves. The Application Key itself is delivered wrapped, and is unwrapped only with material derived from the one-time token.
Configuration Protection
Protection of the Keeper Secrets Manager configuration is critical in the overall security posture of the environment.
The Secrets Manager CLI stores configuration securely in your operating system's native secure storage manager by default. This provides enhanced security compared to storing credentials in plaintext files.
How It Works
macOS
Keychain
Windows
Windows Credential Manager
Linux
Secret Service (GNOME Keyring, KWallet)
When the user initializes a Secrets Manager profile, the credentials are automatically stored in the OS-native secure storage. As an optional capability, the configuration can be stored as a file called keeper.ini which is referenced as a file-based storage method.
If the local file storage option is enabled, the keeper.ini file contains the following format:
When utilizing Keeper's developer SDKs, Keeper offers various methods for protecting configuration files by integrating with third-party secrets storage solutions, including:
Configuration Parameters
A description of each configuration parameter is described below.
clientkey
One Time Access Token - deleted after first use (32-byte random value)
clientid
Unique Client Device Identifier (HMAC_SHA512 hash of the One Time Access Token)
privatekey
Client Device Private Key (ECC secp256r1)
appkey
Application Private Key (AES-256)
hostname
Destination endpoint - US, EU, AU, JP or US_GOV
serverpublickeyid
Identifier of the Keeper API public key for transmission wrapper
Authentication and Encryption
The Client Device only authenticates with the hashed One Time Access Token one time. The client signs the payload and registers a Client Device Public Key with the server on the first authentication. After the first authentication, subsequent requests are signed with the Client Device Private Key.
API requests to the Keeper Cloud are sent with a Client Device Identifier and a request body that is signed with the Client Device Private Key. The server checks the ECDSA signature of the request for the given Client Device Identifier using the Client Public Key of the device.
The Client Device decrypts the ciphertext response from the server with the Application Private Key, which decrypts the Record Keys and Shared Folder Keys. The Shared Folder Keys decrypt the Record Keys, and the Record Keys decrypt the individual Record secrets.
Protecting Access through IP Lockdown
By default, when creating a Client Device profile, IP lockdown is enabled.
For example:
The client which initializes using this token will be locked on IP. To disable IP lockdown, an additional parameter must be specified, for example:
It is recommended to allow IP lockdown, unless you are deploying to an environment which has a dynamic WAN IP.
Revoking Access
If a configuration is leaked or requires immediate revocation, execute the following from the Commander CLI:
Additional Information
Keeper utilizes best-in-class security with a Zero-Knowledge security architecture and Zero-Trust framework. Technical documentation about Keeper's Zero-Knowledge encryption model can be found at the links below:
Secrets Manager Encryption Model
Keeper is SOC 2 Type 2, ISO27001 certified, FedRAMP High and StateRAMP High Authorized . Customers may request access to our certification reports and technical architecture documentation at Keeper's Trust Center.
Vulnerability Disclosure Program
Keeper has partnered with Bugcrowd to manage our vulnerability disclosure program. Please submit reports through https://bugcrowd.com/keepersecurity or send an email to security@keepersecurity.com.
Last updated
Was this helpful?