IT-Security, e-Payment, e-Government, e-Identity

Das Thema ist bei mir irgendwie zur never-ending Story geworden. Letztens hat es ein anderes Niveau angenommen. Der Anforderungskatalog gestaltet sich nun wie folgt:

• Aufwandsarme Windows/Active Directory Integration
• Anmeldung an Konsole, Remote Desktop und VPN
• Linux-Unterstützung für Ubuntu/Debian
• SSL- bzw. TLS-Client-Authentication in Internet Explorer und Firefox (Windows / Linux)
• e-Mail Signatur in Outlook und Thunderbird (Windows / Linux)
• Utimaco Safeguard support (Windows)
• Truecrypt support (Windows / Linux)
• Option für one time password support
• Option für custom code on card
• SSH login z.B. mit Putty, pageant, pscp oder winscp
• zentrales Zertifikatsmanagement

Was die Smartcard-Komponenten wie Karte, Leser, Lesertreiber, PKCS-11/CSP Treiber angeht natürlich am Besten alles top-aktuell und kostensparend.

Bis auf den vorletzten Punkt war alles recht einfach zu erledigen.  Die bisher favorisierten TCOS 2.x/3.x und JCOP Smartcards mussten weichen, da es keinen vernünftigen und aktuellen CSP oder PKCS#11 Support hierfür gibt. Sicherlich gibt es Alternativen mit Arbeitsplatzlizenzen im Wert von zweistelligen Eurobeträgen je Benutzer oder Arbeitsplatz. Das Geld möchte jedoch lieber an anderer Stelle sinnvoller einsetzen.

Unter Windows hatte sich als SSH-Client schon lange putty mit pageant etabliert. Daher kam erstmal PuTTY SC von Pascal Buchbinder auf den Plan. PuTTY SC macht leider eine Annahme, die so nicht immer gegeben ist und in Zukunft wohl noch seltener anzutreffen sein wird. Zwar wird ein “certificate label” gesucht, aber es wird nicht der public key des Zertifikates verwendet. Viel mehr sucht PuttySC einen getrennt abgelegten Public Key mit demselben Label wie das Zertifikat. Andere (ältere) Angaben verlauteten, es müsse der erste public key in der Karte sein. Beides erfordert besondere und vor allem aufwendige Massnahmen im Personalisierungsprozess einer Smartcard. Nach einem erfolgreichen Durchlauf im Juli dann auf Dauer zu umständlich.

Der nächste Versuch ging an PuTTY-CAC von Dan Risacher. “CAC” steht für die United States Department of Defense Common Access Card. Diese wird z.B. benötigt um sich am U.S. Army Knowledge Online Portal anzumelden. Risacher bemerkt ebenfalls die Einschränkungen von PuTTY SC und implementiert einen einfachen Mechanismus den Public Key aus Zertifikaten auszulesen. Allerdings ist die Implementierung in PuTTY-CAC insofern fehlerhaft, da sie ebenso falsche Annahmen voraussetzt. In Folge dessen lief PuTTY-CAC ebenfalls nicht mit unseren Karten. Die Ursache stellte sich bald heraus: die CAC-Modifikation kennt nur 1024 Bit RSA Schlüssel und bricht ab wenn die hartkodierten Stellen andere Werte enthalten. Zu wenig für uns.

Aus diesem Grund habe ich PuTTY-CAC nochmals modifiziert und stelle es hier als PuTTY-VX4 (putty-vx4 binaries) zur Verfügung. Die Schlüsselgrösse sollte nun zwischen 512 Bit und 2048+ Bit (z.B. 4096, 8192, 16384, …) variabel sein dürfen.