> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/secrets-manager/about/security-encryption-model.md). # Security & 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: ``` :<43-char URL-safe Base64 secret> ``` Example: ``` US:Vn2tFX0c8xtpBElBiBbzFyDkk8-3zZX90tLal0jzN0U ``` Known 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: ```json { "hostname": "keepersecurity.com", "clientId": "XXXXXXXXXXXXXX", "privateKey": "XXXXXXXXXXXXXX", "serverPublicKeyId": "10", "appKey": "XXXXXXXXXXXXXX", "appOwnerPublicKey": "XXXXXXXXXXXXXX" } ``` #### **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](/keeperpam/secrets-manager/secrets-manager-command-line-interface.md) 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 | Operating System | Secure Storage Backend | | ---------------- | --------------------------------------- | | 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: ``` [_default] clientkey = XXX clientid = XXX privatekey = XXX appkey = XXX hostname = US serverpublickeyid = 10 [_config] active_profile = _default ``` When utilizing Keeper's developer SDKs, Keeper offers various methods for protecting configuration files by integrating with third-party secrets storage solutions, including: * [AWS KMS Encryption](/keeperpam/secrets-manager/integrations/aws-kms.md) * [Azure Key Vault Encryption](/keeperpam/secrets-manager/integrations/azure-key-vault-ksm.md) * [Entrust HSM Encryption](/keeperpam/secrets-manager/integrations/entrust-hsm.md) * [Google Cloud Key Management Encryption](/keeperpam/secrets-manager/integrations/google-cloud-key-management-encryption.md) * [Oracle Key Vault Encryption](/keeperpam/secrets-manager/integrations/aws-kms.md) ### Configuration Parameters A description of each configuration parameter is described below. | Config Name | Description | | ----------------- | -------------------------------------------------------------------------------- | | 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: ``` My Vault> secrets-manager client add --app MyApplication Successfully generated Client Device ==================================== One-Time Access Token: PqwnPcUo2Wc3dv3zvu_zC3nHhNAbNWDfooECWMBTRJM IP Lock: Enabled Token Expires On: 2021-08-17 21:00:28 App Access Expires on: Never ``` The client which initializes using this token will be locked on IP. To disable IP lockdown, an additional parameter must be specified, for example: ``` My Vault> secrets-manager client add --app MyApplication --unlock-ip ``` 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: {% code overflow="wrap" %} ``` My Vault> secrets-manager client revoke --client [ClientID] ``` {% endcode %} ### 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: [Keeper Encryption Model](/enterprise-guide/keeper-encryption-model.md) [Secrets Manager Encryption Model](/enterprise-guide/keeper-encryption-model.md#secrets-manager-encryption-model) [Security Disclosure Page](https://keepersecurity.com/security) 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 ](https://trust.keeper.io/)Center. ### Vulnerability Disclosure Program Keeper has partnered with Bugcrowd to manage our vulnerability disclosure program. Please submit reports through or send an email to . --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.keeper.io/keeperpam/secrets-manager/about/security-encryption-model.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.