Bachelorarbeit Informatikborchert/Troja/studdiplfiles/... · Eberhard Karls Universit at T ubingen Mathematisch-Naturwissenschaftliche Fakult at Wilhelm-Schickard-Institut fur Informatik

Eberhard Karls Universitat TubingenMathematisch-Naturwissenschaftliche Fakultat

Wilhelm-Schickard-Institut fur Informatik

Bachelorarbeit Informatik

Sichere Datenhaltung in der Cloud via

Handy-Demoversion

Tuba Yapinti

9. November 2012

Gutachter

Prof. ReinhardtWilhelm-Schickard-Institut fur Informatik

Universitat Tubingen

Betreuer

Dr. Bernd BorchertWilhelm-Schickard-Institut fur Informatik

Universitat Tubingen

Yapinti, Tuba:Sichere Datenhaltung in der Cloud via Handy-DemoversionBachelorarbeit InformatikEberhard Karls Universitat TubingenBearbeitungszeitraum: 29. Mai bis 09. November 2012

i

Zusammenfassung

Cloud-Computing ist in der letzten Zeit immer mehr in den Vordergrund getre-ten. Dies liegt daran, dass Cloud-Computing seinen Usern ermoglicht Datenvon jedem Standort abzurufen. Die mobile Datenhaltung wird dabei durcheinen externen Server ermoglicht.Einer der bekanntesten Anwendungen von Cloud-Computing ist dropbox. Indropbox konnen Daten hochgeladen und gemeinsame Nutzung der Daten furmehrere Anwender freigegeben werden. Die Anzahl der User, die diese Dienst-leistungen in Anspruch nehmen ist in kurzer Zeit extrem angestiegen. DurchAktionen wie Spacerace [1] das Oktober 2012 begonnen hat, werden immermehr User erworben. Weltweit konnen Universitaten an dem Spacerace teil-nehmen. Allein im November 2012 sind 47536 (gesamte User der Top 10deutschlandweit) User dazugekommen, die dropbox nutzen. Anwendungen wiedropbox wecken nicht nur die Aufmerksamkeit der User, sondern auch die derHacker. Aus diesem Grund mussen die Daten strenger vor Angreifern geschutztwerden.Im Rahmen dieser Arbeit wurde eine Demoversion entwickelt, die eine sichere-re Datenhaltung ermoglicht. Dazu werden Verschlusselungsverfahren wie dasAES-Verfahren, Hashingverfahren wie MD5 und das Login Verfahren eKaayangewendet. Die normale Loginverfahren im Web weist Lucken auf, sodassIdentitaten des Users geklaut werden konnen. Diese Risiken sollen in der De-moversion beseitigt werden, indem ein anderes Loginverfahren angewandet.Der User wird sich in der Demoversion nicht mit seinem Passwort einloggen,sondern wird fur das Login sein Handy nutzen. Mit dem AES-Verfahren wer-den Dateiinhalte ver- und entschlusslet und nur in verschlusselter Form aufdem Server gespeichert. Des Weiteren werden die Erweiterungs-und Verbesse-rungsmoglichkeiten behandelt und die Sicherheit der Demoversion analysiert.

ii

Danksagung

Ich bedanke mich bei allen, die mich uber die ganze Zeit unterstutzt haben.Insbesondere geht ein Dank an meine Familie und meine Freunde Dilek Tun-cbilek, Evelina Pillai, Sonja Hagele und Murat Simsek.

Inhaltsverzeichnis

Abbildungsverzeichnis v

1 Einleitung 1

2 Grundlagen 3

2.1 Cloud-Computing . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 eKaay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Message-Digest Algorithmus (MD5) . . . . . . . . . . . . . . . . 6

2.4 Advanced Encryption Standard (AES) . . . . . . . . . . . . . . 6

2.4.1 AddRoundKey . . . . . . . . . . . . . . . . . . . . . . . 6

2.4.2 SubBytes . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.3 ShiftRows . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.4 MixColumn . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.5 Key Schedule . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.6 Entschlusselung . . . . . . . . . . . . . . . . . . . . . . . 11

3 Entwicklung der Demoversion 13

3.1 Das Ziel und die Grundideen . . . . . . . . . . . . . . . . . . . . 13

3.2 Layout mit HTML erstellen . . . . . . . . . . . . . . . . . . . . 14

3.3 Login ohne Ekaay . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Dateninhalt abrufen . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5 Daten bearbeiten und speichern . . . . . . . . . . . . . . . . . . 23

3.6 Login mit eKaay . . . . . . . . . . . . . . . . . . . . . . . . . . 25

iii

iv INHALTSVERZEICHNIS

4 Sicherheitsanalyse 29

4.1 Passwort versus eKaay . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Gefahren fur eKaay . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Diskussion und Ausblick 31

5.1 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Literaturverzeichnis 35

Abbildungsverzeichnis

2.1 Cloud-Computing . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Ablauf des eKaay-Verfahrens . . . . . . . . . . . . . . . . . . . . 5

2.3 AES Operation AddRoundKey . . . . . . . . . . . . . . . . . . 7

2.4 AES Operation SubBytes . . . . . . . . . . . . . . . . . . . . . 8

2.5 AES Operation ShiftRows . . . . . . . . . . . . . . . . . . . . . 9

2.6 AES Operation Key Schedule . . . . . . . . . . . . . . . . . . . 10

3.1 Login mit Passwort-Verfahren . . . . . . . . . . . . . . . . . . . 13

3.2 Login mit eKaay-Verfahren . . . . . . . . . . . . . . . . . . . . . 14

3.3 Hintergrund in CSS-Sytlesheet formatieren . . . . . . . . . . . . 15

3.4 CSS-Sytlesheet in HTML-Datei einbetten . . . . . . . . . . . . . 15

3.5 2D-Code in HTML-Datei einbetten . . . . . . . . . . . . . . . . 16

3.6 Platzierung des 2D Codes . . . . . . . . . . . . . . . . . . . . . 16

3.7 Erstellung von einem Formular fur das Login . . . . . . . . . . . 17

3.8 Login-Formular mit CSS in eine Box platzieren . . . . . . . . . 17

3.9 Buttons anlegen die JavaScript-Funktionen ausfuhren . . . . . . 18

3.10 Textfeld fur Editierung anlegen . . . . . . . . . . . . . . . . . . 18

3.11 Passwort und Username Uberprufung . . . . . . . . . . . . . . 19

3.12 Schutzfunktion bei Fehl-Login . . . . . . . . . . . . . . . . . . . 19

3.13 Hash Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.14 Zusammensetzung des Passworts . . . . . . . . . . . . . . . . . 20

3.15 Java-Funktion die Passwort beim Submitten hasht . . . . . . . . 20

3.16 XML-Objekt fur alle Browser anpassen . . . . . . . . . . . . . . 22

v

vi ABBILDUNGSVERZEICHNIS

3.17 Offnet Datei auf dem Server . . . . . . . . . . . . . . . . . . . . 24

3.18 Implementierte Arbeitsflache . . . . . . . . . . . . . . . . . . . . 25

3.19 Speichert Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.20 2D-Code zur eKaay-Account Aktivierung . . . . . . . . . . . . . 26

3.21 Ansicht der index-Seiten . . . . . . . . . . . . . . . . . . . . . . 27

3.22 Uberprufung der Daten auf dem eKaay-Server . . . . . . . . . . 27

Kapitel 1

Einleitung

Mobilitat gewinnt in der heutigen Zeit immer mehr an Bedeutung und auchin der IT-Branche ist sie ein Luxus, auf den nur wenige verzichten wurden.Sowohl private User als auch Firmen mochten neue und bequeme Technikenund Software,die die Datenhaltung vereinfachen und zu jeder Zeit aufrufbarmachen. Festplatten sind als Speichermedien sehr verbreitet, aber leider auchunpraktisch. Die Verwaltung ist zu zeitaufwendig und nicht immer von Vorteil.Das wird zu einem großeren Problem, wenn es sich um großere Datenmengenhandelt. Das standige neu installieren von Programmen, wenn der Computergewechselt wird oder es mehrere Computer gibt, ist auch sehr arbeitsaufwen-dig und unpraktisch. Diese Problematik und andere Grunde regten große Fir-men wie z.B. IBM zu der Entwicklung von Cloud-Computing an. Seit 2007 istCloud-Computing ein brennendes Thema, das die IT-Branche beschaftig. Im-mer mehr Interessenten und Anbieter befassen sich mit dieser neuen Technik[2].Die Grundidee hinter Cloud-Computing ist, dass Anbieter ihre IT-Dienste insInternet stellen und User somit von uberall und ohne Einschrankungen dieseDienstleistungen nutzen konnen. Diese Dienstleistungen konnen bspw. Daten-haltung oder Datenbearbeitung (Fotos oder Videos im Netz bearbeiten) sein.Weitere Dienste, die bislang nur auf dem eigenen Computer moglich waren,konnen durch Cloud-Computing nun im Netz benutzt werden [3, 4, 5]. Umdiese Dienstleistungen zu nutzen, wird nur ein User-Account mit Usernameund einem Passwort erstellt. Die dem User bereitgestellten und privaten Da-ten konnen eingesehen werden.Nahezu jedem ist die Dienstleistung dropBox bekannt [1]. Bei dropBox stehtjedem User ein Speicher von 2GB kostenlos zur Verfugung womit Daten aus-getauscht, hochgeladen und bearbeitet werden konnen. Der Aufwand um andie Daten zu gelangen beschrankt sich auf die Eingabe eines Usernamens undPasswortes und schon hat man die Daten auf dem Browser. Um auf die Datenzuzugreifen ist kein weiterer Aufwand notig. Der Nachteil dieses Verfahrens istdie geringe Sicherheit gegenuber Dritten.

1

2 KAPITEL 1. EINLEITUNG

