Die versteckten autonomen Systeme in Smartphones

Größe: px
Ab Seite anzeigen:

Download "Die versteckten autonomen Systeme in Smartphones"

Transkript

1 UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/ 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

2 UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/ 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].

3 UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/ 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 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 *

4 UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/ 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.

5 UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/ 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.

6 UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/ AN OTA-Befehl UDHI PID... SPI KIc KID TAR CTNR PCNTR CC Data No Cipher BFFF DES OTA-Antwort Belieb. Signatur Belieb. Befehl SPI: = nur MAC, keine Verschlüsselung, signiere Antwort... TAR CTNR PCNTR Status-Code CC Data... BFFF 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 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.

7 UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/ 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, 2014, Abrufdatum 01-Oktober [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 [3] GSMA Intelligence, Smartphone forecasts and assumptions , https://gsmaintelligence.com/analysis/2014/09/ smartphone-forecasts-and-assumptions /443/, 2014, Abrufdatum 03-Dezember [4] R.-P. Weinmann, Baseband attacks: Remote exploitation of memory corruptions in cellular protocol stacks, in USENIX Workshop on Offensive Technologies, 2012, pp [5] H. Welte, Anatomy of contemporary GSM cellphone hardware, Techn. Report, [6] K. E. Mayes and K. Markantonakis, Eds., Smart Cards, Tokens, Security and Applications. Springer Science + Business Media, [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 [8] D. Perez and J. Pico, A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications, BlackHat Conference, [9] H. Welte, Anatomy of contemporary smartphone hardware, 25th Chaos Communication Congress, [10] G. Delugré, Reverse-engineering a qualcomm baseband, 28th Chaos Communication Congress, [11] ETSI, Digital cellular telecommunications system (phase 2+); universal mobile telecommunications system (UMTS); LTE; network architecture (3GPP TS version release 12), ETSI TS Version , [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 [13] K. Nohl, Rooting SIM cards, BlackHat Conference, [14] ETSI, Digital cellular telecommunications system (phase 2+); specification of the subscriber identity module - mobile equipment (SIM-ME) interface (3GPP TS version release 1999), ETSI TS Version , [15] C. E. Ortiz, An introduction to java card technology - part 1, 2003, Abrufdatum 03-Dezember [16] ETSI, Digital cellular telecommunications system (phase 2+); universal mobile telecommunications system (UMTS); LTE; AT command set for user equipment (UE) (3GPP TS version release 12), ETSI TS Version , [17], Smart cards; UICC-terminal interface; physical and logical characteristics (release 8), ETSI TS Version 8.2.0, [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 version release 1999), ETSI TS Version , [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 [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 [21] K. Nohl and C. Paget, GSM SRSLY? 26th Chaos Communication Congress, [22] K. Nohl, Attacking phone privacy, BlackHat Conference, 2010.

8 UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/ [23] H. Welte and S. Markgraf, Running your own GSM stack on a phone, 27th Chaos Communication Congress, [24] ETSI, Digital cellular telecommunications system (phase 2+); mobile radio interface layer 3 specification (3GPP TS version release 1998), ETSI TS Version , [25], Digital cellular telecommunications system (phase 2+); mobile radio interface signalling layer 3; general aspects (GSM version release 1998), ETSI TS Version 7.3.0, [26] J. J. Drake, P. O. Fora, Z. Lanier, C. Mulliner, S. A. Ridley, and G. Wicherski, Android Hacker s Handbook. Wiley, [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 [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 [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 [30] D. Brumley and D. Boneh, Remote timing attacks are practical, Computer Networks, vol. 48, no. 5, pp , [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, [32] R. Borgaonkar, Dirty use of USSD codes in cellular network, Ekoparty Security Conference, [33] ETSI, Digital cellular telecommunications system (phase 2+); universal mobile telecommunications system (UMTS); man-machine interface (MMI) of the user equipment (UE) (3GPP TS version release 12), ETSI TS Version , [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 version release 12), ETSI TS Version , [35], Smart cards; secured packet structure for UICC based applications (release 9), ETSI TS Version 9.0.0, [36] M. E. Hellman, A cryptanalytic time-memory trade-off, IEEE Transactions on Information Theory, vol. 26, no. 4, pp , [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 [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 , [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 [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 [41] R.-P. Weinmann, Baseband exploitation in hexagon challenges, 30th Chaos Communication Congress, [42] ETSI, Digital cellular telecommunications system (phase 2+); securityrelated network functions (3GPP TS version release 1999), ETSI TS Version 8.6.0, [43] N. Lawson, Timing attack in google keyczar library, 2009/05/28/timing-attack-in-google-keyczar-library/, 2009, Abrufdatum 03-Dezember 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 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

9 UNI. MÜNSTER, COMSYS, PROF. GÜNEŞ, SEMINAR, WS 2014/ 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

Fakultät Informatik, Proseminar Technische Informationssysteme Sind Handyverbindungen abhörsicher?

Fakultät Informatik, Proseminar Technische Informationssysteme Sind Handyverbindungen abhörsicher? Fakultät Informatik, Proseminar Technische Informationssysteme? Dresden, Gliederung -Einführung -Mobilfunkstandard GSM -Mobilfunkstandard UMTS -Mobilfunkstandard LTE -Vergleich der Mobilfunkstandards -Beispiel

Mehr

Smartphone-Sicherheit

Smartphone-Sicherheit Smartphone-Sicherheit Fokus: Verschlüsselung Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz Peter Teufl Wien, 15.03.2012 Inhalt EGIZ Themen Smartphone

Mehr

Sicherheit von Smartphone-Betriebssystemen im Vergleich. Andreas Jansche Gerhard Klostermeier

Sicherheit von Smartphone-Betriebssystemen im Vergleich. Andreas Jansche Gerhard Klostermeier Sicherheit von Smartphone-Betriebssystemen im Vergleich Andreas Jansche Gerhard Klostermeier 1 / 24 Inhalt ios Sicherheitsmechanismen allgemein Sicherheits-APIs weitere Features Probleme Android Architektur

Mehr

SMARTPHONES. Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl

SMARTPHONES. Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl SMARTPHONES Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl A-SIT/Smartphones iphone security analysis (Q1 2010) Blackberry security analysis (Q1 2010) Qualifizierte Signaturen und Smartphones

Mehr

Aktuelle Bedrohungsszenarien für mobile Endgeräte

Aktuelle Bedrohungsszenarien für mobile Endgeräte Wir stehen für Wettbewerb und Medienvielfalt. Aktuelle Bedrohungsszenarien für mobile Endgeräte Ulrich Latzenhofer RTR-GmbH Inhalt Allgemeines Gefährdungen, Schwachstellen und Bedrohungen mobiler Endgeräte

Mehr

17 Ein Beispiel aus der realen Welt: Google Wallet

17 Ein Beispiel aus der realen Welt: Google Wallet 17 Ein Beispiel aus der realen Welt: Google Wallet Google Wallet (seit 2011): Kontaktlose Bezahlen am Point of Sale Kreditkarten werden im Sicherheitselement des Smartphone abgelegt Kommunikation über

Mehr

Internet Datasafe Sicherheitstechnische Herausforderungen

Internet Datasafe Sicherheitstechnische Herausforderungen ERFA-Tagung 14.9.2010 Internet Datasafe Sicherheitstechnische Herausforderungen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte Wissenschaften

Mehr

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Übersicht Internetsicherheit Protokoll Sitzungen Schlüssel und Algorithmen vereinbaren Exportversionen Public Keys Protokollnachrichten 29.10.2003 Prof.

Mehr

Kryptographische Verfahren. zur Datenübertragung im Internet. Patrick Schmid, Martin Sommer, Elvis Corbo

Kryptographische Verfahren. zur Datenübertragung im Internet. Patrick Schmid, Martin Sommer, Elvis Corbo Kryptographische Verfahren zur Datenübertragung im Internet Patrick Schmid, Martin Sommer, Elvis Corbo 1. Einführung Übersicht Grundlagen Verschlüsselungsarten Symmetrisch DES, AES Asymmetrisch RSA Hybrid

Mehr

Inhalt. Grundlegendes zu Bankkarten. Moduliertes Merkmal. PIN-Sicherheit. Seitenkanalangriffe

Inhalt. Grundlegendes zu Bankkarten. Moduliertes Merkmal. PIN-Sicherheit. Seitenkanalangriffe Inhalt Grundlegendes zu Bankkarten Moduliertes Merkmal PIN-Sicherheit Seitenkanalangriffe Harald Baier Ausgewählte Themen der IT-Sicherheit h_da SS 10 24 PIN-Erzeugung bei Debitkarten 1. Variante: Kartendaten

Mehr

Kombinierte Attacke auf Mobile Geräte

Kombinierte Attacke auf Mobile Geräte Kombinierte Attacke auf Mobile Geräte 1 Was haben wir vorbereitet Man in the Middle Attacken gegen SmartPhone - Wie kommen Angreifer auf das Endgerät - Visualisierung der Attacke Via Exploit wird Malware

Mehr

Rechneranmeldung mit Smartcard oder USB-Token

Rechneranmeldung mit Smartcard oder USB-Token Rechneranmeldung mit Smartcard oder USB-Token Verfahren zur Authentifizierung am Rechnersystem und angebotenen Diensten, SS2005 1 Inhalt: 1. Systemanmeldung 2. Grundlagen 3. Technik (letzte Woche) 4. Standards

Mehr

Sichere Identitäten in Smart Grids

Sichere Identitäten in Smart Grids Informationstag "IT-Sicherheit im Smart Grid" Berlin, 23.05.2012 Sichere Identitäten in Smart Grids Dr. Thomas Störtkuhl, Agenda 1 2 Beispiele für Kommunikationen Digitale Zertifikate: Basis für Authentifizierung

Mehr

Compass Security. Darf ich mich vorstellen? [The ICT-Security Experts] !Sprachstörungen - Datenspionage auf Smartphones

Compass Security. Darf ich mich vorstellen? [The ICT-Security Experts] !Sprachstörungen - Datenspionage auf Smartphones Compass Security [The ICT-Security Experts]!Sprachstörungen - Datenspionage auf Smartphones [!Infinigate IT-Security Day 2013 Zürich/Rüschlikon 29.08.13] Marco Di Filippo Compass Security Deutschland GmbH

Mehr

ESecuremail Die einfache Email verschlüsselung

ESecuremail Die einfache Email verschlüsselung Wie Sie derzeit den Medien entnehmen können, erfassen und speichern die Geheimdienste aller Länder Emails ab, egal ob Sie verdächtig sind oder nicht. Die Inhalte von EMails werden dabei an Knotenpunkten

Mehr

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten Versuch: Eigenschaften einer Unterhaltung Instant Messaging Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten welche Rollen gibt es in einem IM-System? Analysieren

Mehr

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr.

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY 1 Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. Bernd Borchert GLIEDERUNG 1. Motivation Gründe für die Entwicklung Ideen für

Mehr

Cnlab / CSI 2011. Demo Smart-Phone: Ein tragbares Risiko?

Cnlab / CSI 2011. Demo Smart-Phone: Ein tragbares Risiko? Cnlab / CSI 2011 Demo Smart-Phone: Ein tragbares Risiko? Agenda Demo 45 Schutz der Smart-Phones: - Angriffsszenarien - «Jailbreak» - Was nützt die PIN? - Demo: Zugriff auf Passwörter iphone Bekannte Schwachstellen

Mehr

Relevante Sicherheitskriterien aktueller mobiler Plattformen

Relevante Sicherheitskriterien aktueller mobiler Plattformen Relevante Sicherheitskriterien aktueller mobiler Plattformen RTR-Workshop Sicherheit mobiler Endgeräte Thomas Zefferer Zentrum für sichere Informationstechnologie - Austria Motivation RTR-Workshop Sicherheit

Mehr

10. WCI-Konferenz in Berlin

10. WCI-Konferenz in Berlin 10 WCI-Konferenz in Berlin Ende-zu-Ende-Sicherheit bei Long Term Evolution (LTE) Foliennr: 1 Prof- Dr-Ing Kai-Oliver Detken DECOIT GmbH Fahrenheitstraße 9 D-28359 Bremen URL: http://wwwdecoitde E-Mail:

Mehr

Secure Socket Layer V.3.0

Secure Socket Layer V.3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer V.3.0 (SSLv3) Zheng Yao 05.07.2004 1 Überblick 1.Was ist SSL? Bestandteile von SSL-Protokoll, Verbindungherstellung

Mehr

Wireless Security. IT Security Workshop 2006. Moritz Grauel grauel@informatik.hu-berlin.de Matthias Naber naber@informatik.hu-berlin.

Wireless Security. IT Security Workshop 2006. Moritz Grauel grauel@informatik.hu-berlin.de Matthias Naber naber@informatik.hu-berlin. Wireless Security IT Security Workshop 2006 Moritz Grauel grauel@informatik.hu-berlin.de Matthias Naber naber@informatik.hu-berlin.de HU-Berlin - Institut für Informatik 29.09.2006 (HU-Berlin - Institut

Mehr

Mobile ID für sichere Authentisierung im e-government

Mobile ID für sichere Authentisierung im e-government Mobile ID für sichere Authentisierung im e-government Patrick Graber Senior Security Consultant, dipl. El.-Ing. ETH Swisscom (Schweiz) AG Grossunternehmen Agenda 2 Einführung in Mobile ID Mobile ID für

Mehr

VPN unterstützt 3 verschiedene Szenarien: Host to Host: Dies kennzeichnet eine sichere 1:1 Verbindung zweier Computer, z.b. über das Internet.

VPN unterstützt 3 verschiedene Szenarien: Host to Host: Dies kennzeichnet eine sichere 1:1 Verbindung zweier Computer, z.b. über das Internet. 1. VPN Virtual Private Network Ein VPN wird eingesetzt, um eine teure dedizierte WAN Leitung (z.b. T1, E1) zu ersetzen. Die WAN Leitungen sind nicht nur teuer, sondern auch unflexibel, da eine Leitung

Mehr

Malware Detection on Mobile Clients

Malware Detection on Mobile Clients Malware Detection on Mobile Clients Michael Gröning INET RG - HAW Hamburg December, 11 th 2010 Gliederung Einleitung Motivation Schadprogramme auf Mobiltelefonen Erkennung von Malware Ziele des Projektes

Mehr

Nutzerauthentifizierung mit 802.1X. Torsten Kersting kersting@dfn.de

Nutzerauthentifizierung mit 802.1X. Torsten Kersting kersting@dfn.de Nutzerauthentifizierung mit 802.1X Torsten Kersting kersting@dfn.de Inhalt EAP Protokoll EAP Methoden 802.1X Netzwerk Port Auth. 802.1X in WLAN s 802.11i (TKIP, CCMP, RSN) Einführung Design Fehler in statischem

Mehr

Denn es geht um ihr Geld:

Denn es geht um ihr Geld: Denn es geht um ihr Geld: [A]symmetrische Verschlüsselung, Hashing, Zertifikate, SSL/TLS Warum Verschlüsselung? Austausch sensibler Daten über das Netz: Adressen, Passwörter, Bankdaten, PINs,... Gefahr

Mehr

Grundlagen der Kryptographie

Grundlagen der Kryptographie Grundlagen der Kryptographie Seminar zur Diskreten Mathematik SS2005 André Latour a.latour@fz-juelich.de 1 Inhalt Kryptographische Begriffe Primzahlen Sätze von Euler und Fermat RSA 2 Was ist Kryptographie?

Mehr

Einleitung Theorie Praxis Demo Gegenmaßnahmen Zusammenfassung. Faulty Hardware. Seminar on Mathematical Weaknesses of Cryptographic Systems

Einleitung Theorie Praxis Demo Gegenmaßnahmen Zusammenfassung. Faulty Hardware. Seminar on Mathematical Weaknesses of Cryptographic Systems Faulty Hardware Seminar on Mathematical Weaknesses of Cryptographic Systems Martin Heistermann July 17, 2013 Motivation: Beispielszenario Smartcard zur Authentifizierung Geheimnis darf nicht kopierbar

Mehr

Sicherheit in Wireless LANs

Sicherheit in Wireless LANs Sicherheit in Wireless LANs VS-Seminar Wintersemester 2002/2003 Betreuer: Stefan Schmidt Übersicht Funktion und Aufbau von Infrastruktur Wireless LAN Sicherheit in Wireless LANs Sicherungsmechanismen in

Mehr

Aktuelle Probleme der IT Sicherheit

Aktuelle Probleme der IT Sicherheit Aktuelle Probleme der IT Sicherheit DKE Tagung, 6. Mai 2015 Prof. Dr. Stefan Katzenbeisser Security Engineering Group & CASED Technische Universität Darmstadt skatzenbeisser@acm.org http://www.seceng.de

Mehr

Mobile App Testing. Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013. Functional Test Automation Tools

Mobile App Testing. Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013. Functional Test Automation Tools Functional Test Automation Tools Mobile App Testing Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013 Presenter: Christoph Preschern (cpreschern@ranorex.com) Inhalte» Ranorex Company Overview»

Mehr

Mobile Datensicherheit Überblick ios und Android

Mobile Datensicherheit Überblick ios und Android Mobile Datensicherheit Überblick ios und Android Aldo Rodenhäuser Tom Sprenger Senior IT Consultant CTO 5. November 2013 Agenda Präsentation AdNovum Smartphone Daten Kommunikationskanäle Risikolandschaft

Mehr

Verteilte Systeme. Sicherheit. Prof. Dr. Oliver Haase

Verteilte Systeme. Sicherheit. Prof. Dr. Oliver Haase Verteilte Systeme Sicherheit Prof. Dr. Oliver Haase 1 Einführung weitere Anforderung neben Verlässlichkeit (zur Erinnerung: Verfügbarkeit, Zuverlässigkeit, Funktionssicherheit (Safety) und Wartbarkeit)

Mehr

u2f authentication Universal Second Factor Jan-Erik Rediger 20. Mai 2015

u2f authentication Universal Second Factor Jan-Erik Rediger 20. Mai 2015 u2f authentication Universal Second Factor Jan-Erik Rediger 20. Mai 2015 0 who am i? Hi, ich bin Jan-Erik! Informatik-Student, RWTH Redis Contributor, Maintainer einiger Projekte rundherum damals: Webdev,

Mehr

Motivation Sicherheit. WLAN Sicherheit. Karl Unterkalmsteiner, Matthias Heimbeck. Universität Salzburg, WAP Präsentation, 2005

Motivation Sicherheit. WLAN Sicherheit. Karl Unterkalmsteiner, Matthias Heimbeck. Universität Salzburg, WAP Präsentation, 2005 Universität Salzburg, WAP Präsentation, 2005 Gliederung 1 WLAN die neue drahtlose Welt Gefahren in WLAN Netzwerken Statistische Untersuchen 2 Gliederung WLAN die neue drahtlose Welt Gefahren in WLAN Netzwerken

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

Wiederholung: Informationssicherheit Ziele

Wiederholung: Informationssicherheit Ziele Wiederholung: Informationssicherheit Ziele Vertraulichkeit: Schutz der Information vor unberechtigtem Zugriff bei Speicherung, Verarbeitung und Übertragung Integrität: Garantie der Korrektheit (unverändert,

Mehr

Bewusster Umgang mit Smartphones

Bewusster Umgang mit Smartphones Bewusster Umgang mit Smartphones Komponenten Hardware OS-Prozessor, Baseband-Prozessor Sensoren Kamera, Mikrofon, GPS, Gyroskop, Kompass,... Netzwerk: WLAN-Adapter, NFC, Bluetooth,... Software Betriebssystem

Mehr

Das Kerberos-Protokoll

Das Kerberos-Protokoll Konzepte von Betriebssystemkomponenten Schwerpunkt Authentifizierung Das Kerberos-Protokoll Referent: Guido Söldner Überblick über Kerberos Network Authentication Protocol Am MIT Mitte der 80er Jahre entwickelt

Mehr

Workshop: IPSec. 20. Chaos Communication Congress

Workshop: IPSec. 20. Chaos Communication Congress Cryx (cryx at h3q dot com), v1.1 Workshop: IPSec 20. Chaos Communication Congress In diesem Workshop soll ein kurzer Überblick über IPSec, seine Funktionsweise und Einsatzmöglichkeiten gegeben werden.

Mehr

www.eset.de Bewährt. Sicher.

www.eset.de Bewährt. Sicher. www.eset.de Bewährt. Sicher. Starke Authentifizierung zum Schutz Ihrer Netzwerkzugänge und -daten ESET Secure Authentication bietet eine starke zusätzliche Authentifizierungsmöglichkeit für Remotezugriffe

Mehr

Sicherheit in Android

Sicherheit in Android Motivation Aufbau Sicherheit Ausblick Quellen Sicherheit in Android Peter Salchow INF-M2 - Anwendungen 1 Sommersemester 2008 Department Informatik HAW Hamburg 20. Mai 2008 Peter Salchow Sicherheit in Android

Mehr

SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen

SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen Immo FaUl Wehrenberg immo@ctdo.de Chaostreff Dortmund 16. Juli 2009 Immo FaUl Wehrenberg immo@ctdo.de (CTDO) SSL/TLS Sicherheit

Mehr

Benutzerhandbuch (Powered by App Security Technology)

Benutzerhandbuch (Powered by App Security Technology) m-identity Protection Demo App v 2.5 Trusted Login, Trusted Message Sign und Trusted Web View Benutzerhandbuch (Powered by App Security Technology) Inhaltsverzeichnis Anforderungen... 3 1 Inbetriebnahme...

Mehr

Anlage zur Akkreditierungsurkunde D-PL-19015-01-00 nach DIN EN ISO/IEC 17025:2005

Anlage zur Akkreditierungsurkunde D-PL-19015-01-00 nach DIN EN ISO/IEC 17025:2005 Deutsche Akkreditierungsstelle GmbH Anlage zur Akkreditierungsurkunde D-PL-19015-01-00 nach DIN EN ISO/IEC 17025:2005 Gültigkeitsdauer: 15.12.2014 bis 14.12.2019 Ausstellungsdatum: 15.12.2014 Urkundeninhaber:

Mehr

Nach Hause telefonieren

Nach Hause telefonieren Technische Universität Berlin FG Security in Telecommunications Matthias Lange, 03.05.2011 mlange@sec.t-labs.tu-berlin.de Nach Hause telefonieren Wie funktioniert eigentlich Mobilfunk? Technisches Seminar

Mehr

IT-Sicherheit Kapitel 3 Public Key Kryptographie

IT-Sicherheit Kapitel 3 Public Key Kryptographie IT-Sicherheit Kapitel 3 Public Key Kryptographie Dr. Christian Rathgeb Sommersemester 2013 1 Einführung In der symmetrischen Kryptographie verwenden Sender und Empfänger den selben Schlüssel die Teilnehmer

Mehr

Apple iphone und ipad im Unternehmen. Ronny Sackmann ronny.sackmann@cirosec.de

Apple iphone und ipad im Unternehmen. Ronny Sackmann ronny.sackmann@cirosec.de Apple iphone und ipad im Unternehmen Ronny Sackmann ronny.sackmann@cirosec.de Agenda Einführung Bedrohungen Integrierte Schutzfunktionen Sicherheitsmaßnahmen Zentrale Verwaltungswerkzeuge Zusammenfassung

Mehr

Security Issues in Mobile NFC Devices

Security Issues in Mobile NFC Devices Dissertation Doktoratsstudium der Techn. Wissenschaften Angefertigt am Institut für Computational Perception Beurteilung: Dr. Josef Scharinger Dr. René Mayrhofer Security Issues in Mobile NFC Devices Michael

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

"Practical Cryptography" Kapitel 8, 9, 15, 16 und 22 (Ferguson/Schneider)

Practical Cryptography Kapitel 8, 9, 15, 16 und 22 (Ferguson/Schneider) "Practical Cryptography" Kapitel 8, 9, 15, 16 und 22 (Ferguson/Schneider) Seminar Internetsicherheit TU-Berlin Martin Eismann Martin Eismann Internet-Sicherheit Practical Cryptography Folie 1 Was ist Sicherheit?

Mehr

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter Datensicherheit Vorlesung 5: 15.5.2015 Sommersemester 2015 h_da, Lehrbeauftragter Inhalt 1. Einführung & Grundlagen der Datensicherheit 2. Identitäten / Authentifizierung / Passwörter 3. Kryptografie 4.

Mehr

Methoden der Kryptographie

Methoden der Kryptographie Methoden der Kryptographie!!Geheime Schlüssel sind die sgrundlage Folien und Inhalte aus II - Der Algorithmus ist bekannt 6. Die - Computer Networking: A Top außer bei security by obscurity Down Approach

Mehr

Mobile ID für sichere Authentisierung im e-government

Mobile ID für sichere Authentisierung im e-government Mobile ID für sichere Authentisierung im e-government Patrick Graber Senior Security Consultant, dipl. El.-Ing. ETH Swisscom (Schweiz) AG Grossunternehmen Agenda 2 Einführung in Mobile ID Mobile ID für

Mehr

Dynamische Web-Anwendung

Dynamische Web-Anwendung Dynamische Web-Anwendung Christiane Lacmago Seminar Betriebssysteme und Sicherheit Universität Dortmund WS 02/03 Gliederung Einleitung Definition und Erläuterung Probleme der Sicherheit Ziele des Computersysteme

Mehr

Selbstverteidigung im Web

Selbstverteidigung im Web An@- Hacking- Show Selbstverteidigung im Web Marcel Heisig Norman Planner Niklas Reisinger am 27.10.2011 1 Inhalt der Veranstaltung Live- Vorführung gängiger Angriffsszenarien Schutzmaßnahmen Diskussion

Mehr

Was ist eine Firewall? Bitdefender E-Guide

Was ist eine Firewall? Bitdefender E-Guide Was ist eine Firewall? Bitdefender E-Guide 2 Inhalt Was ist eine Firewall?... 3 Wie eine Firewall arbeitet... 3 Welche Funktionen eine Firewall bieten sollte... 4 Einsatz von mehreren Firewalls... 4 Fazit...

Mehr

Digital Signature and Public Key Infrastructure

Digital Signature and Public Key Infrastructure E-Governement-Seminar am Institut für Informatik an der Universität Freiburg (CH) Unter der Leitung von Prof. Dr. Andreas Meier Digital Signature and Public Key Infrastructure Von Düdingen, im Januar 2004

Mehr

Authentifizierung. Benutzerverwaltung mit Kerberos. Referent: Jochen Merhof

Authentifizierung. Benutzerverwaltung mit Kerberos. Referent: Jochen Merhof Authentifizierung Benutzerverwaltung mit Kerberos Referent: Jochen Merhof Überblick über Kerberos Entwickelt seit Mitte der 80er Jahre am MIT Netzwerk-Authentifikations-Protokoll (Needham-Schroeder) Open-Source

Mehr

Secure Socket Layer v. 3.0

Secure Socket Layer v. 3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer v. 3.0 (SSLv3) Zheng Yao 05.07.2004-1 - 1. Was ist SSL? SSL steht für Secure Socket Layer, ein Protokoll zur Übertragung

Mehr

KeePass. 19.01.2010 10:15-10:45 Uhr. Birgit Gersbeck-Schierholz, IT-Sicherheit, RRZN

KeePass. 19.01.2010 10:15-10:45 Uhr. Birgit Gersbeck-Schierholz, IT-Sicherheit, RRZN KeePass the free, open source, light-weight and easy-to-use password manager 19.01.2010 10:15-10:45 Uhr Birgit Gersbeck-Schierholz, IT-Sicherheit, RRZN Agenda Einführung Versionen Features Handhabung Mobile

Mehr

Multicast Security Group Key Management Architecture (MSEC GKMArch)

Multicast Security Group Key Management Architecture (MSEC GKMArch) Multicast Security Group Key Management Architecture (MSEC GKMArch) draft-ietf-msec-gkmarch-07.txt Internet Security Tobias Engelbrecht Einführung Bei diversen Internetanwendungen, wie zum Beispiel Telefonkonferenzen

Mehr

Authentikation und digitale Signatur

Authentikation und digitale Signatur TU Graz 23. Jänner 2009 Überblick: Begriffe Authentikation Digitale Signatur Überblick: Begriffe Authentikation Digitale Signatur Überblick: Begriffe Authentikation Digitale Signatur Begriffe Alice und

Mehr

Remote Access. Virtual Private Networks. 2000, Cisco Systems, Inc.

Remote Access. Virtual Private Networks. 2000, Cisco Systems, Inc. Remote Access Virtual Private Networks 2000, Cisco Systems, Inc. 1 Remote Access Telefon/Fax WWW Banking E-mail Analog (?) ISDN xdsl... 2 VPNs... Strong encryption, authentication Router, Firewalls, Endsysteme

Mehr

Sicherheit im Mobile Computing Praxisforum "Anwender und Anbieter im Dialog - Mobile Sicherheit im Unternehmen" 4.12.2014, IHK Akademie München

Sicherheit im Mobile Computing Praxisforum Anwender und Anbieter im Dialog - Mobile Sicherheit im Unternehmen 4.12.2014, IHK Akademie München Dr. Martin Werner Sicherheit im Mobile Computing Praxisforum "Anwender und Anbieter im Dialog - Mobile Sicherheit im Unternehmen" 4.12.2014, IHK Akademie München Dr. Martin Werner Überblick Sicherheit

Mehr

11 Instanzauthentisierung

11 Instanzauthentisierung 11 Instanzauthentisierung B (Prüfer) kann die Identität von A (Beweisender) zweifelsfrei feststellen Angreifer O versucht, Identität von A zu übernehmen (aktiver Angri ) Oskar (O) Alice (A) Bob (B) Faktoren

Mehr

MAC Message Authentication Codes

MAC Message Authentication Codes Seminar Kryptographie SoSe 2005 MAC Message Authentication Codes Andrea Schminck, Carolin Lunemann Inhaltsverzeichnis (1) MAC (2) CBC-MAC (3) Nested MAC (4) HMAC (5) Unconditionally secure MAC (6) Strongly

Mehr

web'n'walk Box Mobile WLAN Bedienungsanleitung

web'n'walk Box Mobile WLAN Bedienungsanleitung web'n'walk Box Mobile WLAN Bedienungsanleitung 1 3 Beispiel Internet gleichzeitig im Internet Mobiler leistungsfähige Installation Alternativ via USB Kabel am PC, MAC oder im Auto als dauerhaften Mobilen

Mehr

SMARTPHONE SECURITY. Sichere Integration mobiler Endgeräte

SMARTPHONE SECURITY. Sichere Integration mobiler Endgeräte Sichere Integration mobiler Endgeräte ÜBERSICHT PROFI MOBILE SERVICES.mobile PROFI Mobile Business Agenda Workshops Themen Business Case Design Business Case Zielgruppe / -markt Zielplattform BPM fachlich

Mehr

Mobile Security Smartphones

Mobile Security Smartphones Mobile Security Smartphones Schmelztiegel privater und geschäftlicher Aktivitäten eberhard@keyon.ch V1.1 2011 by keyon (www.keyon.ch) Über Keyon Warum Smartphones Welcher Nutzen wird vom Unternehmen erwartet?

Mehr

Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com

Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com 1 Ingo Schubert Technical Consultant Central Europe +49 89 540 523-01 ischubert@baltimore.com 2 Baltimore auf einen Blick Weltmarktführer für e security Produkte, Service, und Lösungen Weltweite Niederlassungen

Mehr

cnlab security engineering Mobile Security Vergleich Sicherheitsmechanismen in Apples ios und in Googles Android

cnlab security engineering Mobile Security Vergleich Sicherheitsmechanismen in Apples ios und in Googles Android cnlab security engineering Mobile Security Vergleich Sicherheitsmechanismen in Apples ios und in Googles Android September 2013 Inhalt Risiko-Analyse Eingebaute Sicherheitsmechanismen Vergleich der Risiken

Mehr

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

Mehr

Häufig gestellte Fragen Erfahren Sie mehr über MasterCard SecureCode TM

Häufig gestellte Fragen Erfahren Sie mehr über MasterCard SecureCode TM Informationen zu MasterCard SecureCode TM 3 1. Was ist der MasterCard SecureCode TM? 3 2. Wie funktioniert MasterCard SecureCode TM? 3 3. Wie schützt mich MasterCard SecureCode TM? 3 4. Ist der Umgang

Mehr

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8 Byte-Taxi Bedienungsanleitung Seite 1 von 8 Inhaltsverzeichnis 1. Beschreibung 3 2. Systemvoraussetzungen 4 3. Installationsanleitung 5 4. Bedienung 6 5. Infos & Kontakt 8 Seite 2 von 8 1. Beschreibung

Mehr

Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen. Fabian Pretsch

Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen. Fabian Pretsch Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen Fabian Pretsch Ziel Implementierung von XML Encryption/Signature in Java Testen der Implementierung auf

Mehr

8. Von den Grundbausteinen zu sicheren Systemen

8. Von den Grundbausteinen zu sicheren Systemen Stefan Lucks 8. Grundb. sich. Syst. 211 orlesung Kryptographie (SS06) 8. Von den Grundbausteinen zu sicheren Systemen Vorlesung bisher: Bausteine für Kryptosysteme. Dieses Kapitel: Naiver Einsatz der Bausteine

Mehr

Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen

Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen Agenda 1. Kerckhoff sches Prinzip 2. Kommunikationsszenario 3. Wichtige Begriffe 4. Sicherheitsmechanismen 1. Symmetrische Verschlüsselung

Mehr

MDM meets MAM. Warum mobile Sicherheit nicht allein durch MDM-Systeme gewährleistet werden kann

MDM meets MAM. Warum mobile Sicherheit nicht allein durch MDM-Systeme gewährleistet werden kann MDM meets MAM Warum mobile Sicherheit nicht allein durch MDM-Systeme gewährleistet werden kann Wulf Bolte (CTO) & Wolf Aschemann (Lead Security Analyst) Wie werden Unternehmen üblicherweise angegriffen?

Mehr

Konzepte von Betriebssystem-Komponenten: SSH

Konzepte von Betriebssystem-Komponenten: SSH Benutzersicht - Algorithmen - Administration Andre Lammel Inhalt Allgemeines Einführung Historisches Überblick Struktur Transport Layer Authentication Layer Connection Layer Administration

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen FAEL-Seminar Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte

Mehr

Anonymes Kommunizieren mit Mixminion

Anonymes Kommunizieren mit Mixminion Anonymes Kommunizieren mit Mixminion Seminar Peer-to-Peer Netzwerke Claudius Korzen Institut für Informatik Albert-Ludwigs-Universität, Freiburg SS 2009 28. Juli 2009 1/ 35 Überblick 1 Motivation 2 Grundlagen

Mehr

Hardware based security for Smart Grids July 2011 Thomas Denner

Hardware based security for Smart Grids July 2011 Thomas Denner Hardware based security for Smart Grids July 2011 Thomas Denner INSIDE General Business Use Thomas Denner Expert Secure Products Inside Secure Konrad-Zuse-Ring 8 81829 München tdenner@insidefr.com 2 Wer

Mehr

ESecure Vault Die verschlüsselte CloudFESTplatte

ESecure Vault Die verschlüsselte CloudFESTplatte Sie möchten von überall aus auf Ihre Daten zugreifen, aber niemand anderes soll Ihre Daten einsehen können? Mit dem Secure Vault von Evolution Hosting stellen wir Ihnen ein sicheres System vor. Sie müssen

Mehr

Kurzeinführung VPN. Veranstaltung. Rechnernetze II

Kurzeinführung VPN. Veranstaltung. Rechnernetze II Kurzeinführung VPN Veranstaltung Rechnernetze II Übersicht Was bedeutet VPN? VPN Typen VPN Anforderungen Was sind VPNs? Virtuelles Privates Netzwerk Mehrere entfernte lokale Netzwerke werden wie ein zusammenhängendes

Mehr

Virtual Private Network. David Greber und Michael Wäger

Virtual Private Network. David Greber und Michael Wäger Virtual Private Network David Greber und Michael Wäger Inhaltsverzeichnis 1 Technische Grundlagen...3 1.1 Was ist ein Virtual Private Network?...3 1.2 Strukturarten...3 1.2.1 Client to Client...3 1.2.2

Mehr

Hochschule Prof. Dr. Martin Leischner Bonn-Rhein-Sieg Netzwerksysteme und TK Modul 7: SNMPv3 Netzmanagement Folie 1

Hochschule Prof. Dr. Martin Leischner Bonn-Rhein-Sieg Netzwerksysteme und TK Modul 7: SNMPv3 Netzmanagement Folie 1 Modul 7: SNMPv3 18.06.2014 14:42:33 M. Leischner Netzmanagement Folie 1 SNMP-Versionen Party-Based SNMP Version 2 (SNMPv2p) User-Based SNMP Version 2 (SNMPv2u) SNMP Version 3 1988 1989 1990 1991 1992 1993

Mehr

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

Sicherheitsaspekte unter Windows 2000

Sicherheitsaspekte unter Windows 2000 Sicherheitsaspekte unter Windows 2000 Margarete Kudak Sascha Wiebesiek 1 Inhalt 1. Sicherheit 1.1 Definition von Sicherheit 1.2 C2 - Sicherheitsnorm 1.3 Active Directory 2. Sicherheitslücken 3. Verschlüsselung

Mehr

Security in Computer Architecture Am Beispiel der AEGIS Architektur

Security in Computer Architecture Am Beispiel der AEGIS Architektur Sandro Schwarz E-mail: sschwarz@informatik.hu-berlin.de Seminar: Spezielle Probleme von Echtzeitsystemen Security in Computer Architecture Am Beispiel der AEGIS Architektur Inhaltsverzeichnis 1. Einführung

Mehr

A9: Mobile Security - So werden Sie angegriffen! Renato Ettisberger renato.ettisberger@switch.ch

A9: Mobile Security - So werden Sie angegriffen! Renato Ettisberger renato.ettisberger@switch.ch A9: Mobile Security - So werden Sie angegriffen! Renato Ettisberger renato.ettisberger@switch.ch Zürich, 11. Oktober 2011 Security (SWITCH-CERT) Derzeit 7 Mitarbeiter, bald 10 Unser Team erbringt Security-Dienstleistungen

Mehr

SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0

SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0 SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0 mit den eingetragenen Materialnummern Inhalt Inhalt... 2 1 Vorwort... 3 2 Allgemeines zur Verschlüsselung...

Mehr

Mobile Transaktionen. Christian Kantner 13.10.2011

Mobile Transaktionen. Christian Kantner 13.10.2011 Mobile Transaktionen Christian Kantner 13.10.2011 Mobile Transaktionen Mobiles elektronisches Gerät Display + Eingabemöglichkeit Internetzugang Always On SIM Karte Mobile Transaktionen Ticketing (Bahn,

Mehr

Compass Security AG [The ICT-Security Experts]

Compass Security AG [The ICT-Security Experts] Compass Security AG [The ICT-Security Experts] Live Hacking: Cloud Computing - Sonnenschein oder (Donnerwetter)? [Sophos Anatomy of an Attack 14.12.2011] Marco Di Filippo Compass Security AG Werkstrasse

Mehr

Softwaresicherheit. Sicherheitsschwachstellen im größeren Kontext. Ulrich Bayer

Softwaresicherheit. Sicherheitsschwachstellen im größeren Kontext. Ulrich Bayer Softwaresicherheit Sicherheitsschwachstellen im größeren Kontext Ulrich Bayer Conect Informunity, 30.1.2013 2 Begriffe - Softwaresicherheit Agenda 1. Einführung Softwaresicherheit 1. Begrifflichkeiten

Mehr

Überprüfung der Wirksamkeit der BSI-Konfigurationsempfehlungen für Windows 7

Überprüfung der Wirksamkeit der BSI-Konfigurationsempfehlungen für Windows 7 BSI-Veröffentlichungen zur Cyber-Sicherheit ANALYSEN Überprüfung der Wirksamkeit der BSI-Konfigurationsempfehlungen Auswirkungen der Konfiguration auf den Schutz gegen aktuelle Drive-by-Angriffe Zusammenfassung

Mehr

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden:

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden: Abkürzung für "Virtual Private Network" ein VPN ist ein Netzwerk bestehend aus virtuellen Verbindungen (z.b. Internet), über die nicht öffentliche bzw. firmeninterne Daten sicher übertragen werden. Die

Mehr