Sicheres Online Banking via Smartphone mit Nahfunk (NFC)

Eberhard Karls Universität Tübingen Fakultät für Informations und Kognitionswissenschaften Wilhelm Schickard Institut für Informatik Arbeitsbereich für Theoretische Informatik / Formale Sprachen Diplomarbeit Informatik Sicheres Online Banking via Smartphone mit Nahfunk (NFC) Max Günther 24. September 2011 Betreuer Dr. Bernd Borchert Prof. Dr. Klaus Reinhardt

Günther, Max: Sicheres Online Banking via Smartphone mit Nahfunk (NFC) Diplomarbeit Informatik Eberhard Karls Universität Tübingen Bearbeitungszeitraum: März 2011 September 2011

Selbstständigkeitserklärung Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig und nur mit erlaubten Hilfsmitteln angefertigt und nicht für weitere Prüfungszwecke verwendet habe. Tübingen, den 24. September 2011 Max Günther

Inhalt 1 Einleitung... 5 1.1 Motivation... 5 1.2 Ziel der Arbeit... 5 1.3 Verwandte Arbeiten... 6 1.4 Aufbau der Arbeit... 6 2 Grundlagen... 8 2.1 Technologische Grundlagen... 8 2.1.1 Chipkarten und Smartcards... 8 2.1.2 Entwicklung von Smartcardanwendungen... 11 2.1.3 Near Field Communication (NFC)... 12 2.1.4 NFC Smartphone... 13 2.2 Relevante Probleme und Lösungsansätze im Kontext der Online Authentifikation... 14 2.2.1 Problem 1 Online Authentifikation... 14 2.2.2 Problem 2 Transaktionsabsicherung... 15 2.2.3 Lösungsansätze... 16 2.2.4 Lösung 1 Authentifikation mit C/R und Signatur... 17 2.2.5 Lösung 2 Transaktionsabsicherung mit C/R und Signatur... 17 2.2.6 Generische Lösung... 18 2.2.7 Trusted Interface Problem... 18 2.3 Fazit Authentifikation... 20 3 ekaay... 22 3.1 Beschreibung... 22 3.2 Architektur und technische Voraussetzungen... 22 3.3 Abläufe... 23 3.4 Fazit ekaay... 27 4 Sicherheitsanalyse und Sicherheitsstrategie... 28 4.1 Vorgehen... 28 4.2 Focus der Sicherheitsanalyse... 29 4.3 Mögliche Angriffsziele und deren Konsequenzen... 29 4.4 Internetbasierte Angriffe... 30 4.5 Mobile Security... 31 4.6 Hardwarezentrierte Angriffe... 32 4.7 Softwarezentrierte Angriffe... 33 1

4.8 Sicherheitsstrategie... 34 5 Sicherheitsanalyse des ekaay Verfahrens... 35 5.1 Schlüsselvereinbarung beim ekaay Verfahren... 35 5.2 Password: Fallback to insecure... 36 5.3 Prüfung der Challenge durch den Nutzer... 36 5.4 App PIN... 36 5.5 Prüfung von ekaay anhand der Sicherheitsstrategie... 37 6 Entwurf des ekaaycard Verfahrens... 39 6.1 Motivation und Idee... 39 6.2 Vorgehen... 39 6.3 Anpassungen an Gefährdungsmodell und Sicherheitsstrategie...40 6.4 Essentielle Services: ekaaycard Interface Key Management...40 6.5 Absicherung des Schlüsselaustausches gegen Schadsoftware... 42 6.5.1 CON als Kartenaufdruck... 45 6.5.2 Fazit Cards Owner Number und Very Simple Key Agreement... 45 6.6 Mehrere Accounts: ekaaycard Interface Multi... 46 6.7 Backup und Migration: ekaaycard Interface Full... 47 6.8 Verwendung mehrerer ekaaycards durch einen Benutzer... 50 6.9 Sicherheitsanalyse des ekaaycard Verfahrens... 50 6.10 Fazit ekaaycard... 51 7 ekaaypin... 53 7.1 Beschreibung... 53 7.2 Ein wissensbasiertes Credential: Die ekaaypin... 54 7.3 Sicherheit... 54 7.4 Sicherheitsanalyse des ekaaypin(+ekaaycard) Verfahrens... 56 7.4.1 ekaaycard+ekaaypin... 56 7.4.2 ekaaypin... 56 7.4.3 Erweiterte Gefahrenlandschaft... 57 7.5 Fazit ekaaypin... 59 8 Die Verfahren der ekaay Familie... 60 8.1 Verschiedene Kombinationen und die Sicherheitsstrategie... 60 8.1.1 Schlussfolgerung nach Sicherheitsbedingungen... 61 8.1.2 Schlussfolgerung nach Verfahren... 62 8.1.3 Konsequenzen nach Verfahren... 62 2 8.1.4 Restrisiken... 62

8.1.5 Vergleich: ekaaypin/ekaaycard... 63 8.2 Vorteile durch das ekaaycard Verfahren... 63 8.3 Nachteile von ekaaycard... 65 8.4 Fazit ekaay Familie... 65 9 Technologiewahl und Implementierung... 66 9.1 Technologie... 66 9.2 Implementierung der ekaaycard... 67 9.2.1 Erweiterung der ekaaycard Schnittstelle um Ausnahmebehandlung... 67 9.3.1 Kommunikation zwischen Terminal und Karte mit ISO 7816 4 APDUs... 70 9.3.2 Konkretisierung der abstrakten Schnittstelle und Umsetzung in ISO7816 4 APDUs.. 71 9.4 Fazit Technologie und Implementierung... 74 10 Fazit... 75 10.1 Zusammenfassung... 75 10.2 Ausblick... 76 Abbildungsverzeichnis... 78 Tabellenverzeichnis... 78 Literaturverzeichnis... 79 Anhang A: ekaaycard Schnittstellendokumentation (ISO7816 4).. 83 3

4

