6

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

Anewbis
  • 163
  • 2
  • 6
  • 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 Grigoryev Jul 21 '15 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) – Anewbis Jul 21 '15 at 12:37
  • Please note what technologies you use. PHP? MySQL? Linux? – TheHidden Jul 21 '15 at 13:07
  • So the front end is just a webpage (usual html/css/js), the back end is a mix of python and java with postgreSQL database – Anewbis Jul 21 '15 at 13:11
  • 1
    Oh 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 – TheHidden Jul 21 '15 at 13:15
  • 2
    Why 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. – rev Jul 21 '15 at 13:58
  • but the password must checked and stored somewhere, as we cannot have access to a third party for that. We have to store the password. Then we can decrypt the random, am i wrong ? – Anewbis Jul 21 '15 at 14:11
  • 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 – TheHidden Jul 21 '15 at 14:23
  • So the user would need to have a password for login and a password for encryption (known only by him) – Anewbis Jul 21 '15 at 14:30
  • Not necessarily, you can just use his login password. – rev Jul 21 '15 at 19:18
  • Have the encrypted data stream to between 1-30 different laser apparatus. Then, using laser pulses shoot the information to a sensor array 5 miles downstream to a sensor and computer that isn't networked to anything else. Another actor would have to intercept all 30 laser pulse streams (and then resubmit them in real time) in order to decrypt this data stream. – easymoden00b Jul 21 '15 at 19:48

1 Answers1

12

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

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 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 – Anewbis Jul 21 '15 at 12:58
  • @Anewbis can you install/ask to install browser extensions? :) The scenario would be similar as with the standalone apps. – Matiss Jul 21 '15 at 13:06
  • 1
    I 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. – TheHidden Jul 21 '15 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. – Anewbis Jul 21 '15 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). – Charles Duffy Jul 21 '15 at 15:44
  • @CharlesDuffy - Making the site accessible only over a Local would mean that no one can access it remotely unless they VPN in the encrypted connection then keeps the passwords the users input secure. as for AES using AES to encrypt the data means that the key does not have to be saved, using AES as the encryption along with L2TP(VPN) means that the possibility of a MiTM attack very unlikely. I have alot of reasons and ideas but no answers and a very short comment box to explain everything in extreme detail. I am just spitballing ideas for the sake of it. – TheHidden Jul 21 '15 at 16:03
  • @silverpenguin, it wasn't a MITM attack that Thomas and I were proposing, it was an attacker successfully compromising the server -- the server that *isn't supposed to have access to customer data*, but provides all the code that they run. – Charles Duffy Jul 21 '15 at 16:04
  • @CharlesDuffy, Ah ok I am following you, I misunderstood. I thought the discussion was just all aspects of an attack and security, I shall silence now. :) – TheHidden Jul 21 '15 at 16:08
  • @silverpenguin: client-side certificates sound promising, especially since the `` element makes generating a keypari and signing request in the browser easy. I think the private key can't be used for explicit client-side encryption, though, since I think the keypair is not accessible through javascript. – Ulrich Schwarz Jul 21 '15 at 19:07
  • I understand what you guys are saying but I lack of knowledge to add to the discussion... It seems like they should hire an expert on the problem. It looks like being constrained to javascript on the client side is the main problem. – Anewbis Jul 22 '15 at 07:11