Security and User Flow
Technical description of Keeper SSO Connect Cloud
Zero-Knowledge Architecture
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.
Encryption Model for SSO Connect Cloud
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).
SSO Connect Cloud Encryption Model
Security for SSO Connect Cloud
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.
Device Approval
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.
Login Flows
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
Additional Security Details
To learn more about the Keeper Encryption Model, see the below link:
https://docs.keeper.io/enterprise-guide/keeper-encryption-model
Security Model Questions and Answers
Q: When an admin approves a new user device via the Keeper Web Console, how is the user’s encrypted data key transferred to the new device?
Each device has a unique Elliptic Curve (EC) public/private key pair generated locally on the device. The public key is stored on the server. When the user requests a device approval, the new device public key is sent to the server. The Admin who has "device approval" permissions has the ability to decrypt the user's Data Key during device approval processing. When the admin reviews and approves the device, the user's Data Key (DK) is re-encrypted with the new device's (EC) public key and the encrypted Data Key is stored on the server associated with that user's device, also sent to the new device. The new device decrypts the Data Key with the device's (EC) private key.
Q: Is the data key decrypted in order to encrypt with the new device’s private key?
The Admin decrypts the data key in memory and re-encrypts it with the new device's public key inside the Admin Console when performing an approval. After the user signs into SSO, the server verifies the attestation then the encrypted Data Key is provided to the new device. The device then decrypts the Data Key with the local EC private key. Every time the user logs in and verifies the attestation from the IDP, the encrypted key is provided to the device, and decrypted in memory, then used for encrypting/decrypting record keys, folder keys, etc.
Q: Where is the data key when it is in its decrypted state?
It's never stored in a decrypted state. The Encrypted Data Key is stored on the cloud, encrypted with the device public keys. So if the user has 10 devices, we are storing 10 encrypted Data Keys, encrypted with each of the device public keys. The re-encryption of the Data Key always takes place locally on the device either by the user, or by the Admin to preserve zero knowledge.
Q: For the Automator approval of a new user device, same question, where is the crypto operation happening for the user's data key?
The Automator runs the exact same process, it decrypts the user's Data Key at the time of the request, verifies the attestation, re-encrypts the data key with the new device EC public key, then transfers the encrypted data key to the user's device.
Q: What happens if a user has data encrypted in their vault, but has no available devices to perform the sharing of the user's data key?
The Automator and the Admin can always perform a device approval if the user loses all of their devices.
Q: Do new and old user devices both have to be online to add a new device?
No, the approval can occur asynchronously.
Q: If the data key is only ever decrypted on device, then it seems like the old device needs to be online to encrypt the data key with the new device’s public key?
The entire approval process can be performed in real time or in separate steps. The apps will prompt users upon login for the approval, encrypt the data key with the new public key, and send it up to the server. Here's a video of the process:
Last modified 13d ago