Archiv für die Kategorie » Wirtschaft «

“Bürgerclient” für den ePerso

Montag, 16. November 2009, 16:32 Uhr | Autor: ich

Siemens und Openlimit entwickeln Bürgerclient – Anwendungssoftware für den elektronischen Personalausweis” (golem.de)

Siemens wird zusammen mit Openlimit den sogenannten Bürgerclient für den elektronischen Personalausweis entwickeln. Den entsprechenden Auftrag vergab das Bundesinnenministerium jetzt an Siemens IT Solutions and Services, Openlimit und die Bundesdruckerei.

Dieser “Bürgerclient” ist die Software, die auf dem Computer des Bürgers installiert sein muss, die dann die Kommunikation zwischen dem Kartenlesegerät und dem eID-Server herstellt. Es ist eine der Komponenten der ich vertrauen muss, dass sie mit meinen Daten keinen Mist baut.

Die eigentliche Bürgerclient-Software soll Openlimit entwickeln.

Adhoc-Mitteilung: OpenLimit realisiert den Bürger-Client” (openlimit.com)

OpenLimit XSS
Ok, dies ist nur mal wieder etwas Cross-Site Scripting, was wohl an dem CMS bzw. der Form-Erweiterung liegt, aber trotzdem schwindet mein Vertrauen, wenn so etwas sehe.

Wer an solch sensiblen Projekten arbeitet, der muss ganz besonders darauf achten, dass nicht der Hauch von Misstrauen auftaucht. Da ich nun annehmen muss, dass diese Firma Software aus fremden Quellen ungeprüft verwendet, stellen sich mir verschiedene Fragen:

  • Wird im “Bürgerclient” auch Fremdsoftware zum Einsatz kommen?
    • Ist dies Open Source, damit man prüfen kann was sie mit den Daten anstellt?
    • Wenn es kein Open Source ist, wie wird dann geprüft, um unerwünschte Funktionen darin aufzuspüren?
  • Wer bekommt die Möglichkeit in den Quellcode zu schauen, um zu prüfen, was der “Bürgerclient” mit den Daten anstellt?



Da die Verteilung über die Einwohnermeldeämter und deren Websites erfolgen soll, frage ich mich, wie man dort verhindern will, dass keine manipulierten Versionen unter das Volk gebracht werden?

Im letzten Jahr schrieb ich in “Meldedaten leck(t)en ins Netz” über diese Ämter, weshalb die Frage nicht ganz unberechtigt ist. Mehr als ein Jahr ist in der IT eine halbe Ewigkeit, in der sich viel ändern kann, aber bei den Ämtern?

Am Arbeitslosenamt sah man in den letzten Wochen ja wie man dort tickt:
Bewerber und Betrüger” (sueddeutsche.de)

Jeder, der sich als Arbeitgeber ausgibt, kommt über die Jobbörse der Arbeitsagentur an sensible Bewerberdaten.

Man wollte erst nichts an der bisherigen Praxis ändern:

“Im Hinblick auf die Engpässe am Arbeitsmarkt wollte die BA eine Erhöhung der Einstiegsbarrieren für die Jobbörse vermeiden”, heißt es in einer Stellungnahme.

Erst nach dem “Missbrauch der Jobbörse der Arbeitsagentur” (faz.net) wollte man handeln:

Die Bundesagentur reagierte auf diesen und ähnliche Vorfälle und verschärft die Zulassungsbedingungen für Arbeitgeber, wie BA-Vorstandsmitglied Raimund Becker gegenüber der F.A.Z. sagte

Und hier “Datenschutzmängel bei neuem Computersystem der Arbeitsagentur” (heise.de) wurde über die Datenbank geschrieben, über die jeder der beim Arbeitslosenamt angestellt ist, auf die Datensätze aller Arbeitslosen zugreifen kann.

Und wenn ich dann auf Golem noch

Unternehmen und Institutionen müssen sich ebenfalls authentifizieren, um auf die Daten der Bürger zugreifen zu dürfen.

lese, so wird mir ganz schlecht. Beim Arbeitslosenamt hat es bisher ausgereicht sich als Arbeitgeber auszugeben, um an die Daten der Arbeitssuchenden zu kommen und bei den Meldeämtern reicht es noch immer aus, wenn man ein paar Euro bezahlt, um an Meldedaten der Bürger zu gelangen, sofern diese der Weitergabe nicht explizit widersprochen haben.

Da werden wir wohl die ersten Missbrauchsfälle abwarten müssen, bis man sich mit großer Vorsicht dem ePerso und dem “Bürgerclient” nähern kann.


Nach wie vor glaube ich nicht, dass die Verantwortlichen in Politik, Wirtschaft und Verwaltung schon reif genug sind, um Projekte solcher Tragweite, unter das Volk zu bringen.

Thema: Politik, Sicherheit, Wirtschaft, XSS | Ein Kommentar

Wie Zertifizierer mit Sicherheitslücken ihrer Kunden umgehen sollten

Donnerstag, 5. November 2009, 15:08 Uhr | Autor: ich

Vor einigen Monaten hatte ich einen Termin bei einem Unternehmen welches auch Zertifikate für Webshops ausstellt. Damals fragte ich den Geschäftsführer ob die zertifizierten Firmen Änderungen an ihren Seiten melden würden, damit eine erneute Prüfung durchgeführt werden kann, um den Status der Zertifizierung aufrechtzuerhalten. Er sagte, dies würde keine Firma machen, da jede Prüfung natürlich auch bezahlt werden muss. Ab und zu würde man zwar Hinweise zu Änderungen bekommen und auch nachprüfen, aber in der Regel warten die Unternehmen bis sie wieder zur jährlichen Prüfung antreten müssen. Es gäbe auch Firmen die diesen Termin schon fest in ihrer Planung für die Website verinnerlicht hätten und diesen geradezu herbeisehnen, damit sie wieder auf der sichereren Seite stehen. Ich fragte noch einmal nach, ob ich dies richtig verstehen würde, denn schließlich würde seine Firma ihren guten Namen 364 Tage im Jahr für etwas hergeben, worauf sie keinen Einfluss hat. Ja, ich hatte richtig verstanden.

