Montag Jan 14, 2013

LDoms IO Best Practices & T4 Red Crypto Stack

Die DOAG Konferenz & Ausstellung 2012 war ja bereits im November.  Endlich finde ich die Zeit, die Slides zu den beiden Vortraegen auch hier zugaenglich zu machen.

  • In "LDoms IO Best Practices" geht es darum, die verschiedenen Varianten von Disk- und Netzwerk-IO darzustellen, zu vergleichen und Anhaltspunkte fuer einen optimalen Einsatz zu geben.  Der eine oder andere Performance-Hinweis ist natuerlich auch dabei.
  • In "T4 & the Red Crypto Stack" zeige ich, zusammen mit meinem Kollegen Heinz-Wilhelm Fabry, wie man Verschluesselung und andere Sicherheitsmechanismen in den verschiedenen Schichten des Red Stack benutzen kann, um eine recht gut abgesicherte Datenbank zu implementieren.

Ich hoffe, die Slides sind hilfreich und nuetzlich!

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!

Mittwoch Nov 24, 2010

Dateisystem verschluesseln mit ZFS und AES128

Mit Solaris 11 Express ist nun auch die Dateisystemverschluesselung mit ZFS verfuegbar.  Damit schliesst Solaris eine Luecke, die zumindest fuer all jene Festplatten die man ueblicherweise mit sich herumtraegt, dringend geschlossen werden musste.  Aber natuerlich gibt es auch viele gute Gruende, die im RZ gut gesicherten Festplatten zu verschluesseln - schliesslich werden auch diese irgendwann einmal das RZ verlassen...

Genug der Vorrede - so einfach geht das Ganze: 

  1. Der Zpool, der das zu verschluesselnde Dateisystem enthalten wird, muss mindestens auf Version 30 gebracht werden.  Das geht mit einem einfachen "zpool upgrade <poolname>.  Bei einem neu installierten Solaris 11 Express entfaellt dieser Schritt natuerlich.
  2. Jetzt kann man ein neues Dateisystem anlegen: zfs create -o encryption=on <poolname/newfs>
    Das Kommando fragt jetzt interaktiv nach einem Passwort, aus dem der Schluessel fuer das Dateisystem erzeugt wird. Und schon ist es fertig.  Ein Dateisystem nachtraeglich verschluesseln geht nicht.  Natuerlich gibt es weitere Optionen fuer den Schluessel, die in der Manpage beschrieben sind.

Ebenfalls gibt es diverse Wahlmoeglichkeiten bei der Schluessellaenge fuer AES.  Die einfache Variante mit "encryption=on" waehlt AES-128 im CCM Modus.  Alternativ koennen auch 192 oder 256 Bit Schluessel verwendet werden.  Bei der Entwicklung von ZFS crypto wurde diskutiert, welche Schluessellaenge als Default verwendet werden sollte.  Die Wahl fiel aus zwei Gruenden auf 128 Bit:  Erstens ist die Verschluesselung, insbesondere wenn keine Hardware-Beschleunigung wie bei der SPARC T2/T3 oder Intel 5600 CPU vorhanden ist, bei 128 deutlich weniger aufwendig als bei den groesseren Schluessellaengen.  Zweitens gibt es neue Untersuchungen und auch erfolgreiche Angriffe auf AES256 und AES192 mit Aufwaenden von nicht mehr als 2\^39.  Diese Angriffe greifen bei AES128 nicht, weswegen diese Variante nicht nur schneller, sondern auch sicherer ist als die Variante mit groesserer Schluessellaenge.

Weitere Details zu ZFS Crypto gibt es im ZFS Admin Guide.

Freitag Nov 05, 2010

DOAG 2010

Die diesjaehrige DOAG geht auch an mir nicht spurlos vorueber.  Ich werde dort nicht nur zwei Vortraege zum Thema Verschluesselung und neue Hardware halten, sondern auch am Stand der Oracle Hardware fuer Fragen offen sein.  Ich wuerde mich freuen, ein wenig Besuch zu bekommen :-)

Dienstag Sep 21, 2010

Keine Entschuldigung fuer keine Sicherheit