1 Einleitung 1.1 Motivation Das Geschäftsmodell der meisten Onlineservices sieht vor, jedem Kunden individuell eine wertvolle Dienstleistung anzubieten. Dafür müssen sie sicherstellen, dass die bereitgestellten Dienste tatsächlich vom richtigen Kunden in Anspruch genommen werden und nicht von einem Betrüger in dessen Namen. Dies fordern zu Recht auch die Kunden, und zwar insbesondere dann, wenn sie einen Onlineservice nutzen, um damit private, geschäftliche, finanzielle oder aus sonstigen Gründen sensible Daten zu verwalten. Beide Seiten haben dann ein Interesse daran, vor jeder Aktion sicherzustellen, dass es sich um den richtigen Benutzer und eine von ihm gewünschte Aktion handelt. Dieser Vorgang heißt Authentifikation und ist aus den geschilderten Gründen eines der wichtigsten Probleme für die Onlinewirtschaft und darüber hinaus ein grundlegendes der IT Sicherheit insgesamt. Authentifikation wird heute meist mit dem Passwortverfahren oder mit Challenge/Response Verfahren umgesetzt. Beide Lösungen sind nicht optimal: Erstere ist weder sicher noch komfortabel, trotz und wegen der heute geforderten Passwortkomplexität. Letztere ist zwar relativ sicher, aber unkomfortabel, da zur Umsetzung der Challenge in eine Response ein Gerät (Token) benötigt wird. An der Eberhard Karls Universität Tübingen wurde ekaay (ekaay.com 2011) als Verfahren zur Onlineauthentifikation mit dem Ziel entwickelt, eine sowohl sichere als auch komfortable Lösung für diese Probleme zu bieten: Der ekaay Nutzer verwendet sein Smartphone als Token in einem Challenge/Response Verfahren. Aus Usabilitysicht ist die Eignung des Smartphones hierfür angesichts seiner Ubiquität und technischer Ausstattung relativ unstrittig. Allerdings eignet sich das Smartphone nicht per se zur sicheren Speicherung sensibler Daten. Gründe hierfür sind bekannte hardwarezentrierte und softwarezentrierte Angriffe sowie die etlichen Gelegenheiten, die sich gerade aus der gewohnten Allgegenwart ergeben, diese aber abrupt beenden: Verlust und Diebstahl. Unter diesen Umständen ist es für Banken und andere Anbieter wertvoller Accounts undenkbar (Mobey Forum 2010) ein Verfahren dieser Art einzusetzen. Es lohnt sich also einerseits zu untersuchen, welchen für Smartphones charakteristischen Gefahren das ekaay Verfahren ausgesetzt ist, und andererseits, wie diesen entgegengearbeitet werden kann. 1.2 Ziel der Arbeit Seit Anfang des Jahres 2011 ist das Smartphone Nexus S von Google auf dem Markt. Dieses Handy hat die sogenannte NFC Technik eingebaut, die das Potenzial bietet, geheime kryptographische Daten auf eine Smartcard auszulagern und damit wichtige Sicherheitsbedenken auszuräumen. Die Aufgabenstellung besteht darin, die Auslagerung der vom ekaay Verfahren verwendeten geheimen Schlüssel auf eine NFC fähige Smartcard mit sicherheitsrelevanten Argumenten zu motivieren, sie zu konzipieren, zu analysieren und schließlich zu implementieren. Hierfür wird eine eingehende Untersuchung der spezifischen Gefährdungslandschaft in der ekaay eingesetzt und eine Formalisierung der Ergebnisse zur weiteren Verwendung notwendig werden. Neben sicherheitsrelevanten Aspekten besteht außerdem die plausible Annahme aus der externen Schlüsselspeicherung weitere Vorteile wie die einfachere Integration in bestehende Smartcardinfrastrukturen ziehen zu können. 5

Das Ziel der Arbeit ist es eine prototypische, aber gebrauchsfertige Implementierung der beschriebenen Erweiterung ekaaycard zu liefern, sowie eine Evaluation desselben anhand vergleichbarer Kriterien für sicherheitsrelevante Aspekte in Gegenüberstellung und Kombination mit dem herkömmlichen ekaay Verfahren und einer zweiten, bereits existierenden Erweiterung durzuführen. 1.3 Verwandte Arbeiten Ortiz Yepes (Ortiz Yepes 2009) stellte eine Lösung zur Authentifikation mittels Mobiltelefon vor, bei der eine NFC Smartcard als Schlüsselspeicher und Signiergerät verwendet wird. Damals stand kein leistungsstarkes Smartphone zur Verfügung, weswegen die Interaktion mit dem Browser anders umgesetzt werden musste, als dies von dem hier zu erweiternden ekaay Verfahren vorgenommen wird. Eine Analyse über Möglichkeiten zur technologischen Absicherung des Mobile und Onlinebankings auf Smartphones wird vom Mobey Forum (Mobey Forum 2010) gegeben. Die dort vorgeschlagenen Lösungen basieren ebenfalls auf Smartcardtechnologie. Dort werden im Wesentlichen drei Möglichkeiten unterschieden, die alle eine fast permanente physische Verbindung von Smartphone und Smartcard beinhalten. Darin unterscheiden sich diese Ansätze von dem der vorliegenden Arbeit. Vitense (Vitense 2008) untersuchte verschiedene Onlinebanking Verfahren mit der Protokollspezifikation HLPSL formal, darunter auch das ekaay Verfahren mit einer Erweiterung. Die vorliegende Arbeit wird einen weniger formalen, dafür aber breiter aufgestellten Ansatz wählen. In einer Übersichtsarbeit analysieren Becher et al. (Becher, et al. 2011) aktuelle Befunde über smartphonespezifische Sicherheitsaspekte. Die dortigen Ergebnisse werden in dieser Arbeit wichtig. Stajano (Stajano 2011) schlägt ein autonomes Gerät (Pico) zur Authentifikation von Benutzern vor. Dieses Gerät verwendet wie ekaay eine Kamera zur Aufnahme einer Challenge. Es kommuniziert außerdem über Funk, allerdings nicht mit einer Smartcard, sondern mit dem Login PC. In einer ersten Version kann diese Lösung auf einem Smartphone implementiert werden, das langfristige Ziel ist ein tatsächlich autonomes und sicheres Gerät. In diesem wäre dieselbe Funktionalität vereint, die in dieser Arbeit durch den Einsatz von Smartphone und Smartcard erreicht werden soll. Campo et al. (Campo, et al. 2001) stellen eine Smartcardanwendung Speicherung und Verwendung kryptographischer Schlüssel vor. Sie haben dabei keine spezielle Anwendung im Sinn, sondern bieten eine allgemeine Lösung. Anders als die vorliegende Arbeit basiert sie auf asymmetrischen Verfahren. 1.4 Aufbau der Arbeit In Kapitel 2 werden wesentliche Grundlagen der in dieser Arbeit verwendeten Technologien erläutert. Außerdem wird das angesprochene Authentifikationsproblem näher erläutert, sowie im mobilen Kontext existierende und typische Lösungsvorschläge vorgestellt. In Kapitel 3 wird das ekaay Verfahren beschrieben. Kapitel 4 stellt die Vorgehensweise zur Erarbeitung von Sicherheitsbedingungen vor und wendet diese mit besonderem Fokus auf für Smartphones spezifische Sicherheitsaspekte an. In Kapitel 5 wird die Sicherheit des ekaay Verfahrens auf Einhaltung der zuvor erarbeiteten Bedingungen überprüft. Kapitel 6 liefert das Design für das Interface der Smartcardanwendung sowie Vorschläge für die Umsetzung sicherheitsrelevanter 6

Abläufe. Beides wird dabei wesentlich von den inzwischen vorliegenden Sicherheitsbedingungen beeinflusst. In Kapitel 7 wird eine zweite, bereits existierende Erweiterung des ekaay Verfahrens vorgestellt und ebenfalls auf seine Sicherheitseigenschaften überprüft. Kapitel 8 beinhaltet eine vergleichende Darstellung sicherheitsrelevanter Aspekte der zwei bereits vorhandenen Verfahren der ekaay Familie und der bis dorthin erarbeiteten Erweiterung. In Kapitel 9 wird das Interface der Smartcardanwendung konkretisiert und auf Byteebene spezifiziert. Außerdem werden Hinweise auf die Implementierung gegeben. Kapitel 10 fasst abschließend die Ergebnisse dieser Arbeit zusammen und nennt offene Probleme und Ansatzpunkte für weitere Arbeiten. 7