Die Problematik bei solchen jährlichen Prüfungen liegt auf der Hand. Die zertifizierte Website besitzt zu dem geprüften Termin den, zu dem Zeitpunkt, korrekten Status einer zertifizierten Seite, aber bei der nächsten Änderung an den Seiten kann sofort eine Sicherheitslücke aufgerissen werden, die diesen Status augenblicklich aufhebt.


Eine Änderung die zu neuen Lücken führt, kann vielfältiger Natur sein.

Ein Update der verwendeten Software könnte zwar den eigentlichen Zweck haben, dass bekannte Sicherheitslücken geschlossen werden sollen, aber gleichzeitig tun sich u.U. neue, noch unbekannte, Lücken auf. Hierbei ist es unerheblich, welche Software ein Update erfährt. Es könnte das Betriebssystem des Servers sein, der Web- oder Datenbankserver oder auch die Shopsoftware selber.

Integriert man z.B. ein ein neues Widget, so wird meist nur eine Zeile Code in die Templates eingefügt, welche ab sofort ein JavaScript von einem externen Anbieter nachlädt. Ist der Code des Widgets nicht sorgfältig genug programmiert, so könnte es sein, dass man sich gerade eine Lücke in sein System eingebaut hat – ein Widget mit eher unerwünschten Features.


Ich würde nun zwar nicht behaupten, dass diese Zertifikate vollkommen wertlos sind – da nicht nur die Sicherheit aus technischer Sicht geprüft wird, sondern auch die Prozesse einer Bestellung, die nach dem letzten Klick im Shop folgen – aber die Zertifizierer sollten dem Endkunden klar machen, dass das Zertifikat, aus technischer Sicht, nur ein Schnappschuss, eine Zustandsbeschreibung für den Zeitpunkt der Prüfung sein kann.

Aus meiner Sicht gibt es nur zwei Möglichkeiten, um mit dieser unbefriedigenden Position, als Zertifikat ausstellende Stelle, umzugehen:

  1. Man muss seine Kunden dazu zwingen, jegliche Änderungen an der Website mitzuteilen, damit eine Nachprüfung erfolgen kann. Jede Nachprüfung (Datum, evtl. kurze Beschreibung) wird auch für den Endkunden Dokumentiert, um auch hier Vertrauen zu schaffen. Wird festgestellt, das Änderungen nicht mitgeteilt wurden, so verfällt ein Zertifikat mit sofortiger Wirkung, was ebenfalls für den Endkunden dokumentier wird.
  2. Dem Endkunden muss glasklar Mitgeteilt werden, dass das Zertifikat für das Datum gilt, an dem eine Prüfung abgeschlossen wurde und er sich darauf verlassen kann, dass zu diesem Datum eine relative Sicherheit bestand – denn 100% Sicherheit gibt es nicht. Dem Besucher der Website muss aber auch vermittelt werden, dass die nächste Prüfung erst in 12 Monaten erfolgt und bis dahin jederzeit Lücken entstehen könnten, die alleine im Verantwortungsbereich des Betreibers der Website liegen und nicht der Zertifikat ausstellenden Stelle anzulasten sind.



Die Betreiber der Websites wollen mit der Zertifizierung werben, um dadurch mehr Umsatz zu generieren – was durchaus legitim ist – aber, sie müssen sich dann auch mehr in die Pflicht nehmen lassen. Wenn eine Website eine Prüfung erfolgreich durchlaufen hat, so kann man nicht die nächsten 12 Monate fleissig neue Features einbauen oder Änderungen vornehmen und wirklich meinen, weiterhin mit einem Zertifikat glaubhaft werben zu können.


Als Zertifizierer könnte man aus dem Dilemma – zwischen 364 Tage Risiko und fortlaufender Prüfung nach jeder Änderung, welche angeblich kein Websitebetreiber will – auch entkommen, indem ein neues Produkt mit zwei Stufen angeboten wird.

  1. Der Kunde bekommt das bisherige Zertifikat, allerdings mit dem für den Endkunden deutlich erkennbaren Hinweis, dass das Zertifikat nur für das Datum der Ausstellung des Zertifikats gilt und jegliche zukünftigen Lücken von dem Betreiber der Website zu verantworten sind. Sollte der Websitebetreiber eine angeforderte Nachprüfung erfolgreich durchlaufen, so wird natürlich auch das Datum des Zertifikats aktualisiert.
  2. Jegliche Änderungen an der Website müssen dem Zertifizierer mitgeteilt werden, welche eine kostenpflichtige Nachprüfung erfordert. Nur bei dieser Variante kann der Websitebetreiber glaubhaft mit dem Zertifikat werben.

Die weiteren Details zu den zwei Varianten müssen genau erarbeitet werden, welche auch die juristischen Gesichtspunkte mit einbeziehen, wer wofür haftbar gemacht werden kann, etc.


Sollte an der aktuellen Vergabepraxis von Zertifikaten nichts geändert werden, so werden wir erleben, dass diese, von der technischen Seite her, vollkommen wertlos werden, da der Endkunde jegliches Vertrauen verloren hat.

Thema: Sicherheit, Wirtschaft | Ein Kommentar