Oracle Encryption and the Solaris Cryptographic Framework
By Stefan Hinker-Oracle on Feb 09, 2010
In release 10gR2, Oracle introduced Transparent Data Encryption  - a feature that allows the encryption of individual columns of a table. In Release 11gR1, this was extended to tablespaces , allowing the creation of encrypted tablespaces which transparently store all tables and indexes in encrypted form. Both of these features help protect data against the risk of storage devices being lost, stolen or otherwise compromised.
The "Master Key", which is used to secure the individual keys for columns and tablespaces, is being stored in the Oracle Wallet. By default, this is simply a file with a location specified in sqlnet.ora. For applications with higher demands to security, it is also possible to move the Oracle Wallet to external devices, so called "Hardware Security Modules" . Access to these devices is realized using the PKCS#11 standard API. If you don't happen to be lucky enough to call one of these devices, for example the Sun Crypto Accelerator Card SCA 6000, your own, you can still use the same mechanism to store the Master Key in the Softtoken Store of the Solaris Cryptographic Framework [4,5], effectively simulating a real HSM. The Oracle-configuration stays exactly the same. And if a real HSM comes around some time later, you can use smart export/import to migrate your keys to that device without changes to the database.
Here now the steps necessary to achieve all this:
First of all, you create a normal Oracle Wallet. For this, add the following to your sqlnet.ora:
Now create your Master Key:
alter system set encryption key identified by "walletpasswd" ;
With this, you can now encrypt table columns (alter table oe.customer modify (credit_limit encrypt); ) or tablespaces (create tablespace test datafile '+DATA' size 10M encryption default storage(encrypt); ). You are still using the default Oracle Wallet at this point.
The next step is to migrate your existing Master Keys for column and tablespace encryption to the softtoken store. This still needs to be prepared. Each Solaris user has his or her own softtoken store, located in ~/.sunw. Therefore, preparing this softtoken store needs to be done as the Solaris user running the database. Set your own password for accessing the softtoken store using the command "pktool setpin". (The default password is "changeme", something you should of course do!) Now, the tokenstore is ready.
Next, Oracle needs to have access to the right pkcs11-libraries:
mkdir p /opt/oracle/extapi/32/hsm/sun/1.0.0
mkdir p /opt/oracle/extapi/64/hsm/sun/1.0.0
cp /usr/lib/libpkcs11.so /opt/oracle/extapi/32/hsm/sun/1.0.0
cp /usr/lib/sparcv9/libpkcs11.so /opt/oracle/extapi/64/hsm/sun/1.0.0
Finally, modify your sqlnet.ora:
Now you migrate your keys using the command:
alter system set encryption key identified by "scfpasswd" migrate using "walletpasswd";
To open and close the wallet, and make encrypted data accessible or not, with the commands:
alter system set wallet open identified by "scfpasswd";
alter system set wallet close ;
That's it - you've now configured Oracle to use the Solaris Cryptographic Framework's softtoken store to keep its Master Keys safe and sound. As a final step, you might want to modify the original Oracle Wallet to auto-open mode and to use the same password as the softtoken store. You do this with Oracle's WalletManager owm. (Thanks to Peter Wahl for pointing this out.)
Of course, this also works in RAC installations, not only single-instance. My recommendation here: Do all the configuration on one of your nodes, with the other's shut down. Then copy the auto-open Oracle Wallet and the SCF softtoken (~/.sunw) to all other nodes and only then start them. Otherwise, you risk having several different master keys in your different instances, which only leaves you with a "drop database" for recovery... Remember, each node needs to open the wallet individually! Synchronization between nodes has been included in release 220.127.116.11 . However, this assumes a wallet on a shared filesystem, which isn't usually possible with SCF, because each oracle user of a RAC installation wants his or her own home directory. The most elegant solution here: Get some SCA 6000 cards, which allow synchronization of their token stores via LDAP.
2010-02-23: I finally found what I thought I remembered: You can point SCF to an alternate location of the softtoken store (usually ~/.sunw) by setting the environment variable SOFTTOKEN_DIR. This can then also point to a shared directory available from all nodes of a cluster .
(This blog entry is a translation from the orginial german entry.)