Bei einem Hackerangriff oder sonstigen Eingriffe von Dritten kann das Passwortfur User-Accounts schnell entwendet werden. In nahezu jedem Login Verfahrenwird das eingegebene Passwort gehasht und auf den ersten Blick ist das origi-nale Passwort nicht mehr lesbar. Doch was fur einen einfachen User unmoglicherscheint, ist fur einen Hacker meist nur ein rechenaufwendiges, aber einfachesVerfahren um das Passwort zu erhalten [6, 7, 8].Die meisten Web-Portale hashen die Passworter mit MD5 dieses Verfahrenwird in Kapitel 2.3 erklart. Jedoch ist MD5 nicht das sicherste Verfahren,um Passworter zu schutzen. Es existieren sog. Regenbogentabellen, mit denenPassworter wieder generiert werden konnen (Kapitel 3.3). Um das Verfahrensicherer zu machen gibt es bereits neue Methoden (Kapitel 3.3).Abgesehen von der Sicherheit kann das standige Eingeben des Passwortes auchals lastig empfunden werden.Eine Alternative zu dieser Methode stellt das von Forschern der UniversitatTubingen entwickelte eKaay Verfahren dar. EKaay ist das neue Verfahren, umUser vor Trojanern oder Angriffen durch Dritten zu schutzen. Login ohne dieUserdaten einzugeben ist dank eKaay moglich und die Anwendung sehr ein-fach. Der User muss mit seinem Handy, auf dem die App fur eKaay installiertist, den 2D-Code abfotografieren und schon wird man nach kurzer Zeit mitdem Account eingeloggt. Hinter dem Abfotografieren verbirgt sich ein Prozesszwischen Handy und dem Server, dieser Prozess wird in Kapitel 2.2 im Detailerlautert. Des Weiteren kommt die Frage auf wie die Daten auf dem Servergeschutz werden.Bei einem direkten Angriff auf den Server konnen die Dateninhalte ausgelesenund die Daten sind somit nicht sicher aufbewahrt werden. Doch solange derInhalt nicht im Originaltext zu lesen ist, kann der Angreifer wenig mit denDaten anrichten, solange er nicht weiß wie der Inhalt verschlusselt wurde. DerUser ist durch Verschlusselung des Dateninhaltes zusatzlich gesichert [9, 10].Im Rahmen dieser Bachelorarbeit wird eine Demoversion entwickelt, welche dieDatenhaltung in der Cloud, an das eKaay-Verfahren anknupft. Zusatzlich wer-den die Daten mit dem Verschlusselungs-Verfahren AES ver- und entschlusselt.Die Grundlagen dazu in Kapitel 2 und die Entwicklung der Demoversion inKapitel 3 erlautert. Sicherheitsanalyse, Diskussion und Ausblick runden dieArbeit ab.

Kapitel 2

Grundlagen

In diesem Kapitel wird Cloud-Computing und die fur die Demoversion verwen-deten Vefahren zusammenfassend erlautert. Beschreibungen und Erklarungenin diesem Kapitel sollen einen kurzen Einblick in die angewendeten Technikengeben. Anhand Beispielen soll das Verstandnis verstarkt werden.

2.1 Cloud-Computing

Cloud Computing, eine Wolke die immer mitkommt. Zahlreiche Anbieter bie-ten umfangreiche Dienstleistungen an, um den User von arbeitsaufwendigenProzessen zu befreien. Dienstleistungen wie Wartung, Sicherheit und Upda-tes sind nicht mehr Aufgaben des Users sondern, werden von den Anbieternubernommen. Zusammengefasst heit das fur den User weniger Arbeit undmehr Mobilitat[11]. Stellt man sich den Aufbau der Cloud, als ein Schich-tenmodell vor, dann ist die erste Schicht die Infrastruktur-Schicht ( Infrstuc-tur as a Service-IaaS ), die zweite Schicht der Cloud die Plattform und dieletzte Schicht die Anwendungs-Schicht. Diese Schichten sind die Grundbau-steine des Cloud Computings. Die Infrastruktur-Schicht kann auch als Basisdes Cloud Computings bezeichnet werden. Der Anbieter vermietet bei dieserArt von Service die fur die Anwendungen benotigten Infrastrukturen, wobeider Anbieter die Kosten fur diesen Service ubernimmt. Unter Infrastrukturkann man sich die Bereitstellung von Software (Netzwerkdienste) oder Hard-ware (Server, Arbeitsspeicher) vorstellen. Nicht nur die Infrastruktur, sondernauch die Plattform wird dem User vom Anbieter bereitgestellt. Dieser Servicewird Plattform as a Service genannt. Dem User werden Webanwendungen, z.B.Entwicklungsumgebungen wie Frameworks zur Verfugung gestellt, die er freinutzen und erweitern kann. Webanwendungen sind . Der Anbieter ubernimmtdann die aufwendige Arbeit wie Wartung oder Aktualisierung der Anwendun-gen, somit kann sich der User auf hauptsachlichen Aufgaben konzentrieren.Software as a Service (SaaS), der Anbieter stellt dem User nur Anwendungen

3

4 KAPITEL 2. GRUNDLAGEN

zur Verfugung. Dabei werden alle Anwendungen auf den Browser ausgefuhrtund die Daten auf dem Server des Anbieters gespeichert. Der Anbieter ist desWeiteren fur Sicherheit, Updates und Wartung der Anwendungen verantwort-lich [4, 12, 13, 14].

Abbildung 2.1: Dienste in der Cloud. In der weißen Wolke sind Anbieter abge-bildet, die dem User Plattformen im Internet zur Verfugung stellen. Jede weitereWolke stellt Anbieter dar, die Dienstleistungen in der Cloud anbieten. Anbieterin der blauen Wolke bieten softwarebasierte Dienstleistungen und Anbieter inder grauen Wolke bieten Dienstleistungen zu Infrastruktur [15]

2.2 eKaay

Ein Login ohne Passwort einzugeben! Klingt vorerst sehr unvorstellbar, aberist moglich. Was dazu benotigt wird, ist nur ein Smartphone und eine App,die leicht auf dem Handy installiert werden kann. Das eKaay-Verfahren istleicht zu erklaren. Der User sieht einen 2D-Code auf dem Bildschirm und

2.2. EKAAY 5

muss diesen mit der App scannen, den Rest ubernimmt die Technik. Dergenaue Ablauf des Logins mit eKaay wird im folgenden naher erlautert.Der User offnet die App, um den angezeigten 2D-Code zu scannen. Der zusehende 2D-Code wird fur jede Session vom Server generiert. Informationenwie Name des Account Servers, Session-ID und vom Server berechnet derSchlussel sind im 2D-Code codiert und konnen von der App ausgelesenwerden. Nach dem Scannen des 2D-Codes wird an Hand den gelesenenDaten nach einer Registrierung auf dem im 2D-Code codierten AccountServer nach dem Useraccount gesucht. Ist der User auf dem Account-Serverregistriert, so wird die Session-ID vom Account-Server mit dem privatenSchlussel (Userpasswort) des Users vom Handy verschlusselt. Das vom Handyverschlusselte Codewort wird mit dem Usernamen und der Session-ID viaInternet an den Account-Server gesendet. Anschließend muss vom AccountServer gepruft werden, ob die vom Handy gesendeten Daten dem Server furdiesen User bekannt sind. Wenn die Daten vom Handy mit den Daten aufdem Server ubereinstimmen, wird eine Verbindung zwischen Browser undServer hergestellt. Uber diese Verbindung werden die Daten des Users zumLogin verwendet und der User ist erfolgreich eingeloggt [10, 9, 16, 17].

Abbildung 2.2: Ablauf des eKaay-Verfahrens. Der Server erstellt einen 2D-Code in dem Informationen zur Session und dem Accountserver. Als nachstesscannt der User den 2D-Code auf dem Bildschirm mit der eKaay-App undschickt dem Server ebenfalls Infromationen zuruck. Anschließend loggt der Ser-ver den User mit dem Account auf dem Browser ein [18].


2.3 Message-Digest Algorithmus (MD5)

MD5 ist ein Hash-Algorithmus, der in vielen Internet-Portalen zum Schutz desPasswortes verwendet wird. Der Algorithmus berechnet aus der Eingabe einen128-Bit Hashwert. Nach dem die Eingabe gehasht wurde, wird an den Hashwerteine Eins angehangt. Im nachsten Schritt wird der Hashwert so lange mit Nul-len erweitert bis die Zahl durch (512−64)-teilbar ist. Die Lange des Passworteswird anschließend zu einem 64-Bit Hashwert kodiert und an den Hashwert an-gehangt. Der Hashwert in mehrere 512-Bit Große Blocke geteilt werden. DerHauptalgorithmus fuhrt dann auf dem Puffer, der in 32-Bit Worter unterteiltist, die Komprimierungsfunktion mit dem ersten Block aus. Dabei durchlauftjeder Block jeweils 16 Operationen pro Wort. Das Ergebnis der Funktion wirddann mit dem nachsten Block als Parameter ubergeben. Nachdem alle Blockeabgearbeitet sind, erhalt man am Ende den 128-Bit großen Hashwert. Sogar diekleinste Anderung in der Eingabe fuhrt zu einem komplett anderen Hashwert.Somit kann bei einer falschen Eingabe nie derselbe Hashwert erzeugt werden.Es ist aber moglich das zwei verschiedene Eingaben denselben Hashwert haben,was jedoch sehr unwahrscheinlich ist [6, 7].

2.4 Advanced Encryption Standard (AES)

Das AES Verschlusselung-und Entschlusselungsverfahren arbeitet mit einemDatenblock, dass den Inhalt der Daten enthalt und einem Cipher-Block indem sich der Userschlussel befindet. Der Algorithmus bildet aus den Daten128-Bit große Blocke und diese werden mit einem Schlussel der Lange 128, 192oder 256 Bit Lange ver-/entschlusselt. Die Schlussellange bestimmt im Algo-rithmus, wie oft dieser auf den Daten angesetzt durchgefuhrt wird. Bei 128-Bitwird der Algorithmus 10mal, bei 192-Bit 12mal und bei 256-Bit 14mal durch-gefuhrt.Jeder Block durchlauft wahrend dem verschlusseln mehrmals vier verschiedeFunktionen(Subbytes, ShiftRows, MixColumn und AddRoundKey). Ein gan-zer Durchlauf wird auch als Runde bezeichnet. Bis auf die letzte Runde werdenalle vier Abschnitte auf gleicher Weise durchlaufen. Der Unterschied der letz-ten Runde liegt darin, dass die Funktion MixColumn nicht ausgefuhrt wird.Furjede Runde wird ein eigener Schlussel benotigt der sich aus vorherigen Cipher-Block berechnen lasst. AES wird angewendet um Texte zu verschlusseln umden geheimen Inhalt der Nachricht oder Datei zu schutzen [19, 20].