2 Grundlagen 2.1 Technologische Grundlagen 2.1.1 Chipkarten und Smartcards In den späten 1960er und frühen 1970er Jahren wurden Patente in Deutschland, Japan und Frankreich eingereicht, die Lösungen für Systeme zur Speicherung von Daten in einem unabhängigen, tragbaren Gegenstand (Eckert 2009, 529) vorschlugen. Diese Ideen wurden zu den heute weit verbreiteten Chipkarten weiterentwickelt. Geldkarte, SIM Karte, Studentenausweis, Reisepass und Personalausweis sind prominente Beispiele für den Einsatz dieser Technologie. Chipkarten ermöglichen es, ihrem Besitzer elektronische Daten insbesondere auch sensible Daten einfach zu transportieren und einzusetzen. Die dafür notwendige Infrastruktur wird üblicherweise vom Dienstanbieter bereitgestellt. Es handelt sich dabei meist um ein Lesegerät oder Terminal mit Online Anbindung an ein Verwaltungssystem, z.b. ein Geldkartenautomat. Charakteristisch für Chipkarten ist, dass sie ohne dauerhafte Stromversorgung Daten speichern und deswegen auf eine eigene Stromquelle verzichten können. Nur bei der Verwendung der Karte ist eine Stromversorgung durch das Terminal notwendig. Der wichtigste Standard für Chipkarten ist die ISO Norm 7816, die unter anderem Kartendimension, Größe und Position der Kartenkontakte und die zulässigen Signale und Spannungswerte sowie Übertragungsprotokolle festlegt. Klassischerweise kommuniziert eine kontaktbehaftete Chipkarte mit dem Terminal über acht Kontakte, die auch das auffälligste visuelle Merkmal derselben darstellen. Kontaktlose Karten haben lediglich ein Funk Interface zur Kommunikation mit dem Terminal 1. Verfügt eine Karte über beide Schnittstellen, spricht man von einer Dual Interface Karte. Ein wichtiger Standard für die kontaktlose Datenübertragung ist die ISO Norm 14443, die eine induktive Kopplung der Smartcard an ein vom Terminal erzeugtes Hochfrequenzfeld (13,56 MHz) zur Stromübertragung sowie Amplitudenmodulationsverfahren zur Datenübertragung in beide Richtungen festlegt. Die ISO Norm 14443 für kontaktlose Übertragung wurde kompatibel mit den entsprechenden Teilen der ISO Norm 7816 für kontaktbehaftete Übertragung gestaltet, um die Unabhängigkeit oberer Stufen der Norm vom konkreten Übertragungsmechanismus zu gewährleiste 2. Terminal und Chipkarte tauschen Kommandos im sogenannten Halbduplexverfahren aus, bei dem jeweils nur eine Seite sendet, wobei ein Mater/Slave Prinzip eingehalten wird: Das Terminal, das ein Kommando sendet, als Master und die Karte die eine Antwort sendet, als Slave. Jegliche Kommunikation wird also vom Terminal initiiert, die Karte sendet niemals selbstständig. Die heute verwendeten Chipkarten unterscheiden sich in Bezug auf Formfaktor, Speicherkapazität, Rechenkapazität, Kommunikationsanbindung, Zielmarkt und Preis teilweise erheblich voneinander. Für die vorliegende Arbeit wurde eine sogenannte Smartcard verwendet. Im Folgenden wird darum kurz der Aufbau und die Funktionsweise dieses Chipkartentyps erläutert. Gemeinsamkeiten und Unterschiede zu anderen Typen werden hier nicht herausgearbeitet, stattdessen sei auf die 1 Beide Varianten haben Vor und Nachteile: Kontaktlose Datenübertragung ermöglicht komfortablere und robustere Einsatzmöglichkeiten z.b. als Transitkarte an Skiliften oder in öffentlichen Verkehrsmitteln, da das Terminal keinen Einschub benötigt. Andererseits ist es für den Besitzer einer kontaktbehafteten Karte eindeutig, wann sie gelesen wird; insbesondere gibt es keine Möglichkeit sie auszulesen, solange sie sich in der Tasche befindet. 2 Vergleichbar den Aufgaben von LAN/WLAN vs. Webbrowser/Mailclient im OSI Schichtenmodell 8

ausführliche Darstellung und Klassifizierung verschiedener Chipkartentypen (Rankl und Effing, Handbuch der Chipkarten 2008, 17) verwiesen. 2.1.1.1 Smartcard Architektur Der zentrale Baustein einer Smartcard ist ihr Mikrocontroller. In Abbildung 1 ist eine typische Architektur einer Dual Interface Smartcard zu sehen, wie sie in dieser Arbeit eingesetzt wird. Links sind die Kontaktflächen (oben) und das kontaktlose Interface (unten) gezeichnet; beide werden zusammengeführt und verwenden die einzige Schnittstelle des Mikrocontrollers, in Ausnutzung der Kompatibilität der entsprechenden Teile der ISO Normen 14443 und 7816. Abbildung 1: Architektur einer Dual Interface Smartcard, Quelle: (Rankl und Effing 2008, 26) Die Architektur eines Smartcard Mikrocontrollers hat große Ähnlichkeit mit der eines PCs: Es gibt eine CPU, diverse Coprozessoren, verschiedene Speichertypen, Adress, Daten und Steuerbusse sowie diverse I/O Kanäle. CPU + Coprozessoren: Als CPU kommt eine RISC (Reduced Instruction Set Computer) oder CISC (Complex Instruction Set Computer) CPU mit 8, 16 oder 32 Bit zum Einsatz. Je nach Anwendungsbereich wird die Funktionalität einer Smartcard durch zusätzliche Hardware erweitert, z.b. Coprozessoren für symmetrische Verschlüsselungsalgorithmen 3 oder arithmetische Einheiten, die asymmetrische Verschlüsselung beschleunigen 4. Speicher: Ein Chipkarten Mikrocontroller benötigt sowohl nichtflüchtigen Dauerspeicher für das Betriebssystem, Anwendungen und Daten, als auch flüchtigen Arbeitsspeicher. Nichtflüchtiger 3 Dabei kann mit geringem zusätzlichen Platzbedarf viel Geschwindigkeit erkauft werden: Hardwareimplementiert ist z.b. der AES deutlich schneller, benötigt aber nur unwesentlich mehr Platz, als für seine Speicherung im ROM nötig wäre. 4 Asymmetrische Verschlüsselungsverfahren sind in der Regel nicht vollständig in Hardware implementiert. 9

