Translucent Databases

问题:

I am building an application with health information inside. This application will be consumer-facing with is new for me. I would like a method to put privacy concerns completely at ease. As I review methods for securing sensitive data in publicly accessible databases I have frequently come across the notion of database translucency. There is the original book on the subject and an excellent tutorial on the subject from Oriellynet.

My concern is that I have seen very little information regarding this idea on what I would consider very-modern programming sites (like this one). There does not seem to be an article about the idea on wikipedia. No questions on the subject here, and no very recent tutorials or articles on the subject. To be uber-brief, the idea is that certain data is clear to some users of the system, while other users a cryptographically prevented from accessing that data, even if they have administrator access.

I have done substantial work on a prototype database that provides translucent data access. I have run across a considerable problem: To be truly translucent, there can be no mechanism for password recovery. If an administrator can reset a users password, then they can briefly gain access to a users data. To be truly translucent, the user must never loose the password.

Those of us who use strong encryption to protect private data in our daily lives (technorati to be sure) are used to this problem when using these kinds of strong encryption systems. If the word "blowfish" is part of your daily lexicon that is one thing, but a website that is consumer focused? I am concerned that users will not be willing to wrap their mind around the "truly encrypted just for you" notion implicit with true database translucency. I am afraid of the support call that begins with "I lost my password" and ends with me saying "There is nothing that I can do for you".

My question: Should I implement this method in my application? Are there other open source applications that have gone down this route that I can compare database designs with (esp using php/MySQL)? I anyone else pursuing these kind of truly secure, but really inconvenient feature sets? Is there another database security model that is more popular and modern that I have missed? Was database translucency a fad or a legitimate database design method that I should embrace? While I always appreciate discussion I would prefer objective answers that I can leverage in my design.

回答1:

So, I've been looking at something similar to this recently, and hit upon the same issue. The solution I'm considering implementing is as follows:

• Upon registration, create a unique, secure (long) key for the user and use this to encrypt their data.
• Encrypt this key with the user's password using e.g. AES and store it in the database.

At this point, you're still in the situation where if the user forgets their password, they've had it.

• Create a public/private key pair representing your organisation, and store the public key on the server.
• Split the private portion of the key into several components and give each to people (e.g. directors of your company) who have a significant stake (preferably financial) in the continued success of your company. Do this such that any two, or any three people can get together and restore the full private key when required. Encrypt each person's key with their own password.
• When a user registers, as well as encrypting their key with their password, encrypt it with the organisational public key and store it somewhere.
• Create a password reset form which records a request to reset the password of a user, along with some proof that the user is who they say they are (e.g. challenge/response).
• Record these reset requests (optionally encrypted using the public key again) in the database.
• Once per hour/day/week/month, get the requisite key-holders together, and use their combined keys to process the accrued reset requests, decrypting the keys of users who successfully proved they are who they say they are.

There are lots of challenges and considerations in this. I've got a few thoughts on most of these, but would be interested in others opinions too:

• How to split the key safely between multiple people so that no one person can decrypt the stored keys.
• How to minimise the number of keys that would be exposed if the 'master keys' genuinely fell into the wrong hands.
• How to make sure that if (heaven forbid) your key-holders lost their keys, then (a) there's no risk of exposure of the data, and (b) there's no risk that suddenly the ability to reset passwords is lost forever.
• How to successfully validate that someone really is who they say they are without making this a glaring hole in your whole security approach.

Anything you implement in this area WILL reduce the security of the translucent database approach, without a doubt, but this may be a worthwhile compromise depending on the nature of your data.

回答2:

Should I implement this method in my application? Well like other things in life, there is a trade off :) It's probably more secure but harder to built.

Are there other open source applications that have gone down this route that I can compare database designs with (esp using php/MySQL)?

Don't know, I guess the tools are there to do it yourself :)

Is anyone else pursuing these kind of truly secure, but really inconvenient feature sets?

Yes, but it seems like it's still in an immature state, like your problem you describe concerning lost passwords.

Is there another database security model that is more popular and modern that I have missed?

Basically there are two kinds of database connections. One option gives users a real database account, the other is to use single sign-on to the database. Prior to the web coming along, there were proponents of both models in the client/server world, but amongst web developers the single sign-on method is leading.

Was database translucency a fad or a legitimate database design method that I should embrace?

Don't think so, the UNIX password database, for instance, is a great example of a basic translucent database ;)

here something to read link text

回答3:

Re: translucent databases. You could, I suppose, use fingerprints. What about burn victims, or people who end up losing their fingerprints? Oops. Is it worth that small percentage of users?

Familiarize yourself with HIPAA, especially when it comes to technology. Remember that no system is truly secure, except Skynet*, and look what happened with that! Humans are in charge. When you work in a medical company, you sign an NDA indicating that you won't release any of the information you learn as part of your duties because it is confidential. There will be someone to reset people's passwords. That's the way it is, because not everyone is technologically competent, and that's the way it stays for now. You only have to implement security as well as HIPAA says.

• in truth, there is another truly secure system: it is unplugged from both the network and the electricity, and it is turned off.

回答4:

Slightly different solution, you might want to check out cryptdb:

http://css.csail.mit.edu/cryptdb/