ausarbeitung.org

Studienarbeit Web of Trust

Abstract

Einleitung

Allgemeines Blabla

Zielsetzung (aus Exposee, bzw. alles rein was tatsächlich gemacht wurde)

Software zur Erstellung der Datenbasis und Analyse derselben -> Grundlage für weitere Arbeiten

Herausfinden: wie stark wird das WoT benutzt (aus Graph), von wem wird das WoT benutzt

Allgemein: Strukturelle Untersuchung des gesamten Graphen.

Vergleich mit Arbeiten, die ältere oder unvollständigere Daten benutzt haben.

Grösse der MSCC in Relation zu Gesamtzahl der Knoten sehr klein: Wie ist der Rest strukturiert? -> “unerforschte Bereiche” der MSCC

Communities

Small-World/Scale-Free/Clustering Coefficient deutet auf modulare Struktur hin.

Lässt sich mit vorhandenen Algorithmen und akzetablem Aufwand die MSCC in eine Community-Struktur zerlegen?

Lassen sich die erhaltenen Communities sinnvoll zuordnen? (Soziale Gruppen/KSPs) -> Lassen sich Schlüsse ziehen, wie das Netz zustande kommt?

Statistiken: Verwendung von Algorithmen und Schlüssellängen, best. Features (Cert level), zeitliche Entwicklung…

Warum ist das relevant: ernsthafte Angriffe gegen RSA mit kurzen Schlüssellängen (<= 1024 bit, siehe Paper über 768-bit Faktorisiriung), ernsthafte Angriffe gegen MD5 (total am Arsch) und SHA1 (schwer gebeutelt)

Abgrenzung: Arbeit hat nichts mit der zugrundeliegenden Kryptographie im eigtl. Sinne zu tun, beschäftigt sich mit sozialen Aspekten (?) und der tatsächlichen Verwendung.

Gliederung

Grundlagen und Theorie

Kryptographie mit öffentlichen Schlüsseln

Ziele

Vertraulichkeit

Authentizitaet

Terminologie: Hier meint Schlüssel einen Schlüssel im Allgemeinen, später ein OpenPGP-Schlüsselpaar.

Funktionsprinzip

symmetrische Krypto: Alice und Bob verfügen über ein shared secret. Der gleiche Key wird für Ver- und Entschlüsselung benutzt.

Symmetrische Krypto hat Schlüsselverteilungsproblem:

muss sicherstellen, dass kein dritter den schlüssel bei der verteilung erhalten kannIm internet: Abhören ist immer auf mehreren Protokollebenen und an mehreren Stellen möglichBeispiel: Email kann vom Transporteur der IP-Pakete (ISP), den Betreibern der Mailserver und staatlichen Stellen/Kriminellen abgehört werdenalso: braucht sicheren Kanal, um das PSK zu verteilen. Problem, wenn es sich um die erste Kommunikation zwischen bis dato unbekannten handelt

asymmetrische Krypto: Ein Schlüsselpaar mit öffentlicher und geheimer Komponente

Schlüssel, mit dem verschlüsselt wird, ist nicht der Schlüssel, mit dem entschlüsselt wird

public und private keys sind zusammenhängend, aber der private key kann nicht aus dem public key abgeleitet werden (computationally infeasible)

public key kann beliebig verteilt werden (Damit verbundene Probleme: nächstes Kapitel)

Authentizität: Signatur (Hash + Verschlüsselung mit private key). Jeder der im Besitz des public key ist, kann die Signatur überprüfen. Signierer beweist, dass er Zugang zum zugehörigen private key hat.

Vertraulichkeit: Verschlüsselung mit Public key, Entschlüsselung nur mit Private key

Beispiele von Algorithmen

Authentisierung von Schlüsseln

public key crypto löst zwar das schlüsselverteilungsproblem insofern, als kein sicherer/vertraulicher kanal mehr vorrausgesetzt wird. dafür aber neues Problem: Sicherstellen, dass der public key authentisch ist.

Bei Kommunikationspartnern, die sich bereits kennen und die sich raeumlich treffen koennen: kein Problem

Aber: Charakteristikum im Internet: raeumlich verteilt

Beispiel: Man in the middle attack/impersonation attack am Beispiel von PGP

Grundproblem

Muss sicherstellen

Schlüssel wurde nicht verändertSchlüssel gehört der Person/Entität, die angegeben ist

Zentrale PKI

Web of Trust

