13

I'm actually interested about zero-knowledge storage system. Those system where the storage provider claims he can't have any access to the data stored.

As far I know, the data are encrypted using a symmetric encryption system, such as AES or another, But those systems need a key to function.

So what happens to the key? Is it stored? Where? If a user connects from another location, and wants to retrieve one of his files, he must retrieve the key first. So if the storage provider stores the key too, he could have access to the encrypted data. It's like having a chest locked and the code on a paper next to the chest, and then claiming that you couldn't open the chest.

So is there a flaw in that? I'm I mistaking completely about those zero-knowledge system? If they can finally open the file, how some of them could escape justice by saying "We can not know that we are hosting illegal files?"

malnourish
  • 1
  • 2
  • 2
    From the little research I've done, the data is encrypted and decrypted on the client side with the keys never being transferred to the server side. Don't know how the transfer of keys from one client to another is done. –  Aug 28 '14 at 12:17
  • That seems weird, When a single client store something then want to retrieve it from an other location, If he is the only one to have the key, how could he gets it? I really wanna know "the trick" behind this. –  Aug 28 '14 at 12:19
  • @Jaydee - you could store the keys on the server as long as they are encrypted and the decryption of the keys and thus the decryption of the data using the keys are done on the client side using a user-provided password. – Scott Whitlock Aug 28 '14 at 12:19
  • @ScottWhitlock Then a zero-knowledge system can't make some files public without loosing his "zero-knowledge" system? –  Aug 28 '14 at 12:23
  • @CarlierRobin You don't need to use the same server to transfer the keys. Use a USB stick or encrypt your keys, upload to FTP server. Download on new client, delete from ftp server. I guess with a system like this you gain security and lose convenience. But as I said I haven;t done that much research. –  Aug 28 '14 at 12:28
  • https://lavaboom.com/en/blog/item/73-examining-spideroak-s-zero-knowledge-cloud-storage.html –  Aug 28 '14 at 12:30
  • @Jaydee - I just think it's a matter of convenience. Storing the key on the client, or on a USB stick is truly zero-knowledge, but it's less convenient. Storing it on the server is more convenient but less secure. In either case the key file needs to be password protected. Also look at [SpiderOak](https://spideroak.com/). – Scott Whitlock Aug 28 '14 at 12:45
  • @ScottWhitlock It depends on the way the encryption to the server is done. The link I provided is for "SpiderOak" which is described as "Dropbox for people that want privacy". This suggests that the encryption is done transparently to the user, so to download something on a different client, you would need the key to decrypt the key you had uploaded! –  Aug 28 '14 at 12:50
  • Are you talking about real zero-knowledge proofs and the like, or about the spideroak abuse of terminology? – CodesInChaos Aug 28 '14 at 14:22
  • @CodesInChaos I'm talking about real system. And I was talking too of the abuse of terminology of some company yes, I wanted to be explained what exactly those system are, from an other source than the company who wants to sell his product. –  Aug 28 '14 at 14:27
  • @Jaydee - your password by itself can be used as an encryption/decryption key, and depending on how they implement it, they never need to have known the password. – Scott Whitlock Aug 28 '14 at 15:29
  • @ScottWhitlock Isn't a simple password a bit "weak" to decrypt the whole file? I mean, with a simple password you can easyly bruteforce the file no? –  Aug 28 '14 at 15:31
  • @CarlierRobin - it completely depends on your ability to pick a strong password with lots and lots of entropy (as in long and complicated). People in general are not good at choosing passwords, but good (i.e. strong) passwords do exist. At some point the password is so complicated that you might as well be storing a full-on key. In principle, however, there is no difference between a symmetric key and a password. – Scott Whitlock Aug 28 '14 at 15:34
  • MIT's Mylar -> http://css.csail.mit.edu/mylar/ is a system based on keeping the provider ignorant of your data. – Eric G Aug 28 '14 at 16:23

2 Answers2

11

In the simplest models for symmetric (reversible) encryption, you just need a decryption key - which can be as simple as a common password.

For the system to be zero-knowledge, the encryption must be done on the client's system and ONLY encrypted information passed to storage provider. This way the storage provider technically has the data stored, yet it has no way to access the clear text (human-readable un-encrypted version) because it doesn't have the key.

Note that in the old-days, we did this with simple FTP and "password protected ZIP files".

The weakness of this system is then that if the decryption key is just a common password then the storage provider (or anyone that intercepts the data) could trivially brute-force crack it and get the clear-text.

So, to make this system even more safe and robust, usually a public-private key system is used, again with the client's private key always being left on the client and NEVER given to the storage provider. Any storage provider that accepts or can access the decryption key is not zero-knowledge, by definition.

As you point out, this could be inconvenient - if I store information with the provider and want to access it at home, I have to manage the key myself. Many tools exist for this, from "keyrings" to secure USB dongle's to biometric storage devices with TPM chips, etc. But yes, you have to carry the key around with you or store it on some other provider's server, with all the potential dangers and inconvenience that has.

The simplest way to understand the systems is just to compare them to a keyed safe. You put in things you don't want anyone to touch, and you lock the safe. You give the safe to a storage company, and then you have the security of knowing the storage company only has access to your safe - not it's contents. If you also have the storage company store the keys to the safe, well then obviously they could trivially access it anytime they want.

The price of security and privacy is very often inconvenience - sometimes tremendous inconvenience. You just have to decide if what you gain is worth the price you must pay in time and potential insecurity (if you lose your key that data is pretty much gone forever, no one can get it back for you).

BrianH
  • 245
  • 2
  • 7
  • So according to this, some big storage sites wich are claiming that they host files with zero knowledge, but in the other hand allow users to share those file if they want are not that "zero-knowledge", and can't argue that they don't know some of their files are illegal once those illegal files are publicly released. Making them vulnerable to justice. (You will probably recognize wich site I am talking about) –  Aug 28 '14 at 13:41
  • @CarlierRobin They are basically putting up a paper wall that makes it harder for them to access the data (they can't just filter based on search terms or file names, because they would have to decrypt them first). Whether or not it is effective legally or morally, I'm not qualified to say. They aren't really zero-knowledge, so much as unable to automate filtering solutions - a human employee with file system access could see what was in the file just like their client/customer could. I wouldn't bet my life on such a system holding up to any legal (or illegal) scrutiny. – BrianH Aug 28 '14 at 13:50
  • Carlier - No, your comment is incorrect. It is perfectly possible for the host to be unable to access any of the data and yet let the owner share it – Rory Alsop Aug 28 '14 at 14:02
  • @RoryAlsop Then can you explain me how? I mean, if the user share it, and share it **publicly**, everyone would access it, And everyone include the host. No? –  Aug 28 '14 at 14:07
  • You have placed an assumption I didn't make: sharing publicly is not usually the case. Sharing to a group, or selected individuals is much more common in these instances. The group does not include the host. – Rory Alsop Aug 28 '14 at 14:22
  • Then yes, I could understand how the file can still be secured, Thank you –  Aug 28 '14 at 14:25
  • @CarlierRobin I just realized from reading Rory's comment that I misunderstood your comment - I thought that the KEY was also shared by the same service. But no, if the service doesn't have the key then they can't access the file contents - they have no way to know if it's cute pictures of puppies or pictures of nude...puppies, or a copy of Star Wars HD. If the host is given the key and they allow you to share the key itself along with the files, then my first comment applies. – BrianH Aug 28 '14 at 14:52
  • @BrianDHall It confirms what I thought, A service can not legaly store both data and key. if they do, they don't respect privacy and looses their "legal protection" against illegal file hosting –  Aug 28 '14 at 15:04
  • I think I can clear this up. A workable solution is to encrypt each object with a per document key and store that key encrypted with the users secret password. Then to share the file I encrypt the document key with the other users public key, knowing only they can decrypt it and send that along with the location of the file. If I want to revoke access later I just move the object to a new location with the location being derived from GUID's it would be impossible to workout where it went even thought key has not changed. – dave.zap Oct 30 '16 at 14:05
1

The answer BrianDHall provided is correct but I wanted to add a few more details around the idea of "Zero Knowledge" as it is only true in the context of removing the ability for the storage provider to decrypt your files.

Other meta attacks on such systems do exist and may be launched by the provider in cooperation with say the police (or other government organisation) or by an attacker who has direct access to the servers or a trojan on your client device.

A trojan could log key strokes exposing your private password rendering the whole thing pointless.

If you have an account with any of these providers you have probably given them your user name, email address, credit card information that links back to you.

Then consider how does the provider delete encrypted files once you close your account? The only way they can do that is by linking your user name to the encrypted objects in the store. So now meta data such as the number of files, possibly the tree structure used to store them, the size, the dates and times those files were created and accessed.

If I'm a movie studio and want to work out who has uploaded a movie, I might encrypt and upload it to my own account determine the encrypted object size and then ask the provider for a list of names of people who have stored the same size objects and then send all those users a legal looking thread asking for payment and see who bites.

It all depends on the specific implementation and how much trust you place in the storage service provider.

dave.zap
  • 131
  • 5