2.4.1 AddRoundKey

Bevor die Verschlusselung beginnt werden Datenblock und Cipher-Blockbitweise durch XOR miteinander verknupft. Bei einer XOR-Verknupfung

2.4. ADVANCED ENCRYPTION STANDARD (AES) 7

Tabelle 2.1: XOR-Wertetabelle

a b a⊕b

0 0 00 1 11 0 11 1 0

gilt im Allgemeinen, dass nie beide Bedingungen gleichzeitig erfullt odernicht erfullt sein durfen. D.h. sobald nur eines der Bits wahr ist, so ist auchdie XOR-Verknupfung wahr. Die Verknupfung wird dann Zelle fur Zelledurchgefuhrt und der AddRoundKey erzeugt [19, 20].

Abbildung 2.3: AES Operation AddRoundKey. Jede Zelle im Datenblock(blau) und Cipherblock (rot) wird durch XOR verknupft. Das resultierende Er-gebnis wird in die Zelle des neuen Datenblocks eingetragen [19].

2.4.2 SubBytes

In dieser Funktion der Verschlusselung wird jedes Byte im Datenblock miteinem anderen festen Byte ersetzt. Dabei werden alle Zeichen der 64 Byteseinzeln betrachtet und mit einem anderen, aber festen Hexadezimalcode er-setzt. In der Substitutionstabelle oder im Array, ist fur jedes Byte von 0-255ein Eintrag enthalten und kann problemlos durch den Eintrag ersetzt werden.Nimmt man an, dass der aktuelle Zelleninhalt aus dem Datenblock z.B.

”15“

ist und eine Substitutionstabelle existiert, so wird durch die Eins die Zeile unddurch die Funf die Spalte in der Substitutionstabelle bestimmt. Somit wird die


”15“ mit dem Eintrag an dieser Stelle ersetzt und ist dann der neue Wert der

Zelle im Datenblock [19, 20].

Abbildung 2.4: AES Operation SubBytes Beispiel fur eine Substitutionstabel-le. Eintrage jede Zelle im Datenblock wird mit einem anderen Hexadezimalwertersetzt. Die Substitutionswerte werden aus der Tabelle entnommen. Ist die zuersetzende Hexadezimalzahl die 19 so ist der Substirionswert d4

2.4.3 ShiftRows

Nachdem die 64 Bytes im Datenblock erfolgreich substituiert wurden wirdals nachstes, wie man auch aus dem Namen des Verfahren entnehmenkann, die Zeilen im Datenblock verschoben. Die erste Zeile des neuen DatenBlocks bleibt unverandert, nur die weiteren Zeilen werden um einige stellenverschoben. Dabei wird dir zweite Zeile um eine Stelle, die dritte um zwei unddie vierte Zeile um drei Stellen verschoben, bei einem Zeilenuberlauf wird dieZeile von rechts fortgesetzt [19, 20].

2.4.4 MixColumn

Nach Verschiebung der Zeilen werden die Spalten verschoben. Im Vergleich zuder Zeilenverschiebung ist MixColumn wesentlich komplexer. Bei MixColumnwird ein komplexes mathematisches Verfahren, das Galois-Feld angewendet.im Rahmen dieser Bachelorarbeit werden keine vertieften Definitionen undErklarungen zu diesem Verfahren gegeben, sondern nur die Grundideevon MixColumn zusammengefasst. Alle Eintrage der Spalten werden mitKonstanten multipliziert, bei der Multiplikation handelt es sich jedoch nichtum das gewohnliche Multiplizieren von Zahlen, sondern es handelt sich umeine Polynom-Multiplikation. Nach der Multiplikation werden die Ergebnissejeder Spalte mit XOR verknupft und an der entsprechende Stelle des neuen


Abbildung 2.5: AES Operation ShiftRows. Jeder Zeilen Eintrag wird nachlinks verschoben. Dabei bleibt die erste Zeile unverandert. Alle anderen Zeilenwerden folgendermaßen verschoben, zweite Zeile um eins, die dritte um zwei unddie vierte um drei [19].

Datenblocks eingetragen. Fur die nachsten Spalten wird die Reihenfolge derKonstanten geandert, welche je nach Stelle im neuen Datenblock festgelegtwird. Nachdem alle Zellen des neuen Datenblocks gefullt sind ist das VerfahrenMixColumn abgeschlossen [19, 20].

2.4.5 Key Schedule

Um das ganze Verschlusselungsverfahren auszufuhren mussen noch dieSubschlussel generiert werden. Daher braucht man Key Scheduling, um denSchlussel fur Verschlusselung und Entschlusselung der Daten zu berechnen.Dazu dient ein Userschlussel, der sich als 128-Bit im Cipher-Block befindet.Dieser wird erweitert, so dass er auf die Runden(ein Durchlauf des Algorith-muses) aufgeteilt wird. Die Anzahl der Subschlussel hangt dann davon ab, wieviele Runden man braucht. Je nach Bit-Große des Datenblocks (10,12 oder 14)wird die Anzahl der Subschlussel bestimmt. Jede Runde erhalt somit einenSubschlussel der jeweils 16 Byte groß ist. Um den Userschlussel zu erweiternwerden zwei Funktionen (SubWord,RotWord) und eine Konstante (Rcon)angewendet. SubWord hat dieselbe Funktion wie SubBytes und zwar wirddurch SubWord jede Zelle des Userschlussels(Cipher-Block) durch einen Wertaus der Substitutionstabelle ersetzt. Die zweite Funktion RotWord verschiebtdie Spaltenwerte um eins nach oben. Zuletzt wird Rcon auf die Spalten desCipher-Blocks angewendet. Rcon ist eine 4 Byte große Konstante, die auf daserste Byte der aktuellen Spalte angewendet wird. Jede neue Spalte die Rconliefert, wird dann mit der vorherigen Spalte(Orange in Abbildung 2.6) durchXOR verknupft. Nun zu genauerem Ablauf der Schlusselerweiterung, die


Abbildung 2.6: AES Operation Key Schedule. Fur die Berechnung der erstenSpalte des neuen Cipherblocks wird die erste Spalte des alten Cipherblocks(blau)durch XOR mit letzten Spalte verknupft. Die erste Spalte bleibt unverandert aufdie letzte Spalte im Cpherblock wird zuerst RotWord und anschließend SubWordangewandt. Das Ergebnis aus der XOR-Verknufung wird mir einer KonstanteRcon einletztes Mal mit XOR verknupft [19].

Berechnung der ersten Spalte des neuen Cipher-Blocks erfolgt im Vergleich zuder Berechnung der zweiten und dritten Spalten anders. Um die erste Spaltedes neuen Cipher-Blocks zu berechnen, benotigt man die erste Spalte und dieletzte Spalte des alten Cipher-Blocks. Die erste Spalte bleibt unverandert.Auf die letzte Spalte wird die Funktion RotWord angewand. Die Spalte,auf der die Funktion RotWord angewendet wurde, werden anschließend mitSubWord substituiert. Als nachstes wird die neu erzeugte Spalte und dieerste Spalte des alten Datenblocks mit XOR verknupft (siehe Abbildung 2.6).Das Ergebnis dieser XOR-Verknupfung wird zuletzt mit der Spalte, dieRcon liefert, wieder mit XOR verknupft. Das Resultat ist die erste Spaltedes ersten Subschlussels. Fur die nachsten Spalten wird immer eine Spaltedes alten Cipher-Blocks und der vorherigen Spalte im Subschlussel durchXOR verknupft und das Ergebnis ist die neue Spalte des Subschlussels. Dieswird solange durchgefuhrt bis dann alle Subschlussel generiert wurden [19, 20].


2.4.6 Entschlusselung

Die Entschlusselung ist der Verschlusselung sehr ahnlich, jedoch wird derAlgorithmus ruckwarts durchgefuhrt. Dennoch gibt es kleinere Unterschiede.Bei der Funktion SubBytes wird im Vergleich zur der Verschlusselung eineandere Substitutionstabelle angewand, die aus der Substitutionstabelle derVerschlusselung berechnet wird. Bei der Zeilenverschiebung (ShiftRow) wer-den die Zeilen nicht nach links, sondern rechts verschoben. Die Subschlusselwerden dann vom letzten beginnend bis zum ersten Subschlussel, fur dasEntschlusseln eingesetzt [19, 20].


Kapitel 3

Entwicklung der Demoversion

3.1 Das Ziel und die Grundideen

Am Ende dieser Arbeit wird sich ein User mit Name und Passwort und demeKaay Schlussel in sein Account einloggen konnen. Der versteckte Inhalt sollvor dem Login fur Dritte nicht sichtbar sein. Dabei soll Username und Pass-wort auf Richtigkeit uberpruft werden, ohne dass das Passwort an den Servergeschickt wird. Wie auch in anderen Portalen wird das Passwort nur gehas-ht auf dem Server liegen. Um die mogliche Angriffe abzublocken wird demgehashten Passwort ein Salt angehangt. In den Kapiteln 3.2- 3.5 werden al-le Funktionen und Methoden beschrieben, die fur Demoversion ohne eKaay-Verfahren benotigt werden. Das Anlegen eines Textfeldes dient zur Bearbei-

Abbildung 3.1: Kommunikation zwischen Server und Browser.Login mit User-namen und Passwort, der Datentransfer erfolgt uber Ajax. Ajax ermoglicht eineasychrone Datenubertragung zwischen Server und Client so konnen nebenherandere Prozesse bearbeitet werden solange auf Response vom Server gewartetwird [21].

