Die versteckten autonomen Systeme in Smartphones

UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/2015 1 Die versteckten autonomen Systeme in Smartphones Erwin Quiring Seminar Hot Topics in Communication Systems and Internet of Things Communciation and Networked Systems (ComSys) Institute of Computer Science Zusammenfassung Bei der Betrachtung der Sicherheit von Smartphones liegt der Fokus häufig auf den mobilen Betriebssystemen Android und ios. Allerdings sind in einem Smartphone weitere autonome Systeme vorhanden wie die Baseband- Komponente und die SIM-Karte. Beide arbeiten mit einem eigenen Prozessor und Betriebssystem. Die sichere Verwendung von Smartphones lässt sich nur dann gewährleisten, wenn alle Bestandteile und deren Beziehungen zueinander berücksichtigt werden. Diese Arbeit gibt daher einen strukturierten Überblick über die verborgenen Systeme eines Smartphones, fasst bekannte Angriffe auf die Baseband-Komponente und die SIM-Karte zusammen und beleuchtet die daraus resultierende Gefährdung für das gesamte Smartphone. I. EINFÜHRUNG UND MOTIVATION Smartphones sind ein elementarer Bestandteil unseres alltäglichen Lebens und bieten bei weitem nicht nur die Möglichkeit zu telefonieren. So ermöglichen sie einen mobilen Internetzugang, besitzen eine integrierte Kamera und lassen sich als Security- Token in Multi-Faktor-Authentifizierungen einsetzen [1], [2]. Der Funktionsumfang nimmt stets zu und laut Schätzungen der GSMA Intelligence sollen 2020 zwei Drittel der mobilen Kommunikation von Smartphones ausgehen [3]. Daher gelten für Smartphones ebenso hohe Sicherheitsanforderungen wie für klassische Computersysteme. Mobile Betriebssysteme wie Android oder ios implementieren deswegen verschiedene Sicherheitsfunktionen wie beispielsweise Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP) und Code Signierungen. Während also Android und ios immer schwerer anzugreifen sind, wird vergessen, dass in einem Smartphone weitere autonome Systeme arbeiten [4]. So läuft Android oder ios auf einem Applikationsprozessor, der mit einem Baseband-Prozessor verbunden ist [4]. Dieser ist für die Kommunikation zum Mobilfunknetz mit 2G-, 3G- oder 4G-Technologien zuständig und arbeitet mit einem eigenen Betriebssystem [5]. Der Baseband-Prozessor ist wiederum mit einem Subscriber Identity Module (SIM) verbunden, das als Smartcard ein geschützter Rechner mit eigenem Prozessor, Speicher und Betriebssystem ist [6, S. 8ff.]. Da der Angreifer den Angriffspunkt wählt, kann zum Beispiel eine Schwachstelle bei nur einer Komponente die Sicherheit des gesamten Smartphones gefährden. Beispielsweise zeigt Weinmann die Möglichkeit auf, durch einen Pufferüberlauf auf der Baseband-Komponente beliebigen Code aus der Ferne ausführen zu lassen [4]. Wenn die Baseband- Komponente Zugriff auf das Mikrophon oder die Kamera besitzt [5], lässt sich damit ein Nutzer überwachen, ohne dass Android oder ios dies überhaupt feststellen können [4]. Da die Sicherheit eines Systems also nur so stark ist wie die des schwächsten Glieds (the weakest link), muss also die gesamte Smartphone-Architektur betrachtet werden. Diese Arbeit setzt sich daher zum Ziel, einen ersten strukturierten Überblick über die verborgenen Smartphone-Systeme und deren Beziehungen zueinander zu geben. Mögliche Angriffe auf die Baseband-Komponente und die SIM-Karte stehen hierbei im Fokus. Auch wird die daraus folgende Gefährdung für die anderen Komponenten betrachtet. Ein solch umfassender Überblick ist dem Autor bis jetzt nicht bekannt. Welte [5] beschreibt zwar die Anatomie eines Smartphones, geht jedoch auf die technische Realisierung ein und nicht auf bekannte Angriffe. Die Arbeit von Becher et al. [7] behandelt auch die Angriffsmöglichkeiten auf Smartphones, basiert allerdings nicht wie diese Arbeit auf einer Unterteilung in die einzelnen Bauteile bzw. Systeme. Smartphones stehen im Zentrum dieser Arbeit. Davon abzugrenzen sind die günstigeren Mobiltelefone, auch Feature- Phones genannt. Bei diesen fällt der Baseband- und Applikationsprozessor zusammen [5]. Schwachstellen bei der Baseband- Komponente oder der SIM-Karte betreffen Feature-Phones aber ebenso. Auch Notebooks, Tablets oder Geräte im Internet der Dinge wie TV-Geräte oder Kühlschränke sind gefährdet, wenn diese durch eine zusätzliche Baseband-Komponente eine Internetverbindung aufbauen [8]. Außerdem liegt bei der Betrachtung der Baseband-Komponente der Fokus auf GSM (Teil von 2G), welches aufgrund der Abwärtskompatibilität weiterhin in Geräten zu finden ist. Die Arbeit ist wie folgt aufgebaut: Das folgende Kapitel II liefert einen Überblick über die Smartphone-Architektur. Auf dieser Grundlage beschreibt Kapitel III mögliche Angriffe auf die Baseband-Komponente und Kapitel IV Angriffe auf die SIM-Karte. Die Arbeit schließt mit einer Diskussion der gewonnenen Erkenntnisse und gibt einen Ausblick auf den weiteren Forschungsbedarf. II. ARCHITEKTUR EINES SMARTPHONES Ein Smartphone besteht grob aus drei autonomen Systemen: Der Applikationsprozessor, die Baseband-Komponente und die SIM-Karte. Abbildung 1 veranschaulicht den Hardwareaufbau sowie die Kommunikation zwischen den Komponenten. Zum Applikationsprozessor werden mehrere Komponenten gezählt [9]: So ist der eigentliche (Multi-Core) Prozessor enthalten, auf dem ein mobiles Betriebssystem wie zum Beispiel Android oder ios läuft. Als Speicher stehen Flash- Speicher und RAM zur Verfügung. Des Weiteren besitzt der

UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/2015 2 Applikationsprozessor Baseband-Komponente Basisstation SIM-Karte Tastatur Wifi Flash CPU ROM RAM AT Befehle Signalaustausch CPU SAT APDU RAM EEP- ROM CPU ROM Display Bluetooth GPS GPS Mikrophon Kamera Abbildung 1. Hardwareaufbau eines Smartphones sowie die Kommunikation zwischen den Komponenten Prozessor Zugriff auf Peripheriegeräte wie die Tastatur, das Display, Wifi, Bluetooth und GPS [9]. Die Baseband-Komponente realisiert die Kommunikation zum Mobilfunknetz. Dafür enthält es neben den Bauteilen für den physischen Signalaustausch einen eigenen Prozessor zur Verarbeitung dieser Signale [5]. Zudem ist ein Zugriff auf das Mikrophon und die Kamera sowie manchmal auf GPS möglich [4]. Auf dem Prozessor arbeitet oft ein Realtime Operating System (RTOS) wie beispielsweise VxWorks oder AMSS [5] [10]. Auf dem RTOS laufen Prozesse, die u. a. für das Hardware-Management (z. B. die SIM-Karte) und für das Netzwerk-Management (z. B. GSM, UMTS) zuständig sind [10]. Letzteres beinhaltet bei GSM die Implementierung des Um-Interfaces, welches das Kommunikationsprotokoll zwischen Baseband-Komponente und Basisstation (BTS) darstellt [11]. Die Implementierung ist in drei Schichten aufgeteilt, die unter dem Begriff GSM Software Stack zusammengefasst sind [5]. Die untersten beiden Schichten stellen die physikalische Schicht und die Sicherungsschicht dar und ähneln denen im OSI-7-Schichtenmodell [12]. Die dritte Schicht umfasst u. a. das Mobilitätsmanagement (z. B. Standort-Updates) und Verbindungsmanagement (z. B. SMS, Anrufe) [4]. Die SIM-Karte verknüpft das Smartphone mit der Identität des Nutzers. Des Weiteren speichert und berechnet die Karte kryptographische Schlüssel für die Authentifizierung und Verschlüsselung im Mobilfunknetz [6, S. 89f.]. Die Karte ist eine Smartcard und stellt somit einen speziellen, manipulationssicheren Computer dar [6]. So ist ein Prozessor mit ROM (>200kb), EEPROM (>64kb, spezieller Speicher) und RAM (>8kb) vorhanden. Die Karte wird extern über die goldenen Kontakte mit Strom versorgt. Die Berechnungen sind nach außen durch eine physische Barriere geschützt und ein Aufbruch macht die Karte unbrauchbar. Auf der Karte läuft ein RTOS [13]. Eine Zugriffskontrolle schützt die hierarchisch organisierten Daten [14, S. 28f.]. So ist zum Beispiel der Zugriff auf die SMS-Nachrichten erst nach Eingabe einer PIN möglich. Zusätzlich läuft auf dem Betriebssystem eine Java Virtual Machine, die die Implementierung von Java Applets erlaubt [13]. Die dafür verwendete Java Card Sprache ist eine Teilmenge der normalen Java Programmiersprache [15]. Zum Beispiel lässt sich damit die SIM-Funktionalität durch ein Banking-Applet erweitern [13]. Anzumerken ist, dass vor der Einführung von 3G der Begriff SIM sowohl die Karte, als auch die Software darauf bezeichnete [6, S.86]. Da heutzutage mehrere Mobilfunkstandards die Karte verwenden, folgte eine genauere Unterscheidung [6]: die Karte als Basis heißt Universal Integrated Circuit Card (UICC). Die GSM-Anwendung heißt SIM und die 3G-Anwendung Universal Subscriber Identity Module (USIM). Da der Fokus dieser Arbeit bei GSM liegt, wird weiterhin der Begriff SIM für die Karte und die Anwendungen darauf verwendet. Die Datenübertragung zwischen Applikations- und Basebandprozessor erfolgt über ein Serial Peripheral Interface (SPI), einen Universal Asynchronous Receiver/Transmitter (UART) oder über Shared Memory [9]. Bei letzterem besitzt je nach Design der Basebandprozessor kompletten Zugriff auf den Speicher und damit auch auf den Speicher des Applikationsprozessors. Abbildung 1 zeigt diesen Fall. Bei einer besseren Isolation haben aber beide getrennte Speicherbereiche und teilen sich nur einen Bereich zur Kommunikation [4]. Informationen werden entweder über standardisierte AT- Befehle [16] oder herstellerabhängige, proprietäre Protokolle ausgetauscht [5]. Zum Beispiel kann der Applikationsprozessor mit dem AT-Befehl AT+CBC den aktuellen Akkustatus abfragen [16, S. 102]. Falls die Baseband-Komponente +CBC:0,50 zurückgibt, signalisiert die Null den Akkubetrieb und 50 den aktuellen Ladestatus des Akkus in Prozent. Die Baseband-Komponente und die SIM-Karte sind über ein spezielles elektrisches Interface [17, S. 21ff.] verbunden. Auf der Anwendungsschicht stellt die Application Protocol Data Unit (APDU) das Austauschformat dar [14, S. 37ff.]. Damit kann die Baseband-Komponente zum Beispiel Dateien auf der SIM-Karte abfragen oder die PIN ändern. Hierbei geht die Kommunikation von der Baseband-Komponente aus. Auf jede Anfrage folgt eine Antwort der SIM-Karte. Allerdings kann auch die SIM-Karte die Initiative ergreifen. Mit dem SIM Application Toolkit (SAT) stehen Befehle und Mechanismen zur Verfügung, mit denen ein SIM-Applet mit der Baseband-Komponente und dem Applikationsprozessor kommunizieren kann [18]. So kann ein Applet SMS senden oder Dialoge mit dem Smartphonenutzer initiieren. Dafür wird ein SAT-Befehl in einem APDU-Befehl übertragen [14, S. 36]. Die Kommunikation der drei Smartphone-Komponenten kann nun durch eine Verschachtlung der einzelnen Befehle erfolgen. Um zum Beispiel eine SMS-Nachricht von der SIM- Karte abzufragen, fügt der Applikationsprozessor einen APDU- Befehl in einen AT-Befehl ein [16, S. 118]. III. BASEBAND-KOMPONENTE Bei der Betrachtung der GSM-Sicherheit steht oft das Protokoll selbst im Fokus. Beispielsweise ist die GSM- Verschlüsselung durch die A5/1 bis A5/4 Verfahren Gegenstand verschiedener Arbeiten, wobei die Verfahren A5/1 und A5/2 praktisch gebrochen sind [19] [22].

UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/2015 3 Weniger im Mittelpunkt stand bis jetzt die Software- Implementierung von GSM, der GSM Software Stack. Eine Untersuchung ist schwierig, da Hersteller hier Sicherheit durch Geheimhaltung (Security by Obscurity) versuchen zu erreichen [5]. Der Software mangelt es teils an modernen Sicherheitsfunktionen wie ASLR oder DEP [4], [23]. Zusätzlich findet bei GSM keine gegenseitige Authentifizierung zwischen dem Smartphone und der Basisstation statt [4]. Anhang A beschreibt den Ablauf der Authentifizierung (und der Verschlüsselung) bei GSM. Das Smartphone authentifiziert sich zwar bei der Basisstation, aber nicht umgekehrt. Jeder, der eine eigene Basisstation mit einem stärkeren Signal als die richtige Station aufsetzt, kann so die Kommunikation kontrollieren. Open-Source-Projekte und kostengünstige Hardware erlauben seit jüngerer Zeit ein einfacheres Aufsetzen als früher. Programmfehler und mangelnde Sicherheitsfunktionen im GSM Software Stack zusammen mit einer eigenen Basisstation erlauben einem Angreifer das gezielte Ausnutzen von Schwachstellen, um so die Baseband-Komponente zu übernehmen. Ein Angriff erfolgt dabei in drei Schritten, welche diese Arbeit abschnittsweise erläutert: 1) eine eigene Basisstation aufsetzen (Abschnitt III-A), 2) Programmfehler finden (Abschnitt III-B), 3) einen Exploit entwerfen und nutzen (Abschnitt III-C). A. Aufsetzen einer eigenen Basisstation Ein Angreifer muss zunächst eine eigene GSM-Basisstation aufstellen. Auf Hardware-Seite kann zum Beispiel ein Universal Software Radio Peripheral (USRP) der Firma Ettus Research mit weiteren, kleineren Anpassungen als Basisstation verwendet werden [4]. Die Kosten belaufen sich auf ungefähr 1500$ [4]. Auf Software-Seite stellen die Open-Source Projekte OpenBTS und OsmoBTS eine fertige Implementierung einer GSM-Basisstation dar. Zusammen mit dem USRP ist somit der Betrieb einer eigenen GSM-Basisstation möglich [4]. Sofern ein Smartphone vorzugsweise 3G/4G nutzt, kann ein Angreifer einen Mobile Phone Jammer einsetzen [8]. Dieser blockiert die 3G/4G-Frequenzen. Aufgrund der Abwärtskompatibilität verbinden sich Smartphones dann über GSM und damit über die GSM-Basisstation des Angreifers. B. Finden von Programmfehlern Der nächste Schritt besteht in der Identifikation von Programmfehlern im GSM Software Stack, die sich für einen Exploit nutzen lassen. Wie bereits in Abschnitt II bei der Architektur erwähnt, besteht der Stack aus drei Schichten. Bisherige Arbeiten konzentrieren sich auf die oberste, dritte Schicht [4], [12]. Das Nachrichtenformat auf dieser Schicht zwischen Baseband-Komponente und Basisstation erlaubt ausreichend lange Dateninhalte, um so beispielsweise einen Exploit-Code beim Pufferüberlauf zu übertragen. Eine Nachricht der dritten Schicht besteht aus einem 16 Bit großen Header und gegebenenfalls einem oder mehrerer Information Elements (IEs) [24], [25]. Ein IE besitzt entweder eine feste oder variable Länge [25, S. 83]. Abbildung 2 zeigt beispielhaft das Nachrichtenformat mit einem Mobile-Identity- IE. Dieses IE erlaubt die Übertragung der International Mobile Bit 7 6 5 4 3 2 1 0 Oktett Ziffer 1 Ziffer p+1 Header IEI Länge Identity Type Ziffer p Abbildung 2. Nachrichtenformat der dritten Schicht im GSM Software Stack mit einem Mobile Identity Information Element als Inhalt (in Anlehnung an [24]) Subscriber Identity (IMSI) oder der Temporary Mobile Subscriber Identity (TMSI). Beide Werte werden zur Authentifizierung des Nutzers im Mobilfunknetz genutzt [24, S. 376]. Das Mobile- Identity-IE enthält zunächst ein Information Element Identifier (IEI). Dann folgt die Länge des IE-Inhalts. Der Identity-Type gibt an, ob es sich um eine IMSI oder eine TMSI handelt. Dann folgen die 16 Ziffern der TMSI (oder 15 Ziffern der IMSI). Gerade das Längenfeld bietet nun einen möglichen Angriffspunkt. Die eigene Basisstation aus Schritt 1 erlaubt einem Angreifer das Senden von Schicht-3 Nachrichten mit einem längeren als im Längenfeld angegebenen IE-Inhalt. Von besonderem Interesse ist hierbei die teils widersprüchliche GSM-Spezifikation. So erlauben manche IEs eine variable Länge, obwohl die textuelle Beschreibung der jeweiligen IE eine feste Länge vorgibt. Beispielsweise kann obiges Mobile Identity IE eine variable Länge besitzen, allerdings ist eine TMSI genau 16 Zeichen lang [24, S. 376] [25, S. 85]. Dies kann zu klassischen Pufferüberläufen führen, falls aufgrund der Spezifikation eine Funktion eine feste Länge erwartet und nicht für den Umgang mit variablen Längen vorbereitet ist. Folgendes Szenario ist damit denkbar: Ein Angreifer sendet von der eigenen Basisstation eine Schicht-3 Nachricht mit einer Mobile Identity IE. Das Längenfeld spezifiziert zwar 16 Ziffern (TMSI), aber der Angreifer fügt eine deutlich längere Nachricht ein. Eine Funktion, die eine 16-Ziffern TMSI erwartet und nicht die Länge überprüft, kann nun abstürzen oder Code ausführen. Weinmann bringt auf diese Weise den GSM Software Stack von iphones zum Absturz, indem er eine 128 Bytes lange Nachricht im TMSI-Feld überträgt [4]. Zwei Techniken erlauben das Finden von Programmfehlern. Die Erste ist Fuzzing und betrachtet ein Programm als Black Box. Mit zufällig generierten Eingaben wird das Programmverhalten beobachtet und festgestellt, ob ein Absturz stattfindet [26, S. 178]. Das Ziel ist durch die Vielzahl der zufälligen Eingaben möglichst viele Programmpfade abzuarbeiten. Beispielsweise nutzen Broek et al. Fuzzing zum Auffinden von Fehlern bei der SMS-Verarbeitung im GSM Software Stack [12]. Allerdings zeigt Fuzzing nur durch beispielsweise einen Absturz einen Fehler an. Für die Beurteilung, ob ein sicherheitskritischer Fehler vorliegt, ist ein tieferes Verständnis der Software und der eigentlichen Absturzstelle notwendig. Dies führt zwangsläufig zur nächsten Möglichkeit. Die zweite und auch aufwendigere Möglichkeit ist ein Binary/Source Code Review. Beispielsweise stellen die Funk- 1-2 3 4 5 6*

UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/2015 4 tionen memcopy(), memmove(), bcopy() eine potenzielle Sicherheitslücke dar. So kopiert memcopy(a,b,size) alle Bytes von b zur Stelle von a ohne vorherige Längenüberprüfung. Solche Programmstellen sind potenzielle Möglichkeiten für Pufferüberläufe. Da der Source Code nicht öffentlich zugänglich ist, ist ein Reverse-Engineering des Codes notwendig. Hierfür sei auf Weinmann [4] und Delugré [10] verwiesen. Fuzzing und ein Code Review sind durchaus kombinierbar. Fuzzing findet Fehlerquellen, die sich durch eine genaue Kenntnis der Code-Basis zu Exploits weiter entwickeln lassen. Weinmann schildert weitere Fehlerquellen wie zum Beispiel Use-After-Free Fehler und Integer-Überläufe. Unzureichende Längenüberprüfungen sind jedoch die häufigsten Fehler [4]. C. Entwurf von Exploits Der letzte Schritt besteht darin, die identifizierten Programmfehler für einen Exploit zu nutzen. Für die Entwicklung ist dabei ein tieferes Verständnis der Funktionsweise des Codes bzw. Betriebssystems notwendig. So sollte für einen Pufferüberlauf der Speicheraufbau und die Heap- und Stackstruktur bekannt sein. Solche Informationen lassen sich notfalls ebenfalls durch Reverse-Engineering gewinnen. So rekonstruiert Delugré das RTOS eines Qualcomm Baseband-Chips [10]. Als konkretes Beispiel dient hier der von Weinmann beschriebene Exploit, der die automatische Rufannahme nach einer gewissen Klingel-Anzahl aktiviert [4]. Hierfür sendet der Nutzer normalerweise den AT-Befehl ATS0=n, wobei n die Klingel- Anzahl angibt. Der Wert n=0 deaktiviert die Rufannahme. Ein S0-Register speichert n. Der oben besprochene TMSI-Fehler kann einen Pufferüberlauf erlauben, welcher zur Ausführung eines eigenen Codes führt. Dieser schreibt bei ARM Baseband-Prozessoren den gewünschten n-wert ins R0-Register. Dieses Register enthält für eine aufgerufene Funktion das erste Argument. Mehr Argumente sind nicht notwendig. Für andere Prozessoren kann eine andere Argument-Übergabe notwendig sein. Nun wird der Programmzähler auf die Adresse der Funktion, die das S0- Register ändert, gesetzt. Diese liest als Argument den Wert aus dem R0-Register und aktiviert die automatische Rufannahme. Während der vorherige Exploit weniger schädlich ist, lassen sich mit einer kontrollierten Baseband-Komponente aber auch folgende Angriffe durchführen: Die Baseband-Komponente kann Zugriff auf das Mikrophon, die Kamera und GPS-Position besitzen und erlaubt so eine Überwachung des Nutzers. Das Initiieren von Anrufen und SMS-Nachrichten erlauben zum Beispiel ein Umgehen von telefonbasierten Authentifizierungsverfahren und den Versand von Premium-SMS. Falls sich Baseband- und Applikationsprozessor den Arbeitsspeicher teilen, ist auch die Übernahme von Android/iOS möglich. Die im nächsten Abschnitt beschriebenen Angriffe auf eine SIM-Karte lassen sich statt über das Mobilfunknetz direkt von der Baseband-Komponente durchführen. Zum Beispiel könnte dies Timing-Attacks erleichtern (Abschnitt IV-A). Applets JCRE Betriebssystem Physische Schicht Sim Applicat. Toolkit Applet-Firewall MMI, OTA-Management Side Channel Attacks Abbildung 3. Schichtenmodell einer SIM-Karte mit den jeweils in dieser Arbeit besprochenen Angriffsflächen jeder Schicht IV. SIM-KARTE Der folgende Abschnitt behandelt die Sicherheitsmechanismen einer SIM-Karte und mögliche Angriffe darauf. Dafür wird die Karte in dieser Arbeit in vier Schichten unterteilt, die Abbildung 3 zeigt. Die unterste Schicht stellt den physischen Aufbau einer SIM-Karte dar und umfasst Schutzmechanismen wie eine Barriere gegen einen möglichen Aufbruch. Der Abschnitt IV-A widmet sich dieser Schicht. Die darüber liegende Schicht ist das Betriebssystem, welches die Autorisierung von Dateizugriffen und die Installation neuer (Java-)Applets kontrolliert. Abschnitt IV-B behandelt diese Schicht. Die dritte Schicht umfasst die Java Card Runtime Environment (JCRE). Diese besteht aus der Java Card Virtual Machine, dem Java Card Framework und bestimmten APIs [15]. Abschnitt IV-C befasst sich mit dieser Schicht. Die einzelnen Applets stellen die letzte Schicht dar. Abschnitt IV-D beschreibt die Angriffsmöglichkeiten, die ein Applet durch die Nutzung der SIM Application Toolkit API besitzt. Dieses Schichtenmodell erlaubt eine strukturierte Sicht auf die Sicherheit einer SIM-Karte. Diese ist nur dann dann gegeben, wenn alle Schichten sicher sind. Da untere Schichten volle Kontrolle über höhere Schichten besitzen, führt beispielsweise eine Schwachstelle beim Betriebssystem zur einer Gefährdung der darüber liegenden Java Virtual Machine. A. Physische Schicht Wie oben erwähnt, ist eine Smartcard ein manipulationssicherer, kleiner Rechner. Dafür ist eine physische Barriere vorhanden, um zum Beispiel ein Auslesen des ROMs zu verhindern. Mittels Sensoren kann eine Smartcard Anomalien in Temperatur, Stromzufuhr und Taktfrequenz erkennen und bei einem erkannten Aufbruchsversuch sensible Daten löschen oder Berechnungen stoppen [6, S. 205]. Ein physischer Angriff erfordert aber nicht notwendigerweise ein Aufbrechen. Sogenannte Side Channel Attacks greifen hauptsächlich die physische Implementierung an und erfordern meist nur unmittelbare Nähe zur Karte [6, S. 207ff.]. Zum Beispiel lassen sich durch die Messung des Energieverbrauchs Rückschlüsse auf die durchgeführten Operationen ziehen [27]. Bei RSA erfordert bei einer Square-and-Multiply Implementierung ein 1-Bit im Schlüssel ein Quadrieren und Multiplizieren als Operation, während ein 0-Bit nur zum Quadrieren führt.

UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/2015 5 Beide Operationen verbrauchen unterschiedlich viel Energie, so dass das Muster des Energieverbrauchs die Bitsequenz des Schlüssels offenlegen kann [6, S. 209f.]. Rao et al. greifen ebenfalls auf Basis des Energieverbrauchs die Implementierung des COMP128-Algorithmus an, den manche Karten bei GSM zur Ableitung der Authentifizierungsund Verschlüsselungsschlüssel verwenden [28]. Eine Timing-Attack als weitere Side Channel Attack gewinnt einen Schlüssel durch die Messung der benötigten Ausführungszeit einer kryptographischen Funktion bei unterschiedlichen Eingaben [29]. Anhang B verdeutlicht diesen Angriff mit einem früheren Programmfehler der Krypto-Bibliothek Keyczar. Sofern ein Angreifer eine eigene GSM-Basissation aufsetzt, sind durch die direkte Verbindung zur Basisstation weniger Netzwerkknoten als im normalen Mobilfunknetz vorhanden. Es entstehen weniger Verzerrungen, was eine Timing-Attack erleichtert [30], [31]. Bei einem erfolgreichen Angriff ließe sich so der Ki- oder OTA-Schlüssel gewinnen. Letzterer ist Teil des noch folgenden Abschnitts IV-B2. Die Möglichkeit eine eigene GSM-Basisstation kostengünstig aufzusetzen, könnte also Angriffe und Forschungen zu diesem Szenario möglich machen. Eine kontrollierte Baseband-Komponente könnte außerdem aufgrund der unmittelbaren Nähe Timing-Attacks noch weiter erleichtern. B. Betriebssystem Dieser Abschnitt behandelt zunächst die Zugriffskontrolle einer SIM-Karte als Grundlage eines von Android aus initiierten Angriffes. Dann folgt die Beschreibung eines Angriffes auf das Over-the-Air (OTA) Management einer Karte, mit dem ein Angreifer eigene (Java-)Applets installieren kann. 1) Man-Machine-Interface Angriff: Die in der Karte gespeicherten Dateien umfassen beispielsweise Informationen für GSM wie der kryptographische Schlüssel oder die IMSI [14]. Auch Nutzerdaten wie Telefonbucheinträge und SMS-Nachrichten sind gespeichert. Eine Zugriffskontrolle schützt diese Dateien [14]: Jede Datei erfordert für eine Leseoder Schreiboperation ein jeweiliges Zugriffslevel, welches vereinfacht ausgedrückt die Authentifizierung durch eine PIN, PIN2 oder eines ADM-Codes erfordert. Letzterer ist meist nur dem Mobilfunkbetreiber bekannt. Beispielsweise ist das Lesen der IMSI nur bei vorheriger Eingabe der PIN gestattet (meist beim Smartphone-Start), während eine Änderung nur mit einem ADM-Code möglich ist. Der Angriff von Borgaonkar zeigt wie sich durch eine Schwachstelle in Android aufgrund der wechselseitigen Beziehungen im Smartphone die SIM-Zugriffskontrolle gegen den Nutzer anwenden lässt [32]: Dazu verwendet er Man-Machine- Interface (MMI) Befehle [33]. Diese erlauben dem Nutzer im Anrufmenü durch Eingabe von Befehlen beispielsweise die PIN oder PIN2 zu ändern. Ein Befehl startet dabei immer mit einem * und endet mit # [33, S. 11] 1. Zum Beispiel lässt sich 1 Davon zu unterscheiden sind Unstructered Supplementary Service Data (USSD) Befehle. Diese ermöglichen den Austausch von Informationen zwischen dem Nutzer und Mobilfunkbetreiber. Sie besitzen das gleiche Format wie MMI-Befehle. Beispielsweise initiiert *100# oft eine Kontostandabfrage beim Mobilfunkbetreiber. mit folgendem Befehl die PIN mit dem Personal Unblocking Key (PUK) ändern [33, S. 19]: **05*PUK*neue PIN*neue PIN# Android-Versionen mancher Hersteller erlauben das direkte Ausführen von MMI-Befehlen innerhalb einer App. Damit kann ein Angreifer auf einer Webseite durch einen iframe verborgene, eigene Befehle senden: <iframe src="tel:**05*12345*1234*1234# /> Falls nun die Webseite den obigen Befehl zur Änderung der PIN zehnmal mit einem falschen PUK an die SIM-Karte sendet, sperrt sich die SIM-Karte unwiderruflich. 2) OTA-Management: Ein Mobilfunkbetreiber kann Applets aus der Ferne installieren, deinstallieren oder aktualisieren (OTA-Management) [13]. Konkatenierte SMS-Nachrichten dienen dabei häufig als Trägermedium einer größeren OTA- Befehls-Nachricht [34, S. 9]. Die Baseband-Komponente leitet den OTA-Befehl ohne Anzeige beim Nutzer direkt an die SIM-Karte weiter. Die SIM-Karte akzeptiert einen OTA-Befehl aber nur mit dem korrekten Message Authentication Code (MAC) [13]. DES, 3DES oder AES kommen hierbei zum Einsatz [35, S. 12f.]. Diese symmetrischen Verfahren erfordern einen OTA-Schlüssel, den nur der Mobilfunkbetreiber und die SIM-Karte kennen. Hierfür speichert der Betreiber den OTA- Schlüssel während der Produktion in der SIM-Karte. Zusätzlich speichert der Betreiber noch weitere Schlüssel in der SIM- Karte. Anbieter eigener Applets können diese erwerben, um so beispielsweise ein Banking-Applet zu verwalten. Zwar könnte ein Angreifer einen OTA-Befehl abfangen und durch einen Brute-Force-Angriff alle Schlüsselwerte ausprobieren, allerdings ist dies selbst beim schwächsten Verfahren DES der drei Verschlüsselungsverfahren praktisch noch sehr aufwendig oder kostspielig. Jeder DES Brute-Force-Angriff pro Smartphone dauert auf einer GPU ungefähr 6 Monate [13]. Nohl [13] beschreibt dagegen einen Angriff, der zwar ein Jahr Vorberechnung benötigt, dann aber für jedes verwundbare Smartphone den jeweiligen OTA-Schlüssel in wenigen Minuten liefert. Dazu nutzt er erstens aus, dass manche Karten noch weiterhin DES zur Signatur nutzen. Zweitens ist die Fehlerbehandlung bei falsch signierten OTA-Befehlen ungenügend spezifiziert. So senden manche SIM-Karten keine oder eine einfache Fehlermeldung zurück. Aber geschätzte 25% signieren die Antwort-Fehlermeldung durch einen MAC mit dem OTA- Schlüssel und senden die Antwort zum Absender zurück [13]. Drittens kann ein Angreifer den Klartext der Antwort mit folgenden Feldern im Header eines OTA-Befehls festlegen: Security Parameter Indicator (SPI): Dieses Feld besteht aus zwei 8-Bit Folgen. Die ersten acht Bits legen fest, ob ein MAC und/oder Verschlüsselung beim Befehl eingesetzt wird. Die zweite Folge von acht Bits spezifiziert, ob eine Antwort erwartet wird (Proof of Receipt) und ob diese mit einem MAC signiert und/oder verschlüsselt sein soll. Key Identifier (KID): Dieses Feld gibt den verwendeten Algorithmus (DES, 3DES, AES) an, der für die Berechnung eines MACs eingesetzt wird. Cryptographic Checksum (CC): Dieses Feld enthält den MAC, sofern einer benutzt wird.

UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/2015 6 AN OTA-Befehl UDHI PID... SPI KIc KID TAR CTNR PCNTR CC Data 1 127... No Cipher BFFF DES 01 01 00 OTA-Antwort Belieb. Signatur Belieb. Befehl SPI: 00010010 00101001 = nur MAC, keine Verschlüsselung, signiere Antwort... TAR CTNR PCNTR Status-Code CC Data... BFFF00 01 01 01 Gültige Signatur SIM Abbildung 4. Schematischer Aufbau eines OTA-Befehls und der darauf folgenden OTA-Antwort. Jedes Paket zeigt oben die jeweiligen Feldnamen und darunter deren Inhalt. Bei KIc, KID, CC, Data ist der Inhalt sprachlich erläutert; AN = Angreifer (in Anlehnung an [13]) Der Angreifer definiert zum Beispiel im SPI-Feld eine MACsignierte Antwort und im KID-Feld die Nutzung von DES. Das CC- und Counter-Feld enthalten beliebige Werte. Abbildung 4 zeigt schematisch die Struktur des OTA-Befehls. Für eine Erklärung der übrigen Felder sei auf Nohl [13] und die ETSI TS 102 225 Spezifikation [35] verwiesen. Abbildung 4 verdeutlicht auch die Struktur des Antwort- Paketes sowie die Felder, über die der MAC berechnet wird. Alle diese Antwortfelder sind durch den vorherigen OTA-Befehl definiert. Das TAR-, CNTR- und PCNTR-Feld werden kopiert. Der Status-Code definiert einen Fehler bei der Signatur des OTA-Befehls aufgrund der beliebig gewählten Signatur. Das Datenfeld ist wegen des Fehlers leer. Die drei obigen Schwachstellen (DES, MAC-Antwort, wählbarer Klartext) kombiniert erlauben einen Time-Memory Trade- Off (TMTO) bzw. Rainbow-Table Angriff [36], [37]. Anhang C geht auf TMTO-Angriffe ein. Ein solcher Angriff erfordert bei DES eine einmalige Vorberechnung von einem Jahr und mehrere Terabyte Speicher [13]. Dann aber ist jeder OTA- Schlüssel bei verwundbaren Smartphones in wenigen Minuten berechnet. Der Angriff ist nicht möglich, falls ein Smartphone keine Antwort, eine Antwort mit zufälligen Werten oder eine Antwort ohne MAC sendet. Außerdem ist ein TMTO-Angriff bei AES oder 3DES aufgrund der Schlüssellänge praktisch nicht anwendbar. Ein Angreifer kann aber an eine große Anzahl von Smartphones einen OTA-Befehl über das normale Mobilfunknetz senden und die verwundbaren Smartphones aus den Antworten herausfiltern. Nach Berechnung des jeweiligen OTA-Schlüssels kann der Angreifer ein eigenes Java-Applet signieren und aus der Ferne installieren. C. Java Card Runtime Environment Sobald ein Angreifer Zugriff auf die SIM-Karte durch ein Java-Applet besitzt, kann er Sicherheitslücken in der JCRE für den Zugriff auf geschützte Speicherbereiche nutzen. Eine Applet-Firewall isoliert die einzelnen Applets (Sandbox- Konzept) [15]. Ein Applet kann nur auf eine Datei in der eigenen Umgebung oder über die JCRE auf ein shared object eines anderen Applets zugreifen. Die Java VM überprüft stets den angeforderten Bereich eines Java-Arrays. Folgender Zugriff sollte zu einer Out-of-Bounds-Exception führen: byte a[] = new byte[1000]; byte b = a[1200]; Nohl hat beispielsweise eine Möglichkeit gefunden die Überprüfung der Grenzen zu umgehen, indem er eine Reihe von Dereferenzierungen nutzt, um den Integerwert mit der gewünschten Speicherstelle anzugeben [13]. Damit erhält er Zugriff auf den kompletten Speicher. Somit kann ein Angreifer den Ki-Schlüssel oder sensible Daten anderer Applets auslesen. Aber auch das Betriebssystem lässt sich ändern, um Sicherheitsupdates zu verhindern. Verschiedene Veröffentlichungen beschreiben weitere Schwachstellen von JCRE-Versionen, unter anderem auch in Kombination mit Side Channel Attacks [38] [40]. D. Java Applets Dieser Abschnitt beschreibt die offiziellen Befehle des SIM Application Toolkits, mit der ein Java-Applet nach außen kommunizieren kann [18]. Diese Befehle erlauben aber auch einen Missbrauch durch ein eigenes Applet. Folgende Aktionen und damit denkbare Angriffe sind möglich [13]: SMS senden: Ein Applet kann eigenständig SMS versenden. Eine Missbrauchsmöglichkeit wäre der Versand von Premium-SMS. Anrufe tätigen: Ein Applet kann Anrufe initiieren und Tastentöne beim Anruf schicken. Damit kann zum Beispiel ein Angreifer telefonbasierte Authentifizierungsverfahren umgehen oder Nachrichten auf der Mailbox weiterleiten. GPS: Die Abfrage des GPS-Standortes ist möglich. Damit kann ein Applet den Nutzer überwachen und die Daten in der SIM-Karte zwischenspeichern. Diese sendet es per SMS über die Baseband-Komponente am Applikationsprozessor vorbei zum Angreifer. URL: Ein Applet kann einen Befehl zum Öffnen einer URL an Android/iOS senden, womit Phishing oder der Drive-By Download von Malware denkbar wäre. Denkbar wäre außerdem, dass Angriffe auf die Baseband- Komponente aus Abschnitt III von der SIM-Karte anstelle einer eigenen Basisstation durchgeführt werden. Die Angriffe in diesem Abschnitt verdeutlichen nochmals, wie eine Schwachstelle in der SIM-Karte die Sicherheit der anderen Smartphone-Komponenten gefährdet. Beispielsweise kann ein SIM-Applet eine URL in Android/iOS öffnen lassen und so den Drive-By Download einer Malware-App initiieren. Falls der Nutzer die Installation bestätigt, hat der Angreifer den Applikationsprozessor (teils) unter Kontrolle.

UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/2015 7 V. DISKUSSION Diese Arbeit gibt einen Überblick über die Teilsysteme eines Smartphones und deren Angriffsfläche. Der Fokus liegt hierbei auf der Baseband-Komponente und der SIM-Karte. Die besprochenen Angriffsszenarien zeigen, dass ein Angreifer aus der Ferne beide Systeme übernehmen kann. (Ältere) GSM-Implementierungen auf der Baseband- Komponente besitzen keine modernen Sicherheitsfunktionen und sind damit zum Beispiel durch einen Pufferüberlauf leicht verwundbar. Mit einer eigenen Basisstation sendet ein Angreifer dazu eine Nachricht in Überlänge, um so einen eigenen Exploit ausführen zu lassen. Manche SIM-Karten erlauben einem Angreifer durch eine Schwachstelle beim Over-the-Air Management die Installation eines eigenen SIM-Applets. Solch ein Applet kann dann durch Schwachstellen in der Java Virtual Machine die gesamte Karte kontrollieren. Die Übernahme einer der beiden Teilsysteme führt zudem zu einer Gefährdung des gesamten Smartphones. Falls beispielsweise Android die GPS-Überwachung eines Nutzers verhindert, wechselt der Angreifer den Angriffspunkt und überwacht den Nutzer mit einem SIM-Applet. Aber auch die Übernahme der Baseband-Komponente ist von der SIM-Karte anstelle einer Basisstation denkbar, indem ein SIM-Applet durch eine Nachricht einen Pufferüberlauf in der Baseband- Komponente provoziert. Teilen sich die Baseband-Komponente und der Applikationsprozessor den Arbeitsspeicher, sind mit einer Übernahme der Baseband-Komponente zudem die Sicherheitsmechanismen von Android/iOS wirkungslos. Angriffe auf den Applikationsprozessor und damit auf Android/iOS sind aufgrund des begrenzten Umfangs nicht Teil dieser Arbeit. Die Sicherheit dieser Betriebssysteme ist nicht weniger wichtig, da diese in direkter Weise mit dem Nutzer und dessen Daten agieren. Allerdings stehen Android/iOS auch stärker im öffentlichen Fokus, so dass sich diese Arbeit auf die vernachlässigten Teilsysteme konzentriert. Wie bei der Erläuterung der Architektur gezeigt, enthält ein Smartphone neben der Baseband-Komponente und der SIM- Karte weitere Systeme wie GPS, Wifi und Bluetooth. Auch diese und deren Einfluss auf andere Komponenten müssen in weiteren Arbeiten in die Gesamtbetrachtung der Smartphone- Sicherheit einbezogen werden. In der Baseband-Komponente steht GSM im Zentrum dieser Arbeit, da sich hierzu detaillierte Forschungsarbeiten finden [4], [12]. Die Möglichkeit eigene GSM-Netzwerke aufzustellen motiviert hoffentlich weitere Überprüfungen der GSM- Implementierung, die auch die aktuellen Entwicklungen der Baseband-Hersteller berücksichtigen. Zum Beispiel bespricht Weinmann die Hexagon-Architekur von neueren Qualcomm Baseband-Chips [41]. Aber auch die Überprüfung der 3G- und 4G-Implementierung ist in zukünftigen Arbeiten erforderlich. Auf Protokollebene beheben 3G und 4G Sicherheitsfehler von GSM. So findet zum Beispiel eine gegenseitige Authentifizierung zwischen Smartphone und Basisstation statt. Aber Weinmann beschreibt zum Beispiel, dass eine Nachricht verarbeitet wird bevor eine Authentifizierung stattfindet [4]. Dies gibt eventuell Spielraum für neue Programmfehler. Die Sicherheit eines Smartphones lässt sich also gut mit einem Kartenhaus vergleichen. Falls nur eine Komponente eine Schwachstelle besitzt, ist das gesamte System gefährdet. Diese Arbeit versucht in einem ersten Schritt alle Komponenten in die Sicherheitsanalyse einzubeziehen und sich nicht nur auf eine zu konzentrieren. LITERATUR [1] Google 2-step verification, http://www.google.com/landing/2step/, 2014, Abrufdatum 01-Oktober-2014. [2] R. M. van Rijswijk and van Dijk, J., Tiqr: a novel take on two-factor authentication, in 25th International Conference on Large Installation System Administration, 2011, pp. 81 97. [3] GSMA Intelligence, Smartphone forecasts and assumptions 2007-2020, https://gsmaintelligence.com/analysis/2014/09/ smartphone-forecasts-and-assumptions-20072020/443/, 2014, Abrufdatum 03-Dezember-2014. [4] R.-P. Weinmann, Baseband attacks: Remote exploitation of memory corruptions in cellular protocol stacks, in USENIX Workshop on Offensive Technologies, 2012, pp. 12 21. [5] H. Welte, Anatomy of contemporary GSM cellphone hardware, Techn. Report, 2010. [6] K. E. Mayes and K. Markantonakis, Eds., Smart Cards, Tokens, Security and Applications. Springer Science + Business Media, 2008. [7] M. Becher, F. Freiling, J. Hoffmann, T. Holz, S. Uellenbeck, and C. Wolf, Mobile security catching up? revealing the nuts and bolts of the security of mobile devices, in IEEE Symposium on Security and Privacy, 2011, pp. 96 111. [8] D. Perez and J. Pico, A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications, BlackHat Conference, 2011. [9] H. Welte, Anatomy of contemporary smartphone hardware, 25th Chaos Communication Congress, 2008. [10] G. Delugré, Reverse-engineering a qualcomm baseband, 28th Chaos Communication Congress, 2011. [11] ETSI, Digital cellular telecommunications system (phase 2+); universal mobile telecommunications system (UMTS); LTE; network architecture (3GPP TS 23.002 version 12.5.0 release 12), ETSI TS 123 002 Version 12.5.0, 2014. [12] F. van den Broek, B. Hond, and A. Cedillo Torres, Security testing of GSM implementations, in Engineering Secure Software and Systems, ser. Lecture Notes in Computer Science, J. Jürjens, F. Piessens, and N. Bielova, Eds. Springer International Publishing Switzerland, 2014, vol. 8364, pp. 179 195. [13] K. Nohl, Rooting SIM cards, BlackHat Conference, 2013. [14] ETSI, Digital cellular telecommunications system (phase 2+); specification of the subscriber identity module - mobile equipment (SIM-ME) interface (3GPP TS 11.11 version 8.14.0 release 1999), ETSI TS 100 977 Version 8.14.0, 2007. [15] C. E. Ortiz, An introduction to java card technology - part 1, http:// www.oracle.com/technetwork/java/javacard/javacard1-139251.html, 2003, Abrufdatum 03-Dezember-2014. [16] ETSI, Digital cellular telecommunications system (phase 2+); universal mobile telecommunications system (UMTS); LTE; AT command set for user equipment (UE) (3GPP TS 27.007 version 12.6.0 release 12), ETSI TS 127 007 Version 12.6.0, 2014. [17], Smart cards; UICC-terminal interface; physical and logical characteristics (release 8), ETSI TS 102 221 Version 8.2.0, 2009. [18], Digital cellular telecommunications system (phase 2+); specification of the SIM application toolkit (SAT) for the subscriber identity module - mobile equipment (SIM-ME) interface (3GPP TS 11.14 version 8.18.0 release 1999), ETSI TS 101 267 Version 8.18.0, 2007. [19] A. Biryukov, A. Shamir, and D. Wagner, Real time cryptanalysis of A5/1 on a PC, in Fast Software Encryption, ser. Lecture Notes in Computer Science, G. Goos, J. Hartmanis, J. van Leeuwen, and B. Schneier, Eds. Springer Berlin Heidelberg, 2001, vol. 1978, pp. 1 18. [20] E. Barkan, E. Biham, and N. Keller, Instant ciphertext-only cryptanalysis of GSM encrypted communication, in Advances in Cryptology CRYPTO 03, ser. Lecture Notes in Computer Science, D. Boneh, Ed. Springer Berlin Heidelberg, 2003, vol. 2729, pp. 600 616. [21] K. Nohl and C. Paget, GSM SRSLY? 26th Chaos Communication Congress, 2009. [22] K. Nohl, Attacking phone privacy, BlackHat Conference, 2010.

UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/2015 8 [23] H. Welte and S. Markgraf, Running your own GSM stack on a phone, 27th Chaos Communication Congress, 2010. [24] ETSI, Digital cellular telecommunications system (phase 2+); mobile radio interface layer 3 specification (3GPP TS 04.08 version 7.21.0 release 1998), ETSI TS 100 940 Version 7.21.0, 2003. [25], Digital cellular telecommunications system (phase 2+); mobile radio interface signalling layer 3; general aspects (GSM 04.07 version 7.3.0 release 1998), ETSI TS 100 939 Version 7.3.0, 1999. [26] J. J. Drake, P. O. Fora, Z. Lanier, C. Mulliner, S. A. Ridley, and G. Wicherski, Android Hacker s Handbook. Wiley, 2014. [27] P. Kocher, J. Jaffe, and B. Jun, Differential power analysis, in Advances in Cryptology CRYPTO 99, ser. Lecture Notes in Computer Science, M. Wiener, Ed. Springer Berlin Heidelberg, 1999, vol. 1666, pp. 388 397. [28] J. Rao, P. Rohatgi, H. Scherzer, and S. Tinguely, Partitioning attacks: Or how to rapidly clone some GSM cards, in IEEE Symposium on Security and Privacy, 2002, pp. 31 41. [29] P. C. Kocher, Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems, in Advances in Cryptology CRYPTO 96, ser. Lecture Notes in Computer Science, N. Koblitz, Ed. Springer Berlin Heidelberg, 1996, vol. 1109, pp. 104 113. [30] D. Brumley and D. Boneh, Remote timing attacks are practical, Computer Networks, vol. 48, no. 5, pp. 701 716, 2005. [31] S. A. Crosby, D. S. Wallach, and R. H. Riedi, Opportunities and limits of remote timing attacks, ACM Transactions on Information and System Security, vol. 12, no. 3, pp. 17:1 17:29, 2009. [32] R. Borgaonkar, Dirty use of USSD codes in cellular network, Ekoparty Security Conference, 2012. [33] ETSI, Digital cellular telecommunications system (phase 2+); universal mobile telecommunications system (UMTS); man-machine interface (MMI) of the user equipment (UE) (3GPP TS 22.030 version 12.1.2 release 12), ETSI TS 122 030 Version 12.1.2, 2014. [34], Digital cellular telecommunications system (phase 2+); universal mobile telecommunications system (UMTS); LTE; secured packet structure for (universal) subscriber identity module (U)SIM toolkit applications (3GPP TS 31.115 version 12.0.0 release 12), ETSI TS 131 115 Version 12.0.0, 2014. [35], Smart cards; secured packet structure for UICC based applications (release 9), ETSI TS 102 225 Version 9.0.0, 2010. [36] M. E. Hellman, A cryptanalytic time-memory trade-off, IEEE Transactions on Information Theory, vol. 26, no. 4, pp. 401 406, 1980. [37] P. Oechslin, Making a faster cryptanalytic time-memory trade-off, in Advances in Cryptology CRYPTO 03, ser. Lecture Notes in Computer Science, D. Boneh, Ed. Springer Berlin Heidelberg, 2003, vol. 2729, pp. 617 630. [38] G. Bouffard and J.-L. Lanet, Reversing the operating system of a java based smart card, Journal of Computer Virology and Hacking Techniques, vol. 10, no. 4, pp. 239 253, 2014. [39] G. Barbu, H. Thiebeauld, and V. Guerin, Attacks on java card 3.0 combining fault and logical attacks, in Smart Card Research and Advanced Application, ser. Lecture Notes in Computer Science, D. Gollmann, J.-L. Lanet, and J. Iguchi-Cartigny, Eds. Springer Berlin Heidelberg, 2010, vol. 6035, pp. 148 163. [40] W. Mostowski and E. Poll, Malicious code on java card smartcards: Attacks and countermeasures, in Smart Card Research and Advanced Applications, ser. Lecture Notes in Computer Science, G. Grimaud and F.-X. Standaert, Eds. Springer Berlin Heidelberg, 2008, vol. 5189, pp. 1 16. [41] R.-P. Weinmann, Baseband exploitation in 2013. hexagon challenges, 30th Chaos Communication Congress, 2013. [42] ETSI, Digital cellular telecommunications system (phase 2+); securityrelated network functions (3GPP TS 03.20 version 8.6.0 release 1999), ETSI TS 100 929 Version 8.6.0, 2008. [43] N. Lawson, Timing attack in google keyczar library, http://rdist.root.org/ 2009/05/28/timing-attack-in-google-keyczar-library/, 2009, Abrufdatum 03-Dezember-2014. ANHANG A. GSM Authentifizierung und Verschlüsselung Der folgende Abschnitt beschreibt das GSM-Verfahren bei der Authentifizierung sowie das Initiieren der Verschlüsselung [42]. Abbildung 5 veranschaulicht diesen Ablauf mit Angabe der jeweils verwendeten Smartphone-Komponente (SIM-Karte, Baseband-Komponente). Ki A3 SIM 1 IMSI A8 3 SRES 4 Kc Daten Baseband A5 2 RAND Abbildung 5. Ablauf der GSM-Authentifizierung und Verschlüsselung mit Angabe der jeweils verwendeten Smartphone-Komponente (MB = Mobilfunkbetreiber) Die SIM-Karte speichert einen symmetrischen Schlüssel Ki für die Authentifizierung und Verschlüsselung im Mobilfunknetz. Dieser verlässt die SIM-Karte aus Sicherheitsgründen nicht und ist nur dem Mobilfunkbetreiber bekannt. Die Authentifizierung beginnt, indem die SIM-Karte zur Identifikation des Nutzers die International Mobile Subscriber Identity (IMSI) zum Mobilfunkbetreiber sendet. Dieser schickt eine Zufallszahl (RAND) zurück. Aus der RAND generiert die Karte zusammen mit dem Ki-Schlüssel durch eine Einwegfunktion, den A3-Algorithmus, eine Signed Response (SRES) zur Authentifizierung. Diesen schickt die Karte wiederum zum Betreiber. Dieser berechnet ebenfalls mit der RAND und dem durch die IMSI nachgeschlagenen Ki-Schlüssel die SRES. Bei Übereinstimmung ist das Smartphone authentifiziert. Ebenfalls aus dem Ki-Schlüssel und der RAND generiert die SIM-Karte mit dem A8-Algorithmus den Kc-Schlüssel zur symmetrischen Verschlüsselung der Mobilfunkkommunikation. Der Verschlüsselungsalgorithmus A5 arbeitet dabei in der Baseband- Komponente, um Anrufe und Nachrichten zu verschlüsseln. Der Mobilfunkbetreiber führt ebenfalls die gleichen Berechnungen durch. Die Spezifikation 3GPP TS 03.20 enthält Sequenzdiagramme, die die Netzwerkkommunikation bei der Authentifizierung und Verschlüsselung verdeutlichen [42, S. 17ff.,S. 23ff.]. B. Beispiel Timing-Attack Als Beispiel für eine Timing-Attack dient ein Programmfehler in der Krypto-Bibliothek Keyczar, mit dem ein Angreifer einen Message Authentication Code (MAC) für eine eigene Nachricht erstellen kann [43]. Der Angriff nutzt dazu eine Methode, die den MAC einer Nachricht überprüft. Die Methode erhält also eine Nachricht m und einen MAC c. Anschließend erstellt die Methode einen eigenen MAC ĉ der Nachricht mit dem geheimen Schlüssel. Den so erstellten MAC ĉ vergleicht sie mit dem erhaltenen MAC c. Folgender Python-Code implementiert den Vergleich: return self.sign(message) == mac Der Vergleich findet zeichenweise statt. Genau dies ermöglicht eine Timing-Attack. Angenommen, ein Angreifer wählt einen zufällige Folge von Bytes als MAC. Falls das erste Zeichen mit dem richtigen MAC-Wert nicht übereinstimmt, bricht der Vergleich ab und die Methode sendet eine Fehlermeldung zurück. Falls aber das erste Zeichen übereinstimmt, geht der Vergleich zum MB

UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/2015 9 zweiten Zeichen über. Ein erfolgreicher Vergleich erhöht also die Ausführungszeit der Methode, da später abgebrochen wird. Genau diese Differenz kann gemessen werden. Der Angreifer wählt also als erstes Byte alle 256 Möglichkeiten aus und sendet diese jeweils. Bei einem dieser 256 Zeichen wird die Methode eine höhere Ausführungszeit besitzen, womit dieses das richtige MAC-Zeichen sein muss. Der Angreifer geht dann über zum nächsten Zeichen und wiederholt das Verfahren. Allerdings entstehen in Netzwerken verschiedene Verzögerungen wie zum Beispiel Warteschlangenverzögerungen an Routern. Daher muss ein Angreifer jedes Zeichen eines Bytes mehrmals ausprobieren, um durch beispielsweise einen Mittelwert die Verzerrungen auszugleichen. C. Time-Memory Trade-Off Angriff Der TMTO-Angriff geht auf Hellman zurück [36] und ist ein Chosen-Plaintext-Angriff. Der Angreifer kontrolliert den Plaintext, welches das Opfer verschlüsselt. Aus dem Ciphertext lässt sich nun der verwendete Schlüssel berechnen. Der Angriff teilt sich in eine Vorberechnungsphase und eine aktive Phase auf. Als Beispiel für den Verschlüsselungsalgorithmus ist DES denkbar, der als Blockchiffre einen n = 64 Bit Input-Block mit einem k = 56 Bit Schlüssel in einen 64 Bit Ciphertext wandelt. 1) Vorberechnung: Bei der Vorberechnung probiert ein Angreifer zu einem gewählten, festen Klartext alle möglichen Schlüssel. Hierbei wird eine Verschlüsselungskette gebildet. Abbildung 6 veranschaulicht die Idee. Sei für den Augenblick die Blockgröße gleich der Schlüssellänge, also n = k. Ein Startschlüssel K 1 wird zum Verschlüsseln des festen Klartextes P verwendet. Der sich ergebene Ciphertext C 1 wird nun als Schlüssel K 2 für eine erneute Verschlüsselung angewendet. Der Klartext P bleibt stets der gleiche. Dadurch entsteht eine Kette von Verschlüsselungen. Der Ciphertext der vorangegangen Verschlüsselung wird als Schlüssel der nächsten Verschlüsselung angewendet. Die Kette stoppt frei wählbar nach L Verschlüsselungen. Die Kette ist damit durch den Startschlüssel K 1 eindeutig festgelegt. Die Zwischenwerte lassen sich stets rekonstruieren und müssen nicht gespeichert werden. Für die aktive Phase speichert der Angreifer aber noch den Endpunkt C L der Kette. Nun werden weitere Ketten mit anderen Startschlüsseln berechnet, bis alle Schlüssel in einer der Ketten auftreten. Da von jeder Kette nur die Start- und Endschlüssel als Paar gespeichert werden, ist eine Speicherung aller 2 k Schlüssel nicht mehr erforderlich. Dennoch sind alle rekonstruierbar. 2) Aktive Phase: Das Ziel der aktiven Phase ist das Berechnen des Schlüssels zu einem Ciphertext C a. Es ist bekannt, dass C a in einer der Ketten irgendwo als Ciphertext und somit als Schlüssel auftritt. Jedoch ist die genaue Kette und die Kettenposition von C a nicht bekannt. Zudem sind nur die Anfangs- und Endschlüssel jeder Kette gespeichert. Daher leitet der Angreifer erneut eine Kette für C a ab: Es wird also zunächst mit C a eine Verschlüsselung durchgeführt. Sei C b der resultierende Ciphertext. Nun wird in der Liste der Endschlüssel nachgeschlagen, ob C b auftritt. Falls dieser bei P P DES- C 1 = K 2 DES- C 2 = K 3 DES- C 3 K DES- K 1... L-1 Encrypt Encrypt Encrypt Encrypt Abbildung 6. Eine Verschlüsselungskette beim TMTO-Angriff der Länge L mit dem Startschlüssel K 1 einer Kette übereinstimmt, muss der Ciphertext C a in dieser Kette liegen. Da die Kette aber nur in eine Richtung verläuft, geht der Angreifer nun vom Startwert dieser Kette bis C a und kann so den Schlüssel herausfinden. Bei keinem übereinstimmenden Endschlüssel wird C b zur Verschlüsselung genutzt und es wird erneut in der Endschlüssel-Liste nachgeschlagen. Auf diese Weise kann ein Angreifer alle denkbaren Ableitungstiefen von C a in der Kette probieren. Falls die Schlüssellänge und Blocklänge des Verschlüsselungsverfahren nicht übereinstimmen (n k), bildet vorher eine Reduktionsfunktion einen Cipertext C i auf die Schlüssellänge ab. Für die genauen Details des Verfahrens sei auf Hellman [36] verwiesen. Oechslin beschreibt Rainbow-Tables als Verbesserung des TMTO-Angriffes [37]. P P C L