Keeper Encryption and Security Model Details
The full details of Keeper’s encryption and security model are outlined below, with block diagrams, implementation details and additional resources.
Keeper is a Zero Knowledge security provider. Zero Knowledge is a system architecture that guarantees the highest levels of security and privacy. Encryption and decryption of data always occurs locally on the user's device.
Our encryption model adheres to the following structure:
- 1.Each vault record is encrypted by a unique and client-side generated 256-bit AES encryption key in GCM mode.
- 2.Each record-level key is wrapped by a 256-bit AES Shared Folder key if it is contained within a Shared Folder.
- 3.For Vault users, the Record and Folder Keys are encrypted with another AES-256 key called the Data Key.
- 4.For Secrets Manager users, the Record and Folder Keys are encrypted with a 256-bit AES Application Key.
- 5.For users who login with a Master Password, the keys to decrypt and encrypt data are derived from the user’s master password.
- 6.For users who login with SSO or Passwordless technology, Elliptic Curve cryptography is used to encrypt and decrypt data at the device level.
- 7.All encrypted payloads sent to the Keeper servers are additionally wrapped by a 256-bit AES transmission key in addition to TLS, to protect against MITM attacks. The transmission key is generated on the client device and transferred to the server using ECIES encryption via the server's public EC key.
- 8.Sharing of secrets between users uses Elliptic Curve Cryptography for secure key distribution.
- 9.Multi-Layer encryption provides access control at the user, group and admin level.
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 SOC2 and ISO27001 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.
Keeper is GDPR compliant and we are committed to ensuring our business processes and products continue to maintain compliance for our customers in the European Union.
Our Privacy Policy can be found here:
Keeper's desktop applications, web applications and mobile applications do not contain any trackers or 3rd party libraries which perform tracking. As an example, see this link for information on Keeper's Android app which shows that no trackers are installed.
Keeper is a fully SaaS platform and currently hosts data in the following Amazon AWS data centers. Customer may host their Keeper tenant in any preferred primary region. Customer data (stored ciphertext) and access to the platform is isolated to the specific region.
- United States (US)
- United States Government Cloud (US_GOV)
- Europe (EU)
- Australia (AU)
- Japan (JP)
- Canada (CA)
Keeper utilizes FIPS 140-2 validated encryption modules to address rigorous government and public sector security requirements. Keeper’s encryption has been certified by the NIST CMVP and validated to the FIPS 140 standard by accredited third party laboratories.
Keeper has been issued certificate #3967 under the NIST CMVP: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3976
Keeper Security Government Cloud (KSGC) is KSI’s password management and cybersecurity platform for public sector agencies. KSGC is a FedRAMP Authorized provider at the Moderate Impact Level, hosted in AWS GovCloud (US). KSGC can be found on the FedRAMP Marketplace.
The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. federal government program that provides a standardized approach to security assessment, authorization and continuous monitoring for cloud products and services. FedRAMP enables government agencies to use modern cloud technologies, with an emphasis on security and protection of federal information and helps accelerate the adoption of secure, cloud solutions. For more information about FedRAMP, please visit https://www.gsa.gov/technology/government-it-initiatives/fedramp.
KSGC supports compliance with the United States International Traffic in Arms Regulations (ITAR). Companies that are subject to ITAR export regulations must control unintended exports by restricting access to protected data to U.S. Citizens and by restricting physical location of protected data to the U.S.
KSGC’s FedRAMP Moderate environment supports ITAR requirements through the following:
- Fully compliant data storage hosted on AWS GovCloud and restricted to the U.S.
- Secure data encryption in transit and at rest.
- Zero-knowledge and zero-trust security, in conjunction with granular permissions, allows organizations to ensure that only approved personnel can access sensitive data.
- Robust compliance reporting features provide a traceable, electronic audit trail of all actions performed and data entered.
- Sequestered Customer Success team is comprised of U.S. Persons specifically trained in safe handling of Export Controlled and ITAR-governed data.
- No non-U.S. based support.
The Keeper FedRAMP environment has been audited by an independent third-party assessment organization (3PAO) to validate that proper controls are in place to support customer export compliance programs.
Keeper implements a multi-layered encryption system based on client-side generated keys. Record-level keys and Folder-level keys are generated on the local device which encrypt each stored Vault record (e.g. Password). For example, if you have 10,000 records in your vault, you also have 10,000 AES Record Keys protecting the data.
Keys are generated locally on the device to preserve Zero Knowledge and to support advanced features such as record and folder sharing. Record and Folder Keys are wrapped by other keys, such as the Data Key and Client Key.
All fields and all of the data in the vault is encrypted, including file attachments.
For users who login with a Master Password:
A Master Password Key is derived from the Master Password using PBKDF2 with 1,000,000 rounds and used to unwrap the AES-256 Data Key, which is then used to unwrap the AES-256 Record Keys and Folder Keys. Record Keys are then used to decrypt the stored record information in the vault.
For users who login with Keeper SSO Connect Cloud:
A locally stored Elliptic Curve (EC) key pair is generated locally to encrypt and decrypt the user's Data Key, which then unwraps the Record and Folder keys.
Additional details about the key wrapping is described in the Encryption of Stored Data section below.
For users who login with Keeper SSO Connect (On-Prem):
Master Password Hashes and 256-bit AES Master Password Keys are generated by the on-premise SSO Cloud application.
Business and Enterprise customers can manage many different capabilities of the Keeper platform, such as role-based enforcement policies, provisioning, authentication and team management.
Administrative functions are protected in the Keeper platform by encryption, in addition to authorization. Authorization allows an Admin to access certain capabilities of the platform, but Encryption is used in many ways to ensure that only designated users are able to physically perform functionality or view sensitive information.
Many features within the Administrative features require decryption of keys in order to function and to preserve Zero-Knowledge and Zero-Trust. For example:
- Teams have a public and private encryption key pair.
- Role policies for Vault Transfer and Device Approvals utilize public and private encryption key pairs
- Enterprise-level key pairs are used for sharing usage data from the individual user to the Admin
- Auditing of Password Strength and other sensitive usage data is encrypted with Enterprise Public Keys that can only be decrypted by the Admin.
Keeper's platform as a whole can be thought of as a key management platform, where the keys are in full control of the users and the Keeper Administrators. The underlying complexity of key management is abstracted from users by the friendly front-end interface.
Keeper has created an advanced cloud authentication and network communications model that has been built for the highest levels of privacy, security and trust. A few key features of the authentication model are:
- Master Password is never transmitted over the network layer Unlike most SaaS services, the login credentials never leave the device. PBKDF2 is utilized on the local device to derive a 256-bit AES key used for decryption. A second PBKDF2 key is generated locally and then hashed with HMAC_SHA256 to derive an authentication token. Keeper’s Cloud Security vault has zero knowledge of the user’s decryption key.
- Traffic between client device and Keeper Cloud cannot be intercepted or decrypted Keeper utilizes Key Pinning and additional layers of network-level encryption (Transmission Keys) between the device and the Keeper servers, to ensure that MITM attacks are prevented.
- New devices cannot login to an account without a device verification step No login attempts can be made on an account without passing this step. Keeper supports several types of device verification methods that depend on the authentication scheme being used.
- 2FA is performed after device verification, prior to Master Password entry If a user has 2FA configured or enforced, this step must pass prior to the Master Password entry.
- Master Password entry cannot be performed until the Device Verification and 2FA step succeeds The user is unable to proceed to the Master Password entry step without first performing a device verification and 2FA authentication. This advanced authentication flow provides protection against several attack vectors including brute force attack, password spraying, enumeration and MITM.
Keeper provides several methods of authenticating into the platform.
- Master Password
- SSO (On-Prem) with SAML 2.0
- SSO (Cloud) with SAML 2.0
- SSO Alternate Master Password
- Biometrics
A user cannot attempt to login to an account without a device approval and verification step.
For customers logging in with a Master Password, device verification can be performed using several new methods including:
- Email verification code
- 2FA code entry from a TOTP or text message
- Sending a Keeper Push™ message to recognized devices
For customers who authenticate with Keeper SSO Connect Cloud, device approval is made of up a key transfer, in which the user's encrypted data key is delivered to the device, which is then decrypted locally using their elliptic curve private key. Device approval methods include the following:
- Keeper Push (using push notifications) to existing user devices
- Admin Approval via the Keeper Admin Console
2FA can be added to any consumer or business account. Business customers can enforce the use of 2FA with various levels of control and security options.
Starting with version 3 of the Keeper backend API (which corresponds to version 15+ of the Keeper client applications), the 2FA step comes before the Master Password entry. Performing the device verification and 2FA step prior to the Master Password entry phase offers mitigation of several attack vectors including brute force attack, password testing and account enumeration.
The user's vault records are encrypted locally with a 256-bit AES-GCM "Record Key" that is randomly generated on the device. The record keys are encrypted with a 256-bit AES-GCM "Data Key" that is also generated randomly on the user's device and unique to each user. For users who login with a Master Password, the Data Key is encrypted with a key derived from the user's Master Password using PBKDF2-HMAC-SHA256 with a 128-bit random salt and 1,000,000 iterations. The encrypted vault ciphertext is stored in the Keeper cloud.
For authentication, a second PBKDF2 key is generated locally on the user's device using 1,000,000 iterations and a 128-bit randomly generated salt. This key is then hashed with SHA256 to derive an authentication token. In the Keeper cloud, the authentication token is super-encrypted with a "user authentication" key. The user authentication key is randomly generated by the server and encrypted with a hardware security module (with a non-exportable key) prior to storage. The user authentication key is used to encrypt the salt, authentication token, user’s encrypted data key and other authentication related fields for alternate authentication methods like biometrics, etc.
Keeper's SSO Cloud capability provides authentication against a SAML 2.0 identity provider, while retaining full Zero Knowledge encryption with the user's vault. An Elliptic Curve (secp256r1) private key key pair is generated on the device. The Data Key of the user is decrypted with the device private key, and the Encrypted Data Key is provided to the user upon successful authentication from their designated identity provider.
For users who authenticate to Keeper with a SAML 2.0 identity provider, Keeper SSO Connect software is hosted in the customer's environment. The SSO Connect software generates and manages the user's Master Password. The Generated Master Password is then processed with PBKDF2 to derive a key which decrypts the user's other keys such as the Data Key.
Customers who normally login to their Keeper Vault using Enterprise SSO Login (SAML 2.0) can also login to Keeper Web Vault, Browser Extension and Keeper Commander using an "Alternate Master Password". To make use of this capability, it must be enabled by the Keeper Administrator in the role policy and then configured by the user. Offline access can also be achieved with a Master Password for SSO-enabled users when this feature is activated.
This feature may be useful for users for several reasons including:
- The requirement to login to the vault in offline mode
- The ability to login to the vault if the SSO identity provider is unavailable
- Authentication via Keeper Commander CLI (Command Line Interface)
PBKDF2 is used to derive a key from the Alternate Master Password. A hash of the key performs authentication, and the key decrypts the user's Data Key locally on the device. More information is available on SSO Master Password at this link.
Keeper natively supports Windows Hello, Touch ID, Face ID and Android biometrics. Customers who normally login to their Keeper Vault using a Master Password or Enterprise SSO Login (SAML 2.0) can also login to their devices using a biometric. Biometrics must be enabled by the Keeper Administrator in the role policy. Offline access can also be achieved with a biometric for both Master Password and SSO-enabled users when this feature is activated.
When biometric login is enabled on a device, a key is randomly generated locally and stored in the secure enclave (e.g. Keychain) of the device. The user's Data Key is encrypted with the biometric key. Upon successful biometric authentication, the key is retrieved and the user is able to decrypt their vault.
Keeper does NOT store or process biometric data of users. Keeper integrates with the existing biometrics capabilities of the operating system to authenticate the user and retrieve the encryption key protected by the device secure enclave.
- 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 FIDO2 WebAuthn, TOTP, Duo Security, RSA SecurID, SMS or SmartWatch.
- If the user is authenticated via Keeper SSO Connect™ Cloud, a 256-bit Elliptic Curve (ECC secp256r1) private key is generated and stored locally on each device. The ECC private key is used to decrypt the AES-256 Data Key, and the Data Key decrypts the user's vault record keys and folder keys. No Master Passwords are utilized in this encryption model.
- If the user is authenticated via Keeper SSO Connect™ On-Prem (integration with SAML 2.0 identity provider), the Master Password and AES-256 key is auto-generated by the SSO Connect software (hosted and operated by the Enterprise customer on-premise).
- The ECC 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 1,000,000 rounds.
- On the client device, a 256-bit AES “Data Key” and “Client Key” are generated, as well as the ECC Private/Public Key Pair. (For legacy compatibility with older shared records, a 2048-bit RSA Private/Public Key Pair is also generated)
New user creation encryption model
- 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 (secp256r1) 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 through role enforcement policies.
- 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 a 128-bit random salt and 1,000,000 iterations. 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 "EC Public Key" is stored directly to the Cloud Security Vault.
- The “EC 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 unwrapped 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.
Master Password Encryption Model
- To share a Keeper Record to another user, Keeper first requests the user’s Elliptic Curve Public Key from the Cloud Security Vault.
- The Record Key of each record is encrypted with the recipient’s Elliptic Curve 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 Elliptic Curve Private Key. For optimization, the Record Key will be re-encrypted with the user’s Data Key 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.
- Note that for legacy compatibility with Keeper's legacy "general" record type, a 2048-bit RSA Private/Public Key Pair is also utilized.
Sharing with Elliptic Curve Encryption
For all cryptographic functions in the Keeper client device, a secure random number generator is utilized. For example, on web-based applications like the Keeper Web Vault and Browser Extensions, the getRandomValues method of the Web Crypto API is used. On iOS, the SecRandomCopyBytes method is used. On Android, SecureRandom is used.
The Keeper Cloud Security Vault is protected by APIs which are validated through authorization by the client device. The client retrieves a session token upon login and sends it with each API call. The session token is tracked on the server. Login is performed either by a Master Password, session resumption, or SAML 2.0 SSO authentication.
When using a Master Password, the client device derives a 256-bit "Authentication Key" using PBKDF2-HMAC-SHA256 with 1,000,000 iterations and a 128-bit 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 on the server and sent to the client to be used by the client device for subsequent API requests. The session must be active to allow continued use of client to server communications.
KSI supports 256-bit and 128-bit TLS to encrypt all data transport between the client application and KSI's cloud-based storage.
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:
- ECDHE-ECDSA-AES128-GCM-SHA256
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-ECDSA-AES128-SHA256
- ECDHE-RSA-AES128-SHA256
- ECDHE-ECDSA-AES256-GCM-SHA384
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-ECDSA-AES256-SHA384
- ECDHE-RSA-AES256-SHA384
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 Settings screen of the Keeper Web App, Desktop App or mobile application. 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 Passkeys and FIDO2-compatible WebAuthn 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. These Hashes-of-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.
BreachWatch System Diagram
In summary:
- The passwords are hashed twice with HMAC_512 - once on the client device using a "pepper", and once in the Amazon AWS CloudHSM, using a hardware security module with a non-exportable key.
- HMAC_512 is utilized because it takes advantage of a strong hashing function, plus a secret key (which is not exportable). Therefore, an offline attack against the hashes is not feasible.
- "Message authentication code" (MAC) with the result of a cryptographic hash function. It is a way to expand the use of hash functions. Its results depend not only on the message but on a second input that can be a secret key.
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 Device-Encrypted Data Key ("DEDK") is provided to the user upon successful authentication from their designated identity provider (e.g. Okta, Azure, AD FS, Google Workspace, Duo, Ping, JumpCloud, etc...).
SSO Connect Cloud Encryption Model
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.
- When a user logs into a device (with their SSO provider), they first authenticate with the identity provider using the SAML 2.0 protocol.
- After a successful authentication with the identity provider, Keeper delivers a Device-Encrypted Data Key ("DEDK") to the user's device.
- The Data Key is unwrapped locally with the Elliptic Curve private key. If this is a new device that has never been used before, the user must perform a Device Approval step as described in the next section.
- 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 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.
Keeper SSO Connect Cloud supports several device approval methods:
(1) Keeper Push
(2) Admin Approval via the Keeper Admin Console
(3) Admin Approval via Commander automation tool
(4) Automatic Admin Approval via Azure Function
(5) Automatic Approval using Keeper Automator (** Recommended)
Learn more about SSO Cloud Device Approvals here:
https://docs.keeper.io/sso-connect-cloud/device-approvals
The system architecture diagram for Keeper SSO Connect is shown below:
SSO Connect Security Architecture
Keeper provides account recovery using a randomly generated 24-word recovery phrase. The recovery phrase can be used to regain access to your Keeper Vault in case you forget your Master Password.
Keeper implements recovery phrases using the industry-standard BIP39 word list, which is a set of 2,048 words used to generate an encryption key with 256 bits of entropy. Each word in the BIP39 list is carefully chosen to improve legibility and make the recovery process less error-prone.
Recovery Phrase account recovery works by storing a second copy of the user's data key encrypted with a 256-bit AES-GCM key. This key is derived using HKDF with HMAC_SHA512 as the underlying hashing algorithm, from the 24 randomly-selected words on the BIP39 list.
To complete a vault recovery, the user is required to:
- Enter an email verification code
- Pass the Two-Factor Authentication step (if enabled on the account)
- Enter the recovery phrase locally on the device
Account Recovery with 24-word Recovery Phrase
Keeper Secrets Manager is a Zero Knowledge platform for DevOps, IT Security and software development teams to manage secrets throughout the software development and deployment lifecycle.
Secrets Manager adheres to the following encryption model:
(1) Secrets are encrypted and decrypted on the device (not on the server)
(2) The device never stores plain text (human readable) data
(3) The server never receives data in plain text
(4) No Keeper employee, 3rd party or intermediary can decrypt secrets
(5) The keys to decrypt and encrypt secrets are managed by the customer on the Client Device.
(6) Each secret is encrypted by a unique and client-side generated 256-bit AES encryption key in GCM mode.
(7) Each record-level key is wrapped by a Shared Folder key if it is contained within a Shared Folder.
(8) A client-side generated 256-bit AES Application Key is used to decrypt the Shared Folder and Record Keys. The record key decrypts the individual secret.
(9) All encrypted payloads sent to the Keeper servers are additionally wrapped by a 256-bit AES transmission key in addition to TLS, to protect against MITM attacks. The transmission key is generated on the client device and transferred to the server using ECIES encryption via the server's public EC key.
(10) Sharing of secrets between users uses Elliptic Curve Cryptography for secure key distribution.
(11) Multi-Layer encryption provides access control at the user, group and admin level.
(12) Secrets that are managed within a User Vault are segmented and isolated to defined Secrets Manager devices that are granted access to the individual records and folders.
One-Time Sharing
Keeper "One-Time Share" provides time-limited secure sharing of a record (such as a password, secret, document or other confidential information) to a recipient without having to create a Keeper account. The encryption model implemented for one-time sharing uses the same technology as Keeper Secrets Manager, a zero-knowledge and zero-trust platform for protecting cloud infrastructure.
(1) In the vault, the sharer generates a one-time access token by clicking on "One-Time Share" in the record options screen. The 256-bit AES Record Key for the record being shared is encrypted with the one-time access token, and this encrypted value is stored in the Keeper Cloud.
(2) The sharer sends the One-Time Access Token to a recipient via a simple URL or QR code through their preferred channel. The URL portion that contains the access token is held within the "fragment identifier" section of the URL which is never sent over the network to Keeper's servers. Therefore, zero-knowledge is retained and Keeper has no ability to access or decrypt the information.
(3) The recipient opens the URL on their device browser, and a single-page Vault application is loaded on the device. The One-Time Access Token is handed off directly to the local vault application (not sent to the server).
(4) Upon loading the URL, the recipient's device generates a client-side public/private Elliptic Curve key pair, and the private key is stored locally on the Client Device in the browser's CryptoKey storage.
(5) Upon first use, the SDK library authenticates using the hash of the One Time Access Token and upon successful authentication, the server responds with the encrypted record ciphertext plus the Encrypted Record Key.
(6) The Client decrypts the Record Key with the One Time Access Token, and the record contents are decrypted using the Record Key. The Record Key is then stored locally on the client device in the browser's CryptoKey storage or other designated storage location.
(7) On the server, the encrypted record key for that given device is deleted so that the One Time Access Token cannot be used again. After that, the client's requests must be signed with the Client Private Key.
(8) Subsequent calls on the same device to the server are sent with an identifier which uniquely defines the device (hash of the one-time access token) and a request body that is signed with the Client Private Key. The server checks the ECDSA signature of the request for the given device identifier using the Client Public Key of the device. The Keeper Cloud processes the request for the record, and the server returns encrypted record ciphertext to the Client upon successful authentication.
(9) In addition to the record-level encryption, the Client Device creates a randomly generated AES-256 bit Transmission Key which is encrypted with the public key of the Keeper cloud API. The Client Device decrypts the response from the server with the Transmission Key and then decrypts the ciphertext response payload with the Record Key, which decrypts the contents of the record.
When Account Transfer Policy is activated for a role, a role enforcement policy public/private key pair is generated on the Admin Console locally. The end-user's data key (for users in a role to which the enforcement is applied) is encrypted with the role enforcement policy's Public Key when the user signs into the Vault. The role enforcement private key is encrypted with the Admin's Public Key. Therefore, the Admin can decrypt the role enforcement private key when a vault transfer is required.
To perform a Vault Transfer, the Keeper Admin first must lock the user's account, then the transfer can occur which immediately is followed by deleting the user's account. This ensures the operation is not performed secretly. When performing the transfer, the user's Data Key is retrieved by first unwrapping the role enforcement Private Key and then unwrapping the user's Data Key. The Data Key is then used to unwrap the record keys, team keys, and folder keys.
All encryption is performed client side within the Admin Console, and at no time does Keeper have the ability to decrypt the information being shared or transferred. Additionally, at no time is a user's client Data Key shared. Therefore, the data cached on a user’s device cannot be decrypted without the user’s master password. A user who is removed from a team, shared folder, or direct share will not receive new data from the team, shared folder, or record. Although the record, folder and team keys are compromised to the admin during the transaction, the keys are not usable for gaining access to the underlying record or folder data.
Several different administrative privileges may be assigned to portions of a hierarchical tree that allows the members of the privileged role to perform operations in our Keeper Admin Console.
Keeper's consumer product supports the ability to add up to 5 emergency contacts to grant vault access in the event of an emergency or death. Once a specified wait time has elapsed, the emergency contact will gain access to the user's vault. The process of sharing a vault is Zero-Knowledge, and the user's Master Password is never directly shared. 2048-bit RSA encryption is utilized to share a 256-bit AES key with the emergency contact, at the expiration of the wait time set by the originating user. Therefore, the emergency contact must have a Keeper account (and a public/private key pair) to accept the invitation.
Digital Legacy is only supported on consumer-level accounts
Keeper's mobile apps do not contain any trackers. All mobile apps go through vulnerability testing with Keeper's 3rd party testers and the Bugcrowd bug bounty program.
Exodus Privacy is an organization that monitors the applications that perform user tracking. Keeper's Android application is listed below:
Browser Extension Architecture
The Keeper Browser extension ("KeeperFill") provides customers with autofill capabilities on all web browsers including Chrome, Firefox, Edge, Safari and other chromium-based browsers.
When users login to Keeper using a Master Password: A key is derived from the Master Password using PBKDF2. This key, called the "Master Password Key", is NOT stored anywhere. It is used to decrypt the AES-256 Client Key and the AES-256 Data Key. The Data Key is used to decrypt the data coming from the Keeper Cloud, and the Client Key is used to encrypt and decrypt the ciphertext stored locally.
After the user's ciphertext is sync'd from the Keeper Cloud to the local device, the ciphertext is decrypted locally using the Data Key and then encrypted using the Client Key into the device's local IndexedDB database. The browser IndexedDB database is only available to the Keeper browser extension.
At no time is Keeper storing the encryption key used to decrypt the local ciphertext. The information is held in memory while the user is logged in, and used for auto-fill and accessing the Keeper browser toolbar functionality. When the Service Worker is restarted, Keeper repeats the process of decrypting data from IndexedDB using the Client Key. In between Service Worker restarts, the Client Key is held in memory.
After the user logs out of Keeper, or after the inactivity logout timer expires, the vault is locked and the user must login again using their Master Password.
When users login to Keeper using Single Sign-On: After the signed SAML response is returned by the SSO identity provider, Keeper delivers the user a Device-Encrypted Data Key ("DEDK") to the user. The Data Key is decrypted with the Elliptic-Curve Device Private Key ("DPRIV"). The Data Key is then used to decrypt the ciphertext delivered by the Keeper cloud. The Data Key is never stored, and the user must authenticate with the SSO provider in order to retrieve the Device-Encrypted Data Key every login in order to decrypt their data.
- 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 in IndexedDB. The Elliptic Curve private key is stored in Chromium CryptoKey storage.
- Domain-to-Record mapping is stored via URLs hashed with HMAC_SHA256 using the Client Key.
The Keeper Web Vault implements a strict Content Security Policy that restricts the origin of outbound requests and prevents all scripts from being executed, except those explicitly sourced from Keeper, including inline scripts and event-handling HTML attributes, reducing or eliminating most vectors for cross-site scripting attacks.
Access to the keeper domain names is restricted to HTTPS with TLS v1.2 and is enforced by HTTP Strict Transport Security. This prevents a wide array of packet sniffing, data modification, and man-in-the-middle attacks.
Within the Keeper Browser Extension, Keeper will not prompt users to login to their vault from within the page frame area. Login to the extension occurs within the Browser Extension toolbar area of the browser. Login to the vault on the web browser will always occur either on the keepersecurity.com, keepersecurity.eu, keepersecurity.com.au, keepersecurity.jp, keepersecurity.ca or govcloud.keepersecurity.us domain, or from the Keeper browser extension toolbar which exists outside of the content page.
The Keeper Browser extension on Chrome, Firefox, Edge and Safari place an iFrame into the login forms of a web page to ensure that no malicious website has access to injected content. Record content injected into iFrames is also limited to the vault records stored in the user's vault which match the domain of the target website. Keeper will not offer Autofill of login or password data unless the website domain matches the website domain field of the Keeper vault record.
The Internet Explorer Extension uses a separate native application window for logging in and accessing records. These separate windows are not subject to XSS attacks because they are not accessible from the browser. This allows the Extension in Internet Explorer to provide a login window from inside the page. The extension will not show records unless the records match the website address root domain.
3rd party browser extensions may have elevated permissions in web browsers and can access information within the page. Therefore, it is recommended that Keeper administrators prevent users from installing 3rd party browser extensions from the browser's respective app store.
Background Scripts are run by the Browser Extension framework, which work with local storage and CryptoKey storage.
- Web Page scripts are added to pages and perform detection of fields.
- iFrame-injected documents process the Keeper user interface and user-initiated fill actions.
- Context menu (right-click) scripts are built from the Chrome extension background scripts.
- Browser Action (Toolbar) filling communicates with background scripts and manages the UI toolbar menu.
- Content scripts communicate with Background scripts via Chrome messaging APIs (chrome.tabs.sendMessage).
- The Browser Extension and Web Vault communicate with each other via native Port messaging on chromium browsers and window.postMessage on Firefox. Messages are encrypted with Elliptic Curve transmission keys.
- Background scripts communicate with Keeper's Zero-Knowledge backend API.
The Keeper Browser Extension (KeeperFill) provides customers with the ability to fill and save credentials from their vault into a target website login page.
The Autofill feature protects against XSS attacks using many techniques and advanced functionality including but not limited to the following:
- An iFrame is added into the login forms of a web page to ensure that no malicious website has access to injected content.
- Domain matching is performed to ensure that only matching records are available for Autofill. Keeper will not offer to fill passwords unless there is a root domain match.
- Customers may also enforce strict subdomain matching in role enforcement policies to restrict available logins based on exact subdomain match.
- Keeper will not autofill passwords on any non-secure (http://) website, without explicit forced consent by the user or the Keeper Admin.
Keeper Compliance Reports adheres to Keeper's Zero-Knowledge encryption model. From an encryption standpoint, here's how it works. When the Enterprise end-user logs into their vault, the Type, Title and URL fields are encrypted with the Elliptic Curve Enterprise Public Key. This data, we call the "Audit Data", is encrypted locally on the user's device and stored in the Keeper cloud. The Audit Data is continuously updated by the end-user devices over time.
The Keeper Administrator logs into the Admin Console using either a Master Password or Single Sign On. After a successful login, the Admin decrypts what we call the AES 256 Enterprise Tree Key and then decrypts the Elliptic Curve Enterprise Private Key. If the Administrator has permissions to run Compliance Reports, they can run a report over any user within the node that they have been granted permissions.
The encrypted audit data is delivered to the Admin Console and the Admin is able to decrypt audit data locally on their device using the Elliptic Curve Enterprise Private Key. The report contents are then displayed locally on the user interface and available for export into CSV, JSON or PDF format. Only the designated Keeper administrator can retrieve and decrypt the compliance report data for the nodes that they have been granted admin rights over.
Patent No | Abstract |
|---|---|
System and method for providing secure cloud based single sign-on connections using a
security service provider having zero-knowledge architecture. | |
System and method for a single sign on connection in a zero-knowledge vault architecture. | |
A method of detecting the existence of a
breached password in a zero-knowledge vault without disclosing any identifiable information about the password to the service provider or any outside party. | |
System and method for chat messaging in a
zero-knowledge vault architecture. | |
Method and apparatus for protecting account numbers and passwords. | |
Apparatus for selecting and displaying a file
associated with a current geographic location. | |
Method for facilitating quick logins from a
mobile computing device for autofilling login
credentials into websites and applications. | |
User-defined identity verification system. |
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 researchers and believe that an ongoing relationship with the cybersecurity 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 good-faith 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 [email protected] 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,
- 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.
bugcrowd
A: NO. We are Zero Knowledge and cannot decrypt customer data.
A: The Master Password is not stored and the encryption keys derived from the master password are not stored. When the user types in their Master Password, a key is derived in real time using a password derivation function known as PBKDF2. This key then unwraps the ciphertext to extract the Data Key which then unwraps the folder keys, record keys and record data.
Keeper uses 1,000,000 (1 million) PBKDF2 iterations.
If biometrics are activated and allowed by the Admin, a AES-256 "biometric key" is generated locally on the device and then stored in the iOS Keychain. When the user successfully authenticates with the operating system using Face ID or Touch ID authentication, the key is provided to the Keeper application and used to unwrap the stored ciphertext to retrieve the Data Key.
Keeper natively supports Windows Hello, Touch ID, Face ID and Android biometrics. Customers who normally login to their Keeper Vault using a Master Password or Enterprise SSO Login (SAML 2.0) can also login to their devices using a biometric. Biometrics must be enabled by the Keeper Administrator in the role policy. Offline access can also be achieved with a biometric for both Master Password and SSO-enabled users when this feature is activated.
A: Keeper has implemented multiple layers of protection against password stuffing and password brute force attack. We do not permit login on any device that has not been approved. Once approved, the first step is 2FA. One 2FA passes, only then can a user attempt a password test. After 10 failed password attempts, the account will become exponentially locked with each attempt. Keeper's self-destruct mechanism can also be enabled on the local device to delete locally stored data on 5 failed attempts. Read more about our Login API at this link.
A. Keeper does not permit login on any device that has not been approved. Once a device is approved (either through email verification, Keeper Push or 2FA code entry), the user will be prompted with 2FA. Keeper will lock an account after 10 failed 2FA attempts on an exponential basis for each failed attempt.
The Login API V3 makes major strides in the prevention of user enumeration against the Keeper cloud infrastructure. This means that the server will not disclose the existence or non-existence of a user's account. Enumeration is denied unless the user is logging in from a trusted/known device or IP.
Since Keeper operates several isolated data centers and enumeration between data centers is denied, there are some cases when a user must perform round trips and email verifications if they attempt to login from the wrong data center. Since disclosures cannot be made through the web interface, emails are utilized to communicate login and redirection.
A: When the user logs into their device, all of the Enterprise policies are downloaded from the Keeper Cloud and processed locally on the device for policies that require record-level filtering, URL filtering or password-specific rules and processing.
Account recovery can be disabled by the customer in the role policy section of the Admin Console. This may be desired if you are using SSO Cloud which utilizes a 3rd party identity provider.
The way account recovery works (with the Recovery Phrase method) is by storing a second copy of the user's data key that is encrypted with a 256-bit AES key generated from the user's 24-word recovery phrase. To complete a vault recovery, the user is required to (1) enter an email verification code, (2) pass the Two-Factor Authentication step (if enabled on the account) and (3) enter the recovery phrase locally on the device to decrypt the data key, which then allows the user to reset the Master Password. In addition to enabling Account Recovery, we recommend turning on Keeper's Two-Factor Authentication feature from the 'Settings' screen.
Enterprise customers who wish to disable account recovery and rely on the "Vault Transfer" admin feature are able to set this policy. Note that if account recovery is disabled, Vault Transfer is the only way that a user can be recovered if they forget their Master Password or if they lose access to the SSO IdP.
Business and Enterprise customers are provided a zero-knowledge method of account recovery for their users using Keeper's Account Transfer policy. This is described in detail at this link.
This section details the strength of Keeper's AES-256 encryption method (using Master Password authentication) versus the strength of ECC-256 (when using SSO authentication via Keeper SSO Connect).
For symmetric encryption, Keeper uses AES-256. The advanced encryption standard (AES) is assumed to be a pseudorandom permutation. By the PRP/PRF switching lemma this assumes key recovery requires brute force key enumeration.
Assume that:
- 1 ns/candidate key (this assumes 3 cycles/key and a 3GhZ CPU
- Attacker has 1 millions CPUs operating in parallel
AES-128 = 2^128 keys / (1 ns/key * 10^6) = 2^108 ns >= 10^16 years
AES-256 = 2^256 keys / (1 ns/key * 10^6) = 2^108 ns >= 10^54 years
AES-256 key enumeration is considerably longer than AES-128, and both require more computing resources than exist presently and more than 1 billion years of compute time. Key enumeration for either algorithm are considered improbable avenues of attack given the best known attacks against AES.
ECC-256 with AES-256
ECC-256 gives only 128b of key enumeration given the best known attacks against these elliptic curves. This is half the strength of AES-128. It is true that key enumeration attacks against ECC-256 are likely easier than attacking AES-256. However, the performance difference between AES-256 vs AES-128 is negligible, but the performance difference between ECC-256 and ECC-512 is noticeable and some libraries do not support 512b versions of elliptic curves, unfortunately.
ECC-512 Usage
As is noted above key enumeration attacks against AES-128 and AES-256 are impractical. But since the performance penalty is negligible and AES-256 is supported in all development libraries, the implementation is easy and standardized. Using ECC-512 is challenging since it's not universally supported and has noticeable performance penalties.
It's worth noting that the Bitcoin blockchain uses ECC-256. This creates a de facto 300 billion dollar bounty on the strength of 256b elliptic curves.
Strength of an AES key derived by PBKDF2 applied to a Master Password
No matter the size of AES key (128b, 192b, or 256b), if the AES key is derived from a password and key derivation function, the strength of the key is very likely to be bounded by the strength of the password combined with the complexity if the key derivation function.
The derived key will have strength equal to the (entropy of the password) plus log2(iterations) up to a maximum of 256 for AES-256.
- For 100,000 iterations: log2(10^5) = 16.6
- For 1,000,000 iterations: log2(10^6) = 19.9
An empirical study indicates that the average password used by humans is 40.5b of entropy. This implies that an AES key derived from an average strength password would be:
- For 100k iterations: 40.5+16.6 = 57.1b of entropy.
- For 1,000,000 iterations: 40.5+19.6 = 60.1b of entropy.
In comparison, a randomly generated ECC-256 key has 128b of entropy.
SSO Connect Cloud Security Model
https://docs.keeper.io/sso-connect-cloud/security-and-user-flow
If you have any additional questions or documentation requests, please email [email protected].
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 [email protected] 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 [email protected] 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].
Last modified 1mo ago