PGP/GnuPG

Geschichte von PGP/PGP.com und GnuPG

Eigenschaften/Fähigkeiten der Implementierungen allgemein

Verwendete Algorithmen

RSA encrypt/sign

RSA sign only

dsa+el gamal

weitere?

Trust-Modell beschreiben (ausführlich)

PGP-Keys werden oft benutzt, um Kommunikation zwischen räumlich entfernten Partnern abzusichern.

Schlüssel werden in dem Fall nicht persönlich übergeben, können also nicht direkt verifiziert werden.

Algorithmus, der bestimmt, welche Keys GnuPG als “valide” betrachtet.

im PGP-WoT: Unterschreiben entspricht dem Ausstellen eines Zertifikats.

Valide: Die Zuordnung von Schlüssel zu UserID wird von GnuPG als gültig betrachtet.

Anmerkung: nicht-valide Keys können trotzdem benutzt werden, werden aber bei Verwendung mit einer Warnung versehen

Wichtiger Begriff: introducer trust (Vertrauen)

Bedeutet nicht: Vertrauen in die Gültigkeit eines Schlüssels oder sonst was

Sondern: Vertrauen in den Besitzer des Schlüssels, gültige Zertifikate, d.h. Zusicherungen über die Bindung von Schlüssel an Identität abzugeben. Das bedeutet, dass der introducer korrekt die Identität des Schlüsselbesitzers verifiziert. (Eigentlich müsste an dieser Stelle auch verifiziert haben, dass der angebliche Eigentümer auch die Kontrolle über den privaten Schlüsselteil hat. Das wird normalerweise aber nicht gemacht. (?))

Mögliche trust-Werte

