# 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. ### Client Device Configuration File The local configuration file (e.g. keeper.ini) for the `ksm` application contains the following format: ``` [_default] clientkey = XXX clientid = XXX privatekey = XXX appkey = XXX hostname = US serverpublickeyid = 10 [_config] active_profile = _default ``` This file must be protected on the local filesystem. It contains keys can authenticate with the Keeper API and decrypt secrets that have been explicitly associated with the Application and Client Device. ### Protection of Configuration Files Keeper provides several methods of configuration file protection. #### Using the Secrets Manager CLI Using the [Secrets Manager CLI](https://docs.keeper.io/en/keeperpam/secrets-manager/secrets-manager-command-line-interface), credentials are securely stored in your operating system's native secure storage manager by default, enhancing security over storing them in configuration files. #### Secrets Manager SDKs 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](https://docs.keeper.io/en/keeperpam/secrets-manager/integrations/aws-kms) * [Azure Key Vault Encryption](https://docs.keeper.io/en/keeperpam/secrets-manager/integrations/azure-key-vault-ksm) * [Entrust HSM Encryption](https://docs.keeper.io/en/keeperpam/secrets-manager/integrations/entrust-hsm) * [Google Cloud Key Management Encryption](https://docs.keeper.io/en/keeperpam/secrets-manager/integrations/google-cloud-key-management-encryption) * [Oracle Key Vault Encryption](https://docs.keeper.io/en/keeperpam/secrets-manager/integrations/aws-kms) ### Configuration File Fields | 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](https://app.gitbook.com/s/-LO5CAzpxoaEquZJBpYz/keeper-encryption-model) [Secrets Manager Encryption Model](https://app.gitbook.com/s/-LO5CAzpxoaEquZJBpYz/keeper-encryption-model#secrets-manager-encryption-model) [Security Disclosure Page](https://keepersecurity.com/security) Keeper is SOC 2 Type 2, ISO27001 certified, FedRAMP and StateRAMP 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: 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: ``` GET https://docs.keeper.io/en/keeperpam/secrets-manager/about/security-encryption-model.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.