Announcements

If you're experiencing problems with the software, the best way to get ahold of us is to head to https://stablebit.com/Contact, especially if this is a licensing issue.
Issues submitted there are checked first, and handled more aggressively. So, especially if the problem is urgent, please head over there first.

Full Drive Encryption

Recommended Posts

Some years ago, when I first got the idea for StableBit CloudDrive, as cool as the concept sounded technically, I started thinking about its use cases. What would be the reason to use StableBit CloudDrive over any of the various "drive" applications that you can get directly from a cloud storage provider? Of course there are some obvious reasons, for example, StableBit CloudDrive is a real drive, it has an intelligent adaptive cache that stores the most frequently accessed data locally, but the main reason which really drove the overall design of StableBit CloudDrive is full drive encryption.

If you want to ensure the privacy and the security of your data in the cloud, and who doesn't in today's security conscious climate, one option that you have is to have the cloud storage provider encrypt your data for you. That's exactly what many cloud storage providers are already doing, and it all sounds great in theory, but there's one fundamental flaw with this model. The service or company that is storing your data is also the entity which is responsible for ensuring the privacy and the security of your data. In some cases, or perhaps in most, they also provide a secondary way of accessing your data (a back door / key recovery mechanism), which can be misused. If there's a bad actor, or if the company is compelled to do so, they can unwillingly or willingly expose your data without your knowledge to some 3rd party or even publicly.

I came to the conclusion, as I'm sure many other people have in the past, that trusting the storage provider with the task of ensuring the security and privacy of your data is fundamentally flawed.

Now there are other solutions to this problem, like manually encrypting your files with a standalone encryption tool before uploading them or using a 3rd party backup application that supports encryption, but StableBit CloudDrive aims to solve this problem in the best technical way possible. By integrating full drive encryption for the cloud directly into the Operating System, you have the best of both worlds. Your encrypted cloud drive acts like a real disk, making it compatible with most existing Microsoft Windows applications, and it's fully encrypted. Moreover, you are in complete control of the encryption, not the cloud provider.

Because full drive encryption is essential to securing your data in the cloud, let's get a little technical and let me show you how StableBit CloudDrive handles it:

This is just a rough diagram to give you a top level overview and is not technically complete.

Here are the basic steps involved when an application reads or writes data onto an encrypted cloud drive.

A user mode application (or a kernel mode driver) issues a read or a write request to some file system.

The file system issues a read or a write requests to the underlying disk driver, if the request can't be satisfied by the RAM Cache.

For an encrypted cloud drive, any data that is passed into our disk driver is first encrypted, before anything is done to it. Any data that needs to leave our disk driver is decrypted as the last step before returning it to the file system.

This means that any data on an encrypted cloud drive will always be encrypted both in the local cache and in the cloud. In fact none of the code involved in handling the I/O request even needs to know whether the data is encrypted or not. Decrypted data is never committed to your hard drive, unless the application itself saves the decrypted data to disk. For example, if you open a text file with Notepad on an encrypted cloud drive and then save that file to your desktop (which is not encrypted), then you've just committed a decrypted file to disk.

The encryption algorithm that StableBit CloudDrive uses is AES-256 bit CBC, an industry standard encryption algorithm. The encryption API is Microsoft's CNG (https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx), which is FIPS 140-2 compliant. We definitely didn't want to reinvent the wheel when it comes to choosing how to handle the encryption. CNG is a core component of Microsoft Windows and has both a user mode component and a kernel mode component (upon which the user mode component is built).

When you first create your cloud drive, you can choose among 2 methods of unlocking your encrypted drive. Either you can generate a random key, or you can enter a passphrase of varying length and have the system derive a key from the passphrase.

If you choose to generate a key, we do so using a secure random number generator (CNG from user mode) and combine that data (using XOR) with data obtained from your mouse movements (which are gotten from your use of the application). This adds an extra layer of security, just in case the secure random number generator is discovered to be compromised in the future.

The one and only key that is used to decrypt your data can optionally be derived from a passphrase that you enter. This key derivation is performed using a salted PBKDF2-HMAC-SHA512 (200,000 iterations) using the unmanaged CNG API from user mode.

You can also choose to save the key locally for added convenience. If you choose to do this, we use the standard Microsoft Windows credential store to save a locally encrypted version of your key. Obviously if anyone ever gets physical access to your system, or obtains remote access, your key can be compromised. You should save your key locally only if you're not concerned with absolute security and want the added convenience of not having to enter your key on every reboot.

Whatever unlock method you choose, you should always save your key to some permanent medium. You should print it out on a piece of paper or save it to an external thumb drive and store it in a secure place. Since only you have the key, it is absolutely critical that you don't lose it. Without your key, you will lose your data.

Hopefully this post gave everyone a little insight as to why I think encryption is important in StableBit CloudDrive and how it's actually implemented.

Share this post

Link to post

Share on other sites

Can you consider providing us with more control over how our drives are encrypted (mode of operation, algorithm, and key/hash length selection) in a future release? AES-256 bit CBC is a good default, but I'd prefer to use something stronger.

