Bildbasierte Zugriffskontrolle Für Passwortverwaltungssysteme Auf Mobilen Geräten Bachelorarbeit An Der Universität Ulm

Universitt Ulm | 89069 Ulm | Germany
Fakultt fr Ingenieurwissenschaften und Informatik Institut fr Medieninformatik
Bildbasierte Zugriffskontrolle fr Passwortverwaltungssysteme auf mobilen Gerten

Bachelorarbeit an der Universitt Ulm Vorgelegt von: Daniel Ritter daniel.ritter@uni-ulm.de Gutachter: Prof. Dr.-Ing. Michael Weber
Betreuer: Florian Schaub
2011
Fassung vom 27. Juli 2011
Diese Arbeit ist lizensiert unter der Creative Commons Namensnennung-Keine kommerzielle Nutzung-Weitergabe unter gleichen Bedingungen 3.0 Deutschland Lizenz. Nhere Informationen nden Sie unter http://creativecommons.org/licenses/by-nc-sa/3.0/de/.
A Satz: PDF-LTEX 2
Inhaltsverzeichnis
1 Einleitung 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Vergleich bildbasierter Passwortsysteme 2.1 Kategorisierung graphischer Passwrter . . . . . . . . . . . . . 2.2 Einfhrung einer Vergleichsmetrik . . . . . . . . . . . . . . . . 2.3 TAPI Touchscreen Authentication using Partitioned Images 2.4 Passfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Dj Vu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 VIP Visual Identication Protocol . . . . . . . . . . . . . . . 2.7 Passpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8 CCP Cued Click Points . . . . . . . . . . . . . . . . . . . . . . 2.9 Loci Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10 Picture Password . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11 DAS Draw A Secret . . . . . . . . . . . . . . . . . . . . . . . . 2.12 Pass-Go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.13 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 3 5 5 6 8 9 10 11 12 14 16 16 18 21 23 27 27 29 31 33 34 34 37 37 38
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
3 Konzeptvorstellung eines MIBA Schemas 3.1 Verwendung des CCP Hintergrundbildsystems . . . . . . . . . . . . . . 3.2 Verwendung der Shift-Methode . . . . . . . . . . . . . . . . . . . . . . . . 4 Implementierung des MIBA Konzepts fr Android 4.1 Umsetzung des CCP Hintergrundsystems . . . . . . . . . . . . . . . . . . 4.2 Umsetzung der Shift-Funktion . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Korrektur der Fingerstellung whrend der Eingabe . . . . . . . . . . . . 5 Untersuchung des MIBA Passwortraumes 5.1 Einfhrung der Formeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Berechnung des theoretischen Passwortraumes . . . . . . . . . . . . . . .
INHALTSVERZEICHNIS
6 Implementierung eines Passwortverwaltungssystems fr Android 6.1 Beschreibung von Picpass . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Mglichkeiten der Browserintegration . . . . . . . . . . . . . . . . . . . . 7 Diskussion und Ausblick
39 39 44 47
iv
1 Einleitung
1.1 Motivation
Das Handy wird mittlerweile nicht mehr nur zum Telefonieren verwendet. Es ist zu einem echten Multifunktionsgert geworden, das uns stndig begleitet. Von der Fahrplanauskunft, ber Navigation, Webbrowsing bis hin zur Kamerafunktion ist mit Smartphones fast alles mglich. Aufgrund der vielseitigen Verwendungsmglichkeiten erfreuen sich Smartphones steigender Beliebtheit. Bei 17% aller weltweiten Handyverkufe handelte es sich im ersten Quartal 2010 bereits um Smartphones [13]. Besonders in Nordamerika steigerte sich im ersten Quartal 2010 die Verkaufsrate von Android Smartphones um 707% [13]. Die steigende Verbreitung spiegelt sich auch im mobilen Datenverkehr wider. Der mobile Trafc hat sich 2009 gegenber dem Vorjahr auf nahezu 40 Millionen Gigabyte vervierfacht [1]. Mit einem internetfhigen Handy werden natrlich auch Webseiten abgerufen, doch gerade die Passworteingabe ist auf mobilen Gerten umstndlich und langwierig. Viele Benutzer wrden es bevorzugen, ihre Passwrter auf den Gerten zu speichern. Jedoch werden Passwrter vom Browser i.d.R. in unverschlsselter Form gespeichert. Fr Schadsoftware ist es somit theoretisch einfach mglich alle Passwrter auszulesen und an Dritte zu schicken. Bei Android muss fr den Zugriff auf die Browserpasswortdatenbank das OS gerootet werden [27]. Da bisherige Android Root-Exploits eine vorhandene PC-Verbindung voraussetzen, ist es fr Android-Schadsoftware zur Zeit nicht mglich, Root-Rechte ohne Zutun des Benutzers zu erschleichen. Bei iPhone Gerten gengte bis Firmwareversion 4.0.1 der Besuch einer prparierten Website, um Root-Rechte zu erlangen [34]. Da Smartphones als Angriffsziel wegen der steigenden Verbreitung stets lukrativer werden, ist besondere Vorsicht geboten. Die unverschlsselte Speicherung ist auch kritisch im Falle eines Verlusts oder Diebstahls. Dass ein Diebstahl nicht abwegig ist, besttigt die Londoner Kriminalittsstatistik [14]. Hier stieg die Zahl der gestohlenen Smartphones zwischen Dezember 2009 und November 2010 um 22% auf 13400 Gerte an. Das entspricht ungefhr der Hlfte aller gemeldeten Raubberflle in dieser Zeit. Ein Dieb kann ein OS in Sekunden rooten und die gespeicherten Passwrter auslesen, bevor er es weiterverkauft. Ziel dieser Bachelorarbeit ist es, die Sicherheit und den Komfort im Umgang mit Passwrtern auf mobilen Gerten zu erhhen. Dazu sollen Passwrter auf einem
1 EINLEITUNG
Smartphone in verschlsselter Form gespeichert werden. Der Schlssel fr die Verschlsselung wird durch ein graphisches Passworteingabesystem (GPS)1 erzeugt.
1.2 Problemstellung
Passwrter sind entweder unsicher und merkbar oder sicher und schwer merkbar [38]. Dies wird als Passwortproblem bezeichnet und entsteht durch zwei kontrre Anforderungen an Passwrter. Ein Passwort sollte einfach zu merken sein und die Authentizierung sollte einfach und schnell vonstatten gehen. Allerdings sollten Passwrter auch sicher sein, d.h. sie sollten schwer zu erraten sein und hug gendert werden. Fr jeden Account sollte der Benutzer ein eigenes Kennwort erstellen und es nirgendwo niederschreiben oder es in lesbarer Form speichern. Dass viele Benutzer diese Kriterien nicht beachten und eher schwache Passwrter auswhlen, zeigt eine Studie von Klein [22]. Klein konnte mit einem relativ kleinen Wrterbuch mit lediglich 62.727 Eintrgen 25% von 14.000 Unix-Passwrtern knacken. Ein Lsungsansatz fr das Passwortproblem sind graphische Passwrter, da es allgemein anerkannt ist, dass sich Menschen visuelle Informationen besser merken knnen als reinen Text [16, 26]. Wenn sich Nutzer graphische Passwrter besser merken knnen und dadurch komplexere Passwrter bilden oder der Passwortraum von graphischen Passwortsystemen sehr viel grer ist, msste ein Angreifer ein greres Wrterbuch erstellen, wodurch entweder mehr Zeit oder mehr Rechenleistung fr einen Angriff bentigt werden wrde. Komplexere Textpasswrter lassen sich auf mobilen Gerten zudem nur relativ schwer eingeben. Die Eingabezeit knnte durch graphische Passwrter ebenfalls verbessert werden. Graphische Passwrter sind eher schwer niederzuschreiben, was normalerweise als Sicherheitspluspunkt anzusehen ist. Je schwerer ein Passwort aufschreibbar ist, desto unwahrscheinlicher sind erfolgreiche Social-Engineering-Angriffe. Damit ist nicht gemeint, dass ein graphisches Passwort berhaupt nicht aufschreibbar ist und verschickt werden knnte. Jedoch macht es dieser Sicherheitspluspunkt fast unmglich dem Benutzer leicht interpretierbare systemgenerierte Passwrter zu bermitteln, falls dieser sein Passwort zurcksetzen mchte. Da man aus Erfahrung sagen kann, dass die meisten Passwrter auf Smartphones im Browser eingegeben werden und die dortige Speicherung sehr unsicher implementiert ist, wird sich das Anwendungsgebiet der App nur auf diesen Bereich konzentrieren. Durch die Verwendung eines GPS sollte sich bestenfalls die Authentizierungsdauer verkrzen. Es gibt in der Tat schon einige kommerzielle graphische Passwortsysteme wie V-GO [30] oder Passfaces (siehe Abschnitt 2.4). Doch diese sind aufgrund ihres Installationsaufwands und der Extrakosten i.d.R. nicht in der alltglichen IT-Landschaft
1 Nicht
zu verwechseln mit dem Global Positioning System
1.3 AUFBAU DER ARBEIT
anzutreffen. Dagegen gibt es bereits sehr viele Passwortsafes auf dem Markt. Allerdings gibt es bisher keine bekannte Kombination aus Beidem. Eine Symbiose aus Beidem wrde die Sicherheit erhhen und die Usability verbessern.
1.3 Aufbau der Arbeit

Im nachfolgenden Kapitel 2 werden einige bekannte Image Based Authentication Schemata (kurz IBA) miteinander anhand einer Metrik verglichen. Am Ende des zweiten Kapitels werden die Ergebnisse des Vergleichs zusammengefasst. Kapitel 3 stellt das Konzept eines Multitouch IBA Systems (kurz MIBA) vor. Das anschlieende Kapitel 4 geht nher auf die konkrete Umsetzung dieses Konzepts fr die Android Platform ein. Der Passwortraum von MIBA wird in Kapitel 5 untersucht. Als Einsatzgebiet von MIBA wird ein Passwortsafe vorgeschlagen, der in Kapitel 6 nher beschrieben wird. Das Kapitel Diskussion und Ausblick liefert eine abschlieende Zusammenfassung, fhrt die Ergebnisse der Arbeit auf und gewhrt einen Ausblick auf weiterfhrende Arbeiten.
2 Vergleich bildbasierter Passwortsysteme

Im Bereich der IBA existieren bereits einige Anstze (siehe Tabelle 2.2), die in diesem Kapitel vorgestellt und im Hinblick auf ihre Eignung fr mobile Gerte untersucht werden. Des Weiteren wird der theoretische Passwortraum der einzelnen Systeme untersucht, um deren Sicherheit einzuschtzen. Die verschiedenen Kategorien graphischer Passwortsysteme werden erlutert und die nachfolgenden Systeme dementsprechend eingeordnet. Das Kapitel schliet mit einer zusammenfassenden Bewertung der Systeme ab.
2.1 Kategorisierung graphischer Passwrter

Authentizierungsmechanismen knnen in vier Oberkategorien unterteilt werden Token, Knowledge, Location und Biometric basierte Authentizierung. Es sei angemerkt, dass sich aus diesen Oberkategorien weitere hybride Verfahren kombinieren lassen zum Beispiel ein Fingerabdruck kombiniert mit einem Passwort. Sowohl die textuellen als auch die bildbasierten Methoden gehren zur Knowledge Gruppe. Hierbei teilen das System und der Benutzer ein Geheimnis und nur derjenige, der das Geheimnis kennt, erlangt Zugriff zum System. Graphische Passwortsysteme untersttzen das Gedchtnis des Anwenders durch visuelle Informationen und knnen weiter unterteilt werden in Recall, Cued-Recall, Recognition und Association. Bei Recognition-Modellen muss der Anwender entscheiden, ob er ein Objekt schon einmal gesehen hat oder nicht. Zum Beipiel knnen sogenannte Decoy-Bilder eingesetzt werden, um dem Benutzer durch die falschen Bilder Hinweise zu geben, welches das richtige Bild sein knnte. Hingegen gibt es bei der Recall-Kategorie keinerlei Gedchtnissttzen, die dem Benutzer helfen sich zu erinnern. Das klassische Textpasswort gehrt beispielsweise zu dieser Gruppe. Zu den bildbasierten Recall-Anstzen zhlt zum Beispiel das Draw A Secret (DAS) Verfahren (siehe Abschnitt 2.11). Jakob Nielsen [29] hat gezeigt, dass Recall-Anstze gegenber Recognition-Methoden unterlegen sind, da man sich mit Hinweisen besser erinnern kann, als ohne Hilfestellungen.
2 VERGLEICH BILDBASIERTER PASSWORTSYSTEME
Cued-Recall ist eine Mischform aus Recognition und Recall. Ein Anwender muss sich das Passwort zwar merken, aber er erhlt visuelle Hinweise, die dies erleichtern. Background Draw A Secret (BDAS) nutzt solch eine Mischform. Das Hintergrundbild in BDAS gibt dem Nutzer Hinweise auf den Startpunkt und den ungefhren Verlauf der Zeichnung. Die genaue Zeichnung zu reproduzieren stellt dabei weiterhin den Recall-Anteil dar. Beim assoziativen Modell werden Zusammenhnge zwischen Objekten hergestellt. Da unser Gehirn auch auf eine assoziative Weise funktioniert, wird diesem Verfahren eine sehr hohe Merkbarkeit zugesprochen. Die Loci-Methode ist eine Gedchtnisstrategie, die sich die Assoziationsfhigkeit des Gehirns zu Nutze macht. Kot et al. [23] haben die Loci-Methode so angepasst (siehe Abschnitt 2.9), dass sie sich fr eine Authentizierung eignet. Leider gibt es zur Arbeit von Kot et al. keine Studien, welche die Usability evaluieren. Die Tabelle 2.2 gibt einen berblick ber den zeitlichen Entwicklungsverlauf der graphischen Authentizierungsmechanismen und ordnet die Systeme in die angesprochenen Kategorien ein.
2.2 Einfhrung einer Vergleichsmetrik

