50px	Dieser Artikel ist eine Idee von Wobble und damit keine offizielle Aussage. Du kannst sie kopieren, verbessern, erweitern oder umsetzen. Vielleicht wurde sie auch schon umgesetzt. Wenn du meinst etwas beitragen zu können, sei kein Ninja.

Anonyme Identifizierung

Klingt paradox, geht aber.

Ziel

Die Piratenpartei hat unter anderem drei wichtige Forderungen: Datenschutz, Transparenz und mehr Demokratie. Für den "mehr Demokratie"-Teil wurden in letzter Zeit mehrere online Abstimmtools (Liquid Feedback, Adhocracy, ...) entwickelt, die dies realisieren sollen. Da Problem bei Online-Abstimmungen ist allerdings, dass sie

nachvollziehbar sein müssen. Jeder muss darauf vertrauen können, dass alle Stimmen gezählt werden und auch keine Fake-Stimmen hinzugefügt werden.
geheim sein sollten. Bei Abstimmungen und Meinungsbildern ist es kein Muss, da nach dem Parteiengesetz nur Persohnenwahlen geheim sein müssen. Allerdings handelt es sich hier um Abstimmungen im Internet, das einzelne Abstimmverhalten ist also vermutlich maschienenlesbar im Internet abrufbar. Da persöhnliche Meinungen im Sinne des Datenschutzes schützenswerte personenbezogene Daten sind, muss es für Parteimitglieder möglich sein an den Abstimmungen teilzunehmen ohne auf Anonymität verzichten.

Online-Abstimmungen, die die obigen Punkte erfüllen, sollen realisierbar sein. Das heißt, Mitglieder sollen gegenüber einem Softwaresystem beweisen können, dass sie Mitglied sind, ohne dass sie sagen müssen, wer sie sind.

Lösungsmöglichkeit

Die Variante, die momentan realisiert wird, basiert auf Escrow-Agents um die Anonymität der Nutzer zu gewährleisten. D.h., dass mehrere Stellen der Piratenpartei kooperieren müssen, um die Identität einzelner Nutzer aufzulösen. Diese Lösung ist auch, solange es nur um unverbindliche Meinungsbilder geht, vollkommen ausreichend (zur Not greift halt die Schere im Kopf, aber das kann dann notfalls auf einem Parteitag mittels geheimer Abstimmung korrigiert werden). Die folgende Lösungsmöglichkeit ist also eher für die langfristige Perspektive gedacht.

Da manche Piraten sehr datenschutzbewusst sind und selbst die Möglichkeit der Auflösung ihrer Identität kritisch entgegensehen, wird hier ein System vorgestellt, was bei der Anonymität ohne Escrow-Agents auskommt. Es ist also (solange man nicht den Computer der Nutzer hackt), komplett unmöglich (außer man hat sehr viel Rechenpower, wie bei allen Kryptosystemen) die Pseudonyme der Nutzer aufzulösen. Genutzt wird ein Verfahren namens U-Prove (Es gibt auch ein Buch indem das Verfahren beschrieben wird). Eine Referenzimplementierung wurde von Microsoft unter BSD-Lizenz veröffentlicht, ist also Open-Source.

Das Grundprinzip ist folgendes. Es gibt 3 Akteure, das sind

der Issuer (im Falle der Piratenpartei: der Generalsekretär),
der Prover (das ist das Mitglied, was sich authentifizieren möchte) und
der Verifier (das ist das Softwaresystem an dem das Mitglied sich authetifizieren möchte).

Dabei dürfen Issuer und Verifier sogar zusammenfallen (insbesondere also kooperieren) und die Anonymität der Nutzer wäre weiterhin gesichert.

Der Issuer

Der Issuer signiert Authorisierungsanfragen. Eine Authorisierungsanfrage kann z.B. folgende 3 Attribute enthalten:

Realname, oder etwas, was den Piraten eindeutig identfiziert, sodass der Issuer entscheiden kann, ob derjenige tatsächlich Mitglied ist. Hier könnte man auch einen Token benutzen, der den Mitgliedern vorher zugeschickt wurde, damit kein Identitätsklau passiert.
Service, was angibt, für welches System das Mitglied eine Authentifizierung haben möchte (z.B. Lqfb, Forum, ML, ...)
Zeitraum, was angibt für welchen Zeitraum man die Authentifizierung haben möchte. Damit durch Korrelationsanalyse die Anonymität nicht aufgehoben werden kann, sollte Zeiträume z.B. immer ganze Jahre sein (z.B. 2010, 2011, ...) Somit kann jeder Pirat regelmäßig seine Idenität wechseln (was nützlich ist, falls die Identität doch mal aufgeflogen ist). Falls die Identität beibehalten werden soll, so kann mit der neuen Authentifizierung einfach seinen bestehenden Account verlängern.

