Welcome to the security conundrum.
When it comes right down to it, there has to be someone
you can trust to have the keys to the kingdom.
Create a separate Oracle account with a single table
with one row in it; your key. Create a package containing
a function that can use the key to encrypt/decrypt data.
Grant 'execute ' on the package to the application account
or users that are trusted to use it.
Users can decrypt and encrypt data only by the interface
you provide. Since they don't have the key, the data
cannot be decrypted outside of the database, and false
encrypted data cannot be inserted into the database
without going through your interface.
This gives you the opportunity to examine any data
inserted into encrypted columns if you like in the event
that you could identify obviously false data.
I'm not a security expert, this is just where I would start
with really sensitive data, and then try to find ways to
break the security.
When it comes down to it though, you still have to know
who you can trust.
Jared
"Jamadagni,
Rajendra" To: Multiple recipients of list
ORACLE-L <[EMAIL PROTECTED]>
<Rajendra.Jamadagni cc:
@espn.com> Subject: Encryption - Question about
the key
Sent by:
[EMAIL PROTECTED]
12/18/01 08:10 AM
Please respond to
ORACLE-L
Hi all,
I am investigating using dbms_obfuscation_toolkit in my application. Now, I
need a key to encrypt and decrypt the key. The question is how to protect
the key? The data will be accessed from Forms application, reports, SQR
reports, SQLPLUS scripts.
I need to find a mechanism to
* hide the key from developers (or non authorized persons))
* preferable fetch the key from database
* make this fetching and storing key as non-intrusive as possible.
What are my options? A column on application users table that is not
accessible? Hard coding the key is out of question. Also I need to separate
keys for production and development servers.
As I am clueless, any ideas are most welcome.
Happy Holidays
Raj
______________________________________________________
Rajendra Jamadagni MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect that of ESPN
Inc.
QOTD: Any clod can have facts, but having an opinion is an art!
(See attached file: ESPN_Disclaimer.txt)
ESPN_Disclaimer.txt
Description: Binary data
