How to make strong encryption easy to use

By | November 12th, 2008

Goal: Security done right
Protecting the privacy of our users’ data is a top priority for us here at Backblaze and that means encryption. But providing a service that is extremely easy to use is also a key part of our vision and far too often encryption makes a product hard to use. This trade-off was unacceptable to us so we set out to build a system that delivers military grade encryption without compromise! Here is the full list of our requirements:

1) Protect data with military grade encryption
2) Implement encryption transparently so users don’t have to deal with it
3) Allow users to change their password without re-encrypting their data
4) In business environments, allow IT access to data without the user’s password

The solution: Military grade encryption made easy
To accomplish the ambitious goals above we used a mix of public/private and symmetric key algorithms. The math behind this cryptography is hard but the idea is simple…. Public/private keys allow you to encrypt data with one key and decrypt it with another one. Typically data is encrypted with the public key and decrypted with a private key that is kept secret but the reverse also works. This is very useful because it allows us to encrypt data in the background without requiring the user to type in their password.

Unfortunately, public/private key algorithms are slow and can’t be used to encrypt a large amount of data. Symmetric key algorithms use the same key to encrypt and decrypt data and are very fast on large amounts of data. But since the same key is used to decrypt the data, the data is only secure if the symmetric key is secure.

Combining these algorithms, here’s how our system works.
We generate a new 2048-bit RSA public/private key pair when our client is installed, store the public key on the local disk and transmit the private key to our datacenter via https. Then, for each backup session, we generate a new random 128-bit AES symmetric key which we use to encrypt the user’s data. We secure the 128-bit AES key by encrypting it with the user’s public key and transmit the encrypted file along with the encrypted key to our datacenter over https. We destroy the unencrypted 128-bit AES key at the end of each backup session and never write it to disk. To decrypt a file, the user’s private key is used to decrypt the 128-bit AES which is then used to decrypt the file.

The user’s private key which is stored safely in our datacenter is protected by a password that is highly guarded. But for some users this is not good enough and we allow the user to secure this file with their own password. When this is done it is impossible to access the data without the user’s password. Unfortunately, this also means we can’t help the user if they ever forget this password so we don’t recommend it for most users.

The real beauty of this scheme becomes clear when you look back at our goals above. AES is the encryption standard adopted by the US government to protect classified information. #1 solved. Using the user’s public key we can safely run transparently in the background without compromising security. #2 check. Since a password is used to secure the private key rather than to encrypt the data directly, the password can be changed by re-encrypting only the private key with the new password. #3 accomplished. And last but not least, you can make several copies of the user’s private key and encrypt each copy with a different password to provide IT access to data without the need to share passwords. #4 done!

Tim Nufire

Tim Nufire