Share this post

Link to post

Share on other sites

Brought up elsewhere on the forum, but copied and pasted here, as it is directly related to the Full Drive Encryption feature:

Is there some way to store the header of the encrypted volume in case it gets overridden, like there is with TrueCrypt? Or would such a function be pointless in CloudDrive?

I think the equivalent of a TrueCrypt volume header in StableBit CloudDrive is the drive metadata. The drive metadata is a file that's stored in the cloud (or locally for the Local Disk / File Share providers) that describes your drive. It contains the size of the drive, the block size, the provider type, etc... In essence it contains everything necessary to mount the cloud drive. In addition, if the drive is encrypted, it contains the necessary data to validate your encryption key.

Currently StableBit CloudDrive doesn't have an automated way of backing up this file, but if your cloud provider lets you browse your cloud drive, the file is named [GUID]-METADATA (sometimes it's stored in its own folder). If your cloud provider loses that file, your cloud drive becomes inaccessible. So it might be a good idea to back that file up, and it might not be a bad idea to add this feature to the app at some point.

Can you consider providing us with more control over how our drives are encrypted (mode of operation, algorithm, and key/hash length selection) in a future release? AES-256 bit CBC is a good default, but I'd prefer to use something stronger.

We can definitely look into providing something stronger or more options.

However, for the initial release, the AES-256 bit CBC encryption algorithm should be very strong, without suffering too much of a performance penalty. But in the future, I don't think it should be too difficult to add additional options and flexibility here.

Share this post

Link to post

Share on other sites

I've got a few questions about the implications of CBC mode in this application.

First, how do you handle large chunk support with CBC mode, since it doesn't support random writes? If I use 100MB chunks and change a single byte at the start of the file, do you have to reupload all 100MB?

Second, since CBC mode does not provide authentication, are the blocks protected with a MAC of some kind? (And if so, is the MAC over the ciphertext rather than the plaintext?)

Share this post

Link to post

Share on other sites

I believe it is handled the same. Most of our providers are encrypted at this point, with a "default key", due to various file parsing that occurs on the provider (Amazon Cloud Drive and Google Drive come to mind).

Specifically, I beleive that each block is broken up, checksummed, and then uploaded that way.

However, I'm not entirely sure on the specifics, and I've flagged this for Alex, so he can post a detailed response.

Share this post

Link to post

Share on other sites

I've got a few questions about the implications of CBC mode in this application.

First, how do you handle large chunk support with CBC mode, since it doesn't support random writes? If I use 100MB chunks and change a single byte at the start of the file, do you have to reupload all 100MB?

Second, since CBC mode does not provide authentication, are the blocks protected with a MAC of some kind? (And if so, is the MAC over the ciphertext rather than the plaintext?)

StableBit CloudDrive's encryption takes place in our kernel virtual disk driver, right before the data hits any permanent storage medium (i.e. the local on-disk cache). This is before any data is split up into chunks for uploading, and the provider implementation is inconsequential at encryption point. The local on-disk cache itself is actually also split up into chunks, but those are much larger at 100 GB per chunk and don't affect the use of CBC.

Our units of encryption for CBC are sector sized, and sectors are inherently read and written atomically on a disk, so the choice of using CBC does not cause any issues here. This is similar to how BitLocker and other full disk encryption software works. Since the on-disk cache is a 1:1 representation of the raw data on the virtual disk, there is no place to store a MAC after the encrypted sectors on the disk. Instead, data uploaded to the provider (which is fully encrypted by this point) is signed upon uploading and verified upon downloading. Many other full drive encryption products (like BitLocker) use no MAC at all.

The algorithm StableBit CloudDrive currently uses for encrypted chunk verification is HMAC SHA-512 over 1 MB sized units or the chunk size, whichever is less. The HMAC key and the encryption key are derived from the master key using HKDF (https://en.wikipedia.org/wiki/HKDF).

In terms of how much data needs to be uploaded, that depends on a few factors.

For example, if you modify one byte on the disk, that byte needs to be uploaded eventually to the provider. One byte modified on an encrypted drive will translate to the entire sector being modified (due to the encryption). The bytes per sector of the virtual disk can be chosen at disk creation time. Additionally, if you have an Upload threshold set (under the I/O Performance window), then we will wait until a certain amount of data needs to be uploaded before beginning to upload anything. If not, then the uploading will begin soon after the virtual disk is modified.

If the provider doesn't support partial chunk uploads (like most HTTP based cloud providers), then we will need to perform a read-modify-write for the chunk that needs to be altered in order to store that sector in the provider's data store. The entire chunk will be downloaded, verified, the signed 1 MB unit will be modified with the encrypted data, it will be re-signed and the whole chunk will be re-uploaded.

If the provider does support partial chunk uploads and partial chunk downloads (like the File Share provider), then only the 1 MB signed unit will be downloaded, verified, modified, re-signed, and re-uploaded.