tung und zum Aufruf der Datei. Speichern und Offnen der Datei wird durch

13

14 KAPITEL 3. ENTWICKLUNG DER DEMOVERSION

Buttons gesteuert. Dabei wird der Inhalt der Dateien nur verschlusselt ausdem Server abgelegt und erst dann wieder bei Anfrage des Clients auf demBrowser entschlusselt. Der abgespeicherte neue Text wird auf dem Browserverschlusselt bevor der Text an den Sever gelangt. Zuletzt wird das Login mitdem eKaay-Verfahren erweitert, so dass Handy und Passwort fur das Logineingesetzt werden.

Abbildung 3.2: Smartphone als dritte Komponente im Login, Handy scnanntden vom Server erstellten QR-Code auf. Handy schickt Token(Schlussel auf demHandy) und Codewort an Server.Ist der User bekannt wird eine Verbindung zumBrowser hergestellt und der User wird zur nachsten Seite weitergeleitet [21].

3.2 Layout mit HTML erstellen

Fur die Anwendung werden drei Webseiten erstellt. Auf der ersten HTML-Seitewird nur ein 2D-Code zusehen sein(index.php). Auf der zweiten Seite wird einFormular erstellt, in dem der User seinen Passwort eintragt mit dem die Datenver- und entschlusselt werden(indexzwei.php). Auf der letzten Webseite kannder User seine Daten bearbeiten und speichern. Die einzelnen Details der Web-seiten werden nun naher beschrieben. Alle Webseiten sollen denselben Hinter-grund haben. Dieser in der CSS-Datei style.css definiert wird(siehe Abbil-dung 3.3). Damit die Webseite alle Formatierungen der Elemente ubernimmt,wird die CSS-Datei angebunden (Abbildung 3.4).

3.3. LOGIN OHNE EKAAY 15

Abbildung 3.3: Definition der Hintergrundformatierung. Fur den Hintergrundder Seite wird ein JPG-Bilddatei wolke nr 7.jpg. Große vom Hintergrund wirdder Bilschirmgroße angepasst [22].

Abbildung 3.4: Einbetten des CSS-Stylesheets. Stylesheet wird mit <link>-Tag im <head>-Bereich der Seite eingefugt. So werden alle Formatierungen desStylesheets auf der HTML-seite angewandt.

Der 2D-Code auf der Webseite index.php wird mittig auf der Seite plat-ziert. Dazu werden die Definitionen in der CSS-Datei benotigt siehe Abbil-dung 3.6. Damit der 2D-Code uberhaupt auf der Webseite sichtbar ist, wirddieser als <iframe> eingefugt siehe Abbildung 3.5. Auf der zweiten Webseiteindexzwei.php wird ein Formular mit Input-Tags erstellt damit der User sei-nen Passwort eingeben kann Abbildung 3.7. Um die Daten abzuschicken wirdein Button erstellt, der dann JScript Funktionen ausfuhrt, wenn man diesenanklickt. Das Formular und der Button werden in einer Box mit einem grunenRand platziert zusatzlich wird ein Schatten um die Box erzeugt Abbildung 3.8. Die letzte Webseite cloud.php, wird eine Textarea mittig angelegt. In derAbbildung 3.10 ist zu sehen wie die HTML-Elemente erzeugt weden, so dasder User seine Daten lesen bearbeiten und abspeichern kann, dazu werden diebenotigten Formatierungen in der CSS-Datei definiert und die Textarea in dercloud.php Datei angelegt. Um die Daten in der Textarea zu verwalten wer-den zwei Buttons erstellt mit denen die JScript Funktionen ausgefuhrt werdenkonnen (siehe Abbildung 3.9).

3.3 Login ohne Ekaay

Nachdem in Kapitel 3.2 beschrieben wurde, wie eine Login Seite erstellt werdenkann, wird nun erlautert, wie die Richtigkeit der Userdaten verglichen werden.Zuerst mussen die Zeilen des Formulars ausgelesen werden. Da diese mit der


Abbildung 3.5: Einbetten des 2D Codes. Der 2D-Code wird mit einem<iframe>-Tag im <body> der HTML-Seite eingefugt. Der Server berechnetden 2D-Code dieser wird durch das einbetten des IFrames im Body der Seiteangezeigt.

Abbildung 3.6: Platzierung des 2D Codes. 2D-Code wird der Fenstergroßeabsolut angepasst. Hohe und Breite werden so gewahlt das der 2D-Code mittigeingefugt wird. Die Formatierungen wird fur die Element mit der id=iframe aufder HTML-Seite angewendet

POST-Funktion an die PHP-Datei cloud.php gesendet wurden, konnen dieseAngaben mit den Eintragen aus dem Server auf Richtigkeit uberpruft werden.Dazu wird in der cloud.php Datei eine PHP-Funktion geschrieben, die die Ab-frage durchfuhrt.Dabei ist es sehr wichtig, dass das vom User eingegebene Passwort keines fallsfur die Abfrage in einen nicht gehashtem Zustand an den Server gesendet wird.Das Ziel ist es immer, das Einsehen des Passwortes durch Dritte zu vermei-den. Um die Abfrage durchzufuhren werden Informationen vom Server zumUsernamen und zum Passwort, das gehasht auf dem Server liegt, angefordert.Wurde das Passwort nicht gehasht auf dem Server liegen, ware es fur Hackerein Kinderspiel aus dem Response des Servers das Passwort abzufangen. Des-halb darf das Passwort nicht im Original auf dem Server aufbewahrt werden[23, 24, 25]. Ist die if-Abfrage(siehe Abbildung 3.11) True so soll der versteckteInhalt der Seite angezeigt werden.

Falls das Passwort oder der Username falsch und somit die if-Abfrage zufalse evaluiiert, soll eine andere PHP-Seite aufgerufen werden, die fur den Usersichtbar ist (schutz.inc.php). Des Weiteren wird dem User mitgeteilt dassein Login-Versuch fehlgeschlagen ist (siehe Abbildung 3.12).


Abbildung 3.7: Formular fur das Login erstellen. In <form> werden die<input>-Bereiche angeleg in die der User seine Daten eintragen kann. Zusatzlichwird die Seite definiert in der die Fromulardaten bearbeitet werden, wenn dasFormular abgeschickt wird.

Abbildung 3.8: Formular wird in Box platziert. Durch die Formatierung solldas Formular hervorgehoben werden. Um das Formular herum, wird in eine grunumrahmte Box erstellt.

Das Passwort wir nach dem Submitten ungehasht an den Server geschicktund dort mit dem MD5-Algorithmus, das in der PHP-Libarey enthalten ist, ge-hasht. Der Hashwert des eingegebenen Passwortes ist dann mit dem Hashwertauf dem Server identisch. MD5 ist fur einfache Passworter nicht mehr sicher.Das Passwort kann mit sogenannten Regenbogentabellen regeneriert werden.Es existieren schon zahlreiche Regenbogentabellen fur Hashwerte. Damit derUser von solchen Angriffen geschutzt ist, wird das Passwort nicht allein ge-hasht, sondern es wird ein Salt angehangt. Der Vorteil ein Salt zu benutzenliegt darin, dass das Passwort aus mehreren Zeichen besteht und somit eineBerechnung einer Regenbogentabelle enorme Berechnungszeiten brauchen, umdas Urbild wieder zu erstellen. Um eine Regenbogentabelle fur ein Passwortder Lange sechs zu berechnen, wird fur jede der sechs Stellen gepruft, ob dieZeichen von A-Z, a-z oder 0 − 9 an dieser Stelle vorkommen. Klein und Groß-schreibung wird beim Hashen mit MD5 beachtet, deshalb genugt es nicht nur


Abbildung 3.9: Speichern und Lesefunktion.”Rufe Datei“-Button soll eine

Funktion ausfuhren, die den Inhalt der Datei vom Server liest.“Speicher“-Buttonfuhrt die Funktion aus die den Inhalt im Textfeld in die Datei auf dem Serverschreibt.

Abbildung 3.10: Formatierung des Textfeldes. Der Textfeld wird im <body>-Bereich der Seite eingefugt. Mit der Formatierung wird das Textfeld mittig aufder Seite platziert.

nach Kleinbuchstaben oder nur nach Großbuchstaben zu suchen [26, 8, 27].Bei einem einfachen Beispiel wird in Abbildung 3.13 auch deutlich, wieso dieUberprufung wichtig ist. Nimmt man zwei Worter bei dem nur ein Buchstabegroß geschrieben wird und hasht beide Worter.

Wie in dem Beispiel zusehen ist, entstehen zwei komplett unterschiedli-che Hashwerte, daher muss Klein-und Großschreibung beim Berechnen be-achtet werden, sonst erhalt man nicht das richtige Urbild. Man hat bei ei-ner einfachen Regenbogentabelle fur ein Passwort der Lange sechs und 64Zeichen insgesamt 646 Moglichkeiten, d.h. umso langer das Passwort, destolanger die Berechnung und desto großer der zu Berechnung benotigter Spei-cher. Eine andere Moglichkeit ware mehrmalige hintereinander Anwendungdes MD5-Algorithmus oder eine Kombination anderer Hash Algorithmen. Allediese Moglichkeiten sind keine sichere Losung, das Passwort vor Hackern zuschutzen [6, 7, 8]. Ein Hacker wird erstmals alle einfachen Passwort Kombi-nationen bspw. 1234, 1111, aaaa usw. mit der Brute-Force Methode durch-probieren. Anschließend werden alle moglichen Kombinationen der bekanntenHash-Algorithmen ausprobiert, so ist diese Losungsmoglichkeit weniger sinn-voll.

Aus den oben genannten Grunden, wird das Passwort mit einem Salt er-weitert. Der User ist auf dieser Art und Weise frei ein beliebiges Passwort zuwahlen und bekommt von dieser Anderung nichts mit. Ein Salt ist ein Pass-wortzusatz, der dem User unbekannt ist. Der Vorteil, einen Salt zu benutzenist, dass dadurch die Lange des Passwortes zunimmt und es schwierig ist, da-zugehorige Regenbogentabellen zu erstellen, weil enorme Großen an Speicher


