- About Us
If you would like to learn more about how Boxcryptor works, the following information will be of your interest - going deeper into certain technical aspects.
Please first take a look at the following table with important terms you would like to know when reading the different topics.
Important terms specific for Boxcryptor software:
|File key||AES encryption key used to encrypt or decrypt a file. Every file has its own unique and random file key.|
|User keys||Every user has its own pair of RSA-4096 keys (private and public) and additional AES-256 keys.|
|Password key||An AES encryption key derived from a password using the key stretching and strengthening function PBKDF2 with HMACSHA512, 10.000 iterations and a 24 byte salt.|
|Group key||Similar to users, every group has also its own pair of RSA-4096 keys (private and public) and additional AES-256 keys. Furthermore every group has its own unique and randomly generated membership key.|
|Company keys||A company can have its own pair of RSA-4096 keys (private and public) in case the master key policy is used.|
Boxcryptor implements a combined encryption process based on asymmetric RSA and symmetric AES encryption. Every file has its own unique random file key which is generated when the file is being created. The file key is used to encrypt and decrypt the contents of the file as follows:
The Boxcryptor user management has the following concepts:
Example: If Alice adds Bob to her group, the group's membership key is encrypted with Bob's public RSA key. Now Bob is able to decrypt the membership key and thus the groups' private RSA key.
NOTE: The additional AES keys have been introduced after the initial release of Boxcryptor and existing accounts are upgraded on an ongoing basis. Due to legacy reasons, the filename key is additionally encrypted with the public RSA key - referred to as "AES key" in previous versions of this documentation.
If Alice shares access to a file with Bob, Boxcryptor executes the following steps:
If Alice shares access to a file with a group where Bob is member, Boxcryptor executes the following steps:
Boxcryptor is a zero-knowledge service provider because any private and sensitive information that we receive from the users will always be in the encrypted form protected by the user’s password - which is never transferred to us or anyone. Only public keys are in plain text.
This is how it works:
Passwords, password keys and file keys never leave the users' devices and are never transferred anywhere or to anyone. On the other hand, user keys, group keys, and company keys are stored on the Boxcryptor Key Server in encrypted form. As we are a zero-knowledge service provider, prior to submission, all sensitive information (e.g. private RSA keys or wrapping keys) is encrypted using keys which are never submitted to the Boxcryptor Key Server (such as personal passwords) or require access to keys which are never available in plaintext to the Boxcryptor Key Server (like membership keys or wrapping keys).
The starting point for every decryption process is the user's password key as this one is required to unlock the private key and the wrapping key which are then required to unlock all other keys in the system (AES keys, file keys, membership keys, group keys, etc.). The password key however never leaves the user's device. So even though the Boxcryptor Key Server stores keys for all users, Boxcryptor is a zero-knowledge service provider because the sensitive keys are already received from the users in encrypted form. The only types of keys stored in plaintext on the Boxcryptor Key Server are public keys which do not contain any sensitive information and, as these are public, do not need to be kept confidential.
Boxcryptor offers a special company account with additional features especially designed for companies: E.g. password reset, policy management, and a master key. The master key feature gives companies the power to decrypt every file which is accessible by the users of the specific company - without having to know the passwords of its users. When using a master key, companies can ensure that the company does not lose access to its property (files) even in complicated situations such as when a user forgets his/her password or leaves the company. The following is an example if the master key is enabled:
User Alice belongs to the company and sets or changes her password
Company requires access to one of Alice's files
Due to Boxcryptor's zero-knowledge nature, if a user forgets or loses his/her password the user loses access to his files. Without the password, it is not possible to decrypt the user's private key and thus it's not possible to decrypt the files. However, if a company has enabled the master key feature, the company can also make use of the password reset feature. The master key feature gives administrators of the company the power to decrypt private keys of all users which belong to the specific company. This also gives the company the possibility to set a new user password by simply re-encrypting the user's private key with a new password:
Example: User Alice belongs to the company and lost her password
A user's password never leaves his/her device and Boxcryptor never submits the password anywhere. The user's password is used for two purposes: User authentication and decryption of the user's private key. In both cases, Boxcryptor does not use the password itself, but derivates of the password which are called the password key and password hash. These are explained as follows
Boxcryptor uses the key stretching and strengthening standard PBKDF2 with HMACSHA512, 10.000 iterations and a random 24 byte salt to derive a strong encryption key from the password. The password key is used to decrypt the user's private RSA key.
PBKDF2 with HMACSHA512 and 5000 iterations is also used to derive the password hash from the password but a different salt is used. To derive the password hash, a salt is used which is the combination of the user's email address and an application specific salt. The password hash is used to authenticate the user.
When a user creates a Boxcryptor account, Boxcryptor derives the password hash from the user's password. This password hash is used for all subsequent authentication operations. Only a hash of the password hash is stored on the Boxcryptor Key Server - the password hash itself is never stored. This is how it works:
A user creates a Boxcryptor account
A user logs in and authenticates himself
Note: This process is only required to authenticate the user against the Boxcryptor Key Server - not to get access to the encrypted files. Access to the encrypted files always relies on the correct decryption of the user's private key which requires the knowledge of the correct password. Even if an attacker would be able to fake authentication (e.g. by hacking the Boxcryptor Key Server) he would not be able to decrypt a single file without knowing the correct password only known by the users.
In order to provide a seamless user experience over a number of different devices and with core features such as file access sharing, Boxcryptor needs to store user data on the Boxcryptor Key Server. This data includes:
Due to Boxcryptor's zero-knowledge nature, all sensitive information received by the Boxcryptor Key Server is already encrypted (e.g. public RSA keys) or otherwise non-retrievable (e.g. password hash) and thus secured. In order to further increase security, all sensitive (e.g. key data) and also personal information (e.g. email addresses) is additionally encrypted before persisted to the database. The database encryption key is only available to the application during runtime. In case of a database breach an attacker would only be able to get access to encrypted data. See table below with some examples of how the information is saved on the server:
|The email address "user(at)example.org" is stored in the database as the string "SLMIL5crw/YIWDoZLU5ehifcoOsTsyg"|
|Private RSA key||The user's private key is already encrypted with the user's password on the client (user device). The encrypted private key is then encrypted again with the database encryption key|
|Password||The password is hashed already on the client (users device). The password hash is hashed again on the server and the hash of the password hash is then encrypted with the database encryption key|
Boxcryptor requires an internet connection to send and receive data to and from the Boxcryptor Key Server as explained in "Which data is stored on the Boxcryptor Key Server". Specifically, the following use cases require an internet connection:
After completing the sign-up form and creating the user keys locally on the device, Boxcryptor sends the (encrypted) user information as outlined above to the Boxcryptor Key Server to create the account.
When logging in with the existing Boxcryptor account on a new device, Boxcryptor authenticates the user based on his credentials (email, password hash) and retrieves all information about the user (e.g. first name, groups, etc.) and all key data for the user (e.g. user keys, group keys of user's groups, etc.) and stores this information locally on the device.
When sharing a file or folder with another user, Boxcryptor retrieves the public key of the sepcific user from the Boxcryptor Key Server.
Creating, editing, or deleting a group or its group members requires access to the Boxcryptor Key Server.
While Boxcryptor is running, tries to continuously sync all user information and key data for the currently logged in user if an internet connection is available.
Besides the use cases described in "Why and when Boxcryptor requires an internet connection", Boxcryptor does not need an internet connection - especially the encryption and decryption processes do not require an internet connection. Once a user has installed Boxcryptor in his/her computer and has successfully logged-in- the user's keys are transferred to the device and Boxcryptor will be fully functional to encrypt and decrypt files regardless of the internet connection. Only the use cases listed on the above mentioned section cannot be executed without a connection to the Boxcryptor Key Server.
Users that are required to keep physical control over their user information and keys can choose to use Boxcryptor with a local account instead of a Boxcryptor account stored at the Boxcryptor Key Server. When using a local account, all user information and key data is stored in a key file on the local device instead of being transmitted to the Boxcryptor Key Server. Local accounts can be converted to Boxcryptor accounts (and vice versa) at any time.
Sharing access to files and folders is not available when using a local account because it requires Boxcryptor accounts and access to the Key Server. Additionally, it's the user's responsibility to take care of the key file - copying it to other devices, creating backups, etc. If the key file is lost, access to all encrypted files will be lost! (Tip: As the sensitive information in the key file (e.g. private keys) is encrypted, users can store the key file in their cloud storage.)
In order to perform the actual "low level" encryption and random number generation, Boxcryptor relies on established and proven third-party libraries. Depending on the platform and purpose, Boxcryptor uses either popular open source libraries or libraries which are part of the underlying operating system. The following libraries are used:
Sign up for our newsletter to stay informed with the latest Boxcryptor news, product updates and special offers.