Chief Cloud Officer at Backblaze
Chief Cloud Officer and co-founder - While Tim stays busy fussing with the Backblaze cloud, designing Storage Pods and managing Operations, he'd much rather be taking Grommit, his Goldendoodle, for a walk.
Category:  Backblaze Bits · TechBytes
  • Piotr Czapla

    Guys do you have any updates on the request to keep the private key private, so that you cant see the unencrypted data during restore? This topic is becoming quite important for anyone in Europe that has a business and would like to use your service for backups. We are not allowed to store any personal information (ex. data about clients) out side of Europe, and with a new regulation GDPR this restriction has fines of 2 mln euro or more. If we can guarantee that the encryption key never leaves the backed up computers this should be compatible with GDPR.

    • Jimbo

      Yes, this is an old thread… but the issue remains. As I understand it, my data is encrypted on Backblaze servers with my Private Encryption Key.

      BUT: Let’s say I need to restore. As I understand this, I enter my Private Encryption Key and then my entire computer basically will be put on a drive, in the clear, and sent through the mail to me unencrypted.

      It doesn’t seem to me that it would be so difficult to put the encryption/decryption on my side, inside the Backblaze app. But then again, maybe it is – I’m not a programming genius.

      But man, that would be a huuuuge improvement.

  • Brian8493

    I agree with other that the encrypt/decrypt of the data should occur on the client machine in order to protect the confidentiality of the private key.

    I signed up to backblaze less than a month ago in an attempt to move away from crashplan due to their price increases (it’s gone up 50% since the last time I paid). I will be deleting my backblaze account today due to the requirement of needing to upload the private key to decrypt.

    On a side note though if you are truly paranoid you could only use a backup system that does encrypt/decrypt on the client & provides the client 100% open source. Even in a situation like Crashplan where the encrypt/decrypt is done on the client with your Private key you have no way to know that there isn’t a second private key that is added during encryption.

  • Ashley

    How can I be assured that Backblaze is HIPAA compliant? I recently learned it is not FIPS-140-2. Does that mean it is not HIPAA compliant?

  • Guest_47

    For those of you who are really paranoid and do not trust Backblaze, there is a very simple solution! Encrypt your most private data! First, make sure you set Backblaze to only backup your data folders and no system or application folders. In addition, create a temporary folder, and make sure that is also excluded from the backup.

    Keep your previous and encrypted data backed up using Backblaze. Even if someone decrypts the entire Backblaze, they still only end up with your original encrypted folder. When you want to decrypt files, do it to the temporary folder mentioned above. Or better yet, do it to a RAM drive (making sure the RAM drive is excluded from the backup).

    • Geff

      Yes, it’s always possible to make a complicated hard to manage and difficult to use solution. We are hoping to get an easy to use hard to forget/ do a mistake solution. Much like backblaze is quite close to provide.

      • Guest_47

        What I mentioned is not complicated at all. Besides, as I said, it’s only for those who don’t trust Backblaze (i.e. Ashley, the OP). If you trust Backblaze, then by all means ignore my message. Or if you have a simpler solution, let’s hear it. Otherwise, what point are you making?

        • Trust has nothing to do with being HIPAA compliant, nor does encryption (by itself). If BackBlaze is not following HIPAA regulations and they will not sign and abide by a HIPAA Business Associate Agreement then it is safe to say, BackBlaze is not HIPAA compliant. Regardless of how secure or trustworthy they may be.

          HIPAA is a legal requirement. Attacking the OP as paranoid and not trusting of BackBlaze doesn’t help nor does it answer the question posted.

  • Charles Dreyfus

    Tim Nufire, could you weigh in on this string? The question is what would happen if Backblaze were served with a NSA Letter. Would the use of a private encryption key prevent Backblaze from being in a poistion to hand over unencrypted customer data to the government? Or does the design of its encryption scheme even without a private key mitigate the same risk?

    • Geff

      I would expect NSA/ GCHQ to be able to get at the data as soon as its in progress of a restore, because at that point backblaze can’t say it can’t provide it anymore.

      • Guest_47

        You are quite correct. And hence my solution (which you dislike) of encrypting your files, so that it is restored only on your own computer and not on Backblaze’s server. It’s that simple.

    • Anand Sharma

      I read this full discussion to date (2016-08-02) and agree with Charles, Geff and Ryan. I am also a *tiny* bit paranoid but enough to with that Backblaze would offer the ability to allow client-side decryption – call it a “paranoid” mode for laughs if you wish.

      Comparing Crashplan and Backblaze, it appears that Backblaze has the more secure option *until it comes to restoring*. Then all user data is decrypted on the server end.

      That is very disappointing.

      @Tim Nufire and @Backblaze, please respond to this thread. I’m very curious to learn whether the thoughts shared on this comment section have been heard and whether any action will be taken to assuage your end user’s concerns.

      PS: I’m subscribed to the Personal Backup subscription.

  • Geff

    Sadly since the private key, even with a extra password, exists on your servers at least at point of restore my data is then possibly compromised by whatever government you operate under.
    As they can compel you, possibly unbeknownst to me, to disclose the unencrypted restore files.

    Please provide an option where only my local machine ever sees the unencrypted data.
    This option should use a private key supplied locally, never transmitted, and known only to me.

    • Perhaps you didn’t read the entire article? In it Tim says:

      “The user’s private key which is stored safely in our datacenter is protected by a password that is highly guarded. But for some users this is not good enough and we allow the user to secure this file with their own password. When this is done it is impossible to access the data without the user’s password.”

      • Geff

        I read the whole web site :)
        Hence I saw this also:
        “Restoring when you set a passphrase”
        “To decrypt your data, you are required to enter your passphrase on our secure website. When you do so, it is passed over an encrypted connection to our datacenter where it is used to decrypt your private key, which in turn is used to decrypt your data.” “once we decrypt your data on our secure restore servers ”
        Backblaze at this point has your data unencrypted on their disks, for Backblaze, NSA, etc to see.

        • Ryan Minnick

          Geff, you should also note that the text you include above is used to describe the restore process, not the backup process. If your local machine was compromised or eliminated, you would need to retrieve your files. Once you retrieve and restore your files, you would delete the old backup and copy of your retrieval download, removing all data from the server.

          At that point, you would install a new copy of BackBlaze on a new machine, set up a new private key, and your desire to keep your data secure is fulfilled.

          The only way to increase that level of security would be for BackBlaze to create a restore client that you would install on your new machine and enter your secondary private key locally for the files to be decrypted upon download.

          Since data in transit during that retrieval process seems to be your greater concern, I would recommend encrypting your data locally so that even in the event of retrieval, there still exists an encryption layer to the file (think of it as building an encryption ‘onion’ – at the core is your local encryption, with the standard BackBlaze encryption surrounding that, with your private key surrounding that.

          • rharder

            Ryan, that’s exactly right: Backblaze would need (DOES need, Geff and I would say) to use the client app as a restore app as well and to send the encrypted files to the client for the final decryption. My current service CrashPlan does that, so I’m not sure I want to switch to Backblaze yet.

            It’s not a matter of trusting Backblaze. I don’t doubt their sincerity, but if they have my super-private-password, then they have my super-private-password. That’s the end of it.

            Obviously not every user cares about this, so I can hardly fault Backblaze for making their decisions the way they did, it’s just that they’re SO CLOSE to getting it perfect. It wouldn’t take much change in their plumbing.

            For the uber-paranoid, At installation the super-private-password could be used to encrypt the private key, which is sent to backblaze. Upon restore, the encrypted private key could be sent to the client to 1) decrypt the private key and 2) decrypt the files.

            SO CLOSE!

            You can do it, Backblaze! You can do it!


          • Geff

            Yes, it seems only the restore is impacted. However there is no point in a backup other than the restore and the security of the solution obviously being defined by its weakest point so that gives little comfort.
            And as Rob says the solution is so close, just give the choice of a client only restore option (as it may require slightly more client managment of keys/ passwords and little/ no option for browser based solutions)

    • I agree. All of the encryption and decryption should occur on the client machine to ensure privacy, and no sending encryption keys to anyone else including the provider. Please provide this option.

    • Jonas Platte

      Are you aware of It has a completely different payment model (prepaid) and is probably not useful for the average user (the only official Tarsnap client is a command-line program), but it’s about the best you can get if you take security seriously.

      • Geff

        Thanks I will have a look at this one 👍🏾