Chipkartenanwendungen und Browser-Integration: Standard gesucht

Da hier in letzter Zeit doch ein gewisses Interesse in Zusammenhang mit dem ComputerBild-Lesegerät und v.a. der beigelegten Karte aufkam, wollte ich nun nochmal etwas allgemeiner auf die Problematik (und bisher verbreiteten Lösungen) der Schnittstelle zwischen Web-Anwendung und Kartenlesegerät eingehen.

Eine Web-Anwendung kann nicht einfach nach Belieben auf die Hardware des Computers zugreifen, was ja grundsätzlich auch erstmal nichts Schlechtes ist; hin und wieder ergibt sich aber doch die Situation, wo dies vom Benutzer gewünscht ist: Bekanntestes Beispiel dürfte hier wohl das Flash-Plugin mit der Bitte um Zugriff auf Kamera und Mikrofon sein.

Für Chipkarten dagegen hat sich noch kein globaler Standard so wirklich durchgesetzt.
Allerdings fehlte es hier bisher auch an Angeboten, die die breite Masse ansprechen; insbesondere lokale Anwendungen mit jeweils beschränktem Nutzerkreis sind geradezu prädestiniert dafür, Insellösungen hervorzubringen.

Eine inzwischen schon relativ verbreitete Anwendung kommt dagegen aus dem Bankensektor:

Mit der SmartLine von fun communications lassen sich die Funktionen der GeldKarte (die zumindest in der kontaktbehafteten Variante ohnehin schon die meisten mit sich herumtragen dürften) über ein Java-Applet online nutzen.

Alternativ ist auch die Nutzung über das SIZCHIP-Plugin der Sparkassen möglich, das allerdings erst (und nur zu diesem Zweck) installiert werden muss, während Java in den meisten Fällen schon vorhanden sein dürfte.

Wer das nun selbst ausprobieren möchte, findet auf der GeldKarte-Seite die Möglichkeit, die im Chip gespeicherten Informationen auszulesen: http://www.geldkarte.de/_www/de/pub/geldkarte/privatnutzer/services/karten_tests.php

Hierzu genügt schon ein Klasse-1-Leser (für kontaktbehaftete Karten, da die meisten GeldKarten bisher nicht kontaktlos sind) – die Transaktion wird dann am Bildschirm über eine virtuelle Tastatur bestätigt. Grundsätzlich wäre es also möglich, eine Transaktion z.B. umzuleiten; bisher hat das scheinbar auch niemanden gestört, erst jetzt mit dem nPA wird der Eindruck erweckt, als seien Klasse-1-Leser ein erst in diesem Zusammenhang entstandenens Problem.
Allerdings speichert die eigene GeldKarte immer auch die ID der jeweiligen Händlerkarte, mit der der Empfänger schließlich seine Umsätze bei seiner Bank einfordert, d.h. es wäre im Zweifelsfall relativ gut nachvollziehbar, wo das Geld gelandet ist.

Beide Varianten sind für den Betreiber kostenpflichtig, und damit für Anwendungen abseits von Zahlungsfunktion oder Altersverifikation für die meisten Websites erstmal weniger interessant.

Eine ebenfalls proprietäre aber für alle Beteiligten kostenlose Methode stellt REINER SCT mit “One Web, one Key” zur Verfügung.
Die Serverkomponente bzw. Spezifikation zur Einbindung in eigene Web-Anwendungen soll in Kürze bereitgestellt werden; vermutlich wird es zukünftig auch möglich sein, eigene Karten nach PKCS#11 für OWOK zu verwenden(?); außerdem soll z.B. auch der neue Personalausweis unterstützt werden.

Voraussetzung für den Nutzer ist hier jedenfalls wieder die Installation des passenden Browser-Plugins.

Nun ist der Gedanke des Logins auf Webseiten ohne Benutzername und Passwort an sich nichts neues, und so hat natürlich auch Microsoft hierzu seit längerem eine Lösung parat:
Windows CardSpace ermöglicht dem Benutzer das Erstellen und Verwalten von virtuellen ‘Karten’, mit denen man sich bei Webseiten anmelden kann, die dies unterstützen. Zusammen mit einigen anderen bekannten Unternehmen wurde die Information Card Foundation gegründet – es handelt sich hier also um einen offenen Standard.

Eine sehr interessante Möglichkeit, sich mit InformationCards einzuloggen, bietet die Seite openidbycard.com, die übrigens von fun communications (s.o.) betrieben wird.
Man kann sich damit auf einer beliebigen OpenID-Website anmelden, indem man einfach openidbycard.com eingibt und anschließend eine (selbst erstellte!) virtuelle Karte zur Identifikation sendet; man ist hier also mehr oder weniger sein eigener OpenID-Provider.

