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

Der Anwendungstest des neuen Personalausweis ist mit Beginn des Jahres gestartet worden. 30 Unternehmen entwickeln prototypische Anwendungsfälle mit dem Ausweis und testen die Infrastruktur auf Herz und Nieren.

Pünktlich zum Start haben Dr. Marc Fischlin von der TU Darmstadt und Dr. Jens Bender sowie Dr. Dennis Kügler, beide Referenten beim BSI, ein Papier über die Sicherheit des PACE (Password Authenticated Connection Establishment) Protokolls veröffentlicht. Landläufig herrscht der Irrglaube, der Ausweis liesse sich “einfach so” auslesen. In der Tat bedarf es zum Auslesen jedoch entweder der e-ID PIN, der sogenannten Card Access Number (CAN) von der Vorderseite der Karte oder dem Hash der Machine Readable Zone (MRZ) von der Rückseite. Die Berechtigungen sind dabei dem Verwendungszweck der jeweiligen Zugangsnummer entsprechend unterschiedlich. So kommt die MRZ z.B. an Durchzugsausweislesegeräten, wie sie an Flughäfen zu finden sind, zum Einsatz und soll lediglich eine schnelle und sichere Identifikation des Reisenden ermöglichen. Die CAN hingegen dient der Freigabe allgemeiner Informationen auf einem RFID Lesegerät zu Hause oder im Amt und zum sicheren Verbindungsaufbau zur Signaturanwendung, während die e-ID PIN zur Authentisierung des Ausweisinhabers (Besitz und Wissen) eingesetzt wird. Siehe auch Kapitel 3.3 BMI TR-03127.

Das PACE Protokoll ermöglicht die Authentisierung und den sicheren Verbindungsaufbau mit Hilfe der vorgenannten Zugangsinformationen. Daher liegt in dem Protokoll der neuralgische Punkt wenn es um die Sicherheit vor dem unbefugtem Auslesen des Personalausweises geht.

Mehr zum Thema wurde bereits 2008 z.B. hier veröffentlicht. Weitere Informationen z.B. zu den neuen Ausweisen der anderen EU Länder findet der interessierte Leser bei der European Network and Information Security Agency.

In den letzten Wochen und speziell auf der Messe „Moderner Staat“ am 24. und 25.11. in Berlin wurden die Themen DE-Mail und Post-Onlinebrief ausführlich und kontrovers diskutiert. Beide Seiten bemühten sich redlich aber vergebens darum, sich nicht als Konkurrenz zum anderen und den anderen nicht als Konkurrenz ihrer selbst zu sehen. Dabei ist der Ausgangspunkt hinter den Konzepten natürlich identisch: sichere, vertrauliche und verbindliche Email-Kommunikation, sicher und vertraulich im Sinne der lückenlosen Verschlüsselung der Übertragung und verbindlich durch die feststehenden Identitäten von Absender und Empfänger, was zusätzlich dazu auch Spam und Phishing verhindert. Mit einer solchen Email-Infrastruktur soll und kann das händisch unterschriebene Dokument in sehr vielen Anwendungsfällen durch eine E-Mail ersetzt werden. In punkto Authentisierung bieten beiden Konzepte zwei Sicherheitsniveaus, die „normalen“ Authentisierung mit Nutzername und Passwort und die „hohe“ Authentisierung nach dem Prinzip „Besitz und Wissen“, das zusätzlich zu Nutzername und Passwort z.B. durch eine mTAN oder auch ab Herbst 2010 mit dem elektronischen Personalausweis abgesichert wird.

Doch während BMI und BSI mit einer Vielzahl von Partnern aufwendig spezifizierten, wie De-Mail funktionieren soll, wie die Akkreditierung von Dienstanbietern erfolgt, wie die Kommunikation zwischen De-Mail-Nutzer und Dienstanbieter und auch zwischen den Dienstanbietern technisch abgesichert wird, hat die Post erkannt, dass ein Dienst wie De-Mail eine massive Bedrohung für das Kerngeschäft der Post, den Briefversand, darstellt. Die notwendige Schlussfolgerung daraus war die Erstellung eines eigenen Dienstes für sichere, vertrauliche und verbindliche Email-Kommunikation. Und da die Post mit Post-Ident sogar ein eigenes Verfahren zur persönlichen Identifikation von Personen hat, stand dem Dienst Onlinebrief (Arbeitstitel für das Projekt) nichts im Weg.

Die Spezifikation des Onlinebriefs fiel der Post natürlich um einiges leichter als dem De-Mail-Konsortium, da sie hier freie Hand hatte und sich nur mit potentiellen Anwendern und Kunden über deren Anforderungen unterhalten musste.

