Dienstag Mai 15, 2012

T4 Crypto Spickzettel

Wie man die T4 Crypto-Beschleuniger fuer Oracle TDE nutzbar macht, habe ich ja bereits in einem frueheren Beitrag erwaehnt.  Daran hat sich nichts geaendert, auch der Patch fuer Solaris 10 ist immer noch in Entwicklung.  Es gibt ja aber noch reichlich andere Verwendungsmoeglichkeiten fuer die Crypto-Hardware der T4.  Da sich die Implementierung gegenueber frueheren CPUs deutlich veraendert hat, ist auch die Verwendung und das Monitoring etwas anders geworden.  Daher hier eine kurze Zusammenfassung dieser Aenderungen:

Verwendung:

 Feature / Software consumer
 T3 und frueher*
 T4 / Solaris 10
T4 / Solaris 11
 SSH

Automatisch aktiv seit Solaris 10 5/09.

(De-) aktivieren mit der "UseOpenSSLEngine" Klausel in /etc/ssh/sshd_config

Automatisch aktiv, benoetigt Patch 147707-01

(De-) aktivieren mit der "UseOpenSSLEngine" Klausel in /etc/ssh/sshd_config

Automatisch aktiv.

(De-) aktivieren mit der "UseOpenSSLEngine" Klausel in /etc/ssh/sshd_config

 Java / JCE

Automatisch aktiv.

Konfiguration in $JAVA_HOME/jre/lib/security/java.security

Automatisch aktiv.

Konfiguration in $JAVA_HOME/jre/lib/security/java.security

Automatisch aktiv.

Konfiguration in $JAVA_HOME/jre/lib/security/java.security

 ZFS Crypto
Nicht verfuegbar
Nicht verfuegbar HW crypto automatisch aktiv, falls Dataset verschluesselt.
 IPsec

Automatisch aktiv.

Automatisch aktiv.

Automatisch aktiv.

OpenSSL

Aktiv mit "-engine pkcs11"

Requires patch 147707-01

Aktiv mit "-engine pkcs11"

Die Engine "t4" wird automatisch verwendet.  Optional "-engine pkcs11" angeben.

Pkcs11 derzeit empfohlen fuer RSA/DSA.

KSSL (Kernel SSL proxy)

Automatisch aktiv.

Automatisch aktiv.

Automatisch aktiv.

Oracle TDE

Nicht supported

Patch in Entwicklung.

Automatisch aktiv mit Oracle DB 11.2.0.3 und ASO

Apache SSL
Konfiguration mit "SSLCryptoDevice pkcs11"
Konfiguration mit "SSLCryptoDevice pkcs11"
Konfiguration mit "SSLCryptoDevice pkcs11"
Logical Domains
Crypto Units (MAUs) den Domains zuweisen.
Immer verfuegbar, keine Konfiguration notwendig.
Immer verfuegbar, keine Konfiguration notwendig.

* T1 CPUs kennen noch keine Unterstuetzung fuer symetrische Chiffren wie AES.  Anwendungen wie SSH verwenden daher auf T1 Software Crypto.

Monitoring:
  • Anders als bei T3 und frueher wird bei T4 kein Kernel-Modul wie ncp oder n2cp benoetigt.  Entsprechend ist die Crypto-Hardware weder mit kstat noch mit cryptoadm sichtbar.
  • T4 stellt jedoch Hardware Zaehler fuer Crypto-Operationen zur Verfuegung.  Diese kann man mit cpustat auswerten:
    cpustat -c pic0=Instr_FGU_crypto 5
    
  • Die Verfuegbarkeit der Engine fuer OpenSSL kann man mit dem Kommando "openssl engine" pruefen.  Die grundsaetzliche Verfuegbarkeit der Crypto-Operationen mit dem Kommando "isainfo -v".
  • Die Crypto-Operationen sind bei T4 als normale Assemblerbefehle verfuegbar.  Daher gibt es keine speziellen "Crypto Units" mehr, die bspw. mit cryptoadm verwaltbar waeren.  Aus dem gleichen Grund sieht auch der LDom Manager keine "Crypto Units".  Die Funktionalitaet ist immer und ueberall verfuegbar und muss nicht separat konfiguriert werden.  Fuer den LDom Manager sollte man dennoch den neuesten LDoms Patch 147507 installiert haben.
