Effiziente Implementierung des PACE- und EAC-Protokolls für mobile Geräte

Transkript

1 Effiziente Implementierung des PACE- und EAC-Protokolls für mobile Geräte Bachelor-Thesis von Franziskus Kiefer Fachbereich Informatik Kryptographie und Computeralgebra Betreuer Prof. Dr. Johannes Buchmann (TUD - CDC) Dr. Alex Wiesmaier (TUD - CDC) Falko Strenzke (FlexSecure GmbH & TUD - CDC)

2 i

3 Erklärung zur Bachelor-Thesis Hiermit versichere ich die vorliegende Bachelor-Thesis ohne Hilfe Dritter, nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die den angegebenen Quellen entnommen wurden, sind als solche kenntlich gemacht. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Darmstadt, den Franziskus Kiefer ii

4 iii

5 An dieser Stelle möchte ich allen danken, die durch fachliche und persönliche Unterstützung zum gelingen dieser Arbeit beigetragen haben. Dabei möchte ich mich ganz herzlich bei Moritz Horsch und Manuel Hartl (Flexsecure GmbH) bedanken, die mir bei mir vielen Fragen weitergeholfen haben. Ebenfalls bedanke ich mich bei den beiden Betreuern dieser Arbeit Falko Strenzke und Dr.-Ing. Alex Wiesmaier, sowie Prof. Dr. J. A. Buchmann für die Möglichkeit diese Arbeit zu Verfassen. Weiterhin möchte ich mich bei Denise Plocinik, Christian Fritz und Daniel Reker für das Korrekturlesen bedanken. iv

6 v

7 Zusammenfassung Elektronische Identitäten werden in unserer Gesellschaft immer wichtiger. Mit der Einführung des neuen Personalausweises in Deutschland ergeben sich zahlreiche neue Einsatzgebiete für die elektronische Identität. Eines dieser Gebiete ist zweifellos die Nutzung des neuen digitalen Identitätsnachweises im Zusammenhang mit mobilen Endgeräten. Die Verbreitung mobiler Endgeräte, deren Leistungsspektren immer mehr an die eines normalen PCs heranreichen, steigt enorm. In dieser Arbeit wird der Anwendungsfall einer Onlineauthentisierung mit einem Webservice betrachtet. Zur Nutzung dieser Funktion mit einem mobilen Endgerät ist eine NFC-Schnittstelle für die Verbindung mit dem Personalausweis, ein eid-server zum Auslesen der Daten des Ausweises und eine Applikation auf dem mobilen Endgerät, welche die Kommunikation mit dem Personalausweis und dem eid-server organisiert, nötig. Diese Applikation, der eid-client, wird im Rahmen dieser Arbeit entwickelt und als Midlet 1 implementiert. Eine Herausforderung bei der Implementierung der notwendigen Protokolle für diese Anwendung ist die Effizienz, weil die Protokolle auf rechenintensiver Kryptographie auf elliptischen Kurven basieren basieren. Hinzu kommt, dass das PACE-Protokoll zum Verbindungsaufbau zwischen Personalausweis und Lesegerät mit sieben Kontaktpunkten kein besonders effizientes Protokoll ist. Zusätzlich ist eine Implementierung in JAVA, im Vergleich zu anderen Sprachen, relativ langsam ist. Trotzdem wird JAVA, aufgrund der einfachen Portabilität der Anwendung auf andere Endgeräte, für die Implementierung verwendet. Der Ansatz einer effizienten Implementierung beginnt bei einer effizienten Punktarithmetik. Dazu wird zuerst die Implementierung der Langzahlarithmetik in JAVA auf mobilen Endgeräten untersucht, um anschließend die Punktarithmetik der verschiedenen kryptographischen Serviceprovider zu analysieren und die jeweils effizientesten Implementierungen zu ermitteln. Ausgehend von den Analysen und aufgrund der starken Einschränkungen, welche die Java Micro Edition (JME) mit sich bringt wird zunächst die Abstraktionsebene Java Cryptography Micro Architecture (JCMA) entwickelt und implementiert. Dabei handelt es sich um eine an die Java Cryptography Architecture (JCA) und Java Cryptography Extension (JCE) angelehnte Provider-Architektur zur Abstraktion kryptographischer Primitive, die auch Punktarithmetik unterstützt. Mit Hilfe dieser Architektur wird nun eine providerunabhängige, effiziente Implementierung der Protokolle PACE und EAC realisiert. Um die Anwendung in dem genannten Szenario einsetzen zu können müssen die beiden Authentisierungsprotokolle Terminalauthentisierung und Chipauthentisierung des EAC-Protokolls, soweit benötigt, und eine Anbindung an einen eid-server, der die eid-funktionen des neuen Personalausweises ausließt, implementiert werden. Da zum Zeitpunkt des Verfassens dieser Arbeit kein Server mit ecard-api zur Verfügung steht, erfolgt die Kommunikation zwischen mobilem Endgerät und eid-server nicht ecard-api konform, sondern folgt dem eid-server eigenen Protokoll des von FlexSecure 2 bereit gestellten Servers. Am Ende der Arbeit steht mit MobileEAC ein mobiler eid-client zur Nutzung der eid-anwendung des neuen Personalausweises mit NFC-fähigen mobilen Endgeräten. 1 JAVA-Applikation für mobile Endgeräte 2 vi

8 vii

9 Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Umfeld - Der neue Personalausweis Auf dem neuen Personalausweis gespeicherte Daten Technische Aspekte Ausgangszustand & Eigener Beitrag Technologien Begriffserläuterungen Terminaltypen PACE Das PACE Protokoll Secure Messaging EAC Terminalauthentisierung Chipauthentisierung RI NFC und RFID Analyse verschiedener Java Krypto Provider und JME konformer BigInteger-Implementierungen Java Krypto Provider JCA/JCE und JME JCA/JCE und elliptische Kurven Kryptographie Java CSPs BigInteger Implementierungen Original Java BigInteger FlexiBigInt BouncyCastle BigInteger IAIK BigInteger Analyseergebnisse BigInteger und CSP Performance Messungen Vorgehen BigInteger Performance CSP EC Performance Ergebnisse BigInteger Performance CSP EC Performance viii

10 4.2.3 Analyseergebnisse JCMA Implementierung einer CSP Abstraktion Architektur MobileEAC Effiziente Implementierung von PACE und EAC Konzeption PACE EAC Implementierung MobileEAC Performance Tests Vorgehen Ergebnisse Fazit und Ausblick Fazit Ausblick A Ergebnisse der Performance Messungen 55 A.1 CSP - Performance Ergebnisse A.2 MobileEAC - Performance Ergebnisse A.2.1 Zustand 1.i A.2.2 Zustand B Benutzerhandbuch 57 ix

11 Abbildungsverzeichnis 1.1 Der elektronische Personalausweis Technoligie- & Protokoll- Übersicht Passwörter auf dem npa Berechtigungs-PKI JCA Architektur Provider Abstraktion BigInteger Performance Diagramm BigInteger Performance Diagramm Punktarithmetik Performance Diagramm JCMAConnector UML Diagramm JCMAProvider UML Diagramm - Übersicht JCMAProvider UML Diagramm - Klasse IFileWriter ISO1443Thread MobileEAC Performance B.1 User Interface x

