RE: Encryption - Question about the key

No problems with this system; troubleshooting has not been an issue. The key is actually also stored in management's hidden place of choice (I have no knowledge; it's probably in all likelihood either a cleartext file in email or on a few people's hard drives.)

But changing keys is something we're going to need to do, especially as attrition sets in. I had suggested keeping another column on each row as a sort of key sequence (if we convert from one key to another "organically" as the app uses the data) or key seeding value. You could potentially store millions of "keys" in a table further obfuscating the true key -- again -- the main idea here is to split the key management work into the application logic to make it more difficult to get the true key.

Key management is just as tricky as all the other parts, and certainly what we're doing is a lot better than plainly storing the key in the database, but it's got its own weaknesses. I like the idea of using a hardware device to store/manage the keys -- and have all the encrypt/decrypt happen there, so the key is never sent anywhere. That's about as secure as you can get. As long as you implicitly trust that device .. and have a backup of it so there's no single point of failure..

The way I look at security is (mostly) working to keep the honest people honest. You won't *stop* the truly malicious; your best bet is to set traps to alert yourself to their presence and hope to the deity of choice that they fall for your honeypots.

Steve

-----Original Message-----
Sent: Tuesday, December 18, 2001 7:49 PM To: ORACLE-L_at_fatcity.com; Austin, Steve S

This sounds great until something doesn't work properly.

Bet it's difficult to toubleshoot.

Has this setup given you any problems in that regard?

Jared

On Tuesday 18 December 2001 16:25, Austin, Steve S wrote:
> What we do is have the application manage the encryption keys. The DBA
> therefore only has access to the encrypted data. Being the DBA in this
> equation, I am exonerated from having easy access to the keys, and
> therefore exonerated when it comes time to hunt down perpetrators (well,
> nearly!) :). I further suggested that they split the key into parts and
> allow the DBA, root, and the application owner to put in parts to derive
> the actual key that is not stored anywhere, but exists only in the memory
> of the app. This did not go over well. :) We're also looking at
> procedures to change the keys, since any set of encrypted data is a
target,
> and if you change the keys, it's a "moving" target.
>
> hope this is interesting if not amusing.
> sa
>
> -----Original Message-----
> Sent: Tuesday, December 18, 2001 3:55 PM
> To: Multiple recipients of list ORACLE-L
>
>
> Believe it or not Jared, one of your script gave me following idea (the
> wrapper sql for decrypt/encrypt on your site).
>
> 1. I have a system users table, I can add a column to store user's key in
a
> column that only that user has access to.
> 2. Create a DBA owned package to handle encryption/decryption.
> 3. The key will be picked up in this package and used (maybe I'll use user
> key is used to derive the actual key).
> 4. The package will be deployed as 'wrapped' in production, so by looking
> at dba_source you won't find much.
>
> I'll have to test this though but I think this will make it a bit more
> secure.
>
> The question is "Can I trust myself?" The answer is 'Yes".
>
> Can someone see any drawbacks?
>
> 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!

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Austin, Steve S
  INET: steve.s.austin_at_xo.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).