Boxcryptor’s Single Sign-on with Zero-Knowledge Guarantee: This Is How It Works

Since the introduction of Boxcryptor Enterprise, Single Sign-on (SSO) has been an authentication feature available to companies in Boxcryptor. In June 2020 we 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 as providers of encryption software we must stay true to our zero-knowledge promise. This means that authentication, encryption, and key management must function in such a way that we never hold keys or passwords in plain text ourselves. How we managed that? The short answer is: with our new Boxcryptor Crypto Server. The long answer is provided in this article.

SSO: The One Password Solution

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 signs in to all services used in the company with only one single password.

Boxcryptor’s Zero-Knowledge Encryption

Without Single Sign-on enabled, only the individual user password is required for Boxcryptor’s encryption to work. Values derived from the password are used for two operations: authentication (the user is allowed to sign in) and to manage and create the encryption keys (the user has the right to see and access the unencrypted files).

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 as all encryption happens locally on the user’s device.

The problem is, as mentioned above, that Single Sign-on only takes care of authentication. That means that we had to find a solution how SSO could be used additionally to create encryption keys, to which only the customer has access.

Technical Requirements for SSO

To keep our zero-knowledge promise while still enabling an SSO solution, Boxcryptor additionally requires two components on the company side, which many large companies already have in use. A third component is also provided by Boxcryptor:

• The Identity Provider (IdP) enables the authentication.
• The Key Management System (KMS) creates keys to which we at Boxcryptor have no access.
• The Crypto Server is provided by Boxcryptor but hosted exclusively by the company.

Challenges for SSO with Zero-Knowledge Encryption

We have developed the SSO integration for Boxcryptor to offer the best possible security with the greatest possible ease of use. For this, we were able to successfully resolve the following issues through the SSO with SCIM:
How can we replace the password key? Normally, the password key is derived from the password of each team member in the Boxcryptor client. With SSO, the KMS, which is set up on the customer’s own infrastructure, creates a key for each user. This key is now independent of the password.

Which Key Management Systems can be used? Our goal is to support as many KMS as possible—both cloud and on-premises solutions.

How can we make sure that we never have access to the KMS ourselves? This is where the Crypto Server helps. It handles user authentication via the identity provider (IdP) within the company's infrastructure. The Boxcryptor server is not contacted.

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 communication between the Boxcryptor client and the KMS. This reduces the complexity of the clients, as new KMS interfaces only need to be implemented on the Crypto-Server.

Server-to-Server Communication: Most KMS interfaces are designed for server-to-server communication. However, our original SSO solution was implemented in such a way that the individual clients communicated with the KMS. The Crypto Server now handles this as a central interface. This also reduces licensing costs.

The Crypto Server: Self-Administered Key Management

The Crypto Server is the innovative and central component of the Boxcryptor SSO setup. 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.

There are also advantages in terms of licensing costs, as the company’s KMS now only has to communicate with a single client—the Crypto Server. Previously, each individual Boxcryptor client, i.e. all users, had to be licensed individually.

The Crypto-Server allows us to configure everything needed for SSO easily and quickly for our enterprise customers. After adding the Crypto-Server and the KMS configuration for the Crypto-Server to the customer’s infrastructure existing KMS and IdP can also be used with Boxcryptor without extensive customization.

Centralized Authentication with Zero-Knowledge Promise

The Crypto Server mainly improves the communication between KMS and the individual Boxcryptor clients on the end devices. In addition, it also simplifies the SSO setup overall. Here's how authentication with Boxcryptor's single sign-on works in detail:

The Boxcryptor client is the starting point where company employees log in with the SSO password. The Boxcryptor client authenticates the user at the Boxcryptor server via the IdP (1). For that purpose, the client requests the encrypted keys from the Boxcryptor server and also obtains information about the Crypto server, where it is located and how it can address it.

Next, the Boxcryptor client authenticates the user at the Crypto Server (2). 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 infrastructure. Hence, the client sends the request to decrypt the password key to the Crypto Server (3). The Crypto Server knows where the KMS is located and forwards the request accordingly (4). The KMS sends the decrypted key to the Crypto Server, which forwards it to the client (5).

This way, the Boxcryptor client gets the plaintext version of the password key, the user can log in and is now able to encrypt and decrypt data (6). 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 we only use a single 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-premises, making our SSO compatible with many KMSs and IdPs.

Furthermore, the Crypto Server means that communication with the KMS takes place from server to server. This is advantageous as some KMS are not suitable for client-server communication.

SCIM: Group Management Made Simple and Secure

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. However, even with SCIM, the setup at Boxcryptor is a special case due to the zero-knowledge guarantee, which the Crypto Server solves.
Without SCIM Boxcryptor utilizes the group owner concept: Keys needed for group management are derived from the group creator’s password: a password key, a user key pair, a group membership key, and a group key pair. 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, the 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, it can now store the user, the groups, and the details of the group membership.

Advantages of the 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.

A Plan to Match Your Ambitions

With our SSO setup, our customers can integrate Boxcryptor Enterprise into their infrastructure more easily and quickly, adding and managing as many users as needed. This also removes limits on the possible number of members of a Boxcryptor organization, although the security level is maintained—an ambitious goal.

Robert Freudenreich, CTO and co-founder of Secomba, about SSO and Boxcryptor Enterprise:

The number of our customers is growing steadily and quickly and with it, the size of the businesses protecting their cloud with Boxcryptor. One important requirement for those larger organizations is to be able to quickly and simply add and manage their users. We are very proud that we managed to create an SSO solution that can handle encryption and security operations while staying zero knowledge.

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.