Und genau an diesem Punkt überholt der Onlinebrief die De-Mail, denn es wird von vorne herein auf zusätzlichen Mehrwert bei der Anwendung gesetzt, und den kann die Post durch die Verknüpfung des Onlinebriefs mit der physischen Briefpost in den folgenden Features reichlich bieten:

• Der Onlinebrief kann auch an Personen gesendet werden, die keine Onlinebrief-eMail haben. In diesem Fall druckt die Post die E-Mail aus und sendet sie als klassischen Brief an den Empfänger.
• Den Unternehmen und Behörden bietet die Post eine „elektronische Poststelle“, die z.B. im einfachsten Fall den Printdatenstrom abgreift, die Anschrift aus einem Schreiben erkennt, die Onlinebrief-eMail dieser Peron ermittelt, und das Dokument dann per Onlinebrief zustellt. Wird für eine Person keine Onlinebrief-eMail gefunden, wird das Schreiben von der Post ausgedruckt und als klassischer Brief zugestellt.
• Ein zentrales Onlinebrief-Adressbuch ermöglicht die Suche nach Behörden, Unternehmen und bietet die Verlinkung auf deren Onlineservices, die den Onlinebrief benutzen, z.B. die Anmeldung eines Kfz.
• Für die Anbindung solcher Dienste an den Onlinebrief stehen konkrete Schnittstellen zur Verfügung.
• Um die Integrierbarkeit zu erhöhen und zu vereinfachen, startet die Post die Onlinebrief zunächst nur über ein Onlinebrief-Webportal, d.h. die Nutzung von anderen Email-Clients ist nicht möglich.

Solche zusätzlichen Mehrwerte stehen bei der Konzeption der De-Mail nicht im Vordergrund. Die Ideen für Mehrwerte der De-Mail will man hier den Unternehmen und Institutionen überlassen, die De-Mail nutzen möchten.

Damit hat sich die Post mit dem Onlinebrief klare Vorteile gegenüber der De-Mail erarbeitet und wird diese Vorteile auch zu nutzen wissen. Der Anreiz für die Post ist groß, denn (das Beste kommt zum Schluss) der Service Onlinebrief wird nicht kostenlos sein, sondern es wird vermutlich, es gibt hier noch keine offizielle Festlegung, eine Transaktionsgebühr, d.h. einen Zahlbetrag pro Onlinebrief geben, der nach Aussagen der Post „deutlich unter dem Briefporto“ liegen wird, aber egal wo dieser Preis sich am Ende festmacht, der Emailversand per Onlinebrief wird ein Riesengeschäft für die Post werden.

Interessant wird es im Frühjahr 2010, denn dann wird eine umfangreiche Marketingkampagne für den Onlinebrief gestartet, und danach wird sich zeigen, wie sich der Onlinebrief der Post und die De-Mail im Markt behaupten.

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.

Für die Einen der Hoffnungsträger schlechthin für sicherere und effizientere Geschäftsprozesse, insbesondere im Internet. Für die Anderen eine Horrorvision.

Am 16.11.2009 vermeldeten Heise und Golem die offizielle Bestätigung, dass Siemens und OpenLimit die Infrastruktur bzw. die Middle-Ware (Bürgerclient, von uns auch Bürgerware genannt) für den ePA liefern werden. Die SIS (Siemens IT Solutions and Services) hat als Generalunternehmer die Hauptverantwortung und ihrerseits die OpenLimit SignCubes GmbH mit der Herstellung der Endanwender-Software beauftragt.

In den Foren der beiden oben genannten News-Seiten sorgte dies leider für viele polemische Kommentare weitab von Sachlichkeit. Was ist nun eigentlich dran am ePA?

Beginnen wir doch bei einigen Mythen die nun in den letzten Monaten entstanden sind.

1.  ”Der ePA soll als ‘Internet-Ausweis’ jeden Bürger eindeutig im Netz identifizieren”.

Wir reden hier nicht über ein “soll”, sondern über ein “kann”. Es bietet sich die Möglichkeit Geschäfts- und Verwaltungsprozesse für den Bürger und die Anbieter/Ämter zu vereinfachen. Dabei können Vertragsschlüsse (Direktbanken, Direktversicherungen, grössere Online-Einkäufe auf Rechnung, …) oder Anträge (Hundemarke, KFZ-Kennzeichen, Wohngeld, etc.pp.) quasi 24/7 von der Wohnzimmercouch aus erledigt werden. Der Bürger muss diese Dienste nicht nutzen, aber er/sie darf es.

