ADMIN Magazin Gestapelt - Schneller und sicherer mit RAID (Vorschau)

Login
Admin-Story
© schiffner, Photocase
Wegweiser duch Crypto-Bibliotheken und ‐Services
Im Dickicht
Der Einsatz von Crypto-Bibliotheken kann manchmal etwas umständlich
sein. Dass hiervon gleich eine ganze Handvoll existieren, erleichert die
Sache nicht unbedingt. Der folgende Artikel versucht, ein wenig Licht ins
Dunkel zu bringen und erklärt den Einsatz der Network Security Services
(NSS) und OpenSSL im Zusammenhang mit X.509-Zertifikaten. Thorsten Scherf
Linux lässt einem bei nahezu allem die
Wahl zwischen einer Vielzahl von Alternativen,
warum sollte dies also bei
Crypto-Frameworks anders sein? Auf
proprietären Systemen hat man sich
meistens auf ein bestimmtes Framework
festgelegt (beispielsweise die CryptoAPI
bei Microsoft Windows) und passt die
Standard-Applikationen daraufhin an, bei
Linux existieren neben den bekannten
OpenSSL und den Network Security Services
auch noch BeeCrypt, Cyrus SASL,
libgcrypt, GnuTLS und diverse andere
Implementierungen.
Große Auswahl
Dabei versuchen nahezu alle Frameworks
das gleiche Problem zu lösen oder
ähnliche Lösungen für bestimmte Anwendungsfälle
anzubieten, also beispielsweise
eine Implementierung für das TLS/​
SSL-Protokoll, für S/​MIME, für Crypto-
Algorithmen und Hash-Funktionen, Zufallszahlen-Generatoren
und Ähnliches.
Hier den Überblick zu behalten, ist nicht
wirklich einfach. Zumal es dem Entwickler
einer Anwendung natürlich freigestellt
ist, welches Crypto-Framework
er für seine Applikation verwendet. Ob
die Auswahl des Frameworks auf dem
System, auf dem die Anwendung einmal
laufen wird, zu Problemen führt, ist nicht
wirklich sichergestellt.
Ein kleines Beispiel: Die Anwendung
nutzt die Network Security Services und
erwartet Benutzerzertifikate in einem
Berkley-DB basierten Zertifikatsspeicher.
Der Benutzer hat sein X.509-Zertifikat
aber als PEM-codierte Datei auf dem
Dateisystem liegen und weiß nichts von
einer Berkley-DB. Hier ist erst einmal etwas
Handarbeit gefragt, bevor schließlich
das Benutzerzertifikat als PKCS#12
Datei in die Berkely-DB geschoben werden
kann. Das Fedora-Projekt hat sich
vor einiger Zeit zum Ziel gesetzt, diesen
Wildwuchs etwas einzudämmen und ein
Crypto-Framework gesucht, das einen
breiten Funktionsumfang, hohe Portabilität
und ein flexibles Lizenzierungsmodell
bietet. Betrachtet man die Anforderungen,
so kommen hierfür eigentlich
nur OpenSSL und die Network Security
Services (NSS) infrage.
OpenSSL ist in der OpenSource-Community
sehr gut bekannt und hat die erste
OpenSource-Implementierung für SSL zur
Verfügung gestellt, hat einen hohen Verbreitungsgrad
auf Unix-artigen Systemen
und verwendet ein duales Lizenzierungsmodell
– es kommen die BSD-artigen Lizenzen
SSLeay und OpenSSL zum Einsatz.
NSS ist das ältere Framework und hat von
Haus aus einen höheren Funktionsumfang
als OpenSSL. Der Zertifikatsspeicher
besteht aus einer Berkeley-Datenbank,
anders als bei OpenSSL, wo Zertifikate
in regulären Dateien abgelegt sind. NSS
verwendet ein dreistufiges Lizenzierungsmodell,
bestehend aus der Mozilla, der
GNU General und der GNU Lesser General
Public License.
OpenSSL oder NSS
Heute setzt der Großteil der Fedora-Applikationen
NSS als Crypto-Framework
ein, andere Anwendungen benutzen
OpenSSL oder lassen dem Benutzer die
Wahl zwischen dem einen oder dem
anderen Framework. Ein gutes Beispiel
hierfür ist der bekannte Webserver
Apache. TLS/​SSL-Support stellt dieser
seit jeher über das Modul »mod_ssl« zur
Verfügung. Vor einiger Zeit bereits wurde
daneben das Modul »mod_nss« für den
Einsatz der Network Security Services
entwickelt. Dem Admin steht es frei, das
eine oder das andere Modul einzusetzen.
Ähnlich ist es auch auf der Client-
Seite. OpenLDAP kann beispielsweise mit
18 Ausgabe 06-2012 Admin www.admin-magazin.de