PDF 941kB - Hochschule Ulm

Aufbau eines sicheren Kanals über NFC
6.2 Sicherheitsanforderungen an das Smartphone Betriebssystem
Sensible Daten von Apps müssen sicher gespeichert werden können. Wie in Kapitel 4.1
erläutert wurde, ist es nicht möglich, dass z.B. eine App A auf die Daten von einer
App B zugreifen kann. Dennoch unterliegen Smartphone Betriebssysteme verschiedenen
Angriffsvektoren. Ein typisches Ziel eines Angreifers ist es eine Privilege Escalation
durch fehlerhafte Softwareimplementierung zu erreichen. Dadurch, dass die Rechte vom
Angreifer erhöht werden, kann dieser je nach Berechtigungsstufe und der konsequenten
Umsetzung der Defense-in-Depth-Schutzmaßnahmen vom Betriebssystem unterschiedlich
großen Schaden anrichten. Ein erster Schritt z.B. wäre der Zugriff auf die Sandbox
einer anderen App. Sollte dieser Zugriff gelingen, ist ein Angreifer möglicherweise
in der Lage vertrauenswürdige Daten von der App zu kopieren oder zu manipulieren.
Daher empfiehlt es sich, sensible Informationen, wie z.B. einen Private Key, nicht auf
dem Dateisystem zu speichern [Cer13]. Sollte keine andere Möglichkeit bestehen, scheint
zunächst Verschlüsselung als möglicher Lösungsansatz. Wenn ein Angreifer aber Zugriff
auf die Sandbox hat und die Daten verschlüsselt sind, kann der Angreifer immer noch
in die ausführbaren Dateien der App einsehen. Darin wird sich auch üblicherweise der
geheime Schlüssel befinden, um die Dateien in der Sandbox zu entschlüsseln. Apps in
Windows Phone 8 und Android 4.3 werden typischerweise in Managed Code umgesetzt,
wie z.B. .NET bzw. Java. Da Managed Code zur Laufzeit übersetzt wird, befinden sich
die ausführbaren Dateien in einem plattformunabhängigen Format, auch als Common
Intermediate Language (CIL) bei .NET und Bytecode bei Java bezeichnet. Aus diesem
plattformunabhängigen Format lässt sich mit diversen Programmen der originale Quellcode
wiederherstellen. Daher ist es ratsam, keine Geheimnisse im Quellcode hardzucoden.
Es gibt zwar Verschleierungsprogramme, die Klassen und Objekte in nicht-triviale
Namen umbenennen, um das Reverse Engineering eines Angreifers zu erschweren. Dennoch
ist das zwangsweise kein Schutz, da z.B. ein String, der im Code eine längere
Zeichenfolge zugewiesen bekommt, für den Angreifer ein Indiz dafür sein kann, dass dies
möglicherweise ein Private Key zum Entschlüsseln sein könnte. In Windows Phone 8
wird der CIL im Windows Phone Store in ein sogenanntes Machine Dependent Intermediate
Language (MDIL) Format kompiliert [Ram12]. Zum Installationszeitpunkt wird
nativer Code aus den MDIL-Binärdateien erzeugt. Aber auch nativer Code bietet an
dieser Stelle keinen garantierten Schutz, da auch dieser mit Analyseprogrammen nach
auffälligen Codeabschnitten durchsucht werden kann.
Absolute Sicherheit kann nicht erreicht werden, da es letztendlich nur um Schadensbegrenzung
geht. Es muss davon ausgegangen werden, dass Smartphone Betriebssysteme
kompromittierbar sind und das Dateisystem, welches einer App zur Verfügung steht kein
vertrauenswürdiger Ort, für sensible Daten ist. In Kapitel 7 wird ein Ansatz für Windows
Phone 8 gezeigt, wie ein Schlüsselpaar aus Private Key und Public Key erzeugt
werden kann und sicher persistiert werden kann.
40