Blockchain security

  • Quantum Resistant Encryption (QRE): The system uses a 2048-bits AES-hybrid encryption standard. It also has many protocols that undermines trust, centralization and non-distribution of assets. The power of the SDK lies in integrating all into an ABC technology path:
    A. Easily add ECSMID to your blockchain applications to make it truly decentralized private and secure. B. Use this technology to make the web, IoT, mobile, cloud devices autonomously secure with encryption footprints that are resistant to quantum computing.
  • Homomorphic Encryption (HE):The homomorphic properties puts another layer of encryption on already encrypted data. The product is a complexity of cipher texts. We see the uses in protecting cloud resources. It will secure cloud, Web, Mobile, IoT data. The power of the SDK lies in integrating all into an ABC technology path:
    A. Easily add ECSMID to your blockchain applications to make it truly decentralized private and secure. B. Use our technology to make your IoT device autonomously secure with its encryption footprints.
  • De-addressing: We use ECSMID mechanism for open location addressing or SOL-C with higher accuracy of 0.1cm square to represent your address regardless of your location.
  • Supply Chain integrity: ECSMID engages the development of an all inclusive technology that uses material tomography ( security ) to track, trace, source and sample origin of products in supply-chain. We also use this same method to secure data and exchange between connected devices.

Business Application

  • LokDon$: This an application that makes possible for secure SMS, file sharing, payment and users/teams collaboration.
  • Java/Python/C-C++/C# SDK and mobile (Android and IOS) encryption library which allows for the easiest integration of cryptographic operations into your own enterprise software or software product.
  • Desktop Software for encrypting data on Windows, Mac and Linux OS: 2048 bits encryption of files and file archives in the cloud.
  • Browser plugins This will be using 2048 bits encrypted token authentications or cookies.
  • Messenger support: Include the highest security (2048 bits encryption) in all messenger application with our SDK etc. e.g audio and video calls.

Technical details

  • We offer consultation to help government and private organizations understand the new paradigm in the race of cryptography. We help them to see the need to derive stable functions with dynamic key generation mechanism for their highly advanced and/or customl cryptographic suite.

Technical Overview of Cryptography-Encryption

If you want to learn more about how Lokdon works, you are in the right place here. You will be delighted to learn the details of certain technical aspects of this cryptographic system.



Encryption Keys Used in Lokdon and Their Functions

Every user, group and company do not have the same set of keys. Here we developed a symmetric key hybrid which shows the qualities of asymmetric key cryptography as well. Individuals, developers/businesses and enterprises are assigned attributes based on advanced 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 enterprises 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.

LokDon Server – What User Data we Store

All data that we store on our servers is secured and protected. 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 some data on the Boxcryptor server.

General user data that we store

We store a small amount of information of each user, group and company. The information is necessary to authenticate you as a user at sign in.

  • Email address
  • First and last name
  • Country
  • Etc

Keys and additional values

Additionally, we store keys and values that are necessary for encrypting and decrypting processes. Of course, these values are protected carefully as well.

  • Private RSA key (encrypted with the user’s password)
  • Public RSA key
  • AES keys (encrypted with the user’s password / wrapping key)
  • Hash of the password hash
  • Number of KDF iterations used in the key derivation functions
  • Salt
  • If a company uses the master key: Password Key (encrypted with the company’s public RSA key)
    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.
  • Private RSA key (encrypted with the membership key)
  • Public RSA key
  • AES keys (encrypted with the membership key / wrapping key)
  • Membership key (encrypted with every member’s public RSA key)
  • Membership key (optional – AES encrypted with every member’s group key)
    Data we store if you are part of a Boxcryptor Company Team
    When you are using the Boxcryptor Company, this additional data is stored on our servers.
  • Private RSA key (encrypted with the company administration password)
  • Public RSA key
  • List of users
  • Policies that have been activated by your company

Data Privacy – How we Protect the Data on our Servers

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.

Email
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 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.

Data Privacy with Zero Knowledge Triangle Flow (ZT-Flow)

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.