Als Basis fr die nachfolgend vorgestellte Metrik dient der theoretische Passwortraum eines GPS und die damit zusammenhngende Entropie eines Passwortes. Der theoretische Passwortraum ist nichts anderes, als die Anzahl aller mglichen Kombinationen ein Passwort mit bestimmter Lnge zu bilden. Der Passwortraum ist kein absolutes Ma fr die Sicherheit eines Systems, d.h. Systeme mit gleichem theoretischen Passwortraum mssen nicht zwangsweise die gleiche Sicherheit haben. In der Praxis hngt die Sicherheit nicht lediglich von der puren Gre des gesamten Passwortraums ab (genannt theoretischer Passwortraum), sondern eher von der Gre des merkbaren Passwortraums (genannt effektiver Passwortraum). Beim effektiven Passwortraum wird bercksichtigt, dass viele Benutzer leicht merkbare Passwrter whlen. Da die Menge der leicht merkbaren Passwrter nur eine Teilmenge des gesamtes Passwortraumes darstellen, ist der effektive Passwortraum ein genaueres Ma fr die Sicherheit. Der Passwortraum eines achtstelligen Textpasswortes, das aus allen druckbaren Zeichen bestehen kann, betrgt Beispielsweise 958 6, 6 1015 . Der effektive Passwortraum von Textpasswrtern ist jedoch viel kleiner, da bestimmte Kombinationen sehr viel unwahrscheinlicher von Benutzern ausgewhlt werden. Beispielsweise Zeichenfolgen, die sehr zufllig aussehen, wie o!5L*c. Zur besseren Vorstellung sei angemerkt, dass die englische Sprache aus lediglich einer Millionen (106 ) Wrtern besteht. Der effektive Passwortraum von Textpasswrtern ist also ungefhr um den Faktor 109 kleiner. Authentizierungsmechanismen sollten daher den effektiven Passwortraum mglichst maximieren. Da sich der effektive Passwortraum nur ungefhr schtzen lsst, erffnet
2.2 EINFHRUNG EINER VERGLEICHSMETRIK
der theoretische Passwortraum eine gute Mglichkeit Passwortsysteme mathematisch zu vergleichen. Wendet man den Zweierlogarithmus auf den Passwortraum an, so erhlt man die Entropie. Die Entropie ist ein Ma fr die Zuflligkeit bzw. den Informationsgehalt von Daten. Je hher die Entropie ist, desto lngere zufllige Bit-Strings knnen erzeugt werden und desto sicherer ist ein Verfahren. Um die unterschiedlichen Anstze mit einer Metrik zu vergleichen, wird errechnet, wie viele Klicks ntig wren, um die Entropie eines Referenzpasswortes zu erreichen. Dabei stellt die Klickanzahl ein Ma fr die Eingabezeit dar, was wiederum ein Ma fr den Komfort ist. Die Statistik Distribution of passwords between men and women [33] hat gezeigt, dass unter 873.000 Passwrtern die durchschnittliche Passwortlnge bei 6,94 liegt. Als Referenzpasswort dient daher ein siebenstelliges Passwort aus drei Klein- und drei Grobuchstaben inklusive einer Ziffer. Das stellt einen angemessenen Kompromiss aus Sicherheit und Komfort dar und drfte reprsentativ fr die meisten Benutzerpasswrter sein. Fr besagtes Passwort lsst sich eine Entropie von 42 Bit bestimmen (7 log2 (26 + 26 + 10) 42). Wie bereits erwhnt lsst sich anhand der Entropie eine Aussage ber Sicherheit treffen. Nun kann man fr Touch-Verfahren die bentigten Touchklicks messen, die ntig sind, um mindestens eine Entropie von 42 Bit zu erreichen. Auerdem wird bercksichtigt, dass fr das Referenzpasswort auf einem mobilen Gert meistens mehr als sieben Klicks notwendig sind, da fr Grobuchstaben und Ziffern mehr als ein Klick bentigt wird. Fr das Referenzpasswort sind auf einem Android-System beispielsweise 10 Klicks notwendig. Deswegen werden fr die nachfolgenden Vergleiche 10 Klicks als Referenzklickanzahl angenommen. Zudem werden alle Verfahren fr eine bessere Vergleichbarkeit auf eine beschrnkte Displaygre parameterisiert. Zum Beispiel wird die Zahl der sinnvoll gleichzeitig angezeigten Bilder fr jedes Verfahren individuell bercksichtigt. Dabei ist die Ausung des Displays nicht der ausschlaggebende Punkt. Wichtiger bei mobilen Touchauthentizierungsmechanismen ist die Bildschirmdiagonale. Auch wenn die Displayausung in den nchsten Jahren weiter ansteigen sollte, lieen sich dennoch nicht mehr Items gleichzeitig auf einem Bildschirm anzeigen. Der limitierende Faktor ist, dass die Items stets gro genug sein mssen, um sie mit den Fingern komfortabel und przise auswhlen zu knnen. Somit muss die Anzahl der gleichzeitig angezeigten Items immer konstant bleiben. Daher hngt die Anzahl der gleichzeitig angezeigten Items nur von der Bildschirmdiagonale ab. Als Referenzdisplay wird daher eine Bildschirmdiagonale von 4 Zoll angenommen. Da sich der Trend hochwertiger Smartphones in Richtung 4 Zoll und mehr bewegt, stellt dies eine zukunftssichere Minimalbasis fr einen Vergleich dar. Als Ausung fr ein 4 Zoll Display wird 800 480 Pixel angenommen.
2.3 TAPI Touchscreen Authentication using Partitioned Images
Abbildung 2.1: Das TAPI Eingabesystem. Der Benutzer hat bereits drei von vier Bildbereichen ausgewhlt. Quelle: [7]
TAPI Touchscreen Authentication using Partitioned Images [7] ist ein Ansatz, um die Sicherheit von klassischen PIN-Systemen zu erhhen. Hierbei wird anstelle eines Ziffernblocks ein 4 4 Gitter aus Icons benutzt und jedes Icon wird in vier Bereiche (oben, links, rechts, unten) unterteilt (siehe Abbildung 2.1). Dadurch wird die Wahr1 1 scheinlichkeit mit der ersten Ziffer richtig zu liegen von 10 auf 64 gesenkt. Das fhrt gegenber einer klassischen, vierstelligen PIN zu einer Entropiesteigerung von 81 Prozent. Das Layout von TAPI wurde fr mobile Gerte konzipiert und muss daher nicht weiter angepasst werden. Um die gleiche Entropie, wie das Referenzpasswort zu erreichen, wren bei TAPI 7 Klicks notwendig (7 log2 (64) = 42 Bit). Zwischen TAPI und dem Referenzpasswort ist die Entropie direkt proportional im Bezug auf die Passwortlnge (wegen 64 TAPI Mglichkeiten gegenber 62 Buchstaben) und es werden sogar noch weniger Klicks bentigt (Referenzklickanzahl betrgt 10). Die reduzierte Klickanzahl wird allerdings durch einen erhhten Lernaufwand und eine geringere Merkbarkeit erkauft. Der Benutzer kann zwar die Icons wiedererkennen, muss sich aber explizit merken, welchen der vier Bereiche eines Icons er auswhlen muss. Falls das gleiche Icon im Passwort mehr als einmal vorkommt, so knnten die gebildeten visuellen/assoziativen Zusammenhnge zwischen einem Bereich und einem
2.4 PASSFACES
Icon verwischt werden, was zu erhhten Fehleingaberaten fhren kann. Nach einer Woche Nichtbenutzung wird sich der Benutzer nur schwer erinnern knnen, ob er zuerst die linke und danach die rechte Ankerspitze auswhlen muss oder umgekehrt. Durch dieses explizite Merken der Bereiche (entspricht einem hohem Recall-Anteil) erhht sich die Gefahr, das Passwort nach lngerem Nichtgebrauch zu vergessen, weshalb dieses Verfahren fr unseren Ansatz nicht geeignet ist.
2.4 Passfaces
Abbildung 2.2: Beim Passfaces Schema muss der Benutzer in jeder Runde ein Gesicht wiedererkennen. Quelle: [8]
Passfaces [32] ist ein komerzielles GPS der Passfaces CorporationTM und zhlt zur Kategorie der Recognition-basierten Methoden. Auch dieses System ist eher dafr ausgelegt ein PIN-System zu ersetzen. Passfaces macht sich die Fhigkeit des menschlichen Gehirns zu Nutze, sich Gesichter besser merken zu knnen als Passwrter [3]. In der Passworterstellungsphase muss der Benutzer aus einem Bilderset eine beliebige Anzahl an Gesichtern auswhlen. Um sich zu authentizieren muss der Benutzer in jeder Runde aus 9 Gesichtern eines der zuvor ausgewhlten Gesichter erkennen (siehe Abbildung 2.2). Diese Challenge wird fr jedes der zuvor ausgewhlten Gesichter durchgefhrt. Es knnen auch mehr als acht Decoy-Bilder und mehr als ein Passface pro Runde angezeigt werden. Es hat sich jedoch herausgestellt, dass dies den Benutzer eher verwirrt und die Auswahl erschwert. Brostoff und Sasse [3] haben belegt, dass sich von 56 Testpersonen, mit einer durchschnittlichen Benutzungspause von 5,4 Monaten, 72% beim Ersten und 84% beim Dritten Versuch erfoglreich mit Passfaces anmelden konnten.
Darren Davis et al. haben Passfaces evaluiert [8] und als unsicher eingestuft. Zum Beispiel whlten mnnliche und weibliche Testpersonen meistens weibliche Gesichter aus (ber 68% der Frauen und ber 75% der Mnner). Wenn Mnner weibliche Gesichter auswhlten, whlten sie fast immer die Gutaussehensten (ungefhr 80% der weiblichen Gesichter). Auerdem prferierten die Testpersonen signikant Gesichter aus ihrer eigenen Rasse. Um Passfaces fr mobile Gerte zu adaptieren, wird angenommen, dass sich neun Gesichter auf dem Referenzdisplay benutzerfreundlich darstellen lassen. Die iPhone Applikation von Passfaces stellt ebenfalls neun Gesichter gleichzeitig dar. Passfaces hat eine relativ geringe Entropie, da die Wahrscheinlichkeit pro Runde zufllig das richtige Bild zu erraten, relativ hoch ist ( 1 ). Um die Entropie des Referenzpasswortes 9 zu erreichen wren 14 Klicks notwendig (14 log2 (9) 44 Bit). Da Benutzer es lstig nden knnten, so viele Runden durchfhren zu mssen, ist dieses System fr unseren Zweck ungeeignet.
2.5 Dj Vu
Abbildung 2.3: Bei Dj Vu werden Fraktale anstatt Gesichter eingesetzt. Quelle: [10]
Dj Vu [10] von Dhamija und Perrig verfolgt einen hnlichen Ansatz wie Passfaces, jedoch werden hier anstatt Gesichter zufllige Fraktale erzeugt. Dies soll jegliche Vorlieben von Benutzern ausschlieen, wodurch Rckschlsse auf dessen mgliche prferierte Auswahl vermieden werden. Zur Fraktalerzeugung ist einmalig ein Seed notwendig, von dem aus ein Portfolio an Bildern generiert wird. Aus diesem Portfolio muss der Benutzer fnf Authentizierungsbilder fr sich aussuchen. Um seine Identitt zu beweisen, muss der Benutzer die fnf Passbilder unter 20 zuflligen Decoybilder erkennen. Der Seed muss allerdings im Klartext auf dem Server/System gespeichert
10
2.6 VIP VISUAL IDENTIFICATION PROTOCOL
werden, um dem Benutzer seine selektierten Bilder wieder anzeigen zu knnen. Jedoch ist das Speichern von Seeds bedenklich, da damit die Passbilder von Angreifern zurckgerechnet werden knnten. Dhamija und Perrig stellten in Benutzerstudien fest, dass nach einer Woche Benutzungspause sich noch 90% der Testpersonen mit Dj Vu authentizieren konnten, wohingegen die Quote bei den Textpasswrtern bei 70% lag. Fr Dj Vu spricht hierbei, dass die Textpasswrter lediglich die Auage einer Mindestlnge von sechs Buchstaben hatten. Auerdem wurde von Dhamija und Perrig evaluiert, dass sich Fraktale schlechter merken lassen und mehr Zeit zum Wiedererkennen bentigen als normale Fotograen. Mit Hilfe von Fotograen konnten sich 95% der Probanden noch nach einer Woche erfolgreich anmelden. Der vorgeschlagene Ansatz von Dhamija und Perrig fnf aus 25 Bildern zu selektieren ist fr mobile Gerte mit kleiner Displayausung nicht geeignet. Deshalb wird die Anzahl der gleichzeitig angezeigten Fraktale angepasst. Die Anzahl an Bildern pro Runde wird auf neun festgelegt (3 3 Gitter) und die Zahl der Passbilder pro Runde wird auf zwei beschrnkt. Um die Sicherheit des Referenzpasswortes zu erreichen, wren somit 8 Runden ntig, was zu 16 Klicks und 16 Passbildern fhrt und daher zu nutzerunfreundlich ist (8 log2 (9) 41 Bit). Die Rechnung mit acht Runden ergibt 2 allerdings eine um 0, 32 Bit kleinere Entropie als die des Referenzpasswortes. Dies soll vernachlssigt werden, da bei neun Runden die Entropie bereits um 4 Bit hher ist als die Referenzentropie.
2.6 VIP Visual Identication Protocol

