Security and User Flow
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 (in the SSO Cloud model)
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 controlled by the user (and the Enterprise Administrator)
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.
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.
Different devices/platforms have varying levels of security, and so in order to provide optimal security we recommend using an up-to-date Chromium-based web browser.
As general protection against compromised device attacks, we also recommend that all devices (such as desktop computers) are protected with disk-level encryption and up-to-date anti-malware software.
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 both SP-initiated and IdP-initiated login flows, described below.
1) SP-initiated Login (using "Enterprise Domain")
From Keeper, user types in the "Enterprise Domain" on the vault login screen
Keeper retrieves the configured SAML Login URL for the Keeper SSO Cloud instance (for example, https://keepersecurity.com/api/rest/sso/saml/login/12345678)
User is redirected to the SAML Login URL
Keeper sends an encoded SAML request to the IdP with the Entity ID and our public key, along with a "Relay State" which identifies the session.
User signs into the IdP login screen as usual
After successful sign-in to the IdP, the user is redirected back to Keeper at the pre-defined "ACS URL" (this can be via "Redirect" or "Post", depending on the IdP configuration).
The SAML message from the IdP to Keeper contains a signed assertion that validates the user has successfully authenticated at the IdP. Keeper validates the signed assertion.
SAML Attributes "First", "Last" and "Email" are provided by the IdP to Keeper.
Keeper SSO Connect Cloud redirects the user to the vault
If the user's device is not recognized, Keeper performs device verification (via "Keeper Push" or "Admin Approval")
After successful device verification and key exchange, Keeper provides user with Encrypted Data Key
User decrypts their data key locally with their Device Private Key
User decrypts their vault with their Data Key
2) SP-initiated Login (using Email)
From Keeper's vault login screen, user types in their email address
If the user is using a verified device, the email is looked up and converted into a SAML Login URL
If the device is not recognized, Keeper looks at the domain portion (@company.com) and retrieves the configured SAML Login URL for the Keeper SSO Cloud instance (for example, https://keepersecurity.com/api/rest/sso/saml/login/12345678)
User is redirected to the Keeper Login URL
Same steps as SP-initiated Login are followed.
3) IdP-initiated Login
User logs into the Identity Provider website (e.g. https://customer.okta.com)
From the identity provider portal, the user clicks on the Keeper icon
The user is redirected to Keeper at the pre-defined "ACS URL" (this can be via "Redirect" or "Post", depending on the IdP configuration).
The SAML message from the IdP to Keeper contains a signed assertion that validates the user has successfully authenticated at the IdP. Keeper validates the signed assertion with the IdP's public key and we ensure that the assertion has not been tampered with. Keeper also verifies the message is signed with our public key.
SAML Attributes "First", "Last" and "Email" are provided by the IdP to Keeper.
Keeper SSO Connect Cloud redirects the user to the vault
If the user's device is not recognized, Keeper performs device verification (via Keeper Push or Admin Approval)
After successful device verification and key exchange, Keeper provides user with Encrypted Data Key
User decrypts their data key locally with their Device Private Key
User decrypts their vault with their Data Key
To learn more about the Keeper Encryption Model, see the below link: https://docs.keeper.io/enterprise-guide/keeper-encryption-model