12 Listings 4.1 Auzug aus den BigInteger Performance-Tests (de.tud.cdc.peac.test.bigintegertest.java) Auzug aus den CSP Performance-Tests (de.tud.cdc.peac.test.csptest.java) A.1 Ergebnisse des CSP Performance-Tests (de.tud.cdc.peac.test.csptest.java) A.2 Ergebnisse des MobileEAC Performance-Tests Zustand 1.i A.3 Ergebnisse des MobileEAC Performance-Tests Zustand xi

13 Tabellenverzeichnis 1.1 Schematischer Ablauf der zu implementierenden Protokolle Allgemeines PACE Protokoll PACE Protokoll mit ECDH Terminal Authentication Protokoll Chip Authentication Protokoll Analyse der Original Java BigInteger Klasse BigInteger Performancetests CSP Performancetests Performante Version des PACE Protokolls mit ECDH Vergleich der Laufzeiten in Abhängigkeit von w für die Berechnung s G + x Y Das EAC-Protokoll Laufzeitmessungen der MobileEAC-Anwendung xii

14 xiii

15 1 Einleitung 1.1 Motivation Sowohl die Betriebssysteme auf mobilen Endgeräten als auch ihre Hardware nähern sich immer stärker der Funktionalität moderner Desktopsysteme an. Die Near Field Communication (NFC) Technologie setzt dabei neue Maßstäbe in der mobilen Kommunikation zwischen physikalischen Objekten. Durch die Unterstützung der Radio Frequency Identification (RFID) Technologie eröffnen sich neue Anwendungsszenarien, wie die Kommunikation mit dem neuen Personalausweis. Um die drei allgemeinen Schutzziele der Informatik (Vertraulichkeit, Integrität und Authentizität) auch beim neuen Personalausweis (npa) sicherzustellen, kommen das Password Authenticated Connection Establishment (PACE) Protokoll und das Extended Access Control (EAC) Protokoll zum Einsatz. PACE dient dem Aufbau einer sicheren Verbindung über die Luftschnittstelle zwischen npa und Lesegerät. EAC besteht aus der Terminalauthentisierung (Terminal Authentication, TA) und der Chipauthentisierung (Chip Authentication, CA), welche zusammen für eine gegenseitige Authentifizierung des npas und eines darauf zugreifenden Dienstes sorgen. Als Machbarkeitsstudie der Kommunikation mit dem npa mittels NFC wurde in einer vorhergehenden Bachelor Thesis von M. Horsch [11] das PACE-Protokoll für mobile Endgeräte in einer naiven Variante implementiert. Bei der Entwicklung stand insbesondere ein robustes, flexibles und leicht zu erweiterndes Design im Vordergrund. 1.2 Zielsetzung Ein Problem des PACE-Prototypen der Machbarkeitsstudie ist die sehr lange Laufzeit des Protokolls. Deshalb soll in dieser Arbeit das PACE-Protokoll effizienter gemacht werden, so dass die Verbindung in nutzerfreundlicher Zeit zustande kommt. Weiterhin soll das Handy in der Lage sein, durch Nutzung des EAC-Protokolls, die Verbindung mit einem eid-server, der einen Dienst zum Auslesen der Daten für die eid-anwendung zur Verfügung stellt, aufzubauen. Ziel dieser Arbeit ist es mit MobileEAC einen mobilen eid-client als JAVA-Applikation zu entwickeln, welcher einen kompletten Durchlauf der Protokolle realisiert, sowie die Datengruppen der eid-anwendung von dem eid-server auslesen lässt, um sie anschließend auf dem Handy anzuzeigen. 1.3 Umfeld - Der neue Personalausweis Mit dem Gesetz über Personalausweise und den elektronischen Identitätsnachweis sowie zur Änderung weiterer Vorschriften vom 18. Juni 2009 [8], wird zum 1. November 2010 der neue Personalausweis in Deutschland eingeführt. Immer mehr Transaktionen, die einen Identitätsnachweis verlangen, wie z.b. die Eröffnung eines Bankkontos, verlagern sich auf das Internet. Mit dem elektronischen Personalaus- 1

16 weis wird ein standartisierter Identitätsnachweis für die Online-Welt eingeführt, der dies ermöglicht. Der neue Personalausweis ist mehr als nur eine digitale Version des bisherigen Personalausweises. Er beinhaltet alle herkömmlichen Merkmale des Sichtausweises. Darüber hinaus werden auf dem kontaktlosen Chip im Karteninneren elektronische Merkmale zur Nutzung der elektronischen Ausweisfunktionalität gespeichert. Die Anwendungsgebiete des neuen Personalausweises erstrecken sich von E-Government-Dienstleistungen über Altersverifikation im Internet, bis hin zum rechtsverbindlichen Unterzeichnen digitaler Dokumente. Abbildung 1.1: Muster des elektronischen Personalausweises [7] Dabei dürfen die Daten nur von staatlich berechtigten Diensten abgefragt werden, so dass sichergestellt ist, dass sowohl dem Nutzer als auch dem Anbieter valide Daten vorliegen Auf dem neuen Personalausweis gespeicherte Daten Der npa unterscheidet zwischen drei verschiedenen Anwendungen: Biometrieanwendung, eid-anwendung und Signaturanwendung [6]. Die Biometrieanwendung umfasst die maschinenlesbare Zone (MRZ), ein digitales Lichtbild, evtl. enthaltene Fingerabdrücke, Hashwerte dieser Daten, sowie Signaturen über diese Hashwerte und das zugehörige Zertifikat des Signierers (DS-Zertifikat). Diese Daten sind nach Herstellung des Personalausweises nicht mehr veränderbar. Die Signaturanwendung dient zur Erstellung qualifizierter elektronischer Signaturen (QES). Dafür ist ein Schlüsselpaar nötig, welches durch den Anwender erzeugt wird und durch eine Signatur-PIN gesichert wird. Die Daten, die im Rahmen dieser Arbeit durch ein Authentisierungsterminal ausgelesen werden sollen, sind in der eid-anwendung gespeichert. Diese speichert auf dem integrierten Chip folgende Daten: Dokumententyp ( ID ) Ausgebender Staat ( D ) Ablaufdatum Vorname(n), Familienname Ordensname / Künstlername Akademischer Grad Tag und Ort der Geburt Adresse 2

