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:

[_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 through 3rd party secrets storage mechanisms including:

• AWS KMS

• Azure Key Vault

• Entrust HSM

• Google Cloud Key Management

• Oracle Key Vault

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.

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

Secrets Manager Encryption Model

Security Disclosure Page

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 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 [email protected].