Re: Suggestion reg. encryption ??

Hi,

For your reference, have a look at
http://www.cybcon.com/~jkstill/util/encryption/encryption.html there is some good information from Jared, and a PL/SQL implementation of the Blowfish algorithm that I donated.

In answer to your first question:

1. Security being the priority , which would be the way to go & why ?

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:

1. It seems to only provide Electronic Code Book encryption, if you want Cipher Block Chaining you need to implement this yourself;
2. 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
3. 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:

1. 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).
2. 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.
3. There should be functions available so that derived keys are never exposed in the clear outside of a secure device.
4. 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?
5. 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.

1. 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).