GNOME Keyring: Kann es so einfach sein?

Auf der Suche nach Möglichkeiten, die nötigen Zertifikate unter Linux zentral zu verwalten (anstatt gesondert für jede Applikation) stößt man unweigerlich auf das GNOME-Keyring-Paket, das viele Distributionen von vorneherein mitbringen. Bereits der Name kann dazu verführen, die Möglichkeiten dieses Werkzeugs zu unterschätzen, denn:

- Obwohl eigentlich Teil der GNOME Desktop-Umgebung wird GNOME-Keyring durchaus auch z.B. mit KDE erfolgreich verwendet.

- Anders als der Begriff "Keyring" vielleicht vermuten lässt, verwaltet GNOME-Keyring nicht nur "Keyrings" in der Diktion von PGP/GnuPG, sondern auch X.509-Zertifikate und Benutzer-Passwörter.

Die zentrale Komponente ist der gnome-keyring-daemon, der seine Management-Funktionen über drei verschiedene Komponenten bereitstellt:

- "login" verwaltet Passwörter und Authentizierungs-Informationen und stellt diese über entsprechende libraries anderen Systemkomponenten (z.B: PAM) zur Verfügung,

- "pkcs11" bietet eine Schnittstelle für PKCS#11-fähige Applikationen, die über die libgnome-keyring als "Security Module" eingebunden werden kann. Solcherart erlangt die betreffende Applikation auf einfache Weise Zugriff auf alle vom gnome-keyring-daemon verwalteten Daten.

- "ssh" stellt einen vollwertigen Ersatz für einen anderweitigen SSH-Client (z.B. openssh) dar und lässt sich insbesondere auch mit den entsprechenden Tools verwalten (z.B. ssh-add -s [lib] für die Einbindung von SmartCard-Zertifikaten).

Es existieren verschiedene CLI-Tools, um Zertifikate zentral zu importieren und dem gnome-keyring-daemon zugänglich zu machen, sodass unter Verwendung der libgnome-keyring viele Standard-Applikationen auf einfache Weise mit einem und demselben Zert-Store arbeiten könnten. Ein komfortables GUI dazu gibt es leider noch nicht (bzw. nicht mehr), da der "GNOME Keyring Manager" seit GNOME 2.22 durch das ausschließlich für PGP konzipierte Seahorse-Projekt abgelöst wurde. Erweiterte Management-Funktionen sind zwar seit einiger Zeit in der Roadmap des Projekts, auf den Zeitpunkt der Realisierung darf man allerdings noch gespannt sein.

Ganz reibungslos funktioniert das Interworking zwischen den verschiedenen Komponenten und Applikationen dzt. noch nicht immer, die dbzgl. Test sind jedoch im Gange.

Zertifikats-Management unter Linux

Ein wesentlicher Usability-Aspekt ist aus unserer Sicht das Zertifikats-Management. Gibt es bei Windows bereits einen betriebssystemweiten Certificate Store, so ist dies unter Linux noch nicht so einfach - die Benutzerfreundlichkeit leidet erheblich:

- Mozilla Firefox verwendet die Mozilla "Network Security Services" (NSS) mit einer eigenen Datenbank, in der Zertifikate, digitale IDs und Schnittstellen zu anderen Security Modulen (SmartCards, HW- & SW-Token) hinterlegt sind.

- Mozilla Thunderbird verwendet ebenfalls NSS, speichert diese Informationen jedoch in einer getrennten Datenbankdatei. Die in Firefox importierten Zertifikate stehen somit nicht automatisch auch Thunderbird zur Verfügung - dafür, dass es sich bei den beiden Programmen um zwei Teile einer "Suite" eines und desselben Anbieters handelt, eigentlich sonderbar.

- Epiphany verwendet als Gecko-basierter Browser ebenfalls NSS. Und zwar - man ahnt es schon - wiederum mit einer gesonderten Zert-DB.

- Evolution verwendet sowohl eine typische NSS cert8.db als auch andere (camel-cert.db, key3.db) und bringt seine Zertifikate in einer eigenen Verzeichnisstruktur mit. Die dbzgl. Zusammenhänge werden dzt. genauer untersucht.

