An entity like user, group and company does not have the same set of keys at any given time. Here we developed quantum resistant symmetric key cryptography with the qualities of asymmetric key cryptography as well. Individuals, developers/businesses and enterprises are identified via attributes. These facilitates an inbuilt identity access management (IAM) with primary ID to cover multi factor authentication derivatives. For example a user will always have a name (What You Have), password (What You Know) and fingerprints (What You Are). As you can see an enterprise will equally have corresponding attributes but not exactly the same.
User keys, group keys and Master Key
User keys: Every user has its own pair of ECSMID keys (private and public) and 2048 bits AES derived keys for volumetric encryption.
Business keys: Every user has its own pair of ECSMID keys (private and public) and 2048 bits keys for volumetric encryption. Furthermore every group has its own unique and randomly generated keys.
Enterprise Keys: A company can has its own pair of ECSMID keys (private and public) and 2048 bits keys for volumetric encryption. They can share files with anyone that is registered to use their applications i.e Anyone who they shared the key generators with.
Lokdon uses 8 times the capacity of the current day AES. The is an addition lay of security which introduces simpler non-repudiation scheme. Keys used in Lokdon applications and continuously changing. They are generated on the fly and are never saved. This makes them so volatile that a character written which this algorithm will show up different for each output level and instance. There are five input modes in the Lokdon encryptIon standard. Each mode uses 2048 bytes or 680 digit long characters. One mode’s output serves as the input to the succeeding mode except for the first one. Basically you have m1, m2, m3, m4 and m5. Generally, keys are never re-used for any purpose; there are multiple keys for a single purpose. Currently, additional AES keys are used for profile or users attributes which has the potential to grow in the future.
Additional AES keys
File key: The derived AES encryption key used to encrypt or decrypt a file are unique and thus produces random key at every instance of generation. They are never saved anywhere.
Password key: An AES encryption key is not derived form your password. The key is created using knight’s tour solution stretching and strengthening function PBKDF2 or SHA-2 with HMAC, 10.000 iterations. Hashing is used for message integrity check only.
All data stored on our nodes are encrypted. In order to provide a seamless user experience over a number of different devices and with core features such as file access sharing, Lokdon needs to store some encrypted data on its endpoints or nodes.
General user data that we store
We only store encrypted data; a small amount of information of each user, group and company. The information is necessary to authenticate you as a user at sign in.
Keys and additional values
Additionally, we do not store keys and values that are necessary for encrypting and decrypting processes. There are upset pointing to how to derive the keys.
Data we store when you are part of a group
If you are a member or owner of a group, some more keys are created that we store on our servers as well.
li>Private RSA key or M3PIN intermediate representation(IR)
Data we store if you are part of a Lokdon Company Team
When you are using the Boxcryptor Company, this additional data is stored on our servers.
li>Private RSA key or M3PIN intermediate representation(IR)
Due to Boxcryptor’s zero-knowledge nature, all sensitive information that reaches the Boxcryptor server is already encrypted (for example private RSA keys) or otherwise non-retrievable (for example the password hash). In order to further increase security, all sensitive data and personal information is encrypted additionally, 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.
Of the data that we store, your email address, your private RSA key and your password are the most sensitive values. This is how we protect them.
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.
The password is already hashed on the client (the user’s 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.
p>Lokdon is a ZT-flow provider. Any private and sensitive information will always be in encrypted form, protected by the user’s attributes – which we do not know and have no way of finding out. Only public keys are open to the public as a part of digital data nucleic authority (DDNA). At that it is still not in plain text.
Passwords, password keys and file keys never store on the users’ devices and are never transferred anywhere or to anyone. No key is stored on the Lokdon servers. All encryption operations take place on your device – never on our server or elsewhere.
The starting point for every decryption process is whatever was predetermined by users. The password key, however, never leaves the user’s device. The only types of keys stored in plaintext on the Lokdon is whatever the user requires. More so, non sensitive information could be kept in plain text. They do not need to be kept confidential.
A user’s password never leaves his or her device and Boxcryptor never submits the password anywhere. The 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 derivatives called the password key and password hash.
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 are also used to derive the password hash from the password. However, in this case, a different salt is used. To derive the password hash, a salt, which is the combination of the users email address and an application specific salt, is used. The password hash authenticates the user.
In conclusion, your password is hashed and sent to us in this hashed form, when you want to authenticate yourself during sign in to Boxcryptor. Before the hash value is stored to our database, we hash it again, so that potential attackers have an even harder time to figure out your password.
A user is someone who creates a Boxcryptor account and is identifiable by his/her email address and his/her user keys. The user keys are generated on the user’s device during the account set-up and creation. Before the keys are submitted to the Boxcryptor server, the sensitive information is encrypted so that only the user has access to it.
The private RSA key is encrypted with the user’s password key so that knowledge of the password is required to decrypt the private RSA key. The wrapping key is encrypted with the user’s password key so that only someone who knows the password can decrypt the wrapping key. All other AES keys are encrypted with the wrapping key so that access to the wrapping key is required to decrypt any other AES key.
A group is a list of users that are members of a group and, therefore, have group keys. Every group has a membership key which is used to manage group memberships.
he group keys are generated on a user’s device when a user creates a new group. Before the keys are submitted to the Boxcryptor server, sensitive information is encrypted so that only the user who created the group has access to it.
The private RSA key is encrypted with the membership key so that access to the membership key is required to decrypt the private RSA key. The wrapping key is encrypted with the membership key so that access to the membership key is required to decrypt the wrapping key.
All other AES keys are encrypted with the wrapping key so that access to the wrapping key is required to decrypt any other AES key. The membership key is encrypted with the user’s public RSA key so that access to the user’s private RSA key is required to decrypt the membership key.
In order to speed up the sign in process, the membership key will be additionally AES-encrypted with the user’s group key on the first possible occasion, for example, the user’s next sign in. When the membership key is also available in AES encrypted form, subsequent sign-ins can use AES decryption over RSA decryption which is much faster.
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 group’s private RSA key.
Users and groups can belong to a company which has additional company keys. The company keys are generated on a user’s device during the company’s account creation. Before the keys are submitted to the Boxcryptor server, the sensitive information is encrypted so that only the company administrator has access to it.
The private RSA key of the company is encrypted with a company administration password key to make sure that knowledge of this password is required, to decrypt the company’s private RSA key.
Additionally, an organization or company can define a set of policies (rules). They apply to all users and groups that belong to the specific company. One example is minimum password length.
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 encrypted additionally with the public RSA key – earlier referred to as “AES key”.
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 server – the password hash itself is never stored. See below, how it works in detail.
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 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 – for example by hacking the Boxcryptor server – he would not be able to decrypt a single file without knowing the correct password, which is only known by the user himself.
Lokdon implements a combined encryption process based on LFKI 2048 bits quantum resistant encryption derived from Advanced Encryption Standard. Every file has its own unique random file key which is generated when the file is being created. The file offset key is used to encrypt and decrypt the contents of the file as can be seen below in more detail.
Encrypt the plaintext data using dynamically generated file key. The file key disappears as they are turned into offset gotten for a lattice face or matrix. Offset are kept with the encrypted data. If multiple users have access to a file, the file is encrypted multiple times with different keys of the different users and each result is stored in the encrypted file.
Decrypt the encrypted data using the offset to get the keys. Then M3PIN and SessionID are used for non repudiation. The M2PIN or private key are the intermediate representation. Decrypt the encrypted data using (silent password, keys, m2pin, m3pin and sessionID).
Due to Boxcryptor’s zero-knowledge nature, if you forget or lose your password, you lose access to your files. Without the password, it is not possible to decrypt a user’s private key and thus it is not possible to decrypt any files. However, if a company has enabled the Master Key feature, the company can make use of the password reset feature. The Master Key feature gives the administrator of a 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.
Boxcryptor offers a special company account with additional features especially designed for businesses and organizations, for example 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 their passwords. With the Master Key, companies can ensure that the company does not lose access to its property (files) even in difficult situations, such as when a user forgets his or her password or leaves the company. In the following examples, the Master Key feature is activated and Alice is part of the company.
Alice creates or changes her password
The company needs access to Alice’s files
Alice forgot her password and wants to reset her password
Boxcryptor requires an internet connection to send and receive data to and from the Boxcryptor server. Specifically, the following use cases require an internet connection.
When an internet connection is necessary
Setting up a New Device 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.
Sharing Access to a File or Folder When sharing a file or folder with another user, Boxcryptor retrieves the public key of the sepcific user from the Boxcryptor Key Server.
Managing groups Creating, editing, or deleting a group or its group members requires access to the Boxcryptor Key Server.
Syncing cached information While Boxcryptor is running, it tries to continuously sync all user information and key data for the currently logged in user if an internet connection is available.
Working offline with Boxcryptor
Besides the use cases described above, Boxcryptor does not need an internet connection. Especially the encryption and decryption processes do not require an internet connection, since everything takes place on your device. Once a user has installed Boxcryptor on 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.
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.
Important: 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 is 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, Lokdon relies on established and proven third-party libraries. Depending on the platform and purpose, Lokdon uses either popular open source libraries, or libraries which are part of the underlying operating system. The following libraries are used.
Which processes does Boxcryptor perform, when you allow a colleague to access a file or folder? What happenes, when you share access with a group where your colleague is a member? Imagine your name is Alice and your colleague is called Bob.
Sharing file access with one person
Sharing file access with a group
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 can be seen below in more detail.
Create a secure random file key. Encrypt the plaintext data using the file key. Encrypt the file key with the user’s public key. Store the encrypted file key next to the encrypted data in the encrypted file. If multiple users have access to a file, the file key is encrypted multiple times with different public keys of the different users and each result is stored in the encrypted file.
Decrypt the encrypted file key using the user’s private key. Decrypt the encrypted data using the file key.