Prüfstrategie für Chipkartensoftware von Ausweisdokumenten

Inhaltsverzeichnis

Einleitung

1 Software-Qualitätssicherung
1.1 Qualitätsmanagement
1.2 Qualitätsmanagementmodell des V-Modell
1.3 Prozesse der Qualitätssicherung

2 Chipkarte als Ausweisdokument
2.1 Chipkarten und RFID
2.1.1 Bedrohungsszenarien für kontaktlose Chipkarten .
2.2 Sicherheitsmechanismen nach EAC 1.11
2.3 EAC 2.0 konforme Ausweisdokumente
2.3.1 Elektronische Authentisierung
2.3.2 ePassport-Anwendung
2.3.3 eID-Anwendung
2.3.4 eSign-Anwendung
2.3.5 Zertifikate
2.3.6 Password Authenticated Connection Establishment
2.3.7 Terminal Authentication
2.3.8 Chip Authentication
2.3.9 Restricted Identification

3 Prüfmethoden
3.1 Statische Prüfmethoden
3.2 Dynamische Prüfmethoden
3.2.1 Strukturorientierte Prüfmethoden
3.2.2 Funktionsorientierte Prüfmethoden
3.2.2.1 Partitions-Test
3.2.2.2 Klassifikationsbaummethode
3.2.2.3 Erweiterungen der Klassifikationsbaummethode
3.2.2.4 Zustandsbezogener Test
3.3 Diversifizierende Prüfmethode
3.4 Diskussion

4 Prüfstrategie für die Entwicklung von funktionalen Systemtests
4.1 Merkmale des Prüflings
4.1.1 Untersuchung des Eingaberaumes
4.1.2 Chipkartenbetriebssystem abhängige Implementierungsunterschiede
4.2 Prüfstrategie
4.2.1 Identifikation der Prüfobjekte
4.2.2 Prozessbeschreibung der Prüfung eines Prüfobjekts
4.3 Bewertungsmöglichkeiten
4.4 Vorteile gegenüber anforderungsbasiertem Test

5 Anwendung der Systematik auf Chipkartensoftware von Ausweisdokumente
5.1 Probleme der Testfalldurchführung
5.2 Prüfobjektidentifizierung
5.3 Modellierung und Testfallableitung der Prüfobjekte
5.3.1 PACE
5.3.1.1 Verbindungssicht
5.3.1.2 Detailsicht
5.3.2 Zertifikateinspielung
5.3.2.1 Verbindungssicht
5.3.2.2 Detailsicht
5.3.3 TA/Aux
5.3.3.1 Verbindungssicht
5.3.3.2 Detailsicht
5.3.4 CA
5.3.4.1 Verbindungssicht
5.3.4.2 Detailsicht
5.3.5 Dienstberechtigung
5.3.5.1 Verbindungssicht
5.3.5.2 Detailsicht

6 Erfahrungsbasierter Systemtest
6.1 Systematik
6.2 Analyse der Testfälle

7 Vergleich
7.1 Vergleich der Abdeckungsqualität
7.2 Vergleich des Aufwands und Wartbarkeit .
7.3 Zusammenfassung und Ausblick

Anhang
A Algorithmus zur Erzeugung von Testimplementierung aus Klassifikationsbäumen
B Zertifikatgenerator
C Beschreibung des Werkzeugs CTE-Export

Glossar

Abbildungsverzeichnis

1.1 Teststufen und Testaktivitäten des V-Modell
1.2 Effekt unterschiedlicher Systemansichten

2.1 Schematische Darstellung der Zertifikate und Zertifikatsfelder .
2.2 Nonce Verschlüsselung mit unzuverlässigem Zufallsgenerator .
2.3 Versuchsauswertung mit unzuverlässigem Zufallsgenerator
2.4 Überschneidungszeiträume von Zertifikaten