Schon seit der UltraSPARC T2 gibt es eigentlich keine Entschuldigung mehr, einen Web- oder Applicationserver nicht mit sicherem SSL zu betreiben.  Die in die CPU integrierte Crypto-Beschleunigung, die kostenfrei verwendet werden kann, ermoeglicht schon seit Jahren Sicherheit per SSL.  Mit der neuen T3 CPU wurden nicht nur die moeglichen Algorithmen modernisiert.  Auch die Anleitungen, wie dieses Feature zu nutzen ist, wurden auf den neuesten Stand gebracht.  Hier die ersten beiden - mehr kommt vermutlich in Kuerze:


Frohes Verschluesseln!

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.

Mittwoch Aug 19, 2009

ssh und Hardware-Crypto

In Solaris 10 5/09 (aka Update 7) ist ja bekanntlich der Support der ssh fuer hardwarebeschleunigte Verschlusselung enthalten.  Diesen erhaelt man auch, wenn man den entsprechenden Kernel-Patch 139555-08 einspielt - allerdings nur, wenn der dazu gehoerende Treiber-Patch ebenfalls eingespielt wird.  Fuer UltraSPARC T2/T2+ ist das Patch 140386-02, fuer die SCA 6000 Beschleunigerkarte ist der entsprechende Patch im Softwarebundle 1.1 update 2 enthalten.  Spielt man diese Patches nicht ein, koennen keine neuen SSH-Verbindungen aufgebaut werden!  Bestehende Verbindungen bleiben erhalten - dennoch sollte man diese Patches vorsichtshalber ueber die Systemkonsole installieren.  Telnet bleibt natuerlich ebenfalls als zweite Tuer, aber sicher ist das natuerlich nicht.

Montag Jun 29, 2009

Hardware Cryptosupport fuer Websphere

Am Anfang war es nur der Apache, inzwischen unterstuetzen immer mehr Web- und Applicationserver die PKCS#11-Schnittstelle und damit auch die Hardwareunterstuetzung der SSL-Operationen auf UltraSPARC T2 CPUs.  Wie dies mit Websphere richtig konfiguriert wird, ist nun in einem neuen Blueprint kurz, knapp aber anschaulich beschrieben - einschl. einer kleinen Messung der Geschwindigkeitsgewinne.

Freitag Jun 19, 2009

SunSSH unterstuetzt HW-Crypto auf UltraSPARC T2

Die Leistungsfaehigkeit der 8 Crypto-Beschleuniger im UltraSPARC T2 Prozessor ist enorm, leider ist es teilweise immer noch recht aufwendig, sie zu nutzen. Mit dem Update 7 Release fuer Solaris 10 (Solaris 10 5/09) gibt es hier Fortschritte: Aus dem "What's New" (Seite 11) geht hervor, dass die SunSSH, die Sun-Implementierung der SSH mitsamt dem Abkoemmling scp jetzt die Hardware-Beschleunigung unterstuetzt.  Und sie erreicht damit recht gute Werte.  Ein weiterer Grund, einen Upgrade zu machen - und Systeme der T-Serie entsprechend zu konfigurieren.  Jan Pechanec hat die entsprechenden Aenderungen recht ausfuehrlich beschrieben.

Mittwoch Okt 22, 2008

Hardware Crypto Support fuer SSH

Seit es die Cryptoeinheiten der T2 CPUs gibt, wird immer wieder nach Support in SSH/OpenSSH gefragt.  Endlich ist es soweit!  Mein Kollege Jan Pechanec hat die notwendigen Aenderungen in den Code von OpenSSH eingebracht.  Diese sind in Nevada build 99 verfuegbar, an einem Backport fuer Solaris 10 wird derzeit gearbeitet.  Die Details beschreibt Jan in einem Blogeintrag.


Weitere Details zur Cryptoeinheit und wie sie verwendet wird, sammelt Lawrence Spracklen auf einer Seite bei wikis.sun.com.   Diese kann ich nur empfehlen.

Dienstag Apr 15, 2008

Wie schnell sind sie denn, die Crypto-Units?

Ein kleiner Nachtrag zu den Crypto-Units der T2/T2+ CPUs.  Ein Kollege fragte mich, wie man denn am einfachsten demonstriert, was diese Beschleuniger z.B. einem Webserver bringen.  Am einfachsten geht das mit dem Speedtest von OpenSSL:

 Ohne Hardware-Beschleunigung geht das auf einer T5120 so:

# openssl speed rsa1024             
Doing 1024 bit private rsa's for 10s: 407 1024 bit private RSA's in 10.01s
Doing 1024 bit public rsa's for 10s: 6994 1024 bit public RSA's in 9.99s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial) blowfish(ptr)
compiler: information not available
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                  sign    verify    sign/s verify/s
rsa 1024 bits   0.0246s   0.0014s     40.7    700.1

Mit Hardwarebeschleunigung so:

 # openssl speed rsa1024 -engine pkcs11
engine "pkcs11" set.
Doing 1024 bit private rsa's for 10s: 15551 1024 bit private RSA's in 0.60s
Doing 1024 bit public rsa's for 10s: 32649 1024 bit public RSA's in 0.99s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial) blowfish(ptr)
compiler: information not available
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                  sign    verify    sign/s verify/s
rsa 1024 bits   0.0000s   0.0000s  25918.3  32978.8

Im Ueberblick:

  RSA1024 sign/s
 RSA1024 verify/s
 Ohne CryptoUnit
 40700
 Mit CryptoUnit
 25918 32978


 Zu Demozwecken hier natuerlich nur mit einem Thread.  Nicht vergessen: Die CPU hat 8 Cryptounits...

Nachtrag: Natuerlich wird hier nur der Crypto-Beschleuniger gemessen.  In einer Anwendung mit Webserver und ggf. Applicationserver ist dessen Beitrag natuerlich nicht 100% ;-)

Dienstag Mrz 04, 2008

Hardware Crypto


Die UltraSPARC T2 CPU ist mit der derzeit schnellsten Cryptoeinheit ausgestattet, die am Markt verfuegbar ist.  Die Vorteile liegen auf der Hand - Verschluesselung ohne CPU-Belastung und zum Nulltarif bedeutet auch, dass das Gesamtsystem deutlich robuster gegen DOS-Angriffe aller Art ist.  Und Verfuegbarkeit bedeutet Sicherheit.  Verstaendlich und erfreulich, dass das Interesse an diesen Features hoch ist, was wir an den immer haeufigeren Anfragen zu diesem Thema merken. 

Leider ist, was neu ist, nicht immer so einfach wie jahrelang Erprobtes.  Und das eine oder andere Hardware-Feature muss auch seinen Weg durch das Library-Dickicht noch nach oben finden. Deswegen hier ein paar Links auf "Haeufig gegebene Antworten"...

Allgemeine Einfuehrung:
http://www.sun.com/blueprints/0306/819-5782.pdf

IPsec: Benötigt ein “Activation File”:
http://www.sun.com/download/products.xml?id=46d8d2e1

Java: Automatisch ab JDK 1.5
http://www.sun.com/bigadmin/xperts/sessions/22_javasec/

SSH: wird derzeit noch nicht unterstützt,
http://bugs.opensolaris.org/view_bug.do?bug_id=6445288

Apache:
SSL Handshake wird schon seit UltraSPARC T1 unterstuetzt.  Der mit Solaris ausgelieferte Apache 2.0 ist bereits entsprechend vorbereitet.  Ggf. muss “SSLCryptoDevice pkcs11” in der httpd.conf bzw. ssl.conf eingetragen werden. 

Bulk Encryption bswp. mit AES funktioniert derzeit noch nicht, hier gibt es einige offene Bugs:
http://bugs.opensolaris.org/view_bug.do?bug_id=6596364
http://bugs.opensolaris.org/view_bug.do?bug_id=6606361
http://bugs.opensolaris.org/view_bug.do?bug_id=6375348
http://bugs.opensolaris.org/view_bug.do?bug_id=6602801
http://bugs.opensolaris.org/view_bug.do?bug_id=6540060

Teilweise sind die Fixes hierfuer in OpenSolaris bereits implementiert.  Fuer Solaris 10 werden sie mit Update 5 kommen.

Die gleichen Einschraenkungen gelten derzeit auch fuer den Sun Webserver.

Als Workaround kann man in der Zwischenzeit den KSSL-Proxy verwenden, der eine deutliche Leistungssteigerung bei Bulk-Crypto bringt.  Wie das geht, ist ebenfalls in dem o.g. Blueprint beschrieben.

Wir bleiben dran...

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