Einleitung
Chipkarten sind bereits heute Bestandteil unseres täglichen Lebens: Wir benutzen sie nicht nur
als Telefon-, Krankenkassen- und Bankkarte, sondern verwenden sie auch um Zugangsberech-
tigungen zu prüfen, sensible Daten sicher aufzubewahren oder aber um andere sicherheitsre-
levante Transaktionen abzusichern. Ein besonders sensibler und wichtiger Bereich ist die Ver-
wendung als elektronisches Ausweisdokument. Dies ist in vielen Ländern Europas bereits ganz
normal.
Ab dem Jahr 2010 wird in Deutschland der elektronische Personalausweis ausgegeben, der in
Form einer klassischen Chipkarte den alten Personalausweis ersetzt. Der neue elektronische
Personalausweis soll einen elektronischen Identitätsnachweis über das Internet ermöglichen,
der die hohen Sicherheitsanforderungen des bisherigen Personalausweises erfüllt.
Grundlage für den elektronischen Personalausweis ist die vom Bundesamt für Sicherheit in
der Informationstechnik (BSI) veröffentlichte technische Richtlinie TR03110[3], die Anfor-
derungen und Protokolle beinhaltet, auf deren Grundlage sichere maschinenlesbare Ausweis-
dokumente zu erstellen sind. Die Menge der dadurch entstehenden Anforderungen und Pflich-
ten erzeugt eine für Chipkartensoftware sehr komplexe Software, die zu den anspruchsvollsten
Chipkartenanwendungen gehören, die bisher entwickelt wurden.
Der Prozess der Softwareentwicklung ist extrem fehleranfällig. Ein Großteil der Kosten von
Softwareprojekten wird in den Testphasen und durch Wartung verschlungen. Hierfür gibt es
verschiedene standardisierte Prozesse wie die ISO 9000, die Prozesse für die Überprüfung der
Qualität von Software definieren.
Doch haben diese normierten Verfahren einen entscheidenden Knackpunkt: Sie beschreiben le-
diglich die Prozessabläufe, geben aber keine konkreten Prüfmethoden für ein bestimmtes Soft-
wareprofil vor. Aber genau diese sind ausschlaggebend im Hinblick auf die Ökonomie und
Qualität der Prüfung.
Trotz der bereits gewonnen Erfahrungen treten in der heutigen Softwareentwicklung immer
noch schwere Fehler auf, so dass wöchentlich oder monatlich Nachbesserungen für Software
veröffentlicht werden müssen. Chipkartensoftware hingegen kann auf Grund von Sicherheits-
anforderungen und physikalischen Limitationen nur begrenzt nach der Auslieferung verändert
werden. Zudem würde das hohe Kosten verursachen.
Da es keine allgemeingültige Prüfmethode gibt, nach der eine Software getestet werden kann,
muss die Verwendung der Prüfmethoden abhängig von dem Anwendungsgebiet und dem Kom-
plexitätsprofil der Software entschieden werden. [24]
Dieses Problem trifft insbesondere auf die Eigenschaften und Anforderungen zu, die elektroni-
sche Ausweisdokumente erfüllen müssen. Nur ein Fehler in der Software kann die Sicherheit
und den Datenschutz des Inhabers verletzen und dadurch das Vertrauen in das neue Ausweis-
dokument beschädigen.
In der vorliegenden Arbeit werden wir die Eigenschaften von Chipkartensoftware für Ausweis-
dokumente analysieren und auf Basis dieser Spezifikationen eine systematische Prüfstrategie
i
Einleitung
!
!
"
#
$
%
&
'
(
Abbildung 1: Aufbau der Arbeit
ableiten und anwenden. Wir konzentrieren uns hierbei nicht auf die Überprüfung von physikali-
schen Eigenschaften der Karte oder nicht-funktionalen Anforderungen, sondern auf die korrekte
Implementierung der technischen Richtlinie, die die Sicherheit des Ausweisdokuments gewähr-
leisten soll. Die weiter unten vorgeschlagene Prüfstrategie zeichnet sich dadurch aus, dass sie
verschiedene praktisch bewährte Prüfmethoden und die reichhaltigen Erfahrungen vergangener
Projekte mit einbezieht.
Im ersten Kapitel beschreiben wir die Stellung der Qualitätssicherung in der Softwareentwick-
lung und suchen die Gründe, warum Softwareentwicklung grundsätzlich fehleranfällig ist. In
einem kurzen Einblick beschreiben wir die Prozesse und Ziele der Qualitätssicherung und ord-
nen diese in die Testhierarchie des V-Modells ein.
Im zweiten Kapitel widmen wir uns den elektronischen Ausweisdokumenten und beschreiben
Spezifikationen für maschinenlesbare Reisedokumente. Wir beschreiben hier die Anforderun-
gen und Protokolle, die sichere Ausweisdokumente umsetzen.
Im dritten Kapitel vergleichen wir verschiedene Prüfmethoden, die sich in der Qualitätssiche-
rung etabliert haben, und diskutieren deren Einsatzgebiete und Vorteile. Auf dieser Grundlage
werden wir die bestehenden Prüfmethoden erweitern.
Im vierten Kapitel beschreiben wir schließlich die neue Prüfstrategie. Diese beinhaltet konkrete
Prüfmethoden, die sich aus den vorangegangen Untersuchungen ergeben.
Im fünften Kapitel wenden wir die neue Prüfstrategie an. Ziel ist die Modellierung abstrakter
Testfälle, auf deren Grundlage ein funktionaler Systemtest entwickelt wird. Dessen Ergebnisse
sowie die Modellierungen liegen der Arbeit bei.
Im sechsten Kapitel explizieren wir einen bereits existierenden Systemtest[4], der erfahrungs-
basiert entwickelt wurde. Welche Bereiche und Fehlerklassen in diesem Fall fokussiert wurden,
steht dabei im Vordergrund.
Im siebten Kapitel vergleichen wir die Systemtests und zeigen Probleme und Vorteile der je-
weiligen Methodologien auf.
1 SoftwareQualitätssicherung
Das klassische Vorgehensmodell der Softwareentwicklung teilt ein Projekt in sieben Phasen:
Planung, Definition, Entwurf, Implementierung, Test, Einsatz und Wartung. In der Planungs-
und Definitionsphase wird der wirtschaftliche Rahmen des Projektes festlegt. Dieser besteht
aus einem Zeitplan und einem Budget. Ein erfolgreiches Softwareprojekt ist daher ein Projekt,
das sowohl den geplanten Zeitplan als auch das geplante Budget einhält.
Nach einer Studie der Standish Group waren im Jahre 1995 nur 16,2% der Softwareprojekte
erfolgreich und 83,8% der Softwareprojekte scheiterten in mindestens einer der Kategorien Zeit
und Budget[14]. In der Konsequenz wurden diese nur unvollständig umgesetzt oder sogar vor-
zeitig abgebrochen. Der Anteil der erfolgreichen Projekte ist bis zur letzten Erhebung im Jahre
2006 stetig auf 25% gestiegen.
Für das Scheitern der Projekte ermittelte die Standish Group Gründe, die sie aus den Selbstein-
schätzungen von 365 befragten Unternehmen ableiteten. Im Folgenden zeigen wir eine Auswahl
der wichtigsten Gründe für das Fehlschlagen von Softwareprojekten:
1
1. Ca. 13% der Befragten gaben an, dass die Anforderungsanalyse zu oberflächlich verlief
oder in dem anschließend erstellten Lastenheft Aspekte fehlten oder inkonsistent waren,
so dass das spezifizierte Produkt ohne neue Anforderungen nicht funktionstüchtig war.
Diese Anforderungen verursachten neuen Aufwand, der zusätzliche Kosten erzeugt hat.
2. Ca. 12,5% der Befragten gaben an, dass der Kunde oder der spätere Benutzer zu spät
oder gar nicht in den Entwicklungsprozess einbezogen wurden und dadurch Fehler in den
Anforderungen und der Umsetzung zu spät erkannt wurden.
3. Ca. 10% der Befragten gaben an, dass der Kunde während der Entwicklung Anforde-
rungen verändert hat. Die Änderungen haben andere bereits umgesetzte Anforderungen
betroffen, so dass die Umsetzung mehr Aufwand erzeugt haben.
4. Ca. 10% der Befragten gaben an, dass der Kunde seine Erwartungen an das zu erstellende
Produkt falsch definiert hat.
Die genannten Scheiterungsgründe der Kategorie (2), (3) und (4) sind auf die fehlende oder
missverstandene Kommunikation zwischen Softwarefirma und Kunden zurückzuführen. Die
Standish Group empfiehlt daher den Kunden stets in die Entwicklung einzubeziehen. Außer-
dem sollten die Phasen ,,design, prototype, develop, test and deploy" mit kurzen Iterationszy-
klen verwendet werden, um frühzeitig Fehler und Missverständnisse aufzudecken[14].
Agile Softwareentwicklungsmethoden fordern keine vollständige Anforderungsanalyse, son-
dern basieren darauf, dass der Kunde von vornherein in die Projektplanung integriert wird.
Dadurch ist es möglich kleine, schnell umsetzbare Projektziele zu definieren, die kurze Itera-
1
Die Zahlen ergeben sich aus dem Durchschnittswert der jeweiligen Typ 2 und 3 Gründe[14]: (1) ,,Incomplete
Requirements & Specifications", ,,Incomplete Requirements"; (2) ,,Lack of User Input", ,,Lack of User Involve-
ment"; (3) ,,Changing Requirements & Specifications", ,,Changing Requirements & Specifications"; (4) ,,Unrea-
listic Expectations", "Unclear Objectives"
1
1 SoftwareQualitätssicherung
tionszyklen der Phasen erlauben. Auf diese Weise werden konzeptionelle Fehler früh erkannt
und der Schaden von Aufwandsfehleinschätzungen verringert.
Nicht alle Projekte können mit einem agilen Vorgehensmodell umgesetzt werden. Für ein Pro-
jekt mit festen Rahmenbedingungen und bereits konkreten Anforderungen könnte die agile Um-
setzung grundsätzlich teurer sein, wenngleich das Risiko zu scheitern kleiner ist.
Bereits vor der Entwicklung agiler Vorgehensmodelle hat man erkannt, dass der Entwicklungs-
prozess von Software fehlerträchtig ist. Projekte mussten nach vielen Jahren der Entwicklung
abgebrochen werden, weil die Kosten für die Fehlerkorrektur die einer Neuentwicklung über-
stiegen hätten. Im Rahmen der oben genannten Studie wurde ermittelt, dass im Durchschnitt
jedes Projekt ein zweites Mal auf Grund einer zu großen Anzahl von Fehlern erneut begonnen
wird.
Die Prozesse, die den Grad der Übereinstimmung zwischen Lasten und Software - die Softwa-
requalität - überprüfen oder sicherstellen, gehören zu der Qualitätssicherung. Die Qualitätssi-
cherung verwendet die Techniken Analyse, Verifikation und Test, um die Softwarequalität zu
messen und Fehler zu finden[35].
· Die Analyse wird angewendet, um bestimmte Aussagen über das Produkt zu treffen, und
ist ein Mittel die Softwarequalität zu sichern, indem Fehler vor ihrer Entstehung verhin-
dert werden. Die Analyse allein reicht nicht aus, um eine hohe Qualität des Produktes
sicherzustellen.
· Beim Test werden Teile der Software ausgeführt und die Ergebnisse überprüft. Stimmen
die Ergebnisse nicht mit der Spezifikation überein, so ist der Test fehlgeschlagen. Ein
fehlgeschlagener Test deutet entweder auf falsche Erwartung oder auf ein Fehler in der
Software hin. Ein Test kann allerdings nur die Implikation zeigen, dass ein Fehler exis-
tiert, wenn ein Testfall fehlschlägt.
· Die Verifikation versucht die Korrektheit der Software zu beweisen; schlägt dieser Beweis
fehl, zeigt dies, dass die Software einen Fehler enthält. Gelingt der Beweis, so enthält die
Software keinen Fehler.
In der Praxis hat sich die Analyse und das Testen gegenüber der Verifikation zur Überprüfung
der Qualität durchgesetzt, da der Aufwand für eine formale Verifikation drei bis fünfmal so hoch
ist, wie eine gleichwertige Prüfung durch Analyse und Test[25].
In den meisten Projekten werden die Ergebnisse einer Phase durch qualitätssichernde Maßnah-
men geprüft. Die Prüfung der Spezifikationen und Entwürfe der konzeptionellen Phasen erfolgt
durch Analyse. Die Implementierung der Software wird durch Tests auf Funktionstüchtigkeit
geprüft. Auch werden die korrekte und fehlerfreie Umsetzung der Anforderungen durch Tests
geprüft.
Da die Korrekturkosten für einen Fehler geringer sind je früher der Fehler gefunden wird, ist die
Qualitätssicherung für ein Projekt ökonomisch: Die Korrekturkosten für einen in der Analyse
gefundenen Fehler sind um das 100 fache geringer als die Korrekturkosten, für ein im Feld ge-
fundenen Fehler. Auch die Korrekturkosten für ein in der Entwicklung gefundenen Fehler sind
noch um das 12-fache größer als die Korrekturkosten, für ein im Feld gefundenen Fehler[30].
Daher sind die Prozesse der systematische Überwachung der Qualität fester Bestandteil eines
Softwareprojekts. Eine effektive Qualitätssicherung kann das Scheitern eines Projektes aktiv
verhindern und die Wahrscheinlichkeit für Scheiterungsgrund der Kategorie (1), (3) und (4)
verringern.
2
Das Qualitätsmanagement plant und bestimmt die Qualitätssicherungsprozesse eines Software-
projekts. Im Folgenden beschreiben wir die Aufgaben des Qualitätsmanagements und zeigen
das Qualitätsmanagementmodell des V-Modells, mit dem Ziel die Prüfungen der in dieser Ar-
beit verglichenen Methodologien einzuordnen.
1.1 Qualitätsmanagement
Das Qualitätsmanagement definiert Prüfungen zum Nachweis und organisatorische Maßnah-
men zur Erreichung der Softwarequalität, die um funktionale und nicht funktionale Qualitäts-
zielbestimmungen erweitert werden kann. Diese Qualitätsziele können vom Kunden vorgege-
ben oder von der Softwarefirma selbst definiert werden. Für Software mit einem kritischen Ein-
satzgebiet, wie zum Beispiel in Banken und Versicherungen, aber auch eingebetten Systemen,
können besondere Qualitätszielbestimmungen für sensible Module definiert werden, da Fehler,
die erst im produktiven Einsatz gefunden werden, besonders hohe Fehlerkorrekturkosten oder
Schaden erzeugen können. Eine Rückrufaktion von Chipkarten würde zum Beispiel das Image
von Kartenherausgebern über Jahre hinweg schaden[33] und das Vertrauen des Benutzers in
das Produkt verringern. Das Qualitätsmanagement muss daher besondere Sicherungsmaßnah-
men für die entsprechenden Module definieren.
Bestimmte Qualitätszielbestimmungen können ein Projekt ökonomischer machen oder die Wahr-
scheinlichkeit für den Erfolg des Projektes erhöhen, indem Qualitätsziele nicht auf das Produkt,
sondern an den Prozess gestellt werden. Das Qualitätsmanagement könnte beispielsweise die
Vollständigkeit oder Verständlichkeit der Dokumentation als Qualitätsziel definieren, welche
von der Qualitätssicherung im Entwicklungsprozess überprüft wird. Durch diese Qualitätsziel-
bestimmung wird die Nachvollziehbarkeit gesichert und die Einarbeitungszeit für neue Mit-
arbeiter verringert. Ein positiver Nebeneffekt wäre außerdem, dass in vielen Fällen durch die
Prüfung der Dokumentation Fehler im Produkt gefunden werden, und somit eine Steigerung der
Qualität des Produktes verursacht.
Die Prüfung zum Nachweis der Softwarequalität wird von der Qualitätssicherung unter Ver-
wendung einer Prüfstrategie durchgeführt. Eine Prüfstrategie besteht aus Prüfmethoden, deren
Auswahl von den spezifischen Eigenschaften des Prüflings abhängt [24].
1.2 Qualitätsmanagementmodell des V-Modell
Im Folgenden zeigen wir das Qualitätsmanagementmodell des V-Modells. Der Name ,,V-Modell
" ergibt sich grundsätzlich daraus, dass ein Vorgehensmodell definiert wird, und aus der Visua-
lisierung der zeitlichen Abfolge der Phasen, die in ,,V"-Form dargestellt werden können, siehe
Abbildung 1.1.
Das ,,V-Modell " definiert zu jeder Phase der Entwicklung eine Prüfung mit bestimmten Prüf-
zielen, in der eine Testspezifikation während oder nach Abschluss der Phase konzipiert wird.
Allein die Erstellung der Testspezifikation deckt in der Regel eine Reihe von Fehlern entweder
in den Anforderungen, der Architektur oder der Komponente auf, da ein Testfallingenieur eine
andere Sicht auf die Anforderung der entsprechenden oder vorhergehenden Phasen besitzt als
der Analyst, Architekt oder Programmierer[32][25]. Die Qualität einer Testspezifikation ergibt
sich aus der Abdeckung des Prüflings, die sich nur in bestimmten Fällen formal messen lässt.
Die Prüfstrategie beschreibt in diesem Fall das Vorgehen zur Erstellung der Testspezifikation
3
1.2 Qualitätsmanagementmodell des V-Modell
)
Abbildung 1.1: Teststufen und Testaktivitäten des V-Modell
und hat somit direkte Auswirkung auf die Qualität dieser. Außerdem beeinflusst die Prüfstrate-
gie den Aufwand, der für die Prüfung notwendig ist.
Im Anschluss an die Implementierung werden die Testspezifikationen von Testern durchgeführt.
Die dabei aufgedeckten Fehler werden dann korrigiert und die Testspezifikation wird erneut
durchgeführt. Dieser Prozess wird so lange wiederholt, bis kein Fehlverhalten mehr von den
Tests aufgedeckt wird.
Abbildung 1.1 zeigt die schematische Übersicht und die zeitliche Abfolge der Testaktivitäten
in den jeweiligen Phasen. Es folgt die Erläuterung der Prüfziele der einzelnen Testspezifikatio-
nen:
· Der Komponententest untersucht Module und Klassen isoliert. Eine Testspezifikation für
den Komponententest muss daher Kenntnis von der Schnittstelle des Moduls haben. Ziel
des Tests ist es zu garantieren, dass Schnittstelle und Verhalten eines einzelnen Moduls
den Anforderungen entsprechen. Das Verhalten, dass eine Komponente für die Interaktion
zwischen Modulen definiert, wird hier nicht geprüft.
· Der Integrationstest untersucht Teilsysteme mehrerer Komponenten. Hier werden die
Schnittstellen für die Interaktion zwischen Modulen getestet, die im Komponententest
nicht durchgeführt wurden.
· Der Systemtest untersucht die vollständige Software gegen die Anforderungen der Spe-
zifikation. Der Systemtest des V-Modells wird in der Praxis häufig mit Funktionstest be-
zeichnet. Im Rahmen dieser Arbeit wird eine Prüfstrategie zur Entwicklung eines funk-
tionalen Systemtests entworfen.
· Der Abnahmetest prüft die Software gegen die nicht-funktionalen Anforderungen und
beinhaltet unter anderem Feldtests und Benutzerakzeptanztests.
Durch diese Aufteilung wird versucht zunächst Fehlverhalten in den kleinsten Einheiten des
Projekts und dann Fehlverhalten in den nächstgrößeren Einheiten zu finden. Dieses systema-
tische Vorgehen spart Zeit in der Fehleranalyse und minimiert die Anzahl der durchgeführten
4
!
"
#
$
#
%
Abbildung 1.2: Effekt unterschiedlicher Systemansichten.
Tests. Werden Fehler durch eine Testspezifikation gefunden, sollten nach der Fehlerbehebung
die Tests der vorhergehenden Testspezifikationen erneut durchgeführt werden, um Fehlverhal-
ten, welches durch Seiteneffekte der Korrektur erzeugt wurde, möglichst früh zu finden.
1.3 Prozesse der Qualitätssicherung
Jede Prüfung beginnt mit der Anforderungsanalyse, in der das Team der Qualitätssicherung un-
ter Verwendung der vom Qualitätsmangement vorgegebenen Methodologien und Werkzeugen
die vorhandenen Spezifikationen nachvollzieht und auf Testbarkeit überprüft. Es findet ein ers-
ter Prozess des Reviews statt, bei dem wie oben erwähnt in der Regel Fehler gefunden werden.
Durch den Prozess der Kommunikation zum Analyseteam, findet eine Auffrischung des Wis-
sens im Analyseteam statt, so dass komplexe Bereiche häufiger diskutiert werden und somit
die Wahrscheinlichkeit für das Entdecken von Fehlern in diesem Bereich erhöht wird. Abbil-
dung 1.2 dient zur Veranschaulichung dieses Effektes: Zwar findet der Prüfer nicht immer einen
Fehler, trägt aber zur Wissensverteilung im Analyseteam bei.
Der Prüfer erzeugt bei der Analyse ein Modell des Systems und leitet unter Verwendung einer
Prüfmethode Prüfobjekte und Tests ab. Um den Prozess nachvollziehbar zu halten, sollte der
Prozess der Prüfobjekt- und Prüffallselektion dokumentiert werden. Nach der Analyse werden
daher Dokumente angelegt, die begründen, welche Bereiche unter welchen Aspekten getestet
werden sollten. Im Anschluss an die Prüfobjektidentifikation kann zwischen drei Vorgehens-
weisen Tests abzuleiten unterschieden werden:
1. Im erfahrungsbasierten Test werden Tests nach Analyse der Anforderungen auf Basis von
Fehlervermutung und Erfahrungen von Softwarefehlern einer ähnlichen Domäne erstellt.
2. Im anforderungsbasierten Test wird für jede einzelne Anforderung eine Anforderungstes-
tanalyse durchgeführt, aus der sich dann eine Menge von Tests ergeben.
3. Im modellbasierten Test wird die Modellerstellung des Systems formalisiert, so dass die
Analyse der Anforderungen eines Prüfobjekts ein Modell ergibt. Aus dem Modell werden
Tests abgeleitet, die dann die Abdeckung des Modells und somit der Anforderungen, die
dem Modell zugeordnet wurden, sicherstellt.
5
1.3 Prozesse der Qualitätssicherung
Modellbasiertes Testen hat den Vorteil, dass Tests die aus einem Modell abgeleitet werden,
leichter nachzuvollziehen und wartbarer sind. Darüber hinaus kann die ,,Vollständigkeit" der
Tests über objektive Abdeckungsmetriken des Modells gemessen werden. Die subjektive Ab-
schätzung der Anforderungsabdeckung von länglichen Testspezifikationen wird dabei auf die
subjektive Abschätzung der Anforderungsabdeckung des Modells verschoben.
Nachdem die Tests abgeleitet und gegebenenfalls implementiert wurden, beginnt die Testdurch-
führung. Stellt sich dabei heraus, dass ein Prüfobjekt besonders viele Fehler enthält, sollten für
dieses Prüfobjekt weitere Tests entworfen werden, da sich die Wahrscheinlichkeit, dass ein Teil
einer Software einen weiteren Fehler enthält, proportional zu der Anzahl der bereits gefundenen
Fehler in diesem Bereich ist [31]. Es empfiehlt sich daher frühzeitig Bereiche zu identifizieren,
die eine hohe Veränderungsrate haben, und mehr Testfälle dafür zu entwerfen.
Durch die hohe Anzahl der beteiligten Personen ist der Prozess von der Analyse bis zur Durch-
führung der Tests aufwendig, weil das System von vielen Personen zum Teil vollständig nach-
vollzogen werden muss. Aufgabe einer Prüfstrategie ist es also, die speziellen Eigenschaften
des Prüflings zu erfassen und Prüfmethoden zu nennen, die für diese Eigenschaften geeignet
sind. Gleichzeitig muss die Komplexität der Nachvollziehbarkeit, Abdeckungsbegründung und
Wartbarkeit gering zu halten.
6
2 Chipkarte als Ausweisdokument
In diesem Kapitel stellen wir die Details der Software vor, für die wir in dieser Arbeit die
Prüfstrategie entwickeln und anwenden. Im Folgenden beschäftigen wir uns zunächst abstrakt
mit den Funktionen von Ausweisdokumenten. Ziel der Chipkarte als Ausweisdokument ist
es, die herkömmliche Nutzung von Ausweisen in der ,,Papierwelt" auf die elektronische Welt
auszuweiten[28].
Die Funktion eines Ausweises ist es die Identität des Ausweisinhabers gegenüber einer Entität
zu bestätigen. Es ist daher unmittelbar klar, dass ein Ausweis vom Ausweisaussteller mit be-
sonderen Sicherheitsmerkmalen zum Schutz vor Fälschung und Kopie ausgestattet wird. Für die
Bestätigung der Identität sind die meisten Ausweise mit personenbezogenen Daten beschriftet,
die auch direkt überprüfbare biometrische Informationen enthalten können. Manche Ausweise
tragen keine biometrischen Informationen und bestätigen lediglich die Identität des derzeitigen
Besitzers oder sind nur in Verbindung mit einem weiteren Ausweisdokument gültig.
Im Folgenden wollen wir die herkömmliche Verwendung des Ausweises am Beispiel einer Kon-
toeröffnung erklären, um daraus die Prozesse abzuleiten, die in einem elektronischen Ausweis-
dokument umgesetzt werden müssen. Für die Kontoeröffnung benötigt die Bank eine Bestäti-
gung der Identität des zukünftigen Kontoinhabers, die in der Regel mit einem Ausweis durch-
geführt wird. Der Prozess der Identitätsbestätigung und -überprüfung wird als Authentisierung
bezeichnet[28]. Der Vorgang gliedert sich in folgende Schritte:
1. Die Person betritt die Räumlichkeiten der Bank, bei der sie ein Konto eröffnen will.
2. Die Person übergibt ihren Ausweis an den Bankangestellten.
3. Der Bankangestellte prüft, ob der Ausweisaussteller von der Bank als vertrauenswürdig
eingestuft wird.
4. Der Bankangestellte prüft die Sicherungsmerkmale, sowie die Gültigkeit des Ausweises.
5. Der Bankangestellte liest Daten des Ausweises ab.
Die Schritte 2 bis 4 bilden die ausweisgestützte Authentisierung ab. Tatsächlich findet in Schritt
1 eine implizite Authentisierung der prüfenden Bank gegenüber dem Ausweisinhaber statt, so
dass die Bank durch Schritt 1 eine implizite Legitimation vom Ausweisinhaber erhält, den Aus-
weis prüfen zu dürfen. Die herkömmliche Nutzung eines Ausweises ist daher eine gegenseitige
Authentisierung.
Um die elektronische Authentisierung zu ermöglichen, müssen diese Schritte auf Protokolle
zwischen einer Chipkarte und einem Dienst übertragen werden. Die in Schritt 1 stattfinden-
de implizite Authentisierung der Entität gegenüber der Person ist in dieser Form nicht auf
die elektronische Welt übertragbar. Hier muss eine Authentisierung des Dienstes gegenüber
der Chipkarte erfolgen, so dass die Chipkarte die Legitimation des Dienstes überprüfen kann,
um sicherzustellen, dass sie mit einem zum Auslesen von Ausweisdaten legitimierten Dienst
kommuniziert. Dieser Schutz ist notwendig, da eine elektronische Kommunikation für einen
Menschen nicht nachvollzogen werden kann und so unbemerktes Auslesen der Daten aktiv ver-
7
2 Chipkarte als Ausweisdokument
hindert werden muss.
Der elektronische Reisepass (ePass) als elektronisches Ausweisdokument ist bereits mit einem
kontaktlosen Chip ausgestattet. Die auf dem Chip elektronisch gespeicherten Daten können von
Kartenterminals ausgelesen werden
1
. Auf dem Chip des ePass werden sowohl personenbezoge-
ne Daten wie Name, Geburtsdatum, Geschlecht, Staatszugehörigkeit, sowie eine digitale Form
des Passbildes und der Fingerabdrücke
2
, als auch dokumentenbezogene Daten wie Seriennum-
mer, Dokumententyp und Gültigkeitsdatum gespeichert. Diese Daten, abgesehen von den Fin-
gerabdrücken, befinden sich auch in menschenlesbarer Form innerhalb des Passes. Die Integrität
der elektronisch gespeicherten Daten wird durch eine digitale Unterschrift des Ausweisausstel-
lers sichergestellt. Der Chip im Reisepass ist daher ein weiteres Element zur Überprüfung der
Integrität des Ausweises und ist daher nur Bestandteil einer klassischen Authentisierung der
,,Papierwelt". Im obigen Beispiel würde der Chip erst im Schritt 4 verwendet werden und somit
keine vollständige in der elektronischen Welt stattfindende Authentisierung ermöglichen.
Ziel der Einführung des elektronischen Personalausweises (ePA) im September 2010
3
ist es, die
Nutzung des Personalausweises auf die elektronische Welt auszuweiten und eine Authentisie-
rung über das Internet zu ermöglichen. Die auf dem Chip umgesetzten Protokolle ermöglichen
eine Authentisierung, die vollständig elektronisch ablaufen kann und daher die einzelnen Schrit-
te der gegenseitigen Authentisierung des obigen Beispiels in elektronischer Form abbildet. Die
implizit stattfindende Authentisierung aus Schritt 1 des obigen Beispiels wird über folgenden
Mechanismus gelöst: Jede zum Auslesen von Ausweisdaten berechtigte Instanz besitzt ein Zer-
tifikat, welches die Klassifikation der Daten enthält, die von der Instanz ausgelesen werden
dürfen. Die Gültigkeit des Zertifikats kann der Ausweis selbstständig mit einem auf dem Chip
gespeicherten Schlüssel prüfen. Anschließend prüft der Dienst die Gültigkeit und Echtheit der
Karte und kann dann die Identität des Benutzers elektronisch bestätigen.
Der Standard ICAO Dokument 9303[16] definiert die Protokolle und Datenstrukturen, die ein
elektronischer Reisepass erfüllen muss. Diesen Richtlinien entsprechend wurde die ,,Techni-
schen Richtlinie 03110 Extended Access Control 1.11"[4] (TR03110 EAC 1.11) vom BSI
definiert, die die Details des deutschen elektronischen Reisepasses festlegt. Die Version 2 der
,,Extended Access Control" wurde in der ,,TR03110 Version 2 - EAC 2.0"[3] veröffentlicht und
definiert Protokolle und Datenstrukturen für ein sicheres, öffentlich einsetzbares, europäisches
Ausweisdokument.
In diesem Kapitel beschreiben wir zunächst die Grundlagen von Chipkarten und RFID. An-
schließend skizzieren wir die Protokolle der EAC 1.11 zur Herstellung einer Verbindung und
zeigen, warum diese nicht die Anforderungen eines nicht-öffentlich einsetzbaren und daten-
schutzfreundlichen Ausweisdokuments erfüllen. Dann erklären wir die Bestandteile der EAC
2.0, für die wir die Prüfstrategie zur Systemtestentwicklung konzipieren. Dabei beschränken
wir uns auf die Aspekte, die für die Wahl der Prüfmethoden relevant sind. Dazu gehört der lo-
gische Aufbau der Protokolle und die verwendeten Datenstrukturen, nicht aber die spezifischen
Kodierungen, wie zum Beispiel die DER-TLV Kodierung der Parameter oder Datenstrukturen
oder dem detaillierten ISO 7816-4 Paketformat[18]. Diese Informationen können aus der TR
03110 bezogen werden.
1
Nach §18 PassG ist es nur hoheitlichen Geräten erlaubt die Daten elektronisch auszulesen. Sonst ist es nur Beför-
derungsunternehmen in bestimmten Situationen erlaubt eine Verbindung mit dem Pass herzustellen.
2
Seit dem 1. November 2007 sind Fingerabdrücke im elektronischen Reisepass Pflicht.
3
Stand 10.03.2009.
8
2.1 Chipkarten und RFID
Die ersten Plastikkarten wurden in den 50'er Jahren zur Identifikation von Clubmitgliedern
ausgegeben. Plastikkarten haben den Vorteil gegenüber von Papier- oder Kartonkarten robust,
langlebig und wasserbeständig zu sein. Gegen Fälschung wurden die Karten mittels Hochprä-
gung und Unterschriftsfeld gesichert.
Die 1984 eingeführten Telefonkarten besaßen einen integrierten Chip, deren Funktion es war
Zeiteinheiten auf der Karte manipulationssicher auszustreichen. Galvanische Verbindungen zwi-
schen Lesegerät (in diesem Fall eine Telefonzelle) und Kontaktflächen der Karte dienen der
Stromversorgung des Chips und der Kommunikation zwischen Terminal und Chip. Chipkar-
ten, die auf diese Weise vom Terminal mit Strom versorgt werden und kommunizieren, heißen
daher kontaktbehaftete Chipkarten. Im Jahre 2010 werden 3,0 Mrd. Chipkarten produziert wor-
den sein, woraus sich der Erfolg der Chipkarten ableiten lässt. Für eine detaillierte historische
Betrachtung der Entwicklung der Chipkarten siehe [33].
Mit der Funktechnologie ist es möglich den Chip kontaktlos mit Strom zu versorgen. Dies wird
durch eine in die Karte integrierte Spule ermöglicht, welche in ein elektromagnetisches Wech-
selfeld gehalten durch Induktion Strom erzeugt, der den Chip in der Karte betreibt. Weiterhin
versorgt der Strom einen Funksender und -empfänger in der Karte, die die Kommunikation mit
dem Terminal ermöglichen. Vorteile der ,,kontaktlosen" Chipkarten sind die einfachere Hand-
habung und die höhere Haltbarkeit gegenüber kontaktbehafteten Karten, die bei häufiger Benut-
zung durch das Einführen in ein Kartenlesegerät Verschleißspuren aufweisen.
Kontaktlose Chipkarten haben sich als Ausweiskarten in den Niederlanden, Schweden und im
deutschen Reisepass bewährt[9].
2.1.1 Bedrohungsszenarien für kontaktlose Chipkarten
Kontaktlose Chipkarten kommunizieren mit einem Kartenterminal über elektromagnetische Wel-
len. Zwar sind die von den schwachen Transpondern der Karte gesendeten Wellen nur in kurzer
Distanz mit einfachen technischem Mitteln empfangbar, tatsächlich können diese aber auch
aus größerer Distanz nachgewiesen und empfangen werden. [2] Aus diesem Grund entsteht
für kontaktlose Chipkarten, die mit dem Terminal über Protokolle kommunizieren, deren Si-
cherheit auf einem vertraulichen Kommunikationskanal basieren, das Bedrohungsszenario des
unbemerkten Abhörens, welches für kontaktbehaftete Chipkarten mit einem nicht manipulier-
tem Kartenterminal prinzipiell nicht existiert. Es werden also für kontaktlose Chipkarten stets
geeignete kryptographische Protokolle benötigt, die einen vertraulichen Kanal zwischen zwei
potentiell unbekannten Geräten herstellen können.
Alle Bedrohungsszenarien, die kontaktbehaftete Chipkarten sonst besitzen, lassen sich auch auf
kontaktlose Chipkarten übertragen. Diese zielen darauf ab die zentrale Funktion der sicheren
Aufbewahrung ein oder mehrerer Sicherheitsobjekte auf einer Chipkarte zu kompromittie-
ren.
Die Sicherheitsobjekte sind im Chip oder im externen Speicher des Chips abgelegt. Ein Chip
kann ein Sicherheitsobjekt absichern, indem der Chip vom Terminal den Beweis der Kenntnis
eines weiteren Sicherheitsobjektes verlangt. Für den Beweis der Kenntnis eines Sicherheitsob-
jekts existieren drei Ansätze:
1. Das Terminal sendet das Sicherheitsobjekt über einen hinreichend sicheren Kanal an die
9
2.1 Chipkarten und RFID
Karte.
2. Die Karte sendet eine Frage (engl. challenge), die vom Terminal nur mithilfe eines Si-
cherheitsobjektes beantwortet werden kann (Challenge-Response Protokoll).
3. Das Terminal beweist, dass es das Sicherheitsobjekt kennt, ohne dieses explizit zu erwäh-
nen und ohne dass ein Angreifer Informationen über dieses erhält (ZeroKnowledgePro-
tokoll).
Ansatz 2 hat gegenüber Ansatz 1 den Vorteil, dass ein Angreifer durch Abhören des Kanals
nicht direkt das Sicherheitsobjekt erfährt. Ein Challenge-Response Protokoll hat den Nachteil,
dass das Sicherheitsobjekt bei geringer Entropie offline - durch Ausprobieren - ermittelt werden
kann. Diese Schwachstelle wird von ZeroKnowledgeProtokollen beseitigt.
Die elektronische Versorgung der Karte über die Luftschnittstelle per Induktion verursacht zu-
nächst Bedienbarkeitsprobleme: Die Stromversorgung ist im Gegensatz zu kontaktbehafteten
Karten störungsanfällig, so dass kleine Bewegungen ausreichen, um Stromschwankungen in
der Karte zu erzeugen, so dass Berechnungen im Chip fehlschlagen. Andere magnetische oder
elektronische Geräte im Feld können die Stromversorgung ebenfalls stören und dafür sorgen,
dass die Verbindung zwischen Terminal und Karte nicht zustande kommt oder nicht erfolgreich
abgeschlossen werden kann.
Diese Möglichkeit die Stromversorgung des Chips zu steuern nutzen Angreifer aus, um Rück-
schlüsse auf die im Chip verarbeiteten Daten zu ziehen. Diese als Seitenkanalangriffe bekannten
Bedrohungsszenarien, welche zuerst auf kontaktbehaftete Karten durchgeführt wurden, können
darauf abzielen Informationen auf das im Chip gespeicherte Sicherheitsobjekt zu erhalten und
unter Kenntnis des Sicherheitsobjekts den Chip zu fälschen oder zu kopieren.
Ein weiteres Bedrohungsszenario entsteht, wenn der beschreibbare Speicher der Karte nicht
geschützt ist, und von außen ausgelesen werden kann. Findet der Angreifer temporäre Daten
der in den Protokoll verwendeten Berechnungen, so könnte dies ermöglichen, dass Protokolle
ohne Kenntnis des Sicherheitsobjekts abgeschlossen werden.
Ist das Auslesen des Speichers nicht möglich, könnte eine Überschreibung des Speichers den
Effekt verursachen innere Sicherheitszustände zu verändern. Neben den Angriffen auf den be-
schreibbaren Speicher der Karte gibt es Angriffe die darauf abzielen die Authentisierungsme-
chanismen zu umgehen und Zugriff auf sensible Daten zu erlangen, indem gezielt Chiptransis-
toren oder -leitungen manipuliert werden. [2]
Weiterhin könnten beliebige physikalische Angriffe die Bestandteile der Chipkarte derartig be-
einflussen, dass sie unzuverlässig arbeiten. Insbesondere für den in einer Chipkarte befindlichen
Zufallsgenerator muss sichergestellt werden, dass die Zuverlässigkeit nicht durch derartige An-
griffe beeinflusst werden kann. Ein Beispiel für die Konsequenz eines unzuverlässigen Zufalls-
generators zeigen wir in Abschnitt 2.3.6.
Neben den Angriffen auf die Chipkarte muss allerdings erwähnt werden, dass Kartenterminal
und Software des Terminals ebenfalls eine große Angriffsfläche bilden. Die Angriffe auf Ter-
minals und ihrer Software sind allerdings meist Terminalspezifisch und können in der Regel
nicht auf alle Kartenterminals für eine bestimmte Karte verallgemeinert werden. Erfolgreiche
Angriffe auf Kartenterminals und ihrer Software können durch Austausch dieser oder Einspie-
len von Updates verhindert werden und erfordern daher nicht den Austausch der Chipkarte.
Der mit einem Fehler verbundene Imageverlust ist daher niedriger einzustufen, als der Fehler
im Kartenbetriebssystem. Dennoch muss bei der Umsetzung eines sicheren Ausweisdokuments
die Sicherheit und Qualität der Terminalsoftware genauso intensiv geprüft werden, wie die der
10
Chipkartensoftware.
2.2 Sicherheitsmechanismen nach EAC 1.11
Wie in der Einleitung dieses Kapitels beschrieben, dient EAC 1.11 nicht der Umsetzung ei-
nes elektronischen Identitätsnachweises, sondern einer elektronischen Integritätsprüfung des
Ausweises, die einen weiteren Kopier- und Fälschungsschutz darstellt. Dennoch kritisieren Da-
tenschützer diesen Sicherheitsmechanismus, da die Verwendung eines kontaktlosen Chips in
Verbindung mit den Sicherheitsmechanismen nach EAC 1.11 problematisch sei [34]. Im Fol-
genden wollen wir kurz die Funktionsweise von EAC 1.11 erläutern und begründen, warum
dieser Mechanismus für die Integritätsprüfung des elektronischen Personalausweises nicht in
Frage kommt.
Zur Herstellung eines sicheren Kanals führen EAC 1.11 konforme Chips, wie der Chip des
ePass, das Basic Access Control (BAC) Protokoll aus. Dieses leitet aus der Maschinenlesbaren
Zone (MRZ), die auf einer Seite innerhalb des ePass menschenlesbar aufgedruckt ist, einen
Schlüssel ab. In der MRZ sind Passnummer, Geburtsdatum und Ablaufdatum kodiert, so dass
sich eine maximal Entropie von 50 Bit für den Schlüssel ergibt. Zusammen mit dem Wissen, wie
sich aus diesen Daten der Kommunikationsschlüssel ableitet (was nach dem Kerckhoff Prinzip
keine Erhöhung der Sicherheit darstellt), kann ein Terminal zu dem Chip einen sicheren Kanal
aufbauen. Da zur Herstellung des Kanals das Öffnen des Ausweises und Scannen der MRZ
notwendig ist, stellt das BAC Protokoll das Verhalten eines Grenzkontrolleurs nach. Kennt ein
,,Angreifer" die Passnummer, das Geburtsdatum und das Ablaufdatum und weiß zusätzlich, wo
sich der Pass befindet, könnte er die Daten des Passes unbefugt auslesen. Dieses Szenario wird
aber vom BMI als unwahrscheinlich erachtet[7].
Anfang 2006 ist eine Sicherheitslücke in dem Konzept der Schlüsselgenerierung gefunden wor-
den. Die Entropie des Schlüssels kann von geplanten 50 Bit auf 35 Bit reduziert werden, da
die Verteilungen der Passnummer und des Ablaufdatums zum Teil nicht statistisch unabhängig
sind[38]. So kann das Protokoll eines abgehörten Dialogs zwischen Lesegerät und Karte inner-
halb weniger Stunden durch Brute-Force entschlüsselt werden, ohne dass weitere Informationen
über den Ausweisinhaber notwendig sind
4
. Das Mithören der Kommunikation zwischen Lese-
gerät und Pass ist aus eine Distanz von bis zu 10 Meter durchführbar
5
. Als Konsequenz werden
nun in den betroffenen Ländern die Passnummern zufällig generiert.
Kann die Schlüsselentropie von 50 Bit garantiert werden, besitzt BAC die folgenden Eigenschaften:[36]
· Hohes Sicherheitsniveau gegen aktives Auslesen, da Brute-Force durch Chipgeschwin-
digkeit beschränkt wird.
· Mittleres Sicherheitsniveau gegen passives Mitlesen, wenn keine zusätzlichen Informa-
tionen über den Pass bekannt sind.
· Statischer Sessionkey gewährt keine Forward-Secrecy.
Aus diesen Eigenschaften folgt, dass für die nicht-öffentliche Nutzung eines Ausweises unter
Verwendung von BAC und somit EAC 1.11, folgendes Bedrohungsszenarien entsteht: ,,Stand-
ortverfolgung" (engl. tracking) von Passbesitzern, indem unter Verwendung der MRZ der nach-
4
http://www.heise.de/tp/r4/artikel/21/21907/1.html
5
http://www.riscure.com/contact/privacy-issue-in-electronic-passport.html
11
2.3 EAC 2.0 konforme Ausweisdokumente
zuverfolgenden Person versucht wird, zu jedem in der Nähe befindlichen Reisepass eine Ver-
bindung herzustellen.
2.3 EAC 2.0 konforme Ausweisdokumente
EAC 2.0 umfasst die Spezifikation von drei Anwendungen: Die ePassport, eID und eSignAn-
wendung, für dessen Nutzung die gegenseitige elektronische Authentisierung notwendig ist.
Für die elektronische Authentisierung und die Anwendungen werden eine Reihe von Sicher-
heitsobjekten definiert. Die folgenden Sicherheitsobjekte können verwendet werden, um die
Kommunikation mit dem Chip zu ermöglichen und das Terminal für bestimmte Funktionen zu
autorisieren:
· Persönliche Geheimzahl (Personal Identification Number -- PIN): Zum Beispiel 6 stelli-
ge Zeichenfolge, die nur dem Ausweisinhaber bekannt ist, und daher Voraussetzung für
die elektronische Authentisierung ist.
· Kartenzugangsnummer (Card Access Number -- CAN): Zum Beispiel 6 stellige Ziffern-
folge, die auf dem Ausweis aufgedruckt ist.
· Maschinenlesbare Zone (Maschine Readable Zone -- MRZ): Zum Beispiel 50 Bit lange
alphanumerische Zeichenfolge, die auf dem Ausweis aufgedruckt ist, und nur für Kom-
munikation mit hoheitlichen Stellen verwendet werden darf.
· Persönliches Entsperrgeheimnis (Personal Unblocking Key -- PUK): Zum Beispiel 44
Zeichen lange Ziffernfolge, die nur dem Ausweisinhaber bekannt ist. Diese kann vom
Ausweisinhaber verwendet werden, um eine gesperrte PIN zu entsperren. Die PUK be-
sitzt gegenüber den anderen Sicherheitsobjekten eine höhere Sicherheitsstufe.
Neben diesen Sicherheitsobjekten enthält der Ausweis einen privaten Schlüssel, mit dem er sich
gegenüber einem Terminal authentisieren kann.
Auf dem Chip des Ausweises sind die personen- und dokumentenbezogenen Daten digital ge-
speichert. Abhängig von der Anwendung, die ein Terminal verwendet, können bestimmte perso-
nenbezogene Daten ausgelesen werden. Die Prüfung des Ablaufdatums des Ausweises ist jeder
Anwendung gestattet. Hierfür übermittelt ein Terminal das aktuelle Datum und der Ausweis
antwortet, nachdem der Verbindungsaufbau abgeschlossen wurde, mit der binären Information,
ob das Datum vor oder hinter dem Ablaufdatum des Ausweises liegt. Es werden daher keine
Auskünfte gegeben, wie lang genau der Ausweis noch gültig ist.
Im Folgenden geben wir eine Übersicht der Protokolle, die in der elektronischen Authentisie-
rung durchgeführt werden und erläutern anschließend die Möglichkeiten der genannten Anwen-
dungen.
2.3.1 Elektronische Authentisierung
Zur Herstellung eines sicheren Kanals über die Luftschnittstelle muss der EAC 2.0 konfor-
me Chip zunächst mit dem Terminal das ,,Password Authenticated Connection Establishment"-
Protokoll (PACE) durchführen, welches zu der Klasse der ZeroKnowledgeProtokollen gehört.
Dieses Protokoll setzt Schritt 2 des einleitenden Beispiels auf Seite 7 um, da für den Verbin-
dungsaufbau die Eingabe eines Sicherheitsobjektes durch den Ausweisinhaber benötigt wird.
Anschließend übertragt das Terminal seine Zertifikatskette, die aus dem Berechtigungszertifikat
12
2.3.2 ePassportAnwendung
und den Zertifikaten besteht, die die Karte benötigt, um die Gültigkeit des Berechtigungszertifi-
kats zu überprüfen. Mit dem Protokoll der ,,Terminal Authentifcation" (TA) beweist das Termi-
nal, dass es der Besitzer des übertragenen Berechtigungszertifikats ist. Die TA setzt die implizite
Authentisierung (Schritt 1) des erwähnten Beispiels um. Anschließend prüft das Terminal zu-
nächst die Integrität des auf dem Chip gespeicherten Schlüssel und dann die Authentizität des
Chips, indem das Protokoll der ,,Chip Authentifikation" (CA) durchgeführt wird. Die CA setzt
Schritt 3 und 4 der elektronischen Authentisierung um. Anschließend kann das Terminal die
personenbezogenen Daten des Ausweises auslesen, für die er durch sein Zertifikat berechtigt ist
(Schritt 5 des obigen Beispiels).
2.3.2 ePassportAnwendung
Die ePassportAnwendung ist ausschließlich für den hoheitlichen Gebrauch konzipiert. Der
Ausweisinhaber kann die CAN an einem hoheitlichen Gerät eingeben, oder den Ausweis auf
einen Scanner legen, der die MRZ automatisiert ausliest. Dieses gemeinsame Geheimnis wird
für den Aufbau des sicheren Kanals im PACE Protokoll verwendet. Nach Abschluss der elek-
tronischen Authentisierung kann das Terminal die personenbezogenen Daten auslesen, die in
sogenannten Datengruppen gespeichert sind. Der Zugriff auf die Datengruppen Iris und Finger-
abdrücke, sowie die Verwendung der anderen Anwendungen kann für bestimmte hoheitliche
Terminals nicht erlaubt sein und wird im Berechtigungszertifikat festgelegt.
2.3.3 eIDAnwendung
Die eIDAnwendung kann über das Internet von nicht-öffentlichen und öffentlichen Diensten
verwendet werden. Nachdem ein Dienst unter Verwendung der PIN oder CAN eine sichere Ver-
bindung aufgebaut hat und die elektronische Authentisierung abgeschlossen ist, kann ein Dienst
ebenfalls bestimmte Datengruppen auslesen. Der Unterschied besteht in den Berechtigungsde-
tails der Zertifikate. Ein eIDDienst kann gezielt für bestimmte Funktionalitäten freigeschaltet
werden, um beispielsweise lediglich ein einziges Datum auszulesen.
Zusätzlich besitzt die eIDAnwendung Funktionen, die aus bestimmten Datengruppen Infor-
mationen extrahieren, ohne dass das Terminal diese erhält. Die Funktionalität der ,,Altersve-
rifikation" bestimmt, ob ein Datum vor oder nach der Datengruppe des Geburtsdatums liegt.
Das Ergebnis der Prüfung ist daher nur ,,Der Geburtstag des Ausweisinhaber liegt hinter dem
übergebenen Datum" bzw. ,,Der Geburtstag des Ausweisinhaber liegt nicht vor (also hinter oder
gleich) dem übergebenen Datum", ohne dass das Terminal Kenntnis über das Geburtsdatum des
Inhabers erlangt hat. Analog kann ein Terminal die Zugehörigkeit des Ausweisinhabers zu einer
Meldestelle verifizieren. Das Terminal kann hierfür entweder eine vollständige Behördenkenn-
zahl
6
an die Karte senden, die diese mit der auf dem Ausweis gespeicherten Behördenkennzahl
vergleicht, oder einen Teil der Behördenkennzahl übermitteln, um nur zu überprüfen, ob es eine
Teilübereinstimmung der Behördenkennzahl mit der auf dem Ausweis gespeicherten Behörden-
kennzahl gibt.
Mit der ,,Restricted Identifikation"Funktionalität (RI) kann ein eIDDienst eine pseudonyme
Registrierung des Ausweisinhabers durchführen. Hier wird eine eindeutige, unumkehrbare ID
aus der Kombination des Ausweises und des Dienstes erzeugt ohne personenbezogene Daten
an den Dienst zu übertragen.
6
Die vierstellige Behördenkennzahl definiert die Meldestelle, in der der Ausweisinhaber gemeldet ist.
13
2.3 EAC 2.0 konforme Ausweisdokumente
In der eIDAnwendung können Signaturen für die eSignAnwendung installiert werden. Da wir
die eSignAnwendung im Rahmen dieser Arbeit nicht untersuchen, verweisen wir an dieser
Stelle für nähere Informationen zu den eSign spezifischen Funktionalitäten der eIDAnwen-
dung auf die TR03110 und die technische Richtlinie TR03117[6].
2.3.4 eSignAnwendung
Mit der eSignAnwendung können die Ausweisinhaber eine qualifizierte Signatur erzeugen und
somit Dokumente unterschrieben können. Im Rahmen dieser Arbeit wird diese Anwendung
nicht im Detail beschrieben.
Im Folgenden beschreiben wir zunächst die zentrale Datenstruktur der erwähnten Berechti-
gungszertifikate, die eine zentrale Rolle im Testprozess einnehmen. Dann erläutern wir die
Protokolle PACE, TA, CA und das Protokoll der RI.
2.3.5 Zertifikate
Ein Zertifikat im Sinne der TR03110 beinhaltet zu einer Anwendung die spezifischen Be-
rechtigungen, die sie von einer zur Zertifikatsausstellung legitimierten Instanz (im Folgenden
,,Aussteller") erhalten hat. Diese Berechtigungen definieren sowohl Datengruppen, die ausge-
lesen werden dürfen, als auch Funktionalitäten, die verwendet werden dürfen. Im Folgenden
beschreiben wir den grundsätzlichen Aufbau der Zertifikate und die Hierarchie der Aussteller.
Anschließend beschreiben wir im Detail die im Zertifikat auftretenden Felder und beschreiben
ihre Funktion in der zu dem Zertifikat gehörenden Anwendung.
Da ein Kartenchip einen begrenzten Speicher und begrenzte Rechenkapazitäten besitzt[17],
wurden so genannte ,,Card verifiable"Zertifikate (CV) entwickelt, die mit geringem Ressour-
cenanspruch validiert werden können. Gegenüber X.509 Zertifikaten sind diese Zertifikate leicht
gewichtiger und können mit wenigen kryptographischen Routinen validiert werden. Der grund-
sätzliche Aufbau der CVZertifikate ist Bestandteil der ISO 78168[19]. Die Hierarchie der
Aussteller, sowie die anwendungsspezifischen Informationen sind in der TR03110 spezifi-
ziert.
Da im Rahmen der EAC 2.0 keine Verwendung von Zertifikatssperrlisten vorgesehen ist, wird
die Möglichkeit korrumpierte Dienste zu sperren, indirekt über kurze Zertifikatsgültigkeits-
zeiträume gelöst. Ein Zertifikat besitzt daher eine begrenzte Gültigkeit, so dass jeder Zertifi-
katsinhaber nach Ablauf seines aktuellen Zertifikats ein neues Zertifikat von seinem Aussteller
beantragen muss. Falls ein Zertifikatsinhaber durch sein Zertifikat zur weiteren Ausstellung von
Zertifikaten berechtigt ist, kann dieser nur Zertifikate ausstellen, deren Gültigkeitszeiträume in-
nerhalb seiner Zertifikatgültigkeit liegen (Schalenmodell, siehe [39]).
Die Hierarchie der Aussteller ist in der TR03110 auf 2 Stufen beschränkt. Dabei darf nur die
Wurzelinstanz die ,,Country Verifying Certification Authority" (CVCA) Zertifikate für sich
selbst ausstellen und somit ihren eigenen Gültigkeitszeitraum verlängern. Bei der Auslieferung
der Ausweise ist ein Zertifikat der CVCA vorinstalliert, so dass die Karte nur von dieser CV-
CA abgeleitete Zertifikate oder Verlängerungszertifikate dieser CVCA validieren kann. Die von
der CVCA ausgestellten Zertifikate erhalten sogenannte ,,Document Verifier" (DV), die weitere
Zertifikate an Dienste oder Behörden ausstellen kann. Da diese Instanzen nur durch ihr Zerti-
fikat berechtigt ist, weitere Zertifikate auszustellen, kann die DV nicht ihre eigenen Zertifikate
verlängern, sondern muss nach Ablauf ihres Zertifikats ein weiteres Zertifikat bei der CVCA
14
2.3.5 Zertifikate
beantragen. Die von der DV ausgestellten Zertifikate sind Berechtigungszertifikate, dessen In-
haber nicht zur Ausstellung weiterer Zertifikate berechtigt wird.
Um für einen Dienst, der sich über Berechtigungszertifikate gegenüber einer Karte ausweisen
möchte, einen fließenden Übergang zwischen Ablauf- und Startdatum zweier aufeinanderfol-
gender Zertifikate zu ermöglichen, überschneiden sich die Zertifikatsgültigkeiten der Wurzel-
zertifikate um einen kurzen Zeitraum
7
.
Die sich daraus ergebende Kette von Zertifikaten von einer CVCA zu einem Berechtigungszerti-
fikat ist in Abbildung 2.1 dargestellt. Die sich aus dem Überschneidungszeitraum der Zertifikate
ergebende Problematik für die Chipkarte beschreiben wir in Kapitel 2.3.7. Im Folgenden gehen
wir nun auf die Details der einzelnen Zertifikatsfelder ein.
Ein Berechtigungszertifikat besitzt eine Gültigkeit von ungefähr 3 Tagen, ein ,,Document Ve-
rifier" Zertifikat sollte nicht eine Gültigkeit von einem Monat und ein CVCA Zertifikat nicht
die Gültigkeit eines Jahres überschreiten. Die Gültigkeit des Zertifikats ist durch ein Start- und
ein Enddatum im Zertifikat kodiert. Neben der Gültigkeit ist der Name des Zertifikatsinhabers
im Feld ,,Certification Holder Reference" (CHR) kodiert. Falls das Zertifikat von einer CVCA
ausgestellt wurde und somit die beglaubigte Instanz weitere Zertifikate ausgeben darf, enthält
das Zertifikat einen öffentlichen Schlüssel, mit dem die von der Instanz ausgestellten Signaturen
überprüft werden können. Dabei werden der Algorithmus und die Domainparameter zur Erstel-
lung der Signatur verwendet, die im Zertifikat der CVCA ebenfalls im Feld des öffentlichen
Schlüssel definiert sind. Auch jedes Berechtigungszertifikat besitzt einen öffentlichen Schlüs-
sel, der in der ,,Terminal Authentisierung" dafür verwendet wird, den Besitz des Zertifikats zu
beweisen. Im Abschnitt ,,TA im elektronischen Personalausweis" auf Seite 24 gehen wir auf die
Validierung einer Zertifikatskette ein.
Der Name des Ausstellers ist im Feld ,,Certification Authority Reference" (CAR) kodiert, der
mit dem CHR des Zertifikats übereinstimmt. Dessen öffentlicher Schlüssel erstellt die Signatur
über das Zertifikat. Ein Zertifikat kann Zertifikatserweiterungen enthalten, die im wesentlichen
aus Signaturen über bestimmte Informationen bestehen. Die Zertifikatserweiterungen enthalten
beispielsweise die Signatur über die öffentlichen Schlüssel, die für die Restricted Identification
verwendet werden dürfen, oder Signaturen über weitere den Inhaber beschreibende Informatio-
nen. Die Felder der Zertifikatserweiterung werden nicht von der Karte validiert, sondern müssen
vom Terminal validiert werden, da die Karte das signierte Datum nicht kennt.
Das Certification Holder Authorization Template (CHAT)
8
definiert abhängig vom Anwen-
dungstyp die vom Aussteller erteilten Berechtigungen des Inhabers. Dies ist das einzige Feld,
welches die Anwendung (eID, ePassport, eSign) zu der das Zertifikat gehört und den ,,Typ"
im Folgenden bezeichnet als Rolle des Zertifikatsinhabers (CVCA, DV oder Berechtigungs-
zertifikat) definiert. Abhängig vom Anwendungstyp beschreiben wir in den folgenden Unterab-
schnitten den Aufbau der CHATs.
Da die Länge eines CVCA Zertifikats, das einen öffentlichen Schlüssel und die für den Si-
gnaturerstellungsalgorithmus notwendigen Domainparameter enthält, ungefähr 1 KByte groß
ist, muss die Karte ,,Extended Length APDU" unterstützen, die in der ISO 78164 definiert
sind[18].
7
Die Verteilung der neuen Zertifikate und die Erzeugung der von diesem Zertifikat abgeleiteten Zertifikate darf
nicht im voraus geschehen, da sonst der Zweck des Ersatzes einer Zertifikatssperrlistenprüfung entkräftet wäre.
8
Der Datentyp des CHATs ist dereinzige Datentyp der Zertifikatsfelder, welcher noch nicht in die ISO 7816 aufge-
nommen wurde.
15
2.3 EAC 2.0 konforme Ausweisdokumente
!"#$%
&
*
+ ,
- ./
+ ,
0
- ./
1* - 2 3
*
Abbildung 2.1: Schematische Darstellung der Zertifikate und Zertifikatsfelder. Ein Pfeil von
einem Zertifikatsfeld zu einem weiteren Zertifikatsfeld definiert den im Text
beschriebenen Zusammenhang dieser Felder. Eine geschweifte Klammer über
Zertifikatsfelder zeigt, welche Elemente von einem Schlüssel signiert werden.
Der zu der geschweiften Klammer führende Pfeil definiert entweder das Zerti-
fikatsfeld, das den Schlüssel zur Erstellung der Signatur enthält, oder das Zer-
tifikat, dass den Schlüssel enthält. Der von der geschweiften Klammer wegfüh-
rende Pfeil definiert das Zertifikatsfeld, in dem die Signatur gespeichert wird.
Für jedes Feld des Zertifikat existieren Regeln und Kodierungen, die in der TR03110 beschrie-
ben sind. Abbildung 2.1 zeigt eine Übersicht der Zertifikate und den Zusammenhang zwischen
den Feldern des Zertifikats.
ePassport CHAT
Der ePassport CHAT ist ein Byte lang. Darin kodieren die ersten beiden Bits die Rolle, die bei
der ePassportAnwendung ,,CVCA", ,,domestic DV", ,,foreign DV" und ,,Inspection System"
lauten. Der Typ der DV gibt an, ob die Karte ihre innere Uhr abhängig vom Berechtigungszer-
tifikat aktualisieren darf. In den darauffolgenden drei Bits kann im ePassport CHAT der Zugriff
auf die eIDAnwendung und die Berechtigung des Zugriffs auf die Iris und Fingerabdrücke be-
schränkt werden. Die übrigen drei Bits sind noch nicht fest definiert und werden für zukünftige
Zwecke reserviert.
eID CHAT
Der eID CHAT ist fünf Byte lang. Darin kodieren wie auch bei der ePassportAnwendung
die ersten beiden Bits die Rolle, die bei der eIDAnwendung ,,CVCA", ,,domestic DV", ,,non-
domestic/commercial DV" und ,,Authentication Terminal" lauten. Weiterhin enthält der CHAT
die Berechtigungen, ob bestimmte Datengruppen beschrieben (DG 17 bis 21, siehe [3]) oder
gelesen (DG 1 bis 21, siehe [3]) und welche der speziellen Funktionen benutzt werden dürfen.
Darin enthalten sind fünf Bits, die für zukünftige Zwecke reserviert sind.
2.3.6 Password Authenticated Connection Establishment
Ziel von PACE ist es, eine gesicherte Verbindung zwischen zwei Entitäten herzustellen, die nur
ein gemeinsames Geheimnis ein Passwort mit beliebiger Entropie kennen. PACE wurde
16
2.3.6 Password Authenticated Connection Establishment
1. A
B: c = E( f (Secret),n
A
) , D
2. B
A: P
1
B
= G r
1
B
3. A
B: P
1
A
= G r
1
A
4. B
A: P
2
B
= (G n
A
+ P
1
A
r
1
B
) r
2
B
5. A
B: P
2
A
= (G n
A
+ P
1
B
r
1
A
) r
2
A
6. B
A: s
B
= Sign(P
2
A
r
2
B
,P
2
A
)
7. A
B: s
A
= Sign(P
2
B
r
2
A
,P
2
B
)
8. A: Prüft, ob s
B
gleich Sign
(P
2
B
r
2
A
,P
2
A
)
9. B: Prüft, ob s
A
gleich Sign
(P
2
A
r
2
B
,P
2
B
)
Algorithmus 1: Password authenticated connection establishment
vom BSI im Jahre 2006 veröffentlicht[36]. Im Gegensatz zu existierenden Passwort-basierten-
Authentisierungsprotokollen, wie B-SPEKE[21], steht PACE nicht unter Patentschutz und kann
frei verwendet werden.
Im Folgenden beschreiben wir den Ablauf von PACE, der in 1 dargestellt ist, und beschrän-
ken uns auf die PACE Implementierung, die elliptische Kurven verwendet. Dabei setzen wir
grundlegende Kenntnisse der Kryptographie und elliptischen Kurven voraus[15]. Wir verwen-
den folgende Notation:
A
,B Teilnehmer des Protokolls, A ist der Initiator, B der Partner.
E
(x,y) Symmetrische Verschlüsselung von y mit dem Schlüssel x.
D
Die in der Protokollinstanz zu verwendenden elliptischen Kurven Parameter.
G
Basispunkt der verwendeten elliptischen Kurve.
f
(x) Eine beliebige unumkehrbare Abbildung.
n
x
Eine von der Entität x generierte Nonce.
r
n
x
Die n'te von der Entität x generierte Nonce.
P
n
x
Der n'te öffentliche Schlüssel der Entität x.
Sign
(x,y) Signatur von Text y mit dem Schlüssel x auf der elliptischen Kurven D.
X
y Skalare Multiplikation des elliptischen Punktes X mit y.
X
+Y Addition der elliptischen Punkte X und Y.
Im Schritt 1 sendet A eine Challenge zusammen mit den für den weiteren Protokollverlauf zu
verwendenden Domainparameter. Die Challenge ergibt sich aus der Nonce n
A
, die mit einem
sich aus dem gemeinsamen Geheimnis ergebenden Schlüssel symmetrisch verschlüsselt wird. B
kann die Challenge nur dann entschlüsseln, wenn B Kenntnis über das gemeinsame Geheimnis
hat.
Anschließend einigen sich A und B im Schritt 2 und 3 durch einen anonymen elliptischen
,,Diffie-Hellmann" (DH) unter Verwendung eines zufällig gewählten Geheimnisses r
1
A
bzw. r
1
B
auf ein gemeinsames Geheimnis K
1
= G r
1
B
r
1
A
. Wichtig hierbei ist die Tatsache, dass zwar
A und B K
1
berechnen können, allerdings nicht auf das Geheimnis des Partners schließen kön-
nen.
Auf Basis der im ersten Schritt übertragenen Nonce und dem gemeinsamen Geheimnis K
1
wird
nun ein weiterer anonymer elliptischer DH im Schritt 4 und 5 durchgeführt, dessen Basispunkt
sich aus der Summe: G'
= n
A
G + K
1
ergibt. Da jede zyklische Untergruppe einer Gruppe, die
eine Primzahlordnung hat, die gleiche Ordnung wie die ursprüngliche Gruppe besitzt[15], ist
17
2.3 EAC 2.0 konforme Ausweisdokumente
der Generator G genauso stark wie G.
Die geringe Entropie von n
A
, die sich direkt aus der Entropie des Geheimnisses ergibt, wirkt
sich durch den zweiten DH und die Kombination mit dem eigenen Zufall r
2
A
bzw. r
2
B
nicht auf
die Entropie der öffentlichen Schlüssel P
2
B
bzw. P
2
A
aus. Aus dem Punkt K
2
werden nun die
Schlüssel für die Verschlüsselung und Signatur erzeugt.
Im Schritt 6 und 7 tauschen A und B Signaturen mit den aus K
2
gewonnenen Schlüsseln aus,
um zu beweisen, dass sie das gemeinsame Geheimnis berechnen können.
Ziele von PACE
Nach Abschluss von PACE ist A überzeugt, dass es eine Entität B gibt, die mit A kommunizieren
will und B das PACE Geheimnis kennt. B ist überzeugt, dass A eine Entität ist, die das gleiche
Geheimnis kennt, dass B verwendet hat.
Für die weitere Kommunikation wurde für die Sitzung ein temporärer Schlüssel ausgehandelt,
der ausschließlich den Kommunikationspartnern bekannt ist. Somit ist PACE ein Key Agree-
ment Protokoll, welches Forward Secrecy leistet, da durch Kenntnis eines Sitzungsschlüssels
keine anderen Sitzungen entschlüsselt werden können.
Wenn die m-stellige Zufallszahl n
A
gleichverteilt auf dem Intervall 0
..2
m
- 1 ist, ist auch c
auf dem Intervall 0
..2
m
- 1 gleichverteilt, da die symmetrische Verschlüsselung als pseudo-
zufällige Abbildung angesehen werden kann. Somit ist es einem Angreifer durch Abhören eines
Protokollablaufs nicht möglich, Informationen über das verwendete Geheimnis zu beziehen
[36]. Ein Angreifer, der sich als Entität A oder B ausgibt, kann in jedem Protokollablauf nur
genau ein Geheimnis testen. Er kann keine Rückschlüsse auf eine Menge von Geheimnissen
ziehen, so dass das Protokoll ein ZeroKnowledgeProtokoll [36] ist.
Für das Protokoll werden derzeit formale Beweise erstellt, die zeigen, dass das Protokoll ,,si-
cher" ist und nicht durch bekannte Angriffe kompromittiert werden kann. Im Folgenden werden
wir zeigen, welche Auswirkungen eine fehlerhafte Implementierung des Protokolls haben kann
und definieren Angriffsvektoren, gegen die die Implementierung gesichert werden muss.
Angriff auf den Zufallsgenerator
Ein Angreifer kann das Ziel haben PACE erfolgreich abzuschließen, ohne das Geheimnis zu
kennen. Auch wenn angenommen wird, dass PACE zu der Klasse der ZeroKnowledgePro-
tokollen gehört
9
, ist zu überprüfen, ob über die verschlüsselte Nonce unter bestimmten Bedin-
gungen Informationen auf das Geheimnis geschlossen werden könnte.
Ein Angreifer kann, solange er die Nonce nicht zufällig errät, durch Abhören der Challenge
zunächst nicht direkt auf das PACE Geheimnis schließen, da die Nonce selbst eine zufällige
Zeichenfolge ist, ist auch die zugehörige verschlüsselete Nonce -- die Challenge -- eine zu-
fällige Zeichenfolge. Besitzt der Angreifer aber bestimmte Informationen über den Aufbau der
Nonce, könnte ein Angreifer das Geheimnis durch BruteForce finden.
Abbildung 2.2 zeigt den Abbildungsprozess einer Challenge auf eine Nonce. Ein unzuverläs-
siger Zufallsgenerators bildet häufiger (im Sinne einer höheren Wahrscheinlichkeit) auf eine
Teilmenge der Nonces ab, die hier als hellblaue Teilmenge dargestellt sind. Durch Berechnung
9
Diese Aussage ist erst nach Abschluss des formalen Beweis möglich.
18
Ende der Leseprobe aus 100 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2009, Chipkartensoftware: Die Entwicklung einer Prüfstrategie für elektronische Ausweisdokumente, Hamburg, Bedey Media GmbH, https://www.bachelor-master-publishing.de/document/296668
Kommentare