Crypto-Hardware unter Sun für OpenVPN

From
Jump to: navigation, search

Vorueberlegungen

Projekt

Ziel des Projektes war es, OpenVPN zur Benutzung der auf Sun Niagra2-CPU's verfuegbaren Crypto-Hardware zu bewegen, in der Hoffnung, mit dieser Hardware einen OpenVPN-Server aufsetzen zu koennen. Mit der, durch hardware-beschleunigte Kryptographie, einhergehenden Entlastung der Integer-Einheiten, wuerde sich dessen Leistungsfaehigkeit/Durchsatz unter Umstaenden deutlich steigern lassen.

Projektumfeld

Hardware

Es stand ein root-Account auf einer Sun T5220 mit installiertem Solaris 10 zur Verfuegung. Die CPU (Sun Niagra2) dieser Maschine hat 8 Cores, wobei jeder Core neben Festkomma- und Fliesskommaeinheiten zusaetzlich eine sogenannte MAU (ModularArithmeticsUnit) und eine SPU (StreamProcessingUnit) mitbringt.


UltraSparc T2

MAU`s implementieren Potenzierung/Multiplikation modulo n in Hardware, und eignen sich daher fuer:

  • RSA, DSA, Diffie-Hellman (Schluessellaengen bis 2048bit)

SPU`s eignen sich hingegen sowohl fuer Block/Stromchiffren, als auch fuer diverse Hash-Algorithmen:

  • DES, AES, RC4 (diverse Schluessellaengen)
  • SHA1, SHA256, MD5

Die beiden Einheiten koennen von Solaris mittels der Treiber 'ncp' und 'n2cp' (NiagraCryptoProvider) angesteuert werden. Zur optimalen Ausnutzung, ist ein LoadBalancer vorangestellt, der versucht die 8 Einheiten gleichmaessig (und fuer die darueberliegenden Anwendungen/Bibliotheken vollkommen transparent) mit Anfragen/Daten zu versorgen.

Software

Die Crypto-Services unter Solaris 10 werden durch das Solaris Cryptographic Framework zur Verfuegung gestellt. Das SCF ermoeglicht es einer Anwendung ('Consumer'), mittels einer einzigen Library (libpkcs11.so), auf die von Bibliotheken ('Provider') implementierten Algorithmen ('Mechanism') zu zugreifen. Neue Algorithmen in Software und/oder z.B. Crypto-Hardware ('Devices') koennen beliebig hinzugefuegt werden. Welche Mechanismen von welchen Providern wirklich durch die Consumer benutzbar sind, kann durch das Konfigurationstool 'cryptoadm' gesteuert werden. Die Bibliothek 'pkcs11_kernel.so' stellt eine Schnittstelle zu den im Kernel verfuegbaren hardware-beschleunigten Algorithmen bereit, (es werden auch Third-Party Provider unterstuetzt, das SCF ist also beliebig erweiterbar) welche damit im User-Level benutzt werden koennen.

Solaris Cryptographic Framework

Demonstration

Benutzte Tools/Programme

kstat

'kstat' liest statistische Daten aus, welche vom Kernel gesammelt werden. Hier interressant sind natuerlich die von den Treibern 'ncp' und 'n2cp' bereitgestellten Daten. Fuer jede MAU/SPU wird von Diesen eine Statistik ueber die Anzahl der ver/entschluessulungen und/oder signs/verifies (seit letztem Boot) gefuehrt. Im Prinzip ist dies auch die einzige Moeglichkeit als Anwender wirklich zu erkennen, ob die Harware-Einheiten ueberhaupt benutzt wurden.

Mit

kstat -n n2cp0

lassen sich z.B. die Daten aller SPU's anzeigen.

Cryptoadm

Mittels 'cryptoadm' kann das SCF administriert werden. Insbesondere koennen crytographische Mechanismen aktiviert/deaktiviert, und neue 'Provider' hinzugefuegt oder entfernt werden. Dadurch koennen also alle 'Consumer' dazu gezwungen werden, z.B. eine DES-Verschluesselung in Hardware auszufuehren.

Anzeige aller verfuegbaren Provider:

cryptoadm list -p

Anzeige aller verfuegbaren Mechanismen:

cryptoadm list -m

'In/Destallation' eines kompletten Providers:

cryptoadm uninstall provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
cryptoadm install provider=/usr/lib/security/\$ISA/pkcs11_kernel.so

Auch einzelne Mechanismen eines Providers koennen (de)aktiviert werden:

cryptoadm disable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so \
mechanism=CKM_SSL3_PRE_MASTER_KEY_GEN

OpenSSL

Mit OpenSSL lassen sich bekanntermassen Daten ver/entschluesseln. Das ganze natuerlich 'nur' in Software, es besteht jedoch die Moeglichkeit, ueber sogenannte 'Engines' auch Hardware-Einheiten zu benutzen. Unter anderem kann unter Solaris die oben beschriebene libpkcs11 als Engine verwendet werden. Diese Funktionalitaet ist essentiell, da OpenVPN auf OpenSSL aufsetzt, und damit in der Lage waere, alle vom SCF bereitgestellen (und von OpenSSL unterstuetzten) Mechanismen zu verwenden.

Anzeige aller unterstuetzten Engines und deren Mechanismen:

openssl engine -c -t

Beispiel fuer letztendliches Verwenden der libpkcs11 (der Parameter kann praktisch bei allen ver/entschluesselnden Aktionen benutzt werden):

openssl speed -engine pkcs11 aes128


OpenVPN

Die unter OpenSSL verfuegbaren Engines koennen auch in OpenVPN benutzt werden (einfacher Kommandozeilenparameter) . Da OpenVPN nur DES, AES und Blowfish benutzt, sollte Hardware-Beschleunigung zumindest fuer DES und AES moeglich sein.

Durchfuehrung

Kompilieren

Da die Version von OpenSSL auf dem Testsystem veraltet war, wurde zuerst eine neue heruntergeladen und kompiliert. Zu diesem Zeitpunkt war 0.9.8i die neueste Ausgabe der Sourcen. Leider ist standardmaessig kein Support der libpkcs11 vorhanden, weshalb dieser nachtraeglich eingepatcht werden muss - ein Patch (README dazu) war damals jedoch nur fuer 0.9.8h vorhanden, weshalb auf also auf letztere Version zurueckgegriffen wurde. Inzwischen existiert auch fuer 0.9.8i ein Patch (README dazu). Mehr und aktuelleres gibt es in Jan Pechanec's weblog.

Jetzt ist libcrypto.so auf dem System vorhanden, und kann von OpenVPN benutzt werden. Auch OpenVPN musste neu kompiliert werden, es wurde das Release 2.1_rc15 verwendet.

Da OpenVPN auf ein TUN-device aufsetzt, musste der dafuer benoetigte Treiber nachtraeglich installiert werden: (link fehlt noch).

Beim Kompilieren kommt es zu Fehlern, das ./configure-Skript erkennt offenbar nicht richtig das es sich bei der Sun um eine 64bit-Maschine handelt. Ein kurzes editieren des Makefile behebt den Fehler jedoch schnell.


Benchmarks (OpenSSL)

AES-256CBC

rest kommt noch