 |
|
Oracle Encryption
Security
Oracle Security Tips by
Burleson Consulting |
2008
Update - For a complete
treatment of the topic of Oracle security on the web, see these
books and resources:
This is an excerpt from the
bestselling book "Oracle
Privacy Security Auditing", a complete Oracle security reference
with working Oracle security scripts.
What is Encryption?
I have a tough time remembering numbers – any
number – ATM Card PIN, Social Security Number, telephone numbers,
pretty much anything that starts or ends with or is enclosed by
numbers. So I have a simple infrastructure – I write the numbers on
the objects they are used with, in code – a code only I can
decipher. In other words, I encrypt them to be decrypted using the
original algorithm used to encrypt them.
In our effort to prevent and discourage hackers
from obtaining valuable information from the database, we have
discussed the essential steps to take to prohibit unauthorized
access to the database and the tables. But what if the hacker
somehow gets in? In a recent report by a prestigious research
company, and also reported by other independent studies, most of
unauthorized data access is done from inside, not outside.
In a typical setup, the database is behind a
firewall and is not necessarily open to external traffic – making it
difficult, if not impossible, for hackers to break in from outside.
However, lax security policies or employees with their own agenda
can "sniff in" the sensitive data. Sometimes the urge to do that is
purely benign – perhaps for a conversation piece in a cocktail
party; but sometimes the intent is to obtain sensitive information.
In an insurance company, the information contained within the annals
of the database can be quite valuable, such as the history of
diseases a member may have been tested for or diagnosed with. This
information is defined within HIPAA as Patient Health Information
(PHI) and has been explicitly identified as data that is to be
protected.
This calls for the last line of defense for
protecting the sensitive data from prying eyes – making the data
useless for the unauthorized user – or encrypting it. In the case of
the insurance database, the sensitive information such as diagnosis
codes or physician comments could be stored as encrypted. In the
case of hospitals, the information could be even more sensitive – in
addition to the diagnosis codes, there are data about the patient's
credit card information, employer information, health history, and
much more. Of course, it is probably impractical to encrypt all the
information that needs to be protected. So a decision must be made
to choose the most important data to protect.
There are several ways data can be encrypted.
There are third party tools that encrypt the data before it gets to
Oracle. Similarly, the data is decrypted after it is fetched from
the database. However, they are outside the scope of the database.
Although it is valuable and practical – the cost may be prohibitive,
and may not be justifiable. Fortunately, Oracle provides certain
encryption routines to be used by the users. This book explores
those options and explains how to use them.
In all of the Oracle-supplied encryption
routines, the concept is fundamentally simple – the data is fed
along with the encryption key, and out pops the encrypted data. When
the need comes to decipher the data, the encrypted information and
the key both are fed into the routine, and the raw information comes
out.
However, the common element in both cases is
the key, called the encryption key. This key is literally the key to
get to the data, and thus becomes valuable and must be strongly
protected. If this key is lost, the encrypted data will not be
decipherable in any way. And, of course, if the hackers get this
key, they can decrypt the sensitive data. Needless to say, the
challenge is to somehow store the key in a secured manner so that
unauthorized users don't have access to it, but authorized users
should have no problem in using it to decrypt the data.
Types of Encryption
DES
There are several encryption schemes in use
today – with varying strengths and difficulty in deciphering the
contents. The most popular is the standard called DES (Digital
Encryption Standard). It was introduced by the American National
Standards Institute (ANSI) over 20 years ago and has been the de
facto standard or encryption, particularly in the financial services
industry. It uses a 64-bit key to encrypt the data. Actually only 56
bits of the 64 bits are used, but the user has to supply all the 64
bits. So the hacker has to try 256, or 72,057,594,037,927,936
combinations to guess the encrypted data.
DES3
The DES standard was difficult enough to crack
at the time it was introduced; but for today's powerful machines,
the encryption is rather prone to cracking by brute force. To
address the problem the standard was enhanced to DES3 (Triple DES
algorithm), which encrypts the DES encrypted data to make it more
difficult to crack. It can pass the DES encrypted data up to three
times through its encryption routine. Therefore, the hacker must try
2112 times for a two-pass scheme, or 2168 times for a three pass
one. Needless to say, this is more difficult to crack and is used
frequently.
Hashing
Hashing is making a string of characters from
an input string based on some calculations. This is primarily used
for check summing methods, where checksums (hashed) before and after
the transit are compared to make sure that the string was not
tampered with while in transit. This also provides a tool to have
some type of encryption. Please note that this is not an encryption
in the strictest sense of the term; it is not encrypted with a key
big enough to withstand deciphering programs, but the concept is
similar and is discussed briefly here. Also, there is no equivalent
of decryption – or de-hashing. So it is not used to encrypt data.
Oracle's Built-in Tools
Oracle has a suite of tools to implement
encryption inside the database. The primary package in providing the
APIs is the dbms_obfuscation_toolkit. In this chapter, we will
explore this package.
DES3 Encryption
Before starting to explain the concepts and
usage, it might be helpful to see an actual example of the
encryption routine in action. If we need to encrypt a value 'TOOSENSITIVEINFO',
we would call
declare
v_encrypted_data varchar2(2000);
begin
dbms_obfuscation_toolkit.DES3Encrypt (
input_string => 'TOOSENSITIVEINFO',
key_string => '1234567890123456',
encrypted_string => v_encrypted_data
);
dbms_output.put_line('Encrypted Value = '||
v_encrypted_data);
end;
/
The output comes back as
Encrypted Value = ??ó?é??Az????ëf?
PL/SQL procedure successfully completed.
Note the value that comes back as encrypted. It
has some types of control characters, but can be easily stored in
the database as a varchar2 field. Let's dissect this little piece of
code.
The procedure DES3Encrypt takes two input and
one output parameters. One of the inputs is, of course, the string
to be encrypted. The other is the encryption key. In this example,
we have used a 16-byte key. In real life examples, you should
probably use longer keys to protect better.
To decrypt the encrypted data, we will use the
sister procedure, DES3Decrypt as follows:
declare
v_decrypted_data varchar2(2000);
begin
dbms_obfuscation_toolkit.DES3Decrypt (
input_string => '??ó?é??Az????ëf?',
key_string => '1234567890123456',
decrypted_string => v_decrypted_data
);
dbms_output.put_line('Decrypted Value = '||
v_decrypted_data);
end;
/
The output comes back as
Decrypted Value = TOOSENSITIVEINO
PL/SQL procedure successfully completed.
We used the same key used to encrypt the
original value and we got the results back. This should be enough
for you understand the basic workings of the encryption and
decryption routines. This type is known as symmetric encryption
model – the same key is used for both encryption and decryption.
Note, we have used a key of exactly 16
characters. Remember the definition of the Triple DES algorithm? It
passes an 8-bit key to the encrypted data through the encryption
operation again to get the encrypted data. In this case, the default
implementation of the DES3Encrypt procedure passes only once after
the original encryption by the 8-bit key; so there are two passes,
each with 8 bits. Therefore, the procedure requires a 16-bit key for
encryption. If a key of lesser length is specified, the procedure
will return an error. Longer strings are accepted but only the first
16 characters are used.
However, DES3 encryption is about three passes,
not two. The third pass is made by specifying a parameter in the
procedure to value 1, which ups the key requirement to 24 bits. For
example, the above encryption routine might be written for Triple
DES Encryption as.
declare
v_encrypted_data varchar2(2000);
begin
dbms_obfuscation_toolkit.DES3Encrypt (
input_string => 'TOOSENSITIVEINFO',
key_string =>
'123456789012345678901234',
encrypted_string => v_encrypted_data,
which => 1
);
dbms_output.put_line('Encrypted Value = '||
v_encrypted_data);
end;
/
Note the key supplied is 24-bit, not 8, and the
encrypted value will be different from the above case.
The DES3 encryption can be used in many
situations to provide strong security for sensitive data. Note the
key is the central figure in this scheme, and proper generation of
the key is vital to encrypt the data securely.
dbms_obfuscation_toolkit
Now that you understand the concept and
application of the package, let's explore what it has to offer.
Essentially, it offers encryption and decryption routines for DES
and Triple DES and a hashing routine for MD5. We saw the examples of
DES3 routines earlier. Let's expand on the features of this tool.
The following is an explanation of the procedures inside the package
 |
This is an excerpt
from the book "Oracle
Privacy Security Auditing". You can buy it direct from the
publisher for 30%-off and get instant access to the code depot
of Oracle security and auditing scripts. |
