Private files should only be stored in the cloud being encrypted via a key controlled and known by the user solely (= end-to-end encryption). Transport encryption and encryption in the cloud provided by storage providers are not sufficient here.

Attack Surface

The safety of encryption depends on good passwords. Passwords are good if they are not only strong but also easy to use. For an interesting discussion about better passwords see Toward Better Master Passwords.

Some cloud storage providers like Tresorit support automatic end-to-end encryption out of the box. Many widely used services like DropBox and the deeply in Windows integrated OneDrive are sadly lacking this support. For these one can use additional encryption tools like:

boxcryptor: Good commercial tool.CryptSync: Free open source tool based on 7-zip encryption.
Allows decrypting files even without CrypSync using 7-zip apps.

Without any form of automated end-to-end cloud encryption one should encrypt private data manually before storing it in the cloud, which is inconvenient. Some tools for this are: 7-zip passwords, TrueCrypt 7.1a or VeraCrypt.

Data I classify as “paranoid” should not be stored in the cloud at all. Some of it should never be stored electronically at all, like critical login credentials or banking TANs.

OneNote uses a custom synchronization mechanism over OneDrive. Thus non of the automatic encryption approaches work with it. One either looses synchronization or must use inconvenient notebook or section passwords

In addition to end-to-end cloud encryption one should encrypt local drives because your files (or at least remnants of them) are stored there in decrypted form. Win10 does automatically enable BitLocker for all internal drives (not for removable drives like SD cards!) but for convenience stores the key under your Microsoft account in OneDrive, see onedrive.live.com/recoverykey. To regain control of your keys one can disable and reenable BitLocker and not select “Save to your Microsoft account”. By this you loose the convenience of MS taking care of your keys and are responsible yourself: if you loose your key you loose your data! On Win10 mobile one must manually enable encryption via Settings, System, Device Encryption. Win10 mobile does not allow to encrypt removable drives and there seems to be no way to gain control of your keys, see here.

CloudCryptor experimental app

When using cloud storage one has to trust storage providers and/or creators of encryption tools. Thus it would be nice to roll your own end-to-end encryption. To get a feeling for this I wrote the experimental app CloudCryptor (download code). Beware! I have limited expertise in security and my experimental code is buggy and unsafe (e.g. does not use the IV properly). While the abstraction level of the .NET crypto API is nicely high, the strength of a crypto solution depends on selecting the right crypto methods and using them correctly for which one needs solid crypto expertise. My resumé: Don’t write your own encryption apps if you are not a security expert!

Encrypting the password

To avoid having to enter the password frequently it can be stored locally. CloudCryptor stores the password encrypted via ProtectedData (= NET API of the Windows Data Protection API (DPAPI)). DPAPI derives its encryption key form the login credentials of the current Windows user.

Configuration UI

Notice the DPAPI encrypted password in the config file!

Configuration UI

Cross-device usage

End-to-end encrypted files can be used across heterogeneous devices like desktops, tablets and phones. BoxCryptor offers a Win10 mobile app and there are 7-zip apps with password support for Win10 mobile. In my CloudCryptor experiments I used “file type associations” to trigger decryption on the Windows Phone.

2 Responses to Thoughts and Experiments on Cloud Encryption

It is important to put clear files onto a path that is not potentially synced to the cloud. In your app sample, it should be fine since the encrypted folder is not where the user directly writes their files into.

Even with folder sync enabled, I’m not positive it is secure enough. If by mistake clear files are saved in the cloud folder, according to logs, it is copied to the clear folder then used as source for encrypting. However, if we suppose a huge file copy takes some time for some reason, all clear files sit there while in the mean time and may potentially be uploaded.

Correct: “It is important to put clear files onto a path that is not potentially synced to the cloud.”
In my code experiment files are copied to the synced folder via a stream pipeline containing an encrypting stream.
Thus no clear file or part of a clear file ever gets copied to the cloud, regardless of the file size.
I expect commercial products implementing something similar.

The problem with Viivo you are referring to looks like users not being aware of sideeffects of a specific feature usage of this product.