Als zusätzliches Merkmal verfügt der ePA über einen “Restricted Identifier” (sektorspezifische Kennung). Diese ID ist als Pseudonym zu verstehen und hat ihren Ursprung in internationalen Standards. Sie dient der Identifikation des Benutzers im Single-Sign-On Gedanken. Ein einmal einem Benutzerkonto hinzugefügter Personalausweis kann so zukünftig durch den Benutzer als sichere Login-Methode verwendet werden.  ”Sektorspezifisch” heisst hierbei, dass die resultierende ID je “Sektor” zwar eindeutig über mehrere Sektoren hinweg jedoch nicht mehr zuordenbar ist. Der Sinn dahinter ist es genau keine weitgreifenden Datenspuren zu legen.

2.  “Alle Angaben des Benutzers sind unkontrolliert verfügbar.”

Bis der ePA überhaupt etwas preisgibt ist es ein langer Weg. Kurz gefasst antwortet der ePA erst dann wenn während der aktuellen Verbindung ein gültiges Berechtigungszertifikat präsentiert wurde. Dieses Zertifikat weist den Anfragenden nicht nur als akkreditiert aus, sondern sagt auch aus auf welche Fragen der ePA antworten darf. Fragen sind hierbei z.B. “Vorname?”, “Nachname?”, “Land?”, “Bist Du über 18?”, uvam. Es kann nicht automatisch jeder jede Information abrufen. Und wie man sehr deutlich sieht ist insbesondere für die Altersverifikation ein Mechanismus implementiert, der lediglich noch die Frage beantwortet ob jemand z.B. voll Geschäftsfähig ist oder nicht – das genaue Geburtsdatum erfährt der Anfragende nicht. Weiterhin ist es vorgeschrieben, dass der Bürgerclient in einem Fenster den Nutzer um Bestätigung bittet welche Daten dieser für den Anfragenden freigeben möchte. Dabei kann der Nutzer beliebig Elemente abwählen (z.B. kein Nachname, kein Land).

 3. “Bürgerclient == Bundestrojaner”

Sicherlich ist die Sorge berechtigt, dass sich in der Software früher oder später auch Trojaner (eigentlich sind es ja Griechen) untergebracht finden. Jedoch würde so ein Fall genauso früher oder später bekannt werden und zum maximalen Image-Schaden für die Verantwortlichen in den Behörden wie auch in der Wirtschaft werden. Dabei würde jede Menge verbrannte Erde entstehen, die die EU für ihre zukünftigen ID-Projekte absolut nicht gebrauchen kann. Damit aber auch kein Wildwuchs und daraus resultierende Probleme entstehen gibts es eine Reihe Technischer Richtlinien vom BMI (nein, das Kürzel TR steht nicht für TRojaner und auch nicht für Türkei), welche genau vorschreiben wie der ePA (BMI TR-03130) aber auch der Client (BMI TR-03112) auszusehen und zu funktionieren haben. Um Spekulationen gleich vorzubeugen sei gesagt, dass die Verwendung eines Clients nach BMI TR-03112 durch das Gesetz über Personalausweise (PAuswG) in §27 (3) vorgeschrieben ist.

4. “Der ePA dient als Vorwand von allen Bürgern biometrische Daten zu erfassen”

Diese Aussage ist ebenfalls nicht wahr. Schon immer wird zu einem Personalausweis die Augenfarbe, die Körpergrösse und ein Lichtbild (aka Foto) erfasst. Das Lichtbild ist nun zwar ein ”biometrisches Bild”, um eine maschinelle Wiedererkennung zu vereinfachen aber sonst ändert sich an der Menge der erfassten Daten nichts. Um das biometrische Bild ranken sich schon seit dem neuen Reisepass diverse Gerüchte bezüglich der damit entstehenden Fahndungsmöglichkeiten. Trotz aller Spekulation um die rechentechnischen Möglichkeiten von Regierungsbehörden, insbesondere einige Jahre in der Zukunft, ist die Gesamtmenge des -im Zweifelsfall- zu verifizierenden Materials enorm gross. Unterstellt man diesen Institutionen die “schlechteste” Motivation aus Sicht der Kritiker, so werden diese lediglich einen bereits vorhandenen Anfangsverdacht bestätigen können. Die Erfassung von Fingerabdrücken ist überdies optional und erfolgt vor Ort in einer Ausweisstelle. Die Fingerabdrücke werden erfasst, auf den Chip gebracht und anschliessend gelöscht. Eine zentrale Speicherung findet nicht statt. Die Fingerabdrücke sind nur durch hoheitliche Institutionen zwecks Identifikation aus dem ePA abrufbar.

Die Techies interessiert ggf. dass das RFID Protokoll ISO-14443-B ist und die Kommando-Kommunikation entsprechend ISO 7816 und der eCard-API Sepzifikation erfolgt. Prinzipiell ist es also auch für Andere möglich passende Middleware zu entwickeln. Es bleibt abzuwarten wie hier in Zukunft die EU-weiten Reglementationen aussehen werden.

