Re: Database design and confidential data protection

From: Anne & Lynn Wheeler <lynn_at_garlic.com>
Date: Sun, 16 Nov 2003 21:47:25 GMT
Message-ID: <uu154asxs.fsf_at_earthlink.net>


Christopher Browne <cbbrowne_at_acm.org> writes:
> The "standard" work on this is called _Translucent Databases_.
> <http://www.wayner.org/books/td/>
>
> Basically, the idea is that sensitive fields are encrypted using
> keys that are user-specific. (Probably using some form of PK
> encryption.)
>
> A characteristic example would be of storage of cases by a national
> rape crisis organization. In order to do statistical analysis and
> such, the data needs to be aggregated together across all offices.
> But the identities of the victims should only be accessible by the
> staff at the local office, and perhaps only the staff members that
> have worked with each specific victim.

the problem is different than most PK ... this would have multiple writers and well as multiple readers. PK tends to be multiple writers and a single reader.

For multiple readers ... you typically go thru some sort of access control system that maintains control over any encryption key. If the infrastructure controls the key ... rather than individuals ... then there can be little or no difference whether it is actually a symmetric key or an asymmetric key implementation.

A symmetric key implementation might, however use some sort of derived key for the actual encryption/decryption (making the environment somewhat less susceptable to a brute-force key attack). You find such implementations in the financial infrastructure where the infrastructure generates a derived key (for actual encryption/decryption) from the "master" key combined with some information from the transaction (like account number).

for patient records, a derived key might involve the infrastructure master key and some sort of patient number.

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ 
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Received on Sun Nov 16 2003 - 22:47:25 CET

Original text of this message