How to make strong encryption easy to use

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.
Encryption
Decryption
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!

  • 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.

    • http://doctink.net/ Daniel Carleton

      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:
        https://www.backblaze.com/backup-encryption.html
        “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.

    • http://www.hikingmike.com/ hikingmike

      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 http://www.tarsnap.com? 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.

  • 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?