Backblaze: “Why does the private key still need to be sent to your datacenter?”(help.backblaze.com)
help.backblaze.com
Backblaze: “Why does the private key still need to be sent to your datacenter?”
https://help.backblaze.com/hc/en-us/articles/217664798-Security-Question-Round-up-
50 comments
Double bagging encryption is not a bad option in this case.
You should just encrypt your data yourself before it gets to your provider. It takes an extra step and is annoying but then you can store the data anywhere that’s cheap and convenient
What’s best way to do this on Mac?
[deleted]
Personally I split everything into equally sized tar.gz files, encrypt everything with gpg and upload it using rclone. It should be easily doable and scriptable in any Unix-like machine. It's not the fastest way of doing this, and very inconvenient if you need to access the data often. I only use this for off-site archiving that I will never use unless something catastrophic happens.
> I will never use unless something catastrophic happens
Have you ever tried to restore from one such archive?
Have you ever tried to restore from one such archive?
Yes, it's quite easy. Once all the gpg files are decrypted, the tar archives can be uncompressed with any piece of software that supports tar archives.
You've basically just described duplicity with rclone as the backend (their term). I personally add duply in front for usability (it handles your includes, excludes, "profile", etc.). Restoring is easy with these 3 working in tandem, and you can manually extract the data as needed for SHTF - just gpg encrypted tarballs. duply runs duplicity who runs rclone in a soundbite.
I am curious, why don’t you use rclone crypt?
(And as someone said, duplicity).
(And as someone said, duplicity).
I used to do something similar, but these days I either just use rclone's crypt backend (folder hierarchy is kept intact, files encrypted and filenames obfuscated), or a Restic repository hosted on an rclone backend.
Restic is one option https://restic.net/
There are tools that will provide a virtual drive backed by files that are encrypted on disk. I use Cryptomator [1], which is cross-platform and is designed with cloud syncing in mind, but on mac you can just use Disk Utility to create an encrypted DMG.
[1]: https://cryptomator.org/
[1]: https://cryptomator.org/
Personally, I use encrypted sparse disk images. (You can make them with Disk Utility.) It makes a disk image using many small files in a folder. Might leak some information related about size or number of the contents, but the contents and metadata of the filesystem are encrypted.
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.
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.
I use this same route pretty heavily across several cloud backup providers and never had corruption issues, but yes, it’s technically possible corruption could occur.
Cloud backup is unlikely to corrupt a disk image. Syncing one through Dropbox and having it open on two computers at the same time is living dangerously. :)
Having two independent writers to a file is generally living dangerously, even without the extra complexity of unpredictable async file syncing.
I’ve been trying duplicati recently and it seems fairly simple and is cross platform with a GUI
I use rclone crypt for that (https://rclone.org/crypt/).
Yeah I don't really understand all the chatter about the details of "end-to-end encryption" in this or that product. If you care, if it's important, you absolutely need to take control of that yourself.
The chatter is because storing a blob of encrypted files is secure, but it is another hassle for and end user, and maybe even more importantly, comes with less features: if I stored my photos in an encrypted blob, I wouldn't be able to type my friends name and see all pictures I have with my friend from a random web portal on my phone.
End to end encrypted services allow for users to do more interesting things with the data
End to end encrypted services allow for users to do more interesting things with the data
Of course, but it's not like other providers offer this ability already "baked in".
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?
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?
Because security isn’t black and white.
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.
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.
You’re saying that security isn‘t black and white, but trust somehow is, which I find a bit weird, since they‘re intimately related.
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.
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.
> at installation time, a 2048 bit pub/priv key pair is generated on your laptop, and the private key is transmitted through HTTPS. 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
yes, that does answer my questions
yes, that does answer my questions
I'm not sure if I'm missing something here or what.
> 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?
> 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?
It’s about the Backblaze having your private key, “irregardlessly” of how secured they got yours.
[deleted]
Yeah, it's odd. Maybe a really old answer, when that wasn't true yet?
Depends. For all they know, you could be using their software in 1998.
It makes some kind of sense for them to keep the private key. Most customers are more concerned about data loss from losing the key than snooping.
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?)
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?)
The OpenSSL RSA private key contains all the elements needed to recreate the public key from it. [0] Explains it in more detail.
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.
[0] https://stackoverflow.com/a/26048132/2080636
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.
[0] https://stackoverflow.com/a/26048132/2080636
I think the GP is referring to this part:
> 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.
> 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.
I understand that losing the public key doesn't matter cryptographically, which is why I said "it is not technically unrecoverable".
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.
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.
[deleted]
> You create the private key on the client side so that you can encrypt it with a custom password before sending it to Backblaze.
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].
[0] https://news.ycombinator.com/item?id=28350404
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].
[0] https://news.ycombinator.com/item?id=28350404
I feel like this whole page could be simplified to something along the lines of: We layer encryption. Want another layer? Add it yourself. It's pretty easy but don't come cryin' to us if you can't restore your data one day.
My issue with their encryption scheme is that although you can encrypt your private key before sending it to them, during restore, you still need to hand them the unencrypted private key.
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?
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?
yeah, even if you accept the premise of "we need to backup the key for users" (which I'd still prefer to be optional), that is just WTF.
> you can encrypt your private key before sending it to them
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.
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.
It doesn't have to (and according to the linked page doesn't until a restore), since the private key isn't needed to backup files. If it instead let you fetch the encrypted private key for a restore, it'd be a lot better already.
I’m just telling you what their client actually does based on a previous analysis I conducted, not the claims of their documentation.
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.
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.
would it be hard to implement reading an env var like I_KNOW_WHAT_I_AM_DOING_HANDSOFF_MYKEYS to disable this behaviour?
Client side encryption with apps like Restic and Borg is very easy.
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.