3.1 Prüfmethodenklassifikation nach Liggesmeyer
3.2 Unterschiedliche Modelle erzeugen unterschiedliche Vorgehen .
3.3 Strukturelle Elemente eines Klassifikationsbaums
3.4 Beispiel eines Klassifikationsbaums
3.5 Modellierung eines Prüfobjekts
3.6 Beispiel Schema Version 1
3.7 Beispiel Schema Version 2
3.8 Beispiel Schema Version 3
3.9 Testmodell und äquivalentes System
3.10 Positivtest in einem Zustandsautomaten
3.11 Zusammenhang zwischen Testfallanzahl und Überdeckungsrate

4.1 Zustandsmodellierung der Authentisierung
4.2 Eingaberaum eines elektronischen Ausweisdokuments
4.3 Übersicht des Eingaberaums
4.4 Vergleich der Berechtigungsprüfmechanismen
4.5 Zertifikat Klassifikationsbaum
4.6 Attribute für die Erzeugung einer Testimplementierung

5.1 Übersicht Prüfobjekte
5.2 Verbindungssicht PACE
5.3 Ausschnitt der Detailsicht PACE
5.4 Verbindungssicht Zertifikateinspielung
5.5 Klassifikationsbaum der Zertifikate
5.6 Verbindungssicht CA
5.7 Verbindungssicht Dienstberechtigung

6.1 Anteile der Testkategorien im erfahrungsbasierten Systemtest

A Beispiel der Verwendung der Generatorschnittstelle

B Klassendiagramm eines generischen Zertifikatgenerators

C Zertifikatswizard

Zusammenfassung

Chipkartensoftware von elektronischen Ausweisdokumenten darf aufgrund der hohen Sicher- heitsanforderungen nicht nachträglich veränderbar sein und muss daher eine höhere Qualität als Computersoftware besitzen, weil Fehler nicht durch das Einspielen von Updates korrigierbar sind, sondern nur durch Rückruf und Austausch behoben werden können. Die hohen Qualitäts- ziele, die daher an Chipkartensoftware gestellt werden, können nur durch intensive Prüfung ab- gesichert werden. In der vorliegenden Arbeit entwerfen wir eine Prüfstrategie, die besonders auf die spezifischen Eigenschaften der Chipkartensoftware von elektronischen Ausweisdokumen- ten eingeht, mittels derer sich funktionale Systemtests aus einem Lastenheft (Spezifikation des Auftraggebers) ableiten lassen. Diese Prüfstrategie wenden wir auf die technische Spezifikation des neuen elektronischen Personalausweises an und vergleichen den resultierenden funktiona- len Systemtest mit einem für den elektronischen Personalausweis konzipierten Systemtest, der erfahrungsbasiert entwickelt wurde.

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 TR-031103, die Anforderungen und Protokolle beinhaltet, auf deren Grundlage sichere maschinenlesbare Ausweisdokumente zu erstellen sind. Die Menge der dadurch entstehenden Anforderungen und Pflichten 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 Sicherheitsanforderungen 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 Komplexitätsprofil der Software entschieden werden.24

Dieses Problem trifft insbesondere auf die Eigenschaften und Anforderungen zu, die elektronische 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 Ausweisdokument beschädigen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Aufbau der Arbeit

In der vorliegenden Arbeit werden wir die Eigenschaften von Chipkartensoftware für Ausweis- dokumente analysieren und auf Basis dieser Spezifikationen eine systematische Prüfstrategie 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 Softwareentwicklung 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 ordnen 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 Anforderungen und Protokolle, die sichere Ausweisdokumente umsetzen.

Im dritten Kapitel vergleichen wir verschiedene Prüfmethoden, die sich in der Qualitätssicherung 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 Systemtest4, der erfahrungsbasiert 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 jeweiligen Methodologien auf.

1 Software-Qualitätssicherung

Das klassische Vorgehensmodell der Softwareentwicklung teilt ein Projekt in sieben Phasen: Planung, Definition, Entwurf, Implementierung, Test, Einsatz und Wartung. In der Planungsund 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 Budget14. In der Konsequenz wurden diese nur unvollständig umgesetzt oder sogar vorzeitig 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 Selbsteinschätzungen von 365 befragten Unternehmen ableiteten. Im Folgenden zeigen wir eine Auswahl der wichtigsten Gründe für das Fehlschlagen von Softwareprojekten:¹

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 aufzudecken14.

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- 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 Projekt mit festen Rahmenbedingungen und bereits konkreten Anforderungen könnte die agile Umsetzung 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 Softwarequalität - überprüfen oder sicherstellen, gehören zu der Qualitätssicherung. Die Qualitätssicherung verwendet die Techniken Analyse, Verifikation und Test, um die Softwarequalität zu messen und Fehler zu finden35.

