Archive for the ‘IT-Security’ Category.

Sichere Authentisierung mit SSH, SSL/TLS, S/MIME und Smartcard

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.

Gemalto .NETsolutions – was war geschehen?

Ende Februar informierten wir den Smartcard-Hersteller Gemalto über ein Problem mit der anfänglich “Cryptoflex.NET”  genannten Smartcard in dessen Entwicklerforum. Der Hersteller hat sehr schnell reagiert und Kontakt via e-Mail aufgenommen, anschliessend folgten auch einige Telefonate mit Kollegen am Development Stammsitz in Austin, Texas.

Das Problem war wenige Wochen später gefixt und grosse Kunden wie z.B. Microsoft wurden geupdated. Inzwischen existiert seit einigen Monaten die Nachfolgegeneration der Karten. Wir bekamen zur Bestätigung des erfolgreichen Bugfixes eine Reihe Samples und können nun sagen die Gemalto .NET v2 selber auf Herz und Nieren getestet zu haben. Immerhin handelt es sich um einen der schlimmsten Ernstfälle Smartcards beiläufig so zu töten, dass wirklich gar nichts mehr geht:

Gamebay Advanced SP with Towitoko Chipdrive and Gemalto .NET Smartcard

Gamebay Advanced SP with Towitoko Chipdrive and Gemalto .NET Smartcard

 

Auslöser für das Problem war ein eigentlich sehr intelligenter Mechanismus. Um die ausserordentliche Leistungsfähigkeit der Karte nicht durch in die Jahre gekommene ISO-Protokolle zu beschränken, erfand man ein Tunnel-Protokoll welches durch den Entwickler mit dem aus der Server-Welt bekannten .NET-Remoting bedient werden kann. Ähnlich wie es in Betriebssystemen Bugs in den TCP/IP Stacks geben kann stiessen wir auf einen Fehler in der Packet-Verarbeitung des Protokoll-Stacks der zu Buffer Overflow Attacken einlud. Wir teilten Gemalto eine präzise Analyse des Fehlers und mögliche Behebungswege mit, so dass der Bug im Interesse aller zeitnah behoben werden konnte.