Wer das nun selbst testen möchte, mag vielleicht überrascht sein, als Windows-User (konkret: ab dem .net-Framework 3.0) CardSpace bereits vorinstalliert zu finden, und kann nun einfach mit dem Internet Explorer eine Seite mit OpenID-Unterstützung besuchen und eine persönliche Karte erstellen. Für Firefox gibt es das IdentitySelector-Plugin, das ebenfalls auf die lokale CardSpace-Sammlung zurückgreift (natürlich gibt es auch vollständige Open-Source-Implementationen wie openinfocard oder DigitalMe).

Allerdings handelt es sich hier immernoch um virtuelle Karten, die auf dem PC des Nutzers hinterlegt sind. Ginge man nach der derzeitigen Situation der Berichterstattung in Massenmedien, dürfte dieser wohl schon längst nicht mehr als sicherer Raum einzustufen sein. Aber auch für CardSpace gibt es Möglichkeiten, die Karten des Benutzers mit einer ‘echten’ Karte zu schützen; hier wird sich wiederum noch herausstellen müssen, was für eine das sein wird.

Die von ComputerBild in großer Auflage verbreitete loginCard unterstützt jedenfalls keine asymmetrische Kryptografie, und auch der neue Personalausweis lässt sich ohne BSI-Zertifikat nicht zur Identifikation oder gar Hinterlegung eines Schlüsselpaars nutzen.
Natürlich könnte sich auch jeder selbst eine JCOP- oder andere RSA-Karte kaufen, aber die breite Masse der Internetnutzer erreichen am Ende doch immer proprietäre Komplettlösungen (v.a. wenn für den Nutzer selbst kostenlos).
Vielleicht wird OWOK weitere Verbreitung finden, wenn sich mehr Anbieter für die Ausgabe einer solchen (nicht ‘light’) Karte entscheiden, die sich dann neben der Login-Funktion auch für eigene Anwendungen nutzen lässt.

Nun aber noch kurz zu dem Standard, der am Ende nun auch erst diese ganze Aufmersamkeit in dem Bereich verursacht hat:

Das e-Card-API-Framework vom BSI, das unter anderem den neuen Personalausweis umfasst.
Die Browser-Integration wird in Teil 7 der TR-03112 (Kapitel 2.3.1, ab Seite 12) beschrieben – man ist also grundsätzlich nicht auf die Benutzung einer bestimmten Software angewiesen.
Somit ist also zu erwarten, dass bis zum Aufkommen einer nennenswerten Anzahl von Nutzungsmöglichkeiten der eID-Funktion (sowie der Verbreitung des neuen Ausweises in der Bevölkerung) längst eine Open-Source-Alternative zu dem 800.000 Euro teuren 68-MB-Datenhaufen namens “AusweisApp” zur Verfügung stehen wird.

Eine große Verbreitung ist in diesem Fall langfristig also zu erwarten, leider lässt sich der Ausweis wie bereits erwähnt aber nicht für lokale Anwendungen nutzen.
Und überhaupt ist im Moment noch offen, ob zukünftig wirklich jeder auch zur Investition in einen Standard- oder Komfortleser zur Online-Nutzung bereit wäre.
Vermutlich nicht, aber wahrscheinlich wird das auch gar nicht mehr nötig sein.

Wenn man so die aktuelle Entwicklung in der Mobilfunkbranche betrachtet, stehen wir gerade sehr kurz vor der (praktischen) Einführung von NFC, also im Grunde soetwas wie ein Kontaktloskarten-Lesegerät in jedem Handy – aber auch mit der Möglichkeit der direkten Kommunikation zwischen zwei Geräten.
Uneinigkeit herrschte hier in der Vergangenheit hauptsächlich über die Verwendung von Sicherheitsmodulen – nun scheint aber mit dem ‘Single Wire Protocol’ der Standard für die Integration sicherheitskritischer Anwendungen auf der SIM-Karte gefunden zu sein (die Mobilfunkbetreiber bekommen hier also wieder die Kontrolle darüber, was auf ihre Karten darf und was nicht…).

Bisher hat Nokia angekündigt, sämtliche Geräte der ‘Smartphone’-Kategorie ab 2011 mit NFC auszustatten (das C7 besitzt bereits die Hardware-Funktionalität dafür, welche im nächsten Jahr per Firmware-Update nutzbar werden soll), und auch die Gerüchte um das iPhone 5 mit NFC-Technik tendieren derzeit zum ersten Quartal 2011.