17 Vergleichsgeburtsdatum 1 Schlüssel für sektorspezifische Sperrmerkmale Schlüssel für sektorspezifische Kennung Die letzten vier Datengruppen werden im Rahmen dieser Arbeit nicht ausgelesen. Sichtbare Merkmale Zusätzlich zu den elektronischen Merkmalen, sind nach wie vor alle sichtbaren Merkmale des alten Personalausweises, wie z.b. Augenfarbe und Geburtsname, auf dem npa aufgedruckt. 1.4 Technische Aspekte Der Zugriff auf die Daten der eid-anwendung erfolgt durch ein Authentisierungsterminal. Wir betrachten in dieser Arbeit den Spezialfall der Online-Authentisierung. Dabei wird das Authentisierungsterminal in zwei Teile aufgeteilt: ein lokales Terminal (das Handy) und ein entferntes Terminal (der Server des Dienstanbieters). Die in 1.3 beschriebenen Daten der eid-anwendung sind mit einer fünfstelligen persönlichen Identifikationsnummer (PIN), der eid-pin bzw. einer sechsstelligen Card Access Number (CAN) gesichert, und werden auch nur nach expliziter Eingabe einer der beiden Geheimnisse übertragen. Näheres dazu ist in Abschnitt 2.3 zu finden. Zwischen dem lokalen Terminal und dem entfernten Terminal muss eine gesicherte Internetverbindung bestehen, z.b. mit Transport Layer Security (TLS). Die Übertragung zwischen dem npa und dem mobilen Endgerät erfolgt kontaktlos über Near Field Communication (NFC) nach ISO/IEC Der Verbindungsaufbau der beiden Parteien wird mit Hilfe des PACE-Protokolls gesichert. Der Verbindungsaufbau zwischen dem npa und dem entfernten Terminal erfolgt mit Hilfe des EAC-Protokolls. Anschließend kann das entfernte Terminal die Datengruppen, für die es Berechtigungen besitzt, auslesen. Die Protokolle und Technologien werden in Abschnitt 2 näher erläutert. Abbildung 1.2 zeigt eine graphische Übersicht des Szenarios und der darin verwendeten Protokolle und Technologien. PACE Protokoll Handy (Lokales Terminal) Web Service (Entferntes Terminal) NFC Verbindung Internet EAC Protokoll Abbildung 1.2: Eine graphische Übersicht über die Protokolle und Technologien 1 Ein anhand der bekannten Teile des Geburtsdatums errechnetes, spätestmögliche Datum als Vergleichsdatum. 3

18 1.5 Ausgangszustand & Eigener Beitrag Die in dieser Arbeit vorgestellten Implementierungen bauen auf Vorarbeiten von Moritz Horsch [11] auf, und entwickeln diese weiter. In diesem Abschnitt wird kurz aufgezeigt was bereits vorhanden ist, und was durch diese Arbeit hinzugefügt wird um die in 1.2 vorgestellten Ziele zu erreichen. Ausgangszustand Wie bereits in der Motivation erwähnt, wurde im Rahmen der Bachelor Thesis von Moritz Horsch [11] ein Prototyp des PACE-Protokolls für mobile Endgeräte entwickelt. Zur Ausführung des PACE-Protokolls wird rechenintensive Punktarithmetik benötigt, was auf einem ressourcenbeschränkten Gerät wie dem Handy zu sehr langen Laufzeiten führt. Als kryptographischer Serviceprovider (Cryptographic Service Provider, CSP) wurde der FlexiProvider 2 bzw. BouncyCastle 3 genutzt, wobei der Wechsel zwischen den beiden Providern nicht so einfach möglich ist, da sie jeweils fest eingebaut sind. Dies führte zu zwei Versionen des Prototyps. Eigener Beitrag Tabelle 1.1 zeigt eine schematische Übersicht über die zu implementierenden Protokolle. Das im zweiten Schritt durchgeführte PACE-Protokoll wird im Rahmen dieser Arbeit derart optimiert, dass es in benutzerfreundlicher Zeit abläuft. Die übrigen Schritte der in Tabelle 1.1 dargestellten Protokolle werden, soweit nötig, implementiert und zusammen mit dem PACE-Protokoll und einer Secure Messaging Implementierung in der Anwendung MobileEAC zusammengefasst. Diese bietet die Möglichkeit die Daten der eid-anwendung eines Ausweises mit Hilfe eines eid-servers auszulesen. Zudem werden alle Abhängigkeiten zu kryptographischen Serviceprovidern durch eine Abstraktion entfernt, sodass ein einfacher Wechsel zwischen diesen möglich ist. Dafür wird die Java Cryptography Micro Architecture (JCMA) entwickelt und implementiert. Diese ermöglicht, durch den einfachen Wechsel des unterliegenden Providers, auch die Nutzung von Hardware-Kryptoprovidern, wie sie z.b. von secusmart 4 hergestellt werden. Diese werden beispielsweise als microsd Karte in das Handy eingebaut und können, wenn sie die in dieser Arbeit entwickelte Abstraktionsschicht unterstützen, als CSP genutzt werden. Aufbau der Arbeit Zuerst wird in Kapitel 2 eine Übersicht und kurze Einführung der in dieser Arbeit verwendeten Protokolle und Technologien gegeben. Anschließend werden in Kapitel 3 die Java-Krypto Provider vorgestellt und, wie in Kapitel 4 beschrieben, einigen Performance Tests unterzogen. Dabei ergibt sich dass es nötig ist eine eigene CSP-Abstraktion, wie in Kapitel 5 beschrieben, zu implementieren. In Kapitel 6 können nun die Protokolle PACE und EAC effizient implementiert werden. Zum Schluss wird mit Performancetests in Kapitel 7 gezeigt, wie stark die Effizienz der Implementierung gesteigert werden konnte

19 Personalausweis Handy Server Übertragen des Dienstanbieterzertifikats Lesen der Datei EF.CardAccess; PACE mit eid-pin / CAN als Passwort Übertragen der vollständigen Zertifikatskette; Terminalauthentisierung Lesen der Datei EF.CardSecurity Passive Authentisierung Chipauthentisierung Lesen des Sperrmerkmals; Abfrage der Dokumentengültigkeit Sperrlistenabfrage Auslesen der freigegebenen Daten Tabelle 1.1: Schematischer Ablauf der zu implementierenden Protokolle 5

20 2 Technologien In diesem Kapitel werden die wichtigsten Technologien und Begriffe, die im Zusammenhang dieser Arbeit verwendet werden, eingeführt. Dafür werden die bereits in Abschnitt 1.4 erwähnten Technologien und Protokolle nun genauer beschrieben. 2.1 Begriffserläuterungen Die in den Protokollen als Proximity Integrated Circuit Card (PICC) bezeichnete Einheit ist in dem Umfeld dieser Arbeit der neue Personalausweis. Dieser kommuniziert mit dem mobilen Endgerät und dem eid-server, welche beide als Proximity Coupling Device (PCD) fungieren. Die MRZ ist in Abbildung 2.1a zu sehen und besteht aus dem Ausweistyp, der Seriennummer, dem Geburtsdatum, dem Ablaufdatum, dem Namen und jeweils nachgestellten Prüfsummen. Der SHA-1-Hashwert über die Seriennummer, das Geburtsdatum und das Ablaufdatum aus der MRZ kann als Passwort für das PACE-Protokoll verwendet werden [6]. Auf der Vorderseite des Ausweises ist rechts unten die CAN zu finden. Dabei handelt es sich um eine zufällige sechsstellige Zahl, die als PACE-Passwort verwendet werden kann, wenn keine Bindung an den Ausweisinhaber nötig ist (siehe Abbildung 2.1b). Machine Readable Travel Document (MRTD) wird als Oberbegriff für maschinenlesbare Ausweisdokumente genutzt. Die Begriffe MRTD Chip und npa werden synonym verwendet wenn offensichtlich ist was gemeint ist. CAN MRZ (a) Maschinenlesbare Zone (b) Card Access Number Abbildung 2.1: Passwörter auf dem npa 2.2 Terminaltypen Es werden im wesentlichen vier verschiedene Terminaltypen zum auslesen der Daten des neuen Personalausweises unterschieden. Wie bereits erwähnt wird in dieser Arbeit ein nicht hoheitliches Authentisierungsterminal, hier nur noch Authentisierungsterminal genannt, verwendet. 6

21 Inspektionssysteme: Inspektionssysteme werden zur Kontrolle der Ausweisdaten durch hoheitliche Stellen, wie sie beispielsweise bei Grenzkontrollen erfolgen, verwendet. Dabei wird noch einmal zwischen hoheitlich nationalen und hoheitlich ausländischen Inspektionssystemen unterschieden. Inspektionssysteme dürfen auf die Datengruppen 1 (Daten der MRZ) und 2 (Lichtbild) sowie gegebenenfalls auf die Datengruppe 3 (Fingerabdrücke) und die Daten der eid-anwendung zugreifen. Es dürfen keine Daten verändert werden. Authentisierungsterminal: Authentisierungsterminals haben Lese- und Schreibzugriff auf Teile der eid-anwendung. Die Beschränkungen, auf welche Daten Zugriff besteht, werden während der Authentisierung des Terminals festgelegt. Es wird zwischen hoheitlich nationalen und nicht hoheitlichen / ausländischen Inspektionssystemen unterschieden. Bestätigtes Signaturterminal: Bestätigte Signaturterminals werden zur Erstellung einer QES oder zum setzen einer neuen Signatur-PIN verwendet. Nicht authentisiertes Terminal: Nicht authentisierte Terminals werden für administrative Zwecke genutzt und ohne Certificate Holder Authorization Template (CHAT), das heißt auch ohne TA und CA, durchgeführt. Es wird zum setzen einer neuen eid-pin oder zum Zurücksetzen der Fehlbedienungszähler genutzt. 2.3 PACE Das PACE-Protokoll wird in der Technical Guideline TR [4] des Bundesamts für Sicherheit in der Informationstechnik (BSI) eingeführt. Es ersetzt das Basic Access Control (BAC) 1 Protokoll. PACE basiert auf dem bekannten Diffie-Hellman (DH) Schlüsseltausch [17]. Es erweitert den DH-Schlüsseltausch in sofern, dass die Partner sich gegenseitig authentifizieren, wodurch kein man-in-the-middle Angriff mehr ermöglicht. Das Ziel des Protokolls ist es, sicher zu stellen, dass der Anwender berechtigt ist diesen Ausweis zu nutzen, und eine verschlüsselte und integre Verbindung zwischen Lesegerät und Chip (npa) aufzubauen. Der Nachweis der Berechtigung erfolgt durch ein PACE-Passwort. Dies kann je nach Terminaltyp unterschiedlich sein. Die Passwörter sind wie folgt festgelegt: hoheitlich nationales / ausländisches Inspektionssystem CAN oder MRZ hoheitlich nationales bzw. nicht-hoheitliches/ausländisches Authentisierungsterminal eid-pin oder CAN falls erlaubt Bestätigtes Signaturterminal CAN oder eid-pin (mit jeweils etwas unterschiedlichen Rechten) Nicht authentisiertes Terminal eid-pin oder PUK (mit jeweils etwas unterschiedlichen Rechten) 1 BAC wird beim elektronischen Reisepass eingesetzt. 7

22 2.3.1 Das PACE Protokoll Der generische Protokollverlauf ist schematisch in Abbildung 2.1 zu sehen. Der npa ist der MRTD Chip und das Handy übernimmt die Rolle des Terminals. Das PACE-Protokoll kann mit einfachem DH oder mit DH auf elliptischen Kurven (ECDH) durchgeführt werden. Der npa nutzt die Variante des PACE- Protokolls mit ECDH. Eine Protokollübersicht mit den entsprechenden Operationen ist in Abbildung 2.2 zu sehen. Anhand der korrespondierenden Zeilennummern kann die allgemeine Version leicht mit der ECDH Variante verglichen werden. G bezeichnet dabei den Basispunkt, der auf dem MRTD Chip gespeichert ist. Großbuchstaben bezeichnen wie üblich Punkte auf der elliptischen Kurve (die in Zukunft nur noch Punkte genannt werden), während Kleinbuchstaben Skalare bezeichnen. D P ICC sind die statischen Domain Parameter des MRTD Chips, welche in der EF.CardAccess 2 gespeichert sind. Das Geheimnis, das als Passwort verwendet wird, wird mit π bezeichnet. Aus diesem Passwort wird mittels einer Schlüssel- Ableitungsfunktion (Key Derivation Function, KDF) ein längerer Schlüssel berechnet K π = KDF π (π). KA bezeichnet die Erzeugung von Schlüsselpaaren. MRTD Chip (PICC) (1) s zufällig D P ICC,z Terminal (PCD) (2) z = E(K π, s) s = D(K π, z) (3) Datenaustausch für Map D = Map(D P ICC, s) D = Map(D P ICC, s) (4) Choose ephemeral key pair ( SK P ICC, PK P ICC, D) (5) Verify( PK PC D PK P ICC ) PK PC D Choose ephemeral key pair ( SK PC D, PK PC D, D) PK P ICC Verify( PK P ICC PK PC D ) (6) K = KA( SK P ICC, PK PC D, D) K = KA( SK PC D, PK P ICC, D) (7) K MAC = KDF MAC (K) K MAC = KDF MAC (K) (8) K Enc = KDF Enc (K) K Enc = KDF Enc (K) (9) T P ICC = MAC(K MAC, PK PC D ) T PC D TPC D = MAC(K MAC, PK P ICC ) (10) Verify(T PC D ) (11) T P ICC Verify(TP ICC ) Abbildung 2.1: Allgemeines PACE Protokoll Protokoll Erläuterungen K x bezeichnet die affine x-koordinate des Punktes K als Octet-String. Im allgemeinen wird durch die Funktion Comp(P) = P x der Punkt P auf die x-koordinate komprimiert. Dieser wird als Octet-String dargestellt. KDF bezeichnet ist eine Key Derivation Function. 2 Die EF.CardAccess enthält die vom npa unterstützten Version des PACE und EAC-Protokolls, sowie die zur Durchführung nötigen Domain Parameter. 8

23 KDF MAC ist ein Hash (SHA160/SHA224/SHA256, abhängig von der PACE-Version) H(K x 0x ) KDF EN C ist ein Hash (SHA160/SHA224/SHA256, abhängig von der PACE-Version) H(K x 0x ) T LVP X bezeichnet ein TLV 3 kodiertes Objekt, welches die Domainparameter und die x-koordinate des öffentlichen Schlüssels P enthält. Map bezeichnet das Mapping eines Generators G auf einen neuen Generator G. In dieser Arbeit wird lediglich das generische Mapping G = s G + H auf elliptischen Kurven betrachtet. Weiterhin existiert das integrierte Mapping [14] für elliptische Kurven, sowie eine Version beider Arten für einfachen DH. Verify( ) verifiziert ob die in Klammern stehende Bedingung erfüllt ist. Ist dies nicht der Fall wird das Protokoll abgebrochen. MAC(K, x) berechnet den Message Authentication Code (MAC) über x mit dem Schlüssel K. MRTD Chip (PICC) (1) s zufällig (2) z = E(K π, s) (3) y zufällig Y = y G H = y X G = s G + H Terminal (PCD) D P ICC,z s = D(K π, z) x zufällig X = x G X Y H = x Y G = s G + H (4) neuer Basispunkt G neuer Basispunkt G SK P ICC zufällig SK PC D zufällig PK P ICC = SK P ICC G PK PC D PK PC D = SK PC D G (5) Verify( PK PC D PK P ICC ) Verify( PK P ICC PK PC D ) (6) l = h 1 mod n l = h 1 mod n Q = h PK PC D Q = h PK P ICC K = [ SK P ICC l mod n] Q K = [ SK PC D l mod n] Q (7) K MAC = KDF MAC (K x ) K MAC = KDF MAC (K x ) (8) K Enc = KDF Enc (K x ) K Enc = KDF Enc (K x ) T PC D (9) T P ICC = MAC(K MAC, T LVPK ) PC D TPC D = MAC(K MAC, T LVPK ) P ICC (10) Verify(T PC D ) (11) PK P ICC T P ICC Verify(TP ICC ) Abbildung 2.2: PACE Protokoll mit ECDH 3 Tag-Length-Value 9

24 2.3.2 Secure Messaging Bei dem Secure Messaging handelt es sich um einen sicheren und authentifizierten Kanal zwischen dem npa und einer Gegenstelle. Für die erste Instantiierung des Secure Messaging Kanals werden die Schlüssel K MAC und K EN C, die während des PACE-Protokolls ausgehandelt wurden, verwendet. Dieser Kanal wird verwendet, um zwischen dem npa und dem entfernten Terminal neue Schlüssel auszuhandeln, mit denen schließlich ein Secure Messaging Kanal zwischen npa und entferntem Terminal gestartet wird. Secure Messaging kann mit verschiedenen Sicherheitsstufen instantiiert werden. Die Sicherheitsstufe hängt von den verwendeten Parametern für Verschlüsselung und MAC ab. Secure Messaging nutzt authentifizierte Verschlüsselung zur Übertragung von Daten. Die Verschlüsselung erfolgt mit AES [18] im CBC-Modus. Die Authentifizierung wird mittels CMAC [19] mit AES durchgeführt. Um eine möglichst hohe Sicherheit zu gewährleisten wird das Encrypt-then-Authenticate Verfahren verwendet, wodurch Vertraulichkeit, Integrität und Authentizität gewährleistet wird. Bei diesem Verfahren wird die zu versendende Nachricht zuerst verschlüsselt. Anschließend wird der MAC-Wert der verschlüsselten Nachricht berechnet und an die verschlüsselte Nachricht angehängt. Bei Empfang einer solchen Nachricht wird zuerst der MAC-Wert überprüft, und nur wenn dieser Korrekt ist wird die Nachricht entschlüsselt. 2.4 EAC Das EAC-Protokoll wird zur wechselseitigen Authentifizierung zwischen dem npa und dem entfernten Terminal genutzt. Es besteht aus zwei verschiedenen Teilen; der Terminalauthentisierung zum Nachweis der Zugriffsrechte des entfernten Terminals und der Chipauthentisierung zum Nachweis der Echtheit des Chips und der darauf gespeicherten Daten. EAC existiert in zwei Versionen. Der npa unterstützt EAC2, die Version 2 des Protokolls EAC. Hierbei muss TA vor CA ausgeführt werden, wodurch eine explizite Authentisierung des MRTD-Chips gewährleistet wird. In Version 1 des EAC-Protokolls wird CA vor TA ausgeführt, was dazu führt, dass der MRTD-Chip und die darauf gespeicherten Daten nur implizit authentisiert werden. Im Folgenden ist mit TA und CA immer Version 2 des jeweiligen Protokolls gemeint Terminalauthentisierung Der Nachweis der Rechte eines Dienstanbieters wird mittels TA sichergestellt. Diese Rechte werden von der Vergabestelle für Berechtigungszertifikate (VfB) oder durch eine andere Behörde vergeben und durch die Berechtigungs-Public-Key-Infrastruktur (Berechtigungs-PKI) (auch EAC-PKI genannt) manifestiert. Dabei handelt es sich um eine zweistufige PKI (Wurzelinstanz, Document Verifiers (DV), Terminal Zertifikat), wie in Abbildung 2.2 dargestellt. Die Country Verifying CA (CVCA) ist die Wurzelinstanz jedes Zertifikats, das berechtigt ist die Daten eines npas auszulesen. Sie wird vom Bundesamt für Sicherheit in der Informationstechnik (BSI) betrieben. Die folgende Auflistung beschreibt die vier Arten von Dienstanbietern und deren Berechtigungen. Die Zugriffsrechte werden bereits im PACE-Protokoll (2.3) durch das CHAT festgelegt [5]. 10

25 CVCA DV DV DV Terminal Terminal Terminal Terminal Terminal Terminal Abbildung 2.2: Schematische Übersicht über die Berechtigungs-PKI hoheitlich nationales / ausländisches Inspektionssystem Lesezugriff auf die Biometrieanwendung Wenn Read access to eid application gesetzt ist: Auslesen der Daten der eid-anwendung hoheitlich nationales bzw. nicht-hoheitliches / ausländisches Authentisierungsterminal Lese- und Schreibrechte auf bestimmte Datengruppen der eid-anwendung Bestätigtes Signaturterminal Erzeugen qualifizierter Signaturen Nicht authentisiertes Terminal Lokale, administrative Vorgänge (kein CHAT) Der für diese Arbeit genutzte eid-server ist ein nicht-hoheitlich nationales Authentisierungsterminal, welches die in Abschnitt beschriebenen Daten auslesen darf. Das TA-Protokoll Jegliche Kommunikation zwischen dem MRTD-Chip und dem lokalen Terminal muss mittels Secure Messaging gesichert werden. Die Schlüssel dafür werden während des PACE-Protokolls ausgehandelt. Abbildung 2.3 zeigt eine schematische Übersicht des Protokolls [4]. Protokoll Erläuterungen MRTD Chip bezeichnet den npa. Das Terminal ist in diesem allgemeinen Fall nicht unterteilt in lokales und entferntes Terminal und bezeichnet hier die Gegenstelle des Ausweises zum Auslesen der Daten. Nachdem PACE durchgeführt wurde wird der initiale Secure Messaging Kanal aufgebaut und die Zertifikatskette, die den öffentlichen Schlüssel PK PC D des Terminals enthält, an den npa gesendet, der diese verifiziert. Anschließend wird eine zufällige Challenge vom Chip angefordert. Diese Challenge wird zusammen mit dem temporären öffentlichen Schlüssel Comp( PK P ICC ), der ab jetzt I D P ICC genannt wird, vom Terminal mit dem privaten Schlüssel des Terminalzertifikats signiert und an den npa geschickt. 11

26 Akzeptiert dieser die Signatur ist TA beendet und die EF.CardSecurity kann ausgelesen werden. Die EF.CardSecurity enthält sowohl alle Domainparameter des Ausweises, als auch alle von ihm unterstützten Protokolle. Zudem enthält die Datei die Hashwerte der Datengruppen 1 bis 3 und eine Signatur darüber. Diese kann für die Passive Authentisierung genutzt werden. MRTD Chip (PICC) (1) Verifikation Extraktion von PK PC D (2) (3) (4) r P ICC zufällig (5) Verify(PK PC D, s PC D, I D P ICC r P ICC Comp(PK PC D ) A PC D ) = true Zer ti f ikatsket te 5 Comp(PK PC D ) Terminal (PCD) Gen( SK PC D, PK PC D, D P ICC ) 6 A PC D r P ICC s PC D spc D = Sign(SK PC D, I D P ICC r P ICC Comp( PK PC D ) A PC D ) Abbildung 2.3: Terminal Authentication Protokoll Chipauthentisierung Die CA dient, in Verbindung mit der passiven Authentisierung [13], dem Nachweis der Echtheit der Daten auf dem Chip des Personalausweises, und dem Aufbau einer sicheren Verbindung zwischen dem MRTD und dem Dienstanbieter. Mit der passiven Authentisierung wird die Echtheit der Daten des MRTD Chips nachgewiesen indem das Terminal die in der EF.CardSecurty gespeicherte Signatur der ausstellenden Behörde prüft [5]. (1) MRTD Chip (PICC) PK P ICC,D P ICC 7 Terminal (PCD) (2) Compare(Comp( PK PC D ), PK TA 8 PC D ) PK PC D (3) K = KA(SK P ICC, PK PC D, D P ICC ) K = KA( SK PC D, PK P ICC, D P ICC ) (4) r P ICC zufällig (5) K MAC = KDF MAC (K, r P ICC ) K Enc = KDF Enc (K, r P ICC ) (6) T P ICC = MAC(K MAC, PK PC D ) T P ICC,r P ICC KMAC = KDF MAC (K, r P ICC ) K Enc = KDF Enc (K, r P ICC ) (7) Verify(T P ICC ) Abbildung 2.4: Chip Authentication Protokoll 5 Die Zertifikatskette startet mit einem Zertifikat, das mit dem öffentlichen Schlüssel der CVCA verifizierbar ist, und endet mit dem Terminal Zertifikat (siehe Abbildung 2.2) 6 Erzeugung eines Diffie-Hellman Schlüsselpaares 7 PK P ICC ist ein statischer DH-Schlüssel, und D P ICC sind die Domain Parameter 8 PK TA PC D := Comp( PK PC D ) aus der Terminal Authentication 12

27 Das Chip Authentication Protokoll Das CA-Protokoll ist in Abbildung 2.4 schematisch beschrieben. MRTD Chip bezeichnet den npa. Das Terminal ist in diesem allgemeinen Fall nicht unterteilt in lokales und entferntes Terminal und bezeichnet hier die Gegenstelle des Ausweises zum Auslesen der Daten. Das flüchtige Schlüsselpaar ( SK PC D, PK PC D, D P ICC ) wurde bereits während der Terminal Authentication (2.4.1) erzeugt. Zur Verifikation von PK P ICC, dem statischen öffentlichen Schlüssel des Ausweises, sollte die Passive Authentisierung verwendet werden. Die CA ist ein Diffie-Hellman Key-Agreement Protokoll zwischen dem Terminal und dem npa. Die dabei erzeugten Schlüssel werden zur Instantiierung eines neuen Secure Messaging Kanals zwischen Terminal und Personalausweis genutzt. 2.5 RI RI steht für Restricted Indentification und bezeichnet die Identifikation eines MRTD Chips durch einen Dienstanbieter anhand eines Pseudonyms. Dieses Pseudonym ist für einen Terminal Sektor eindeutig. Ein Terminal Sektor ist eine ID für alle Terminals eines Dienstanbieters. So kann ein npa erkannt werden, ohne persönliche Daten davon auszulesen. RI wird im Rahmen dieser Arbeit nicht näher betrachtet. Für weitere Erläuterungen siehe [4]. 2.6 NFC und RFID NFC bezeichnet die Near Field Communication Technik. Mit dieser ist es möglich kabellos Daten über Entfernungen von bis zu 10 Zentimetern zu übertragen. Definiert ist NFC als Erweiterung des RFID Standards ISO/IEC (Identification cards Contactless integrated circuit cards Proximity cards). Dort werden Transponderkarten zur Identifikation (Elektronische Ausweisdokumente) und deren Kommunikation definiert. Für weitere Informationen zu NFC sei auf die Thesis von Moritz Horsch [11] verwiesen. 13

28 3 Analyse verschiedener Java Krypto Provider und JME konformer BigInteger-Implementierungen Dieses Kapitel beschäftigt sich mit den Java Krypto Providern und Java Micro Edition (JME) konformen Implementierungen der Klasse BigInteger. Die Untersuchung der Krypto Provider ist nötig, da die hier vorgestellte effiziente Implementierung des PACE- und EAC-Protokolls nicht an einen Provider gekoppelt sein soll, um die Möglichkeit zu besitzen z.b. Hardware-Krypto Provider einzubinden. Die Betrachtung der Klasse BigInteger ist notwendig, da die EC-Arithmetik massiven Gebrauch von dieser Klasse macht, diese aber nicht in der JME enthalten ist. Es werden verschiedene Implementierungen der Klasse BigInteger und verschiedene CSPs verglichen um eine möglichst performante Version zu finden, die für die Implementierung der Protokolle verwendet werden kann. Abschnitt 3.1 wird zunächst eine Einführung in den Aufbau von JCA/JCE gegeben um anschließend verschiedene Provider vorzustellen und zu diskutieren. Im darauf folgenden Abschnitt 3.2 werden die Probleme der Klasse BigInteger, so wie sie in der Java Standard Edition (JSE) vorhanden ist, aufgezeigt und Lösungsmöglichkeiten vorgeschlagen. Zudem werden weitere Implementierungen der Klasse untersucht und diskutiert. 3.1 Java Krypto Provider Die Java Cryptography Architecture (JCA) wurde mit dem Java Development Kit (JDK) 1.1 eingeführt und bietet ein Framework zum Zugriff und zur Entwicklung kryptographischer Protokolle. Es unterstützt kryptographische Hashfunktionen und Signaturen. Seit dem Java 2 SDK umfasst die JCA die kryptographischen Teile der Sicherheits API und eine Menge an Konventionen und Spezifikationen. Die Provider- Architektur der JCA erlaubt es verschiedene Implementierungen kryptographischer Primitive transparent und leicht austauschbar zu nutzen. Mit der Java Cryptography Extension (JCE) stellt die JSE ein Framework zum Zugriff auf Funktionen zur Verschlüsselung und zum Schlüsselaustausch zur Verfügung. Die JCE nutzt die selbe Architektur wie die JCA. Die Unterscheidung zwischen JCA und JCE ist historisch bedingt und beruht auf den Exportrestriktionen der USA. Starke Verschlüsselungsmechanismen unterlagen Exportrestriktionen und wurden deshalb in die JCE ausgelagert, welche nur als zusätzliches Paket erhältlich war. Seit dem JDK 1.4 wird JCE zusammen mit JCA ausgeliefert, und kann somit als ein Teil davon betrachtet werden. Die JCE selbst liefert keine Funktionalität sondern nur eine Architektur zum uniformen Zugriff auf Klassen und Funktionen. Um die Funktionalität des Frameworks nutzen zu können ist die Implementierung mindestens eines Providers nötig. Mit der JSE werden bereits einige Provider, wie z.b. SUN, SunRsaSign und SunJ- CE, mitgeliefert (JCA Reference Guide 1 ). 1 CryptoSpec.html 14

29 Im Folgenden wird die JCA der zur Zeit aktuellen Java Standard Edition 6 betrachtet. Es wird dehalb nicht mehr zwischen JCA und JCE unterschieden. JCA - Prinzipien Die JCA baut auf drei Prinzipien auf, die hier kurz vorgestellt werden sollen. Die Implementierungsunabhängigkeit besagt, dass die Sicherheitsalgorithmen nicht von jeder Anwendung selbst implementiert werden müssen, sondern von Providern zur Verfügung gestellt werden. Diese werden über eine uniforme Schnittstelle angesprochen. Dabei können auch mehrere Provider gleichzeitig verwendet werden. Durch die Kompatibilität und Interoparabilität der Implementierungen soll gewährleistet sein, dass die Provider ausgetauscht werden können, ohne dass sich dabei etwas nach außen hin verändert. Ebenso ist ein Provider nicht an eine Anwendung gekoppelt. Die Erweiterbarkeit der Algorithmen soll die JCA zukunftssicher halten. Somit können weitere Algorithmen, die bisher noch nicht implementiert wurden und nicht zu den Standardalgorithmen 2 gehören, spezifiziert und von Providern implementiert werden. Engine Klassen und Service Provider Interfaces Dieser Abschnitt liefert eine Übersicht über die Engine Klassen und die zugehörigen Service Provider Interfaces (SPI) im Rahmen des JCE. Es werden nicht alle SPIs aufgezählt, da die JCA neben der JCE von weiteren Bibliotheken genutzt wird, welche weitere SPIs enthalten (Java Secure Socket Extension (JS- SE), Java Generic Security Services (JGSS) APIs und Simple Authentication and Security Layer (SASL)). Hier werden nur die für die JCA/JCE relevanten SPIs untersucht. Engine Klassen bieten, unabhängig von speziellen Providern und Algorithmen, Zugriff auf bestimmte Typen kryptographischer Dienste. Diese sind: kryptographische Operationen Generatoren und Konverter kryptographischen Materials Objekte zur Kapselung kryptographischer Daten Um eine kurze Übersicht über die zur Verfügung stehenden Funktionen des JCE zu geben folgt nun eine Liste der Engine Klassen mit kurzer Beschreibung ihrer Funktionalität: AlgorithmParameterGenerator (AlgorithmParameterGeneratorSpi): Erzeugt passende Parameter zu einem speziellen Algorithmus AlgorithmParameters (AlgorithmParametersSpi): Speichert die Parameter zu einem bestimmten Algorithmus CertificateFactory (CertificateFactorySpi): Erzeugt Public Key Zertifikate und Certificate Revocation Lists (CRL)

30 CertPathBuilder (CertPathBuilderSpi): Aufbauen von Zertifikatsketten CertPathValidator (CertPathValidatorSpi): Validierung von Zertifikatsketten CertStore (CertStoreSpi): Abrufen von Zertifikaten und CRLs Cipher (CipherSpi): Verschiedenste Chiffren zur Ver- und Entschlüsselung von Daten KeyAgreement (KeyAgreementSpi): Algorithmen zur Schlüsselvereinbarung KeyFactory (KeyFactorySpi): Konversion zwischen kryptographischen Schlüsseln (Interface Key) und transparenter Schlüsselspezifikation (Interface KeySpec) KeyGenerator (KeyGeneratorSpi): Erzeugt geheime Schlüssel für einen bestimmten Algorithmus KeyPairGenerator (KeyPairGeneratorSpi): Erzeugt private und öffentliche Schlüssel für einen bestimmten Algorithmus KeyStore (KeyStoreSpi): Erzeugung und Verwaltung von Keystores. Ein Keystore speichert Zertifikate von vertrauenswürdigen Parteien und private Schlüssel mit Zertifikatsketten Mac (MacSpi): Erzeugung von MACs MessageDigest (MessageDigestSpi): Berechnung eines Hashs über Daten SecretKeyFactory (SecretKeyFactorySpi): Spezialisierte KeyFactory, die geheime Schlüssel konvertiert SecureRandom (SecureRandomSpi): Generierung pseudozufälliger Zahlen Signature (SignatureSpi): Signatur von Daten und Verifikation von Signaturen JCA - Architektur Jeder Provider der die JCA nutzen möchte muss die Klasse Provider aus dem Package java.security erweitern. Diese wird instantiiert, an die Java VM übergeben und kann danach zur Laufzeit ausgewählt werden. Der Provider an sich besteht aus einer Menge von Paketen, die konkrete Implementierungen verschiedener kryptographischer Algorithmen enthalten. Die Klassen müssen dabei die entsprechnen- 16

31 den SPIs implementieren. Bei Aufrauf einer Funktion die im entsprechenden SPI definiert ist wird die Implementierung des ersten Providers, der die gewünschte Funktionalität bereit stellt, verwendet. Die Liste der Provider kann dabei mittels Prioritäten sortiert werden. Alternativ kann ein spezieller Provider angefordert werden indem er beim Aufruf der Funktion übergeben wird. Abbildung 3.1 zeigt eine schematische Darstellung eines Aufrufs und dessen Behandlung durch JCA/JCE. Anwendung Cipher.getInstance("AES"); JCA/JCE Signature Message Digest Key Factory Cipher... CSP1 CSP2 CSP3 Provider.class "Chiper.AES" -> "com.foo.aescipher com.foo.aescipher.class package com.foo; class AESCipher extends CipherSpi{... } Abbildung 3.1: JCA Architektur - Aufruf anhand eines Beispiels (AES) JCA/JCE und JME JCA/JCE ist zwar seit dem JDK 1.4 Bestandteil von JSE, in JME ist allerdings weder die JCE noch die JCA vorhanden. Um die Funktionalität der Provider trotzdem nutzen zu können gibt es von den meisten Providern eine kleinere Variante, die weder die Klasse Provider noch die SPIs implementiert. Diese können nicht über die uniforme Schnittstelle des JCE angesprochen werden, so dass die Nutzung providerspezifisch implementiert werden muss. 17

