(1) SSO with Boxcryptor requires an identity provider, key management service, and optionally a device management system.
(2) From a user's perspective, SSO allows them to log into Boxcryptor with their email and be redirected to the identity provider to enter a common password without needing a separate Boxcryptor password.
(3) From an admin's perspective, SSO means they do not have to manually add each user to Boxcryptor and users will not have separate Boxcryptor passwords to forget or lock themselves out of.
2. 2
Overview
S S O w i t h B o x c r y p t o r
Table of Content
• Preconditions for Boxcryptor SSO
• SSO from a user’s and from an admin’s perspective
• The special case of SSO with encryption and zero knowledge
• SSO and encryption – How we handle key management
• SSO and zero knowledge – Why you need a device management service
• Conclusion
3. 3
What do you need to implement SSO with Boxcryptor
S S O w i t h B o x c r y p t o r
• Identity Provider (IdP or “SSO Provider”)
Boxcryptor is compatible with any SAML-based SSO solution
Examples: Active Directory Federation Services (ADFS), Azure Active Directory (Azure AD), Okta, PingIdentity, OneLogin, LastPass, etc.
• Key Management Service (KMS)
Examples: Hashicorp Vault (On-Premise), Amazon KMS (Cloud), Azure Key Vault (Cloud), etc.
• Device Management System
Optional
Examples: Active Directory (Desktops), MobileIron (Mobile), etc.
4. 4
SSO from a User’s Perspective
S S O w i t h B o x c r y p t o r
(1) The user logs into Boxcryptor with his/her email address.
(2) The user is redirected to the company’s Identity Provider (e.g. Active Directory).
(3) The user enters his/her common password for all applications in the company.
5. 5
SSO from an Admin’s Perspective
S S O w i t h B o x c r y p t o r
• The admin adds the user to the company’s SSO solution.
• The admin does not have to go to the Boxcryptor app and add the user there.
• The user does not need a Boxcryptor password and therefore cannot forget it or accidentally
lock himself out of his account.
Note: With the new SSO it is also possible that companies manage and store their own keys in-
house. Therefore, it becomes even simpler to meet compliance standards.
7. 7
SSO and Zero Knowledge Encryption
S S O w i t h B o x c r y p t o r
Standard SSO protocols only handle user authentication, but Boxcryptor also needs zero
knowledge key management for decrypting and encrypting. Therefore, creating a zero knowledge
SSO solution is more complex.
8. 8
Zero Knowledge Encryption without SSO
S S O w i t h B o x c r y p t o r
• Every Boxcryptor user has his/her own password.
• Derivations of single user’s passwords are used for two operations: authentication and
encryption key management.
• When an account is created, Boxcryptor generates a secure password hash and a password key.
• The password hash is used for authentication.
• The password key is used for encryption.
SSO: Authentication is handled by every standard SSO solution. For key management
(encryption) after the zero knowledge paradigm we had to develop a new solution.
9. 9
Encryption – Key Management with SSO
S S O w i t h B o x c r y p t o r
Pre-condition: The Company has a Key Management Service (KMS), because we need another
entity to hold the “password key”. We cannot do it, because then we would be able to use it.
Examples of key management services:
• Amazon KMS
• Azure Key Vault by Microsoft
• Open Source KMS “Vault” by HashiCorp
10. 10
Encryption – Key Management with SSO
S S O w i t h B o x c r y p t o r
• Your KMS creates a user key for each user.
• The KMS sends an ID of this key to Boxcryptor (to the device of the user).
• On the device of the user, Boxcryptor creates a second, secure “password key”.
• Boxcryptor sends this “password key” and the ID of the user key to the KMS.
• The KMS encrypts the “password key” with the user key created earlier.
Result: An encrypted version of the random “password key”. We will store this version and the ID
on our server.
11. 11
What Happens When a User Signs in
S S O w i t h B o x c r y p t o r
• When a user attempts to sign in, the Boxcryptor client requests the encrypted “password key”
and the ID from our server. It sends both to the KMS, which will return the “password key” to the
client.
• The “password key” is used to derive all other keys that Boxcryptor needs to encrypt files or
manage permissions and groups.
Result: Key management is handled only between the user’s device (client) and your KMS.
12. 12
What Happens When a User Signs in
S S O w i t h B o x c r y p t o r
(1) Request encrypted “password key” and ID from the Boxcryptor Server
(2) & (3) Request and reception of the “password key“ via KMS
13. 13
Zero Knowledge SSO
S S O w i t h B o x c r y p t o r
An important factor for zero knowledge is that we do not have access to the company’s KMS. This
can be achieved by:
• Network access restriction: The KMS is only accessible within the company’s firewall.
• Device Management System: The KMS configuration is not stored on our servers in plaintext,
but encrypted with another key that we do not know: The key store key. Only in combination
with this key, the KMS configuration can be read in order to access the KMS. The key store key is
installed on the user’s device with a certificate, handed out by your company’s central device
management system.
Result: Only devices of the company can decrypt and encrypt files.
14. 14
Zero Knowledge: A Device Management System
S S O w i t h B o x c r y p t o r
(1) Reception of the key store key from the company‘s device management system via certificate
(2) Request & reception of the encrypted KMSConfig. from the Boxcryptor server
(3) Decryption of the KMSConfig. with the key store key on the user’s device: access to KMS
15. 15
Conclusion
S S O w i t h B o x c r y p t o r
• Pre-conditions for Boxcryptor SSO:
Identity Provider
Key Management Service
Device Management System (optional)
• Standard SSO handles user authentication
• Boxcryptor SSO handles zero knowledge encryption key management as well
• This is achieved with a KMS and (optionally) a Device Management System