Speicher ist als ROM (Read Only Memory) und EEPROM (Electrically Erasable Programmable ROM) realisiert. Da der ROM nur gelesen werden kann, eignet er sich für die Initialisierung mit Betriebssystemroutinen durch den Kartenhersteller, die hinterher nicht mehr geändert werden können. Der EEPROM ist wiederbeschreibbar und darum zur Speicherung nachinstallierter Anwendungen und Daten geeignet. Der flüchtige Arbeitsspeicher ist ein RAM (Random Access Memory). Typische Speichergrößen sind wenige duzend bis wenige hundert KByte für den ROM und den EEPROM und einige hundert Byte bis wenige KByte für den RAM. 2.1.1.2 Smartcardsicherheit (Security by Design) Anders als viele andere Systeme (PCs, Laptops, Smartphones) werden Smartcards explizit als sicheres Gerät designt. Sie weisen daher physikalische Schutzmechanismen auf, die in anderen Systemen nicht zu finden sind. Beispielsweise werden die internen Busse des Mikrocontrollers nicht nach außen geführt und sind daher nicht kontaktierbar. Angreifer können also Adress, Daten und Steuerbusse weder abhören noch beeinflussen. Zusätzlich kommen Verschleierungstechniken wie das individuelle Scrambeln der Busse zum Einsatz. Solche Maßnahmen sind allerdings nur wirksam, wenn ihre Spezifikation vertraulich bleibt. Sie gehören also in die Kategorie security through obscurity und sind darum nur als begleitenden Schutzmechanismen sinnvoll. Nach Kerkhoffs Maxime darf die Gesamtsicherheit des Systems nicht von ihnen abhängen. Andere Maßnahmen sind die Abschirmung des Chipkartenspeichers (RAM, ROM und EEPROM) gegen UV Strahlung, Sensoren zur Erkennung unzulässiger Temperaturen, Takte und Spannungswerte (Eckert 2009, 540ff). Physikalische Angriffe sind natürlich dennoch nicht ausgeschlossen.anderson (Anderson 2008, 501ff) liefert einen geschichtlichen Überblick über die Security Evolution von Smartcards, also über Angriffe und Gegenmaßnahmen, die im Laufe der Zeit entwickelt wurden. Aus diesem Überblick wird ersichtlich, dass die meisten Schutzmechanismen doch irgendwann gebrochen werden konnten. Eckert (Eckert 2009, 542) schildert einen relativ aufwändigen Angriff, bei dem der Smartcardchip zunächst chemisch aus der Karte gelöst und anschließend mit Mikroprobenadeln im laufenden Betrieb abgetastet wird. Mit solchen Angriffen ist es durchaus möglich, auf der Karte gespeicherte Geheimnisse auszulesen. Dazu ist allerdings eine extrem umfangreiche Ausrüstung notwendig. In dieser Untersuchung (Eckert 2009, 542f) sind außerdem sogenannte Seitenkanalanalysen beschrieben, die z.b. Rückschlüsse aus der vom Mikrocontroller verbrauchten Leistung ziehen: Unterschiedliche Befehle verbrauchen unterschiedlich viel Energie bzw. der gleiche Befehl verbraucht bei unterschiedlichen Eingabedaten unterschiedlich viel Energie. Bei der Kommunikation zwischen Smartcard und Terminal kann es außerdem zu Angriffen wie Sniffing und Spoofing kommen. Diese unterscheiden sich nicht prinzipiell von Angriffen dieser Art auf gewöhnlich vernetzte Umgebungen. Dort wie hier, werden zur Abwehr Mechanismen wie Verschlüsselung, MAC Berechnung, Signieren und Verifizieren sowie wechselseitige Authentifikation eingesetzt. Eine Smartcard kann also auch nicht als absolut sicheres physikalisches Gerät bezeichnet werden, was natürlich nicht überraschen darf. Es kann argumentiert werden, dass der Einsatz einer Smartcard dann sinnvoll ist, wenn dadurch das schwächste Glied eines Sicherheitssystems durch ein stärkeres ersetzt werden kann, denn dadurch wird normalerweise das Sicherheitsniveau des gesamten Systems angehoben. Dann wird eine andere Stelle als schwächste zu bezeichnen sein und sowohl für Angreifer als auch für Verteidiger ist es dann zunächst sinnvoll, sich auf diese zu 10

konzentrieren. Für letztere ist es dann vermutlich vertretbar, die aufwändigen physikalischen Angriffe auf Smartcards erst einmal in Kauf zu nehmen immerhin müssen sie normalerweise mit ca. einem Jahr Verzögerung, einem 100.000 1 Mio. Euro Budget und ungewissem Ausgang ausgeführt werden (Anderson 2008, 512). 2.1.2 Entwicklung von Smartcardanwendungen Die Grundfunktionalität einer Smartcard muss in der Regel um die speziellen Anforderungen einer konkreten Anwendung erweitert werden. Dazu kann der Anwendungsentwickler Code entwickeln und auf der Smartcard installieren. Hierfür stehen verschiedene Systeme zur Verfügung, die Erweiterungen in verschiedenen Programmiersprachen ermöglichen. Die vorliegende Arbeit verwendet den weit verbreiteten Standard JavaCard (Oracle 2010) zur Implementierung der notwendigen Funktionalität der ekaaycard in der Programmiersprache Java. Bevor anschließend die Umsetzung des erarbeiteten Interfaces für die ekaaycard erläutert wird, erfolgt zunächst ein kurzer Überblick über die JavaCard Technologie. 2.1.2.1 JavaCard Für die JavaCard Technologie musste die virtuelle Maschine zur Ausführung von Code angepasst werden. In diesem Abschnitt werden weniger charakteristische Beispiele dieser Anpassungen dargestellt. Eine ausführlichere Darstellung sowie ein historischer Überblick der Entwicklung dieser Technologie ist z.b. in Rankl und Effing (Rankl und Effing, Handbuch der Chipkarten 2008, 543) zu finden. Einschränkungen der JavaCard VM gegenüber der JVM: Wegen der begrenzten Rechenleistung und des begrenzten Speicherplatzes, kann auf Smartcards nicht der gesamte Sprachumfang von Java unterstützt werden. So kennt JavaCard z.b. kein Typ Fließkommazahlen, keine mehrdimensionale Arrays oder Nebenläufigkeit (Threads). Die Anzahl der Bytecodebefehle wurde um fast die Hälfte reduziert. Die maximal erlaubte Anzahl von Klassen/Interfaces pro package, Klassenmethoden und variablen sowie Methodenparameter wurden ebenfalls auf jeweils 256 Byte reduziert. Ebenfalls aus Ressourcengründen kommt ein Just In Time Compiler nicht in Frage, statt dessen sind insbesondere performancekritische Bibliotheksroutinen nativ implementiert. Bezüglich der Performance kommen Rankl und Effing (Rankl und Effing, Handbuch der Chipkarten 2008, 551) zu dem Schluss, dass mit JavaCard implementierte Smartcard Anwendungen nicht automatisch langsamer sind als in Assambler implementierte, da viele Routinen der JavaCard API nativ implementiert sind. Persistente und transiente Objekte: Objekte werden normalerweise persistent im EEPROM gespeichert, d.h. sie sind nach einem unerwarteten Spannungsabfall noch vorhanden. Objekte belegen auch dann noch Speicherplatz, wenn keine Referenz mehr auf sie existiert, sie also nichtcmehr verwendet werden können. Solche Objekte können mit einem explizit angestoßenen Garbage Collector Lauf gelöscht werden (der GC startet nicht selbständig, da auf den JavaCards keine nebenläufige Ausführung möglich ist). Lokale Variablen in Methoden werden transient im RAM abgelegt (auch transiente Arrays können erzeugt werden) und gehen aus diesem Grund bei Stromverlust verloren. Transaktionsintegrität: Um inkonsistente Zustände nach einem unerwarteten Spannungsverlust zu vermeiden, wird garantiert, dass Schreibzugriffe atomar sind, also ganz oder gar nicht stattfinden. Mehrere Instruktionen lassen sich zu einer Transaktion zusammenfassen, die dann ebenfalls atomar 11