Auch wenn ich persönlich eine gewisse Abneigung gegenüber Apple habe, ist es doch bemerkenswert, welche Macht man inzwischen auf dem Markt hat; mit anderen Worten: Wenn Apple von den Betreibern verlangen würde, SIM-Karten mit Unterstützung für solche Zusatzapplikationen zu verwenden, bliebe diesen wohl kaum etwas anderes übrig, wenn sie das iPhone 5 anbieten wollen (ähnlich der Micro-SIM beim iPad). Wäre also eine Möglichkeit, wir werden sehen ob Apple sie auch nutzt.

Worauf ich aber eigentlich hinauswollte, war die Integration mit Web-Anwendungen. Bisher ist es auch beim Mobilfunk nur über die Installation von Software (Java-MIDlets) möglich, auf die NFC-Funktionen zugreifen zu können.
Es wird sich zeigen, ob sich daran noch etwas ändert, und diese schnelllebige Branche eventuell auch einen offenen Standard hervorbringt, der am Ende sogar in die Desktop-Welt Einzug halten könnte.

Unabhängig davon würde ich jedenfalls auch folgende Kombination für einigermaßen realistisch halten: ein per USB-Kabel am Rechner angeschlossenes Mobiltelefon, das – dank eigenem Display und Tastatur – als Klasse-2 oder -3-Leser zertifiziert sein könnte.
Zumindest erreicht man so sicher eine schnellere Marktdurchdringung als mit dedizierten Kartenterminals, die sonst keinen zusätzlichen Zweck erfüllen, der ihre Anschaffungskosten rechtfertigen würde.

ReinerSCT cyberJack RFID Basis-Leser und ComputerBILD loginCard

Gestern war es endlich soweit: 400.000 vom Staat subventionierte “Basis-Lesegeräte”, die hauptsächlich für die Benutzung mit dem neuen Personalausweis gedacht waren, kamen als Beilage zur aktuellen ComputerBild-DVD-Ausgabe in die Zeitschriftenregale.

//UPDATE: bei heise finden sich einige Interessante Details zu den finanziellen Hintergründen der Aktion.

Und damit nun auch die Antwort auf die Frage: Was steckt drin, um den hypothetischen Preis von € 34,90 zu rechtfertigen?

Hauptsächlich erwähnenswert wäre hier ein NXP PN512, der die eigentliche RF-Schnittstelle zur Karte bereitstellt; die Dinger kosten so um die 3-5$ pro Stück, was wohl den größten Anteil an den Herstellungskosten ausmachen dürfte.
Aber gleichzeitig auch der interessanteste Teil, was eventuelle abweichende Nutzungsmöglichkeiten des Geräts angeht… 🙂

Die Platine ist bemerkenswert kompakt gehalten; neben dem PN512 finden sich noch zwei weitere ICs:
//UPDATE: als USB-Interface dient ein Cypress CY7C64316, weiterhin findet sich ein Spannungswandler von 5V nach 3.3V, dessen Aufdruck offenbar leicht variiert.
Bisher gefunden: “MVAC LEVB” und “MUAB LEVB”
Mehr zur Hardware hier:
http://wiki.steve-m.de/doku.php/epa_basis_reader

Mitgeliefert wurde außerdem jeweils eine “loginCard”, mit der man sich online bei ComputerBild oder anderen bekannten Seiten über “mein-cockpit.de” einloggen kann.

Die Karte basiert auf dem OWOK-Framework von ReinerSCT, das als Standard für die Kommunikation zwischen Browser und Karte gedacht ist. Also am Ende doch wieder nur ein proprietärer Standard, der wohl auch langfrisitg eine Insellösung bleiben wird!? (Was ist denn z.B. mit Windows CardSpace?)

Konkret heißt das also momentan: Ich soll zunächst einmal die Karte selbst über die Seite von ReinerSCT für die Nutzung der “OWOK”-Plattform registrieren, nachdem ich deren Closed-Source Browser-Plugin installiert habe, um anschließend mit der registrierten Karte noch einen Account bei allyve.de erstellen zu können, mit dem ich mich dann über die seite mein-cokpit.de einlogge, wo ich wiederum die Daten all meiner Accounts von diversen anderen Seiten eintragen soll, um mich dann schließlich immer von dort aus einzuloggen?
Ehm, ja. Hättet ihr wohl gern…

Auf der Heft-DVD befinden sich allerdings noch einige Tools, die man scheinbar auch ohne irgendeine Registrierung nutzen kann; dieses “winlogon” werde ich mir als erstes mal genauer ansehen.