De Angeli et al. konzipierten und evaluierten drei VIP Systeme [9] VIP1, VIP2 und VIP3. Alle Systeme beruhen auf der Idee die Ziffern eines Tastenfeldes durch Bilder zu ersetzten. Der Benutzer muss, analog zu Ziffern bei PIN-basierten Systemen, vier richtige Bilder (nachfolgend auch Authbilder genannt) in der korrekten Reihenfolge aus zehn Bildern auswhlen. Jedes Bild stammt dabei aus einer in Gruppen (Tiere, Blumen, Gebirge, Landschaften etc.) eingeteilten Bilddatenbank. Jedes der vier Bilder, welches zum Authentizierungscode gehrt, muss dabei aus einer anderen Gruppe sein. Die Decoy-Bilder werden zufllig aus den brig gebliebenen Gruppen ausgewhlt, um mnemonische Interferenzen zu minimieren. Visual Identication Protocol (VIP) wurde in drei verschiedenen Ausprgungen (VIP1, VIP2, VIP3) evaluiert. Bei VIP1 wird der Benutzer dazu aufgefordert vier aus zehn Bildern in der richtigen Reihenfolge auszuwhlen. VIP2 unterscheiet sich von VIP1 dadurch, dass die vier Authbilder bei jedem Anmeldungsversuch an unterschiedlichen Stellen angezeigt werden. Bei VIP3 stand im Vordergrund, die Grenzen der visuellen Wiedererkennungsleistung zu untersuchen. Im VIP3 Konzept whlte der
11
Benutzer acht Bilder als Passwort. Zur Authentizierung musste der Benutzer aus den acht Authbildern vier zufllige Bilder, in beliebiger Reihenfolge, unter zwlf Decoy-Bildern erkennen. Die vier Authbilder wurden hier, wie bei VIP2, auch bei jedem Anmeldungsversuch an einer anderen Stelle angezeigt. Bei der Evaluierung von VIP2 wurden ca. 1,9% mehr Eingabefehler gemessen als bei VIP1, was bezeugt, dass das motorische Gedchtnis und das Positionsgedchtnis die Merkbarkeit geringfgig verbessern. Allerdings wurden bei PIN-Systemen lediglich 1,1% mehr Eingabefehler gemessen als bei VIP1, woraus ersichtlich ist, dass dieses IBA System nicht zu einer erhhten Merkbarkeit fhrt. Aus diesem Grund ist dieses System als Basis fr unseren Ansatz nicht geeignet. Da VIP1 in der Evaluation die besten Ergebnisse lieferte, wird dieser Ansatz mit der Metrik geprft. Fr die nachfolgende Berechnung wird vorausgesetzt, dass sich 10 Icons in angemessener Gre auf dem Referenzdisplay benutzerfreundlich darstellen lassen. Die Anzahl der Bilder wird nicht auf neun reduziert, da die Form eines PINZiffernblocks beibehalten werden soll. Die Metrik ergibt, dass 13 Runden notwendig sind, um die Entropie des Referenzpasswortes zu erreichen (13 log2 (10) 43 Bit). Da in jeder Runde ein Klick ausgefhrt wird, sind 13 Klicks notwendig.
2.7 Passpoints
Abbildung 2.4: Die Eingabeoberche einer Passpoints Implementierung. Die schwarzen Quadrate auf dem Hintergrundbild stellen die einzelnen Toleranzbereiche um einen Clickpoint dar. Die Nummerierungen neben den Quadraten kennzeichnen die Reihenfolge der jeweiligen Clickpoints. Quelle: [38]
12
2.7 PASSPOINTS
Susan Wiedenbeck et al. beschreiben in [38] ein GPS bei dem der Benutzer eine gewisse Anzahl von Positionen (Clickpoints) in der richtigen Reihenfolge in einem beliebigen Bild klicken muss, um sich zu authentizieren. Durch das frei whlbare Hintergrundbild erhlt der Benutzer zwar Anhaltspunkte, wo er klicken muss, jedoch muss sich der Benutzer die Klick-Reihenfolge explizit merken. Daher handelt es sich bei diesem Ansatz um eine Mischung aus Recognition- und Recall-GPS. Passpoints gehrt demnach zur Gruppe der Cued-Recall-Systeme. Der erste Ansatz auf einem Bild gewisse Bereiche auszuwhlen, stammt von Greg Blonder [2], welcher auch als Grnder von IBA Systemen gilt. Sein Ansatz war allerdings auf ein vordeniertes Hintergrundbild mit vordenierten Clickpoints beschrnkt. Bei Passpoints hingegen sind die Clickpoints frei whlbar. Fr diese Freiheit mssen jedoch Toleranzen erlaubt werden, weil vom Benutzer nicht abverlangt werden kann, eine Serie von Clickpoints pixelgenau zu wiederholen. Die schwarzen Quadrate in Abbildung 2.4 zeigen die Gre der Toleranzbereiche. Um solche Toleranzen zu schaffen, wird bei Passpoints ein unsichtbares Gitter ber das Hintergrundbild gelegt, welches das Bild in potentielle Clickpoints separiert (Diskretisierung). Jedoch kann dies zu erhhten Fehlerraten beim Login fhren, falls sich der Benutzer in der Passworterstellungsphase einen Punkt aussucht, der nicht mittig in einer Gitterzelle liegt. Dieses Kantenproblem kann durch das gleichzeitige Verwenden von drei berlappenden Gittern gelst werden (Robuste Diskretisierung). Anstatt der robusten Diskretisierung wurde in der Evaluationsphase von Passpoints ein naiverer Algorithmus mit gleichem Verhalten verwendet. Durch die Diskretisierung kann ein deterministischer Wert erzeugt werden, der zwingend fr den nachfolgenden Hashvorgang erforderlich ist. Die Information, welches Grid zum Abspeichern des Clickpoints benutzt wurde, kann jedoch nicht gehashed werden, was ein ausnutzbarer Schwachpunkt fr einen Angreifer sein knnte. Ein Angreifer knnte anhand dieser Information evtl. einige Kombinationen ausschlieen. Die Evaluationsstudie [38] von Susan Wiedenbeck et al. vergleicht Passpoint mit textuellen Passwrtern und es stellte sich heraus, dass die Eingabezeit bei Passpoints lnger ist und die Probanden bei lngerer Nichtbenutzung auch hnlich viele Fehler machten wie die Benutzer mit Textpasswrtern. Die meisten Anmeldungsfehlversuche entstanden durch eine falsche Reihenfolge der Clickpoints. Um die Anzahl der Klickpunkte pro angezeigtem Bild fr ein Mobilgert abzuschtzen, wird angenommen, dass der Toleranzbereich quadratisch ist und eine Seitenlnge von 0, 7cm hat. Bei einem 4 Zoll Display im 16 : 10 Format sind somit theoretisch 94 potentielle Klickpunkte mglich( 8,6cm5,4cm ). Jedoch tendieren Benutzer dazu, nur (0,7cm)2 markante Stellen auf einem Bild auszuwhlen, so dass sich Hotspots bilden und sich die potentiellen Klickpunkte reduzieren. Sptere Analysen [37, 17, 11] zeigten, dass auch Passpoints unter einem Hotspotproblem leidet. Daher werden die 94 potenti-
13
ellen Clickpoints auf 30 realistische Clickpoints herabgesetzt. Wenn das Passpoints Schema so verwendet werden wrde, wie von Susan Wiedenbeck et al. vorgeschlagen, 30! wren somit auf einem Bild nur (305)! = 17100720 Kombinationen mglich. Dies fhrt lediglich zu einer Passwortentropie von 24 Bit. Daher muss der Ansatz von Susan Wiedenbeck et al. entsprechend fr Mobilgerte angepasst werden. Es werden mehrere Runden eingefhrt, um die Entropie des Referenzpasswortes zu erreichen. Mit drei Runden mit je drei Clickpoints erreicht Passpoints eine Entropie von 43 Bit 30! (3 log2 ( (303)! ) 43). Da die Merkbarkeit von Passpoint Passwrtern nur geringfgig besser gegenber Textpasswrtern ist, eignet sich diese Methode nicht fr eine Steigerung der Usability.
2.8 CCP Cued Click Points
Abbildung 2.5: Ein CCP Passwort kann als ein auswahlabhngiger Pfad von Bildern angesehen werden. Quelle: [6]
Bei Cued Click Points [6] von Sonia Chiasson et al. besteht ein Passwort aus einer Sequenz von Bildern, wobei auf jedem Bild nur ein Clickpoint deniert wird. Das nchste angezeigte Bild hngt jeweils vom vorherigen Clickpoint ab. Fr die Zuordnung von Clickpoints zu Bildern wird eine deterministische Abbildungsfunktion verwendet. Erkennt der Benutzer das Hintergrundbild nicht wieder, so war die letzte Auswahl vermutlich falsch und er kann die Eingabe von vorne beginnen. Der Benutzer erhlt somit einen impliziten Hinweis, ob die letzte Auswahl korrekt war. Eine explizite Meldung, dass der Login fehlgeschlagen ist, erscheint erst am Ende des Authentizierungsprozesses. Benutzer knnen bei CCP nicht Ihre eigenen Hintergundbilder auswhlen, was bei Passpoints theoretisch mglich wre. Da jeder Clickpoint deterministisch das nchste Bild bestimmt, kann der Benutzer das Hintergrundbild nur durch die Auswahl
14
2.8 CCP CUED CLICK POINTS
eines anderen Clickpoints beeinussen. Das erste Bild wird beim Ansatz von Sonia Chiasson et al. durch den Benutzernamen bestimmt. Wenn man vermeiden mchte, dass zwei unterschiedliche Clickpoints zum gleichen Nachfolgebild fhren knnen, so muss das System mindestens genau so viele Bilder wie Gitterelemente aufweisen. Dadurch wird verhindert, dass ein Benutzer das richtige Nachfolgebild sieht, obwohl die Eingabe inkorrekt war. Das Bilderset kann dann in jeder Runde wiederverwendet werden. Bevor in einer nachfolgenden Runde ein bereits zuvor erschienenes Bild erneut angezeigt wird, wird deterministisch ein anderes Bild angezeigt. Um die Anzahl der Bilder pro Runde zu minimieren, kann ein Algorithmus verwendet werden, der bei unterschiedlicher Eingabe ab und zu auf das gleiche Nachfolgebild fhrt (injektive Abbildungsfunktion). In einer Evaluation [4] die CCP mit Passpoints vergleicht, sagten 70% Testpersonen aus, dass sie CCP gegenber Passpoints bevorzugen wrden. Schlielich ist die Benutzerfreundlichkeit von CCP besser, denn es ist leichter sich fnf Clickpoints auf fnf Bildern zu merken, als fnf Clickpoints in der richtigen Reihenfolge auf einem Bild. Die Evaluation ergab, dass der Median der Eingabezeit bei Passpoints 7,0 und bei CCP 6,0 Sekunden betrgt. Hier ist anzumerken, dass bei CCP der grte Teil der berlegungszeit in diesen sechs Sekunden behinhaltet ist, wohingegen die meisten Passpoints Anwender vor dem ersten Klick lange berlegen. Dies sollte bercksichtigt werden, da die Zeit erst ab dem ersten Klick gemessen wird. In der Benutzerstudie wurde auerdem herausgefunden, dass bei CCP geometrische Muster weniger huger verwendet werden als bei Passpoints und dass 92% der Klicks in einen Toleranzbereich von 9 9 Pixeln gefallen sind. Sicherheitstechnisch stellt dieses Verfahren auch ein Vorteil gegenber Passpoints dar. Um ein Hotspots-Wrterbuch zu erstellen, msste ein Angreifer erstmal alle Bilder des Zielsystems akquirieren und jedes davon analysieren. Da jedes CCP System andere Bildersets benutzen knnte, wre dies nochmals ein erhhter Aufwand. Um die Sicherheit gegen Wrterbuchangriffe weiter zu erhhen, schlagen Sonia Chiasson et al. vor, in die Abbildungsfunktion, die das nchste Bild bestimmt, zustzlich den Usernamen als Salt aufzunehmen. Die Bildung eines Wrterbuches kann weiter erschwert werden, indem man den einzelnen Benutzern nur Teilmengen eines groen Bildersets zuordnet. Beschrnkt man das CCP Schema wieder auf 30 realistische Klickpunkte (siehe Abschnitt 2.7), so wird die Entropie des Referenzpasswortes nach neun Runden erreicht (9 log2 (30) 44 Bit). Da in jeder Runde nur ein Klick ausgefhrt werden muss, sind hierfr neun Klicks erforderlich. Mit der in der Metrik denierten Referenzdisplaygre und Klickpunkten mit einer Toleranz von 0, 49cm2 ergeben sich 94 potientielle Klickpunkte pro Bild, somit wren also 94 Bilder notwendig. Wird eine injektive Abbildungsfunktion verwendet, welche 25% des Bilderportfolios wiederverwendet, wren 71 Bilder notwendig.
15
2.9 Loci Schema
Abbildung 2.6: Die Abbildung zeigt, die einzelnen Phasen einer Loci-GPS-Runde. Zuerst muss ein Ort auf einem Bild ausgewhlt werden. Danach welcher Gegenstand mit dem Ort assoziiert wird. Gefolgt von der Farbe des Gegenstandes. Quelle: [23]
Die Loci-Methode ist eine mnemotechnische Assoziationstechnik und wird von Kot et al. [23] als Grundlage fr ein IBA Schema benutzt. Bei diesem Ansatz muss der Benutzer in mehreren Runden einem Punkt auf einem beliebigen Bild einen Gegenstand inklusive Farbe zuordnen (siehe Abbildung 2.6). Theoretisch wren bei der angenommenen Referenzdisplaygre wieder bis zu 94 potentielle Klickpunkte mglich. Um jedoch die Hotspotsproblematik zu bercksichtigen, wird die Entropieberechnung nur mit 30 Klickpunkten durchgefhrt. Nimmt man an, dass 9 Farben und 9 Gegenstnde zur Auswahl stehen und dass auf einem Smartphonedisplay 30 Klickpunkte realistisch sind, erhlt man bei der Durchfhrung von vier Runden die Entropie des Referenzpasswortes (4 log2 (30 9 9) 44 Bit). Um diese Passwortstrke zu erreichen sind allerdings zwlf Klicks notwendig, da in jeder Runde eine Position, ein Gegenstand und eine Farbe ausgewhlt werden mssen.
2.10 Picture Password

Bei Picture Password [20] muss der Benutzer, wie bei Passpoints, bestimmte Bildbereiche in der korrekten Reihenfolge auswhlen, um sich zu authentizieren. Jedoch ist das System von Jansen et al. im Gegensatz zu Passpoints auf xe Bildbereiche/Thumbnails (30 Stck) eingeschrnkt. Abbildung 2.7 zeigt die Benutzeroberche von Picture Password mit xen Eingabebereichen. Um den Passwortraum zu vergrern haben Jansen et al. das Konzept einer Shift-Taste eingefhrt. Dabei kann jedes Thumbnail durch Gedrckthalten als Shift-Taste eingerastet werden und der nachfolgende Klick auf
16
2.10 PICTURE PASSWORD
Abbildung 2.7: Die Eingabeoberche eines Picture Password Systems. Picture Password verfolgt ein hnliches Konzept wie Passpoints jedoch ohne Toleranzbereiche. Um den Passwortraum dennoch ausreichend gro zu halten, haben Jansen et al. das Konzept einer Shift-Taste eingefhrt. Quelle: [20]
ein zweites Thumbnail bestimmt den Grobuchstaben. Mit diesem Schema kann die Anzahl der Auswahlmglichkeiten auf 30 + 30 30, also 930, vergrert werden. Der Wert 930 kommt folgendermaen Zustande. In jeder Runde hat man die Wahl, ob man die Shift-Funktion nutzen mchte oder nicht. Wird sie nicht verwendet hat man ganz normal 30 Thumbnails zur Auswahl. Wird sie jedoch verwendet hat man 30 30 Mglichkeiten. Also stehen in jeder Runde insgesamt 30 + 30 30 Mglichkeiten zur Verfgung. Der Wert 30 30 kommt dadurch Zustande, dass die Shift-Funktion aus zwei Phasen besteht. In der ersten Phase hat man 30 Auswahlmglichkeiten, welches Thumbnail man als Shift-Taste einrasten mchte. Ist die Shift-Taste eingerastet, hat man anschlieend in der zweiten Phase wieder 30 (sofern Selbstauswahl erlaubt ist d.h. das eingerastete Thumbnail kann selbst wieder angeklickt werden) Mglichkeiten zur Auswahl, welches Thumbnail man groschreiben mchte. Auch wenn sich dieses Konzept auf den ersten Blick vielversprechend anhrt, knnte man argumentieren, dass lediglich die Ausfhrung von zwei Runden anders verpackt wird. Wrde man zwei Runden hintereinander ausfhren, wren ebenfalls zwei Klicks notwendig und man htte 30 30 Auswahlmglichkeiten geschaffen. Der Passwortraum wrde also effektiv nur um 30 Mglichkeiten erweitert werden, was die Entropie nicht sehr viel vergrert. Anhand der Gleichung
2 log(30) = log(302 ) = log(30 30) log (30 + 30 30)
17
ist ersichtlich, dass ein Picture Password Passwort der halben Lnge mit Shift-Funktion annhernd genauso sicher ist, wie ein Passwort der doppelten Lnge ohne ShiftFunktion1 . Man knnte also meinen, dass die Ausfhrung von zwei Runden nur anders verpackt ist. Die reine Entropiebetrachtung reicht in diesem Fall allerdings nicht aus, denn mit Shift-Funktion knnen unter Umstnden fr die selbe Entropie sehr viel weniger Klicks ntig sein (wird im nchsten Absatz gezeigt). Alleine deshalb weil ein Angreifer nie wsste, ob in einer Runde gro- oder kleingeschrieben wurde, msste er aber alle 930 Mglichkeiten in Betracht ziehen, auch wenn der Anwender das Meiste kleinschreibt. Deshalb ist diese Anschauung fehlerhaft und die Shift-Funktion vergrert den Passwortraum, weil unter Umstnden weniger Klicks ntig sind. Der Ansatz von Jansen et al. wird nicht weiter fr Smartphones parametrisiert. Auf einem Smartphone lassen sich 30 Thumbnails in einem 6 5 Gitter benutzerfreundlich darstellen. Um die Entropie des Referenzpasswortes zu erreichen, wren mit ShiftFunktion fnf Runden notwendig (5 log2 (930) 49 Bit). Wie man aus der Rechnung erkennt, wird das Referenzpasswort sogar um 7 Bit berboten. Nimmt man an, das davon zwei Thumbnails mit der Shift-Methode ausgewhlt werden, so wren hierfr sieben Klicks notwendig. Genauso gut knnten aber auch nur 5 Klicks oder bis zu 10 Klicks ntig gewesen sein, um diese Entropie zu erreichen. Ohne Shift-Funktion wren denitiv zehn Runden notwendig um 49Bit zu erreichen (10 log2 (30) 49 Bit). Das bedeutet, dass ohne Shift-Funktion auch denitiv 10 Klicks ntig gewesen wren. Die Vergrerung des Passwortraumes geht allerdings zu Lasten einer erschwerteren Merkbarkeit. Zu jedem Thumbnail muss man sich explizit merken, ob man es mit oder ohne und wenn ja mit welchem Shift-Thumbnail ausgwhlt hat.
2.11 DAS Draw A Secret

