Es existiert eine Vielzahl an Web 2.0-Applikationen, welche es einer Gruppe von Personen ermöglichen, einen gemeinsamen Termin zu finden (z. B. doodle.com, moreganize.ch, whenisgood.net, agreeadate.com, meetomatic.com, etc.) Der Ablauf ist simpel: Ein Initiator legt eine Terminumfrage an und schickt den Link zu der Umfrage zu den potentiellen Teilnehmern. Nachdem jeder Teilnehmer der Anwendung seine Verfügbarkeiten mitgeteilt hat, kann anhand dieser Informationen ein Termin gefunden werden, der am besten passt.
Maßnahmen um die Vertraulichkeit und Integrität der Daten zu schützen finden in allen bestehenden Applikationen zu wenig Beachtung. In dieser Dissertation wurde eine Web 2.0-Applikation entwickelt, welche es zulässt Terminabstimmungen zwischen mehreren Teilnehmern durchzuführen und dabei möglichst wenige Vertrauensannahmen über alle Beteiligten zu treffen.:1. Einleitung 1
2. Anforderungsanalyse 3
2.1. Begriffsdefinitionen/Primärfunktionalität . . . . . . . . . . . . . . . . . . . 3
2.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Benutzbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Mehrseitige Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. Beziehungen der Anforderungen . . . . . . . . . . . . . . . . . . . . 13
3. Abstimmungsverfahren mit mindestens einer vertrauenswürdigen Entität 15
3.1. Existierende Verfahren mit vertrauenswürdigem Serveradministrator . . . 15
3.1.1. Ohne Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2. Schutz gegen außenstehende Angreifer . . . . . . . . . . . . . . . . 16
3.1.3. Schutz gegen angreifende Teilnehmer . . . . . . . . . . . . . . . . . 18
3.1.4. Schutz gegen den Netzwerkbetreiber . . . . . . . . . . . . . . . . . 20
3.1.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Neue Verfahren mit vertrauenswürdigen Teilnehmern . . . . . . . . . . . . 20
3.2.1. Allen Teilnehmern vertrauen . . . . . . . . . . . . . . . . . . . . . 22
3.2.2. Nur dem Umfrageinitiator vertrauen . . . . . . . . . . . . . . . . . 23
3.2.3. Ausblick auf Schemata ohne vertrauenswürdige Entitäten . . . . . 25
3.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Abstimmungsverfahren ohne vertrauenswürdige Entitäten 29
4.1. Existierende Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1. E-Voting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.2. Verteilte Constraint-Optimierung . . . . . . . . . . . . . . . . . . . 33
4.1.3. Spezifische Terminplanungsprotokolle . . . . . . . . . . . . . . . . . 34
4.2. Einfaches Schema für protokolltreue Teilnehmer . . . . . . . . . . . . . . . 34
4.2.1. Umfrageerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.2. Stimmenabgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.3. Ergebnisveröffentlichung . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3. Erweiterung des Schemas auf protokollverletzende Angreifer innerhalb der
Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1. Angriffe erkennen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2. Angreifer identifizieren . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.1. Integrität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.2. Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.3. Vertraulichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.4. Blockierende Protokollrunden . . . . . . . . . . . . . . . . . . . . . 57
4.4.5. Reaktionszeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.6. Installationsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.7. Flexibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5. Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5.1. Teilnehmer dynamisch hinzufügen/entfernen . . . . . . . . . . . . . 64
4.5.2. Präferenzwahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.5.3. Stimmenupdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5. Implementierung 69
5.1. Verfahren mit vertrauenswürdigem Serveradministrator . . . . . . . . . . . 69
5.1.1. YATA – Yet Another Terminabstimmungsapplikation . . . . . . . . 69
5.1.2. Schutz gegenüber dem Netzwerkbetreiber . . . . . . . . . . . . . . 75
5.2. Verfahren ohne vertrauenswürdigem Serveradministrator . . . . . . . . . . 77
5.2.1. Symmetrische Verschlüsselung, symmetrische Authentifikation . . . 78
5.2.2. Symmetrische Verschlüsselung, digitale Signatur . . . . . . . . . . . 80
5.2.3. Asymmetrische Verschlüsselung an den Initiator . . . . . . . . . . . 81
5.2.4. Minimal benötigtes Vertrauen in alle Entitäten . . . . . . . . . . . 83
5.3. Kryptographie mit JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.1. Schlüsselspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.2. Blockieren der JavaScript-Berechnungen vermeiden . . . . . . . . . 94
5.3.3. Performanceverbesserung der JavaScript-Berechnungen . . . . . . . 96
5.3.4. JavaScript-Code vertrauen . . . . . . . . . . . . . . . . . . . . . . . 97
6. Zusammenfassung und Ausblick 99
Literatur xvii
A. Entropie eines Verfügbarkeitsvektors xxv
A.1. Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
A.2. Allgemeine Berechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
B. Stimmenabgabe (min. Vertrauen) xxvii
C. Ergebnisveröffentlichung (min. Vertrauen) xxix
D. Schlüsseltransportmechanismus 2 nach ISO/EIC 1170-3 xxxi / Applications which help users to schedule events are becoming more and more important. A drawback of most existing applications is, that the preferences of all participants are revealed to the others.
We propose a schemes, which are able to schedule events in a privacy-enhanced way. In addition, Dudle, a Web 2.0 application is presented which implements these schemes.:1. Einleitung 1
2. Anforderungsanalyse 3
2.1. Begriffsdefinitionen/Primärfunktionalität . . . . . . . . . . . . . . . . . . . 3
2.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Benutzbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Mehrseitige Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. Beziehungen der Anforderungen . . . . . . . . . . . . . . . . . . . . 13
3. Abstimmungsverfahren mit mindestens einer vertrauenswürdigen Entität 15
3.1. Existierende Verfahren mit vertrauenswürdigem Serveradministrator . . . 15
3.1.1. Ohne Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2. Schutz gegen außenstehende Angreifer . . . . . . . . . . . . . . . . 16
3.1.3. Schutz gegen angreifende Teilnehmer . . . . . . . . . . . . . . . . . 18
3.1.4. Schutz gegen den Netzwerkbetreiber . . . . . . . . . . . . . . . . . 20
3.1.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Neue Verfahren mit vertrauenswürdigen Teilnehmern . . . . . . . . . . . . 20
3.2.1. Allen Teilnehmern vertrauen . . . . . . . . . . . . . . . . . . . . . 22
3.2.2. Nur dem Umfrageinitiator vertrauen . . . . . . . . . . . . . . . . . 23
3.2.3. Ausblick auf Schemata ohne vertrauenswürdige Entitäten . . . . . 25
3.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Abstimmungsverfahren ohne vertrauenswürdige Entitäten 29
4.1. Existierende Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1. E-Voting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.2. Verteilte Constraint-Optimierung . . . . . . . . . . . . . . . . . . . 33
4.1.3. Spezifische Terminplanungsprotokolle . . . . . . . . . . . . . . . . . 34
4.2. Einfaches Schema für protokolltreue Teilnehmer . . . . . . . . . . . . . . . 34
4.2.1. Umfrageerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.2. Stimmenabgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.3. Ergebnisveröffentlichung . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3. Erweiterung des Schemas auf protokollverletzende Angreifer innerhalb der
Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1. Angriffe erkennen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2. Angreifer identifizieren . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.1. Integrität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.2. Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.3. Vertraulichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.4. Blockierende Protokollrunden . . . . . . . . . . . . . . . . . . . . . 57
4.4.5. Reaktionszeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.6. Installationsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.7. Flexibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5. Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5.1. Teilnehmer dynamisch hinzufügen/entfernen . . . . . . . . . . . . . 64
4.5.2. Präferenzwahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.5.3. Stimmenupdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5. Implementierung 69
5.1. Verfahren mit vertrauenswürdigem Serveradministrator . . . . . . . . . . . 69
5.1.1. YATA – Yet Another Terminabstimmungsapplikation . . . . . . . . 69
5.1.2. Schutz gegenüber dem Netzwerkbetreiber . . . . . . . . . . . . . . 75
5.2. Verfahren ohne vertrauenswürdigem Serveradministrator . . . . . . . . . . 77
5.2.1. Symmetrische Verschlüsselung, symmetrische Authentifikation . . . 78
5.2.2. Symmetrische Verschlüsselung, digitale Signatur . . . . . . . . . . . 80
5.2.3. Asymmetrische Verschlüsselung an den Initiator . . . . . . . . . . . 81
5.2.4. Minimal benötigtes Vertrauen in alle Entitäten . . . . . . . . . . . 83
5.3. Kryptographie mit JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.1. Schlüsselspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.2. Blockieren der JavaScript-Berechnungen vermeiden . . . . . . . . . 94
5.3.3. Performanceverbesserung der JavaScript-Berechnungen . . . . . . . 96
5.3.4. JavaScript-Code vertrauen . . . . . . . . . . . . . . . . . . . . . . . 97
6. Zusammenfassung und Ausblick 99
Literatur xvii
A. Entropie eines Verfügbarkeitsvektors xxv
A.1. Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
A.2. Allgemeine Berechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
B. Stimmenabgabe (min. Vertrauen) xxvii
C. Ergebnisveröffentlichung (min. Vertrauen) xxix
D. Schlüsseltransportmechanismus 2 nach ISO/EIC 1170-3 xxxi
| Identifer | oai:union.ndltd.org:DRESDEN/oai:qucosa:de:qucosa:25867 |
| Date | 16 December 2011 |
| Creators | Kellermann, Benjamin |
| Contributors | Pfitzmann, Andreas, Schill, Alexander, Waidner, Michael, Technische Universität Dresden |
| Source Sets | Hochschulschriftenserver (HSSS) der SLUB Dresden |
| Language | German |
| Detected Language | German |
| Type | doc-type:doctoralThesis, info:eu-repo/semantics/doctoralThesis, doc-type:Text |
| Rights | info:eu-repo/semantics/openAccess |
Page generated in 0.0031 seconds