Password Security – How we Protect Your Password

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.

Password key
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.

Password hash
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.

How we Manage Users, Groups and Companies

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.

Group management
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.

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 group’s private RSA key.

Company management
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”.

How the User is Authenticated

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

  1. The password hash is derived from the password.
  2. The password hash (and not the password itself) is sent to the Boxcryptor server
  3. On the server, the password hash is hashed again, using PBKDF2 with HMACSHA512, 10.000 iterations and the user’s random 24 byte salt.
  4. On the server, this hashed password hash is then stored in encrypted form in the database.

A user logs in and authenticates himself

  1. The password hash is derived from the provided password.
  2. The email address and password hash are sent to the Boxcryptor server
  3. On the server, the password hash is hashed using PBKDF2 with HMACSHA512, 10.000 iterations and the user’s random 24 byte salt.
  4. On the server, this hashed password hash is compared with the value stored in the database. If it matches, the user provided the correct password and is successfully authenticated. If not, the password was wrong.

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.

How Boxcryptor Encrypts and Decrypts Files

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.

Encryption
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.

Decryption
Decrypt the encrypted file key using the user’s private key. Decrypt the encrypted data using the file key.

Used algorithms:

  • AES with a key length of 256 bits, CBC (Cipher Block Chaining) and PKCS7 padding.
  • RSA with a key length of 4096 bits and OAEP padding.

Resetting Passwords in Boxcryptor Company – How the Master Key Works

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

  1. A password key is derived from the user’s password.
  2. The user’s private and wrapping keys are encrypted with the password key.
  3. The password key is encrypted with the company’s public key.
  4. The encrypted user’s private and wrapping keys and the encrypted password key are submitted to the Boxcryptor server.

The company needs access to Alice’s files

  1. The company administrator decrypts the company’s private key with the company administration password.
  2. The encrypted password key of Alice is decrypted with the company’s private key.
  3. The user’s private and wrapping keys are decrypted with the password key.
  4. The file key is decrypted with the user’s private key.

Alice forgot her password and wants to reset her password

  1. The company administrator decrypts the company’s private key with the company administration password.
  2. The encrypted password key of Alice is decrypted with the company’s private key.
  3. Alice’s private and wrapping keys are decrypted with the password key.
  4. A new random password is generated and a new password key is derived from it.
  5. The user’s private and wrapping keys are encrypted with the new password key.
  6. The new password key is encrypted with the company’s public key.
  7. The new encrypted user’s private and wrapping keys and the new encrypted password key are submitted to the Boxcryptor server.

Why and When Boxcryptor Requires an Internet Connection

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.

Local Account

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.)

Which Cryptographic Libraries are Used in Boxcryptor

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.

How File Access Sharing Works

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

  1. Alice requests Bob’s public key from the Boxcryptor Key Server.
  2. Alice encrypts the file key with Bob’s public key.
  3. Alice writes the new encrypted file key to the encrypted file.
  4. The cloud storage provider syncs the modified encrypted file.
  5. Bob uses his private key to decrypt the file key.
  6. Bob uses the file key to decrypt the file.

Sharing file access with a group

  1. Alice requests the group’s public key from the Boxcryptor server.
  2. Alice encrypts the file key with the group’s public key.
  3. Alice writes the new encrypted file key to the encrypted file.
  4. The cloud storage provider syncs the modified encrypted file.
  5. Bob uses his private key to decrypt the group’s membership key.
  6. Bob uses the group’s membership key to decrypt the group’s private key.
  7. Bob uses the group’s private key to decrypt the file key.
  8. Bob uses the file key to decrypt the file.

Resetting Passwords in Boxcryptor Company – How the Master Key Works

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.

Encryption
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.

Decryption
Decrypt the encrypted file key using the user’s private key. Decrypt the encrypted data using the file key.

Used algorithms:

  • AES with a key length of 256 bits, CBC (Cipher Block Chaining) and PKCS7 padding.
  • RSA with a key length of 4096 bits and OAEP padding.