Abbildung 3.11: Die Daten die von dem Formular auf der Seiteindexzwei.php gesendet werden, mussen mit den Eintragen auf dem Serveruberpruft werden, denn nur bei erfolgreichen Uberprufung kann der User Inhaltder cloud.php Seite sehen.

Abbildung 3.12: Schutzfunktion bei Fehl-Login. Die Datei Funktion verhin-dert es, dass die Seite cloud.php bei einem fehlgeschlagenen Login-Versuchaufgerufen werden kann.

und Rechnungsschritte benotigt werden. Zu dem weiß der Angreifer nicht, woder Salt beginnt und wie er in dem Passwort eingebaut wurde dies erschwertdem Angreifer passende Regenbogentabellen zu konstruieren. Diese Schutz-maßnahmen werden auch von Linux und Microsoft benutzt, um die Passwortervor Regenbogentabellen zu schutzen. Linux koppelt den Usernamen mit demPasswort, wodurch dient der gehashte Username als Salt dient. Um nun dieSicherheit auch fur den User der Demoversion zu erhohen, wird der Usernamegehasht an das Passwort dran gehangt und spater als Schlussel fur die Ver-schlusselung und Entschlusselung der Daten verwendet.Der User gibt wie gewohnt seinen Usernamen und Passwort ein, als erstesmussen Passwort und der Username gehasht werden. Der Salt kann hinteroder vor das Passwort angehangt werden. Eine weitere Moglichkeit ist, dasszwischendurch irgendwelche Sonderzeichen hinzugefugt werden konnen . Wiedas Passwort mit Salt aussieht ist dem Programmierer uberlassen. Je mehr anden Hashwerten verandert wird, desto schwieriger wird es die Passworter zu-regenerieren. Fur die Demoversion wird der Username hinten an das Passwortangeknupft und der Username wird mit dem MD5-Algorithmus gehasht. D.h.angenommen das Passwort ist

”Cloud“ und der Username

”User1“, dann sieht

das geSaltene Passwort wie folgt aus:

Das Passwort ist jetzt vor Regenbogentabellen geschutzt. Als letztes soll


Abbildung 3.13: MD5 Hashing. Das Beispiel zeigt, dass der MD5-Algorithmusfur Worter, die sich nur in ihrem Anfangs Buchstaben unterscheiden ein kom-plett anderer Haswert erzeugt wird.

Abbildung 3.14: Einfugen vom Salt. Der verlangerte Passwort wird durchKonkatenation vom gehashte Usernamen und dem gehashten Passwort generiert.

das Passwort mit einer Java-Funktion gehasht werden bevor das Passwort mitden Formulardaten an die PHP-Datei cloud.php weitergeleitet wird, um dieEingabe mit dem Hashwert verglichen werden. Wenn das Passwort ungehashtan den Server geschickt wird und erst dort der Hashwert generiert wird, so istdas Passwort kurzzeitig fur Angreifer sichtbar.Aus diesem Grund ist es vorteilhaft eine Java-Funktion anzuwenden, diedas Passwort hasht, sobald der Login Button betatigt wird. Die FunktionHashpswrd() soll Salt und Passwort zusammensetzten und diese dann mit demMD5-Algorithmus hashen(siehe Abbildung 3.15). Um den MD5-Algorithmusanwenden zu konnen wird die JScript Datei md5.js [28] an die HTML-Seiteangebunden [29].

Abbildung 3.15: Hashpswrd()-Funktion. Die Funktion hasht Usernamen undPasswort und Konkateniert die Hashwerte bevor die Eintage auf den Servergesendet werden.

Das Login Verfahren ist mit diesen Verbesserungen sicher einsetzbar.

3.4. DATENINHALT ABRUFEN 21

3.4 Dateninhalt abrufen

In Kapitel 3.3 wurde ausfuhrlich erlautert wie das Login-Verfahren durch-gefuhrt wird. Nach einem erfolgreichen Login-Versuch erscheint eine Seite,in der sich ein Textfeld befindet, in dem man abgerufenen Dateiinhalt lesen,bearbeiten und wieder abspeichern kann. In diesem Abschnitt, wird erstmalsdas Verfahren erlautert wie der Inhalt der Datei aufgerufen wird. Wie inder Einleitung erwahnt, wird das Passwort mit MD5 gehasht und der Inhaltder Datei mit dem AES-Verfahren ver- und entschlusselt. Details zu demAES-Algorithmus wurden in Kapitel 2.4 beschrieben.Um eine Datei abrufen zu konnen muss zuerst eine Datei erstellt werden undauf dem Server gespeichert sein. Da eine Demoversion entwickelt wird, wirdnur eine Datei angelegt. Der User kann danach mit zwei Buttons Dateiinhaltabrufen oder Anderungen abspeichern. Wie genau das Abspeichern funktio-niert und was dazu benotigt wird, ist in Kapitel 3.5 erlautert. Das Textfeldauf der Web-Seite ist die Arbeitsflache fur den User, wenn der User nun eineDatei lesen will, muss er den Button

”Rufe Datei“ anklicken.

Zunachst muss die Datei geoffnet und der Inhalt gelesen werden. Da derInhalt ein verschlusselter Text ist, muss dieser Text auch wieder entschlusseltwerden. Es besteht die Moglichkeit, einen PHP-Code zu schreiben, um denInhalt der Datei zu lesen und zu entschlusseln. PHP-Funktionen werdenimmer auf dem Server ausgefuhrt, wodurch das das Risiko besteht, dass einAngreifer den entschlusselten Dateninhalt wahrend der Ubertragung vomServer zum Client den Inhalt verandern oder lesen kann. Der User ist sonicht vor Datenspionage geschutzt. Daher werden wie in Kapitel 3.1 bereitserwahnt, die Daten nur auf dem Browser ent- und verschlusselt.

Fur den Datentransfer zwischen Server und Client wird XMLHTTP-Request (XHR) angewandt. XHR ermoglicht, dass beliebige Daten uber dashttp-Protokoll ubertragen werden konnen. Daten konnen vom Webserverabgerufen werden, ohne dass die Webseite neugeladen werden muss. AlleAnfragen werden asynchron bearbeitet. D.h. das Skript kann gleichzeitig meh-rere Anfragen bearbeiten, ohne dass auf die Ruckmeldung von einer einzigenAnfrage gewartet werden muss, damit das Skript weiterarbeiten kann. Damitjeder Browser mit einem XMLHTTP-Request arbeiten kann, muss noch einJavaScript xmlhttp.js erstellt werden, die eine Funktion enthalt, in der furjeden Browser der passende Befehl aufgefuhrt wird, um ein neues XHR zuerzeugen [30]. Mit einer einfachen if-Abfrage kann der Browsertyp, der vomUser genutzt wird, bestimmt werden(siehe Abbildung 3.16). Das richtige XHRElement kann so erzeugt werden,so dass keine Probleme auftreten, wenn derUser unterschiedliche Browser verwendet [31].


Abbildung 3.16: Erzeugen von XML-Objekten. Mit dieser JavaScript Funkti-on kann fur jeden Browser XML-Objekt erzeugt werden.

Nun kann XHR problemlos angewendet werden, um Daten uber das HTTP-Protokoll zu ubertragen. Um die Datei auszulesen, muss diese erstmals geoffnetwerden und der komplette Inhalt bis auf die letzte Zeile ausgelesen werden. DesWeiteren werden Java-Funktionen benotigt, um die Daten fur den User sicht-bar zu machen.Mit der Funktion open(), die fur XHR-Objekte in der JavaScript-Bibliothekintegriert ist, wird die Datei geoffnet. Der Funktion mussen drei Parameterubergeben werden. Der erste Parameter bestimmt, ob die Daten gesendet odergeholt werden, da die Daten an den Browser geschickt werden sollen wird derParameter auf GET gesetzt. Als nachstes muss der Pfad der Datei angegebenwerden. Der letzte Parameter bestimmt, ob es sich um ein asynchrones odersynchrones Verfahren handelt. Da XHR asynchron arbeitet, wird der Parame-ter auf true gesetzt. Wenn die Datei erfolgreich geoffnet und der Inhalt gelesenwurde, soll durch ein weiteres Event xhr.onreadystatechange die FunktiongibDateiAus() angeben, die den Inhalt der Datei in das Textfeld einfugt.Onreadystatechange fuhrt dann die Funktion gibDateiAus() immer dannaus, wenn sich der readyState des XHR andert. Der readyState durchlauftinsgesamt funf Zustande die von 0-4 nummeriert sind. In folgender Tabelle 3.1wird die Bedeutung der Zustande erlautert.

Tabelle 3.1: Zustands-Tabelle XMLRequest

Zustand Prozessstatus

0 Anfrage noch nicht initialisiert1 Verbindung mit Server aufgebaut2 Anfrage an Server angekommen3 Anfrage wird vom Server bearbeitet4 Antwort ist am Client angekommen

Beim Lesen der Datei werden vom Client keine Daten an den Server ge-schickt. Deshalb wird der Parameter der Funktion send() auf

”null“ gesetzt.

3.5. DATEN BEARBEITEN UND SPEICHERN 23

Der Handler rufeDateiAusServer() fur Dateiaufrufe ist somit vollstandig.Nun muss in der schon oben genannten Funktion gibDateiAus() gepruftwerden, ob der responseText schon bereitgestellt ist. Aus der Zustandsta-belle ist zu sehen, dass der Request dann beendet ist, wenn der Zustandvier ist. D.h. der Text aus der Datei ist vollstandig am Client angekommen.responseText enthalt dann die Antwort des Servers als String. Der Stringmuss entschlusselt werden, damit der Text fur den User lesbar ist. Um denAES-Algorithmus anwenden zu konnen wird, der Datei cloud.php mit einemscript-Tag als JavaScript-Datei(aes.js) [32] angehangt. Nach Verknupfung kannman den responseText mit der Funktion decrypt(text,passwort,nBit) ent-schlusseln.

