Secrets Manager
Commander CLI
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.Client Device Configuration File
The local configuration file (e.g. keeper.ini) for the
ksm application contains the following format:1
[_default]
2
clientkey = XXX
3
clientid = XXX
4
privatekey = XXX
5
appkey = XXX
6
hostname = US
7
serverpublickeyid = 10
8
9
[_config]
10
active_profile = _default
Copied!
This file should be protected on your 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.
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, 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:
1
My Vault> secrets-manager client add --app MyApplication
2
3
Successfully generated Client Device
4
====================================
5
6
One-Time Access Token: PqwnPcUo2Wc3dv3zvu_zC3nHhNAbNWDfooECWMBTRJM
7
IP Lock: Enabled
8
Token Expires On: 2021-08-17 21:00:28
9
App Access Expires on: Never
Copied!
The client which initializes using this token will be locked on IP. To disable IP lockdown, an additional parameter must be specified, for example:
1
My Vault> secrets-manager client add --app MyApplication --unlock-ip
Copied!
It is recommended to allow IP lockdown, unless you are deploying to an environment which has a dynamic WAN IP.
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 is SOC 2 Type 2, ISO27001 certified. Customers may request access to our certification reports and technical architecture documentation under mutual NDA.
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 [email protected]
Last modified 13d ago