Boxcryptor’s New Single Sign-on with Zero-Knowledge Guarantee: This Is How It Works
Since 2017, Single Sign-on (SSO) has been an authentication feature available to companies in Boxcryptor. But now we have fundamentally reworked our setup, added SCIM and made the implementation process much easier for our customers.
Boxcryptor now supports SSO and SCIM. This may sound simple at first, but there is a lot of complexity behind it. Why? Because we offer encryption software and when it comes to encryption everything gets complicated quickly. But we have found a simple and secure solution to provide Single Sign-on and SCIM to our enterprise users while staying true to our zero-knowledge promise. The short answer is: our new Boxcryptor Crypto Server. The long answer is provided in this article.
Already since 2017 we have been providing an SSO solution for our customers. During this time, however, we have faced a number of challenges, especially in delivering this functionality while keeping our zero-knowledge promise. Read the article to learn about the improvements that the new solution brings.
Many companies rely on Single Sign-on for secure and user-friendly authentication. The advantages are clear: users do not have to create and manage passwords themselves, which increases password security. The administrator manages all users centrally, which gives the company full control and makes it easy to add or remove people. Every company member logs in to all services used in the company with one only a single password.
SSO protocols usually only take care of user authentication. But with Boxcryptor, it's different: The users’ password is not only necessary for authentication, but it is also an important part of the secure zero-knowledge encryption of the data. For this reason, the implementation and provision of SSO was much more complex for us at Boxcryptor.
Boxcryptor’s Zero-Knowledge Encryption
If Single Sign-on is not set up, all users have their own password for Boxcryptor. Values derived from the password are used for two operations: once for authentication (the user is allowed to log in) and once to manage and create the encryption keys (the user has the right to see the files unencrypted). When a new account is created, Boxcryptor creates a secure password hash and a password key. The password hash is used for authentication, the password key for encryption. The password and password key are never sent to the Boxcryptor servers.
The problem is, as already mentioned, that Single Sign-on only takes care of authentication. That means that we had to find a solution how SSO could be used to create additional encryption keys, to which only the customer has access.
Technical Requirements for SSO
In order to provide the encryption keys without us having access to them, companies themselves must provide two components. However, many large companies already have these components in place. Companies that want to use SSO need an Identity Provider (IdP) and a Key Management System (KMS). The Identity Provider is used to authenticate the users of the company. The KMS is necessary to create encryption keys to which we at Boxcryptor have no access. A third component necessary to keep our zero-knowledge promise is provided by us and hosted by our customers: The Crypto Server.
A Rocky Road to a Simple Solution: Challenges that Come with SSO with Zero-Knowledge Encryption
During the implementation of our first SSO solution for our enterprise customers, we had to solve a few problems to enable the use of Boxcryptor’s SSO with zero-knowledge guarantee. We have been able to gain a lot of important experience over the past years. With the new version of the SSO with SCIM it was even simpler for us to solve these challenges. The following questions had to be clarified:
How can we replace the password key? This was the first and biggest issue. The password key in the Boxcryptor client is normally derived from the password of each team member. But since no passwords are created in Boxcryptor with SSO, we had to find another solution. With SSO, a KMS hosted by the customer now creates one key per user, which is no longer dependent on or derived from a password.
Which Key Management Systems can be used? As many KMS as possible should be compatible with Boxcryptor’s SSO, both cloud and on-premise solutions.
How can we make sure that we never have access to the KMS ourselves? Here, the Crypto Server helps. It takes over the user authentication, as with the usual Boxcryptor server login via the Identity Provider (IdP).
How can we authenticate the users with the KMS, how do we communicate with the KMS? The users are authenticated via the Crypto Server. It provides a central interface for the communication between the Boxcryptor client and the KMS. This reduces the complexity of the clients, because new KMS interfaces only have to be implemented on the Crypto Server.
Server-to-Server Communication: KMS interfaces are often designed for server-to-server communication. However, our original SSO solution was implemented so that individual clients communicate with the KMS. With the new version, we have decided to interpose a server, provided by us, to communicate with the KMS. The Crypto Server was born.
CORS (security mechanism for client-server communication): In theory, we would have to set an "Allowed-Origin Header" in the KMS of the client, which allows the client (Boxcryptor) to access the KMS. This does not work with all KMS. Again, the Crypto Server allows access from our web application (our login process) to external services, taking CORS into account.
The Crypto Server: Self-Administered Key Management
The Crypto Server is a new, central component of the Boxcryptor single sign-on. It offers a uniform interface for communication between the Boxcryptor client and the KMS, which is necessary for authentication and key management (creating, encrypting, and decrypting keys). Thanks to the Crypto Server, companies are flexible in their choice of their KMS. The CORS handling is in our hands. Furthermore, thanks owing to the Crypto Server, it is possible to keep the zero-knowledge promise, even when using SSO. Finally, the company’s KMS only has to communicate with one client (the Crypto Server) instead of with each individual client (each user in the company). This is much cheaper in terms of licensing than if each client communicates with the KMS individually.
Thanks to the Crypto Server, we can configure everything necessary for SSO easily and quickly for the client. In this way, we add something to our customers’ infrastructure (the Crypto Server and the KMS configuration for the Crypto Server), but we do not have to fundamentally change anything existing.
Boxcryptor’s SSO: Central Authentication with our Zero-Knowledge Promise
To improve the communication between the KMS and the Boxcryptor clients, as well as to simplify the setup of SSO for our customers, we have developed the Crypto Server. This is how authentication with Boxcryptor’s Single Sign-on works in detail:
The Boxcryptor client (the Boxcryptor Software for Windows, macOS, iOS or Android) is the starting point, because this is where the user wants to log in with SSO.
The Boxcryptor client authenticates the user at the Boxcryptor server via the Identity Provider (IdP). For that purpose, the client requests the encrypted keys from the Boxcryptor server and gets additional information about the crypto server, where it is located and how it can be accessed.
Next, the Boxcryptor client authenticates the user at the Crypto Server. This also happens via the IdP with the same protocol (SAML).
The Boxcryptor client can now use the information from the Crypto Server to decrypt the password key. This process takes place exclusively in the customer’s system. Hence, the client sends the request to decrypt the password key to the Crypto Server. The Crypto Server knows where the KMS is located and forwards the request accordingly. The KMS sends the decrypted key to the Crypto Server, which forwards it to the client.
This way, the Boxcryptor client gets the decrypted version of the password key, the user can log in and is now able to encrypt and decrypt data. The Boxcryptor server never gets insight into this process, which means that we at Boxcryptor never see the decrypted version of the password key and, therefore, can never access any user data.
Other Advantages of the Crypto Server Setup
With the Crypto Server, in contrast to our old SSO solution, we only use one protocol for authentication for both servers (Boxcryptor server and Crypto Server): the SAML protocol. This is an authentication standard that works both in the cloud and on-premise, making our SSO compatible with many KMSs and IdPs. Thanks to the Crypto Server, the KMS communication is now server-server communication. This is an advantage because some KMSs are not suitable for client-server communication. Also, CORS handling is significantly simplified, because the Crypto Server sets the CORS header.
Due to our changes, Boxcryptor’s SSO can be set up as a hybrid solution: Boxcryptor remains a cloud service, but the Crypto Server, which is essential for the zero-knowledge guarantee, can be set up on-premise or in the cloud, depending on the customer’s preference. The most important thing is that no matter which setup is used, the password keys remain exclusively on the customer’s systems and never end up on the Boxcryptor server.
SCIM: Group Management Simple and Secure with the Crypto Server
SCIM enables administrators to manage users and groups easily and centrally. The users and groups created in the company are passed on by the IdP to the Boxcryptor server. But with Boxcryptor, the SCIM setup is a special case as well, due to zero-knowledge. However, the Crypto Server also helps here.
Without SCIM we work with the group owner concept: From the password of the user who creates the group a password key, a user key pair, a group membership key, and a group key pair are derived. With SCIM, the Crypto Server replaces the Boxcryptor client again. In detail this means:
(1) The Identity Provider contacts the Boxcryptor server and asks it to create or modify the following user or group. However, the Boxcryptor server itself should not be able to perform this operation, because since we do not want the Boxcryptor server to have access to the keys due to our zero-knowledge promise.
(2) The Boxcryptor server therefore forwards the request to the crypto server and asks it to create new keys.
(3) The crypto server creates the keys but only sends the encrypted versions back to the Boxcryptor server. This is how all operations work in detail:
- Adding new users: The IdP sends a request to the Boxcryptor server to create a new user. The Boxcryptor server then requests the crypto server to create a new password key and user key. The Crypto Server now requests the KMS to create a KMS key for this user and at the same time creates a randomly generated password key, which the KMS encrypts with the KMS key. Then the Crypto server creates a randomly generated user key and encrypts it with the password key. The crypto server now sends the encrypted password key, the encrypted user key and the ID of the KMS key to the Boxcryptor server. Now the Boxcryptor server can create the user with the encrypted keys.
- Creating new groups: Since the administrator does not need to create groups in Boxcryptor thanks to SCIM, there is the scenario that a group is created without an existing user (in this case the admin or group owner). With SCIM, the crypto server creates an initial group membership key instead and encrypts it with a KMS key. This way, an initial user key is no longer necessary. The crypto server also creates the keys for group administration together with the KMS.
- Adding a user to a group: The Boxcryptor server sends the encrypted password key, the encrypted user key, and the encrypted group membership key to the crypto server. The crypto server decrypts the password key and the group membership key using the KMS. Now the user key is decrypted with the password key. With the user key the group membership key is re-encrypted. After that, tThe encrypted group membership key is now sent back to the Boxcryptor server, which can now create the new group membership for the user. Now the user has access to the group.
(4) The Boxcryptor server now has the metadata of the user and the encrypted keys. Hence, iIt can now store the user, the groups, and the details of the group membership.
Advantages of this SCIM setup
With SCIM, the Boxcryptor admin does not have to create users actively in Boxcryptor anymore, but only once centrally in the SCIM user management. An additional advantage is that the key creation is synchronous, because the Boxcryptor server can communicate with the crypto server at any time. The final state (the new or changed groups and users) is therefore always immediately available on the Boxcryptor server.
With our new SSO setup, our customers can integrate Boxcryptor Enterprise into their infrastructure more easily and quickly, adding and managing as many users as needed. To sum it up: Boxcryptor is the only cloud encryption solution that enables the protection of corporate data with zero-knowledge guarantee, while using SSO and SCIM.
Más información sobre Boxcryptor for Teams
Haga de la protección de datos una prioridad para prevenir de forma fiable los posibles daños a su empresa. Boxcryptor Company y Boxcryptor Enterprise le ayudan a sacarle provecho a la nube mientras cumplen las pautas de cumplimiento internas y externas.