11-15-05 07:51 AM
>I have the following task and would be interested the safe/secure/not
>intrusive design people can offer to accomplish it.
>
>I am creating an encrypted database (let's say it stored records for
>bank customers with primary key customer uid)
Chances are excellent that a bank customer will NOT have a UNIX
login (and therefore will not have a uid) on any bank computer
containing financial information or customer passwords.
On some systems, you will easily run out of available UIDs (especially
if they are 16 bits).
>Each customer calls a program that retrieved his record and no others
>from the db. A customer cannot modify db - nor can view records of
>others (well it is encrypted so, it won't really matter).
Doesn't it? Are you saying that each record has its own, separate,
encryption key? If not, the encryption won't help keeping the above
program from getting someone else's record: it's up to that program
to enforce the rules.
Now, what's this information used for, and who uses it? The
information probably has TWO users: the customer and the bank, and
the point of the site is likely to be communication in one direction
or both. It might just let him look at his balance, but that needs
to be updated periodically. Ok, so how does the bank keep track
of the encryption keys to update that balance if the encryption
keys for each record are different?
>A speical user uses a different program for that db - that can add
>customers, changing their information, remove etc.
>
>A key point.:
>
> .a. encrypting key shouldn't be known to anyone other than owner of
>the db.
But the program that accesses the customer records will have to
have the *de*crypting key to function. If you're using symmetric
encryption, that's the same as the encrypting key.
>Here is how I view the design:
>-------------------------------------------
>
>-Store db in the map data structure- that can be read from the
What's this 'map' thingy?
>[encrypted]]file - file readable by all but modifyable only by the
>owner of the program.
I wouldn't want users with a UNIX login shell anywhere near
such a file. Even if it's mode 600, just a "ls -l" on the
file gives away proprietary information.
>-store encryption key in the file only read/write by the owner
>
>-des_crypt or xcrypt to encrypt the file - they are not secure, can
>someone suggest a good usage or perhaps an alternative?
It is highly desirable that the records be independently decryptable
and independently updatable.
>-When a customer executes the program, the program determines the
>login name via getuid() and getpwuid() and prints its record. I intend
>to read the entire file, decrypt it and store it in map - can someone
>suggest a more effective way?
What's this map thingy? Leaving around a decrypted copy of the whole
file is way too dangerous, even if the only people with shell logins
are employees.
>- when a super user executes his program, the entire db is read, files
>added. augments removed and stored back in encrypted form to the file.
>
>--this lead to locking that I need to implement to avoid race
>condition. any suggestions which locking should be used in this case?
You almost certainly need to lock the file on a less-than-whole-file
granularity, but your design seems to be based on encrypting and
decrypting the whole file. I think locking contention over this
file is going to kill the design.
>This is the bold design guidelines and implementations issues. Would
>highly appreciate the input.
Gordon L. Burditt
[ Post a follow-up to this message ]
| 
