Keeper Encryption Model
Keeper is a Zero Knowledge security provider. Zero Knowledge is a system architecture that guarantees the highest levels of security and privacy by adhering to the following principles:
Data is encrypted and decrypted at the device level (not on the server)
The application never stores plain text (human readable) data
The server never receives data in plain text
No Keeper employee or 3rd party can view the unencrypted data
The keys to decrypt and encrypt data are derived from the user’s master password
Multi-Layer encryption provides access control at the user, group and admin level
Sharing of data uses Public Key Cryptography for secure key distribution
Data is encrypted locally on the user’s device before it is transmitted and stored in Keeper’s Cloud Security Vault. When data is synchronized to another device, the data remains encrypted until it is decrypted on the other device.
Keeper is the most secure, certified, tested and audited password security platform in the world. We are the only SOC 2 and ISO 27001 certified password management solution in the industry and Privacy Shield Compliant with the U.S. Department of Commerce's EU-U.S. Privacy Shield program, meeting the European Commission's Directive on Data Protection. Not only do we implement the most secure levels of encryption, we also adhere to very strict internal practices that are continually audited by third parties to help ensure that we continue to develop secure software and provide the world’s most secure cybersecurity platform.
For password-based authentication, when users create their account profile, they are required to select a “Master Password”. Users are also able to configure a second factor of authentication using SMS, TOTP, Duo Security, RSA SecurID or SmartWatch.
If the user is authenticated via Keeper SSO Connect™ On-Prem (integration with SAML 2.0 identity provider), the Master Password is auto-generated by the SSO Connect software (hosted and operated by the Enterprise customer on-premise).
If the user is authenticated via Keeper SSO Connect™ Cloud, a 256-bit Elliptic Curve (ECC) private key is generated and stored locally on each device. The ECC private key is used to decrypt the Data Key, and the Data Key decrypts the user's vault. No Master Passwords are utilized in this encryption model.
The Device Private Key is not directly utilized to encrypt or decrypt vault data. Upon successful authentication from the Identity Provider, a separate key (that is not stored) is utilized for decryption of the vault data. Offline extraction of the local Device Private Key cannot decrypt a user's vault.
The Master Password is used to derive an encryption key on the client device using a Password Based Key Derivation Function (PBKDF2) with minimum of 100,000 rounds.
On the client device, a 256-bit AES “Data Key” and “Client Key” are generated, as well as 2048-bit RSA Private Key and Public Key pair.
The “Data Key” is used to encrypt data that is synchronized to the Cloud Security Vault. For Master Password-based authentication, the “Data Key” is encrypted with the “Master Password Key” (derived from the Master Password) and this ciphertext is stored in the Cloud Security Vault. For SSO Cloud-based authentication, the local ECC private key is used to decrypt the Data Key. The Data Key decrypts the user's vault.
The “Client Key” is used to encrypt data that is stored locally on the user’s device. The “Client Key” is encrypted with the “Data Key” and this ciphertext is stored in the Cloud Security Vault. For Master Password-based authentication, the “Client Key” is also encrypted with the “Master Password Key” and this ciphertext is stored locally on the device for offline use. Offline mode can be controlled by the Enterprise administrator.
The vault data stored offline is AES-GCM encrypted with a 256-bit “Client Key” that is generated randomly and protected by PBKDF2-HMAC-SHA512 with up to 100,000 iterations and a random salt. The salt and iterations are stored locally. When the user enters their Master Password, a key is derived using the salt and iterations and an attempt is made to decrypt the Client Key. The Client Key is then used to decrypt the stored record cache.
The “RSA Public Key” is stored directly to the Cloud Security Vault.
The “RSA Private Key” is encrypted with the “Data Key” and the ciphertext is stored in the Cloud Security Vault.
For each record (e.g. Website Password or File) that is created, a 256-bit AES “Record Key” is generated on the client device. The “Record Key” is used to encrypt and decrypt the record content. The “Record Key” is encrypted with the user’s “Data Key” and the ciphertext is stored in the Cloud Security Vault. The Record Key and record data is also encrypted with the “Client Key” and the ciphertext is stored locally on the device.
When a user logs into a device (with their master password), they first decrypt their Client Key from the Master Password-derived key.
The Client Key is used to decrypt all locally stored data on the device.
The data key retrieved locally or retrieved from the Cloud Security Vault upon successful authentication is decrypted with the user’s Master Password derived key.
Record Key ciphertext is synchronized from the Cloud Security Vault then decrypted locally with the user’s Data Key. Shared Folder keys are decrypted with the respective Shared Folder Key from each folder. Record content is decrypted with the respective Record Key from each record. Record Keys and content are then encrypted with the client key and stored locally.
To share a Keeper Record to another user, Keeper first requests the user’s RSA Public Key from the Cloud Security Vault.
The Record Key of each record is encrypted with the recipient’s RSA Public Key and synchronized to the user’s Keeper vault via the Cloud Security Vault.
The recipient of the encrypted shared record decrypts the Record Key with their RSA Private Key. For optimization, the Record Key will be re-encrypted with the user’s Data Key (since AES encryption is faster than RSA encryption) and the ciphertext is stored in the recipient’s Cloud Security Vault.
For subsequent record retrievals, the recipient decrypts the Record Key with their Data Key, and then decrypts the record content with the Record Key.
The Keeper Cloud Security Vault is protected by an API which authenticates each request from the client device. On the client device, a 256-bit "Authentication Key" is derived from the Master Password using PBKDF2-HMAC-SHA256 and a random salt. An "Authentication Hash" is generated by hashing the "Authentication Key" using SHA-256. To login, the Authentication Hash is compared against a stored Authentication Hash on the Cloud Security Vault. After login, a session token is generated and used by the client device for subsequent requests. This authentication token must be renewed every 30 minutes, or upon the request of the server.
KSI supports 256-bit and 128-bit TLS to encrypt all data transport between the client application and KSI's cloud-based storage. This is the same level of encryption trusted by millions of individuals and businesses everyday for web transactions requiring security, such as online banking, online shopping, trading stocks, accessing medical information and filing tax returns. KSI deploys TLS certificates signed by Digicert using the SHA2 algorithm, the most secure signature algorithm currently offered by commercial certificate authorities. SHA2 is significantly more secure than the more widely used SHA1, which could be exploited due to mathematical weakness identified in the algorithm. SHA2 helps protect against the issuance of counterfeit certificates that could be used by an attacker to impersonate a website. KSI also supports Certificate Transparency (CT), a new initiative by Google to create a publicly auditable record of certificates signed by certificate authorities. CT helps guard against issuance of certificates by unauthorized entities. CT is currently supported in the latest versions of the Chrome web browser. More information about Certificate Transparency can be found at: http://www.certificate-transparency.org/. Keeper supports the following TLS cipher suites:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Keeper client devices also implement Key Pinning, a security mechanism which prevents impersonation by attackers using fraudulent digital certificates.
To protect against unauthorized access to a customer's account, Keeper also offers Two-Factor Authentication. Two-Factor authentication is an approach to authentication requiring two or more of the three authentication factors: a knowledge factor, a possession factor, and an inherence factor. For more information on Two-Factor Authentication see this link. Keeper uses something you know (your password) and something you have (the phone in your possession) to provide users extra security in the case where your master password or device is compromised. To do this, we generate TOTPs (Time-based One-Time Passwords). Keeper generates a 10-byte secret key using a cryptographically secure random number generator. This code is valid for about a minute, and is sent to the user by SMS, Duo Security, RSA SecurID, TOTP application, Google Authenticator or Keeper DNA-compatible wearable devices. When using the Google Authenticator or TOTP application on your mobile device, the Keeper server internally generates a QR code containing your secret key, and it is never communicated to a third party. Each time a user deactivates, then reactivates Two-Factor Authentication, a new secret key is generated. To activate Two-Factor Authentication, visit the Keeper DNA or Settings screen of the Keeper Web App. Keeper Business customers can optionally enforce the use of Two-Factor Authentication and supported 2FA methods via the Keeper Admin Console's role enforcement functionality.
Keeper supports FIDO-compatible U2F hardware-based security key devices such as YubiKey and Google Titan keys as a second factor. Security keys provide a convenient and secure way to perform two-factor authentication without requiring the user to manually enter 6-digit codes. Multiple security keys can be configured for a user's vault. For platforms that do not support security key devices, users may fall back to other configured 2FA methods. To configure a security key and other two-factor authentication methods, visit the 'Settings' screen of the Keeper application.
Keeper operates a self-contained managed service architecture on Amazon AWS called BreachWatch which is physically separate from the Keeper Backend API and stored user data.
On the BreachWatch servers, a physical Hardware Security Module (HSM) is used to process, hash and store billions of unique passwords from dark web data breaches. Each of these billions of passwords is processed on Keeper's servers using HMAC_SHA512 hashing method, hashed with a Hardware Security Module using a non-exportable key.
On the Keeper end-user client device, when BreachWatch is activated, a HMAC_SHA512 hash is generated based on each stored password and sent to the server. On the server, a second hash is created using HMAC_SHA512 via the Hardware Security Module (HSM) using a non-exportable key. Hashes are compared to determine if a password has been breached.
BreachWatch backend architecture was built to prevent correlation of a breached password to an actual password in the user's vault, no matter the size of the data breach. The hashing used in the breached password detection utilizes a physical Hardware Security Module to ensure that hashing can only be performed online - to prevent any threat of brute force attack on the BreachWatch data.
The below system diagram outlines the overall data flow, encryption and BreachWatch hash processing workflows.
Keeper SSO Connect Cloud provides Keeper Enterprise customers with a method of authenticating a user and decrypting stored data in a zero-knowledge encrypted vault, with authentication provided through a 3rd party identity provider (IdP) utilizing standard SAML 2.0 protocols in a fully cloud environment.
In this implementation, a user can authenticate through their SSO identity provider and then decrypt the ciphertext of their vault locally on their device. Each device has its own EC (Elliptic Curve) public/private key pair and encrypted data key. Each user has their own Data Key. To sign into a new device, the user must utilize existing devices to perform an approval or an administrator with the privilege can approve a new device.
The importance of this new capability is that the user can decrypt their vault using an encrypted key stored in the Keeper cloud. Zero knowledge is preserved because the Keeper cloud is unable to decrypt the user's Data Key on their device. The Data Key ("DK") of the user is decrypted with the device private key ("DPRIV"), and the Encrypted Data Key ("EDK") is only provided to the user upon successful authentication from their designated identity provider (e.g. Okta, Azure, AD FS).
For SSO Connect Cloud users, an Elliptic Curve private key is generated and stored locally on each device. For Chromium-based web browsers, the Keeper Vault stores the local device EC private key ("DPRIV") as a non-exportable CryptoKey. On iOS and Mac devices, the key is stored in the device KeyChain. Where available, Keeper utilizes secure storage mechanisms.
The Device Private Key is not directly utilized to encrypt or decrypt vault data. Upon successful authentication from the Identity Provider, a separate key (that is not stored) is utilized for decryption of the vault data. Offline extraction of the local Device Private Key cannot decrypt a user's vault.
To sign into a new device, the user must utilize existing devices to perform an approval or an administrator with the privilege can approve a new device. New devices generate a new set of public/private keys, and the approving device encrypts the user's data key with the public key of the new device. The new device’s encrypted data key (EDK) is provided to the requesting user/device and then the user is able to decrypt their data key, which then decrypts the user's vault data. Within the decrypted vault data the user can decrypt their other private encryption keys such as record keys, folder keys, team keys, etc.
The importance of this capability is that the user can decrypt their vault using an encrypted key stored by the Keeper cloud, and does not require any on-prem or user-hosted application services to manage the encryption keys. Zero knowledge is preserved because the Keeper cloud is unable to decrypt the user's Data Key on their device. The Data Key of the user is decrypted with the device private key (DPRIV), and the EDK is only provided to the user upon successful authentication from their designated identity provider (e.g. Okta, Azure, AD FS).
From an administrator's perspective, the benefits are: easy setup and no required hosted software to manage encryption keys as described in Keeper's current SSO Connect encryption model.
The only workflow change in this model (compared to on-prem implementation of Keeper SSO Connect) is that the user must perform new device approval on an active device, or delegate the responsibility to a Keeper Administrator to perform device approval.
Full Security Disclosure https://keepersecurity.com/security.html
GDPR Compliance https://keepersecurity.com/GDPR.html
White Papers, Data sheets and Case Studies https://keepersecurity.com/resources.html
SSO Connect Cloud Security Model https://docs.keeper.io/sso-connect-cloud/security-and-user-flow Additional technical documentation is available under NDA.
Keeper Security is committed to the industry best practice of responsible disclosure of potential security issues. We take your security and privacy seriously are committed to protecting our customers’ privacy and personal data. KSI’s mission is to build world’s most secure and innovative security apps, and we believe that bug reports from the worldwide community of security researchers is a valuable component to ensuring the security of KSI’s products and services. Keeping our users secure is core to our values as an organization. We value the input of good-faith cybercriminals and believe that an ongoing relationship with the researcher community helps us ensure their security and privacy, and makes the Internet a more secure place. This includes encouraging responsible security testing and disclosure of security vulnerabilities.
Keeper's Vulnerability Disclosure Policy sets out expectations when working with researchers, as well as what you can expect from us.
If security testing and reporting is done within the guidelines of this policy, we:
Consider it to be authorized in accordance with Computer Fraud and Abuse Act,
Consider it exempt from DMCA, and will not bring a claim against you for bypassing any security or technology controls,
Consider it legal, and will not pursue or support any legal action related to this program against you,
Will work with you to understand and resolve the issue quickly, and
Will recognize your contributions publicly if you are the first to report the issue and we make a code or configuration change based on the issue.
If at any time you are concerned or uncertain about testing in a way that is consistent with the Guidelines and Scope of this policy, please contact us at security@keepersecurity.com before proceeding.
To encourage good-faith security testing and disclosure of discovered vulnerabilities, we ask that you:
Avoid violating privacy, harming user experience, disrupting production or corporate systems, and/or destroying data,
Perform research only within the scope set out below, and respect systems and activities which are out-of-scope,
Contact us immediately at security@keepersecurity.com if you encounter any user data during testing, and
You give us reasonable time to analyze, confirm and resolve the reported issue before publicly disclosing any vulnerability finding.
Keeper has partnered with Bugcrowd to manage our vulnerability disclosure program. Please submit reports through [https://bugcrowd.com/keepersecurity].