unknown (Kein Wert gesetzt)complete trust (marginal trustno trust(ultimate trust, nur für den Benutzer selbst)

Es gibt keine präzise Angabe der Semantik dieser Trust-Level, nur vage Beschreibungen und Intuition

Wann ist ein Key valide

Muss entweder unterschrieben sein von

Benutzer selbst (ultimate trust)mind. 1 Schlüssel mit full trustmind. 3 Schlüssel mit marginal trust

Ausserdem: Die Signaturkette hat maximal die Länge 5

Keine direkte Verbindung zwischen Validität eines Schlüssels und Vertrauen in den Besitzer

Es können nur solche Signaturen im WoT (= Kanten im Graphen) benutzt werden, deren Aussteller (= Quelle) über introducer trust verfügt. (d.h. marginal oder full

Trust-Algorithmus kann nicht direkt über kantendisjunkte Pfade ausgedrückt werden (hat eigentlich genau nichts damit zu tun)

Beispiel: Graph (

introducer trust: none (rund) , marginal (Quadrat), full (diamant)

Validität: none (weiss), marginal (grau), full (schwarz)

Informationsgehalt von Signaturen

Klar: die Zertifizierung (Zusicherung über Binding) an sich

Und: Idealerweise steht eine Signatur für persönlichen Kontakt mit Verifikation der Identität

Aber: Oft (KSPs u.ä.) stehen die Zertifizierungspartner (signer/signee) die dort auftreten nicht in einem tatsächlichen direkten sozialen Verhältnis (sind vielleicht Teilnehmer der gleichen Konferenz, gehören der gleichen Uni an), müssen sich aber nicht wirklich kennen im eigentlichen Sinn. Hier sind auch verschiedene Grade möglich: sich gar nicht kennen und zufällig über eine KSP übereinander stolpern (Verbindung nur über gleiches Event, siehe vorne), enge bekannte, die regelmässig kommunizieren und sich schon länger persönlich kennen, dazwischen: Mitglieder einer Organisation/Gruppe (Debian, Uni), die keinen persönlichen Kontakt haben und deren Verbindung sich im wesentlichen über diese Mitgliedschaft definiert.

Web of trust: Begriff missverständlich: Trust bezieht sich nicht auf die öffentlichen Zertifizierungen, die im Netz sichtbar sind, sondern auf das Vertrauen, dass der Benutzer in verschiedene Aussteller von Zertifikaten von vorheraus hat.

Das komplette System beruht auf bereits vorhandenem Vertrauen. Die Zertifizierungen, die das Netz ausmachen, stellen nur Zusicherungen der Zertifikatsaussteller über die überprüfung des Identity-Key-bindings dar. Ob diesen Zusicherungen vertraut wird, ist vom jeweiligen Benutzer abhängig.

D.h.: Anhand des Netzes als solches kann ohne Hinzunahme einer Trust-Database nichts über die Validität eines Keys ausgesagt werden.

Vertrauen kann nicht aus dem Netz gelesen werden

Was drückt eine Signatur aus?

Die soziale Komponente

Wie kommen grundsätzlich Zertifizierungen zustande?

Keysigning-Parties: ad-hoc und gross/formalisiert auf Konferenzen

Face-to-face

Gruppen, die bekanntermassen stark auf das WoT bauen

Debian

andere Distributionen?

Der OpenPGP-Standard (unwichtig)

Paketformat v4

Unterschiede v3

Keyserver-Netzwerk

Prinzip: Öffentliche Keyserver (auch private denkbar) stellen OpenPGP-Keys für PGP-Benutzer bereit

Web of Trust kann natürlich auch ohne Keyserver betrieben werden, Veröffentlichung ist nicht notwendig. Dann aber privat, keine öffentliche Infrastruktur.

Keyserver gleichen ihren Datenbestand untereinander ab

Beim WoT (Signaturen…) macht der Keyserver die gesamte Vernetzungsstruktur öffentlich. Das bedeutet ein Privacy-Problem (Signaturen sind Abbild von soz. Beziehungen/Vertrauen), das wahrscheinlich (Beleg?) vielen Benutzern nicht bewusst ist. D.h. Keyserver stellen das soziale Netzwerk zur Verfügung.

Das öffentliche PGP-Netzwerk

Struktur und Grösse

Wichtiges Grundprinzip: Was dort ist bleibt. Vorteile und Nachteile…

Warum gut? Warum schlecht? (WP)

Andere Ansätze: PGP Global Directory

Graphentheorie allgemein

Gerichteter Graph

Pfad

Netzwerkanalyse

Netzwerkstatistiken

Clustering coefficient

Betweeness Centrality

Netzwerkmodelle: Random, Small World, Scale free, Implikationen

Communities - Definition, Algorithmen

Related Work

Web of Trust im Allgemeinen

Analyse von WoT-Communities: Duch2005, Boguna2004

Wotsap + Webseiten (

Netzwerkstatistiken: Capkun2002

Analyse von Netzwerken allgemein

Analyse von Community-Strukturen

Methoden und Materialien -> Beschreibung der Software, der Datenextraktion etc.

Warum eigene Extraktion? Warum nicht die wotsap-Daten benutzt?

Untersuchung der Struktur abseits der MSCC

Komplette Geschichte liegt vor, Zustand zu einem beliebigen Zeitpunkt -> Statistiken, kann strukturelle Entwicklung nachvollziehen

Vollständigere Informationen über Schlüssel und Signaturen

wotsap läuft auf veraltetem PKS -> wird nirgends benutzt, nicht gewartete Software…

Wotsap nicht korrekt

Wodurch Fehler verursacht

Unterschiede zwischen Datensätzen

Design

SKS Software

Löst veraltetes PKS ab

Austausch über Emails

Probleme mit OpenPGP-Features: Welche? (Subkeys? KeyIDs?…)

Hat PKS fast vollständig abgelöst (alle wichtigen Keyserver umgestellt)

Geschrieben in Ocaml

Design: Zwei Prozesse (db und recon)

DB: Berkeley-Datenbank

Algorithmus zum Abgleich der Datenbanken (Set reconciliation) kurz anreissen

eigene Software - Methode

Extraktion

Extraktionsteil ist Patch gegen SKS -> ebenfalls in Ocaml

Integration in SKS: erlaubt direkten Zugriff auf Datenbank, Zugriff auf OpenPGP-Low-level-parsing -> muss nur High-level (Paketstruktur, OpenPGP-Semantik) rudimentär selbst entwickeln.

Extraktion kann auf laufenden Keyserver zugreifen, da nur lesend. (-> db und recon können laufen)

Iteration über Datenbank, Reduzierung auf interessante Daten (Welche?), Speicherung in sexp (einfach)

Nur Parsen der Paketstruktur, keine kryptographische Verifizierung.

Problem: Jeder kann Signatur-Pakete auf fremden Schlüsseln anbringen, auch wenn die Signatur nicht gültig ist. (Keyserver verifizieren nicht…)Alternative: Jeden Key in GnuPG werfen (nicht nur parsen sondern verifizieren!): dauert zu lange (siehe Wotsap, wobei Hardware unbekannt)Argumentieren, warum das kein Problem ist: Es interessiert die Struktur und Statistik, nicht einzelne Schlüssel. Es sind sicherlich kaputte/falsche Signaturen vorhanden. Es müssen aber schon ziemlich viele sein, um die Struktur wirklich zu stören/verändern. Das ist wiederum unwahrscheinlich. Ist auch unrealistisches Angriffsszenario, da Signaturen für die Trustberechnung ja kryptographisch verifiziert werden.

Grundsatz: Keys nur dann komplett wegwerfen, wenn es gar nicht anders geht (z.B. Public-Key-Packet nicht parsebar, semantisch unsinnig (Beispiel?)). Dadurch möglichst vollständiger Datensatz vorhanden. Der für diese Arbeit interessante Teil davon (valide Keys, Graph) kann durch SQL etc gewonnen werden -> Flexibilität.

keine Selbstsignatur (auch keine, die expired/revoked sind)nicht parsebar -> kaputte Pakete

Speicherung in SQL-DB, vielfältige Abfragemöglichkeiten (muss keine eigene Abfragemöglichkeit von Hand schreiben, Ausnutzung von Indizes etc)

muss die Daten nicht jedesmal neu aus sexp-Datei laden, muss die Daten nicht komplett im Speicher haltenTabellenstrukturKomponentenzuordnung wird in extra Schritt berechnet.

Trennung von Extraktion und DB: Sinnvoll, weil Extraktion zeitaufwendig und nur einmal (reicht für diese Arbeit aus)

Könnte genauso neue Daten live in Datenbank kippen -> Service, der immer die aktuellen Daten anbietet

Ausblick: Weiterentwicklung zu “Messdatenservice” und automatische Generierung von Analysen

Analyse

Sammlung von kleinen Tools, die die verschiedenen Teile der Aufgabenstellung in Bezug auf Analyse realisieren

mehrere unabhängige Commandline-tools, eigene Prozesse

greifen teilweise auf Datenbank zu

oder nur auf Graphenstruktur in extra Datei

Warum eigene Analyse? Warum nicht auf igraph etc zurückgegriffen? Gute Frage…

MPI

Warum: Graph zu gross, Algorithmen zu komplex…Methode: Abwandlungen von BFS…Distance_statistics trivialBetweeness nach Brandes

Ergebnisse

Kennzahlen Graph insgesamt

Wie viele Knoten, Kanten, etc.

Komponentenstruktur insgesamt

Zahl der Komponenten, Grössenverteilung (scale-free?)

Struktur der Komponenten -> wie sind diese untereinander vernetzt (Aggregatkanten…)

Zeichung der Struktur (bessere Zeichnung als bisher)

Kleine Komponenten (einige wenige herausgreifen + Gesamtbild)

Interne Struktur (Grade, Pfadlängen etc)

Zusammensetzung der Keys

Einteilung der Komponenten nach Nation, Institution, Zeit

Aktivität? Ist die Komponente über die Zeit entstanden oder auf einmal (KSP) (Ad-Hoc-Mass)

MSCC

Netzwerkstatistiken

Gradverteilung in/out

Zwischen ziemlich wenigen Keys gibt es gegenseitige Signaturen

Andere Eigenschaften: (durschnittliche Pfadlängen, Durchmesser, Radius, Eccentricity)

(Fehlt noch, trivial): MSD -> Mean significant distance

Fragestellung: Small-World? Scale-free?

Auch wenn die Gradverteilung nicht scale-free im strikten Sinn ist, hat sie doch wahrscheinlich qualitativ die Eigenschaften, die davon erwartet werden

Was anfangen mit Betweeness Centrality? Ist zwar ein hübsches Werkzeug, trägt aber nichts zur Fragestellung bei (?)

Communities

Liefern Algorithmen erkennbar sinnvolle Einteilung?

(falls ich dazu komme) Vergleich von directed und undirected: Motivation s.o.

lassen sich soziale Gruppen und KSPs unterscheiden?

Community-Struktur zeichnen

Interne Struktur der Communities

Vergleich mit Komponentenstruktur?

Komponenten sind letztendlich auch Communities, d.h. insgesamt Community-Analyse mit zwei Methoden

Statistiken

Verwendung von Algorithmen (Pubkey und Sig)

Zeitliche Entwicklung

Zeitliche Interpretation (Einführung von GnuPG, Änderung von Algorithmen-Defaults, SHA1-Problem…)

Wie entwickelt sich das Wachstum? Stagniert die Grössenentwicklung?

Wie ist das Alter der im Moment aktiven Schlüssel verteilt?

Verwendung von Cert levels

Diskussion

Communities, die durch Fast-modularity gefunden wurden, haben wieder modulare Struktur: Ersichtlich aus Zeichnung mit Force-directed layout (cytoscape): Es ergeben sich dichte teilbereiche, die nach aussen schach vernetzt sind. Hinweis auf feinere Community-Struktur. (siehe paper: modularity-based clustering is force-directed layout).

Komponentenstruktur

SCCs sind auch Communities, die nicht vernetzt sind.

MSCC ist die einzige Komponente, die ein aktives WoT mit globalem Anspruch(!) darstellt

kleinere Komponenten sind (zumindest wenn sie aus einer KSP stammen) wahrscheinlich inaktiv (?)

Geringe Grösse der MSCC in Relation zur Gesamtzahl der Schlüssel und zum Internet

überwiegender Teil der PGP-Benutzer legt keinen Wert auf Authentication (oder macht das privat, ist aber unwahrscheinlich)

Aus Gradverteilung: Selbst in der MSCC ist die grosse Mehrzahl (Grad 1, 2) kaum angebunden, dadurch kaum Chance auf redundante Trust-Pfade, kaum Robustheit

Vergleich mit Literatur: Andere WoT-Analysen: Capkun etc.

Vergleich mit Literatur: Social Networks

Communities: Auflösungslimit

Communities: (falls nicht gemacht) eigentlich wären Overlapping Communities sinnvoll

Communities: Vergleich mit Literatur, insb. Paper zu WoT-Communities

Falls begründbar: WoT stellt ein Abbild sozialer Beziehungen dar und damit ein Tool für Traffic Analysis (Überwacher kann Punkte/Personen bestimmen, an denen weitere Überwachungsmassnahmen ansetzen können). Aus den Daten lassen sich ohne zusätzliche Informationen Erkenntnisse gewinnen, die einiges über Einzelpersonen und Projekte aussagen. Damit ergibt sich ein Privacy-Problem. Ist das den Leuten bewusst? Gibt es Alternativen, die ohne komplette Offenlegung der Beziehungen funktionieren?

Letzter Punkt muss abgeschwächt werden: Relevant ist der Mechanismus, mit dem Signaturen erzeugt werden: private signings können Informationen preisgeben, KSPs tragen nichts wesentliches bei, weil zwischen den Teilnehmern im Allgemeinen keine Vertrauensbeziehung besteht. (Welcher Mechanismus stellt die Mehrheit dar?)

Nochmals abschwächen: Die eigentliche Vertrauensbeziehung im Sinne von introducer trust wird nicht offengelegt.

WoT setzt Vertrauensbeziehungen vorraus, löst nicht das Problem vertraulicher Kommunikation mit Personen, zu denen (noch) keine Vertrauensbeziehung besteht.

Conclusion

“Toolbox” (naja) für Extraktion und Analyse von PGP-WoT-Daten

Analyseergebnisse

Nochmal betonen, dass Erreichbarkeit im WoT noch lange nichts über Trust/Validity aussagt.

Wahrsch. Schlussfolgerung: Nerdspielzeug + ernsthaftes Werkzeug für klar umrissene Communities

Spekulation über Ursachen geringer Verwendung: Insgesamt zu komplex? Doku zu schlecht? Werkzeuge zu schlect?

Basis für Vergleich mit hierarchischer PKI?

Gibt es eine Korrelation zwischen Mass der Vernetzung (Grad) und Verwendung von cert levels? Personen welcher Art benutzen Cert levels? (pro Grad/Grad-bin: wie hoch ist der Anteil der leute, die level != 0x10 verwenden?

PGP-Network aus Arenas et al (models of social networks based on…) wird in mehreren papers u.a. bei gregory (cliquemod-paper) als benchmark fuer community-algorithmen benutzt. daraus zusaetzliche motivation/nutzen ableiten: vollstaendiger, aktueller datensatz fuer benchmarks, insbesondere als gerichtetes netzwerk. analyse von communities mit direction-informationen kommt gerade erst auf und pgp ist inhaerent gerichtet.

Wie viele User insgesamt/pro community stammen aus bekannten os-projekten (debian, ubuntu, …) und wie viele sind akademiker (.edu, uni-.de, …)