Leitfaden für die Erstellung von Javacard Programmen für das Praktikum

Transkript

1 Leitfaden für die Erstellung von Javacard Programmen für das Praktikum Lehrstuhl für Softwaretechnik und Programmiersprachen WS Überblick Dieser Leitfaden soll für Sie eine Anleitung darstellen, wie Dokumentation und Programme im Rahmen des Javacard Praktikums zu erstellen sind. Zunächst werden programmiertechnische Hinweise gegeben, der Hauptteil dieses Leitfadens konzentriert sich auf die Erstellung von Dokumentationen zu Ihrem Kommunikationsprotokoll. 2 Generelles zur Programmierung Gute Programme zeichnen sich durch eine Reihe von Gesichtspunkten aus, auf die im Folgenden eingegangen werden soll. Bitte beachten Sie, dass dieser Leitfaden die Gesichtspunkte aufführt, die für Ihre Programme als Minimalanforderungen zu verstehen sind. Abgaben, die diesen Requirements nicht folgen, werden mit Abzügen bewertet. Gute und sehr gute Abgaben zeichnen sich u.a. dadurch aus, über diese Anforderungen hinaus zu gehen. 2.1 JavaDoc und Kommentare Kommentieren Sie Ihren Code. Sämtliche Methoden (insbesondere diejenigen, die für die Anwendungslogik verantwortlich sind) sollten mit JavaDoc-Kommentaren versehen sein. Sie sollten insbesondere zu jeder Methode den Autor vermerken. Eine vollständige HTML API- Dokumentation ist Pflichtbestandteil jeder Abgabe. An Stellen, an denen dies nötig ist, sollten Sie auch Inline-Kommentare verwenden. 2.2 Magic Numbers Sie sollten keine Zahlen mitten in Ihrem Programmcode verwenden. Beispiel: byte x = (byte) buffer[ * y]; if (x == 0xFC && z << 1 == 0xF0) { System.out.println("Fehler"); Solcher Code ist völlig unleserlich und fehleranfallig. Verwenden Sie statt dessen Konstanten und wenn nötig Kommentare. 1

2 2.3 Naming Variablenbezeichner sollen aussagekräftige Namen haben. Bitte nicht so: byte a = (byte) buffer[x]; byte b = (byte) buffer[y]; if(a == k) {... } Bitte aber auch nicht unbedingt so: byte thisisthefirstparameter = (byte) buffer[thisistheoffsetforthefirstparameter]; byte thisisthesecondparameter = (byte) buffer[thisistheoffsetforthesecondparameter]; if(thisisthefirstparameter = thisistheexpectedparameter) {...} 2.4 Objektorientierung Nutzen Sie die OO-Konzepte, die Java bietet. Z.B. könnten Sie an Grenzen zwischen verschiedenen Teilen der Implementierung Interfaces benutzen. Wenn Sie zwei Klassen mit ähnlicher Funktionalität haben, sollten Sie eine abstrakte Oberklasse benutzen und keinen Code duplizieren. Kodieren Sie keine Real-World-Konzepte (ausser natürlich zur Übertragung an die Karte) in primitiven Datentypen (z.b. erste vier bit eines Integers bedeuten X, zweite vier bit bedeuten Y). Verwenden Sie statt dessen eine Klasse und sehen Sie Methoden vor, die diese Klasse in Ihre Übertragungsform konvertieren. 2.5 Benutzbarkeit Ihre Terminal-Programme sollten robust und sicher gegen (absichtliche oder unabsichtliche) Fehlbenutzung sein. Überlegen Sie Z.B., wie Ihre Teminal (und Ihre Karte) reagieren sollen, wenn die Karte zum falschen Zeitpunkt herausgezogen wird. Alle Terminalfunktionen sollten in der jeweiligen GUI übersichtlich und intuitiv benutzbar dargestellt sein. Ein Terminal, für das man zuerst ein Handbuch konsultieren muss, ist ein schlechtes Terminal. Verwenden Sie (falls es wirklich angemessen sein sollte) Wizards. 2.6 GUI-Programmierung Ihre GUI sollte unabhängig von Ihrer Applikationslogik sein. Schreiben Sie keinesfalls Logik für die Kommunikation und Protokollabwicklung in GUI-Klassen (z.b. direkt in eine actionperformed-methode). Sehen Sie in Ihrem Design eine klare GUI-zu-Logik Schnittstelle vor. Des Weiteren sollte Ihre GUI nicht hängen, wenn die Kommunikation mit der Karte abgewickelt wird. Verwenden Sie daher mehrere Threads. 3 Dokumentation des Protokolls Eine Protokoll-Spezifikation für ein Chipkarten-Applet soll dessen Funktionsweise und den Protokollablauf zwischen allen Beteiligten (Karte(n), Terminals, evtl. weitere Server) definieren. 2

3 Ihre Spezifikation sollte als Grundlage für Ihre Implementierung dienen und sollte daher grundsätzlich vor Beginn derselben abgeschlossen und mit den Betreuern besprochen sein. In diesem Sinne wird erwartet, dass Ihre Spezifikation auch einem fremden Programmierer als Grundlage seiner Arbeit dienen kann und damit selbsterklärend und vollständig sein sollte. Die Erfahrung zeigt, dass die Implementierung des Programms wesentlich leichter ist, wenn man sich im Voraus auf Datenformate, Arraypositionen und Ähnliches geeinigt hat. Grundsätzlich gilt, dass bei Abgabe einer Aufgabe die Spezifikation und die Implementierung vollständig zueinander konsistent sein sollten. Wenn Sie bei der späteren Programmierung feststellen, dass Ihre Spezifikation unzureichend war, ändern Sie diese bitte ebenfalls entsprechend ab. Die Konsistenz zum Programm, die Exaktheit und Verständlichkeit sowie die Form Ihrer Spezifikation sind neben der Implementierung eine weitere Grundlage für die Bewertung Ihrer Abgaben. Als Format für Ihre Spezifikation ist Postscript, PDF oder Word/Openoffice erlaubt. Aufgrund der erfahrungsgemäß schlechten Lesbarkeit sind Abgaben als.txt nicht zulässig. Abschnitt 5 dieses Leitfadens dient als Muster, wie Ihre Spezifikation aussehen soll und welche Daten sie enthalten muß. Es steht Ihnen natürlich frei, zusätzliche Angaben zu machen, wenn Sie der Meinung sind, diese seien für das Verständnis erforderlich. 4 Aufbau Bitte halten Sie sich bei der Erstellung Ihrer Spezifikation an den folgenden Aufbau: 1. Textuelle Beschreibung Ihres Programms 2. Kommunikationsprotokoll 3. Instructions und Datentypen 4. APDU-Beschreibungen und Kartenimplementierung 4.1 Textuelle Beschreibung Ihres Programms Beschreiben Sie kurz, was Ihr Programm leistet und vor allem welche zusätzlichen Annahmen und Festlegungen Sie über die Aufgabenstellung hinaus selbstständig getroffen haben. Gehen Sie kurz auf die Funktionsweise Ihres Terminals ein und beschreiben Sie, unter welchem Szenario ein Einsatz Ihres Programms auf Karte und Terminal denkbar ist (z.b. nur sinnvoll, wenn kein Zugriff auf den Chipkartenleser während der Benutzung möglich ist, etwa wie bei einem Bankautomat). Beschreiben Sie des Weiteren technische Vorraussetzungen Ihres Programms. In diese Kategorie fallen z.b. die evtl. verwendeten Kryptographie-Verfahren und die dazugehörigen Schlüssellängen, die gewählte Länge von Zufallszahlen und Ähnliches. Geben Sie zusätzlich Namen, Applet AID und Package AID an. 4.2 Kommunikationsprotokoll In diesem Abschnitt wird ein Überblick über den Protokollablauf (also sämtliche Kommunikation zwischen den Teilnehmern) erwartet. 3

4 Verwenden Sie bitte bei der Beschreibung Ihrer Nachrichten symbolische Namen für die einzelnen Nachrichtenteile (Instructions, Parameter und Daten) und definieren Sie diese im darauf folgenden Abnschitt Instructions und Datentypen. Ein Einfügen der Behandlung von Fehlerfällen in der folgenden Beschreibung würde die Lesbarkeit enorm verschlechtern. Stellen Sie Ihr Protokoll deshalb so dar, wie es bei einem Kommunikationsablauf funktionieren würde, der keine Fehler enthält. Auf die Behandlung von Fehlern soll erst im nächsten Abschnitt (APDU-Beschreibungen und Kartenimplementierung) eingegangen werden. Es bietet sich die folgende tabellarische Form an (hier für ein Terminal und die Karte): Protokollablauf für einen Rateversuch bei Mastermind Schritt Terminal Karte 1. enter GUESS TRY + GUESS check the GUESS compute ANSWER 2. display ANSWER ANSWER Stellen Sie in der jeweiligen Spalte für die Protokollteilnehmer knapp aber genau dar, welche zusätzlichen Eingaben (z.b. vom Benutzer), Ausgaben (z.b. an den Benutzer) und welche Überprüfungen und Berechnungen stattfinden sollen. In den Spalten zwischen den Protokollteilnehmern geben Sie die verschickten Nachrichten zwischen diesen an. Verwenden Sie ein + für die Konkatenation zweier Nachrichtenteile. Beachten Sie, dass die Kommunikation bei einem Chipkartenterminal (bedingt durch die Funktionsweise von Chipkarten) immer abwechselnd in beide Richtungen erfolgen muss. Im Anschluss an diese tabellarische Auflistung des Protokollablaufs sollten Sie textuell erläutern, warum das dargestellte Protokoll den jeweiligen Anforderungen der Aufgabe genügt und dabei evtl. auch Besonderheiten und wichtige Punkte, die bei Ihrem Protokoll von Belang sind, hervorheben. Für die Notation der Kryptographie verwenden Sie bitte die folgenden Konventionen: E(term card server)[data] = Verschlüsseln des Datensatzes data mit dem public key von Terminal Karte Server. (asymmetrisch) D(term card server)[data] = Entschlüsseln des Datensatzes data mit dem private key von Terminal Karte Server. (asymmetrisch) ES(SK)[data] = Verschlüsseln des Datensatzes data mit dem Sessionkey SK. (symmetrisch) DS(SK)[data] = Entschlüsseln des Datensatzes data mit dem Sessionkey SK. (symmetrisch) S(term card server)[data] = Signatur des Datensatzes data ausgestellt von Terminal Karte Server. H[data] = Hash-Wert des Datensatzes data. N1, N2,... = Zufallszahlen (engl. nonces) 4

5 4.3 Instructions und Datentypen Definieren Sie nun die symbolischen Namen für Ihre Instruction-Bytes und evtl. für weitere Konstanten, die Ihr Protokoll verwendet. Diese Instructions und Konstanten sollten dann natürlich auch im Code in passender Form verwendet werden. Beispiel: Konstanten Name Wert intuitive Semantik START GAME 0x06 Beginn eines neuen Spiels TRY Wenn Sie in Ihrem Applet spezielle Array-Repräsentationen für bestimmte Datentypen verwenden, so geben Sie deren Definition an. Beispiel: spezielle Datentypen Datentyp Beschreibung Repräsentation GUESS Rateversuch für Mastermind Byte 0 Byte 1 Byte 2 Byte 3 X1 X2 X3 X4 Bedeutung: In X1..X4 stehen Kodierungen für die geratenen Farben an den jeweiligen Stellen (0x01 = rot, 0x02 = grün,...) ANSWER 4.4 APDU-Beschreibungen und Kartenimplementierung In diesem Abschnitt sollen Sie nun die verwendeten APDUs und das jeweils zugehörige Verhalten der Karte genau spezifizieren. Beschreiben Sie dazu zunächst kurz die Implementierung Ihres Applets, indem Sie die für die folgenden Beschreibungen relevanten Felder angeben und Ihre Semantik kurz beschreiben. Beispiel: Feld Semantik byte guesscount Anzahl der Rateversuche des Spielers Für die Select -APDU geben Sie bitte an, in welchem Zustand sich Ihr Applet nach Erhalt eines Selects befindet. Für die Install -APDU geben Sie zusätzlich noch die übergebenen Initialisierungsparameter und mögliche Fehlerfälle an (sh. Abschnitt 5). Für die APDUs Ihres Protokolls werden die folgenden Angaben erwartet: 1. Name des Instruction-Bytes Machen Sie zusätzlich Verweise auf die Stellen, an denen diese Instruction in einem Protokollschritt verwendet wird. 5

6 2. Beschreibung der APDU Geben Sie eine exakte Beschreibung des Aufbaus der an die Karte übermittelten APDU. 3. Überprüfungen und Berechnungen Beschreiben Sie sämtliche Vorgänge, die auf der Karte nach Erhalt dieser APDU durchgeführt werden (unter Bezugnahme auf Ihre gerade definierten Felder und die jeweiligen Daten). Die Art der Beschreibung bleibt hierbei Ihnen überlassen (textuell, mittels logischer Formeln, semi-formal,...), solange klar ersichtlich ist, was gemeint ist. 4. Behandlung des Normalfalls (a) Response-APDU Beschreiben Sie die Response-APDU, die verschickt wird, wenn die Überprüfungen dem intuitiven Normalfall entsprachen. (b) resultierender Kartenzustand Beschreiben Sie möglichst genau, was der Zustand der Karte nach Verschicken der Response-APDU ist. 5. Behandlung von Fehlerfällen und Ausnahmen Beschreiben Sie sämtliche Fehlerfälle und Ausnahmen. Gehen Sie dabei jeweils analog zur Beschreibung des Normalfalls vor. Beispiel: APDU: Protokollschritt TRY (verwendet im Protokoll Rateversuch in Schritt 1.) CMD INS P1 P2 LC DATA LE 0x90 TRY 0x00 0x00 0x04 GUESS 0x04 1. Überprüfungen und Berechnungen: (a) prüfe LC == 0x04 LC == #(data) (b) prüfe, ob GUESS[0..3] gültige Codierungen für einen Rateversuch sind ( i : i 0 i 3 GUESS[i] 0 GUESS[i] 5) (c) berechne ANSWER =..., falls Normalfall: (a) Response-APDU: Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 ANSWER SW OK (b) resultierender Kartenzustand: trycount++, falls

7 3. Fehlerfälle und Ausnahmen: (a) falls #(data) 4 #(data) LC : i. Response-APDU: Byte 0 Byte 1 SW WRONG LENGTH ii. resultierender Kartenzustand: (b) falls

8 5 Template für eine Spezifikation 5.1 Beschreibung Generelles Name des Applets: Applet AID Package AID Funktionalität Verwendete technische Verfahren Getroffene Annahmen 5.2 Kommunikationsprotokoll Protokollablauf... Name: Anmerkungen: Schritt Terminal Karte

9 5.2.2 Protokollablauf... Name: Anmerkungen: Schritt Server Terminal Karte Protokollablauf Instructions und Datentypen Konstanten Name Bytewert intuitive Semantik Abkürzungen für komplexe Datentypen Datentyp Beschreibung Repräsentation Byte 0 Byte n b 0 b n Semantik: Byte 0 Byte n b 0 b n Semantik: 5.4 APDU-Beschreibungen und Kartenimplementierung Wichtige Felder des Applets Feld Semantik INSTALL und SELECT INSTALL 9

10 Art und Struktur der Parameter Byte 0... Byte n b 0... b n resultierender Kartenzustand:... Fehlerfälle: 1. falls... : (a) Response-APDU: Byte 0... Byte n b 0... b n (b) resultierender Kartenzustand: 2. falls resultierender Kartenzustand: SELECT Applikationsprotokoll APDU: Protokollschritt... (verwendet im Protokollablauf... in Schritt...) CMD INS P1 P2 LC DATA LE 0xXX 0xXX 0xXX 0xXX 0xXX XY 0xXX 1. Überprüfungen und Berechnungen: 10

11 (a) prüfe (b) berechne (c) Normalfall: (a) Response-APDU: Byte 0... Byte b b 0... b n (b) resultierender Kartenzustand: Fehlerfälle und Ausnahmen: (a) falls... : i. Response-APDU: Byte 0... Byte n b 0... b n ii. resultierender Kartenzustand: (b) falls