Here is the system: The client side of our system generates confidential data that needs to be encrypted. Only the user should be able to read them, by that, I mean that even us who managed the data base and the whole application should not be able to decrypt this data. I cannot think of a good strategy for the key here. In anycase, it seems like more than the user can decrypt the data. I was thinking to generate the key in two part, we store one on our data base, but we would need the other half to decrypt. ok But how to create the 2nd half ? It is not possible from the user's password because we store it somewhere as well, which mean we would still be able to decrypt the data... If anyone has a suggestion? I am definitely not an expert in this type of problem...
-
Can't the client side just keep an encryption key which is not communicated to anyone, so the data is only decrypted by the client?– Dmitry GrigoryevJul 21, 2015 at 12:34
-
I forgot to mention, the client side is limit to be a webpage. So we do not store anything, on the client. If the user could remember a passphrase that we do not store then it would be "fine" (except that if he forget, then the data are lost)– AnewbisJul 21, 2015 at 12:37
-
1Oh just to mention the 2 keys you are talking about sounds like a standard RSA... @anewbis read my comment on the answer below, see if any of those take your fancy– TheHiddenJul 21, 2015 at 13:15
-
2Why don't you just do like MEGA does? Generate a random key, use it to encrypt/decrypt the data, and encrypt the key with the user's password, so nobody, even you, has access to it.– revJul 21, 2015 at 13:58
-
1@Anewbis - no you don't why would you need to? all the user has to do is enter their password it does not have to be stored anywhere unless YOU want to read it or decrypt it later, you can encrypt and decrypt on the fly no need to store the password– TheHiddenJul 21, 2015 at 14:23
1 Answer
Knowledge is power. In other words, if the user must be able to perform some action and nobody else should be able to do the same action, then there must be some value (a "key") that only the user knows, and nobody else.
Moreover, use of a value necessarily means having that value at hand; when you decrypt with a key, then you have that key, at least as long as you decrypt. If the key must be known to the user only, ever, then this implies that decryption shall occur only on a system that is under exclusive control of the user. To put things simply, decryption will have to happen on the user's machine (desktop system, laptop, tablet...) and not on any system that should never see the key (e.g. your server).
You thus have two issues to solve:
- How to store the key such that the user can access it, but only that user may access it.
- How to make the decryption happen on the client system in a way that you cannot easily circumvent.
The first problem can be dealt with using a local file or storage area. To some extent, you can help the client with some server-side storage and password-based encryption: if you have some piece of data D, then you can store on the server Ep(D), which is the encryption of D with a password p that the server does NOT know. Password-based encryption is hard in general; begin by reading this answer. In that model, the really user-specific knowledge is the password p, that the user transports in his head.
The second issue is more problematic. You won't solve it in pure JavaScript (in a Web context) because whatever JavaScript is executed by the client will be sent by your server, so your server always has the conceptual ability to send, one time, a malicious JavaScript that grabs the password/key/whatever and sends it back to you. I suppose that your problem here is not only to give the ability to decrypt data to the user alone, but also to do it so convincingly, i.e. to be able to demonstrate to third parties that you really cannot access the data. At the best of times, this is difficult; a possible strategy is to make the client use some local application code that can handle the decryption, and is signed by you, and is amenable to easy reverse-engineering (C#/.NET and Java come to mind here). If there is such a client application, then you can claim that you cannot discreetly plunder the user's data because it would entail pushing a malicious application on their system, that could later on be reverse-engineered, the signature incriminating you.
In pure Web without such a local application, forget it. The Java applet model could have been applicable, but will be hard to do in practice because not many people support Java applets nowadays (and .NET+SilverLight is even less widely deployed).
-
You pinpointed exactly the problem here. We don't have access to anything else than javascript in our case. So i guess it is kind of hopeless– AnewbisJul 21, 2015 at 12:58
-
@Anewbis can you install/ask to install browser extensions? :) The scenario would be similar as with the standalone apps.– MatissJul 21, 2015 at 13:06
-
1I like your thoughts, but surely pure web is not impossible nor improbable? Using a HTTPS or L2TP or a front end login script which you login with a https + L2TP and the Bcrpyt hash of the password you use is the AES password for any continuous connection? You could even use certificates if you want to be boring and simple about it :P but it can be heavy as in an easy set up you would need a port / vhost per client. Jul 21, 2015 at 13:12
-
No we cannot ask the user to install anything. It is designed to be used in very remote area (using a satellite relay for the connectivity), and only very limited connectivity, very wide range of terminal and wide range of users.– AnewbisJul 21, 2015 at 13:13
-
1@silverpenguin, how does any of that help? The concern is a subverted server; transport-layer protections do no good if the client is trusting whatever code the server sends to be non-hostile (and the server is in fact temporarily or permanently under control of an attacker). Jul 21, 2015 at 15:44