Zum ebenfalls angekündigten Anwendungstest des ePA stellt das Kompetenzzentrum Elekronischer Personalausweis weitere Informationen bereit. 

Wesentlich interessanter, aber in Öffentlichkeit bisher nahezu völlig unbeachtet, sind die Änderungen am Gesetz über Personalausweise. BMI TR-03127 verweist in Kapitel 6.5 “Verantwortung des Ausweisinhabers” explizit darauf, dass der ePA nicht mehr als “Pfand” hinterlegt oder anderweitig (z.B. zum Zigaretten kaufen ausleihen) aus der Hand gegeben werden darf (PAuswG §1 (1)). Weiterhin bei Verlust nach PAuswG §27 (1) umgehend sperren zu lassen ist oder bei Kompromittierung der eID-PIN diese unverzüglich zu ändern, oder die Anwendung abschalten zu lassen (PAuswG §27 (2)).

Online nachzulesen sind die aktuellen Änderungen des PAuswG vom Sommer z.B. hier: http://www.buzer.de/gesetz/8807/index.htm,  http://www.buzer.de/gesetz/8806/index.htm.

Auf jeden Fall wird die weitere Entwicklung des ePA sehr spannend. Soweit es mir möglich ist werde ich an dieser Stelle weiterhin berichten und versuchen mit Fakten auch Klarheit zu schaffen. Es bleiben noch eine ganze Menge Details offen, die ich hier und jetzt nicht anschneiden konnte und auch in Zukunft folgen. Von Anfragen zu Details die über das, was ich hier freiwillig schreibe, hinausgehen bitte ich abzusehen, da auch ich teilweise unter NDA (Verschwiegenheitserklärung) stehe und schlichtweg nicht berechtigt bin zu einigen Punkten Stellung zu beziehen. Viele sollten mich jedoch gut genug kennen, dass ich mir nicht die Mühe machen würde den ePA in ein richtigeres Licht zu rücken wenn es unsauber wäre.

Hinterhergeschickt sei auch noch, dass ich die Vorläuferabteilung der SIS, die SBS, im Zusammenhang mit der Implementierung von Signaturgesetzkonformen Projekten nun seit über 8 Jahren kenne. Die SIS hat definitiv wesentlich mehr Erfahrung im Umgang mit solchen Systemen und ihren Implikationen als die Meisten, die mit Kommentaren mit Siemens-Witzen auf sich aufmerksam machen wollen.

Während einer Unterhaltung mit einer Kollegin kamen wir auf eine alte Aussage von Wau Holland über mich zu sprechen. Wau hatte sich anlässlich des 17. Chaos Communication Congress (17C3) eine “Wau-verkürzte” Zusammenfassung über meine Person ausgedacht.

Bei der Suche nach Quellen fiel dann folgendes etwas unangenehm auf:

Hier das Original des Congress Fahrplans aus dem Jahr 2000.  Von dort aus wird auch auf die Aussage von Wau verlinkt.

Der CCC hingegen hat im Wesentlichen denselben Inhalt in “bereinigter Form” auf seinem Webserver. Selbst mein Speaker-Profil wurde offensichtlich systematisch getilgt. Da es keinen erkenntlichen Grund gibt warum dies geschah finde ich das Vorgehen sehr frech. Insbesondere in Anbetracht der laufenden Relevanz-/Lösch-Diskussionen mit Wikipedia Deutschland erscheint solches Zensurverhalten sehr eigenartig, um nicht zu sagen bigott. So etwas stellt schlichtweg eine Prinzipfrage dar.

Ist etwa auch in den Riegen des CCC Zensur und Egomanie am Werk?

UPDATE: Es gab in kurzer Zeit eine ganze Reihe sehr konstruktiver Reaktionen seitens des CCC. Sehr zügig wurden Anstrengungen unternommen den Effekt zu klären und die Ursachen zu finden. Demnach handelt es sich um eine Inkonsistenz im Rahmen einer Migration bei dem mehrere Vorträge und Referenten betroffen waren. Ich bin beruhigt, dass es sich um ein Versehen handelt und der CCC professionell reagiert. Die Entschuldigung ist natürlich angenommen. Danke für euer schnelles Feedback.

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

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.

Nun ist es endlich soweit. Ein neues Blog ist eröffnet!

Wie der Titel schon sagt wollen wir uns hier im Kern mit den Themen der IT-Sicherheit auseinander setzen. Besondere Aufmerksamkeit erhalten dabei die Bereiche e-Payment, e-Government und e-Identity. Als Initiator dieses Blogs freue ich mich auf viele spannende Themen, Diskussionen und Beiträge von meinen Kollegen. Gemäss unserem Untertitel, welcher auf einer getrennten Seite genauer erläutert wird, möchten wir versuchen komplexe Themen verständlich aufzubereiten.