Java für Fortgeschrittene Proseminar im Sommersemester 2009
Werbung
Java für Fortgeschrittene Proseminar im Sommersemester 2009 Java und Kryptographie Markus Dauberschmidt, [email protected] Technische Universität München 15.06.2009 Zusammenfassung Der Kryptographie kommt in der Software-Entwicklung eine steigende Bedeutung zu, nicht nur für Transaktionen z.B. in Online-Shops, sondern auch zum Absichern privater Daten wie Passwörter. Der vorliegende Artikel beschäftigt sich damit, auf welche Weise Kryptographie in Java-Applikationen integriert werden kann. Dazu werden zunächst die Grundlagen der symmetrischen und asymmetrischen Verschlüsselung erläutert. Des Weiteren wird die Verwendung von digitalen Signaturen und Zertikaten dargestellt. Darüber hinaus zeigt der Artikel sowie ein zugehöriges Demo-Projekt, wie diese Themen in Java mit Hilfe der Bouncy Castle API bzw. dem JCE genutzt werden können. 1 Wozu eigentlich Kryptographie? Der Wunsch des Menschen, Geheimnisse vor den Augen neugieriger Mitmenschen zu verstecken, geht bis in die Antike zurück. Bereits zu Cäsars Zeiten nutzte man Verschlüsselung (Caesar Chire ), um Botschaften über die römischen Truppenbewegungen zu sichern. Auch in späteren Jahrhunderten war die Kryptographie häug im militärischen oder politischen Umfeld anzutreen. Gerade im letzten Jahrhundert hat der Bereich der Verschlüsselung eine geradezu rasante Entwicklung hinter sich. Militärische Verschlüsselungsmaschinen wie die bekannte Enigma oder die Lorenz-Maschine waren groÿen Teilen der Öentlichkeit ein Begri. Der kometenhafte Aufstieg der IT in späteren Jahren sorgte für einen rasanten Entwicklungsschub, da sich nun komplexe Algorithmen in kürzester Zeit in Computern umsetzen lieÿen. Brilliante Köpfe entwickelten ganz neue Methodiken, Daten zu verschlüsseln: die asymmetrische Kryptographie, welche heute eine nach wie vor herausragende Rolle bei der sicheren Kommunikation spielt (S/MIME, HTTPS, etc.). Sie schufen Lösungen für das alte Problem des sicheren Schlüsselaustauschs (Die Helmann Schlüsselaustausch [DH76]). Auch im nichtmilitärischen Bereich sorgte die zunehmende Globalisierung der Wirtschaft für einen gesteigerten Bedarf an Lösungen für den sicheren Austausch von Informationen, um sich vor Wirtschaftsspionage und fremden Nachrichtendiensten zu schützen. Dass diese Sorgen nicht unbegründet sind, zeigt der Fall der Firma Siemens aus dem Jahre 1993: Der Abschluÿ eines Entwicklungsauftrages für einen Hochgeschwindigkeitszug für Südkorea scheiterte deshalb, weil es dem französischen Geheimdienst gelungen war, ein gefaxtes Angebot der Firma Siemens abzufangen. Das ermöglichte es der französischen Konkurrenz, ein besseres Angebot abzugeben. Ein Fall, der ein Milliardengeschäft verhinderte [Ulf99]. Doch nicht nur in der Industrie erfreut sich die Kryptographie steigender Beliebtheit, auch der private Nutzer setzt immer häuger Kryptographie ein, ob zur Verwaltung seiner Passwörter oder zum Austausch von privaten Nachrichten mit Freunden und Bekannten. Natürlich hat auch der .com Hype und der seitdem wachsende Trend zu Online-Shopping sein übriges getan. Niemand würde heute freiwillig mehr seine Bankdaten oder seine Kreditkartennummer unverschlüsselt an einen Online-Shop senden. Die Nutzung von (starker) Kryptographie durch Dienstleister und eShops ist mittlerweile zu einer Grundvoraussetzung für ein tragendes Geschäftsmodell geworden. Unter den Begri Kryptographie fällt nicht nur die reine Datenverschlüsselung, sondern u.a. auch die Integritätsüberprüfung der Daten. Mit Hilfe von sog. digitalen Signaturen ist es heute möglich, die Unverfälschtheit einer Information zu verizieren. So können sich zum Beispiel Bank und Bankkunde sicher sein, dass ein Überweisungsauftrag nicht auf dem Weg durch das Internet zum Bankserver unerkannt verändert wurde und nun ein falscher Betrag auf einem fremden Konto landet. 1 Im Folgenden werden zunächst die beiden groÿen Klassen der symmetrischen und asymmetrischen Verschlüsselung behandelt und deren Unterschiede erläutert. Nach einem Abriss über digitale Signaturen und Hashs wird die Bouncy Castle API vorgestellt, die dem Java-Programmierer ein mächtiges Werkzeug an die Hand gibt, Kryptographie in seine Anwendungen zu integrieren. Es werden hierbei die grundlegenden Funktionen zur symmetrischen bzw. asymmetrischen Verschlüsselung, zur Generierung von Schlüsselmaterial und zur Erstellung von Signaturen betrachtet. Darauf folgt eine Erläuterung, worum es sich bei Zertikaten handelt und was CAs sind. Der Artikel schlieÿt mit einem Überblick über Kryptographie in Hardware. 2 Symmetrische und asymmetrische Verschlüsselung Gemeinhin kann man zwei groÿe Klassen der Verschlüsselung unterscheiden: Die symmetrische und die asymmetrische Verschlüsselung. 2.1 Symmetrische Verschlüsselung Bei der symmetrischen Verschlüsselung kennen sowohl Sender als auch Empfänger das Geheimins (Schlüssel), welches zum Verschlüsseln der Daten verwendet wurde. Man spricht hier auch von einem shared secret. Zum Entschlüsseln kommt der gleiche Schlüssel zum Einsatz wie auch beim Verschlüsseln. Abbildung 1: Symmetrische Verschlüsselung Die symmetrische Verschlüsselung selbst kann man wiederum in zwei groÿe Klassen einteilen: StreamChiren und Block-Chiren. Diese beiden Verfahren arbeiten grundsätzlich verschieden: 2.1.1 Block-Chiren Wie der Name suggeriert, werden bei einer Block-Chire jeweils Blöcke fester Länge der Eingabedaten verschlüsselt. Ist der letzte Block kleiner als die Blockgröÿe der Chire, so muss ein sog. Padding erfolgen, d.h. der Block muss bis zur benötigten Gröÿe mit Bytes in einer bestimmten Form aufgefüllt werden. Arbeits-Modus Normalerweise wird nie jeder Block für sich einzeln genommen verschlüsselt, sondern es kommt ein sogenannter Arbeitsmodus zum Einsatz, welcher die einzelnen Klartext- bzw. Chireblöcke zueinander in Beziehung setzt. Der einfachste Modus ist der ECB, der Electronic Code Book Modus. Hier wird wirklich jeder Block für sich separat verschlüsselt. Das groÿe Problem hierbei ist, dass gleiche Eingabeblöcke auch immer gleiche Ausgabeblöcke produzieren und damit den Chiretext anfällig für z.B. statistische Analysen machen! Um dies zu verhindern bzw. zu erschweren, gibt es verschiedene andere Arbeitsmodi, von denen der CBC vorgestellt werden soll. CBC steht für Cipher Block Chaining und bedeutet, dass jeder KlartextBlock zunächst noch mit dem vorherigen Chireblock XOR verknüpft wird, bevor er verschlüsselt wird. Auf diese Weise ist das Ergebnis also immer vom vorherigen Block abhängig und Chiretext-Analysen werden stark erschwert. Ein Problem existiert natürlich am Anfang: Womit wird der allererste Block verknüpft? Hier kommt der sogenannte IV, der Initialisierungsvektor, ins Spiel. Dieser liefert die Daten, 2 Abbildung 2: Arbeitsweise des ECB Modus mit denen der erste Klartextblock XOR verknüpft wird, bevor er danach verschlüsselt wird. Der IV muss nicht geheim gehalten werden, sollte aber möglichst zufällig gewählt sein. Abbildung 3: Arbeitsweise des CBC Modus Sind die Blöcke bei der Ver- und Entschlüsselung voneinander abhängig, können sich Bitfehler bei der Übertragung natürlich katastrophal auswirken. Beim CBC ist es jedoch so, dass ein Bitfehler im Block N immer nur den nachfolgenden Block N + 1 verfälscht, sich Fehler also nicht beliebig lange fortpanzen. Neben diesen beiden Modi gibt es weitere, die aus der Blockverschlüsselung de facto eine Stromverschlüsselung machen. Hierzu zählen zum Beispiel die Modi OFB (Open Feedback), CFB (Cipher Feedback) und CTR (Counter Mode). Mehr zu diesen Modi ndet man in der einschlägigen Literatur unter [Sch96], [Sch07]. Die wohl bekanntesten Vertreter der Klasse der Blockchiren sind AES (Rijndael), DES, 3DES, Twosh und Blowsh. Die Rijndael-Chire wurde im Rahmen einer NIST Ausschreibung zum Sieger eines Wettbewerbes gewählt, bei dem es darum ging, einen Nachfolger für den bis dahin dominierenden Verschlüsselungsalgorithmus DES bzw. 3DES zu nden. Rijndael hat sich gegen eine Reihe von Chiren von bekannten Persönlichkeiten der Kryptowelt (Ron Rivest, Bruce Schneier) durchsetzen können und wurde dadurch der neue Standard (AES = Advanced Encryption Standard) was symmetrische Verschlüsselung angeht. AES wird heute in so gut wie jeder Anwendung unterstützt, die symmetrische Verschlüsselung einsetzt. Eine Erläuterung, wie der AES funktioniert, ndet sich unter [Zab]. 2.1.2 Strom-Chiren Im Gegensatz zu einer Block-Chire muss bei einer Strom-Chire nicht darauf gewartet werden, dass sich genügend Klartext-Daten angesammelt haben, so dass ein Block verschlüsselt werden kann, sondern die Verschlüsselung kann sofort beim ersten Bit begonnen werden. Hierdurch ergibt sich ein kleiner Geschwindigkeitsvorteil, der Strom-Chiren besonders für Echtzeitübertragungen sinnvoll macht, wie 3 beispielsweise im Mobilfunk zur Verschlüsslung von Gesprächsdaten. Die Klartextdaten werden beim Einsatz einer Strom-Chire mit einem Bitstrom (auch Schlüsselstrom genannt) XOR verknüpft. Die Entwicklung des Schlüsselstroms hängt dabei von den bisher verschlüsselten Daten ab. Strom-Chiren können sehr sicher verwendet werden, jedoch nur, wenn beachtet wird, dass derselbe Startzustand (Initialization vector, IV) nie mehrfach verwendet wird. Die Sicherheit einer Strom-Chire kann der idealen Sicherheit eines One-Time-Pad nahe kommen. Einem One-Time-Pad (OTP) liegt kein fester Algorithmus zugrunde, sondern der Schlüsselstrom wird komplett zufällig gebildet. Da durch die Zufälligkeit kein Ansatz zur Ermittlung des Schlüssels gegeben ist, gilt ein OTP als unbrechbar sofern echte Zufallszahlen zum Einsatz kommen. In der Praxis werden OTPs jedoch sehr selten verwendet, da die wirklich zufällige Generierung von ausreichend langen Zufallszahlenketten alles andere als trivial ist. Generatoren, die Zahlen zufällig rein durch SoftwareAlgorithmen bestimmen, nennt man pseudo-random, da sie nie wirklich zufällig sind. Echte Zufallszahlen erzeugt man durch die Einbeziehung nichtdeterministischer externer Einüsse, wie z.B. Sensoren, die Spannungsschwankungen oder Temperaturunterschiede an Motherboard-Komponenten miteinbeziehen. Ein interessanter Artikel ndet sich unter [tru] oder auch in [Lau09]. Allen Verfahren der symmetrischen Verschlüsselung ist gemein, dass sie in der Regel eine sehr hohe Verschlüsselungs- und Entschlüsselungsgeschwindigkeit erreichen, d.h. auch das Verschlüsseln von groÿen Datenmengen ist hiermit performant möglich. Dies liegt darin begründet, dass normalerweise für die Verschlüsselungsvorgänge relativ einfache arithmetische Operationen wie Multiplikationen und Additionen verwendet werden, sowie Ersetzungen der Daten vorgenommen werden (Substitutionsschritte und Diusion). Ein weiterer Vorteil ist darin zu sehen, dass aufgrund der Einfachheit der algebraischen Umformungen der Verschlüsselungsalgorithmus in der Regel auch sehr gut in Hardware umgesetzt werden kann und hiermit sehr hohe Geschwindigkeiten möglich sind. Die Schlüssellängen bei Block-Chiren sind, als bei der asymmetrischen Verschlüsselung, relativ kurz mit in der Regel 128, 192 oder 256 Bit Schlüssellänge. In der Natur des shared secrets, welches dem Empfänger und dem Sender der Nachricht vorliegen muss, liegt aber auch das gröÿte Problem der symmetrischen Kryptographie. Das gemeinsame Geheimnis muss zunächst auf einem sicheren Weg zwischen den beiden Kommunikationspartnern ausgetauscht werden! Erlangt ein Angreifer bei diesem Austauschprozess Kenntnis von dem geheimen Schlüssel, ist die Verschlüsselung zwecklos, da der Angreifer die Daten nun jederzeit entschlüsseln kann (je nach Vorgehen). Eine Abhilfe für dieses Dilemma fand im Jahre 1976 das Forscherduo Whiteld Die und Martin Hellman mit der Erndung des Die-Hellman Algorithmus zum sicheren Schlüsselaustausch (für weitere Information siehe [DH76]). Diese Forschungsarbeiten bildeten das Fundament für die asymmetrische Verschlüsselung. 2.2 Asymmetrische Verschlüsselung Der grundlegende Unterschied der asymmetrischen Verschlüsselung zur symmetrischen Verschlüsselung besteht darin, dass für die Ver- und Entschlüsselung zwei unterschiedliche Schlüssel zum Einsatz kommen. Man spricht von einem Schlüsselpaar und von dem privaten Schlüssel und dem öentlichen Schlüssel. In Anlehnung an diese Namensgebung bezeichnet man die asymmetrische Verschlüsselung auch häug als private/public key cryptography. Für die konsequente Nutzung wird eine sogenannte PKI (Private/Public Key Infrastructure) benötigt. Den Teil des Schlüssels, der zum Entschlüsseln der Daten verwendet wird, bezeichnet man als Private Key. Dieser wird, wie der Name schon suggeriert, geheim gehalten. Der Schlüsselteil, mit dem die Daten an den Besitzer des Private Keys verschlüsselt werden, bezeichnet man als Public Key. Dieser ist, wie ebenfalls am Namen ersichtlich, öentlich. Häug werden die öentlichen Schlüssel in sogenannten Key Respositories im Internet hinterlegt (häug sind dies LDAP-Verzeichnisse). Ein Verfahren, welches Daten asymmetrisch verschlüsselt, ist das RSA-Kryptosystem [RSA78], dessen Bezeichnung sich aus den Anfangsbuchstaben der Namen seiner Ernder Ron Rivest, Adi Shamir und Leonard Adleman ableitet. Eine kurze und leicht verständliche Einführung ndet sich unter [rsa], [Sch07], [Sch96] und [Sin01]. Im Gegensatz zur symmetrischen Verschlüsselung setzt die asymmetrische Verschlüsselung auf komplexe Operationen zur Verschlüsselung. Eine asymmetrische Verschlüsselung von Daten ist daher häug wesentlich teurer in der Ausführung als eine symmetrische Verschlüsselung. Ebenso werden bei der asymmetrischen Verschlüsselung weitaus längere Schlüssellängen verwendet (i.d. R. normalerweise 1024 Bit, häug auch 2048 Bit, selten 4096 Bit). Dies liegt darin begründet, dass die Sicherheit des Verfahrens 4 zu einem guten Stück auch von der Schlüssellänge abhängt. In der Praxis wird die asymmetrische Verschlüsselung daher häug nur auf relativ kleine Datenmengen angewandt und mit der symmetrischen Verschlüsselung kombiniert: Die eigentliche Datenverschlüsselung der Nutzdaten geschieht mit einem symmetrischen Verfahren (wie z.B. dem AES), welches eine hohe Geschwindigkeit bietet. Der hierfür verwendete Schlüssel wird aber dann wiederum stark asymmetrisch (z.B. mit RSA) verschlüsselt. Häug gibt es auch noch den Fall, dass der symmetrische Schlüssel nach regelmäÿigen Intervallen (z.B. 1 Stunde, 1 MByte Nutzdaten, o.ä.) gewechselt wird, um die Sicherheit weiter zu erhöhen. In den letzten Jahren hat vor allem auch die ECC, die Elliptic Curve Cryptography, von sich reden gemacht, die aufgrund eines anderen Ansatzes eine ähnliche Sicherheit bei weitaus höherer Verschlüsselungsgeschwindigkeit und verringerter Schlüssellänge bietet ([Sch07]). 3 Digitale Signaturen & Hashs Mit Hilfe einer Digitalen Signatur ist es möglich, die eingangs erwähnte Verikation von übermittelten Daten durchzuführen. Die Signatur ist gewissermaÿen das Spiegelbild zur asymmetrischen Verschlüsselung, da hier im Endeekt nur der Einsatz der Schlüssel vertauscht wird. Für die Erstellung der Signatur wird der private Schlüssel verwendet und für die Verikation kommt der öentliche Schlüssel zum Einsatz. Da es aufgrund der Nachteile der asymmetrischen Kryptographie jedoch extrem zeitaufwändig wäre, die gesamten Daten mit dem Private Key zu verschlüsseln (=signieren), bedient man sich einer Abkürzung: Es wird ein Hash/Digest, ein digitaler Fingerabdruck, der Daten genommen und dieser wird verschlüsselt. Dieser Digest wird mit Hilfe einer kryptographischen Hashfunktion gebildet. Das Ergebnis der Anwendung einer kryptographischen Hashfunktion auf einen Eingabetext ist eine Hexzahlenfolge, welche mit üblicherweise 16, 20 oder 32 Byte sehr kurz ist und den gesamten Text repräsentiert. Das Besondere ist, dass das Verändern auch nur eines einzigen Bits im Eingabetext (Ändern einer Zahl, Entfernen eines unsichtbaren Whitespaces o.ä.) zu einem völlig veränderten Digest führen wird. Dieser Hash wird nun mit Hilfe des Private Keys signiert. Zur Verikation der Signatur geht der Empfänger wie folgt vor: Er bildet seinerseits den Hash über die Nachricht, entschlüsselt bzw. veriziert die Signatur mit Hilfe des Public Keys des Senders und vergleicht den erhaltenen Wert mit seinem eigenen errechneten Hashwert. Stimmen beide Werte überein, so kann er sich (relativ) sicher sein, dass die Nachricht nicht verändert wurde, während eine Abweichung ein Indiz dafür ist, dass irgendetwas an den Daten manipuliert wurde. Es gibt heutzutage einige kryptographische Hashfunktionen, unter denen man wählen kann. Der am häugsten eingesetzte Hashalgorithmus ist seit vielen Jahren MD5, welcher wie der RSA-Algorithmus aus der Feder von Ron Rivest stammt. Nachdem jedoch einige Angrie bekannt geworden sind, wird mittlerweile davon abgeraten, MD5 für neue Signaturen einzusetzen. Ein alternatives, von der NSA mitentwickeltes Verfahren, SHA-1, hat in der Zwischenzeit viel Boden gut gemacht. Jedoch sind mittlerweile auch an SHA-1 Schwachstellen entdeckt worden. Die Nachfolge-Algorithmen SHA-256 und SHA-512 haben bislang keine Schwachstellen aufgezeigt. Natürlich lassen sich Verschlüsselung und Signatur auch kombinieren, um die Daten vor fremden Blicken zu schützen und die Integrität zu gewährleisten. Hierbei ist es jedoch nicht unerheblich, ob zuerst verschlüsselt und dann signiert wird oder umgekehrt! Normalerweise wird stets zunächst signiert und dann verschlüsselt, denn dann ist eine bewusste Veränderung der Daten durch einen Angreifer ausgeschlossen, da dieser nicht in der Lage ist, die Daten zu entschlüsseln, um die Unterschrift zu fälschen. 4 JCE & Bouncy Castle Mittels der JCE (Java Cryptographic Extension) innerhalb der JCA (Java Cryptographic Architecture) hat Sun bereits sehr früh (Java 1.2) den Grundstein zur Nutzung von kryptographischen Funktionen in seiner Klassenbibliothek gelegt. War die JCE anfangs noch als separater Download erhältlich, so ist sie seit Java 1.4 fester Bestandteil des J2SDK. Die JCE gliedert sich nahtlos in das JCF, das Java Component Framework, ein. Die tatsächliche Umsetzung der kryptographichen Funktionen wird durch sog. Provider erbracht. Sun liefert einen nativen Provider für alle gängigen Kryptographie-Szenarien mit, der Entwickler kann aber auch zusätzliche Provider in Form von Plugins nachrüsten. Ein solcher Provider ist z.B. die Bouncy-Castle (BC) Klassenbibliothek, um die es in diesem Artikel gehen soll. Diese Provider können sich z.B. in der Anzahl der unterstützen Verschlüsselungsalgorithmen 5 Abbildung 4: Der JCE Provider Selektionsmechanismus unterscheiden, in der maximal möglichen Schlüssellänge usw. Der Entwickler kann sich beim Nutzen der kryptographischen Funktionen entscheiden, welchen Provider er verwenden möchte. Wird keine Vorselektion des Providers durch den Entwickler getroen, so kümmert sich die JCE um die Auswahl eines Providers [Sun05]. Sun liefert mit dem JDK bereits eine ganze Reihe von spezialisierten Providern mit, u.a. auch einen Wrapper für den Zugri auf die nativen Windows-CryptoAPI-Funktionen. Die Wahl des Provider-Konzeptes bringt eine Reihe von Vorteilen mit sich: • Anwendungen sind nicht fest an einen Provider gebunden. Provider können (in den meisten Fällen) transparent ausgetauscht werden, ohne dass die nutzende Applikation verändert werden muss. • Der Entwickler befasst sich nicht mit der eigentlichen Implementierung der kryptographischen Verfahren, sondern kann sich auf deren Nutzung innerhalb seiner Applikation konzentrieren. • Neue oder proprietäre Algorithmen können einfach nachgerüstet werden. Ein Mischen verschiedener Provider innerhalb einer Anwendung ist zwar möglich, es wird jedoch davon abgeraten. Um die Beispiele im weiteren Verlauf dieses Artikels nachvollziehen zu können, müssen die BC Klassenbibliothek und die umlimited strength Policy-Files installiert werden. Eine Anleitung hierfür ndet sich in [Dau09]. 5 Die wichtigsten Klassen für die symmetrische Verschlüsselung Alle mit der Java-Standardbibliothek ausgelieferten Klassen und Interfaces liegen im Paket javax.crypto und in dessen Unterpaketen. Aus diesem Paket werden die folgenden Klassen kurz vorgestellt: • javax.crypto.Cipher • javax.crypto.spec.IvParameterSpec • javax.crypto.spec.SecretKeySpec • javax.crypto.spec.PBEKeySpec • javax.crypto.SecretKeyFactory • javax.crypto.KeyGenerator 6 5.1 Die Cipher-Klasse Mit Hilfe von Methoden der Cipher-Klasse können Daten verschlüsselt werden. Egal welches Verfahren und welche Schlüssellänge verwendet werden soll, es werden stets die selben vier Methoden verwendet. Von allen Methoden gibt es diverse Überladungen. • public static Cipher Cipher.getInstance(String algo, String provider) Über diesen Methodenaufruf wird der Verschlüsselungsalgorithmus, der Modus, das Padding und der Provider ausgewählt. algo ist hierbei ein String wie z.B. DES/CBC/PKCS5Padding, welcher in diesem Fall ein Objekt zurückliefert, mit dem Daten via DES im CBC Modus verschlüsselt werden können. Das Padding wird gemäÿ PKCS#5 durchgeführt. provider deniert den zu nutzenden Provider. Für unsere Beispiele ist dies stets BC, um die BC API zu nutzen. • public void Cipher.init(int mode, Key key) Mit Hilfe dieser Methode wird der Modus (ENCRYPT_MODE, DECRYPT_MODE) gesetzt und der Key deniert, der für die Verschlüsselung verwendet werden soll. Die Init-Methode muss stets aufgerufen worden sein, bevor eine update() oder doFinal()-Operation ausgeführt wird. • public int Cipher.update(byte[] input, int iOffset, int iLen, byte[] output, int oOffset) und public int Cipher.doFinal(byte[] input, int iOffset, int iLen, byte[] output, int oOffset) Hiermit wird die Verschlüsselung des Plaintextes input ab dem Oset iOffset für iLen Zeichen durchgeführt und in den Ausgabe-Puer output ab Index oOffset geschrieben. Die doFinal()-Methode schlieÿt den Verschlüsselungsvorgang ab. Danach wird die Chire in den gleichen Zustand zurückversetzt, in dem sie nach dem Aufruf von init() war. Es ist auch möglich, den gesamten Plaintext mittels eines Aufrufes von doFinal() zu verschlüsseln. Ob segmentweise (mittels update()) oder alles auf einmal (mittels doFinal()) verschlüsselt wird, wird durch den Problemfall bestimmt. 5.2 Die IvParameterSpec-Klasse Die Klasse IvParameterSpec repräsentiert einen Initialisierungs-Vektor (IV) (siehe dazu auch 2.1.1). Bei der Verschlüsselung kann der IV auch durch das Cipher-Objekt automatisch erzeugt werden. Für die Entschlüsselung muss der IV aber auf jeden Fall gesichert werden und dem Empfänger übermittelt werden. Häug wird der IV einfach an die verschlüsselte Nachricht angehängt. • public IvParameterSpec(byte[] iv) erzeugt ein IvParameterSpec-Objekt. • public byte[] getIv() gibt den IV zurück. 5.3 Die SecretKeySpec-Klasse Die Klasse SecretKeySpec repräsentiert einen symmetrischen Verschlüsselungsschlüssel. Verschiedene Crypto-Algorithmen, wie z.B. AES, nutzen nicht direkt einen Schlüssel, sondern leiten aus diesem Schlüssel die tatsächlichen Schlüssel ab. Für AES werden z.B. zehn verschiedene Schlüssel genutzt. • public SecretKeySpec(byte[] key, String algo) Der Parameter key gibt hierbei den Schlüssel an, algo den zu verwendenden Algorithmus. Diese Klasse ist nicht dafür gedacht, das verwendete Passwort für eine Verschlüsselung als byte[] entgegenzunehmen, hierfür ist die Klasse PBEKeySpec vorgesehen. Wie groÿ das übergebene byte[] sein muss, wird durch die Wahl des Verschlüsselungsalgorithmus vorgegeben. Im Falle von DES muss es z.B. 8 Byte lang sein. Eine Überprüfung ndet (hier) nicht statt! Es versteht sich von selbst, dass der angegebene algo im Konstruktor zum Algorithmus des Cipher-Objektes passen muss, damit die beiden Objekte miteinander harmonieren. 7 • public byte[] getEncoded() gibt das byte[] zurück, welches den Schlüssel repräsentiert. Dies kann nützlich sein, wenn man den Schlüssel zufällig hat berechnen lassen. Wurde der Schlüssel z.B. in einer Smartcard oder in einem Token erstellt (siehe Abschnitt 9), so ist dieser in der Regel nicht exportierbar und getEncoded() wird null zurückliefern. 5.4 Die PBEKeySpec und SecretKeyFactory Klassen Die Klasse SecretKeyFactory kann zusammen mit der PBEKeySpec Klasse verwendet werden, um einen symmetrischen Schlüssel aus einem Passwort abzuleiten. Gemeinhin wird nie das Passwort selbst für die Verschlüsselung verwendet, sondern der eigentliche Schlüssel immer nach einem festen Algorithmus daraus abgeleitet. Weit verbreitete Algorithmen hierfür sind jene, welche in den Standards PKCS#5[RSA99b] und PKCS#12[RSA99a] deniert sind (z.B. PBEWithSHAAnd3KeyTripleDES, welches das SHA-Verfahren und 3DES verwendet, um den Key abzuleiten). Der Entwickler hat in jedem Fall dafür Sorge zu tragen, dass das genutzte Passwort nicht trivial ist, denn davor besteht kein Schutz. • public PBEKeySpec(char[] password, byte[] salt, int iterationCount, int keyLength) erzeugt ein PBEKeySpec-Objekt. Das übergebene Passwort wird hierbei als char[] übergeben und nicht als String, damit es möglich ist, das Passwort im Speicher wieder explizit zu löschen. Damit aus demselben Passwort nicht stets in denselben Schlüssel konvertiert wird, wird ein sogenanntes Salt verwendet. Unter einem Salt versteht man einen Zufallswert (z.B. Uhrzeit), welcher zusammen mit dem Passwort in die Generierungsfunktion einieÿt, und somit das Ergebnis individualisiert. Dies macht es möglich, das gleiche Passwort für unterschiedliche Zwecke zu verwenden und dennoch jedesmal einen anderen Schlüssel zu erhalten. Ein Angreifer kann dann nicht erkennen, ob es sich stets um das gleiche Ausgangspasswort handelt oder um unterschiedliche Passwörter, die er knacken muss. Das Salt ist normalerweise so groÿ wie die Hash-Länge des für die Schlüsselaufbereitung verwendeten Hashalgorithmus. Würde kein Salt verwendet, und ein Passwort aus einem Wörterbuch verwendet, welches 100 verschiedene Wörter enthält, so muss der Angreifer nur 100 Varianten durchprobieren. Wird jedoch ein Salt verwendet, von dem man weiÿ, dass es 8 Bit lang ist, so gibt es für jedes dieser 100 Worte jweils noch 256 unterschiedliche Salt-Werte, die auch in Kombination durchprobiert sein wollen. Der Algorithmus zur Schlüsselaufbereitung wird iterationCount oft durchlaufen. Hierdurch erhöht sich der Aufwand zusätzlich für einen Angreifer. keylength letztlich bestimmt, wie lang (in Bit) der aufbereitete SecretKey werden soll. Die SecretKeyFactory Klasse verwendet die Vorgaben im PBEKeySpec Objekt, um damit nach einem vorgegebenen Algorithmus den tatsächlichen Schlüssel zu erzeugen. • public static SecretKeyFactory getInstance(String factory, String provider) gibt ein SecretKeyFactory Objekt zurück, welches die übergegebene Factory factory verwendet, um den Schlüssel abzuleiten. provider ist wie in den anderen Beispielen in diesem Text der BouncyCastle Provider BC. • public SecretKey generateSecret(PBEKeySpec spec) gibt den aufbereiteten SecretKey zurück, welcher nun mit dem Cipher-Objekt genutzt werden kann. 5.5 Die KeyGenerator Klasse Um symmetrische Schlüssel zu erzeugen, kann auch direkt die KeyGenerator-Klasse verwendet werden. Wie für JCE üblich, wird auch hier ein Objekt mit getInstance() geholt. Dem getInstance() Aufruf wird hierbei der Algorithmus und der Provider übergeben. Beispiel: KeyGenerator generator = KeyGenerator.getInstance(AES, BC) erzeugt einen KeyGenerator für AES-Schlüssel. • public final void init(int keysize) initialisiert den Key-Generator und gibt eine Schlüssellänge von keysize Bit vor. 8 • public final SecretKey generateKey() erzeugt einen neuen symmetrischen Schlüssel und gibt ihn als SecretKey Objekt zurück. Der grundlegende Unterschied zwischen einer KeyFactory und KeyGenerator liegt im Prinzip der Schlüsselerzeugung. Mit einer KeyFactory wird ein KeySpec-Objekt in ein SecretKey-Objekt und zurück konvertiert, was häug für den Transport von Schlüsselmaterial verwendet wird. Man besitzt hier also in der Regel den eigentlichen Schlüssel bereits. Dahingegen ist ein KeyGenerator nur dafür da, einen neuen Schlüssel aus dem Nichts zu erzeugen. In manchem Fällen (z.B. Password-Based Key-Generation) gibt es gar keinen Generator, sondern es muss eine Factory verwendet werden. 5.6 Beispiel Folgendes Code-Beispiel nutzt die soeben vorgestellten Klassen und verschlüsselt den Text Hello World mit dem Passwort ThePassword1! mit dem 3DES-Algorithmus im CBC Verfahren und entschlüsselt ihn danach wieder. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ... String String byte [ ] byte [ ] i = " H e l l o World ! " ; password = " ThePassword1 ! " ; i n p u t = i . toByteArray ( ) ; s a l t = new byte [ ] {0 xca , 0 x f e , 0xba , . . . } ; // 16 random Bytes PBEKeySpec pbeSpec = new PBEKeySpec ( password . toCharArray ( ) , s a l t , 2 0 4 8 ) ; // 2048 rounds S e c r e t K e y F a c t o r y s k f = S e c r e t K e y F a c t o r y . g e t I n s t a n c e ( " PBEWithSHAAnd3KeyTripleDES " , "BC" ) ; SecretKey sKey = s k f . g e n e r a t e S e c r e t ( pbeSpec ) ; Cipher c i p h e r = Cipher . g e t I n s t a n c e ( " DESede/CBC/PKCS7Padding " , "BC" ) ; // e n c r y p t c i p h e r . i n i t ( Cipher .ENCRYPT_MODE, sKey ) ; IvParameterSpec i v = c i p h e r . getIV ( ) ; // Save t h e auto −g e n e r a t e d IV f o r l a t e r u s e byte [ ] c i p h e r T e x t = c i p h e r . d o F i n a l ( i n p u t ) ; // c i p h e r T e x t c o n t a i n s now t h e e n c r y p t e d data // t r a n s f e r c i p h e r T e x t t o t h e r e c e i v e r . . . // d e c r y p t c i p h e r . i n i t ( Cipher .DECRYPT_MODE, sKey , i v ) ; // We need t o p r o v i d e t h e c o r r e c t IV ! byte [ ] d e c r y p t e d = c i p h e r . d o F i n a l ( c i p h e r T e x t ) ; System . out . p r i n t l n ( new S t r i n g ( d e c r y p t e d ) ) ; ... Listing 1: Symmetrische Verschlüsselung mit 3DES Die Eingabeparameter für die Verschlüsselung müssen in Form von byte[] vorliegen. Als Eingabeparameter werden benötigt: input, der eigentlichen Text, der verschlüsselt werden soll, sowie salt, ein byte[] mit Zufallswerten, welches für die Key-Erzeugung verwendet wird. Damit man einen nutzbaren SecretKey erhält, muss man die SecretKeyFactory verwenden. Der Schlüssel soll aus einem Passwort erzeugt werden (PBEKeySpec), deswegen wird der Generator PBEWithSHAAnd3KeyTripleDES verwendet. SecretKeyFactory skf = SecretKeyFactory.getInstance("PBEWithSHAaAnd3KeyTripleDES", "BC"); Durch den Aufruf SecretKey sKey = skf.generateSecret(pbeSpec) erhält man nun die Schlüsselbytes. In Zeile 11 wird ein Cipher-Objekt geholt, welches mit dem 3DES im CBC-Mode und PKCS7Padding verschlüsselt. Es wird ein Padding benötigt, da 3DES eine Blockgröÿe von 16 Bytes vorausetzt, unser Inputtext jedoch weniger als 16 Bytes umfasst. Wichtigster Schritt vor dem Beginn der Verschlüsselung ist die Initialisierung des Cipher-Objektes durch den Aufruf der init()-Methode in Zeile 13. Diesem Aufruf gibt man den Modus ENCRYPT_MODE und den Key mit. Da kein IV übergeben wurde, erzeugt das Cipher-Objekt diesen intern aus einem SecureRandom-Objekt. Dieser IV muss nun unbedingt gesichert werden und dem Empfänger bekannt 9 gemacht werden, da ohne ihn die Entschlüsselung des 1. Blockes nicht mehr möglich ist. Die eigentliche Verschlüsselung des Textes erfolgt nun durch den Aufruf cipher.doFinal(input), welcher den byte[] Input nimmt, diesen mit dem kongurierten Algorithmus verschlüsselt und ein byte[] zurückgibt. Die Entschlüsselung des Cipher-Textes erfolgt analog, allerdings muss hier beim Aufruf von init() nun der IV mitgegeben werden. Ansonsten wird eine Exception geworfen, da der 3DES im CBC zwingend einen IV vorausetzt. Des Weiteren muss nun die Konstante Cipher.DECRYPT_MODE im Aufruf von cipher.init() übergeben werden. In der Praxis wird der IV häug einfach als allererster Block den verschlüsselten Daten vorangestellt, da er nicht geheim gehalten werden muss. Soll mit dem AES-Algorithmus verschlüsselt werden, muss eine andere SecretKeyFactory verwendet werden: PBEwithSHAand128bitAES-CBC-BC. Alternativ kann der Schlüssel auch mit dem empfohlenen PKCS#5-Verfahren abgeleitet werden: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... S t r i n g password = " ThePassword1 ! " ; byte [ ] i n p u t = " H e l l o world " . toByteArray ( ) ; PKCS5S2ParametersGenerator g e n e r a t o r = new PKCS5S2ParametersGenerator ( ) ; g e n e r a t o r . i n i t ( PBEParametersGenerator . PKCS5PasswordToBytes ( password . toCharArray ( ) ) , s a l t , 2048) ; ParametersWithIV params = ( ParametersWithIV ) g e n e r a t o r . g e n e r a t e D e r i v e d P a r a m e t e r s (128 , 128) ; KeyParameter keyParam = ( KeyParameter ) params . g e t P a r a m e t e r s ( ) ; SecretKeySpec key = new SecretKeySpec ( keyParam . getKey ( ) , "AES" ) ; Cipher a e s = Cipher . g e t I n s t a n c e ( "AES/CBC/PKCS5Padding " ) ; IvParameterSpec i v S p e c = new IvParameterSpec ( params . getIV ( ) ) ; a e s . i n i t ( Cipher .ENCRYPT_MODE, key , i v S p e c ) ; aes . doFinal ( input ) ; ... Listing 2: Schlüsselableitung beim AES 6 Asymmetrische Verschlüsselung von Daten, Hashfunktionen und Signaturen Der folgende Abschnitt zeigt, wie ein Hash bzw. Message-Digest erstellt wird, um die Integrität von Daten zu überprüfen. Auÿerdem werden zwei Verfahrenvorgestellt, um RSA-Schlüssel zu erzeugen. Es wird gezeigt, wie man damit verschlüsseln und Daten signieren kann. 6.1 MessageDigests Ein Hash/Digest-Objekt wird durch die Klasse MessageDigest repräsentiert. Es hat ähnliche Methoden wie das Cipher-Objekt. 6.1.1 Die Klasse MessageDigest • public static MessageDigest getInstance(String algo, Provider provider) Diese Klassenmethode liefert ein Digest-Objekt des Typs algo vom Provider provider zurück. • public void update(byte[] input, int offset, int len) lässt len Bytes ab Stelle offset aus dem Array input in die Berechnung des Hashs einieÿen. • byte[] digest() schlieÿt die Berechnung des Message Digest ab und liefert diesen als byte[] zurück. • static boolean isEqual(byte[] a, byte[] b) überprüft zwei übergebene Digest-Werte auf Gleichheit. Die beiden Digests sind normalerweise der übergebene und der selbst erstellte Digest. 10 Der Hash wird normalerweise verschlüsselt an die zu übertragenden Daten angehängt. Dazu nutzt man die abschnittsweise Verschlüsselung mit Hilfe der Methode update() des Cipher-Objektes(!). Dies könnte z.B. wie folgt implementiert werden: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 ... Cipher c i p h e r = Cipher . g e t I n s t a n c e ( "AES/CTR/ NoPadding " , "BC" ' ) ; byte [ ] i n p u t = 0 xca , 0 x f e , 0xba , 0 xbe , 0x . . . ; // 32 data b y t e s Key key = ... IvParameterSpec = . . . M e s s a g e D i g e s t hash = M e s s a g e D i g e s t . g e t I n s t a n c e ( "SHA− 1" , "BC" ) ; // e n c r y p t & hash c i p h e r . i n i t ( Cipher .ENCRYPT_MODE, key , i v S p e c ) ; byte [ ] c i p h e r T e x t = new byte [ c i p h e r . g e t O u t p u t S i z e ( i n p u t . l e n g t h ) + hash . getDigestLength () ) ] ; i n t c tLe ng th = c i p h e r . update ( input , 0 , i n p u t . l e n g t h ( ) , c i p h e r T e x t , 0 ) ; hash . update ( i n p u t ) ; ct Le ngt h += c i p h e r . d o F i n a l ( hash . d i g e s t ( ) , 0 , hash . g e t D i g e s t L e n g t h ( ) , c i p h e r T e x t , ctLe ng ht ) ; // d e c r y p t & check hash c i p h e r . i n i t ( Cipher .DECRYPT_MODE, key , i v S p e c ) ; byte [ ] pText = c i p h e r . d o F i n a l ( c i p h e r T e x t , 0 , c tLe ng th ) ; i n t msgLength = pText . l e n g t h − hash . g e t D i g e s t L e n g t h ( ) ; hash . update ( pText , 0 , msgLength ) ; byte [ ] msgHash = new byte [ hash . g e t D i g e s t L e n g t h ( ) ] ; System . a r r a y c o p y ( pText , msgLength , msgHash , 0 , msgHash . l e n g t h ) ; i f ( ! M e s s a g e D i g e s t . i s E q u a l ( hash . d i g e s t ( ) , msgHash ) { // e r r o r h a n d l i n g } ... Listing 3: Ein Beispiel für einen SHA-1 MessageDigest 6.2 RSA Natürlich bietet BC auch Klassen an, um Daten mit dem RSA-Verfahren zu verschlüsseln. Die wichtigesten Konstrukte werden im Folgenden vorgestellt. 6.2.1 Die KeyPairGenerator-Klasse Die Klasse KeyPairGenerator kann genutzt werden, um ein zufälliges RSA-Schlüsselpaar bestehend aus Private Key und Public Key zu erzeugen. • public static KeyPairGenerator getInstance(String algo, Provider provider) Über die statische getInstance()-Methode erhält man das KeyPairGenerator-Objekt, auf dem man die folgenden Methoden aufrufen kann. Um einen Generator vom Typ RSA zu erhalten, lautet der Aufruf: KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA", "BC"). • public void initialize(int keysize) Mit Hilfe der initialize-Methode kann vorgegeben werden, wie lang die RSA Schlüssel werden sollen. In der Praxis sinnvolle Werte sind 1024, 2048 oder 4096. • public KeyPair generateKeyPair() erzeugt das RSA Schlüsselpaar und gibt ein KeyPair-Objekt zurück. 11 6.2.2 Die Klasse KeyPair Die Klasse KeyPair repräsentiert ein Schlüsselpaar. Die beiden public Methoden getPrivate() und getPublic() geben das jeweilige Schlüsselpaar als PrivateKey bzw. PublicKey zurück. Ein Beispiel soll die folgende Anwendung verdeutlichen: 1 2 3 4 5 6 7 ... KeyPairGenerator g e n e r a t o r = KeyPairGenerator . g e t I n s t a n c e ( "RSA" , "BC" ) ; g e n e r a t o r . i n i t i a l i z e ( 1 0 2 4 ) ; // We want 1024 b i t k e y s KeyPair p a i r = g e n e r a t o r . g e n e r a t e K e y P a i r ( ) ; PublicKey pubKey = p a i r . g e t P u b l i c ( ) ; PrivateKey privKey = p a i r . g e t P r i v a t e ( ) ; ... Listing 4: Erzeugen eines Zufalls-RSA-Schlüsselpaars 6.2.3 Die Klassen RSAPublicKeySpec und RSAPrivateKeySpec Diese beiden Klassen können zusammen mit einer KeyFactory-Klasse verwendet werden, um RSAPublicKey und RSAPrivateKey-Objekte anhand vorgegebener Parameter zu erzeugen. • public RSAPrivateKeySpec(BigInteger modulus, BigInteger privateExponent) • public RSAPublicKeySpec(BigInteger modulus, BigInteger publicExponent) Die Konstruktoren der beiden Klassen erzeugen die jeweiligen Schlüsselpaarbeschreibungs-Objekte mit den übergebenen Generator-Primzahlen modulus bzw. private/publicExponent. Mit Hilfe der aus dem AES-Beispiel schon bekannten KeyFactory können nun die Schlüssel generiert werden: 1 2 3 4 5 6 7 ... KeyFactory ke yFac tory = KeyFactory . g e t I n s t a n c e ( "RSA" , "BC" ) ; RSAPublicKeySpec pubKeySpec = new RSAPublicKeySpec ( new B i g I n t e g e r ( " d 4 6 f 4 7 3 a 2 d 7 4 6 5 3 7 d e 2 0 5 6 a e 3 0 9 2 c 4 5 1 " , 1 6 ) , new B i g I n t e g e r ( " 1 1 " , 1 6 ) ; RSAPrivateKeySpec pubKeySpec = new RSAPrivateKeySpec ( new B i g I n t e g e r ( " d 4 6 f 4 7 3 a 2 d 7 4 6 5 3 7 d e 2 0 5 6 a e 3 0 9 2 c 4 5 1 " , 1 6 ) , new B i g I n t e g e r ( " 5 7 7 9 1 d5430d593164082036ad8b29fc1 " , 1 6 ) ; RSAPublicKey pubKey = ( RSAPublicKey ) k eyFa cto ry . g e n e r a t e P u b l i c ( pubKeySpec ) ; RSAPrivateKey privKey = ( RSAPrivateKey ) k eyFa ctor y . g e n e r a t e P r i v a t e ( privKeySpec ) ; ... Listing 5: Erzeugen eines vordenierten RSA-Schlüsselpaars Nachdem das RSA-Schlüsselpaar erzeugt wurde, wird die bereits bekannte Cipher-Klasse verwendet, um zu verschlüsseln bzw. zu entschlüsseln. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ... byte [ ] i n p u t = new byte [ ] { 0 xca , 0 x f e , 0xba , 0 xbe , . . . } ; Cipher c i p h e r = Cipher . g e t I n s t a n c e ( "RSA/None/ NoPadding " , "BC" ) ; KeyPairGenerator g e n e r a t o r = KeyPairGenerator . g e t I n s t a n c e ( "RSA" , "BC" ) ; g e n e r a t o r . i n i t i a l i z e ( 1 0 2 4 ) ; // We want 1024 b i t k e y s KeyPair p a i r = g e n e r a t o r . g e n e r a t e K e y P a i r ( ) ; Key pubKey = p a i r . g e t P u b l i c ( ) ; Key privKey = p a i r . g e t P r i v a t e ( ) ; // e n c r y p t c i p h e r . i n i t ( Cipher .ENCRYPT_MODE, pubKey ) ; // The p u b l i c key i s used f o r e n c r y p t i o n byte [ ] c i p h e r T e x t = c i p h e r . d o F i n a l ( i n p u t ) ; // d e c r y p t 12 17 18 19 c i p h e r . i n i t ( Cipher .DECRYPT_MODE, privKey ) ; // The p r i v a t e key i s used f o r decryption byte [ ] p l a i n T e x t = c i p h e r . d o F i n a l ( c i p h e r T e x t ) ; ... Listing 6: Verschlüsseln und Entschlüsseln mit RSA Testet man das Beispiel mit richtigen Daten durch, so sieht man, dass der cipherText um ein Vielfaches länger ist, als der ursprüngliche plainText. Dies und die rechenintensiven Operationen sind der Preis, den man sich durch dieses sichere Verfahren erkauft. 7 ASN.1, Zertikate und Keystores Im Umfeld der Kryptographie wird man häug auch mit dem Begri ASN.1 konfrontiert werden. Hierbei handelt es sich um eine Notation, in der kryptographische Protokolle dargestellt werden. Hierdurch lässt sich exakt festlegen, wie z.B. ein RSA Public Key serialisiert wird, bzw. aus welchen Komponenten er besteht. Zertikate werden ebenfalls in ASN.1 codiert und dann im DER (binär) oder PEM (Text) Format gespeichert. Die Struktur für einen RSA Public Key ist beispielsweise wie folgt deniert: RSAPublicKey ::= SEQUENCE { modulus INTEGER, publicExponent INTEGER } Eine detaillierte Vorstellung von ASN.1 würde hier zu weit führen. Was sind Zertikate? Ein Zertikat ist eine Urkunde, die einen bestimmten Umstand belegt, wie z.B. eine bestandene Prüfung. In der Private/PublicKeyKryptographie werden Zertikate verwendet, um PublicKeys einem bestimmten Individuum zuzuordnen (vergleichbar mit einem digitalen Personalausweis). Hierbei kann es sich um eine Person (z.B. Student → RBG-Zertikate für Grundstudiums-Tool) oder auch um Zertikate für Websites handeln (Onlinestore → Zertikat für https://www.onlineshop.de). Wann immer man eine Webseite über das httpsProtokoll ansurft, werden im Hintergrund Zertikate zwischen Webserver und Client ausgetauscht. Zertikate werden heute normalerweise nach dem X509Standard ausgegeben, und haben damit ein bestimmtes Set von Eigenschaften und Muss-Feldern. Hierzu zählen neben dem PublicKey, der in dem Zertikat hinterlegt ist, u.a. noch der Gültigkeitszeitraum und der Verwendungszweck (KeyUsages, z.B. nur für Signatur oder Verschlüsselung einzusetzen). Hierbei gibt es sehr viele feingranulare Abstufungen. Ein Zertikat kann seinen Zweck, zu belegen, dass ein bestimmter PublicKey einer gewissen Person zugeordnet ist, nur erfüllen, wenn dieAbbildung 5: Ein X509 Zertikat der RBG ser Fakt von jemandem attestiert wird, dem der Empfänger des Zertikates vertraut. Hierbei handelt es sich um den Issuer, also den Herausgeber des Zertikates. Im Falle der in.tum-Zertikate ist dies z.B. die RBG). Ein Herausgeber eines Zertikates wird häug auch CA genannt, Certicate Authority. Die Daten in einem Zertikat werden mit dem PrivateKey einer CA signiert und dem Zertikat beigefügt. Der Empfänger kann dann mittels des PublicKey des CA-Zertikates diese Signatur überprüfen. (Viele bekannte CA-Zertikate sind normalerweise im Zertikats-Store (s.u.) bereits durch den OS-Hersteller hinterlegt und können durch den Anwender auch erweitert werden.) CAs können auch Kaskaden bilden. So kann es z.B. eine sog. Root-CA für die TUM an sich geben, die dann wiederum Zertikate der einzelnen Fakultäten signiert (→ Intermediate bzw. Issuing-CAs), welche dann wiederum Enduser-Zertikate ausstellen. Bei der so entstehenden ZertikatsKette spricht man von einer Chain of trust . 13 CAs können Zertikate auch widerrufen. Diesen Vorgang nennt man Revozierung. Dies ist z.B. notwendig, wenn der PrivateKey kompromittiert wurde oder das Zertikat anderweitig nicht mehr genutzt werden soll. Die revozierten Zertikate werden in einer CRL, einer Certicate Revocation List, erfasst. Eine Client-Anwendung, die mit Zertikaten arbeitet, sollte diese CRL sowie die KeyUsages überprüfen, bevor es ein Zertikat als gültig akzeptiert. Zertikate werden in sogenannten Certicate Stores verwaltet. Von Java aus kann man mit Hilfe der entsprechenden Provider z.B. auf den Windows-eigenen Store zugreifen, auf einen Store in z.B. einer Smartcard oder den nativen JavaKeystore (JKS) verwenden. Das folgende ProAbbildung 6: Der Zertizierungsprozess gramm gibt alle Zertikate im Persönlichen Zertikatsstore unter Windows aus. Als Provider muss der SunMSCAPI-Provider gewählt werden, der die Schnittstelle zum MicrosoftStore bildet. Würde man hier den Sun-Keystore verwenden wollen, wird der Provider JKS verwendet. Den Keystore önet man mit dem Befehl KeyStore ks = KeyStore.getInstance("Windows-MY") und betrachten mittels eines Enumerators jeden Eintrag. Mit Hilfe von getCertificate() holt man sich die Referenz auf das Zertikat und geben uns von dem erhaltenen X509Certificate-Objekt einige Properties aus. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 import import import import import java . io . ∗ ; java . s e c u r i t y . ∗ ; java . s e c u r i t y . cert . X509Certificate ; j a v a . u t i l . Enumeration ; o r g . b o u n c y c a s t l e . o p e n s s l . PEMWriter ; p u b l i c c l a s s MSCryptAPIAccess { private s t a t i c Provider p = null ; p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) throws E x c e p t i o n { P r o v i d e r p = S e c u r i t y . g e t P r o v i d e r ( "SunMSCAPI" ) ; } KeyStore ks = KeyStore . g e t I n s t a n c e ( " Windows−MY" ) ; ks . l o a d ( n u l l , n u l l ) ; System . out . p r i n t l n ( " K e y s t o r e c o n t a i n s " + ks . s i z e ( ) + " e n t r i e s . " ) ; Enumeration<S t r i n g > enumerator = ks . a l i a s e s ( ) ; w h i l e ( enumerator . hasMoreElements ( ) ) { S t r i n g a l i a s = enumerator . nextElement ( ) ; System . out . p r i n t ( " Entry : \"" + a l i a s + " \ " " ) ; i f ( ks . i s C e r t i f i c a t e E n t r y ( a l i a s ) ) { System . out . p r i n t l n ( " i s a c e r t i f i c a t e ! " ) ; } i f ( ks . isKeyEntry ( a l i a s ) ) { System . out . p r i n t l n ( " i s a key e n t r y " ) ; } X 5 0 9 C e r t i f i c a t e c e r t = ( X 5 0 9 C e r t i f i c a t e ) ks . g e t C e r t i f i c a t e ( a l i a s ) ; printCertInfo ( cert ) ; } p u b l i c s t a t i c v o i d p r i n t C e r t I n f o ( X 5 0 9 C e r t i f i c a t e c e r t ) throws E x c e p t i o n { System . out . p r i n t l n ( " Some i n f o : " ) ; System . out . p r i n t l n ( " S u b j e c t : " + c e r t . getSubjectDN ( ) . getName ( ) ) ; System . out . p r i n t l n ( " I s s u e r : " + c e r t . g e t I s s u e r D N ( ) . getName ( ) ) ; 14 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 System . out . p r i n t l n ( " V a l i d from : " + c e r t . g e t N o t B e f o r e ( ) ) ; System . out . p r i n t l n ( " V a l i d u n t i l : " + c e r t . g e t N o t A f t e r ( ) ) ; b o o l e a n [ ] u s a g e s = c e r t . getKeyUsage ( ) ; i f ( u s a g e s != n u l l ) { System . out . p r i n t ( " KeyUsages : " ) ; i f ( u s a g e s [ 3 ] ) System . out . p r i n t ( " Data Encipherment , " ) ; i f ( u s a g e s [ 0 ] ) System . out . p r i n t ( " Data Encipherment , " ) ; System . out . p r i n t l n ( " " ) ; } System . out . p r i n t l n ( " P u b l i c key : " + c e r t . g e t P u b l i c K e y ( ) ) ; System . out . p r i n t l n ( " C e r t i f i c a t e dump : " ) ; } } ByteArrayOutputStream bOut = new ByteArrayOutputStream ( ) ; PEMWriter pemWriter = new PEMWriter ( new OutputStreamWriter ( bOut ) ) ; pemWriter . w r i t e O b j e c t ( c e r t ) ; pemWriter . c l o s e ( ) ; System . out . p r i n t l n ( bOut ) ; Listing 7: Ausgabe der Zertikate im Windows-Zertikatsstore Mit den Zeilen 49-53 wird das Zertikat in seiner base64-codierte ASN.1 Repräsentation ausgegeben. Speichert man den ausgegebenen Text, kann man auf diese Weise z.B. ein Zertikat exportieren (was auch mit Mitteln des Betriebssystems möglich ist). Ein Zertikat lässt sich auch selbst mit denierbaren Inhalten generieren. Hierfür bietet BC die Klasse X509V3CertificateGenerator an. Das folgende Listing zeigt exemplarisch deren Verwendung: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ... // C r e a t e a p r i v a t e / p u b l i c k e y p a i r KeyPairGenerator kpg = KeyPairGenerator . g e t I n s t a n c e ( "RSA" , "BC" ) ; kpg . i n i t i a l i z e ( 1 0 2 4 ) ; KeyPair kp = kpg . g e n e r a t e K e y P a i r ( ) ; X 5 0 9 V 3 C e r t i f i c a t e G e n e r a t o r certGen = new X 5 0 9 V 3 C e r t i f i c a t e G e n e r a t o r ( ) ; // S e t some p r o p e r t i e s certGen . s e t S e r i a l N u m b e r ( B i g I n t e g e r . v a l u e O f ( 1 ) ) ; certGen . s e t I s s u e r D N ( new X 5 0 0 P r i n c i p a l ( "CN=Test c e r t i f i c a t e " ) ) ; certGen . s e t N o t B e f o r e ( new Date ( ) ) ; // This c e r t w i l l be v a l i d f o r one day o n l y certGen . s e t N o t A f t e r ( new Date ( System . c u r r e n t T i m e M i l l i s ( ) + 8 6 4 0 0 ∗ 1 0 0 0 ) ) ; certGen . setSubjectDN ( new X 5 0 0 P r i n c i p a l ( "CN=Test C e r t i f i c a t e " ) ) ; certGen . s e t P u b l i c K e y ( kp . g e t P u b l i c ( ) ) ; certGen . s e t S i g n a t u r e A l g o r i t h m ( " SHA1WithRSAEncryption " ) ; // We want t o u s e t h i s c e r t f o r s i g n a t u r e s and key e n c i p h e r m e n t certGen . addExtension ( X509Extensions . KeyUsage , t r u e , new KeyUsage ( KeyUsage . d i g i t a l S i g n a t u r e | KeyUsage . keyEncipherment ) ) ; X 5 0 9 C e r t i f i c a t e c e r t = certGen . g e n e r a t e ( kp . g e t P r i v a t e ( ) , "BC" ) ; ... Listing 8: Erzeugen eines self-signed X509V3 Zertikats mit BC 8 Signierter Code Zertikate können auch verwendet werden, um JAR-Dateien zu signieren. Einzelne Klassen lassen sich leider nicht signieren. Dadurch können Empfänger der JARs verizieren, dass der Code während der Übertragung nicht verändert wurde, bzw. tatsächlich von dem jeweiligen Entwickler stammt. Sun liefert hierzu das Tool jarsigner mit, welches einfach zu benutzen ist: jarsigner -verbose -keystore TUM.ks TestJAR.jar markus 15 Enter Passphrase for keystore: updating: META-INF/MARKUS_D.SF updating: META-INF/MARKUS_D.RSA signing: chapter1/eTokenAccess.class signing: chapter1/MSCryptAPIAccess.class signing: chapter1/GenerateCertificate.class signing: .classpath signing: .project signing: keytool_list_etoken signing: resources/eToken.cfg Der Empfänger kann nun einfach die Integrität überprüfen, indem er einen Verify-Aufruf durchführt. Hierbei muss das Zertikat nicht zwangsläug im Keystore enthalten sein: jarsigner -verbose -keystore TUM.ks TestJAR.jar 1014 1181 5341 11040 3692 3991 645 391 153 115 smk smk smk smk smk smk smk s m k i = = = = Mon Mon Mon Sun Mon Mon Sun Tue Mon Sun Apr Apr Apr Apr Apr Apr Apr Feb Apr Apr 20 20 20 19 20 20 19 17 20 19 20:16:02 20:18:52 20:18:52 20:58:26 17:08:58 17:35:24 20:58:06 20:20:46 19:49:30 11:40:52 CEST 2009 META-INF/MANIFEST.MF CEST 2009 META-INF/MARKUS_D.SF CEST 2009 META-INF/MARKUS_D.RSA CEST 2009 chapter1/eTokenAccess.class CEST 2009 chapter1/MSCryptAPIAccess.class CEST 2009 chapter1/GenerateCertificate.class CEST 2009 .classpath CET 2009 .project CEST 2009 keytool_list_etoken CEST 2009 resources/eToken.cfg signature was verified entry is listed in manifest at least one certificate was found in keystore at least one certificate was found in identity scope jar verified. Anwendung ndet dieses Konzept in Zusammenhang mit dem SecurityManager bzw. dem ClassLoader, welcher abhängig von der Signatur den geladenen Klassen bestimmte Rechte einräumt oder verweigert. So lässt sich beispielsweise in einer Security-Policy festlegen, dass alle Klassen eines Applets, die von Markus signiert sind und von der URL in.tum.de heruntergeladen werden, Schreibrechte im lokalen Dateisystem erhalten, was ansonsten für ein Applet nicht möglich wäre. Die Überprüfungen, ob ein bestimmter API Aufruf dem Code erlaubt wird oder nicht, wird durch den SecurityManager geregelt. In sehr vielen JDK-Klassen (vor allem im Bereich I/O) sind Aufrufe des SecurityManagers eingewoben. Beispiel: Der Sourcecode der Methode canRead() in der Klasse File des JDK. 1 2 3 4 5 6 7 p u b l i c b o o l e a n canRead ( ) { S e c u r i t y M a n a g e r s e c u r i t y = System . g e t S e c u r i t y M a n a g e r ( ) ; i f ( s e c u r i t y != n u l l ) { s e c u r i t y . checkRead ( path ) ; } r e t u r n f s . c h e c k A c c e s s ( t h i s , F i l e S y s t e m .ACCESS_READ) ; } Ist ein SecurityManager für die Anwendung konguriert, so wird anhand der Policy geprüft, ob der Zugri erlaubt ist. Ist er nicht gestattet, wird eine SecurityException geworfen. Die Policy ist unter anderem im JRE-Homeverzeichnis in der Datei lib\security\java.policy deniert. In dieser Datei können sehr feingranulare Permissions auf einzelnen Klassen und Aktionen für verschiedene Besitzer bzw. Quellen gesetzt werden. Auch eigene Permissions können bei Bedarf deniert werden. Einige Beispiele: Erlaubt das Lesen unter /tmp und das Verbinden eines Netzsockets für Code, der von java.sun.com stammt und von Doe John signiert wurde: 16 grant codeBase "http://java.sun.com/*", signedBy "Doe John" { permission java.io.FilePermission "/tmp/*", "read"; permission java.io.SocketPermission "*", "connect"; }; Erteilt Lese- und Schreibrechte auf /home/alice für die Identität Alice, die über ein X509 Zertikat repräsentiert wird: grant principal javax.security.auth.x500.X500Principal "cn=Alice" { permission java.io.FilePermission "/home/alice", "read, write"; }; Wichtig zu erwähnen ist, dass in einer Java-Applikation normalerweise gar kein SecurityManager geladen ist, d.h. diese Überprüfungen nden bei interaktiv gestarteten Java-Applikationen normalerweise nicht statt! Anders sieht es bei Applets in einem Browser aus: Hier wird normalerweise automatisch ein SecurityManager geladen, der u.a. dafür sorgt, dass ein Applet nicht auf die lokale Platte zugreifen kann und verhindert, dass es sich ins Netz zu einer anderen Ressource verbinden kann, als zu der, von der es geladen wurde. Möchte man in einer interaktiv gestarteten Java-Applikation auch einen SecurityManager nutzen, so geschieht dies durch Angabe der Option -Djava.security.manager beim Aufruf. Ein Beispiel: java -Djava.security.manager TrojanHorse Neben dem Überprüfen von Security-Policies durch den SecurityManager sorgen auch noch der ClassLoader bzw. der ByteCode-Verier dafür, dass kein bösartiger ByteCode in der JVM ausgeführt wird. Abbildung 7: Schematische Darstellung der Überprüfungen beim Laden von Java-Code 9 Ausblick 9.1 Starke Kryptographie, Smartcards, Tokens, HSMs Alle in diesem Artikel vorgestellten Verfahren verwenden ein secret zur Verschlüsselung der Daten, sei es ein Passwort oder einen Private Key. Letztendlich hängt die Gesamtsicherheit der Verschlüsselung zu einem nicht unwesentlichen Teil von der Geheimhaltung eben jenes Schlüssels ab. Liegt die Schlüsseldatei lediglich auf der Festplatte des Anwenders, so kann diese durch Schadsoftware wie Trojaner oder Viren manipuliert werden oder sie wird einfach kopiert. Abhilfe schaen hier Smartcards oder Tokens, die beide eng verwandt sind: Während eine Smartcard in der Regel wie eine EC-Karte mit Geld-Chip aussieht und ein separates Lesegerät (den Smartcard Reader) benötigt, ist ein Token eine all in one Lösung, die Smartcard und Leser in einem Gerät kombiniert und wie ein USB-Memory Stick aussieht. Eines der am weitesten verbreiteten Token ist das Aladdin e-Token [eTo]. Ein Token bietet die Möglichkeit, Schlüssel zu erzeugen, die das Token aber nicht verlassen Abbildung 8: Aladdin eToken können. Alle kryptographischen Operationen mit diesem Schlüssel wer- Pro 64K den dann nur innerhalb des Tokens durchgeführt und sind dadurch vor der Einussnahme durch Schadcode geschützt. 17 Beiden Produkten ist gemein, dass sie eine sogenannte 2-Faktor-Authentizierung unterstützen, indem nun something you know (das Passwort) nicht mehr ausreicht, sondern nun eine zweite Komponente notwendig ist (der Besitz des Tokens/der Smartcard), um eine Operation durchzuführen. Eine nochmals erhöhte Sicherheit kann durch eine 3-Faktor-Authentizierung erreicht werden: Something you have, Something you know, Something you are. Something you are sind dann biometrische Merkmale wie ein Fingerabdruck, ein Retina-Scan oder ein digitaler Voiceprint. Für High-End-Security Anforderungen, besonders im Banken und CA Umfeld, kommen sogenannte HSMs, Hardware Security Modules, zum Einsatz. Hierbei handelt es sich um groÿe Smartcards in der Form von PCI Steckboards oder kompletten 19" Appliances, welche zusätzlich besonders gegen physische Angrie geschützt sind und diverse Zertizierungen besitzen (z.B. FIPS, CC): Im Falle eines Angris wird innerhalb von Millisekunden der Speicher mit dem Schlüsselmaterial gelöscht und ist dadurch für einen Angreifer wertlos. HSMs haben neben einem schnellen Krypto-Prozessor normalerweise auch einen echten Zufallszahlengenerator. Für ein Beispiel siehe [Uti]. 10 Beschreibung des Demo-Projekts Bezogen auf diesen Artikel wurde auch ein Demo-Projekt erstellt. Es handelt sich dabei um eine JavaApplikation, die in erster Linie die Funktionsweise verschiedener Kryptographie-Algorithmen demonstriert. Der Anwender kann zufällige oder vordenierte Schlüssel verwenden, um beliebige Texte zu verschlüsseln. Gegebenenfalls kann dabei zwischen verschiedenen Betriebsmodi gewählt werden. Zur Verschlüsselung wird die im Rahmen des Artikels vorgestellt API Bouncy Castle verwendet. Ein eigener Menüpunkt gibt die durch BC unterstützten Kryptographie-Capabilities aus. Die Anwendung ist in der Lage, installierte Zertikate auszulesen und anzuzeigen. Darüber hinaus wird die Authentizierung mittels eines Hardware-Tokens demonstriert. 11 Related Work In der Kürze dieses Artikels ist es nicht möglich, alle zugrunde liegenden Konzepte aus den betrachteten Themen detailliert vorzustellen. Unverzichtbare Grundkonzepte werden erläutert, für die wissenschaftlichen Hintergründe und Erläuterungen zu Algorithmen, Konzepten und Umsetzungen sei auf die einschlägige Literatur [Sch07], [Sch96], [Sch03], [And08] und [Sin01] verwiesen. Literatur [And08] Ross J. Anderson. Security Engineering. Wiley & Sons, 2008. [Dau09] Markus Dauberschmidt. Installing the http://home.in.tum.de/~daubersc/java/InstallGuide.pdf, 2009. Bouncy Castle API. [DH76] Whiteld Die and Martin E. Hellman. New directions in cryptography. IEEE Transactinos on Information Theory, 6/1976, 1976. [eTo] eToken PRO - Portable USB Token with advanced smart card ftp://ftp.aladdin.com/pub/marketing/eToken/Factsheets/FS_eToken_PRO.pdf. technology. [Lau09] Oliver Lau. Faites vos jeux! - Zufallszahlen erzeugen, erkennen und anwenden. c't Magazin für Computer Technik, 2/09, 2009. [rsa] RSA explained. http://sergematovic.tripod.com/rsa1.html. [RSA78] Ron Rivest, Adi Shamir, and Leonard Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, Feb 1978, 1978. [RSA99a] RSA Laboratories. PKCS 12 v1.0: Personal Information Exchange Syntax, 1999. [RSA99b] RSA Laboratories. PKCS 5 v2.0: Password-Based Cryptography Standard, 1999. [Sch96] Bruce Schneier. Angewandte Kryptographie. Addison-Wesley, fth edition, 1996. 18 [Sch03] Bruce Schneier. Practical Cryptography. Wiley & Sons, 2003. [Sch07] Klaus Schmeh. Kryptographie. dpunkt.verlag, third edition, 2007. [Sin01] Simon Singh. Geheime Botschaften. DTV, 2001. [Sun05] Sun Microsystems. Java Security Overview - Whitepaper, 2005. http://java.sun.com/developer/technicalArticles/Security/whitepaper/JS_White_Paper.pdf. [tru] True hardware random number generators. http://true-random.com/. [Ulf99] Udo Ulfkotte. Marktplatz der Diebe. Bertelsmann, 1999. R CryptoServer. http://www.utimaco.de/. [Uti] Utimaco SafeGuard° [Zab] Enrique Zabala. Rijndael cipher. http://www.formaestudio.com/rijndaelinspector/. 19