Jermyn et al. fhrten das System Draw a Secret [21] ein, bei dem der Benutzer eine Zeichnung genau wiedergeben muss, um sich auszuweisen. Aufgrund der Wiedergabe aus dem Gedchtnis gehrt dieses GPS zu der Recall-Gruppe. Die Zeichnung muss hierbei stets in der gleichen Reihenfolge ausgefhrt werden. Das System verwendet ein Gitter, um die Zeichnungen zu diskretisieren (5 5 Gitter auf einem Palm Gert). Die Zeichnung wird mit Hilfe des Gitters in eine Sequenz von Koordinatenpaaren bersetzt, indem die Koordinaten der Zellen aufgezhlt werden, durch welche die Zeichnung verluft (siehe Abbildung 2.8). Die Zeichnung muss dabei nicht zwingend zusammenhngend sein. Ist die Zeichnung zu Ende oder wird sie an anderer Stelle fortgesetzt, wird dies mit einem Penup-Koordinatenpaar gekennzeichnet.
1 Bei
Textpasswrter ist dies nicht der Fall, weil der Logarithmus bei kleineren Zahlen einen greren Einuss hat((26 + 26) << 930). Hier sind doppelt so lange Passwrter aus 26 Zeichen stets im Vorteil gegenber halb so langen Passwrtern aus 52 Zeichen.
18
2.11 DAS DRAW A SECRET
Abbildung 2.8: Eingabesystem eines Draw A Secret GPS. Ein Key wird erzeugt, indem die Koordinatenpaare der Zellen, durch welche die Zeichnung verluft, aneinander gereiht werden. Das Linienende wird mit einem speziellen, sonst nicht vorkommenden, Koordinatenpaar markiert (Penup-Event). Die abgebildete Zeichnung kann zu (2,2), (3,2), (3,3), (2,3), (2,2), (2, 1), (5,5) encodiert werden. Die Zeichnung muss nicht zusammenhngend sein und sollte in jeder Zelle mglichst zentral liegen. Quelle: [21]
Zeichnungen werden anhand ihrer Lnge und der Anzahl an Penup-Events klassiziert. Je mehr Zellen von einer Zeichnung durchlaufen werden, desto sicherer ist das Passwort. Da die Lnge einer Zeichnung nicht beschrnkt ist, ist mit diesem Schema theoretisch ein unendlich groer Passwortraum mglich. Um dennoch einen Passwortraum spezizieren zu knnen, wird der Parameter Lmax eingefhrt, der den Passwortraum in eine abzhlbare und eine abzhlbar unendliche Menge aufteilt. In anderen Worten heit dies, dass alle Passwrter, die lnger als Lmax sind, von der Betrachtung ausgeschlossen werden. Mit einer maximalen Strichlnge von 12 hat ein DAS System mit einem 5 5 Grid einen greren Kennwortraum als ein achtstelliges Unix-Passwort aus 95 Zeichen (512 958 ). Tabelle 2.1 zeigt den Entropieanstieg in Abhngigkeit von Lmax . Die Entropie des Referenzpasswortes wrde bereits ab einer Strichlnge von 9 erreicht werden. Jermyn el al. zeigten, dass bereits einfach merkbare DAS Passwrter, die nur aus Recktecken bestehen (2, 56 106 ), den Passwortraum von Kleins Wrterbuch[22] abdecken. Da jedoch mit dem DAS Schema nach Jermyn et al. weitaus mehr merkbare Zeichnungen mglich sind, ist der effektive Passwortraum nher am theoretischen Passwortraum als bei Textpasswrtern. Paul Dunphy und Jeff Yan[12] verbesserten die kognitiven Eigenschaften des DAS Schemas durch ein Hintergrundbild unter dem DAS Gitter genannt Background Draw a Secret (BDAS). BDAS hilft Benutzern sich an den Startpunkt ihrer Zeichnung zu erinnern und fhrt zu lngeren und komplexeren, weniger erratbaren, Zeichnungen.
19
Lmax log2 (#passwords) Lmax log2 (#passwords)
1 5 11 53
2 10 12 58
3 14 13 63
4 19 14 67
5 24 15 72
6 29 16 77
7 33 17 82
8 38 18 87
9 43 19 91
10 48 20 96
Tabelle 2.1: Vergleich der Passwortentropie mit verschiedenen maximalen Passwortlngen auf einem 5 5 Gitter. Quelle: [21]
Aufgrund des verwendeten Hintergrundes kann BDAS als eine Mischung aus Recallund Recognition-System angesehen werden (Cued-Recall). Thorpe und Oorschot [36] untersuchten ebenfalls den merkbaren Passwortraum von DAS. Hierbei whlten sie im Gegensatz zu Jerymyn et al. keine Rechtecke aus, sondern fassten alle spiegelsymmetrischen Zeichnungen zu einer Klasse zusammen. Dabei sank die Entropie bei einem 12-stelligen Passwort auf 42,7 Bit (der volle DAS Passwortraum mit Lmax = 12 betrgt 57,7 Bit), was Wrterbuchangriffe in angemessener Zeit (6 Tage) ermglichen wrde. Um das Symmetrieproblem zu lsen, kann das symmetrische Passwort um fnf Stellen auf n + 5 verlngert werden, wodurch dies ungefhr der Entropie eines asymmetrischen Passwortes mit n Stellen entspricht. Dass das Symmetrieproblem ernst zu nehmen ist, stellten Nali et al. in einer Benutzerstudie[28] fest. 45% der Zeichnungen waren dabei symmetrisch, 80% bestanden aus lediglich drei Linien und 86% waren auf dem Grid zentriert. Goldberg et al.[15] benutzte in seiner Evaluation ein hnliches System wie DAS. Die Probanden konnten hierbei alphanumerische Passwrter nach einer Woche bis zu 11% besser wiedergeben als DAS Passwrter. Die Textpasswrter mussten mindestens sechs Zeichen lang sein, entweder Sonderzeichen oder Ziffern enthalten, nicht in einem Wrterbuch vorkommen und es durften keine bestehenden Passwrter verwendet werden. Goldberg et al. stellte fest, dass die genaue Abfolge der Zeichnung zu den meisten Fehlversuchen fhrte. Wie bei Passpoints entstehen bei DAS Systemen ebenfalls Probleme, falls eine Zeichnung Striche enthlt, die zu dicht an einer Gitterline liegen. Deshalb sind auch diagonale Linien zur Authentizierung ungeeignet. Die Zellen mssen daher gro genug fr einen ausreichenden Komfort und klein genug fr eine zufriedenstellende Sicherheit sein.
20
2.12 PASS-GO
Abbildung 2.9: Graphische Android-Tastensperre.
2.12 Pass-Go
Inspiriert vom chinesischen Brettspiel Go hat Tao ein GPS namens Pass-Go [35] gestaltet. Dieses System hnelt der Android-Tastensperre, wenn als Bildschirmsperre die Option eines Entsperrmusters eingestellt ist (siehe Abbildung 2.9). Bei Pass-Go whlt der Benutzer nicht die Zellen eines Gitters aus, sondern die Kreuzungspunkte des Gitters. Ein G G DAS Gitter entspricht dadurch einem ( G + 1) ( G + 1) Pass-Go Gitter. Nimmt man beispielsweise ein 5 5 Gitter an, so wren bei Pass-Go 36 Auswahlpunkte vorhanden und bei DAS nur 25. Die Zeichnung in Abbildung 2.10 kann als (4,8), (4,7), (4,6), (4,5), (0,0), (4,6), (5,6), (5,5), (6,6), (0,0), (7,7), (0,0), (7,6), (7,5), (0,0) encodiert werden. In Taos Evaluation [35] mit 167 Probanden wurde ermittelt, dass Pass-Go eine akzeptable Benutzerfreundlichkeit aufweist. Zum Beispiel sind bei Pass-Go auch schrge Linien mglich und der Benutzer hat nicht damit zu kmpfen, dass jeder Strich mittig in einer Zelle liegen sollte. Jeder Kreuzungspunkt wird von einem unsichtbaren, sensitiven Bereich umgeben, damit Benutzer nicht genau auf einen Kreuzungspunkt klicken mssen. Tao hat hierfr sensitive Kreise mit einem Radius von 0, 4 d gewhlt, wobei d die Seitenlnge einer Zelle ist. Fr die Umsetzung des Pass-Go Schemas auf mobile Gerte wird angenommen, dass sich ein 5 5 Grid auf dem Referenzdisplay benutzerfreundlich darstellen lsst. Abbildung 2.11 zeigt, dass sich der Kennwortraum von Pass-Go-5 gegenber DAS-5 nicht wesentlich vergrert hat (die Ziffer hinter dem Systemnamen bezieht sich auf die jeweilige Gittergre). Fr die Entropie des Referenzpasswortes wre bei einem Pass-Go-5 System mit Lmax = 12 also auch eine Zeichnung ntig, welche 9 Zellen durchluft.
21
Sensitive area
9 8 7
Shaded cell
Dot indicator Line indicator Star
6 5 4 3 2 1 1 2 3 4 5 6 7 8 9
Abbildung 2.10: Pass-Go Image Based Access Control. Indem nebeneinanderliegende, markierte Punkte durch eine Linie verbunden werden, verstrkt sich der mnemonische Effekt. Schattierte Zellen und Sterne sollen ebenfalls als Hinweise dienen. Quelle: [35]
200 180 160 140
Bit-size
120 100 80 60 40 20 0 1 2 3
Colored Pass-Go-9 Pass-Go-9 Pass-Go-5 DAS-5
10
11
12
13
14
15
16
17
18
19
20
L max
Abbildung 2.11: Vergleich der Kennwortrume zwischen DAS und Pass-Go mit unterschiedlichen Gittergren in Abhngigkeit von Lmax . Tao hat ebenfalls vorgeschlagen Farben (8 Stck) fr einzelne Linien zuzulassen, wodurch sich die Entropie weiter vergrern lsst. Quelle: [35]
22
2.13 DISKUSSION
2.13 Diskussion
In diesem Abschnitt werden die einzelnen Systeme zusammenfassend bewertet und abgewgt, welche sich als Authentizierungsmechanismen fr ein mobiles Passwortverwaltungssystem eignen. Hierbei sei angemerkt, dass es bisher keine Studien gibt, welche die Systeme gegeneinander evaluieren. Es stellt bereits eine Ausnahme dar, wenn ein bildbasiertes System mit Textpasswrtern verglichen wird. Daher ist es schwer eine fundierte Rangfolge allein auf Grundlage von Fakten zu ermitteln. Tabelle 2.2 listet die angesprochenen Systeme mit den errechneten Metrikwerten nochmals auf. Sollte bei einem System nur eine Runde ntig sein, so bedeutet dies, dass alle Eingaben auf einer unvernderten Benutzeroberche stattnden. Die Klickanzahl bezieht sich darauf, wie viele Klicks insgesamt ntig sind, um mindestens die Referenzentropie Klickanzahl von 42 Bit zu erreichen. Mit Rundenanzahl erhlt man die Klicks pro Runde. Das TAPI System hat die gleiche Entropie wie ein Textpasswort aus 62 Zeichen. Der Recall-Anteil bei diesem Verfahren wird allerdings als sehr hoch eingeschtzt. Dadurch ist das Passwort nicht leicht zu merken und fr den Rahmen der Arbeit die erste Wahl. Der effektive Passwortraum von Passfaces ist zu gering, um eine ausreichende Sicherheit zu gewhrleisten. Durch Verhaltensanalysen von Benutzerprferenzen kann der effektive Passwortraum stark minimiert werden. Aus diesem Grund scheidet dieses Verfahren aus. Dj Vu stellt ebenfalls keine Option fr unser Vorhaben dar, da hierbei zu viele Klicks notwendig wren. Die Evaluation von Dj Vu besttigt darber hinaus, dass sich Bilder besser merken lassen als Textpasswrter. Das VIP1 Schema hat keine mnemonischen Vorteile gegenber klassischen PIN-Systemen. VIP steht daher nicht in der engeren Auswahl. Cued Click Points ist im Grunde eine Weiterentwicklung von Passpoints. Bei beiden Systemen sind 9 Klicks fr die Referenzentropie notwendig. Susan Wiedenbeck et al. haben ermittelt, dass bei Passpoints Passwrtern hnlich viele Fehler gemacht wurden wie bei Textpasswrtern. Auerdem hat eine Befragung [4] in einer anderen Studie ergeben, dass die Probanden CCP gegenber Passpoints bevorzugen wrden. Dies beruht allerdings auf einer rein subjektiven Meinung. Die Testkandidaten hatten keinen Kontakt zu einem lauffhigen Passpoints System, ihnen wurde Passpoints lediglich nach der CCP Evaluation beschrieben. Dennoch legt diese Tendenz nahe, dass sich CCP besser fr unser Vorhaben eignen wrde als Passpoints. Das Konzept von Picture Password und Passpoints ist sehr hnlich. Bei beiden Verfahren muss der Benutzer in der korrekten Reihenfolge eine Sequenz von Clickpoints bzw. Thumbnails erkennen. Bei Picture Password sind dabei Wiederholungen der gleichen Thumbnails erlaubt, wohingegen bei Passpoints ein Clickpoint nur einmal im Passwort vorkommen darf. Um die Anzahl der mglichen Clickpunkte zu maximieren verfolgen die beiden Systeme jedoch unterschiedliche Anstze. Bei Picture
23
System
Jahr
Kategorie
Rundenanzahl
Gesamtklickanzahl 7 14 16 13 9 9 12 5-10
TAPI Passfaces Dj Vu VIP1 Passpoints Cued Click Points Loci-Schema Picture Password (mit Shift) Draw A Secret
2010 2000 2000 2003 2003 2007 2008 2003
Cued-Recall Recognition Recognition Recognition Cued-Recall Recognition Association Recognition
1 14 8 1 3 9 4 5
1999
Recall
Zeichnung der Lnge 9 Zeichnung der Lnge 9 Zeichnung der Lnge 9 3-6
Background Draw A Secret Pass-Go
2007
Cued-Recall
2006
Cued-Recall
MIBA
2011
Cued-Recall
Tabelle 2.2: Zusammenfassung der IBA Systeme. Die angegebenen Runden- und Klickanzahlen beziehen sich darauf, wie viele Runden bzw. Klicks notwendig sind, um die Referenzentropie von 42 Bit zu erreichen. MIBA ist ein Konzept eines Multitouch Image Based Authentication Schemas, welches im nchsten Kapitel vorgestellt wird.
24
2.13 DISKUSSION
Password werden die 30 Grundauswahlmglichkeiten durch eine Shift-Funktion auf 930 Mglichkeiten vergrert. Der Passpoints Ansatz gewhrleistet durch kleinere Toleranzbereiche eine mglichst groe Anzahl von Grundauswahlmglichkeiten. Ohne empirische Tests lsst sich jedoch nicht genau sagen, welches der beiden Verfahren im direkten Vergleich vorteilhafter ist. Das Loci Authentizierungsschema kann als eine Kombination aus CCP und VIP angesehen werden. In der ersten Loci-Phase muss der Benutzer einen Ort auf einem Bild markieren (entspricht CCP bis auf den impliziten Hinweis) und in der zweiten und dritten Phase jeweils ein Icon (entspricht VIP). Um die Referenzentropie zu erreichen sind hierbei mehr Klicks erforderlich als jeweils bei CCP, Passpoints, Picture Password, DAS oder Pass-GO. Fr dieses Verfahren spricht eine erhhte assoziative Merkbarkeit. Allerdings existieren fr dieses Schema keine Feldstudien, welche die assoziativen Vorteile belegen. BDAS ist eine Weiterentwicklung von DAS. Beide Systeme funktionieren nach dem gleichen Prinzip. Jedoch fhrt BDAS zu sichereren und besser merkbaren Passwrtern. Daher ist sicher, dass sich BDAS besser eignen wrde als DAS. Pass-Go verfolgt ebenfalls einen hnlichen Ansatz wie DAS/BDAS. Der theoretische Passwortraum der beiden Systeme ist gleichwertig und auf beiden Systemen kann der Benutzer eine Art Zeichnung anfertigen, um sich zu authentizieren. Allerdings unterscheiden sich die Arten der Zeichnungen sehr. Bei DAS/BDAS kann der Benutzer eine Freihandzeichnung anfertigen. Hingegen deniert der Benutzer seine Zeichnung bei Pass-GO durch Auswahl bestimmter Gitterpunkte. Ohne aussagekrftige Benutzerstudien kann keine Aussage getroffen werden, welche Art der Zeichnung zu besser merkbaren Passwrtern fhren wrde. Alle bisher vorgestellten IBA Systeme verwenden kein Multitouch. Im nachfolgenden Kapitel wird ein Schema vorgestellt, das einige der vorgestellten Techniken zu einem neuen bildbasierten Authentifzierungsschema kombiniert und Multitouchfhigkeiten moderner Smartphones ausnutzt.
25
3 Konzeptvorstellung eines MIBA Schemas

In diesem Kapitel wird das Konzept eines neuen IBA Schemas beschrieben, welches einige Anstze aus dem vorherigen Kapitel mit einer Multitouch-Funktionalitt kombiniert. Das vorgestellte Schema wird im Weiteren mit MIBA abgekrzt. Zu den aufgegriffenen Anstzen zhlen die Shift-Funktion aus Picture Password und das Hintergrundbildsystem von Cued Click Points. Die beiden Anstze werden nachfolgend beschrieben und im nchsten Kapitel wird genauer darauf eingegangen, wie diese Methoden fr ein Mobilgert umgesetzt wurden. Als Eingabeelemente dienen rechteckige Schaltchen, welche in einem Gitter halbtransparent ber einem Hintergrundbild angeordnet sind. Die Schaltchen sind halbtransparent, damit das Hintergrundbild nicht verdeckt wird. Wird ein Rechteck mit einem Finger berhrt, so wird es ausgeblendet und gibt den Blick auf das Hintergrundbild komplett frei. Durch die Transparenz kann der Recognition-Effekt aufrecht erhalten werden und dem Benutzer kann gleichzeitig seine Auswahl signalisiert werden. Die Abblildung 3.1 zeigt das Konzept des MIBA Eingabeschemas. Die Multitouch-Funktionalitt des Schemas besteht darin, dass dem Nutzer erlaubt wird, in jeder Runde mehrere dieser Eingabeelemente gleichzeitig auszuwhlen. Werden ein oder mehrere Rechtecke mit den Fingern berhrt, so zhlt dies zur Eingabe einer Runde hinzu. Wie das Wort gleichzeitig bereits andeutet, wird die Reihenfolge beim Drcken innerhalb einer Runde nicht bercksichtigt. Die Multitouchfhigkeit des Schemas erhht einerseits den theoretischen Passwortraum, andererseits wird erwartet, dass sich durch das gleichzeitige Drcken der Schaltchen die Eingabezeit nicht signikant verlangsamt. Durch eine Erweiterung des Passwortraums kann die Anzahl der Runden, die fr ein sicheres Passwort ntig sind, minimiert werden. Durch weniger Runden wird erhofft, dass der Loginprozess subjektiv als weniger langwierig empfunden wird.
3.1 Verwendung des CCP Hintergrundbildsystems

Um sich die jeweilige Eingabe, die mit mehreren Fingern auch komplex werden kann, merken zu knnen, ist man dringlich auf einen visuellen Hinweis angewiesen.
3 KONZEPTVORSTELLUNG EINES MIBA SCHEMAS
Abbildung 3.1: Die Eingabeoberche des MIBA Konzepts. Die Eingabeschaltchen werden gleichverteilt und halbtransparent auf einem wechselnden Hintergrundbild dargestellt. An der Unterseite bendet sich ein Back-Button, der die letzte Eingabe lscht. Die zwei roten Kreise sollen jeweils eine Displayberhrung andeuten. Wird ein Reckteck berhrt, so wird es ausgeblendet.
Hierfr wrde sich ein Hintergrundbild eignen, wie es von Passpoints eingesetzt wird. Da bei MIBA allerdings mehrere Runden ntig sind, liefert ein konstantes Hintergrundbild zu wenig Abwechslung, um Interferenzen zwischen den Runden zu vermeiden. Daher wird fr MIBA die Methode der wechselnden Hintergrundbilder von Cued Click Points adaptiert. Die Rechtecke des MIBA Eingabesystems liegen, wie bereits erwhnt, transparent auf einem Hintergrundbild. Das erste Hintergrundbild ist hierbei fest deniert und je nach Benutzereingabe, wird in der nchsten Runde ein anderes Hintergrundbild angezeigt. Fr die Auswahl der Bilder sollte beachtet werden, dass diese viele Details enthalten und ein breites Interessensgebiet abdecken sollten. Der Benutzer erhlt durch das Hintergrundbild einen impliziten Hinweis, ob die letzte Eingabe korrekt war. Erkennt der Benutzer das angezeigte Bild nicht wieder, so war seine letzte Eingabe vermutlich falsch. Die Eingabe kann bei Bedarf jederzeit mittels eines Back-Buttons an der Bildschirmunterseite rckgngig gemacht werden. Wenn man vermeiden mchte, dass bei unterschiedlichen Eingaben das gleiche Bild angezeigt wird, so muss es fr jede Kombination ein separates Bild geben. Da in jeder MIBA Runde sehr viele verschiedene Eingabekombinationen mglich sind (siehe Abschnitt 5.2), wren sehr viele Bilder ntig (siehe Abschnitt 2.10). Um die Anzahl der ntigen Hintergrundbilder zu minimieren, wird die Funktion f ( a) = a mod max Bilder verwendet. Aus dem Zustand der Eingabeoberche, also ob ein Rechteck gedrckt ist oder nicht oder lange gedrckt ist, wird eine Binrzahl a errechnet. Jede Eingabekombination fhrt somit zu einer eindeutigen Zahl a. Es wird eine Konstante max Bilder deniert, welche die Anzahl der bentigten Bilder auf
28
3.2 VERWENDUNG DER SHIFT-METHODE
die gewnschte Gre limitiert. Wird a mod max Bilder gerechnet, erhlt man den Bildindex i. Der Bildindex i verweist auf ein Bild, welches als Hintergrundbild benutzt werden kann und anschlieend als verwendet markiert wird, falls i zuvor noch nicht verwendet wurde. Wenn eine andere Eingabekombination a auf den selben Bildindex i verweisen sollte, so wird solange linear sondiert bis der nchste freie Bildindex i gefunden wird. Die beschriebene Methode stellt sicher, dass bei Passwortlngen kleiner max Bilder kein Bild zweimal erscheint. Wurden bereits alle Bilder verwendet, werden alle Bilder als frei gekennzeichnet. Wenn das letzte Bild und die Funktion f einem Angreifer bekannt ist, so sollte es fr diesen aufgrund der Modulo-Operation und des Sondiervorganges nicht mglich sein, den gesamten Pfad und damit das Passwort zurck zurechnen. Falls sich der Benutzer durch Drcken des Back-Buttons entscheidet die letzte Eingabe zu lschen und deshalb von Runde n in Runde n 1 zurckspringt, gibt es einen Sonderfall zu bercksichtigen. Whlt der Benutzer in Runde n 1 die gleiche Eingabekombination, wie beim ersten Mal als er sich in Runde n 1 befand, so sollte dies wieder zum gleichen Bild fhren. Dazu muss bei Durchfhrung einer Eigabekorrektur lediglich der zuletzt verwendete Bildindex wieder als frei gekennzeichnet werden, damit die Sondierfunktion erneut den erwarteten Bildindex errechnet.
3.2 Verwendung der Shift-Methode

Um den Passwortraum zu vergrern wird eine hnliche Shift-Methode wie bei Picture Password eingesetzt. Dass die Shift-Methode den Passwortraum effektiv vergrert, wurde im Abschnitt 2.10 bereits diskutiert. Die MIBA Shift-Methode besteht wie in Picture Password ebenfalls aus zwei Phasen. Fr die beiden Phasen gelten in MIBA folgende Regeln: In der ersten Phase knnen bei MIBA ein oder mehrere Rechtecke gleichzeitig durch Gedrckthalten ausgewhlt werden, welche dann als Shift-Taste fungieren. In der zweiten Phase ist Selbstauswahl erlaubt und es knnen wiederum ein oder mehrere Rechtecke gleichzeitig gedrckt werden, worauf die Shift-Operation abgeschlossen ist und die nchste Runde eingeleitet wird. Sowohl nach der ersten Phase als auch nach der zweiten Phase wird das Hintergrundbild gewechselt, um sicherzustellen, dass fr jede Eingabe ein anderes Hintergrundbild dargestellt wird. Die Shift-Funktion lsst sich prinzipiell auf zwei Arten aktivieren. Entweder durch Gedrckthalten der Schaltchen oder per Doppelklick auf die Schaltchen. Im nchsten Kapitel wird darauf eingegangen, warum die Doppelklickaktivierung problematisch ist und wie dem Benutzer die Aktivierung der Shift-Funktion signalisiert wird.
29
4 Implementierung des MIBA Konzepts fr Android

Das im vorherigen Kapitel vorgestellte MIBA Konzept wurde fr die Android Version 2.2 auf einem Samsung Galaxy S implementiert. Zuerst sollte das System ein 3 4 Gitter verwenden - also 12 Schaltchen. Bei ersten Tests stellte sich jedoch heraus, dass dies zu sehr komplexen Fingerstellungen fhren wrde und dadurch das Auftreten bestimmter Kombinationen bereits eher Unwahrscheinlich wre. Daher wird ein 2 4 Gitter eingesetzt. Der Passwortraum ist dennoch sehr hoch, wie in Kapitel 5 gezeigt werden wird. Die MIBA Oberche wurde mit relativen Positions- und Grenangaben implementiert, damit die Schaltchen stets den gesamten zur Verfgung stehenden Platz ausnutzen bzw. das System auch auf kleineren Displays einsetzbar ist. Die Abbildung 4.1 zeigt die Umsetzung der MIBA Oberche fr Android. Fr den Multitouch Aspekt muss bercksichtigt werden, dass die Anzahl der gleichzeitig erkennbaren Finger gerteabhngig ist. Das Galaxy S ist in der Lage bis zu fnf Pointer (Finger welche den Bildschirm berhren) gleichzeitig zu erfassen. Jedoch fhrt die Steigerung von vier auf fnf Finger zu einem geringeren Entropieanstieg als die Steigerung von drei auf vier Finger. Das kann dadurch begrndet werden, dass bei acht Rechtecken die Anzahl der Mglichkeiten pro Runde ab fnf Fingern wieder abnimmt, siehe nachfolgende Gleichung:
(8) < (8) < (8) < (8) > (8) > (8) > (8) > (8) 1 2 3 4 5 6 7 8
Auerdem ist es vom anatomischen Standpunkt sehr viel schwieriger auf einem 2 4 Gitter Eingabekombinationen mit fnf Fingern als mit vier Fingern zu bewerkstelligen. Um diese These besser zu verstehen, stelle man sich vor mit vier Fingern eine komplette Spalte zu markieren und mit dem brigen Finger der Hand noch ein Rechteck aus der anderen Spalte auswhlen zu mssen (siehe Abbildung 4.2). Daher ist das System auf vier gleichzeitig gedrckte Eingabeelemete pro Runde limitiert. Ein Smartphone sollte folglich mindestens vier Pointer gleichzeitig erfassen knnen, um den theoretischen Passwortraum der Applikation nicht zu begrenzen.
4 IMPLEMENTIERUNG DES MIBA KONZEPTS FR ANDROID
(a)
(b)
Abbildung 4.1: Die MIBA Oberche besteht aus acht halbtransparenten Rechtecken, welche in einem 2 4 Gitter ber einem Hintergrundbild angeordnet sind. Die Abbildung (a) zeigt die MIBA Oberche beim Passworterstellungsvorgang und die Abbildung (b) zeigt die Oberche beim Login-Versuch nach einem Shift-Vorgang. Beim Login-Vorgang kann auf einen LoginButton verzichtet werden, da nach jeder Eingabe berprft wird, ob das eingegebene Passwort korrekt ist. Hingegen ist in der Passworterstellungsphase ein zweiter Button erforderlich, welcher dazu dient den Abschluss des Passworts zu besttigen. An der GUI-Oberseite bendet sich ein Rundenzhler, der Aufschluss ber die momentane Eingabelnge gibt. Bei einem Shift-Vorgang vibriert das Gert und neben dem Rundenzhler wird zustzlich der Schriftzug -Shift- eingeblendet. Der Back-Button lscht die letzte Eingabe und wechselt zum Vorgngerbild.
32
4.1 UMSETZUNG DES CCP HINTERGRUNDSYSTEMS
Abbildung 4.2: Die Abbildung zeigt ein Beispiel fr eine anatomisch schwer durchfhrbare Eingabe mit fnf Fingern.
Beim verwendeten MIBA System wird auf einen Login-Button, der normalerweise zur Eingabebesttigung dient, verzichtet. Einerseits um die Eingabezeit zu verkrzen und andererseits um dem Back-Button mehr Geltung zu verschaffen. Der Login funktioniert automatisch, indem nach jeder Runde geprft wird, ob die Eingabe korrekt war. Dies hat auch den Vorteil, dass der Benutzer nach Ausfhrung der letzten Runde des Passwortes kein weiteres Bild angezeigt bekommt, auf dem er nichts auswhlen msste, sondern den Login-Button drcken msste. Der Benutzer erhlt keine explizite Meldung, ob die Authentizierung fehlgeschlagen ist und das System bietet auch nach berschreitung der erwarteten Passwortlnge immer neue Eingabemglichkeiten an. Der Benutzer erkennt eine Fehleingabe anhand einem unbekannten Hintergrundbild.
4.1 Umsetzung des CCP Hintergrundsystems

Fr die Konstante max Bilder wurde in der Implemetierung 31 gewhlt. Auch kleinere Werte wren theoretisch mglich, da ein Passwort i.d.R. nicht aus 31 Stellen besteht. Eine hhere Bilderanzahl als die durchschnittliche Passwortlnge ist jedoch sinnvoll, damit ein Benutzer bei einem Passwortwechsel mglichst andere Bilder sieht als beim vorherigen Passwort. Dies vermeidet Interferenzen zwischen den Bildern/Passwrtern. Es sollten allerdings auch nicht zu viele Bilder verwendet werden, da ansonsten die Gre der Applikation unntig anwachsen wrde und sich somit der AppMarketDownload verlngert. Die verwendeten 32 Hintergrundbilder (31 eingabeabhngige inklusive einem konstanten Starthintergrund) haben bereits eine Gre von 6,57 MB. Durch eine erhhte Kompression knnte die Zahl der Bilder noch gesteigert werden. Das Hintergrundbild muss an die vertikale Displayausung angepasst werden, denn die BitmapFactory beansprucht fr das Skalieren von groen Bildern sehr viel Zeit.
33
4 IMPLEMENTIERUNG DES MIBA KONZEPTS FR ANDROID
4.2 Umsetzung der Shift-Funktion

Die Shift-Funktion wird durch Gedrckthalten eines oder mehrerer Rechtecke aktiviert. Fr die Implementierung der vorgeschlagenen Shift-Methode aus Kapitel 3, muss auerdem beachtet werden, dass keine Aktion ausgelst wird, durch ein weiteres Gedrckthalten in der zweiten Shift-Phase. Da das Gedrckthalten einiges an Eingabezeit kostet, war die ursprngliche Idee, die Shift-Funktion durch einen Doppelklick auf ein oder mehrere Rechtecke zu aktivieren. Da es in Android keinen OnDoubleClickListener fr die verwendete View gibt, musste zunchst eine Doppelklickerkennung mittels eines OnClickListeners, r Threads und r Boolean Werten bewerkstelligt werden. Bei Tests stellte sich allerdings heraus, dass ein Doppelklick mit mehreren Fingern zu hugen Fehleingaben fhrt. Eine huge Ursache davon war, dass die Finger beim zweiten Klick des Doppelklicks nicht auf dem gleichen Rechteck platziert wurden. Eine andere Ursache war, dass mit mehreren Fingern der letzte Doppelklick zeitlich soweit von den ersten Doppelklicks entfernt war, dass dieser bereits als Eingabe fr die nchste Runde gewertet wurde. Auerdem htte sich durch den Doppelklickansatz auch die Programmreaktionszeit fr normale Eingaben verlngert, da immer ein kleines Zeitfenster gewartet werden msste, um einen Doppelklick zu erkennen. Die Aktivierung der Shift-Funktion, wird dem Benutzer durch die Einblendung des Schriftzuges -Shift- neben dem Rundenzhler (siehe Abbildung 4.1 (b)) und einer gleichzeitigen Vibration signalisiert. Der Rundenzhler bendet sich an der Displayoberseite und zeigt an, in welcher Runde sich der Benutzer momentan bendet und gibt somit Aufschluss ber die Passwortlnge. Der Rundenzhler wird durch die erste Phase einer Shift-Eingabe nicht erhht. Das Hintergrundbild wechselt jedoch in der ersten Phase, um fr die zweite Phase ebenfalls einen Recognition-Effekt zu gewhrleisten. Nach der zweiten Phase schliet die Shift-Eingabe ab, das Hintergrundbild wird gewechselt und der Rundenzhler wird erhht. Ein weiteres Kennzeichen, dass die Eingabe als Shift erkannt wurde, ist der Wechsel des Hintergrundbildes, obwohl noch alle Finger auf dem Display sind. Das ist ein Gegensatz zur normalen Eingabe. Bei einer normalen Eingabe wechselt das Hintergrundbild erst, sobald alle Finger das Display verlassen haben. Warum eine normale Eingabe erst nach Abheben der Finger beendet ist, wird im nchsten Abschnitt erlutert.
4.3 Korrektur der Fingerstellung whrend der Eingabe

Mit einem Finger sollte jeder Nutzer in der Lage sein przise Klicks auszufhren. Da es mit mehreren Fingern sehr schwierig ist bei der ersten Displayberhrung alle Finger auf den korrekten Eingaberechtecken zu platzieren, musste ein Konzept erarbeitet werden, das es gestattet, die Fingerstellung whrend einer Eingabe zu korrigieren.
34
4.3 KORREKTUR DER FINGERSTELLUNG WHREND DER EINGABE
Um dem Benutzer solch eine Korrektur zu erlauben, wird die Eingabe erst akzeptiert und die nchste Runde gestartet, sobald alle Finger das Display verlassen haben. Das hat den Vorteil, dass dem Benutzer Korrekturen erlaubt sind, sobald mehr als ein Finger in einer Runde verwendet wird. Besteht das Passwort in einer Runde zum Beispiel aus zwei Eingabeelementen, so kann der Benutzer seine Finger nacheinander (muss also nicht genau gleichzeitig sein) auf den Rechtecken platzieren. Sollte er dabei versehentlich ein falsches Rechteck berhren, so kann er den jeweiligen Finger ganz einfach auf das korrekte Rechteck verschieben, bevor er dann mit beiden Fingern das Display verlsst und die Eingabe akzeptiert wird. In anderen Worten heit dies, das als Eingabe nur die zuletzt ausgeblendeten Rechtecke zhlen. Ein weiterer Vorteil bei diesem Ansatz ist, dass dem Benutzer kein festes Zeitfenster eingerumt wird, indem er eine Korrekutr durchfhren knnte, bevor die nchste Runde nach Ablauf des Zeitfensters automatisch gestartet werden wrde. Besteht das Passwort in einer Runde lediglich aus einem Rechteck, gengt ein kurzes Antippen des Rechtecks, um sofort die nchste Runde zu starten. Dies kommt der Eingabezeit zugute, weil ansonsten gewartet werden msste, bis ein gewisses Zeitfenster abgelaufen ist. Um die Shift-Funktion gegen die gleiche Art von Fehleingaben abzusichern, wird ein Thread gestartet, der kontrolliert, ob der Zustand der Eingabeoberche fr eine Sekunde konstant war. Somit ist es mglich mehrere Finger unkontrolliert auf dem Display abzusetzen. Anschlieend knnen die Finger ber beliebige Rechtecke gleiten, um sich in einer Endhaltung zu positionieren. In der Endhaltung kann sich der Benutzer entscheiden, ob er die Fingerstellung lange gedrckt hlt und einen Shift auslst oder seine Finger abhebt und somit die nchste Runde startet. Wird die Zeitspanne lnger gewhlt, ist das System robuster gegen Fehleingaben, da der Benutzer seine Finger lnger auf den gleichen Stellen belassen kann, ohne einen Shift auszulsen. Eine Zeitspanne von einer Sekunde stellte in Einzeltests einen guten Kompromiss zwischen Eingabezeit und Robustheit dar.
35
5 Untersuchung des MIBA Passwortraumes

In diesem Kapitel wird der theoretische Passwortraum von MIBA Systemen erschlossen. Der Abschnitt 5.1 fhrt zunchst allgemeine Formeln zur Berechnung von MIBA Passwortrumen ein. Die Formeln belegen, dass die Multitouch-Funktionalitt den Passwortraum noch weiter vergrert. In Abschnitt 5.2 werden diese allgemeinen Formeln auf die konkrete MIBA Implementation aus dem vorherigen Kapitel angewendet.
5.1 Einfhrung der Formeln

Sei r die Anzahl der Rechtecke auf der Eingabeoberche, so wren ohne Multitouch genau r Kombinationen in einer Runde mglich (hnlich wie beispielsweise bei VIP). Bei MIBA werden aber zu r noch die Kombinationen addiert, welche mit zwei bis n Fingern mglich sind. Da die Reihenfolge innerhalb einer Runde nicht bercksichtigt r wird, ergeben sich beispielsweise mit zwei Fingern (2) Kombinationen. Die Anzahl aller mglichen Eingabekombinationen einer Runde ohne Shift-Funktionalitt ergibt sich folglich zu:
g(n, r ) = (r) i
i =1
(5.1)
Wird das Schema mit Shift-Funktion umgesetzt, kann der theoretische Passwortraum mit der Funktion f wie folgt bestimmt werden:
f (n, r ) = g(n, r ) + ( g(n, r ))2 (5.2)
5 UNTERSUCHUNG DES MIBA PASSWORTRAUMES
Im nchsten Abschnitt wird die Entropie eines fr Mobilgerte umgesetzten MIBA Systems konkret berechnet.
5.2 Berechnung des theoretischen Passwortraumes

Bei der vorgestellten Android Implementation aus Kapitel 4 ist r = 8 (Anzahl der Rechtecke) und n = 4 (maximale Fingeranzahl). Mit der Formel 5.1 ergeben sich 162 Mglichkeiten pro Runde ohne Shift. Mit Shift sind nach Formel 5.2 in jeder Runde
162 + 1622 = 26406
Kombinationen mglich. Um die Entropie des Referenzpasswortes zu erreichen, sind mit Shift-Funktionalitt drei Runden erforderlich (3 log2 (26406) 44 Bit). Man beachte hierbei, dass mit Shift-Funktion jede Runde aus bis zu zwei Klicks bestehen kann. Fr die Referenzentropie sind demnach 3-6 Klicks erforderlich. Um das Masterpasswort von Picpass (wird in Kapitel 6 vorgestellt) noch sicherer zu machen, wurde die minimale Passwortlnge auf 4 Runden gesetzt. Dies ergibt eine Entropie von 58 Bit und entspricht ungefhr einem neunstelligen Textpasswort aus 95 Zeichen.
38
6 Implementierung eines Passwortverwaltungssystems fr Android

Ein mgliches Einsatzgebiet von MIBA Systemen auf mobilen Gerten sind Passwortverwaltungssysteme. Weil man zur Anmeldung auf Webseiten stets einen Benutzernamen und ein Passwort bentigt und mit graphischen Passwortsystemen nur die Passworteingabe sinnvoll umsetzbar ist, wird das MIBA System mit einem Passwortsafe vereint. Dies erffnet dem Benutzer mehrere Vorteile. Der Nutzer muss sich nur an ein graphisches Passwort erinnern, was bestenfalls einfach zu merken ist. Der Benutzer muss keinerlei seiner bestehenden Textpasswrter ndern und kann sich dadurch auch ohne die App mit seinen bestehenden Passwrtern auf Webseiten anmelden. Den Ansatz jedes Textpasswort durch ein eigenes graphisches Passwort zu ersetzen, wurde aus Bedenken, dass zu viele graphische Passwrter zu erhhten Interferenzen [5] fhren wrden, wieder verworfen. Daher war die Entscheidung naheliegend eine 1 zu N Abbildung zwischen einem graphischen MIBA-Passwort und N Textpasswrtern mit Hilfe eines Passwortsafes zu realisieren.
6.1 Beschreibung von Picpass

Die Implementierung des MIBA Schemas wird nun mit einem Passwortsafe verknpft, um ein mgliches Einsatzgebiet auf mobilen Gerten zu demonstrieren. Das MIBA System und der Passwortsafe bilden gemeinsam die Picpass Applikation (siehe Abbildung 6.1). Beim ersten Start der Applikation wird der Benutzer aufgefordert ein MIBA Passwort zu erstellen und anschlieend zur Besttigung zu wiederholen. Analog zu bekannten Passworterstellungsdialogen werden hierfr zwei Textfelder verwendet anstatt einem Assistenten, Buttons oder hnlichem (siehe Abbildung 6.1 (a)). Tatschlich handelt es sich jedoch nicht um Textfelder, sondern um zwei Labels mit dem gleichen Hintergrund wie ein Textfeld. Das hat den Vorteil, dass das Aufklappen der Soft-Tastatur nicht unterdrckt werden muss und dass kein Cursor im fokusierten Textfeld blinkt. Es werden Textfelder benutzt, weil Benutzer mit dieser Ansicht bereits vertraut sind und die nchsten Schritte intuitiv durchfhren knnen. Klickt der
6 IMPLEMENTIERUNG EINES PASSWORTVERWALTUNGSSYSTEMS FR ANDROID
(a)
(b)
(c)
(d)
Abbildung 6.1: Die Abbildungen (a)-(d) zeigen das Passwortverwaltungssystem Picpass. Picpass nutzt das im vorherigen Kapitel vorgestellte Authentizierungsverfahren. Wird Picpass zum ersten Mal gestartet, wird der Benutzer aufgefordert einen Masterkey mit dem MIBA Schema zu erstellen (a). In Abbildung (b) ist die Hauptoberche von Picpass mit ausgeklapptem OptionsMenu zu sehen. Die Hauptoberche dient zum Navigieren 40 durch die einzelnen Eintrge von Picpass. Wird eine Website angeklickt, startet eine neue Activity, welche den kompletten Eintrag anzeigt (d). Abbildung (c) zeigt den Passwortnderndialog.
6.1 BESCHREIBUNG VON PICPASS
Benutzer auf ein Textfeld, so startet die MIBA Activity. Hat der Benutzer sein MIBA Passwort mit n Runden abgeschlossen, werden im Textfeld n Passwortsternchen angezeigt. Die Passwortbesttigung dient beim MIBA System nicht nur dem alleinigen Schutz vor unabsichtlichen Fehleingaben, sondern bewirkt zugleich eine bessere Einprgung. Nur wenn das erste MIBA Passwort mit der Besttigung bereinstimmt, wird der Masterkey erstellt und man gelangt zur Hauptoberche des Passwortsafes (siehe Abbildung 6.1 (b)). Hat der Benutzer seinen Masterkey angelegt, so wird er bei weiteren Starts der Applikation zur Eingabe seines MIBA Passwortes aufgefordert. Die Hauptoberche des Systems (siehe Abbildung 6.1 (b)) ist eine scrollbare Liste mit allen gespeicherten Eintrgen des Safes. Ein Listeneintrag besteht dabei aus einer Kurz-URL (URL ohne http:// oder www) und einem Favicon der betreffenden Seite. Zur Anzeige der Listenansicht werden nur die mit 256 Bit verschlsselten KurzURLs entschlsselt. Dies beschleunigt den Aufbau der Listenansicht. Die Favicons werden nach dem Anlegen eines neuen Eintrages im Hintergrund durch einen zustzlich Thread heruntergeladen. Dadurch wird vermieden, dass die Liste nicht auf eine Scrollbewegung whrend des Downloadvorganges reagiert. Da der Download bei langsamen Internetverbindungen bis zu ca. 10 Sekunden dauern kann, werden die Favicons im Interal Storage der Applikation dauerhaft gecached. Dadurch knnen die Favicions beim nchsten Programmstart ohne Verzgerung angezeigt werden. Fr einen tatschlichen Einsatz des Systems sollten die Favicons jedoch noch in verschlsselter Form gespeichert werden. Die Abbildung 6.2 zeigt die beschriebene Dialogstruktur. In den Einstellungen der Applikation bendet sich eine Option zum Wechseln des MIBA Kennwortes (siehe Abbildung 6.1 (c)). Diese Funktion ist besonders relevant fr Demonstrationszwecke oder sptere Evaluationen des MIBA-Systems. Wurde der Masterkey gendert, wird dem Benutzer eine Progressbar angezeigt, whrend alle Eintrge des Passwortsafes mit dem neuen Masterkey verschlsselt werden. Sobald ein Listeneintrag ausgewhlt wird, wird der komplette Datensatz entschlsselt und angezeigt (siehe Abbildung 6.1 (d)). Wird der GO-Button bettigt, so wird das Passwort in die Zwischenablage kopiert und der Android Browser ffnet die URL des Eintrages. Hlt man das Passworteingabefeld auf der Webseite gedrckt, so kann das Passwort aus der Zwischenablage eingefgt werden (siehe Abbildung 6.3). Diese Copy&Paste-Methode ist allerdings noch nicht komfortabel genug und zudem unsicher, da jede Applikation Zugriff auf die Zwischenablage hat. Die vorgestellte Lsung soll lediglich einen praktischen Anwendungsfall des MIBA Konzepts auf mobilen Gerten veranschaulichen. Trotzdem soll im Abschnitt 6.2 genauer darauf eingegangen werden, wie sich die Browserintegration fr ein tatschliches System verbessern liee. Der Picpass Sourcecode bendet sich auf einer eingeklebten CD dieser Arbeit. Der nchste Abschnitt beschftigt sich nher mit der in Picpass verwendeten Verschlsselungstechnik.
41
Start
LoginActivity (MIBA-Schema)
(2.1) Klick auf Textfeld
Nein (2.2) Textfeld ausfllen (2.4) Textfeld ausfllen StartsceenActivity (2) Nein Masterkey existiert? Ja LoginActivity (MIBA-Schema)
(2.5) LoginActivity (MIBA-Schema) (2.3) Passwort wiederholen Passwrter identisch? Passwort Korrekt? Nein Ja
Browser
Klick auf GO
EditEntryActivity
Klick auf Eintrag
OverviewListActivity
Ja
Abbildung 6.2: Dialogstruktur von Picpass nach Applikationsstart. Von der OverviewListActivity gelangt man noch zu weiteren Dialogen (Suchdialog, Eintragerstellungsdialog, Lschdialog, Einstellungsdialog). Aus Grnden der bersichtlichkeit wird dies hier nicht aufgefhrt.
Abbildung 6.3: Nach einem Klick auf den GO-Button wird der Browser mit der entsprechenden URL gestartet. Das Passwort kann aus der Zwischenablage eingefgt werden.
42
6.1 BESCHREIBUNG VON PICPASS
Verschlsselung in Picpass
UserInput
Keyphrase
Random Hash
Encrypted Hash
generateKeyphrase()
generateRandomHash()
encrypt()
storeMasterKey()
LoginActivity (MIBA Schema)
decrypt()
CryptoHelper
encrypted Entries
decrypted Entries
Abbildung 6.4: Die Abbildung veranschaulicht die Erzeugung des Picpass Masterkeys und die Entschlsselung der Eintrge des Passwortsafes. Die gestrichelten Linien symbolisieren den Datenuss und die durchgezogenen Linien den Kontrolluss
Picpass verwendet AES-256 zur Verschlsselung. Das MIBA System erzeugt anhand der Benutzereingabe einen Keyphrase. Der Keyphrase dient zur Verschlssung eines zufllig generierten 256 Bit Hashes. Der unverschlsselte Hash wird wiederum als Keyphrase verwendet, um die einzelnen Eintrge im Safe zu chiffrieren/dechiffrieren. Der beschriebene Vorgang wird in Abbildung 6.4 veranschaulicht. Ein Eintrag besteht hierbei aus einer URL, einem Benutzernamen und einem Passwort. Die verschlsselten Eintrge und der verschlsselte Hash werden in der SQLite Datenbank der Applikation gespeichert. Zur Verschlsselung wurde die CryptoHelper.java Klasse von Steven Osborn genutzt [31].
43
6.2 Mglichkeiten der Browserintegration

Die verschiedenen Mglichkeiten, wie eine Applikation mit dem Browser interagieren knnte, werden in diesem Kapitel noch etwas nher erlutert. Vorab sei gesagt, dass sich dieses Thema nur durch unschne Umwege realisieren lsst, da der Android Browser eigentlich kein richtiges Pluginkonzept unterstzt. Mit richtig ist gemeint, dass der Android Browser kein offenes Plugin-Konzept hat mit dessen Hilfe sich der Browser beliebig erweitern oder anpassen liee. Spezielle Programmerweiterungen, wie Flash, werden zwar untersttzt, aber nur weil der Android Browser hiefr extra angepasst wurde. Seit Android 2.3 (Gingerbread) untersttzt der Android Browser eine feste Anzahl an Plugins1 , die ber spezielle Object-Tags in eine HTML-Seite eingebettet werden mssen. Mit diesen Object-Tags ist u.A. auch ein Zugriff auf den DOM-Baum einer HTML-Seite mglich, wodurch sich Formularfelder ausfllen lieen. Da sich jedoch das nachtrgliche Hinzufgen dieser Object-Tags zu einer abgerufenen Webseite als schwierig erweist, ist diese Methode nicht fr Picpass relevant. Nachfolgend werden die einzelnen Methoden erlutert, die sich fr Picpass eignen wrden. Eine Mglichkeit wre die Anpassung des Android Browsers. Der Android Browser ist Opensource und knnte speziell fr die Kommunikation mit externen Programmen, wie Picpass erweitert werden. Der Browser ist allerdings eine native Applikation und der Sourcecode lsst sich daher nicht mit dem Eclipse Android SDK kompilieren. Das komplette Entwicklungsenvironemnt nachzubilden, knnte sich aufgrund von Packetabhngigkeit weiter erschweren. Auerdem bleibt noch die Frage der Kompatibilitt bei verschiedenen Android Versionen und einige Benutzer wrden einem Custom-Browser nicht vertrauen. Man knnte aber auch einen Browser verwenden, der ein offenes Plugin-System untersttzt. Der einzige Browser fr Android, der beliebige Plugins untersttzt, ist Mozilla Firefox Mobile. Firefox Mobile untersttzt zwar Plugins auf Basis von XUL, CSS, JavaScript und XPCOM, diese knnen jedoch nicht mit anderen Activities Daten austauschen. Eine andere Notlsung, die viele Passwortsafes benutzen, ist die Android WebView Klasse. Die Klasse dient eigentlich nur zum Anzeigen von HTML-Seiten. Die WebView wird in die eigene Applikation aufgenommen und bildet einen Browser innerhalb der eigenen Applikation nach. Die WebView hat jedoch keinerlei Browserfunktionalitten, wie beispielsweise eine Adressleiste, Lesezeichen oder hnlichem. Mittels eines Javascript to Java Interfaces von Android lassen sich die Formularfelder in der Webview ausfllen.
1 Ein
Demonstrationsprojekt namens BrowserPlugin gibt es im Android Source Code Verzeichnis (http://android.git.kernel.org) im development.git der Gingerbread Version.
44
6.2 MGLICHKEITEN DER BROWSERINTEGRATION
Das Problem der Browserintegration hat im Grunde jeder Passwortsafe. Deshalb werden einige etablierte Methoden aus anderen Passwortsafes vorgestellt und mit Verbesserungsvorschlgen angereichert. Der Android Passwortsafe LastPass [25] benutzt Javascript Lesezeichen, um HTML Forms auszufllen. Mann muss sich allerdings vorher auf lastpass.com anmelden, bevor das Bookmarklet2 funktioniert. Das LastPass Bookmarklet System kann allerdings in dieser Weise nicht fr Picpass verwendet werden. Wir wollen uns nicht auf einem Webserver mit einem Textpasswort anmelden, sondern das Multitouch Image Based Authentication System benutzen. Der Bookmarklet Ansatz liee sich jedoch wie folgt fr Picpass anpassen. In Android ist es mglich eigene URI-Schemen fr Applikationen zu registrieren (z.B. picpass://) [19]. Diese Technik wird zum Beispiel auch verwendet, um den Android Market ber einen Webseitenlink zu starten. Wird solch eine registrierte URI angesprochen, wird die entsprechende Applikation gestartet. Ein Bookmarklet knnte so genutzt werden, um Picpass mit der Information der momentan geffneten Website zu starten. In Picpass kann die Webseite dann mittels einer WebView angezeigt werden und das Formular ausgefllt werden. Aber der Umweg ber das Lesezeichen bleibt bestehen. LastPass bietet jedoch noch eine andere Alternative an, um Zugriff auf Formularfelder zu erlangen. LastPass installiert im Android System eine eigene Soft-Tastatur. Bei jedem Klick in ein Eingabefeld ffnet sich dadurch eine von LastPass angepasste Tastatur. Die proprietre Tastatur hat einen Extrabutton, welcher Befehle an die LastPass Activity schicken kann. Bei LastPass funktioniert jedoch das Ausfllen von Browser-Formularen nicht, da LastPass nicht in der Lage ist, die geffnete URL zu ermitteln [24]. Weil Soft-Tastaturen keine nativen Android Anwendungen sind, sondern lediglich Activities, lassen sie sich wie normale Applikationen programmieren und installieren (siehe Artikel [18]). Mit einer eigenen Soft-Tastatur Activity liee sich dann eine Kommunikation mit der Picpass Activity bewerkstelligen (siehe Abbildung 6.5). Auf die Soft-Tastatur wird ein zustzlicher Picpass-Button hinzugefgt. Wird der Button gedrckt, so wird eine Anfrage nach einem Passwort und einem Benutzernamen an die Picpass Activity gesendet. Die Antwort fllt die Tastatur Activity in das Formularfeld ein. Fr welche Webseite Picpass die Zugangsdaten liefern soll, kann aus der BrowserHistory ausgelesen werden. Falls man in der Praxis vor hat den Passwortsafe fr ein bestimmtes Zeitfenster von mehreren Minuten offen zu halten, sollten allerdings noch weiterfhrende berlegungen/Recherchen angestrebt werden, damit nicht jede beliebige Applikation eine Passwortanfrage an Picpass stellen kann.
2 Lesezeichen
mit Javascript-Code
45
Benutzer
BrowserActivity
TastaturActivity
PicpassActivity
Klick in Textfeld
Tastatur wird geffnet Klick Picpass Button Passwortanfrage
History abfragen URL Passwort entschlsseln
Benutzer und Passwort sendKeyEvent()
Abbildung 6.5: Die Abbildung zeigt das Zusammenspiel zwischen Softtastatur, Browser und Picpass
46
7 Diskussion und Ausblick

Der ausfhrliche Vergleich mit bestehenden Passwortsystemen lieferte die Inspiration fr ein neuartiges IBA System, das die Multitouch-Funktionalitt von modernen Smartphones ausnutzt. Die Konzepte der bisherigen IBA Systeme wurden analysiert und teilweise in das MIBA Konzept aufgenommen. Die Umsetzung der aufgegriffenen Konzepte auf die Android Platform wurde beschrieben. Bei einer reinen Entropiebetrachtung ist das MIBA System allen betrachteten bisherigen Systemen berlegen. Das MIBA Konzept hat bei gleicher Rundenanzahl eine hhere Entropie, als die vorgestellten IBA Systeme ohne Multitouch. Wie die Tabelle 2.2 zeigt, sind bei MIBA am wenigsten Klicks notwendig, um die Entropie des Referenzpasswortes zu erreichen. Werden alle drei Runden ohne Shift ausgefhrt, so sind drei Klicks notwendig. Mit Shiftaktivierung in jeder Runde wren sechs Klicks erforderlich. Zu beachten ist hierbei, dass jeder Klick mit mehreren Fingern ausgefhrt werden knnte. Die Eingabeerkennung des vorgestellten MIBA Konzepts funktioniert zuverlssig. Das System ist robust gegen Fehleingaben und lsst eine Korrektur der Fingerstellung whrend der Eingabe zu. Das MIBA System wurde in ein Passwortverwaltungssystem integriert. Zusammen bilden die zwei Komponenten die Applikation Picpass. Die Gesamtapplikation reagiert ohne Verzgerungen auf Benutzereingaben. In initialen Benutzertests auf Android Gerten wurde ermittelt, dass sich ein neunstelliges Textpasswort mit Gro- und Kleinschreibung inkl. Sonderzeichen in durchschnittlich 14 Sekunden eingeben lsst. Ein Picpass Passwort mit der gleichen Entropie hat vier Runden. Werden in den vier Runden, drei Runden mit Shift ausgefhrt, so sind sieben Klicks notwendig. Fr eine solche Eingabe sind 11 Sekunden mit MIBA erforderlich. Man beachte jedoch, dass eigentlich zu den 14 Sekunden noch die Zeit fr das Tippen des Benutzernamens dazu gezhlt werden msste. Diese Zeitmessungen sind jedoch nicht reprsentativ, bieten aber einen ersten Einblick in die Benutzbarkeit des Verfahrens. Der Passwortsafe knnte auch fr eine einstellbare Dauer geffnet gehalten werden, damit sich der Benutzer in dieser Zeitspanne, auf mehreren Seiten einloggen kann, ohne bei jedem Loginwunsch sein Picpass Passwort wiederholen zu mssen. Da bei manchen Fingerstellungen teilweise die komplette Hand ber dem Display ist, wird vermutet, dass das Verfahren gegen Shouldsurng relativ resistent ist.
7 DISKUSSION UND AUSBLICK
Die Usability und Merkbarkeit von MIBA Passwrtern sollte jedoch in einer Benutzerstudie genauer evaluiert werden. Als Indikator fr die Merkbarkeit sollte der Test mit den gleichen Probanden zwei Wochen spter erneut durchgefhrt werden. Die Evaluation sollte sich zur besseren Vergleichbarkeit entweder an bereits durchgefhrten Studien orientieren oder mehrere IBA Systeme mit der gleichen Metrik untersuchen. Klassische Textpasswrter sollten ebenfalls in den Vergleich aufgenommen werden. Als Indikatoren fr die Usability knnen die Eingabezeit und die Loginrate Anzahl er f olgreicher Logins herangezogen werden. Anzahl aller Logins
48
Danksagung
Vielen Dank an meinen Betreuer Florian Schaub fr das aufmerksame Korrekturlesen dieser Arbeit und die hilfreichen Verbesserungsvorschlge. Ohne Ihn wre die Arbeit nicht so geworden, wie sie jetzt ist. Mein Dank gebhrt auch Klaus Kammerer fr das Design des Picpass Launcher Icons.
Literaturverzeichnis
[1] BITKOM: Smartphones erobern den Massenmarkt (Presseinfo TK- und Medienpolitik) - BITKOM. http://www.bitkom.org/de/presse/64255_62420.aspx. Version: 2010. [Online: accessed 10-June-2011] Graphical password. In: US Patent 5559961 04 [2] Blonder, Greg: (1996), 18. http://www.google.com/patents?hl=en&lr=&vid= USPAT5559961&id=x9sjAAAAEBAJ&oi=fnd&dq=Graphical+ passwords&printsec=abstract [3] Brostoff, Sacha ; Sasse, M A.: Are Passfaces More Usable Than Passwords ? A Field Trial Investigation. In: In McDonald S., et al. (Eds.), People and Computers XIV - Usability or Else, Proceedings of HCI 2000 (2000), S. 405424 [4] Chiasson, Sonia: Usable Authentication and Click-Based Graphical Passwords, Carleton University (Canada), Ph.D. Thesis, 2009 [5] Chiasson, Sonia ; Forget, Alain ; Stobert, Elizabeth ; Oorschot, P. C. ; Biddle, Robert: Multiple password interference in text passwords and click-based graphical passwords. In: Proceedings of the 16th ACM conference on Computer and communications security - CCS 09 (2009), 500. http://dx.doi.org/10.1145/ 1653662.1653722. DOI 10.1145/1653662.1653722. ISBN 9781605588940 [6] Chiasson, Sonia ; Van Oorschot, P ; Biddle, Robert ; Biskup, Joachim (Hrsg.) ; Lpez, Javier (Hrsg.): Graphical Password Authentication Using Cued Click Points. Springer Berlin / Heidelberg, 2007 (4734). 359374 S. http: //dx.doi.org/10.1007/978-3-540-74835-9_24. http://dx.doi.org/10.1007/ 978-3-540-74835-9_24 [7] Citty, Jonathan ; Hutchings, Dugald R.: TAPI : Touch-screen Authentication using Partitioned Images / ELON UNIVERSITY. 2010. Forschungsbericht [8] Davis, D ; Monrose, F ; Reiter, Michael K.: On User Choice in Graphical Password Schemes. In: Proceedings of the 13th conference on USENIX Security SymposiumVolume 13 Bd. 21 USENIX, USENIX Association, 2004 (SSYM04), 11 Pages
LITERATURVERZEICHNIS
[9] De Angeli, Antonella ; Coutts, Mike ; Coventry, Lynne ; Johnson, Graham I. ; Cameron, David ; Fischer, Martin H.: VIP. In: Proceedings of the Working Conference on Advanced Visual Interfaces - AVI 02. New York, New York, USA : ACM Press, 2002. ISBN 1581135378, 316 [10] Dhamija, by R.: Deja Vu: A user study using images for authentication. In: Proceedings of the 18th annual conference on Computer graphics and interactive techniques - SIGGRAPH 91. New York, New York, USA : ACM Press, 1991 ( 102590), S. S. 319328 [11] Dirik, Ahmet E. ; Memon, Nasir ; Birget, Jean-Camille: Modeling user choice in the PassPoints graphical password scheme. In: Proceedings of the 3rd symposium on Usable privacy and security SOUPS 07 (2007). http://dx.doi.org/10.1145/ 1280680.1280684. DOI 10.1145/1280680.1280684. ISBN 9781595938015 [12] Dunphy, Paul ; Yan, Jeff: Do background images improve draw a secretgraphical passwords? In: Proceedings of the 14th ACM conference on Computer and communications security CCS 07 (2007), 36. http://dx.doi.org/10.1145/ 1315245.1315252. DOI 10.1145/1315245.1315252. ISBN 9781595937032 [13] Gartner: Gartner Says Worldwide Mobile Phone Sales Grew 17 Per Cent in First Quarter 2010. http://www.gartner.com/it/page.jsp?id=1372013. Version: 2010. [Online: accessed 10-June-2011] [14] Gill, Charlotte: iPhone muggers cash in on craze as street thefts of smartphones rise | Mail Online. http://www.dailymail.co.uk/news/article-1345904/ iPhone-muggers-cash-craze-street-thefts-smartphones-rise.html. Version: 2011. [Online: accessed 10-June-2011] [15] Goldberg, Joseph ; Hagman, Jennifer ; Sazawal, Vibha: Doodling our way to better authentication. In: CHI 02 extended abstracts on Human factors in computing systems CHI 02 (2002). http://dx.doi.org/10.1145/506443.506639. DOI 10.1145/506443.506639. ISBN 1581134541 [16] Goldstein, A G. ; Chance, J E.: Visual recognition memory for complex congurations. In: Perception Psychophysics 9 (1970), Nr. 2, 237241. http: //dx.doi.org/10.3758/BF03212641. ISSN 19433921 [17] Golofit, Krzysztof: Click Passwords Under Investigation. In: Computer Security ESORICS 2007 (2007), 343358. http://dx.doi.org/10.1007/ 978-3-540-74835-9_23. DOI 10.1007/9783540748359_23
52
[18] Google: Creating an Input Method. http://developer.android.com/resources/ articles/creating-input-method.html. Version: 2011. [Online: accessed 10June-2011] [19] Google: Intents and Intent Filters | Android Developers. http://developer. android.com/guide/topics/intents/intents-filters.html. Version: 2011. [Online: accessed 10-June-2011] [20] Jansen, W A.: Picture password: a visual login technique for mobile devices. (2003). http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle: Picture+Password+:#0 [21] Jermyn, Ian ; Mayer, Alain ; Monrose, Fabian ; Reiter, Michael K. ; Rubin, Aviel D.: The Design and Analysis of Graphical Passwords. In: Proceedings of the 8th conference on USENIX Security SymposiumVolume 8 (1999), 1. http: //dx.doi.org/10.1109/ICCIIS.2010.35. DOI 10.1109/ICCIIS.2010.35 [22] Klein, Daniel V.: Foiling the Cracker: A Survey of , and Improvements to , Password Security. In: Proceedings of the 2nd USENIX Security Workshop (1990), 514. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1. 129.5012&rep=rep1&type=pdf [23] Kot, Alex: An interactive and secure user authentication scheme for mobile devices. In: 2008 IEEE International Symposium on Circuits and Systems (2008), Mai, Nr. 062, 29732976. http://dx.doi.org/10.1109/ISCAS.2008.4542082. DOI 10.1109/ISCAS.2008.4542082. ISBN 9781424416837 LastPass - Hilfe. http://lastpass.com/support.php?cmd= [24] LastPass: showfaq&id=1176. Version: 2011. [Online: accessed 10-June-2011] [25] LastPass: LastPass - Password Manager, Formular ausfller, Password Management. http://lastpass.com/. Version: 2011. [Online: accessed 10-June-2011] [26] Melcher, D: Persistence of visual memory for scenes - A medium-term memory may help us to keep track of objects during visual tasks. In: Nature 412 (2001), Nr. 6845, S. 401. ISSN 00280836 [27] Mobbeel: Your passwords are not safe in Android. http://www.mobbeel.com/ your-passwords-are-not-safe-in-android/. Version: 2010. [Online: accessed 10-June-2011] [28] Nali, Deholo ; Thorpe, Julie: Analyzing user choice in graphical passwords / Carleton University, University of Ottawa. Version: 2004. http://dx.doi.org/ 10.1.1.85.998. Citeseer, 2004. Forschungsbericht. 16 S.
53
[29] Nielsen, Jakob: Usability Engineering. Morgan Kaufmann, 1993 http://www. useit.com/jakob/useengbook.html. ISBN 0125184050 [30] Oracle: Oracle and Passlogix. http://www.oracle.com/us/corporate/ Acquisitions/passlogix/index.html. Version: 2011. [Online: accessed 10June-2011] [31] Osborn, Steven ; McEoin, Randy: Android Password Safe - Google Project Hosting. http://code.google.com/p/android-passwordsafe/. Version: 2009. [Online: accessed 10-June-2011] [32] Passfaces: Two Factor Authentication, Graphical Passwords - Passfaces. http://www. realuser.com/. Version: 2011. [Online: accessed 10-June-2011] [33] Ruef, Marc: Geschlechtsspezische Passwortunsicherheiten. http://www.scip.ch/ ?labs.20091120. Version: 2009. [Online: accessed 10-June-2011] [34] Spiegel: Jailbreakme.com: Web-Seite knackt iPhone-Sperre - SPIEGEL ONLINE - Nachrichten - Netzwelt. http://www.spiegel.de/netzwelt/gadgets/0,1518,709681, 00.html. Version: 2010. [Online: accessed 10-June-2011] [35] Tao, Hai: Pass-Go , a New Graphical Password Scheme, University of Ottawa, Master of Applied Science degree in Electrical and Computer Engineering, 2006 [36] Thorpe, Julie ; Oorschot, P C V.: Graphical dictionaries and the memorable space of graphical passwords. In: Proceedings of the 13th USENIX Security Symposium USENIX, USENIX Association, 2004 (SSYM04) [37] Thorpe, Julie ; Oorschot, P C V.: Human-seeded attacks and exploiting hot-spots in graphical passwords. In: Proceedings of 16th USENIX Security (2007), 103118. http://portal.acm.org/citation.cfm?id=1362911. ISBN 1113335555779 [38] Wiedenbeck, S ; Waters, J ; Birget, J ; Brodskiy, a ; Memon, N: PassPoints: Design and longitudinal evaluation of a graphical password system. In: International Journal of Human-Computer Studies 63 (2005), Juli, Nr. 1-2, 102127. http://dx.doi. org/10.1016/j.ijhcs.2005.04.010. DOI 10.1016/j.ijhcs.2005.04.010. ISSN 10715819
54
N AME : DANIEL R ITTER
M ATRIKELNUMMER : 656147
Erklrung Ich, Daniel Ritter, Matrikelnummer 656147, erklre, dass ich die Arbeit selbstndig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Ulm, den . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Daniel Ritter
55

Bildbasierte Zugriffskontrolle Für Passwortverwaltungssysteme Auf Mobilen Geräten Bachelorarbeit An Der Universität Ulm

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Bildbasierte Zugriffskontrolle Für Passwortverwaltungssysteme Auf Mobilen Geräten Bachelorarbeit An Der Universität Ulm

Hochgeladen von

Copyright:

Verfügbare Formate

Universitt Ulm | 89069 Ulm | Germany

Fakultt fr Ingenieurwissenschaften und Informatik Institut fr Medieninformatik

Bildbasierte Zugriffskontrolle fr Passwortverwaltungssysteme auf mobilen Gerten

Betreuer: Florian Schaub

Fassung vom 27. Juli 2011

zu verwechseln mit dem Global Positioning System

1.3 AUFBAU DER ARBEIT

1.3 Aufbau der Arbeit

2 Vergleich bildbasierter Passwortsysteme

2.1 Kategorisierung graphischer Passwrter

2 VERGLEICH BILDBASIERTER PASSWORTSYSTEME

2.2 Einfhrung einer Vergleichsmetrik

2.2 EINFHRUNG EINER VERGLEICHSMETRIK

2 VERGLEICH BILDBASIERTER PASSWORTSYSTEME

2.3 TAPI Touchscreen Authentication using Partitioned Images

2 VERGLEICH BILDBASIERTER PASSWORTSYSTEME

2.6 VIP VISUAL IDENTIFICATION PROTOCOL

2.6 VIP Visual Identication Protocol

2 VERGLEICH BILDBASIERTER PASSWORTSYSTEME

2 VERGLEICH BILDBASIERTER PASSWORTSYSTEME

2.8 CCP Cued Click Points

2.8 CCP CUED CLICK POINTS

2 VERGLEICH BILDBASIERTER PASSWORTSYSTEME

2.9 Loci Schema

2.10 Picture Password

2.10 PICTURE PASSWORD

2 log(30) = log(302 ) = log(30 30) log (30 + 30 30)

2 VERGLEICH BILDBASIERTER PASSWORTSYSTEME

2.11 DAS Draw A Secret

2.11 DAS DRAW A SECRET

2 VERGLEICH BILDBASIERTER PASSWORTSYSTEME

Lmax log2 (#passwords) Lmax log2 (#passwords)

Abbildung 2.9: Graphische Android-Tastensperre.

2 VERGLEICH BILDBASIERTER PASSWORTSYSTEME

Dot indicator Line indicator Star

200 180 160 140

Colored Pass-Go-9 Pass-Go-9 Pass-Go-5 DAS-5

2 VERGLEICH BILDBASIERTER PASSWORTSYSTEME

2010 2000 2000 2003 2003 2007 2008 2003

Cued-Recall Recognition Recognition Recognition Cued-Recall Recognition Association Recognition

Background Draw A Secret Pass-Go

3 Konzeptvorstellung eines MIBA Schemas

3.1 Verwendung des CCP Hintergrundbildsystems

3 KONZEPTVORSTELLUNG EINES MIBA SCHEMAS

3.2 VERWENDUNG DER SHIFT-METHODE

3.2 Verwendung der Shift-Methode

4 Implementierung des MIBA Konzepts fr Android

4 IMPLEMENTIERUNG DES MIBA KONZEPTS FR ANDROID

4.1 UMSETZUNG DES CCP HINTERGRUNDSYSTEMS

4.1 Umsetzung des CCP Hintergrundsystems

4 IMPLEMENTIERUNG DES MIBA KONZEPTS FR ANDROID

4.2 Umsetzung der Shift-Funktion

4.3 Korrektur der Fingerstellung whrend der Eingabe

4.3 KORREKTUR DER FINGERSTELLUNG WHREND DER EINGABE

5 Untersuchung des MIBA Passwortraumes

5.1 Einfhrung der Formeln

f (n, r ) = g(n, r ) + ( g(n, r ))2 (5.2)

5 UNTERSUCHUNG DES MIBA PASSWORTRAUMES

5.2 Berechnung des theoretischen Passwortraumes

162 + 1622 = 26406

6 Implementierung eines Passwortverwaltungssystems fr Android

6.1 Beschreibung von Picpass

6 IMPLEMENTIERUNG EINES PASSWORTVERWALTUNGSSYSTEMS FR ANDROID