32 3.1.2 JCA/JCE und elliptische Kurven Kryptographie Seit dem JDK 5.0 unterstützt das JCA/JCE Framework kryptographische Algorithmen auf elliptischen Kurven. So können Schlüssel erzeugt, und Algorithmen wie z.b. Diffie-Hellman auf elliptischen Kurven, ausgeführt werden. Es werden allerdings keine low-level Funktionen auf Punkten elliptischer Kurven unterstützt. Zum Rechnen mit Punkten elliptischer Kurven müssen nach wie vor die individuellen Schnittstellen der CSP verwendet werden Java CSPs Im Folgenden werden verschiedene kryptographische Serviceprovider (CSP) und deren JME-Versionen beschrieben. BouncyCastle Die BouncyCastle Crypto APIs 3 beinhalten neben dem JCA/JCE Provider und einer ASN.1 Bibliothek zum Kodieren und Dekodieren von ASN.1 Datenstrukturen viele weitere kryptographische Objekte. Der größte Teil der BouncyCastle Crypto API steht unter einer leicht modifizierten X11 Lizenz 4. Bouncy Castle Crypto Package Zur Verwendung der Bouncy Castle API auf mobilen Geräten gibt es das Bouncy Castle Crypto Package, welches die light-weight API enthält. Diese soll in allen Umgebungen, inklusive JME, lauffähig sein. FlexiProvider Der FlexiProvider 5 wird von der Gruppe Kryptographie und Computeralgebra um Prof. Dr. Buchmann an der Technischen Universität Darmstadt entwickelt. Der größte Teil des FlexiProviders steht unter der LGPL 6. Die EC, PQC, und NF Module sind GPL 7 lizensiert. Neben dem EC-Provider für Kryptographie auf elliptischen Kurven enthält der FlexiProvider zwei weiter spezialisierte Provider. Der Post Quantum Cryptography (PQC) Provider bietet zusätzliche kryptographische Algorithmen die auch gegen Angriffe von Quantencomputen sicher sind. Der Number Field (NF) Provider bietet kryptographische Algorithmen für Number Field Kryptographie. Zur Kodierung und Dekodierung von ASN.1 Datenstrukturen wird die CoDec 8 Bibliothek verwendet; ein third-party Paket das vom Fraunhofer Institute for Computer Graphics entwickelt wurde

33 FlexiProvider ME Eine kleine Version des FlexiProvider steht mit FlexiProviderME zur Verfügung. Diese nutzt wiederum eine JME fähige Version des CoDecs. Diese Version ist aufgrund lizenzrechtlicher Probleme zur Zeit nur für akademische Zwecke verfügbar. IAIK-Java-crypto-toolkits Die IAIK-Java-crypto-toolkits 9 werden von der Stiftung Secure Information and Communication Technologies SIC entwickelt, welche von dem Institute for Applied Information Processing and Communication (IAIK) der Technischen Universität Graz ins Leben gerufen wurde. Die IAIK-Java-crypto-toolkits sind nicht frei verfügbar. Eine Entwicklerlizenz für die IAIK JCE Micro Edition kostet 400. Für akademische Zwecke sind allerdings kostenlose Versionen verfügbar. Die Software ist unter verschiedenen proprietären Lizenzen 10 für verschiedene Zielgruppen erhältlich: Developer Licence Runtime Licence Server Licence Source Code Licence Eine Bibliothek für elliptische Kurven Kryptographie ist getrennt vom IAIK-JCE erhältlich. Diese enthält alle wichtigen Funktionen zum Rechnen mit Punkten und Unterstützung für die im JCE definierten Algorithmen auf elliptischen Kurven. IAIK JCE Micro Edition Die IAIK JCE Micro Edition bietet zwar nicht alle Funktionen der IAIK-JCE, aber doch die wichtigsten kryptographischen Algorithmen und soll unter JME lauffähig sein. Da die ECC-Bibliothek nicht in das IAIK-JCE integriert ist und die IAIK JCE Micro Edition eine eigene BigInteger Implementierung mit liefert, welche nicht unter java.math.biginteger zu finden ist, ist eine Nutzung der ECC-Bibliothek in der IAIK JCE Micro Edition nicht ohne weiteres möglich. Weitere Provider Die Recherche ergab noch einige weniger interessante Provider, die hier nur kurz genannt werden sollen

34 Cryptix Cryptix 11 ist ein JCE Provider. Das Projekt wurde 2005, wegen zu starker Konkurenz von Bouncy Castle eingestellt. RSA BSafe Crypto-J RSA BSafe Crypto-J ist ein Krypto Provider von RSA. Hierbei handelt es sich, ähnlich wie bei IAIK um einen kommerziellen Provider von dem es auch keine kostenfreien Varianten gibt. Eine nähere Betrachtung entfällt. 3.2 BigInteger Implementierungen Wie bereits in der Einleitung zu diesem Kapitel erwähnt beinhaltet die JME keine Klasse BigInteger. Da diese aber notwendig für die Implementierung kryptographischer Algorithmen ist, werden in diesem Abschnitt verschiedene BigInteger Implementierungen auf ihre JME Konformität untersucht Original Java BigInteger Die Klasse BigInteger der Java Standard Edition ist nicht in der JME zu finden. Ein einfaches Kopieren der Klasse ist aufgrund der vielen Abhängigkeiten die in JME fehlen nicht möglich. Durch kleine Modifikationen im Code und die Hinzunahme zusätzlicher Klassen kann die Implementierung allerdings JME-konform gemacht werden. Tabelle 3.1 liefert eine detaillierte Übersicht über die Probleme und wie man sie lösen kann. Um die volle Funktionalität der Klasse BigInteger zu erhalten müssen die Klassen BitSieve, MutableBigInteger und SignedMutableBigInteger zusätzlich übernommen werden. Die Klasse BitSieve muss für die Zwecke dieser Arbeit nicht mit übernommen werden, da die Erzeugung von Primzahlen nicht nötig ist. Diese Klassen stehen, ebenso wie die Klasse BigInteger selbst, unter Copyright von Sun Microsystems 12, was den vertrieb einer Software mit verändertem BigInteger unmöglich macht FlexiBigInt Die Klasse FlexiBigInt wird im FlexiProviderME verwendet. Dabei handelt es sich um eine leicht veränderte Version des Original BigInteger. Dabei wurden alle in Tabelle 3.1 beschriebenen Probleme gelöst und die Klasse BitSieve ebenfalls übernommen, sodass eine voll funktionsfähige BigInteger- Implementierung zur Verfügung steht. Aus den bereits erwähnten Lizenzproblemen kann diese Version, und damit der FlexiProviderME, nicht vertrieben werden und steht deswegen zur Zeit nur akademischen Zwecken zur Verfügung