ausgeführt oder automatisch zurückgerollt wird (sollte es zu einem Spannungsabfall gekommen sein), sobald wieder Spannung angelegt wird. Deployment und Ausführung: Die JavaCard VM ist in einen Offcard und einen Oncard Teil aufgetrennt. Zum Offcard Teil gehören alle Funktionen die nicht notwendigerweise zur Laufzeit eines Programmes erfolgen müssen, so gehören z.b. der Bytecode Verifyer und der Classloader zum Offcard Teil (und damit zum SDK) und werden vom Entwickler verwendet um aus allen Klassen und Interfaces eines Packages eine CAP Datei zu erzeugen. Die CAP Datei beinhaltet dann also den gesamten verifizierten Bytecode aller Kompiliereinheiten eines Packages mit aufgelösten Abhängigkeiten. Erst die CAP Datei wird dann auf die Smartcard und damit direkt zur Ausführung in den Interpreter, also den Oncard Teil der JavaCard VM geladen. Dort wird der Bytecode stückweise in native Maschinenbefehle übersetzt und ausgeführt. Parallel dazu läuft der Security Manager der sicherstellen muss, dass installierte Applets sich nicht gegenseitig beeinflussen, also insbesondere nur auf eigenen Speicher zugreifen können (es gibt aber einen Mechanismus, der expliziten Datenaustausch zwischen Applets ermöglicht). Für die Sicherheit ist darüberhinaus natürlich eine korrekte Implementierung der JavaCard VM entscheidend. Wegen des reduzierten Umfanges der JavaCard VM gegenüber einer JVM war für erstere eine formale Beschreibung der Funktionalität und eine Evaluierung nach Common Criteria möglich (Rankl und Effing, Handbuch der Chipkarten 2008, 551). JavaCard 3: Der aktuelle JavaCard Standard beinhaltet etliche Erweiterungen wie eine 32 Bit Unterstützung. Außerdem die Integration der Offcard Anteile auf die Karte und damit das direkte Laden von Class Dateien. Unter anderem läuft auf der Karte ein http Server, der das APDU Paradigma ablösen soll. Mit solchen Karten kann per http wie mit einem normalen Webserver kommuniziert werden. Allerdings ist JavaCard 3 noch nicht weit verbreitet. Hier wurde der Standard JavaCard 2.2.2 verwendet, für den obige Einschränkungen in vollem Maße zutreffen. 2.1.3 Near Field Communication (NFC) Near Field Communication ist eine Technologie zur Funkkommunikation, die von dem 2004 von NXP (ehemals Phillips), Sony und Nokia gegründeten NFC Forum (NFC Forum 2011) entwickelt und verbreitet wird. NFC basiert dabei unter anderen auf der ISO Norm 14443 zur kontaktlosen Datenübertragung, erweitert den Anwendungsbereich aber von Chipkarten auf eine Vielzahl unterschiedlicher Geräte. Eine wichtige Erweiterung gegenüber dem Master Slave Prinzip in der Chipkartenkommunikation ist die Möglichkeit für NFC Geräte, prinzipiell als Master oder Slave auftreten zu können. Damit ist auch eine Peer to Peer Kommunikation zwischen zwei NFC Geräten oder die Emulation einer Karte auf einem NFC Gerät möglich. Um der NFC Technologie zu weiterer Verbreitung zu verhelfen, definierte das NFC Forum zunächst eine Technologie Architektur und spezielle Datenformate (NDEF, NFC Data Exchange Format) und später vier verschiedene Tag Typen, die von allen NFC Geräten unterstützt werden sollen. Diese vier Tag Typen basieren auf der ISO Norm 14443 und z.b. in Asien üblichere Normen. Daraus ergibt sich eine Interoperabilität der NFC Geräte mit ISO 14443 kompatiblen Chipkarten einerseits und Terminals andererseits. Für die vorliegende Arbeit ist vor allem der sogenannte Tag Typ 4 interessant, da er vollständig kompatibel zu den in ISO 14443 definierten kontaktlosen Karten ist und somit die Basis der Kommunikation eines NFC fähigen Smartphones mit einer kontaktlosen Smartcard darstellt. 12

2.1.4 NFC Smartphone Das Smartphone Nexus S von Google (Google, Inc. 2011) ist zur Zeit das einzige NFC fähige Smartphone, das von dem in dieser Arbeit zu erweiternden ekaay Verfahren unterstützt wird. Es ist seit März 2011 auf dem deutschen Markt und verfügt über ein Android Betriebssystem (Google, Inc. 2011), welches mit Software von Drittanbietern erweitert werden kann. Auf Details dieses Betriebssystems wird hier nicht eingegangen. Obwohl die ekaay Anwendung für das Smartphone als Teil dieser Arbeit angepasst werden musst, spielt das Androidsystem für diese Arbeit eine untergeordnete Rolle: Die zu entwickelnde Erweiterung soll auch mit beliebigen anderen NFCfähigen Smartphones funktionieren und darum möglichst plattformunabhängig sein. Darüber hinaus verfügt Android nur über eine sehr rudimentäre Schnittstelle zur NFC Kommunikation, die bei den Ausführungen zur Implementierung später in dieser Arbeit angesprochen wird. Als weiterer Kandidat für ein NFC fähiges Smartphone, das von ekaay unterstützt wird, ist insbesondere das iphone von Apple (Apple, Inc. 2011) zu nennen. 13