- Google Chrome setzt auch auf NSS - abermals gibt es hier eine gesonderte Zert-DB, die jedoch immerhin im Benutzerprofil selbst verankert ist (~/.pki/nssdb/cert9.db). Leider funktioniert unter noch zu untersuchenden Bedingungen bei einzelnen Zertifikaten der Import via GUI hier nicht, sodass er vglw. umständlich über CLI erledigt werden muss ("certutil" et al. aus den NSS3-Tools).

- Opera bringt wiederum eigene Zert-DBs mit, die über das eingebaute GUI administriert werden (opcacert6.dat, opcert6.dat).

- OpenOffice verwendet lt. Dokumentation die NSS-DB von Thunderbird - falls dieser nicht installiert ist, diejenige von Firefox. Entsprechende Tests waren aber noch nicht durchschlagend erfolgreich, die Situation hat sich in den aktuellsten OpenOffice-Versionen evtl. auch geändert - work in progress.

- Adobe Reader setzt stattdessen auf libcurl für die Zert-Verwaltung (und bringt die lib selbst mit, anstatt die systemweit installierte zu verwenden) und besitzt dementsprechend auch seine eigene Zertifikatsdatei (~/.adobe/Acrobat/x.x/Cert/curl-ca-bundle.crt).

Man sieht also: Alleine die Installation der erforderlichen Root- und Intermediate-Zertifikate ist dem Benutzer, sofern er diese synchron in mehreren Applikationen nutzen möchte, eigentlich nicht zuzumuten - zumal die GUIs in der Regel beim Import keine Möglichkeit der Mehrfachauswahl von Zertifikaten bieten. Jedes Zertifikat muss daher einzeln importiert und konfiguriert ("trustargs") werden... alleine für die gängigsten österreichischen Zertifikate sind das also ca. 40 (in Worten: vierzig!) einzelne Importvorgänge, und das gesondert für jede Applikation. Ein zentraler Certificate Store tut unserer Ansicht nach unbedingt not, die dbzgl. Untersuchungen sind im Gange...

erste PKCS#11 Tests mit eCard G3 erfolgreich

Als Proof-of-Concept konnten die ersten Tests mit einer PKCS#11-Bibliothek für die eCard G3 unter Linux (32bit) unternommen werden. Die Funktion konnte mit den gängigsten Web-Browsern und dem E-Mail-Client Evolution verifiziert werden (S/MIME mit dem RSA-Zertifikat der eCard). Die nächsten Schritte unter Linux sind:

- Verifikation mit anderen gängigen Applikationen,

- zentrale Integration in das Zert/Key-Management (gnome-keyring-daemon etc.),

- dieselben Tests unter 64bit.

Weiters soll die grundlegende Funktion auch unter Windows und OS X getestet werden. Bei Erfolg wäre somit eine interessante Schnittstelle von der eCard zu den Standardanwendungen geschaffen, zumindest für die fortgeschrittene Signatur. Die Verwendung des qualifizierten Zertifikats hängt dzt. noch an der Unterstützung durch die Applikationen selbst und wird weiter untersucht.

BKU-Tests weitgehend abgeschlossen

Untersucht wurden:

• A-Trust + a.sign Client
• IT-Solution TrustDesk Pro
• EGIZ Mocca

work in progress: Mocca Probleme unter OS X 10.6.8 debuggen

Herangehensweise der Studie

Scope:
Erörtert werden ausschließlich Lösungen die in aktuellen 64bit OS und Software Releases robust funktionieren, interessierten Laien zumutbar sind, auf absehbare Zeit unterstützt und weiterentwickelt werden, d.h. nach major release Wechsel noch immer funktionieren (OS, Adobe, Browser, MUA-Clients) und auch grundsätzlich Zukunftpotenzial haben.

Fokus: Der Schwerpunkt der Betrachtung liegt auf auf dem generischen Nutzen und Anreizen für Unternehmer und Privatpersonen, nicht auf dem Dialog mit der Hoheitsverwaltung oder Spezialanwendungen für besondere Berufsgruppen (RA, Notare, ZT, SV)!

Historie: Eine historische Aufarbeitung der Designentscheidungen, Weichenstellungen, realen Sachzwänge und fragwürdigen Rechtfertigungsargumente für Fehlentscheidungen technischer und rechtlicher Natur wird nicht angestellt, wir betrachten ausschließlich die Gegenwart und blicken in die antizipierbare Zukunft.