- 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 existiert, 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 Test25.

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 Fehler30. 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.

Das Qualitätsmanagement plant und bestimmt die Qualitätssicherungsprozesse eines Softwareprojekts. 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 Arbeit 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 schaden33 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 Verwendung einer Prüfstrategie durchgeführt. Eine Prüfstrategie besteht aus Prüfmethoden, deren Auswahl von den spezifischen Eigenschaften des Prüflings abhängt24.

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 Programmierer32 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 und hat somit direkte Auswirkung auf die Qualität dieser. Außerdem beeinflusst die Prüfstrategie den Aufwand, der für die Prüfung notwendig ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Teststufen und Testaktivitäten des V-Modell

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 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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.2: Effekt unterschiedlicher Systemansichten.

1.3 Prozesse der Qualitätssicherung

Jede Prüfung beginnt mit der Anforderungsanalyse, in der das Team der Qualitätssicherung unter Verwendung der vom Qualitätsmangement vorgegebenen Methodologien und Werkzeugen die vorhandenen Spezifikationen nachvollzieht und auf Testbarkeit überprüft. Es findet ein erster 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 Wissens 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. Abbildung 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 Vorgehensweisen 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.

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 Abschä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 ist31. 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.

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 auszuweiten28.

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 Kontoeröffnung erklären, um daraus die Prozesse abzuleiten, die in einem elektronischen Ausweisdokument umgesetzt werden müssen. Für die Kontoeröffnung benötigt die Bank eine Bestätigung der Identität des zukünftigen Kontoinhabers, die in der Regel mit einem Ausweis durchgeführt wird. Der Prozess der Identitätsbestätigung und -überprüfung wird als Authentisierung bezeichnet28. 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 verhindert 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¹. 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², 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 ³ 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 930316 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 (TR-03110 - EAC 1.11) vom BSI definiert, die die Details des deutschen elektronischen Reisepasses festlegt. Die Version 2 der „Extended Access Control“ wurde in der „TR-03110 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 Paketformat18. Diese Informationen können aus der TR- 03110 bezogen werden.

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 zwischen Lesegerät (in diesem Fall eine Telefonzelle) und Kontaktflächen der Karte dienen der Stromversorgung des Chips und der Kommunikation zwischen Terminal und Chip. Chipkarten, 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 worden sein, woraus sich der Erfolg der Chipkarten ableiten lässt. Für eine detaillierte historische Betrachtung der Entwicklung der Chipkarten siehe33.

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ährt9.

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 Sicherheitsobjekts existieren drei Ansätze:

