I'm not a big fan of the dbms_obfuscation_toolkit in its current
form. Although it gives you an implementation of the DES and Triple DES
algorithms it suffers from the following:

It seems to only provide Electronic Code Book encryption, if you want
Cipher Block Chaining you need to implement this yourself;

The encryption is performed in the server's memory with both the key and
data in the clear at some point; and even more serious

It does not provide for any key management.

The absence of key management is quite a draw back and in my opinion makes
the dbms_obfuscation_toolkit (and my PL/SQL Blowfish package for that
matter) next to useless as a tool for improving data security. The Oracle
documentation talks a little about key management and offers some naive
suggestions for filling the gap. In my opinion here is some of what the
documentation missed:

The encryption key(s) should be stored within a tamper resistant and
tamper evident device fitted with movement detectors (ie. the key is erased
if movement is detected).

No one person should know the entire key. Typically encryption keys
are randomly generated and exported in their component form (2+ components)
that are then given to separate component holders.

There should be functions available so that derived keys are never
exposed in the clear outside of a secure device.

The PL/SQL suggestion within the Oracle documentation would seem to
make it difficult to roll the key when it needs to be changed. Also
literal values do not get obfuscated by the wrap command so I didn't really
understand how wrap was to provide any protection. Could someone explain
this to me?

Storing the clear keys in the database means that not only does your
database security need to be reviewed but most likely your security
procedures around your on-site and off-site backups now need to be
strengthened. Most companies seem to have third parties storing off-site
backups - it is probably not a good idea to hand a backup tape to someone
that contains both keys and the data that the keys protect.

Regarding Java, the Java Cryptographic Extensions API will give you an
interface to a key store and encryption algorithms. It is up to the merits
of a particular JCE implementation that you have to examine, some
implementations are secure, some are not.

In answer to your second question:

2. How is it normally done ?

From reading this list, my guess is that some people have implemented
encryption using the dbms_obfuscation_toolkit. Some people have asked me
if they could use the Blowfish package I donated to Jared's site. Some
people have used the Java Cryptographic Provider provided by SUN within
their application. And from my own experiences I know others have
implemented their own cryptographic code in Java/C++/etc.

If you are serious about security being your priority then I would suggest
that you make use of one of a number of Hardware Security Modules (HSM)
available on the market. They have a bit of a learning curve to them but
they are the only way to go for any serious endeavor. Forget about
dbms_obfuscation_toolkit.

I've worked with a couple of devices and have provided a brief description
of them below.

Thales RG7100 HSM (RG8000 now available) . The device can connect to
your host system via a number of interfaces (ethernet included). This
device provides key management functions and stores one master key (called
the LMK) in its secure memory. All other keys (ie. your key to encrypt the
credit card numbers) are stored external (ie. in a file or database) to the
device encrypted under the LMK such that they can only be decrypted within
the secure memory of the device (ie. the keys are never exposed in the clear).

This device would be useful if you wanted to share a single device between
a number of hosts that needed to perform encrypts/decrypts on credit card
numbers. Alternatively, it is quite easy to conceive an application that
multiplexes encrypt/decrypt requests to a pool of HSMs if one HSM is not
fast enough for your needs. Although the device is fast, crypto can still
take a bit of time.

2) Eracom CSA8000. This device is a card that you insert into a PCI slot
and has a Java Cryptographic Extensions API. Like the Thales HSM, this
device also has a tamper detector protecting its secure memory. Unlike the
Thales HSM this device has approximately 1MB of memory for key storage and
has no LMK - you store your actual encryption key inside the secure memory
of the board - not externally. The device provides key management
functionality. I think Eracom also make a card that will do SSL too.

3) I heard that IBM make a crypto board that is quite cheap. I have never
used it so I cannot comment on it.

Anyway I hoped this helped. I'm happy to provide further information if
you need it.

Regards,
Craig Munday.

At 10:34 PM 28/09/2003 -0800, you wrote:
>Hi List,>>Application desc : Something similar (not exactly) to a >payment gateway ; java/oracle 9iR2 will> be used to develop it; need to > store credit card numbers (encrypted) in the> database ; SSL will be used for > secure transactions;>>Suggestion needed : this being the case, credit card number >encryption can be done with> either java or oracle > (dbms_obfuscation_toolkit) ; the developers came to> me for a suggestion; and i'm here > in front of u seeking the same;>> 1.Security being the priority , > which would be the way to go & why ?> 2.How is it normally done ?>>TIA.>Jp.>>>-->Please see the official ORACLE-L FAQ: http://www.orafaq.net>-->Author: Prem Khanna J> INET: jprem_at_kssnet.co.jp>>Fat City Network Services -- 858-538-5051 http://www.fatcity.com>San Diego, California -- Mailing list and web hosting services>--------------------------------------------------------------------->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).

--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Craig Munday
INET: cmunday_at_bigpond.net.au
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).