Weiterfuehrende Links:

Montag Nov 07, 2011

Oracle TDE und Hardwarebeschleunigte Verschluesselung

Endlich gibt es sie, die kurze, knappe Beschreibung, mit welcher Kombination aus Hardware und Software man mit Oracle TDE in den Genuss von Hardwarebeschleunigung fuer die Verschluesselung  kommt.  Hier die Zusammenfassung der Zusammenfassung ;-)

  • SPARC T4 oder Intel CPU mit AES-NI
  • Solaris 11 oder Linux (ein Patch fuer Solaris 10 ist in Arbeit)
  • Oracle 11.2.0.3
    • Unter Linux geht es auch mit 11.2.0.2 und Patch 10296641

Die Langfassung der Zusammenfassung gibt es in MOS-Note 1365021.1

Frohes Verschluesseln!

Dienstag Jun 01, 2010

SCA 6000 fuer Oracle TDE

Im Februar  hatte ich beschrieben, wie man den Softtoken Store des Solaris Cryptographic Framework als "Software-HSM" fuer Oracle TDE konfiguriert.  In der Zwischenzeit wurde nicht nur die SCA 6000 als HSM fuer Oracle TDE zertifiziert und die Konfiguration dokumentiert, sondern ich konnte das auch selbst einmal testen.  Dass es funktioniert, versteht sich von selbst.  Was die Verwendung der Karte attraktiv macht, sind die zusaetzlichen Moeglichkeiten, die die Karte bietet.  So kann man den Keystore sperren, was ein erneutes "open wallet" sowie die einzelnen Funktionen der Spaltenverschluesselung verhindert.  Auch ein 4-Augen Prinzip laesst sich hier realisieren.  Damit kann in einer Umgebung mit entsprechenden Sicherheits-Anforderungen der Zugriff auf den Master-Key von der "normalen" Datenbank-Administration getrennt werden.  Und das ist, gerade in solchen Umgebungen, ein Vorteil.

Montag Feb 08, 2010

Oracle Encryption und das Solaris Cryptographic Framework

Seit Oracle 10gR2 gibt es die Moeglichkeit, einzelne Spalten einer Tabelle zu verschluesseln[1].  Als Erweiterung hiervon ist es seit Release 11gR1 moeglich, ganze Tablespaces zu verschluesseln[2].  Beide Features ermoeglichen es, sensitive Daten davor zu schuetzen, dass der Datentraeger auf irgend eine Weise ausgespaeht wird.


Der Master Key, der die Schluessel fuer die Verschluesselung von Spalten bzw. Tablespaces absichert, wird im sogenannten "Oracle Wallet" gespeichert.  Dies ist ueblicherweise eine Datei, deren Speicherort in der sqlnet.ora festgelegt werden kann.  Fuer Anwendungen mit besonders hohem Schutzbedarf ist es jedoch auch moeglich, diesen Master Key in einem externen Geraet, einem sogenannten "Hardware Security Modul" (HSM) abzulegen[3].  Der Zugriff auf diese Geraete erfolgt ueber den Standard PKCS#11.  Da nicht jeder immer gleich Zugriff auf tatsaechliche HSM-Hardware wie z.B. die Sun Crypto Accelerator Karte SCA 6000 hat, kann man statt dessen auch den Softtoken-Store des Solaris Cryptographic Framework [4,5] als HSM nutzen.  Die Oracle-seitige Konfiguration ist die gleiche, und ggf. kann man zu einem spaeteren Zeitpunkt ein "echtes" HSM dazu konfigurieren.  Die Schluessel lassen sich dann mit geschicktem export/import migrieren.


Hier nun die notwendigen Schritte:


Als erstes legt man ein normales Oracle Wallet an.  In der sqlnet.ora traegt man dazu folgendes ein:



ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
(method_data=
(directory=/opt/oracle/product/11.1.0/oracle/network/admin)))


Dann erzeugt man den Masterkey mit:



alter system set encryption key identified by "walletpasswd" ;


Damit kann man nun bereits Spalten (alter table oe.customer modify (credit_limit encrypt); ) oder Tablespaces (create tablespace test datafile '+DATA' size 10M encryption default storage(encrypt); ) verschluesseln. Bis hierher wird noch das "normale" Oracle Wallet verwendet.


Als naechstes migriert man nun die jetzt bereits vorhandenen Master-Keys fuer Spalten bzw. Tablespaces in den Softtoken.  Dazu muss dieser erst vorbereitet werden.  Da jeder Solaris-User einen eigenen Softtoken-Store hat (~/.sunw), muss dies als der Oracle-User erfolgen, unter dessen UID die Datenbank betrieben wird.  Dieser Benutzer setzt mit dem Kommando "pktool setpin" ein eigenes Passwort fuer den Tokenstore.  (Das Defaultpasswort ist "changeme", ein Ratschlag, den man natuerlich beherzigen sollte.)  Damit ist der Tokenstore bereit. 


Nun muss Oracle noch Zugriff auf die PKCS#11-Library bekommen:



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


Als letzte Vorbereitung wird nun die sqlnet.ora geaendert:



ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM)
(method_data=
(directory=/opt/oracle/product/11.1.0/oracle/network/admin)))


Die Migration der beiden Master-Keys dorthin erfolgt nun mit:



alter system set encryption key identified by "scfpasswd" migrate using "walletpasswd";


Das Wallet auf und zu (und die Daten damit zugaenglich oder auch nicht) macht man mit den Kommandos



alter system set wallet open identified by "scfpasswd";
alter system set wallet close ;


Damit verwendet Oracle jetzt den Softtoken-Store des Solaris Cryptographic Framework, um seine Masterkeys zu speichern. Wer moechte, kann nun das alte, obsolete Wallet von Oracle entweder loeschen oder in ein auto-open Wallet wandeln. Letzteres geht mit dem WalletManager (owm) von Oracle. (Danke an Peter Wahl fuer diesen Hinweis).


Das ganze funktioniert natuerlich nicht nur Single-Instance, sondern auch im RAC.  Meine Empfehlung dazu: Die Vorbereitung vollstaendig auf einem Knoten machen, dann den Softtoken, also ~/.sunw, auf die anderen Knoten kopieren, dann erst diese starten.  Ansonsten laeuft man Gefahr, dass einzelne Knoten unterschiedliche Masterkeys erzeugen, und dann bleibt, soweit ich weiss, nur ein "drop database"...  Synchronisation der Keys zwischen den Knoten gibt es mit Release 11.2.0.1. [6].  Dabei wird allerdings ein Wallet auf einem gemeinsamen Filesystem vorausgesetzt.  Da dies mit dem SCF normalerweise nicht moeglich ist (da ja die Oracle-User eigene Homeverzeichnisse haben), muss der Softtoken hier weiterhin manuell kopiert werden.  Besonders angenehm macht es hier die Software der SCA 6000, die es ermoeglicht, mittels LDAP zu synchronisieren...


Nachtrag (2010-02-23): Der Speicherort des Softtoken, normalerweise ~/.sunw, kann mittels der Umgebungsvariablen SOFTTOKEN_DIR beliebig gesetzt werden, und damit auch auf ein von allen Knoten aus zugaengliches gemeinsames Verzeichnis [7].


[1] Transparent Data Encryption (TDE)
[2] Tablespace Encryption
[3] Anleitungen
[4] SCF auf BigAdmin
[5] SCF auf docs.sun.com
[6] Neu mit 11gR2
[7] manpage zu pkcs11_softtoken(5)


2010-02-10:  This blog entry is now also available in english.

About

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.

Search

Categories
Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute