Seite 3: Beispiel & Fazit

Inhaltsverzeichnis

Beispiel: AESDroid

Die Beispiel-App AESDroid ist einfach aufgebaut und liegt im Eclipse-Projekt aesdroid bereit. Die App offeriert ein Eingabefeld, in dem sowohl der zu verschlüsselnde als auch der verschlüsselte Text Aufnahme finden. Neben Schaltflächen für "Über AESDroid", Verschlüsseln und Entschlüsseln bietet "Erzeuge Schlüssel" die Möglichkeit, einen AES-Schlüssel zu erzeugen. Die Schaltfläche erzeugt über einen einzugebenden String einen SHA-256-Hash. Der 256-Bit-Wert dient anschließend als AES-Schlüssel. Sobald ein Schlüssel erzeugt ist, sind die Schaltflächen zur Ver- und Entschlüsselung aktiv.

Zum Hin- und Herschalten zwischen den Implementierungen in AesEncryption und AesEncryptionReference dient die Checkbox "Verwende Referenzimplementierung". Das Programm nutzt das Interface AesInterface, das beide AES-Klassen erfüllen, um beide Implementierungen identisch ansprechen zu können.

Eine Besonderheit gilt noch für die Verschlüsselung: Sie erzeugt keinen direkten String im Eingabefeld. Vielmehr konvertiert die App das Kryptogramm in eine hexadezimale Zeichenkette und legt diese in das Eingabefeld (siehe Abb. 2). Entsprechend erwartet die Entschlüsselung einen hexadezimalen String im Eingabefeld.

Um die Implementierung zu verifizieren, liefert das Eclipse-Projekt aesdroid-test Android-JUnit-Tests. Neben einigen Tests der Einzelmethoden der AES-Implementierung führt es für beide Klassen AesEncryption und AesEncrpytionReference die bekannten AES Known Answer Tests (KAT) aus. Die Implementierung der Tests beschränkt sich rein auf den Electronic Code Book Mode (ECB), da er als Einziger in AESDroid genutzt wird.

Auch bei den KATs wartet Java mit einer kleinen Hürde auf. Wie anhand der Quelltexte der JUnit-Tests AesAtomicMethodTest und AesReferenceAtomicMethodTest zu sehen ist, implementieren diese die einzelnen KATs in separaten Methoden. Die Implementierung in C++ ließ an der Stelle noch ein großes Array als Steuertabelle für die KATs zu, was einen wesentlich einfacheren Ablauf innerhalb der CppUnit-Tests gestattete. Java wartet an der Stelle jedoch mit einer Besonderheit auf. Sowohl Methoden als auch Objekt- und Klassenattribute dürfen 64 KByte nicht überschreiten. Daher ist es in Java notwendig, die Tests in separate Methoden zu legen. Die KATs überschreiten sonst die magische 64-K-Grenze.

Problem Key-Management

Moderne Smartphones sind extrem leistungsfähig. Es sind vollwertige Computer, die auch Telefonieren können. Die meisten Vertreter dieser Kleincomputer – darunter auch die Android-Systeme – haben einen Nachteil. Sie sind nicht für höchste Sicherheit ausgelegt. Das Rooten bei Android oder der Jailbreak bei Apples iOS bedrohen sicher abgelegte Daten. Zudem vertraut Android bei der Installation neuer Apps zu sehr auf das Sicherheitsbewusstsein des Benutzers.

Das sichere Verwalten von Schlüsseln – das Key-Management – stellt daher auf mobilen Endgeräten eine große Herausforderung dar. Ein sicheres Speichermedium existiert hier zumeist nicht. Die Bestrebungen, im aktuellen Android einen sicheren Speicher für Schlüssel und Zertifikate zu schaffen, ist daher zu begrüßen. Doch auch dessen Sicherheitsbarrieren lassen sich mit genügend krimineller Energie überwinden.

Die Beispiel-App AESDroid mogelt sich am Thema vorbei. Sie erwartet ein Passwort und bildet einen kryptographischen Hash darüber. Doch auch das Ausspähen der Eingabe von Daten lässt sich auf kompromittierten Geräten nicht ausschließen. Eine tiefergehende Behandlung des so wichtigen Themas würde jedoch den Rahmen der Artikelreihe sprengen.

Fazit

Auch wenn die mathematische Theorie eines kryptographischen Verfahrens sich dem Cryptography Engineer gut erschließt, wartet noch ein gutes Stück Arbeit auf sie oder ihn, bis ein (effizient) lauffähiges Programm implementiert ist. Gerade die Herausforderung mit Java auf Android zeigt, welche Entscheidungen noch getroffen und welche Hürden genommen sein wollen, bis der aus vier Teilen zuvor so vertraute AES auch auf dieser Plattform implementiert ist.

Es gilt vieles zu beachten und abzuwägen – beispielsweise die Prozessor- und Systemarchitektur, Speichergrößen und CPU-Takt sowie die Möglichkeiten der Programmiersprache und die Optimierung von Algorithmen für mathematische Körper. Der Weg von der mathematischen Theorie zum lauffähigen Programm ist ein herausforderndes Arbeitsgebiet. Das hat diese Artikelreihe gezeigt, und sie regt hoffentlich ein wenig zum eigenen Experimentieren an.

Oliver Müller
ist freiberuflicher IT-Berater und -Trainer mit den Schwerpunkten Software Engineering, Kryptographie, Java EE, Linux, Unix, z/OS und OpenVMS. Derzeit forscht er zudem auf dem Gebiet des Key-Managements auf mobilen Endgeräten. (ane)