Re: Protecting the encryption key from the DBA

From: Frank van Bortel <frank.van.bortel_at_gmail.com>
Date: Sat, 23 Jul 2005 15:04:25 +0200
Message-ID: <dbtesu$1nc$1@news4.zwoll1.ov.home.nl>

Frank van Bortel wrote:

> Maxim Demenko wrote:
> 
> 

>>Dump of memory from 0x0CC12C00 to 0x0CC14C00
>>CC12C80 00000000 00000000 00000000 00000000 [................]
>> Repeat 499 times
>>CC14BC0 02012C00 3402C102 EDE7161B 5DA564F3 [.,.....4.....d.]]
>>CC14BD0 6D1CEE34 2DF13D3E F6A88FE7 B18237AB [4..m>=.-.....7..]
>>
>>Decrypted:
>>
>>Dump of memory from 0x0CC12C00 to 0x0CC14C00
>>CC12C80 00000000 00000000 00000000 00000000 [................]
>> Repeat 498 times
>>CC14BB0 00000000 02022C00 0502C102 6978614D [.....,......Maxi]
>>CC14BC0 02002C6D 3402C102 EDE7161B 5DA564F3 [m,.....4.....d.]]
>>
>>The only one encrypted value was "Maxim". Also, as i understand it, TDE
>>doesn't present encrypted data through SQL (decrypting on the fly) , but
>>encryts it in the data files... May be not exactly the feature, many
>>people have expected, but i find it not soo bad. And for encrypted
>>representation via SQL we still have DBMS_CRYPT.
>>

> 
> 
> Your understanding of TDE is the same as mine.
> You only failed to show the correct blocks: in your encrypted
> part, you show the blocks from CC14BC0 onward, while the
> unencrypted part starts at CC14BB0.
> 
> I used grep -a on the datafile, expecting to find *no* match; I found
> a match, so I concluded no encryption had taken place.
> 

I have already stated, I should not have used grep (or strings, as Tom Kyte suggested), but should have made a block dump. Tom Kyte also pointed out, the data is actually *moved* once altered to encrypted, or unencrypted.

This is actually the reason, grep or strings will still find the data - it's the *before* situation...

As the data is moved, that explains the shift in addresses, above.

In case anyone -apart from me- wondered...

-- 
Regards,
Frank van Bortel

Received on Sat Jul 23 2005 - 08:04:25 CDT