how on-premise cloud works with e2e encryption

Our team is trusted with information security audit. I don’t want to imagine what will happen if the results of one of these checks leak into the network. So we take the safety of working documents very seriously. We are also a little paranoid, so we decided reinvent the wheel develop a cloud for secure file collaboration and share best practices.

Yes, cloud storage makes teamwork easier, especially when everyone is away. But, as a rule, for the sake of convenience, providers sacrifice security. Most of them manage the encryption keys in the same environment as the encrypted files.

Files are regularly decrypted for indexing and processing to enable advanced cloud features such as sharing, file sharing, content search. At this point, the data is especially vulnerable to hacker attacks, and the rest of the time the risks are quite high.

If an attacker gains access to the provider’s storage system, it is only a matter of time before he finds the files and their corresponding keys. It happens that such thefts are committed by the administrators themselves, who know how the service works and can cover their tracks.

File owners have no control over how cloud services are encrypted and who has access to decryption keys. Therefore, leaks happen with enviable regularity, and even the largest companies suffer from them. For example, in October 2020 1TB of confidential documents stolen from Nitro Software serversowned Google, Apple, Microsoft and Citibank.

Of course, you can encrypt data manually before uploading it to the cloud. This approach is suitable for storing backups, but it is inconvenient for everyday work.

It’s nearly impossible to get front-line employees to regularly encrypt files before sending them. Attempting to manually send out passwords, manage user groups, grant or deny access, and share files will take a lot of effort and will inevitably turn into a mess. We know we tried.

Therefore, we set about developing a system that would combine the convenience of modern cloud storage, end-to-end encryption, and the on-premise principle – the ability to deploy everything on our own infrastructure.

Task Features

The peculiarity of the development of cryptographic systems is that there is no scope for creativity. It is even harmful. You can’t just come up with a new encryption protocol, its security must be proven by many years of independent research. And so in everything.

Therefore, the task is to select a stack of proven technologies, make them work together and do what is needed. Cryptography gurus are unlikely to find anything original in our solutions. Next, we will simply try to clearly explain how key exchange works, and what pitfalls are associated with encryption in the browser.

Bastion Security Cloud Storage (BSC)

S3 MinIO and PostgreSQL were chosen for data storage. S3 provides freedom in site selection. You can install a server in the office, or you can easily move to the infrastructure of almost any hosting provider. MinIO supports redundant storage and gives you the confidence to recover from multiple hard drive failures.

Nuances of Encryption

To use e2e encryption and at the same time implement convenient file access control, a lot of attention had to be paid to cryptography.

We used the AES256 GCM algorithm. It encrypts every file in the vault. Then every folder is encrypted, every directory with files. In this case, the encryption keys are stored next to the encrypted files.

It turns out a hierarchy of keys that repeats the structure of the file system. This is necessary for the user to operate and share encrypted files in the same way as he is used to doing in familiar cloud services.

Because each file is encrypted with its own key, you can share access to individual directories and files without decrypting them on the server. The vault is designed so that access can be revoked at any time and files that were previously available to other users can be re-encrypted.

At the top of the hierarchy is the root directory. The master key, which gives access to the root directory and all the contents of the cloud, is stored separately. It is encrypted with the public key X25519.

X25519 is an asymmetric protocol, so only the owner of the secret key can access the data, and it is generated and stored by the user and is not transmitted in the clear. This approach ensures that no one except the user can decrypt the root directory, access individual files and keys to decrypt them.

Each file is encrypted before uploading to BSC on the user’s computer with a fresh 256-bit symmetric key. Data integrity ensures Galois/Counter Mode is a special mode of operation of the AES algorithm.

Regular HTTPS is used to transfer data between the client machine and the cloud. The file is placed in the right place in the directory and encrypted sequentially up to the master key.

Establishing secure file sharing with unregistered, untrusted users proved more difficult. I had to use multi-layer encryption and juggling keys with might and main.

Watch your hands. Now it will be difficult.

File sharing

Let’s assume that the client needs to securely transfer an electronic copy of the contract to Bastion.

We generate a link to download the file using the cloud web interface. A “tail” from a random sequence of characters is automatically added to the link. Part of this sequence acts as the ID, and part is used as the key A.

The application sends the ID to the cloud server, and we send the link to the client, for example, via a messenger. Together with the link, the client gets access to the client web application for uploading files to the cloud, ID and key A.

Using the cloud web interface, the client generates a symmetric key B and encrypts the contract with it.

Then, the web interface uses the ID to connect to the cloud, sends an encrypted contract there and receives a public key C, created in advance on the Bastion side.

Now the client application encrypts the file with key B with key C. And then it encrypts the resulting file again with key A.

On our side, this matryoshka is deciphered in the reverse order. First, with key A, transmitted over an independent communication channel, then with secret key C, which did not leave the computer.

Thus, none of the components required for decryption end up on the file server. Moreover, this scheme can be mirrored and generate links to secure download files that will be decrypted only on the client’s computer.

Encryption in the browser

All functions of the cloud could be implemented using a separate application, but we wanted it to work without installing plugins and additional software.

Modern browsers support encryption, so this is not impossible. The problem is that no one expected that they would be used to decrypt large files.

A browser is primarily a means of browsing the web and executing simple logic with limited access to hardware.

The developers are doing everything to keep Trojans out, so the browser does not have direct access to the file storage and writes data directly to the hard drive. But we need to first download the file, decrypt it and place the decrypted version somewhere.

First we used the RAM of the browser tabs. With small files, this worked, but we quickly ran into limitations.

If a tab consumes a lot of RAM, the browser closes it and restarts. For example, Safari limits the consumption of a tab to approximately 4 GB. This is not to mention the fact that RAM itself is a very limited resource. The average laptop has 8 GB installed, and you need to ensure that you can work with heavier files.

The first thing we did was set up sequential upload and download of files. Instead of working with the encrypted file as a whole, they began to split it into small fragments and delete them immediately after processing. This helped to get rid of problems with uploading to the cloud, but did not solve problems with downloading heavy files. The desired solution lay in a different plane.

We decrypted the file in the same thread that is responsible for rendering the page with the cloud web interface. However, browsers use Workers, a mechanism that allows scripts to run on a background thread, separate from the page. Each Worker uses its own memory and, as it turns out, can use the swap file.

By shifting decryption to Worker, we got rid of the problem with limited RAM and accelerated decryption by using multiple processor cores. Even the web interface has become more responsive, since the Worker works asynchronously, regardless of the tab, and does not prevent the browser from processing the page.

What’s next

For the next release, we want to transfer not only decryption to Worker, but also the encryption process. This should speed up file uploads. However, even without this, we successfully use BSC in our daily work. Perhaps the cloud will be useful for you too. Distribution available for free download.

Bastion Security Cloud is free to use, with no limits on storage capacity and available features. The only condition is the size of the team – up to 10 registered users. You can create public folders and use them to share files with unregistered users, so this is not as hard a limit as you might think.

We recently completely redesigned the BSC interface, added mobile layout, file permissions management, and are now developing new features. We plan to implement the creation and downloading of archives, similar to how it works in Google Drive and Yandex.Disk, and we are preparing a client for windows and linux machines.

We are betting that companies will become more attentive to data storage, the demand for secure storage will grow, and we are preparing for this

Similar Posts

Leave a Reply