Tabelle 3.2: Parameter fur decrycpt-und encrypt Funktion

Parameter Typ

text Klartext bei der Funktion encrypt undverschlusselte Text bei der Funktion decrypt

passwort Userpasswort die in indexzwei.php eingegeben wirdnBit Bestimmt wie groß die Datenblock sein sollen

Nun liegt der originale Inhalt der Datei vor und mussnoch in das Textfeld eingefugt werden. Die JavaScript Funktiondocument.getElementByName(

"textarea\) wahlt das Taxtfeld aus und

fugt mithilfe von innerHTML den gewunschten Inhalt in das Textfeld ein. AmEnde ist der entschlusselte Text im Textfeld der Seite eingefugt und es konnenUserseitige anderungen vorgenommen werden.

3.5 Daten bearbeiten und speichern

Der User hat sich eingeloggt und sein Passwort das fur die Verschlusselungund Entschlusselung benotigt wird eingeben. Auf dem Browser ist nun fur denUser ein Textfeld und zwei Buttons zu sehen mit denen er den Inhalt der Da-tei aufrufen oder die Veranderung abspeichern kann (siehe Abbildung 3.18).Damit der User diese Funktionen betatigen kann, mussen diese erst erstelltwerden. In Kapitel 3.4 werden die Funktionen eingefuhrt, die fur den Daten-aufruf zustandig sind.

In diesem Kapitel werden der Prozess und die Funktion beschrieben,die zum Speichern der neuen oder veranderten Daten benotigt werden. Zu-erst muss die Datei daten.txt geoffnet werden. Im Gegensatz zum Abrufender Daten wird fur das Speichern nicht die GET-Methode sondern die POST-Methode angewendet. Die Funktion open() wird mit den Parametern POST,


Abbildung 3.17: Einlesen und Ausgabe des Datei-Inhalts. Daten werdenmit der Funktion rufeDateiAusServer() eingelesen und durch die FunktiongibDatenAus() in das Texfeld geschrieben. Der User kann seine Datei im Text-feld bearbeiten.

save.php und true aufgerufen. Als zweite Parameter wird die Datei ange-geben, die dann uber einen PHP-Code die Datei daten.txt offnet und denInhalt abspeichert. Damit der Server Informationen uber den Sender, alsoden Client erhalt, werden mit der Methode sendRequestHeader() die Infor-mationen erstellt und spater mit dem der Methode send() an den Serverubermittelt. Die Information die dem Server ubermittelt wird, ist der Text,der in die Datei daten.txt geschrieben werden soll. Um den Inhalt speichernzu konnen, muss dieser zuerst aus dem Textfeld gelesen werden. Die Funkti-on document.getElementById(

"textarea\).value gibt den Text im Text-

feld aus, welcher dann unter einer Variable abgespeichert wird(currenValue).Nach dem der Text unter der Variable currentValue abgespeichert wurde,wird uberpruft, ob sich der Inhalt geandert hat, um unnotige Funktionsauf-rufe zu ersparen. Dazu wird eine if-Abfrage erstellt in dem der responseTextmit der currentValue auf Gleichheit gepruft wird. Wenn die Abfrage false er-gibt, soll currentValue in die Datei daten.txt geschrieben werden, falls dieIf-Abfrage true ergibt, so soll die Meldung erscheinen, dass der Dateninhaltnicht verandert wurde. Evaluiert die if-Abfrage zu false, so wird die Variableergebnis auf currentValue gesetzt. Der Inhalt der Variable ergebnis wirddann verschlusselt und unter der Variable encrypt abgespeichert. Nun kannder verschlusselte Text mit der Funktion xhr.send("text="+encrypt) ver-schickt werden.Der Text wird dann mit den Funktionen der PHP-Datei save.php in die Dateidaten.txt geschrieben. Die Datei save.php pruft ob die $ POST[’text’] gesetzt

3.6. LOGIN MIT EKAAY 25

Abbildung 3.18: Implementierte Arbeitsflache. Der User kann im TextfeldTexte editieren und speichern. Betatigt der User die Buttons werden JavaScriptFunktionen ausgefuhrt.

ist und offnet dann die Datei daten.txt, um zu schreiben. Falls die Datei nichtgeoffnet werden kann erhalt der User die Fehlermeldung Datei wurde nichtgeoffnet!.Ist die Datei nun erfolgreich geoffnet wird der Text mit der php-Funktionfwrite($fp,’text’) in die Datei daten.txt gespeichert [33, 34, 24, 23, 35, 36,37].

3.6 Login mit eKaay

Damit das Login-Verfahren mit dem eKaay-Verfahren gekoppelt werdenkann,mussen samtliche Anderungen vorgenommen werden. Damit das Loginuber Handy uberhaupt funktioniert, muss der User Account auf dem eKaay-Server angemeldet bzw. registriert sein. Zur Registrierung wird die App fureKaay heruntergeladen. Diese kann von Smartphones mit Android und IOSSystemen angewendet werden. Als Nachstes muss der Account auf das Handyund dem eKaay-Server gespeichert werden. Dazu wird ein 2D-Code gescannt,der fur die Aktivierung des User-Accounts benotigt wird.Durch das Scannen werden die Daten auf dem eKaay-Server uberpruft(siehe

Abbildung3.22). Wenn der User mit diesem Handy schon auf dem eKaay-Server registriert ist, wird der User auf die nachste Webseite weitergeleitet, dieUberprufung erfolgt in der PHP-Datei indexzwei.php.

Die Webseite indexzwei.php ist fur User, die nicht auf dem eKaay-Serverregistriert sind, nicht sichtbar. Somit kann kein unbefugter User den Inhaltder indexzwei.php Webseite einsehen.


Abbildung 3.19: AES Verschlusselung.Daten aus dem Textfeld werden mit derFunktion speichern() ausgelesen und verschlusselt. Durch die PHP-Funktionin der Datei save.php wird der verschlusselte Text in der Datei gespeichert.

Abbildung 3.20: Aktivierungcode. Der User muss uber die eKaay-App denAktivierungscode scnannen, um das eKaay-Verfahren fur die Demoversion nut-zen zu konnen.

Wie schon erwahnt wurde, braucht man eine Uberprufung der User-Daten.Dazu werden User-Name und Token auf Richtigkeit uberpruft. Der Token istder Schlussel der auf den Handy des Users gespeichert ist und zu Identifizie-rung mit dem User Namen an den eKaay-Server geschickt wird.Wie in Abbildung 3.22 zu sehen ist, wird uber eine cURL-Session das Ergebnisder Uberprufung auf dem eKaay-Server, unter der Variable $res gespeichert.Nun muss uberpruft werden, ob der eKaay-Server ein OK gesendet hat, denndann sind die Userdaten richtig und der User kann den Inhalt der PHP-Seitesehen. Ist die Nachricht vom Server= OK, so wird das Formular erstellt indem der User seinen Verschlusselungspasswort eingeben kann(siehe Abbil-dung 3.21(b)). Der Token wird bei jeder Serverkontaktierung auf Richtigkeituberpruft. Wird der Token bei jeder Anfrage an den Server gepruft, so kannein Hacker die geoffnete Session nicht klauen. Denn er kennt den Token nicht

3.6. LOGIN MIT EKAAY 27

[9].

(a) Ansicht der Seite index.php zeigt den2D-Code an der vom User uber die Appgescannt werden muss.

(b) Ansicht der Seite indexzwei.php zeigtdas Formular an in dem der User seinenPasswort eintragt. Der Userpasswort wird alsSchlussel im AES-Verfahren benutzt.

Abbildung 3.21: Ansicht der index-Seiten

Abbildung 3.22: Der User wird nur dann auf die indexzwei.php Seite weiter-geleitet, wenn Username und Token dem eKaay-Server bekannt sind. Ansonstensoll der Inhalt der Seite nicht zusehen sein.


Kapitel 4

Sicherheitsanalyse

Die Login Verfahren und Anwendungen werden immer weiter entwickelt, wobeiist die Sicherheit und der Datenschutz auf hochste Prioritat sind. Doch nichtnur die Anwendungen werden sicherer, sondern die Angriffe auf die PCs, Smart-phones, Clients und Servern werden immer wieder weiterentwickelt, sodass im-mer mehr Schadsoftware und Hackerangriffe Nutzerdaten im Web bedrohen. Indiesem Kapitel werden Sicherheitsaspekte und Losungen von Sicherheitspro-blemen erlautert, die fur die Demoversion angewendet wurden. Zunachst wirddas Login-Verfahren uber Passwort dem eKaay-Verfahren gegenubergestellt.Es werden mogliche Angriffe und Sicherheitsaspekte, mit denen die einzelnenVerfahren versuchen sich vor Gefahren zu schutzen, diskutiert.

4.1 Passwort versus eKaay

Ein vorerst harmloser Link, seriose Webseiten oder E-Mails konnen verseuchtsein. Ein bekannter Angriff ist das Trojanische Pferd. Es werden Schadpro-gramme im Hintergrund ausgefuhrt, ohne dass der User es mitbekommt. DieseProgramme sind meist als wichtige Daten getarnt, sodass Virenprogrammeauch sehr schwer den Angriff bemerken. Das Ziel ist, Passworter oder wichtigeDaten, abzuhoren. Nimmt man an, dass der PC des Users mit einem Trojanerinfiziert ist bspw. mit einem Keylogger, so kann der Hacker alle Tastaturein-gaben des Users ablesen. D.h., loggt sich der User in einer seiner Accounts ein,so kann der Hacker das Passwort uber sein eingeschleustes Schadprogrammablesen. Doch, wenn das Passwort nicht eingegeben werden muss so kann derHacker das Passwort nicht auslesen. Da bei dem eKaay Verfahren es nichtnotig ist das Passwort fur das einloggen einzugeben, kann dieser auch nicht vondem Hacker ausgelesen werden. Der Accountschlussel fur eKaay ist nicht aufdem PC des Users abgespeichert und da der Schlusselaustausch nur zwischenHandy und dem Server ablauft, kann der Hacker uber einen Keylogger nichtan das Passwort gelangen. Also ist bei einem Angriff mit Keylogger der User

29

30 KAPITEL 4. SICHERHEITSANALYSE

mit dem eKaay vor Identitats-Diebstahl dieser Art geschutzt.Des Weiteren sind Angriffe wie Dictionary Attack oder Server-Datenleck furdas eKaay Verfahren keine Gefahr. Dictionary Attack ist eine Art HackerAngriff, in dem der Hacker durch Brute-Force standardisierte Passworterdurch wiederholte Eingabe das Passwort knacken kann. Da eKaay keinePassworteingabe benotigt, hat dieser Angriff keine Auswirkungen fur deneKaay User.Es werden nicht nur PCs von Hacker angegriffen, sondern auch die Serverstellen ein Angriffsziel dar. Webportale speichern die Passworter auf ihremWebserver ab. In meisten Fallen liegt das Passwort gehasht auf dem Server,jedoch gibt es schon Verfahren die auch gehashte Passworter wiedergenerierenkonnen. Bei einem Passwort das mit MD5 gehasht wurde konnen kurzeund einfache Passworter wie bereits in Kapitel 3.3 erwahnt, wurde mitRegenbogentabellen regeneriert werden.Was der User nun dagegen unternehmen kann ist, dass er ein sehr komplexesund langes Passwort generiert so dass bei einem Angriff es fur den Hackerfast unmoglich ist das Passwort wieder zu generieren, denn fur das Loginmit eKaay muss der User nie wieder sein Passwort eingeben. Ein anderesVerfahren, das Passwort zu verlangern, ist mit einem Passwortzusatz moglich,das auch fur die Demoversion angewendet wurde [17, 16, 38].

4.2 Gefahren fur eKaay

Jedoch hat das eKaay-Verfahren auch Nachteile. Es existieren im Netz Gefah-ren, bei denen das eKaay Verfahren keine Sicherheit gewahrleisten kann. DaseKaay Verfahren nutzt das Handy als Schlussel, doch Smartphones konnenauch von Malware befallen sein. Nimmt man nun an, dass das Smartpho-ne bspw. von Malware (Handy-Trojaner) befallen ist, konnen folgende Risi-ken entstehen. Der Schlusselaustausch zwischen Server und Smartphone istnicht mehr sicher, denn durch Malwarekonnen alle Informationen, die uberdas Smartphone laufen, ausgelesen werden. D.h., offnet der User seine eKaay-App und scannt den 2D-Code ein, so kann durch die Malware alle Ablaufevon der App mitverfolgt werden. Da man nicht davon ausgehen kann, dassdie Smartphones nie von Malware befallen sind, ist diese Art von Angriff einegroße Bedrohung fur die Identitat des Users. Bei einem solchen Angriff ist eskeine Losung den Schlussel verschlusselt abzuspeichern. Verschlusselt man denSchlussel, so wird dieser wieder auf dem Smartphone gespeichert. Das bedeutetnicht, dass die Malware das Passwort nicht aus dem Programmcode auslesenkann. Somit ist der User weiterhin wehrlos gegen die Malware [17, 16, 38].

Kapitel 5

Diskussion und Ausblick

5.1 Diskussion

Ziel der Arbeit war es eine sichere Datenhaltung in der Cloud via Handy zugewahrleisten. Dazu wurden Verschlusselungs Algorithmen, Hash-Algorithmenund das eKaay-Verfahren fur die Demoversion angewendet. Wie in Kapitel 4schon behandelt wurde, gibt es im Netz zahlreiche Gefahren, die ein sicheresLogin nicht ermoglichen. Deshalb musste man eine Losung finden, wie das miteinem anderen Verfahren optimiert werden kann. Bei manchen Hacker Angrif-fen ist das Passwort Verfahren nicht mehr sicher genug. In Kapitel 4.1 wurdePasswort und eKaay Verfahren gegenubergestellt und es ist mit eKaay moglichsamtliche Angriffe abzuwehren, bei denen das Passwort Verfahren versagt. Esist von Vorteil, das ekaay Verfahren fur das Login ein zu setzen. Fur die De-moversion wird jedoch das Userpasswort nicht auf dem Handy gespeichert.Denn ist das Passwort auf dem Handy gespeichert, so kann das Passwort vonMalware abgelesen werden. User, die nicht registriert sind, konnen die Demo-version nicht nutzen, denn um zur eigentlichen Anwendung zu gelangen, mussdie Challenge vom Server von der App aufgenommen werden. Ist dann dasToken, das vom Handy gesendet wird, dem Server bekannt, so wird bei demeKaay Vefahren auf der Demoversion nicht der User eingeloggt, sondern ermuss nun seinen Passwort eingeben. In Kapitell 4 wurde aber erklart wiesoman das Passwort nicht eingeben. Angenommen der Hacker hat das Passwortausgelesen und mochte sich mit diesem in dem Account einloggen. Es ist immernoch keine Bedrohung fur den User, denn der Hacker braucht das Handy, damiter uberhaupt die Seite sehen kann, der User aufgefordert wird, sein Passworteinzugeben. Denn ist der Token nicht richtig oder nicht vorhanden, so wird dieSeite indexzwei.php nicht geladen. Also kann der Hacker mit dem Passwortallein nichts anrichten.Erweitert man die Annahme, in dem man davon ausgeht, dass der Hacker ver-sucht, das Token zu klauen, wird der Hacker weiterhin keinen Erfolg haben.

31

32 KAPITEL 5. DISKUSSION UND AUSBLICK

Denn eKaay arbeitet mit einem 2-Kanal Verfahren, d.h. der Server erzeugt furjede Session einen 2D-Barcode, indem benotigte Informationen(Kapitel 2.2)codiert sind und erstellt so eine Challenge. Das Handy nimmt die Challengeauf und fuhrt die notwendigen Funktionen aus. Informationsaustausch erfolgtnun nicht uber einen Kanal sondern uber zwei. Der Server verbindet sich mitdem Browser und schickt die Challenge, das Handy sendet die Informationennicht uber den Browser sondern uber die eigene Internetverbindung direkt anden Server. Es ist fur den Hacker nicht moglich, beide Kanale abzuhoren. Soerhalt er nie die volle Informationen, sondern nur einen Teil und kann so denSchlussel nicht auslesen.Gelingt es dem Hacker, die Dateien vom User aus dem Server zu stehlen, sokann er an wichtige private Daten des Users gelangen. Fur die Demoversi-on wurde deshalb ein Verschlusselungsverfahren angewendet, damit nur derBesitzer des Passwortes den Klartext sehen kann. Ein Angreifer kann zudemversuchen, die Inhalte wahrend dem Datentransfer abzuhoren. Daher durfenDateiinhalte nicht unverschlusselt an den Server und auch nicht an den Brow-ser gelangen. Deshalb wird das Verschlusseln und Entschlusseln der Dateitextenur auf dem Browser ausgefuhrt. Somit wird vermeidet, dass der Server denKlartext auch nur kurzzeitig zu sehen bekommt. So erhalt der Angreifer immernur verschlusselte Klartexte und kann mit diesen nichts anfangen.Es ist moglich, dass die gehashten Passworter auf dem Server entwendet wer-den, um somit Schaden anzurichten, indem der Angreifer versucht das Passwortzu regenerieren. Doch auch dieser Versuch wird durch Massnahmen verhindert.Die Passworter in der Demoversion werden mit dem MD5-Algorithmus gehas-ht. In Kapitel 3.3wurde der Angriff erlautert in dem sognannte Regenbogen-tabellen berechnet werden, die dem Hacker Wiederherstellung des Passwortesermoglichen. Es sind zahlreiche Tabellen vorhanden, doch diese sind nutzlosbei langeren Passwortern. D.h., der User kann weiterhin sein Passwort einge-ben. Es wird jedoch, um die Sicherheit zu erhohen, ein fester Passwortzusatzgewahlt, womit wird die Regenerierung des Passwortes nicht nur erschwertsondern in absehbarer Rechenzeit nicht mehr moglich ist.Der User kann getauscht werden, indem der 2D-Code nicht auf den eigentlichenServer A gelenkt wird, sondern an einen anderen Server B. Falls der User aucheinen eKaay Login auf Server B hat, kann er bei einem erfolgreichen Login dieSession auf Server B stehlen. Um diese Gefahr abzuschwachen wurden Erwei-terungen an dem eKaay Verfahren vorgenommen, in denen der User vor demLogin bestatigen muss, ob er sich wirklich auf dem genannten Server einloggenmochte(Ask before Login). Angriffe wie Denial of Service und Trojaner, diedie Kontrolle uber den ganzen Server haben, sind immer noch eine Gefahr, daes bislang keine Losungen gibt.Neben den oben genannten Gefahren besteht immer das Risiko, dass der Usersein Handy verliert oder es geklaut wird. Ist das Handy geklaut, kann die Per-son, die im Besitz des Handys ist, sich in allen Accounts fur die der User ein

5.1. DISKUSSION 33

eKaay Login benutzt hat, einloggen.Denn ist das Handy geklaut oder verloren ist es fur den User nicht mehrmoglich die Anwendung zu nutzen, d.h. es gibt fur den User in der Demover-sion keine Moglichkeit sich mit Namen und Passwort einzutragen. Es wurdesicherheitstechnisch keinen Sinn machen, da es unter anderem das Ziel derDemoversion ist, das User ohne das Handy oder dem Token die Anwendungnicht nutzen konnen. Also sollten alternative Login-Verfahren ausgeschlossenwerden. Damit das einloggen fur Dritte nicht moglich ist, kann der User einePIN nutzen, um uberhaupt die App offnen zu konnen. Da der Dieb die PINnicht kennt, ist es ihm nictht moglich, die Accounts des Users zu nutzen. Eskann aber nicht ausgeschlossen werden, dass der User aus Bequemlichkeitendiese Funktion abschalten.Bis jetzt wurden Risiken betrachtet, die deshalb entstehen, dass Server oderClient angegriffen werden. Angenommen das Smartphone ist von Malware be-fallen, so ist es moglich, dass das Passwort aus dem Programmcode gelesenwerden kann. Da jedoch beim Login mit eKaay in der Demoversion das Pass-wort nicht auf dem Handy gespeichert ist, sondern erst im zweiten Schritt imBrowser eingegeben werden muss, kann dieser auch von Malware nicht ausge-lesen werden.Die Demoversion sollte zu einem effizienten Verfahren erweitert werden, sodass-die Registrierung mehrerer neuer User moglich ist. Zusatzlich sollen mehrereDateien ausgelesen und bearbeitet werden. Neuen Usern sollte die Moglichkeitgegeben sein, sich ein Account zu erstellen. Da ein Login ohne eKaay nichtmoglich ist, muss gleichzeitig der User sich auf dem eKaay Server registrieren.Momentan ist es nicht moglich sich mit einem anderen Usernamen außer

”Tu-

ba“ und”test“ einzuloggen. Damit die Demoversion von anderen Usern genutzt

werden kann, sollte die Demoversion mit einer Datenbank erweitert werden.Wenn die Datenbank erstellt wird, so konnen weitere Useraccounts eingefugtwerden. Da jeder Username nur einmal verwendet werden kann, mussen dieEintrage der Spalte Username einzigartig sein. Die Individualitat wird also furjeden User durch seinen Username gewahrleistet. Um in der Datenbank dieIndividualitat der User zu schutzen, wird die Spalte als Primarschlussel fur dieDatenbanktabelle (Tabelle mit den Userdaten) gewahlt. Der Primarschlusselwird in einer Datenbank gesetzt, um jeden Datensatz voneinander zu unter-scheiden. Die Tabelle mit den Userdaten konnte folgendermaßen in einer Da-tenbank erstellt werden.Die Eintrage der Spalte Username sind vom Datentyp VARCHAR (Zeichen-ketten max. Lange 255) die Spalte Passwort von Datentyp VARCHAR. Umdie Tabelle

”user“ zu fullen, braucht man auf der Startseite (index.php) ein

Formular in dem der User seinen Usernamen und sein Passwort eintragen kann.Der neue Datensatz muss uber eine Query in die Tabelle

”user“ eingefugt wer-

den, wenn der Button betatigt wird,die Eintrage in Datenbanktabelle einfugt.Querys werden geschrieben um mit der Datenbank zu kommunizieren. D.h.

34 KAPITEL 5. DISKUSSION UND AUSBLICK

Befehle werden angegeben die in der Datenbank oder in Tabellen ausgefuhrtwerden sollen. Die Formulardaten werden zuerst ausgelesen, um die Daten indie Tabelle

”user“ einzufugen, so ist dann der neue User in der Datenbank

gespeichert. Um Fehler zu vermeiden die auftreten konnten, wenn ein schonvorhandener Username versucht wird als neuer Datensatz in die Tabelle

”user“

eingefugt zu werden. Um diesen Fall schon vorzeitig abzufangen, muss eineQuery geschrieben werden. Diese uberpruft, ob der Username schon verwen-det wurde. Ist dieser Username schon in der Tabelle

”user“ enthalten soll eine

Meldung erscheinen, damit der User einen neuen Usernamen eintragt. Wennder Username nicht bereits vorhanden ist, soll der neue Datensatz aus Userna-me und Passwort eingefugt werden. Nachdem der User auf in der Datenbankgespeichert ist, muss dieser auf dem eKaay-Server registriert werden. Um dieAktivierung des Account durchzufuhren kann an das Formular ein zweiter But-ton eingefugt werden. Wird dieser Button betatigt werden diese Daten an eineSeite weitergeleitet, an eine Seite weitergeleitet welche den Aktivierungs-2D-Code beinhaltet. Anschließend wird der Username anhand POST-Daten diean die Webseite gesendet wurden, angepasst wird.Es ist denkbar, dass durch die Anwendung der genannten Erweiterungen ei-ne offentliche Nutzung der Demoversion moglich ist. Nach der Analayse undder Diskussion, ist das eKaay-Loginverfahren sicherer als das herkommlichePasswort Login. Daher ist es immer eine bessere Wahl Logins mit dem eKaay-Verfahren zu initialisieren [17, 16, 38, 39].

Literaturverzeichnis

[1] www.dropbox.com

[2] Der Desktop ist tot. http://www-05.ibm.com/de/ibm/ahead/

datacenter/index3.html. Version: 2008

[3] Was ist Cloud Computing? http://www.salesforce.com/de/

cloudcomputing/

[4] IBMSmartCloud. http://www.ibm.com/cloud-computing/de/de/

what-is-cloud-computing.html

[5] Cloud-Computing. http://www.itwissen.info/definition/lexikon/

Cloud-Computing.html

[6] Rehbein, Daniel: Hashwert-Funktionen MD5 und SHA-1. http://www.daniel-rehbein.de/hashwerte.html

[7] Reimers, Nils: Was ist md5? http://www.php-einfach.de/wissen\

_md5.php

[8] Augsten, Stephan: Schwachstelle in MD5 Hash Algorith-mus ist großte Internet Bedrohung. (2010). http://www.

searchsecurity.de/themenbereiche/applikationssicherheit/

web-application-security/articles/254858/

[9] Borchert, Dr. B.: eKaay Implementierung. http://www.ekaay.com/

implement/

[10] Borchert, Dr. B.: eKaay - Smart Login. http://www.ekaay.com/

[11] Marco Schurmann, Georg P.: Cloud-Computing gewinnt an Bedeu-tung. (2012)

[12] Herrmann, Wolfgang: Technik der Zukunft-Wie der Hy-pe entstand. (2009). http://www.pcwelt.de/ratgeber/

Wie-der-Hype-entstand-Technik-der-Zukunft-228731.html

35

36 LITERATURVERZEICHNIS

[13] Goldi, Andreas: In: Das nachste IT-Schlachtfeld http://netzwertig.com/2008/05/14/

platform-as-a-service-das-naechste-it-schlachtfeld/

[14] Haupter, Ralph: Cloud Computing Chancen und Verantwortung.

[15] Teambox. http://www.cloud-computing-network.com/

[16] Gunther, Max: Sicheres Online Banking via Smartphone mit Nahfunk(NFC). (2011)

[17] Weidmann, Olesja: Einbinden des nPAs in das Fotohandy-Verfahrenmittels NFC. (2012)

[18] http://www.ekaay.com/demo/Open-Sesame.jpg

[19] Fischer, Maximilian: Advanced Encryption Standard. (2008).http://w6hde4t7p.homepage.t-online.de/03_Kryptologie/

KryptDateien/Kapitel%2008_AES.pdf

[20] Advanced Encryption Standard (AES). http://www.dpunkt.de/

leseproben/3112/Kapitel%208.pdf

[21] Borchert, Dr. B., Oktober 2012

[22] Novemberkind: Im Tagtraum. September 2010

[23] Network, Erack: PHP Tutoial. http://www.tizag.com/phpT/

fileappend.php

[24] Reimers, Nils: PHP-Einfuhrung. http://www.php-einfach.de/

php-tutorial/php-dateien2.php

[25] Offnen von Dateien mit PHP. http://www.teialehrbuch.de/

Kostenlose-Kurse/PHP/9368-Oeffnen-von-Dateien-mit-PHP.html

[26] Schroder, Alexey: Passwort, MD5-Hash und Salt. (2012)

[27] Schmidt, Jurgen: Hash mich, die zweite-Konsequenzen der erfolgreichenAngriffe auf MD5. (2009). http://www.heise.de/security/artikel/

Konsequenzen-der-erfolgreichen-Angriffe-auf-MD5-270106.html

[28] Mieke, Ralf: MD5-Hashing mit JavaScript. http://aktuell.de.

selfhtml.org/artikel/javascript/md5/

[29] Alles so bunt hier! http://www.heise.de/security/artikel/

Regenbogentabelle-270992.html

LITERATURVERZEICHNIS 37

[30] Das XMLHttpRequest - Objekt. http://www.webmasterpro.de/coding/article/ajax-das-xmlhttprequest-objekt.html

[31] Kesteren, A. van: XMLHttpRequest Level 2. http://www.w3.org/TR/

XMLHttpRequest/. Version: Januar 2012

[32] Vaness, Chris: Announcing the Advanced Encryption Stan-dard. (2001), November. http://csrc.nist.gov/publications/fips/

fips197/fips-197.pdf

[33] Walker, John: JavaScrypt: Browser-Based Cryptography Tools. (2005),Dezember

[34] SELFHTML:JavaScript Einfuhrung in JavaScrypt. http://de.

selfhtml.org/javascript/intro.htm#javascriptdateien

[35] Klaus, Michael: PHP-Datei lesen. November 2007

[36] phpbox.de: PHP fopen-Datei offnen, Datei bearbeiten. http://www.

phpbox.de/php_befehle/fopen.php

[37] phpbox.de: PHP - Dateien bearbeiten, schreiben und lesen. http://

www.phpbox.de/php_befehle/dateien.php

[38] Borchert, Dr. B.: eKaay - Sicherheit. http://www.ekaay.com/

security/

[39] Wille, Christoph: Passworter speichern - aber richtig! http://www.

aspheute.com/artikel/20040105.htm

38 LITERATURVERZEICHNIS

Selbstandigkeitserklarung

Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbstandig undnur mit den angegebenen Hilfsmitteln angefertigt habe und dass alle Stellen,die dem Wortlaut oder dem Sinne nach anderen Werken entnommen sind,durch Angaben von Quellen als Entlehnung kenntlich gemacht worden sind.Diese Bachelorarbeit wurde in gleicher oder ahnlicher Form in keinem anderenStudiengang als Prufungsleistung vorgelegt.

Ort, Datum Unterschrift

Documents

Bachelorarbeit Informatikborchert/Troja/studdiplfiles/... · Eberhard Karls Universit at T ubingen Mathematisch-Naturwissenschaftliche Fakult at Wilhelm-Schickard-Institut fur Informatik