Backblaze: “Why does the private key still need to be sent to your datacenter?”
help.backblaze.com
help.backblaze.com
Except, they say your data is unrecoverable if you lose your public key (which presumably serves as proof of your ownership of the data). Of course, it is not technically unrecoverable, they just won't recover it for you. In other words, this negates the one good reason for them storing the private key. I'm confused.
(Also, why is the private key generated on the client and then transmitted to their server?)
You create the private key on the client side so that you can encrypt it with a custom password before sending it to Backblaze. Doing this makes they key recoverable from you - as long as you remember the passphrase to decrypt it - and unusable from Backblaze.
> The priv key is NEVER written to disk on your system,it is then thrown away after transmission. The public key can be found on your local system here on a Windows PC (ask if you want to know on a Macintosh): C:\Program Files\Backblaze\userPub.pem This is a standard "OpenSSL PEM File" as decribed here: http://www.openssl.org/docs/crypto/pem.html#PEM_ENCRYPTION_F....
> You can read these files with Notepad or Wordpad, but be very very careful not to write out any changes or it will effectively destroy your backup -> make it unrecoverable/unreadable.
Also, the encryption happens on the server. If you protected the private key with a passphrase from the moment it was created then your data couldn't be encrypted because backblaze would never have access to the key.
Their client is not designed this way. Their installer generates and sends the private key before the user has an option to set a passphrase. I replied to a different comment about this with more detail[0].
Have you ever tried to restore from one such archive?
(And as someone said, duplicity).
This method can result in corruption of the disk image if you’re not careful.
Edit: This is probably the most seamless way to handle encryption. It’s built in to the OS and you can save the password in Keychain if you like. Used it with Dropbox for years. Just make sure to unmount and let it sync before opening the disk on another system.
End to end encrypted services allow for users to do more interesting things with the data
At the same time, Backblaze only offers a security-theatre for encryption - they give you the ability to encrypt your backup private key with a password before sending it to them. But during restore, they collect this password and decrypt everything server-side. What's the point of offering encryption then?
If you’re going to use BackBlaze’s software, which has access to all your files, you have to trust Backblaze as a company. If you don’t trust them, don’t use their service. Simple. There is no circumstance under which you can both distrust them and run their software. (Try tarsnap instead.)
So now the question becomes: what threats are you protecting yourself against?
For me, it’s:
- malicious employees accessing my data
- a security breach giving outside actors access to my data.
Encrypting the backups and encrypting the private key protects me against these threats.
My “restores” aren’t protected against these threats, because they’re not encrypted (as of 2019 when this FAQ was written), so that’s a gap. It’s one I’m willing to put up with because I can mitigate the risk by not leaving restores hanging around.
Backblaze could easily reduce the trust required, which they‘re not doing, but have been promising to do for years, with nothing happening.
Also, given your threat model, I‘d say the risk-mitigation is not applicable. Attackers lying low and continuously collecting and exfiltrating data is nothing new. Especially if this data includes passwords, private keys and data „zipping-by“.
Or does your threat model include specifically only an attacker being advanced enough to compromise Backblaze, but somehow not being able to persist for a while?
No, it‘s Backblaze‘s job of keeping data safe the best way possible, it shouldn‘t be necessary for customers to find excuses for their bad encryption scheme or to add another layer of encryption, especially if the fix is quite obvious and has been promised for years.
> HTTPS doesn't hurt anything and actually has some nice side effects (it separates backups onto a separate port than the majority of your web traffic, allows for traffic shaping if you want to do it).
Wouldn't using HTTPS put it on the same port as virtually all web traffic?
This feature is thus pure security theatre.
You gain nothing - the provider may still access your data at some point (yes, they only "fly-by fast on a super-secure-server"), but still lose the ability to restore without the password.
The thing is, it wouldn't be hard to do the decryption during restore on the client. Why haven't they done this in all these years?
You can’t even do that! Setting a PEK passphrase sends it to Backblaze. It has to[0]: your private key exists only on their servers.
As you say, the entire feature is basically a lie.
[0] I mean “has” in the sense that they deliberately designed it this way. Obviously there are plenty of ways to design this that don’t involve sending your password.
The private key is auto-generated by the Backblaze Client installer and gets sent to their server at install time. This is done before the user has any choice to set a passphrase. Setting a passphrase later does not generate a new keypair, it just sends that passphrase to their server so the server can re-encrypt the private key using the new passphrase.
Because the key is uploaded at install time and doesn’t ever change, they already have the private key in unencrypted form. When a user tries to protect it, now they also have the user’s passphrase. There is no technological way by which “PEK” shields your data from Backblaze, even at rest, as implemented.
Did you publish your findings somewhere or notify Backblaze?
For those that want something more zero-knowledge, we have Backblaze B2 Cloud Storage which has a lot of integrations, and you can even DIY your own backup schemes, including encrypting everything on your end before sending it up to Backblaze B2 for storage.
yes, that does answer my questions