SEO

Hi Me,



The more I think about it, the harder this gets ... perhaps it's just
'over egging the pudding' at this stage.



Would we be better off with something *MUCH* simpler and almost
completely under the control of the application...



We store the cryptographic keys in the databases config file - the
application owner/designers need never know what they are. The keys can
then be cached in the server when the database is loaded and restricted
to specific roles, (but not groups or users (?)). Only a
security_administrator can insert, update or delete an encryption key.



The application may then call an encrypt/decrypt function on any data
field it likes, what it does with the data is its business, and if it
stores encrypted data in a table then that's cool too. Any database
restore will bring back the config file with the necessary keys.
Changing a key then becomes a management issue just like adding a new
column to a table. We could also have a specified encryption function
as a configuration option.



And in the bulk download scenario, the downloader can't connect to the
database as a specific role - as per normal, that's password protected,
hence they can't get the key access, so any download of the data can't
decrypt it.



Is that a better solution?



Is it adequate?

It would easily allow for multiple keys by tieing a specific key to a
specific role, but would struggle to have a specific key for a specific
table or column.



Marty

--

Random Titus Quote #1:

Every great man was thought to be insane before he changed the world.

Some never changed the world - they were just insane.



From: info-ingres-bounces@kettleriverconsulting.com
[mailto:info-ingres-bounces@kettleriverconsulting.com] On Behalf Of
Martin Bowes
Sent: 22 November 2007 09:02
To: info-ingres@kettleriverconsulting.com
Subject: [Info-Ingres] Encryption of Data at Rest



Hi Everyone,



Does anyone know if there are any plans to introduce data encryption
into the database? I'm not talking about encryption on data in flight,
Ingres/Net can handle that quite adequately. What I want is to be able
to encrypt data when stored in the database and ensure that unless the
proper key is given that the data displayed is gobbeldygook.



I'd like to be able to - and I apologise in advance, the following is a
stream of consciousness:

1. Encrypt on AES/Rijndael cipher specific columns in a table.

Probably just non index items will do for a starter.

I don't need to have different rows encrypted on different keys, but I
could see situations where that might be useful.

2. Have multiple keys allowed so column X might be encrypted with one
key and column Y with another.

3. Be allowed to change keys.

Although how that will work on existing data encrypted on an old key
will be fascinating particulary if the table is huge. Probably would
need to store a uuid to identify the key in time as well as the data
encrypted with that specific key and then have some modify command to
heal it all up at some point, table partitions may be useful here. Hmm,
that may help with allowing horizontal differences in encryption keys.

4. Not store the encryption keys in the database.

But it would be good to do it in something attached to the database so
it could be part of the backup cycle. This would allow the recovery of
older databases and their older encryption keys.

My thought was to extend the configutaion file.

5. Encryption key restricted access.

Only people with a specific privilege can access the keys. Not even
database owners should be automatically granted the privilege.

Although I'm not sure how applications can then specify the encryption
key required to decrypt data...Embed it like a role password?



If anyone has some thoughts on this then lets here them!



Martin Bowes

--

Random Duckman Quote #74:

Cornfed: Oh....I must say I'm surprised at how readily you boys
bastardized

your code of ethics in order to justify a morally dubious
decision.

That was very grown up of you.