2.2 Relevante Probleme und Lösungsansätze im Kontext der Online Authentifikation 2.2.1 Problem 1 Online Authentifikation Onlineservices müssen häufig die Identität eines Benutzers prüfen, bevor sie diesem Zugang zu einem Account gewähren. Beim Vorgang der Authentifikation 5 prüft der Server die vom Benutzer behauptete Identität anhand verschiedener Beweise. Offensichtlich genügt es nicht, dazu einfach den Benutzernamen heranzuziehen diesen könnte jeder Betrüger auch angeben. Stattdessen werden weniger leicht fälschbare Merkmale einer Person verwendet, sogenannte Credentials. Man unterscheidet drei Klassen von Credentials: wissensbasierte, besitzbasierte und eigenschaftbasierte (z.b. ein Passwort, ein Schlüssel oder ein Fingerabdruck). Ein Authentifikationsschema kann Credentials aus einer, zwei oder allen drei Klassen verwenden, wobei dann von einer 1 Faktor, 2 Faktor oder 3 Faktor Authentifikation gesprochen wird. Ein Schema wird im Allgemeinen mit steigender Faktorzahl sicherer (Eckert 2009, 441), aber auch aufwändiger für Anbieter und Benutzer, sodass zwischen Aufwand und Sicherheitsbedarf abgewogen werden muss: 1 Faktor Authentifikation wird von vielen Systemen eingesetzt (z.b. Password für Emailaccount), 2 Faktor Authentifikation von besonders zu schützenden Systemen (z.b. PIN + TAN Generator für Onlinetransaktionen) und 3 Faktor Authentifikation von paranoiden (Schneier, Secrets and Lies digital security in a networked world 2000, 136) 6. Authentifikationsschemata reduzieren die Identität eines Benutzers also auf die Übereinstimmung seiner Credentials mit gespeicherten Werten. Dadurch wird die ansonsten höchstens schriftstellerisch relevante Gefahr des Identitätsdiebstahls plötzlich konkret: Die logische Identität eines Benutzers ist durch seine Credentials definiert, die einerseits gestohlen oder übertragen werden können und andererseits nicht selten verloren gehen (dies gilt es bei der Analyse und dem Design von Verfahren in diesem Kontext zu beachten und wird auch für die vorliegende Arbeit noch eine besondere Rolle spielen). Für Onlineservices wird meist eine wissensbasierte Authentifikation mit Passwörtern implementiert, weitgehend aus pragmatischen Gründen: Ein Bildschirm für das Eingabeformular und eine Tastatur für die Passworteingabe sind an fast jedem PC vorhanden, während ein Irisscanner eher selten ist 7. Als Umsetzung der uralten Idee einer Parole, wird dieses Schema für IT Systeme aber immer unbrauchbarer: Passwörter sollen immer länger und komplizierter werden, sodass sie nicht erraten oder geknackt werden können. Sie dürfen nicht aufgeschrieben werden und sind ständig durch Social Engineering 8, Phishing 9, Shoulder Surfing 10 oder Keylogger 11 (Herley, Van Oorschot und Patrick 5 In der Literatur werden auch die beiden Begriffe Authentifikation und Authentisierung verwendet, um die Richtung des Prozesses anzugeben, den Prozess also aus der Sicht einer bestimmten Instanz zu benennen (Kampe 2010, 4). Diese Unterscheidung ist jedoch nicht immer notwendig, da die Richtung entweder keine Rolle spielt oder aus dem Kontext klar wird. Dann wird der gesamte Vorgang als Authentifikation zusammengefasst (Eckert 2009, 439) und der Begriff Authentisierung synonym verwendet (Kampe 2010, 4), diese Arbeit hält sich an diese Terminologie. Im Englischen gibt es nur den Begriff authentication für beide Richtungen (Schneier, Secrets and Lies digital security in a networked world 2000, 68ff). 6 Es erscheint unnötig, den Zugang zu einem Gebäude durch einen Irisscan und einen elektronischen Ausweis und eine PIN abzusichern: Wenn der Irisscan gut funktioniert, ist er vermutlich sicher genug. 7 Eckert stellt aber fest, dass biometrische Technologien mittlerweile auch im Massenmarkt Fuß fassen und nennt als Beispiel Fingerabdrucksensoren in Mobiltelefonen, Tastaturen und Schlüsseln (Eckert 2009, 469). 8 Nichttechnische Angriffe (Eckert 2009, 24), z.b. ein Anrufer, der sich als Kollege ausgibt und schnell mal das Passwort braucht. 14

2009) gefährdet. Sie sollen außerdem regelmäßig geändert werden und bei keinem der heute durchaus ein bis zwei Duzend Accounts darf sich das Passwort wiederholen. Stajano (Stajano 2011) kommt deswegen zu dem Schluss, dass computer security people vernünftigerweise nicht länger von Benutzern eines Systems verlangen können sich Passwörter zu merken. Diese sehen das häufig genauso und überführen daher nicht selten das Schema in ein besitzbasiertes, allerdings meist implizit: Ob Passwortzettel am Bildschirm oder Passwortcaches auf dem PC, streng genommen ist nun ein Gegenstand für den Login notwendig. Passwortcaches haben dabei den Nachteil, dass sie erstens geknackt werden können 12 und zweitens nicht mobil sind, also nicht für das Login über den Browser eines anderen PCs verwendet werden können. Passwortzettel können sogar die Sicherheit steigern, wenn etwas mehr Raffinesse aufgeboten wird, als das Passwort an den Bildschirm zu kleben: Ein Passworthinweis im Geldbeutel ist gar keine schlechte Idee, und sei es nur, weil dann ein stärkeres Passwort gewählt werden kann (Schneier, Secrets and Lies digital security in a networked world 2000, 147). Es bleibt also festzuhalten, dass Onlineservices darauf angewiesen sind, ihre Benutzer authentifizieren zu können. Meist wird dazu ein Passwort verwendet, es zeigt sich aber, dass dieses Schema das Ende seiner sinnvollen Tage erreicht hat (Stajano 2011). Die Nutzer behelfen sich mit mehr oder weniger geeigneten Maßnahmen, weswegen andere Authentifikationsschemata nötig scheinen, die einerseits mindestens so sicher, andererseits aber komfortabler als das Passwortschema sind (ebd.). 2.2.2 Problem 2 Transaktionsabsicherung Bei Onlinetransaktionen gilt es nicht nur sicherzustellen, dass Transaktionen auf bestimmten Konten nur von bestimmten Personen ausgeführt werden dazu muss der Nutzer authentifiziert werden sondern auch, dass die Transaktion auf dem Weg vom Kunden zum Bankserver nicht manipuliert wird. Mit dem Begriff Transaktionsabsicherung werden im Folgenden diese beiden Aspekte zusammengefasst. Dafür kam zunächst ein Verfahren zum Einsatz, das erstaunlich ähnlich zum impliziten Faktorwechsel durch das Passwortverfahren überforderter Nutzer ist: das TAN Verfahren 13. Eine Beschreibung sowie Sicherheits und Kostenanalysen dieses und anderer Verfahren zur Transaktionsabsicherung ist bei Vitense in seiner Arbeit Sichere Transaktionen beim Onlinebanking (Vitense 2008) zu finden. Leider konnten Phishermen, wie Anderson (Anderson 2008) sie nennt, ihre Erfahrungen mit dem Einsammeln von Passwörtern zu einfach auf dieses System übertragen der einfachste Angriff auf das PIN/TAN Verfahren ist dann auch: Phishing: Dabei locken Angreifer einen Bankkunden auf eine gefälschte Website, um seine Onlinebanking PIN und eine TAN abzugreifen und dadurch einen Blankoscheck zu erhalten: Sie können eine fast beliebige Transaktionen ausführen, das einzig unveränderliche Feld ist das des zu belastenden Kontos. Als Gegenmaßnahme wurde das itan Verfahren mit durchnummerierten TANs eingeführt. Die Bank fordert nun zufällig eine TAN mit einer bestimmten Nummer an, sodass der Angreifer schon etwas Glück haben musste, genau die richtige TAN zu kennen statt Glück 9 Z.B. eine Email mit der Aufforderung, dem Absender eine PIN oder TAN zu schicken, oder eine Email, die den Nutzer auf eine gefälschte Website lockt. Diese imitiert z.b. eine Bankwebsite, stiehlt aber Loginnamen und PIN des Nutzers (Anderson 2008, 17). 10 Achten Sie darauf, dass Ihnen bei der Passworteingabe niemand zuschaut! 11 Schadsoftware auf dem Computer des Nutzers, die die Tastenanschläge mitschreibt. 12 Z.B. mit (nsauditor 2011) 13 Der Nutzer hatte eine Liste mit Passwörtern, sogenannten Transaktionsnummern oder TANs, wovon jede Nummer genau einmal eine Transaktion freischalten konnte. 15