1. Das Terminal sendet das Sicherheitsobjekt über einen hinreichend sicheren Kanal an die 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 (Zero-Knowledge-Pro- 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 Zero-Knowledge-Protokollen 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ückschlü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 beschreibbaren Speicher der Karte gibt es Angriffe die darauf abzielen die Authentisierungsmechanismen zu umgehen und Zugriff auf sensible Daten zu erlangen, indem gezielt Chiptransistoren oder -leitungen manipuliert werden.2

Weiterhin könnten beliebige physikalische Angriffe die Bestandteile der Chipkarte derartig beeinflussen, dass sie unzuverlässig arbeiten. Insbesondere für den in einer Chipkarte befindlichen Zufallsgenerator muss sichergestellt werden, dass die Zuverlässigkeit nicht durch derartige Angriffe beeinflusst werden kann. Ein Beispiel für die Konsequenz eines unzuverlässigen Zufallsgenerators 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 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 sei34. 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 erachtet7.

Anfang 2006 ist eine Sicherheitslücke in dem Konzept der Schlüsselgenerierung gefunden worden. 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 sind38. So kann das Protokoll eines abgehörten Dialogs zwischen Lesegerät und Karte innerhalb weniger Stunden durch Brute-Force entschlüsselt werden, ohne dass weitere Informationen über den Ausweisinhaber notwendig sind⁴. Das Mithören der Kommunikation zwischen Lesegerät und Pass ist aus eine Distanz von bis zu 10 Meter durchführbar⁵. 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 Chipgeschwindigkeit beschränkt wird.
- Mittleres Sicherheitsniveau gegen passives Mitlesen, wenn keine zusätzlichen Informationen ü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- zuverfolgenden Person versucht wird, zu jedem in der Nähe befindlichen Reisepass eine Verbindung herzustellen.

2.3 EAC 2.0 konforme Ausweisdokumente

EAC 2.0 umfasst die Spezifikation von drei Anwendungen: Die ePassport-, eID- und eSign-An- 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 stellige 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 Ziffernfolge, 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 Kommunikation 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 gespeichert. Abhängig von der Anwendung, die ein Terminal verwendet, können bestimmte personenbezogene 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 Zero-Knowledge-Protokollen 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 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 ePassport-Anwendung

Die ePassport-Anwendung 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 eID-Anwendung

Die eID-Anwendung kann über das Internet von nicht-öffentlichen und öffentlichen Diensten verwendet werden. Nachdem ein Dienst unter Verwendung der PIN oder CAN eine sichere Verbindung aufgebaut hat und die elektronische Authentisierung abgeschlossen ist, kann ein Dienst ebenfalls bestimmte Datengruppen auslesen. Der Unterschied besteht in den Berechtigungsdetails der Zertifikate. Ein eID-Dienst kann gezielt für bestimmte Funktionalitäten freigeschaltet werden, um beispielsweise lediglich ein einziges Datum auszulesen.

Zusätzlich besitzt die eID-Anwendung 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⁶ 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 eID-Dienst 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.

In der eID-Anwendung können Signaturen für die eSign-Anwendung installiert werden. Da wir die eSign-Anwendung im Rahmen dieser Arbeit nicht untersuchen, verweisen wir an dieser Stelle für nähere Informationen zu den eSign spezifischen Funktionalitäten der eID-Anwen- dung auf die TR-03110 und die technische Richtlinie TR-031176.

2.3.4 eSign-Anwendung

Mit der eSign-Anwendung 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 Berechtigungszertifikate, 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 TR-03110 beinhaltet zu einer Anwendung die spezifischen Berechtigungen, die sie von einer zur Zertifikatsausstellung legitimierten Instanz (im Folgenden „Aussteller“) erhalten hat. Diese Berechtigungen definieren sowohl Datengruppen, die ausgelesen 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 besitzt17, 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 CV-Zertifikate ist Bestandteil der ISO 7816-819. Die Hierarchie der Aussteller, sowie die anwendungsspezifischen Informationen sind in der TR-03110 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ültigkeitszeiträume gelöst. Ein Zertifikat besitzt daher eine begrenzte Gültigkeit, so dass jeder Zertifikatsinhaber 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 innerhalb seiner Zertifikatgültigkeit liegen (Schalenmodell, siehe39 ).

Die Hierarchie der Aussteller ist in der TR-03110 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 beantragen. Die von der DV ausgestellten Zertifikate sind Berechtigungszertifikate, dessen Inhaber nicht zur Ausstellung weiterer Zertifikate berechtigt wird.

[...]

---

¹ 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 Involvement“; (3) „Changing Requirements & Specifications“, „Changing Requirements & Specifications“; (4) „Unrealistic Expectations“, “Unclear Objectives“

¹ 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.

² Seit dem 1. November 2007 sind Fingerabdrücke im elektronischen Reisepass Pflicht.

³ Stand 10.03.2009.

⁴ http://www.heise.de/tp/r4/artikel/21/21907/1.html

⁵ http://www.riscure.com/contact/privacy-issue-in-electronic-passport.html

⁶ Die vierstellige Behördenkennzahl definiert die Meldestelle, in der der Ausweisinhaber gemeldet ist.