Montag Jan 14, 2013

LDoms IO Best Practices & T4 Red Crypto Stack

In November, I presented at DOAG Konferenz & Ausstellung 2012.  Now, almost two months later, I finally get around to posting the slides here...

  • In "LDoms IO Best Practices" I discuss different IO options for both disk and networking and give some recommens on how you to choose the right ones for your environment.  A couple hints about performance are also included.

I hope the slides are useful!

Donnerstag Mai 10, 2012

T4 Crypto Cheat Sheet

In an earlier post, I already mentioned what's needed to make use of T4 crypto acceleration for Oracle TDE.  This hasn't changed - the patch for Solaris 10 is still under development.  However, there are of course other usecases for hardware crypto on T4.  Since the code path to this functionality has changed considerably from earlier CPUs, there have also been some changes in how it's used and observed.  Here's a short summary of these changes.

Using it:

 Feature / Software consumer
 T3 and before*
 T4 / Solaris 10
T4 / Solaris 11

Automatically enabled with Solaris 10 5/09 and later.

Disable/Enable with "UseOpenSSLEngine" clause in /etc/ssh/sshd_config

Requires patch 147707-01

Disable/Enable with "UseOpenSSLEngine" clause in /etc/ssh/sshd_config

Automatically enabled.

Disable/Enable with "UseOpenSSLEngine" clause in /etc/ssh/sshd_config

 Java / JCE

Automatically enabled. 

Configure in $JAVA_HOME/jre/lib/security/

Automatically enabled. 

Configure in $JAVA_HOME/jre/lib/security/

Automatically enabled. 

Configure in $JAVA_HOME/jre/lib/security/

 ZFS Crypto
Not available
Not available
HW crypto automatically enabled if dataset encrypted.

Automatically enabled. 

Automatically enabled. 

Automatically enabled. 


Use "-engine pkcs11"

Requires patch 147707-01

Use "-engine pkcs11"

The engine "t4" is automatically used.  Optionally use "-engine pkcs11".

pkcs11 recommended for RSA/DSA at this time.

KSSL (Kernel SSL proxy)

Automatically enabled. 

Automatically enabled. 

Automatically enabled. 

Oracle TDE

Not supported

Pending patch

Automatically enabled with Oracle DB and ASO

Apache SSL
Configure with "SSLCryptoDevice pkcs11"
Configure with "SSLCryptoDevice pkcs11"
Configure with "SSLCryptoDevice pkcs11"
Logical Domains
Assign crypto units to domains.
Functionality always available, no configuration required.
Functionality always available, no configuration required.

* T1 CPUs do not support symetric ciphers like AES.  Consumers like SSH will therefore use software crypto on T1.

  • Note that unlike T3 and before, T4 crypto doesn't require kernel modules like ncp or n2cp, there is no visibility of crypto hardware with kstats or cryptoadm.  
  • T4 does provide hardware counters for crypto operations.  You can see these using cpustat:
    cpustat -c pic0=Instr_FGU_crypto 5
  • You can check the availability of the openssl engine with the command "openssl engine", and the general crypto support of the hardware and OS with the command "isainfo -v".
  • Since T4 crypto's implementation now allows direct userland access, there are no "crypto units" visible to cryptoadm.   For the same reason, there are no "crypto units" visible in LDoms Manager.  In LDoms, the functionality is always available and does not need to be configured separately.  Note that you should have the latest LDoms Manager Patch 147507 installed.
Additional Reading:

Dienstag Nov 08, 2011

Oracle TDE and Hardware Accelerated Crypto

Finally, there's a clear and brief description of the hardware and software required to use hardware accelerated encryption with Oracle TDE..  Here's an even shorter summary ;-)

  • SPARC T4 or Intel CPU with AES-NI
  • Solaris 11 or Linux (a patch for Solaris 10 will be provided eventually)
  • Oracle
    • If you use Linux, Oracle DB with patch 10296641 will also work.

The longer version of this summary is available as MOS-Note 1365021.1

Happy crypting!

Mittwoch Nov 24, 2010

Encrypting Your Filesystem with ZFS and AES128

ZFS filesystem encryption is finally available in Solaris 11 Express.  This closes a gap in Solaris that hurt all those that carried their data around with them.  But of course there are many good reasons to encrypt data living on disks well secured in a datacenter.  After all, they will all leave the datacenter in one way or another eventually...

Enough introduction, here's how simple this is:

  1. You will need to upgrade the zpool intended to host the encrypted filesystem to version 30.  Issue a simple "zpool upgrade <poolname>.  Of course, you can skip this step on a newly installed Solaris 11 Express.
  2. Now create a new filesystem, with encryption enabled: zfs create -o encryption=on <poolname/newfs>
    The command will interactively prompt for a passphrase which will be used to generate the key for this filesystem.  You're done!  You can not encrypt an already existing filesystem.  Of course there are several more options on how and where to store the key.  Just have a look at the manpage :-)

Likewise, you also have a choice of three different key lengths for AES, the algorithm used for encryption.  The default used for "encryption=on" is AES-128 in CCM mode.  But you can also choose the longer 192 or 256 bit keys.  While developing ZFS crypto, it was discussed what default keylength to choose.  AES-128 was chosen for two reasons:  First, of course, the 128 bit variant is faster than the longer key lengths, especially without hardware acceleration like it is available in the SPARC T2/T3 and Intel 5600 Chips.  Second, there is new research including successful attacks on AES256 and AES 192 that requires a search of only 2\^39.  These attacks don't work for AES128, which is therefore, as of today, not only faster, but also more secure than the variants with longer keys.

More details about ZFS Crypto in the ZFS Admin Guide.

Freitag Nov 05, 2010

DOAG 2010

This years DOAG 2010 (German Oracle User Group) Conference will see me busy.  I'll not only present about cryptography and new Oracle hardware, but also answer any questions you might have at the exhibition.  Hope to meet you there!

Dienstag Sep 21, 2010

No Excuse for no Security

Ever since Sun shipped the UltraSPARC T2 CPU, there was no excuse for not using SSL security for web services.  With the new T3 chips, this is more true than ever.  Not only have the supported algorithms been modernized.  The required documentation on how to use this feature has also been updated.  Find the first two papers hers.  I expect there to be more soon.

Happy encrypting!

Dienstag Feb 09, 2010

Oracle Encryption and the Solaris Cryptographic Framework

In release 10gR2, Oracle introduced Transparent Data Encryption [1] - a feature that allows the encryption of individual columns of a table.  In Release 11gR1, this was extended to tablespaces [2], 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" [3]. 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/ /opt/oracle/extapi/32/hsm/sun/1.0.0
cp /usr/lib/sparcv9/ /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 [6].  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 [7].

[1] Transparent Data Encryption (TDE)
[2] Tablespace Encryption
[3] Admin Guides
[4] SCF on BigAdmin
[5] SCF on
[6] New in 11gR2
[7] manpage of pkcs11_softtoken(5)

(This blog entry is a translation from the orginial german entry.)


Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« July 2016