Zusätzlich enthalten Authorisierungsanfragen als verstecktes Feld das gewählte Pseudonym. Dieses Pseudonym kann der Issuer zwar nicht entschlüsseln, signiert es aber mit.

Der Prover

In Form eines kryptographischen Protokolls, lässt der Prover sich ein signiertes Token erstellen, welches die 3 Attribute (Realname, Service, Zeitraum), das Pseudonym und ein Pflichtfeld vom Issuer enthält. Das Pflichtfeld vom Issuer bleibt in diesem Anwendungsfall aber ungenutzt. Wenn nun der Prover sich mit dem Token bei dem Verifier authentifizieren möchte, so kann er einstellen, welche der Attribute übertragen werden sollen. Insbesondere, kann er also einstellen, dass der Realname nicht übertragen wird. Zusammen damit kann er eine Nachricht übertragen, die mit dem Token signiert ist. Die Nachricht könnte z.B. ein verschlüsseltes Passwort sein, mit dem der Nutzer sich künftig an dem System anmelden möchte.

Ein kleines Programm, mit dem man einfach diese Schritte ausführen kann, kann man hier herunterladen.

Der Verifier

Der Verifier prüft, ob das Token von dem richtigen Issuer signiert wurde und ob die Nachricht auch von dem Token signiert wurde. Wenn dies der Fall ist, dann ist der Nutzer authentifiziert und der Verifier bearbeitet die Nachricht. Da der Prover das "Realname"-Attribut nicht übertragen hat, kann er die Identität des Nutzers nicht auflösen.

Angriffsmöglichkeiten

Es gibt mehrere Angriffszenarien (wer weitere kennt, einfach dazuschreiben):

Fake-Nutzer: Der Issuer könnte einfach Nutzer authorisieren, die keine Piraten sind. Da aus dem Token, dass dem Verifier nicht hervorgeht, wer dahinter steckt, ist es nachträglich unmöglich einen solchen Angriff aufzudecken. Es muss also dafür gesorgt werden, dass der Issuer nur Nutzer authorisiert, die authorisiert werden dürfen. Insbesondere darf auch niemand doppelt authorisiert werden (dann hätte er zwei Stimmen). Eine Lösung des Problems wird weiter unten beschrieben.
Aufdeckung der Identitäten durch zeitliche Korrelationsanalyse. Ein typisches Nutzerverhalten ist folgendes: Der Nutzer lässt sich sein Token vom Issuer signieren und geht gleich danach zum Verifier um sich im System einzuloggen. Wenn keine weiteren Nutzer zeitgleich das gleiche machen, ist relativ eindeutig anhand der Zeitpunkte das Pseudonym an den Realnamen koppelbar. Als Gegenmaßname könnte man den Nutzern raten nach der Beschaffung der Authorisierung erstmal ein paar Tage zu warten, damit in der Zwischenzeit noch weitere Nutzer sich Authorisierungen besorgen und somit die Identitäten nicht mehr gematcht werden können. Da es um die Privatsphäre der Nutzer selbst geht, ist es wahrscheinlich, dass viele Nutzer den Hinweis tatsächlich befolgen.
Allein die Attribute "Service" und "Zeitraum" identifizieren den Nutzer. Als Gegenmaßnahme sollte man hier einfach nur wenige Möglichkeiten zulassen (z.B. "lqfb" nur in kleingeschrieben und nur feste Zeiträume, wie z.B. "2010").
Der Nutzer kann über die IP-Adresse identifiziert werden. Hier hilft aber Tor.

Liste mit signierten Anfragen

Damit nur die Nutzer authorisiert werden, die tatsächlich auch authorisiert werden dürfen, kann man folgendes tun:

Der Issuer veröffentlicht alle Anfragen, die er signiert hat. Dies ist ungefährlich, da Verifier und Issuer kooperieren dürfen.
Da die Liste aber nicht vollständig sein muss, können beliebig viele weitere Issuer von Dritten aufgesetzt werden, die lediglich prüfen, ob die Anfrage, die sie signieren sollen, wirklich in der öffentlichen Liste vom Hauptissuer (Generalsekretär) stehen.
Der Verifier akzeptiert Anfragen nur, wenn diese von fast allen Issuern signiert wurden.

Somit müssten all diese Issuer kooperieren, um Fake-Nutzer zu erzeugen. Da aber jeder selber einen Issuer stellen kann, ist diese Gefahr faktisch nicht existent.

Demo

Es gibt eine ausprobierbare Testversion von dem oben beschriebenen System. Da man bei Google kostenlos Webapplikationen hosten kann, habe ich das einfach mal bei Google hochgeladen:

Der Issuer: http://testidissuer.appspot.com/ (da steht nochmal ein Großteil von dem Text hier, nicht verwirren lassen!)
Der Verifier: http://testidverifier.appspot.com/
Der Prover: https://sourceforge.net/projects/anonymousid/files/prover/prover.jar/download
Sourcecode von allem: https://sourceforge.net/projects/anonymousid

Dort kann man sich Tokens vom Issuer ausstellen lassen und mit diesen Tokens Nachrichten signieren, die vom Verifier veröffentlicht werden. Dabei prüft der Verifier natürlich, ob man die Nachricht von einem gültigen Token signiert hat.

Kritik, Anregungen, etc

Ich hab das Ding implementiert um zu zeigen das es geht. Die Frage, die somit offen bleibt ist: Will man sowas überhaupt? Erst wenn ich positives Feedback bekomme, werde ich mir die Mühe machen eine für die Piraten nutzbare Version zu entwickeln. Insbesondere müssen dann Schnittstellen mit den anderen Piratensystemen für die man es dann einsetzen möchte (z.B. Lqfb, Forum, Wiki, etc.) ausdiskutiert werden.--Wobble 21:26, 31. Jul. 2010 (CEST)

Gute Sache. Allerdings ist das Wissen um derartige Verfahren ja nicht neu. Man könnte sogar sagen, die Funktion der mathematisch fundierten, krypotologischen Schlüssel ist die Basis der "modernen Kryptologie", die historisch häufig mit Shannon verknüpft wird.

Das Prinzip ist den LF-Machern auch bekannt, gegen derartige Anonymous Id wurde von diesen aber argumentiert, dass damit die "Nachvollziehbarkeit" der Abstimmungen nicht gegeben sei. Dass dann dafür der Datenschutz geopfert wird, ist eine Skurillität, die man innerhalb der Piraten vielleicht nicht weiter diskutieren muss (aber ggf. außerhalb). --Bernd 11:09, 5. Aug. 2010 (CEST)

Der wesentliche Punkt, von dem System, das ich hier vorgestellt habe, ist dass die Nachvollziehbarkeit nicht geopfert wird. Man wird damit immer noch sehen können wie jedes Pseudonym abgestimmt hat. Nur kann man die Pseudonyme nicht mehr auflösen (selbst unter Kooperation nicht). --Wobble 12:16, 5. Aug. 2010 (CEST)

Danke Woble, nach so etwas habe ich schon laenger gesucht, vielleicht ist es auch gut, das ganze als anonymous/pseudonymous Id zu bewerben, da ja beides moeglich ist. Ich bin fest davon ueberzeugt, das dieses die Akzeptanz und Brauchbarkeit von Liquid Feedback sowie zukuenftigen Webanwendungen im Allgemeinen erweitern kann, wenn es denn ordentlich implementiert wird. Vielleicht hilft auch eine kleine Visualisierung, wie das ganze funktioniert, ich bin zum Beispiel bis heute noch nie hingewiesen oder gefragt worden, welche Informationen an wen uebertragen werden. Ich glaube das Thema ergibt sich mehr aus logischer Notwendigkeit in all den Situationen, in denen Datenschutz notwendig ist, es erweitert also die Einsatzmoeglichkeit unddamit Brauchbarkeit von Webanwendungen enorm.--Exidon 05:13, 12. Sep. 2011 (CEST)

Mit der PiratenID sollten diese Anforderungen abgedeckt werden. Siehe Erklärung unter PiratenID sowie Dokumentationen unter https://idtest.piratenpartei.de
Hunter 9999 02:49, 13. Nov. 2012 (CET)