Seminararbeit. Securing wireless J2ME. Mühlebach Michael, Ia02

Transkript

1 Seminararbeit Securing wireless J2ME Mühlebach Michael, Ia02 Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuende Dozenten: Prof. Dr. Carlo Nicola Windisch, 29. März 2005

2 Inhaltsverzeichnis 1 Einführung 3 2 Eingesetzte Technologien XML-Signature kxml-parser The Bouncy Castle Crypto API Verwenden von Signierungen Schlüsselpaar generieren Digest Erstellen der Signatur XML-Signatur zusammenstellen Verifizieren von Signaturen Zerlegen der Signatur Berechnen des Digest Verifizierung der Signatur Fazit 9 2

3 1 Einführung Es gibt zwei wichtige Punkte die man mit Verschlüsselungsmechanismen lösen will. Einerseits ist dies die Geheimhaltung der Nachricht und zum anderen die Authentizität der Nachricht. Dieses Seminar deckt vorallem den zweiten Punkt mit XML-Signaturen ab, sowie dem kxml-parser, die vorallem zur Authentifizierung von Nachrichten geschaffen wurden. Das die Authentizität von Nachrichten ein sehr wichtiges Thema ist, lässt sich an einem kleinen Beispiel gut demonstrieren: Es wird ein Service für Aktienhändler angeboten, welcher per Handy über das Web funktioniert. Dieser gibt den Händler schnell Informationen über Kursveränderungen ihrer Aktien an. Es muss nun sichergestellt werden, dass die Informationen wirklich vom Serviceanbieter kommen. Ein Konkurrent könnte sonst Falschinformationen, unter dem Namen des Anbieters, herausgeben, was zu katastrophalen ver- und ankäufen von Aktien führen könnte. Da Wireless-Geräte per Definition auf ein unsicheres Netzwerk zugreifen, muss die Sicherheit über Verschlüsselungmechanismen laufen. Diese Systeme sind in sogenannte Public Key Infrastructure (PKI) verpackt, welche die Probleme der Authentizität lösen kann. Da diese Systeme sehr Rechenintensiv sind, was vorallem bei Handys zu grossen Problemen führt, muss man mit einigen Abstrichen auskommen. 2 Eingesetzte Technologien In diesem Teil wird ein Überblick über die notwendigen Technologien verschaft. Das Ziel ist, grundlegende Themen zu erklären die für sichere Wireless-Verbidungen benötigt werden. 2.1 XML-Signature Das Ziel einer Signatur ist die Authentizität und Integrität einer Nachricht sicherzustellen. Um dies zu realisieren verwendet man bei der XML Signatur den public key des Senders. Beim signieren einer Nachricht verwendet der Sender seinen private key und fügt die Signatur der Nachricht an. Dabei ist zu merken, dass die Nachricht nicht verschlüsselt oder sonst auf einem weg geschützt wird. Um dies zu erreichen müsste man den W3C Standard für XML Encryption verwenden, welcher jedoch nicht Inhalt dieses Berichtes ist. Da die public key Algorithmen, vorallem sichere, sehr Rechenintensiv sind verwendet man nur einen Teil der Nachricht bzw verwendet einen Hashwert. Für die Validierung der Nachricht ist einerseits die Nachricht selbst, die Signatur und auch der public key des Senders von nöten. Der public key wird meistens schon vorgängig ausgetauscht oder wird der Signatur angehängt. Die Signatur jedoch kann entweder komplett von der Nachricht getrennt sein, innerhalb der Nachricht enthalten sein oder die Nachricht umschliessen. Bei einer vollständigen Implementation müssen alle Möglichkeiten berücksichtig werden, jedoch kann man sich hier nach dem Server 3

4 bzw Sender der Nachricht richten, da dieser im Normalfall immer dieselbe Methode verwendet. 2.2 kxml-parser Der kxml ist ein sogenannter Pull Parser, was bedeutet, dass die Applikation, welche den kxml-parser verwendet, die vollständige Kontrolle über den Parser behält. Sie gibt an, wann weitere Daten zu parsen sind. Dies bewirkt, dass die Applikation viel näher an die Struktur des XML Dokumentes rückt, was in unserem Fall sogar enorme Vorteile bringt, da viel effizienter programmiert werden kann. Da der kxml-parser jedoch kaum oder gar keine Validierung des XML Dokumentes vornimmt, liegt es vorallem am Sender und Empfänger der Dokumente sich korrekt zu verständigen. 2.3 The Bouncy Castle Crypto API Da die Signierung von Nachrichten und die Verifizierung von Signaturen nicht Teil von MIDP 1.0 ist und diese Funktionalität von Java nur in der Standard Edition (J2SE) vorhanden ist, muss auf ein anderes Package zurück gegriffen werden. Bouncy Castle ist ein Open Source Kryptographie Packet für Java Plattformen. Es ist eines der wenigen kompletten Packete welche mit MIDP laufen. So mächtig und gut Bouncy Castle auch sein mag, es gibt ein sehr grosses Problem damit: Eine Dokumentation ist so gut wie nicht existent und es ist für Anfänger sehr schwierig zu erfahren, wie man die Klassen verwenden soll. Allerdings gibt es ein paar brauchbare Beispiele, welche nützliche Hinweise liefern können. Installation Um BouncyCastle der Runtimeumgebung zur Verfügung zu stellen kopiert man als erstes die JAR Datei von BouncyCastle, welche den JCE Provider enthält, in das Java Verzeichnis $JAVA HOME/jre/lib/ext. Für den Compiler fügt man sie einfach dem CLASSPATH hinzu. Der normale Weg um den JCE Provider von BouncyCastle zu installieren, wäre über das Hinzufügen des Providers in der Java Datei $JAVA HOME/jre/lib/security/- java.security mit der Zeile security.provider.1=org.bouncycastle.jce.provider.bouncycastleprovider. Dies scheint jedoch sehr häufig ein Problem darzustellen, da der ClassLoader von Java anscheinend nicht fähig ist, die Signierte JAR Datei von BouncyCastle zu verifizieren. Allerdings ist es auch möglich den Provider selbst anzugeben mit folgender JavaCode Zeile: Security.addProvider(new BouncyCastleProvider()). Ein weiteres Problem von BouncyCastle ist BigInteger. Diese Klasse ist im java.math Package von Java enthalten und wird, wie das ganze Packet, in der Micro Edition nicht mitgeliefert. BouncyCastle liefert eine eigene Implementation dieser Klasse mit, welche genau in diesem Packet liegt. Jedoch ist es Applikationen nicht erlaubt, das java oder javax Packet zu erweitern. Die einzige Lösung die es zu geben scheint, ist mit einem Obfuscator die eigene Applikation zu bearbeiten. Ein Obfuscator ändert alle Packet-, Klassen- und Methodennamen ab und minimiert diese. Somit wird eine Minimierung der Applikationsgrösse erreicht, was der ursprüngliche Zweck eines Obfucators ist, und 4

5 löst somit auch das Packet Problem, da nun die Klasse BigInteger nicht mehr ins Packet java.math versucht wird zu stellen. 3 Verwenden von Signierungen Abbildung 1: Schematische Darstellung einer Signierung Eine Nachrichtenübermittlung läuft immer nach dem selben Schema ab (siehe Abbildung 1): 1. Generierung des Schlüsselpaares: Bei produktiven Anwendungen findet dieser Schritt nur einmal statt und beinhaltet auch die Zertifizierung der Schlüssel bei Veriy- SignˆTM oder einem anderen Zertifizierungs Anbieter. 2. Den Digest der Nachricht auf dem Server berechen. 3. Erstellen der Signatur des Digest der Nachricht mit dem geheimen Schlüssel durch den Signierer. 4. XML-Signatur mit der Nachricht, dem Digest, der Signatur und dem öffentlichen Schlüssel erstellen und an den Client senden. 3.1 Schlüsselpaar generieren Mit der Klasse DSAKeyPairGenerator bzw RSAKeyPairGenerator von BouncyCastle kann ein Schlüsselpaar erzeugt werden, jedoch kann auch ein beliebiger Generator für DSA bzw. RSA Schlüssel verwendet werden. Zuerst muss ein Zufallszahlen Generator erzeugt und die Parameter für den Schlüsselgenerator initialisiert werden: 5

6 SecureRandom sr = new SecureRandom(); DSAParametersGenerator dsaparagen = new DSAParametersGenerator(); dsaparagen.init(1024, 80, sr); dsapara = dsaparagen.generateparameters(); DSAKeyGenerationParameters dsakeygenpara = new DSAKeyGenerationParameters(sr, dsapara); Dabei sind die wichtigen zwei Einstellungen: Die Grösse der Schlüssel, hier 1024-Bits, und die Robustheit der Primzahl, hier 80, welches zugleich das Minimum ist. Diese ist für die Übereinstimmtung mit FIPS Als nächstes müssen die beiden Schlüssel erzeugt werden: DSAKeyPairGenerator dsakeypairgen = new DSAKeyPairGenerator(); DSAKeyPairGen.init(dsaKeyGenPara); AsymmetricCipherKeyPair keypair = dsakeypairgen.generatekeypair(); privkey = (DSAPrivateKeyParameters) keypair.getprivate(); pubkey = (DSAPublicKeyParameters) keypair.getpublic(); 3.2 Digest Der Digest ist ein Wert, der aus der Nachricht generiert wird und, unabhängig von der Grösse der Nachricht, immer dieselbe Länge hat. Dabei ist es wichtig das jede Änderung an der Nachricht eine Signifikante Änderung des Digest hervorruft. Häufige Algorithmen zur Berechnung des Digest sind zum Beispiel SHA1 oder MD5. Ein SHA1 Digest einer Nachricht kann wie folgt berechnet werden: static public String getdigest( String mesg ) { SHA1Digest digeng = new SHA1Digest(); byte [] mesgbytes = mesg.getbytes(); digeng.update( mesgbytes, 0, mesgbytes.length ); byte [] digest = new byte[digeng.getdigestsize()]; digeng.dofinal(digest, 0); } return (new String(Base64.encode(digest))); 3.3 Erstellen der Signatur Die Signatur ist das Kernstück der Arbeit und dient zur eindeutigen Verifizierung der Herkunft der Nachricht. Aus Performance gründen kann die Signatur nicht von der Nachricht, sondern nur vom Digest berechnet werden. static public String [] getsignature (String digest) throws Exception { // Sign DSASigner signer = new DSASigner(); signer.init( true, privkey ); BigInteger [] sigarray = signer.generatesignature( digest.getbytes() ); 6

7 String [] result = new String [2]; // Signature R result[0] = new String(Base64.encode(sigArray[0].toByteArray())); // Signature S result[1] = new String(Base64.encode(sigArray[1].toByteArray())); } return result; 3.4 XML-Signatur zusammenstellen Der Server erstellt aus den verschiedenen, zuvor berechneten, Werten, die digitale XML- Signatur, welche er danach an den Client verschickt. 4 Verifizieren von Signaturen Abbildung 2: Schematische Darstellung einer Verifizierung Nach dem empfangen der Nachricht wird die Signierung nach folgendem Schema verifiziert (siehe Abbildung 1): 1. Der Client zerlegt mit Hilfe eines Parser die XML-Signatur in ihre Stücke 2. Zuerst berechnet der Client den Digest der Nachricht und vergleicht diesen mit dem erhaltenen. Falls diese nicht zusammenpassen - Fehler. 3. Zuletzt verifiziert der Signierer mit Hilfe des öffentlichen Schlüssels, der Signatur und des Digest die Signatur. 7

8 4.1 Zerlegen der Signatur Mit Hilfe des kxml-parsers kann die Signatur in die wichtigen Stücke zerlegt werden. String url = " HttpConnection conn = (HttpConnection) Connector.open(url); conn.setrequestmethod(httpconnection.get); is = conn.opendatainputstream(); InputStreamReader reader = new InputStreamReader(is); XmlParser parser = new XmlParser(reader); Document doc = new Document(); doc.parse(parser); Element signedmesg = doc.getrootelement(); String mesg = signedmesg.getelement("mesg").gettext(); String digest = signedmesg.getelement("signature").getelement("signedinfo").getelement("digestvalue").gettext(); String key_g = signedmesg.getelement("signature").getelement("keyinfo").getelement("keyvalue").getelement("dsakeyvalue").getelement("g").gettext(); String key_p = signedmesg.getelement("signature").getelement("keyinfo").getelement("keyvalue").getelement("dsakeyvalue").getelement("p").gettext(); String key_q = signedmesg.getelement("signature").getelement("keyinfo").getelement("keyvalue").getelement("dsakeyvalue").getelement("q").gettext(); String key_y = signedmesg.getelement("signature").getelement("keyinfo").getelement("keyvalue").getelement("dsakeyvalue").getelement("y").gettext(); String sig_r = signedmesg.getelement("signature").getelement("signaturevalue").getelement("r").gettext(); String sig_s = signedmesg.getelement("signature").getelement("signaturevalue").getelement("s").gettext(); 4.2 Berechnen des Digest Als nächster Schritt wird der Digest berechnet. Das Vorgehen, ist das selbe, wie beim erstellen des ursprünglichen Digest. Dieser Schritt ist, wie oben bereits erwähnt, zum schnellen Abbruch einer Verifizierung gedacht und kann nicht zur definitiven Verifizierung der Signatur verwendet werden: if (digest.equals(getdigest(mesg)) { System.out.println("Digests are equal"); } else { 8

9 } System.out.println("Digests are diffrent"); 4.3 Verifizierung der Signatur Als letzter Schritt muss nun die digitale Signatur verifiziert werden. Dafür verwendet man die Verifizierungs-Funktion des DSA Algorithmus. BigInteger g = new BigInteger( Base64.decode(key_g) ); BigInteger p = new BigInteger( Base64.decode(key_p) ); BigInteger q = new BigInteger( Base64.decode(key_q) ); BigInteger y = new BigInteger( Base64.decode(key_y) ); BigInteger r = new BigInteger( Base64.decode(sig_r) ); BigInteger s = new BigInteger( Base64.decode(sig_s) ); DSAParameters dsapara = new DSAParameters(p, q, g); DSAPublicKeyParameters DSAPubKeyPara = new DSAPublicKeyParameters(y, dsapara); // Verify DSASigner signer = new DSASigner(); signer.init(false, DSAPubKeyPara); if (signer.verifysignature(digest.getbytes(), r, s)) { System.out.println("Verification successful"); } else { System.out.println("Verification faild"); } 5 Fazit Die Anwendung von Signierungsverfahren, sieht im ersten Ansatz sehr komfortable aus, jedoch stösst man auf sehr viele Detailprobleme, wie zum Beispiel das Problem mit dem BigInteger. Zudem sind viele mobile Geräte nicht mit den nötigen Rechenresourcen ausgerüstet um in vernünftiger Zeit eine Signatur zu validieren. Jedoch gibt es dort viele Ansätze, wie der JavaButton etc welche eine Lösung versprechen. Literatur [1] Securing wireless J2ME, IBM developer Works, developerworks/wireless/library/wi-secj2me.html [18. Januar 2005] [2] Securing your J2ME/MIDP apps, IBM developerworks, com/developerworks/library/j-midpds.html [18. Januar 2005] [3] The Legion of Bouncy Castle, [16. Januar 2005] [4] Severin Kaufmann, Seminarvortrag: XML Signature, 2005 FH-Aargau. [5] Christoph Meier, Seminarvortrag: kxml: A parser for J2ME, 2005 FH-Aargau. 9