reichte bald Raffinesse, denn es stellte sich heraus, dass ein ganz ähnlicher Angriff auf das itan Verfahren funktioniert (RedTeam Pentesting GmbH 2009): Man in the Middle Angriff: 14 Phishing in Echtzeit; sobald ein Kunde auf die gefälschte Bankwebsite kommt und seine PIN eingegeben hat, eröffnet diese für sich eine Sitzung mit der echten Bankwebsite und der richtigen PIN, außerdem startet sie dort eine Überweisung und wird aufgefordert, die itan dafür einzugeben. Die gefälschte Website muss jetzt nur noch warten, bis der Benutzer seinerseits eine Transaktion startet und reicht ihm dann die itan Anfrage weiter (eine ausführliche Beschreibung ist bei Vitense (Vitense 2008, 17) zu finden. Bei einem MITM Angriff kann sich der Angreifer näher beim Kunden (Trojaner auf dessen Rechner) oder weiter von diesem entfernt (gefälschte Bankwebsite15) befinden (RedTeam Pentesting GmbH 2009). Ein Angriff dieser Art wird auch Middleperson Angriff (Anderson 2008, 74) genannt und taucht in großer Variationsvielfalt im Bereich der IT Sicherheit und in geringerem Umfang auch in dieser Arbeit immer wieder auf. Ein Grund hierfür ist, dass ein MITM Angriff jedes Protokoll das kein Geheimnis kennt, erfolgreich angreifen kann (Schneier 1996) 16. Die Anfälligkeit der bisher vorgestellten Ansätze zur Transaktionsabsicherung überrascht deswegen nicht weiter, lässt aber die zentrale Frage des Problems ungeklärt: Wie können Transaktionsintegrität und authentizität sichergestellt werden? 2.2.3 Lösungsansätze Challenge/Response: Bei einem Challenge/Response Verfahren (im Folgenden auch C/R Verfahren) stellt der Server dem Benutzer eine Aufgabe (Challenge) und erwartet eine bestimmte Antwort (Response). Das Passwortverfahren stellt einen Spezialfall dieses Schemas dar, erfüllt aber nicht eine Bedingung die für die Sicherheit wesentlich ist nicht: Die Challenge und damit die Response müssen sich jedesmal ändern, um es Angreifern nicht zu ermöglichen, einmal abgefangene Responses wieder einzuspielen 17 (Eckert 2009, S.461). Die TAN und itan Verfahren erfüllen zwar diese Eigenschaft, können aber leicht angegriffen werden, weil die Transaktionsdaten nicht in die Berechnung der Response eingehen. Signierung: Ein digitaler Text kann unter Verwendung eines Geheimnisses signiert werden. Dazu wird seine Signatur berechnet als,. Die Signatur ist oft deutlich kürzer als der Text selbst, da sie nicht als Ciphertext für eine verschlüsselte Kommunikation verwendet wird. Stattdessen kann mit einer Signatur die Integrität eines Textes gewährleistet werden, es kann also sichergestellt werden, dass der Text bei der Übertragung nicht unbemerkt geändert werden kann. Verfügen zwei Seiten über das gleiche Geheimnis, kann die eine Seite als Nachricht einen Text und eine Signatur schicken. Die andere Seite kann dann selbst die Signatur des Textes berechnen und mit der empfangenen vergleichen. Solche symmetrischen Signaturen heißen auch MACs (Message 14 Im Folgenden auch abgekürzt: MITM Angriff 15 Eine Möglichkeit, die aus aktuellem Anlass besonders gefährlich scheint: Kurz vor Fertigstellung dieser Arbeit häufen sich die Meldungen über die gefälschte SSL Zertifikate in Folge eines Hacks auf DigiNotar im Juli 2011: (heise Security 2011), (heise Security 2011) und (heise Security 2011). Aber auch zuvor hatte SSL natürlich schon Schwächen, (z.b.: (John E. Dunn techworld.com 2009)). Nur am Rande sei erwähnt: Nicht jeder Nutzer achtet darauf, dass da beim Onlinebanking immer ein https sein muss. 16 Zitiert via (Anderson, Bergadano, et al. 1998) 17 sogenannter Replay Angriff. 16

Authentication Code). Der Begriff digitale Signatur wird meist im Zusammenhang mit asymmetrischen Verfahren verwendet und auch in diesem Zusammenhang vorgeschlagen (Diffie und Hellman 1976). Dann besitzt nur eine Seite das Geheimnis zur Erzeugung der Signatur während die Prüfung durch eine beliebige Stelle erfolgen kann, da dazu kein Geheimnis nötig ist. Als Folge kann ein Empfänger einer Nachricht dann wirklich davon ausgehen, dass ein bestimmter Sender die Nachricht signiert hat, während dies bei MACs nur implizit durch das Protokoll gegeben ist und damit z.b. vor Gericht nicht aussagekräftig ist (Schneier, Secrets and Lies digital security in a networked world 2000, 96ff). Tatsächlich erfüllen MACs die meisten Definitionen einer digitalen Signatur nicht 18. Technisch kann allerdings auch bei asymmetrischen Signaturen nur gesagt werden, dass ein bestimmtes Geheimnis verwendet wurde, nicht aber, dass eine bestimmte Person die Signatur erzeugt hat oder dies tatsächlich wollte, weswegen Schneier feststellt: Digital signature is a terrible name for what is going on, because it is not a signature. (Schneier, Secrets and Lies digital security in a networked world 2000, 225). Organisatorisch betrachtet, ist einer der wichtigsten Unterschiede zwischen symmetrischen und asymmetrischen Signaturen, dass bei ersteren zwei statt eines Geheimnisses zu verwalten sind. Nach diesem Hinweis auf die präzise Terminologie wird aus Gründen der besseren Lesbarkeit im Folgenden nur noch der Begriff Signatur verwendet, wobei immer symmetrische MACs gemeint sind, sofern nicht anders kenntlich gemacht. 2.2.4 Lösung 1 Authentifikation mit C/R und Signatur Die Ideen des C/R Verfahrens und der Signatur lassen sich zu einem passwortloses Loginverfahren kombinieren: Der Server fordert dazu kein Passwort mehr an, sondern präsentiert dem Benutzer eine Nonce 19 als Challenge. Er erwartet als Response die Signatur der Nonce mit dem gemeinsamen Geheimnis, also,. Kann der Benutzer diese Response liefern, gilt er als authentifiziert. Hierbei sind die Nonce, das Secret und die Signatur lange Zahlen, z.b. 32 Byte Strings. Da vom Benutzer nicht erwartet werden kann, sich ein solches Geheimnis zu merken oder die Berechnung auszuführen, besitzt er dafür ein Gerät. Ein solches Loginverfahren ist also besitzbasiert. 2.2.5 Lösung 2 Transaktionsabsicherung mit C/R und Signatur Für eine Transaktionsabsicherung nimmt der Bankserver Transaktionsdaten entgegen und präsentiert dem Kunden eine Challenge. Ein aus den Transaktionsdaten abgeleiteter Text 20 oder die Transaktionsdaten selbst, was im Folgenden mit Tx bezeichnet und nicht weiter unterschieden wird. Der Server erwartet als Response,, also die Signatur der Transaktionsdaten mit dem gemeinsamen Geheimnis. Kann der Benutzer diese Response liefern, gilt er nicht nur als authentifiziert, sondern auch die Transaktion als glaubwürdig. Für eine Fälschung müsste ein Angreifer die Transaktionsdaten ändern und dazu die passende Signatur berechnen können, also das Geheimnis kennen. Wie bei der Diskussion symmetrischer und asymmetrischer Signaturen festgestellt, muss der Kunde hierbei der Bank vertrauen, da die Bank jegliche Transaktion mit dem Geheimnis des Kunden 18 Wie sie z.b. in Anderson (Anderson, Bergadano, et al. 1998) zu finden sind. 19 Number used once; eine Zufallszahl, die sich nicht (d.h. selten genug) wiederholt. 20 Um Replay Angriffe abzuwehren, wird hierbei auch ein Zeitstempel oder eine Nonce miteinbezogen. 17

ausführen könnte 21. Dieses Problem lässt sich mit einer asymmetrischen Signatur technisch lösen. Andererseits kann die Bank dem Kunden eine getätigte Transaktion nicht nachweisen. Dieses Problem lässt mit einer asymmetrischen Signatur zwar juristisch 22, aber nicht technisch lösen. 2.2.6 Generische Lösung Lösung 2 (Transaktionsabsicherung) ist ein Spezialfall von Lösung 1 (Authentifikation). Der einzige Unterschied besteht darin, dass die von Lösung 2 verwendete Challenge Transaktionsdaten codiert, während die von Lösung 1 eine Zufallszahl ist. Bei Lösung 1 wurde implizit angenommen, dass die Nonce vor der Signierung nicht geändert wird, da sonst die Prüfung durch den Server immer fehlschlagen würde eine Eigenschaft, die bei Lösung 2 explizit ausgenutzt wird. Für die Benutzerauthentifikation und Transaktionsabsicherung lassen sich also sehr ähnliche, bzw. aus Sicht des Benutzers fast identische Lösungen angeben, welche auf der Kombination eines Challenge/Reponse Schemas mit Signierung eines Textes mit einem Geheimnis basieren. Diese Kombination wird im Folgenden mit C/R/S bezeichnet, um den Unterschied zu TAN basierten C/R Schemata zu unterstreichen. 2.2.7 Trusted Interface Problem Das komfortable sichere Signieren eines digitalen Textes ist ein bisher nicht umfassend zufriedenstellend gelöstes Problem (Eckert 2009, 407). Es gibt jedoch diverse Lösungen, die für bestimmte Anwendungen einen zufriedenstellenden Tradeoff zwischen Sicherheit und Komfort wählen. Da der Nutzer den Signiervorgang nicht manuell vornimmt, sondern dafür ein Gerät verwendet, stellt sich ihm unweigerlich das Trusted Interface Problem (Anderson 2008, 514ff): Wie kann der Nutzer sicher sein, dass das Gerät den echten Text signiert? Er benötigt dafür ein Gerät, das den zu signierenden Text zunächst anzeigt und anschließend garantiert diesen Text signiert 23. Beispiele für solche Geräte sind sich heute im Umlauf befindende TAN Generatoren unterschiedlicher Onlinebanking Angebote. So berechnet z.b. der TAN Generator der BW Bank aus der Empfängerkontonummer eine TAN, mit der die Transaktion autorisiert werden muss (BW Bank 2007). Dieser TAN Generator ist ein unabhängiges Gerät, das lediglich ein Nummernpad und ein einzeiliges Display als Schnittstelle nach außen hat es kann also als im Wesentlichen als trojanersicher angesehen werden. Weiter kann angenommen werden, dass dieser TAN Generator tatsächlich den Text signiert, der eingegeben wurde und den es 21 Das Problem dabei ist nicht die Bank als Institution, dieser muss der Kunde ohnehin vertrauen. Einzelne Betrüger sind aber nicht auszuschließen, ein frühes Beispiel für einen IT Betrug durch einen Insider findet sich bei Schneier (Schneier 2000, 48). 22 Digital signature laws transfer the risk of forged signatures from the bank that relies on the signature (and that build the system) to the person alleged to have made the signature (Anderson 2001). Die hier von Anderson angesprochenen Signaturen heißen im deutschen Sprachraum qualifizierte elektronische Signaturen (QES), wie sie z.b. der neue Personalausweis (npa) ausführen kann (Oepen 2010). Eine Einschätzung juristischer Konsequenzen von QES insbesondere bei mobilem Einsatz sind z.b. in Ranke Fritsch und Rossnagel (Ranke, Fritsch und Rossnagel 2003) zu finden. 23 Die hier implizit formulierte Gefahr einer Manipulation des Textes zwischen Anzeige und Signiermodul stellt eine weitere Variante des oben erläuterten MITM Angriffs dar. Das Signiergerät zeigt dann zwar den echten Text, z.b. eine Überweisung, an, signiert aber einen ganz anderen. Ein ähnlicher Angriff ergibt sich im Authentifikationsfall: Ein Angreifer kann sich die Login Challenge eines Accounts signieren lassen, während der Benutzer eine ganz andere Signierung angefordert hat. 18

anzeigt 24. In einem solchen Fall wird auch von einem trustworthy interface gesprochen (Naumann und Hogben 2008). Es sei allerdings darauf hingewiesen, dass in der Regel kein Trustworthy Interface Problem sondern ein Trusted Interface Problem besteht und zwar dann, wenn einem nicht vertrauenswürdigen Interface vertraut wird. Die Lösung mit einemtan Generator hat aber auch Nachteile: Der Benutzer muss ein weiteres Gerät verwalten: Um es mobil einsetzen zu können, muss er es mitnehmen dabei könnte es gestohlen werden oder verloren gehen. Das Display ist relativ klein, längere Texte z.b. Sammelüberweisungen oder Auslandsüberweisungen sind darauf schlecht zu prüfen. Der Benutzer kann das Gerät i.a. nur für einen Account verwenden. Hat er mehrere Konten bei unterschiedlichen Banken, muss er mehrere unterschiedliche Geräte verwenden. Der Ablauf ist relativ aufwändig: Der Benutzer muss bei der Eingabe der Überweisung am PC, auf der nachfolgenden Bestätigungsseite und bei der Eingabe in den TAN Generator die Daten prüfen, bzw. eintippen 25. Die relativ sichere Lösung des TAN Generators hat also diverse Komfortnachteile und ist damit nur für kritische Accounts wie beim Online Banking geeignet. Bei vielen anderen Anwendungen (z.b. Benutzerauthentifikation oder weniger kritische Transaktionen wie einer Pizzabestellung ) wäre jedoch eine deutlich komfortablere Lösung wünschenswert, die allerdings immer noch so sicher wie möglich ist. Auch hier sind die beiden Ziele Sicherheit/Komfort nicht gleichzeitig optimierbar, stattdessen stellen sie eine Instanz eines im Bereich der IT Sicherheit sehr häufig vorkommenden Tradeoffs dar. 2.2.7.1 Smartcards Anders als der TAN Generator sind Smartcards (vgl. 2.1.1) sehr komfortabel: Mehrere davon passen per Design bequem in den Geldbeutel und eine Stromversorgung ist nicht notwendig. Sie können Geheimnisse sicher speichern und damit Texte signieren, haben aber i.a. kein Display, um diese Texte auch anzuzeigen. Meist werden deswegen andere Geräte als Display und Schnittstelle zu Smartcards eingesetzt, wobei der Aufbau PC/Reader/Smartcard recht häufig ist: Smartcards werden dabei über einen Reader an einen PC angeschlossen, auf dem eine Anwendung komfortabel auch große Texte anzeigen kann und zum Signieren an die Smartcard schickt. Dabei ist der Weg vom Display zum Signiermodul der critical path, auf dem Angreifer den Text manipulieren können: It s just too easy to dupe people into signing a message by having the equipment display another, innocuous, one (Anderson 2008, 672f). Eine solche Lösung ist also unter Umständen relativ komfortabel, aber auch relativ unsicher letztlich in dem Maße, in der der verwendete PC und die dort installierte Software unsicher sind. Dies wird insbesondere beim Onlinebanking im Internetcafe relevant oder wann immer ein anderer als der eigene PC verwendet wird 26. Ein 24 Unter dieser und der weiteren Annahme, dass das Gerät kryptographisch sicher ist, wird das gesamte Verfahren als sicher nach dem Stand der Technik angesehen (Frauenhofer Institut Sichere Informationstechnologie 2009). 25 Das chiptan Verfahren ermöglicht es, die Transaktionsdaten per Flackercode auf den TAN Generator zu bringen und sie anschließend nur noch zu prüfen. Das Display ist allerdings wieder zu klein, was wieder MITM Angriffe ermöglicht (RedTeam Pentesting GmbH 2009). 26 Zumindest weiß der Benutzer, dass er seinen eigenen PC nicht bewusst manipuliert hat oder welche Sicherungsmaßnahmen er ergriffen hat, aber wieso sollten Sie dem Betreiber eines Internet Cafés irgendwo auf Gottes schöner Welt vertrauen[ ]? (Klaeren 2006, 125). 19