views:

182

answers:

2

Hi Guys,

I have an interesting encryption problem at hand. I do not know if it can be solved but here goes:

A database is to contain sensitive user information. As such, the user information must be encrypted (two way encryption). The user has a login / password and these may be used in the two way encryption. Now, the encryption is to be designed in such a way that even the administrator viewing the database tables should not be able to make sense of the user information.

However, the design has to take care of the cases where the user may forget her password. If the password is used for encryption, forgetting the password means the information is lost - not wanted. If the user password itself is stored in the database using a two way algorithm (instead of a one way hash) with a key hardcoded in the script, the administrator can discover the hardcoded key by looking at the script (the administrator of course has access to the script).

Does anybody know a way out of this?

PS: This is a real problem. My company is an absolute security fanatic (ISO 27001 and all) and I have been entrusted to design a system with the above mentioned functionality. By the way, I am using a PHP script and MySQL.

EDIT: Perhaps it was not clear earlier, the user needs to see / edit this user information on a day-to-day basis.

+1  A: 

Can't be done.

In all cases, someone has to be able to recreate the key to decrypt it. Let's consider the options:

  1. Key stored on server. Fails: administrator has access.
  2. Key encrypted with user's password. Fails: user might forget it.

The solution is to relax the administrator having access restriction, and instead of impossible, you make it just very difficult. For example, if the data were encrypted with a key stored encrypted with the user's password, but that key were escrowed in some other system which can't be accessed in the normal course of events by the administrator (perhaps only another admin has access?) then you can still recover from a user forgetting their password (with intervention of whoever has access to escrowed keys), but the admin can't just download your database and read all the data.

Kevin Peterson
But is this how extremely secure systems like banks etc. work? I ask this because I believe somebody else would definitely have cracked this problem and banks appear to be a strong candidate.
Crimson
Banks etc use Hardware Security Modules for their encryption
Umair Ahmed
I agree, it's a Ghostbusters scenario. Separate the Keymasters from the Gatekeepers, the people in control of user account passwords from those in control of the user's data, and you will be able to avoid having a bad employee as a single point of failure. That's good, because the alternative is total protonic reversal.
zombat
@zombat LOL!
Greg B
+11  A: 

What you want is a recovery agent. Encrypt all data twice: once with the user key, once with the recovery agent (public) key; atleast the latter one needs to be asymmetric. Keep the recovery agent key in a pyhsical safe, with a formal access protocol (e.g. four eyes principle). Usually, the administrator cannot access the encrypted data, but if the user loses the key, and recovery is authorized, then the recovery key is obtained.

There are also ways to encrypt the recovery agent's key so that m-out-of-n people have to agree to use it.

Edit: One implementation strategy is to encrypt everything twice. Alternatively, for each data set that needs to be recoverable independently, create a fresh symmetric key, and encrypt only that key twice; the original data get encrypted only with the session key. That approach can extend to multiple independent readers; it requires asymmetric keys per reader (so that you can encrypt the session key with the public keys of all readers - one being the recovery agent).

I copied the terminology from Microsoft's Encrypting File System, which has that scheme implemented.

Martin v. Löwis
Simple and elegant
Umair Ahmed
Could you please provide some reference links where I can read up further?
Crimson
Further, would not encrypting everything twice mean that the user herself would not be able to retrieve / edit the user information?
Crimson
If I understand correctly, Martin suggests storing user data twice in the database - once encrypted with user key, once encrypted with recovery agent key.
Juozas Kontvainis
@Crimson: see my edit. The user can still retrieve the information. When modifying it, the user would again need to encrypt the new data with the recovery agent's public key.
Martin v. Löwis
very nice. One concern however might be the sizing (h/w[cpu] and storage [db]) because this method, though elegant argueably ~doubles the storage requirements as well as the processing power.
Ryan Fernandes