Bei der Karte (mit der Beschriftung “OWOK light”) handelt es sich übrigens um eine MIFARE DESFire EV1 2k (MF3 IC D21 wer es genauer wissen möchte), damit hätte ich nun überhaupt nicht gerechnet o_O
Dachte zunächst in Richtung JCOP oder zumindest irgendeine andere RSA-Karte, aber die wären wohl einfach zu teuer gewesen(?); Hauptsache der gemeine ComputerBild-Leser ohne nPA hat schonmal ein bisschen was zum rumspielen, damit er den Leser nicht gleich in die Tonne wirft… 😉

Auf der Karte sind im Auslieferungszustand bereits zwei ApplicationIDs vorinstalliert:
00 83 80
01 83 80

Allerdings enthält noch keine davon irgendwelche Files, mal sehen was sich daran nach Nutzung der winlogin-Software ändert 🙂

Wer sich mit der Struktur von DESfire-Karten genauer befassen möchte, findet hier die Dokumentation der verfügbaren Kommandos:
http://read.pudn.com/downloads165/ebook/753406/M075031_desfire.pdf

Der Vollständigkeit halber hier noch mein log:

;GetVersion (Kartentyp und UID auslesen)
> 60
< AF 04 01 01 01 00 16 05 > AF
< AF 04 01 01 01 03 16 05 > AF
< 00 04 20 3C 82 FE 20 80 BA 14 97 5D 50 28 10 ;die 7 bytes lange eindeutige UID der Karte: 04203C82FE2080, gefolgt von einer Batch-ID und dem Produktionsdatum: KW 28, 2010 ;GetApplicationIDs > 6A
< 00 00 83 80 01 83 80 ;zwei AIDs, je 3 bytes lang ;SelectApplication 008380 > 5A 00 83 80
< 00 ;GetKeySettings > 45
< 00 0B 8E ;Key-Änderung benötigt Application Master Key (=dies ist die OWOK-Applikation!?) ;GetFileIDs > 6F
< 00 ;noch keine Dateien vorhanden ;SelectApplication 018380 > 5A 01 83 80
< 00 ;GetKeySettings > 45
< 00 EB 84 ;Key-Änderung benötigt lediglich den aktuellen Key (=Computerbild-eigene Applikation?!) ;GetFileIDs > 6F
< 00 ;ebenfalls keine Dateien vorhanden

how to remove your birthday from the icq directory


//UPDATE: the method described below does not seem to work anymore.

if someone finds an alternative way, please leave a comment 🙂

All those who have ever tried to hide this little detail from their icq profile (for whatever purpose…) might have noticed that it’s actually impossible to permanently remove it. You can change it on the website, and there is even the option to leave the field blank, however, when you try to update, the current birth date will be preserved.

The fact that the removal of other information submitted through dropdown-fields (e.g. spoken languages) is easily possible, made me have a closer look at the the actual value sent for those input fields for the blank option:

<select name="user_data[year]" class="ubu-1-cmb">
<option value=""></option>
<option value="1995">1995</option><option value="1994">1994</option>
<option value="1993">1993</option><option value="1992">1992</option>
<option ...

It’s just an empty string – the same as for the selection of languages etc. – which makes it seem rather intentional than being just some bug in the backend software… 😀

I tried to send several values like 0, null, -1,… but all with the same effect.

However, if you give a “valid” year that is just a bit out of range (i.e. dates before “The Epoch” or after january, 2038), the server will set the date as unspecified! …yeah! 😀

To do this on your own, just login to the icq website, edit your profile (/full_details_update.php) and save the source code of that page to your disk (rename to .htm !).

Then open with notepad, search for the lines shown above and set the value for the first option (the blank one) to something like 1337 😀 )

<select name="user_data[year]" class="ubu-1-cmb">
<option value="1337"></option>
<option value="1995">1995</option><option value="1994">1994</option>
<option value="1993">1993</option><option value="1992">1992</option>
<option ...

To submit data from your personal copy of the form, complete the “action=”-url for the form, i.e. search for the following lines:

<form action="save_user_details.php" method="post" 
enctype="multipart/form-data" name="user_details" id="user_details">
<input type="hidden" name="uin" value="...

and replace with the full path:

<form action="http://people.icq.com/people/save_user_details.php" method="post"
enctype="multipart/form-data" name="user_details" id="user_details">

…now save changes, open the local .htm-file, and set the value for the year to the blank one.

For whatever reason, the javascript-initiated submit does not work locally, so feel free to either add your own submit button, or just click one of those text input fields to set the focus, and press enter – that should actually do it! 🙂