Bring Your Own Encryption: How Not To Do It

Lately I’ve been spending a lot of time talking with cloud service providers about how they protect their customers’ data with strong encryption and how they deal with content owners who don’t trust anyone (or can’t due to compliance reasons) and want to control their own end-to-end encryption.  In the case of service providers that offer file sync and sharing, one common response I’ve received is that they already integrate with 3rd party “encryption as a service” systems through APIs and leave it to the customer to verify the effectiveness of the security mechanisms. The industry refers to this approach as BYOE or Bring Your Own Encryption.

While I’m sure it’s technically possible for an end user to cherry pick a combination of cloud service providers, one or more of their service tiers and plug-ins, and bolt it to a 3rd party encryption as a service tool kit, how effective is this in the real world when some of the most popular services are involved?

It took me about five minutes to convince myself there are red-flags all over this approach.  Since I use nearly all of the most popular services myself (not as punishment but as “keeping up with the Joneses”), and without naming names, I installed a popular 3rd party end-to-end encryption service as a shell around a very popular file sharing app. I put a couple of files in my “sync” folder, edited one of the files a few times so that some number or versions were generated, and my local Windows PC looked like this:

I then encrypted one of the files using the 3rd party tool and the encrypted version of the file replaced the original on my local machine.  This is indicated by the little icon in front of - and the new extension appended to the file name.

Also as expected, the version in the cloud was replaced by the encrypted file, so far so good.