Re: [AG Liquid Democracy] An einem System als "berechtigt" gelten, obwohl das System nicht weiß, wer man ist?

[Arne Mueller <arne.c.mueller AT googlemail.com>]

Am Donnerstag, den 01.07.2010, 11:27 +0200 schrieb Michael Vogel:
> Genial wäre es natürlich, wenn man als User selber festlegen könnte, 
> welche Daten die Applikation sehen soll. Dazu müsste die Applikation 
> übermitteln, welche Daten sie mindestens benötigt und welche sie 
> optional gerne hätte.

Ich möchte zwar jetzt nicht wie der totale U-Prove-Verfechter
rüberkommen, aber genau das ist der Anwendungsbereich von U-Prove.

Kurzfassung:
Es gibt drei Rollen: Den Issuer, den Prover und den Verifier. In der
Piratenpartei wäre der Issuer der Generalsekretär, der Prover das
jeweilige Mitglied und der Verifier die Software, wo man sich
authentifizieren möchte (Forum, LF, etc.)

Jeder Prover kann sich vom Issuer ein oder mehrere "U-Prove"s austellen
lassen. Ein U-Prove besteht insbesondere aus mehreren Attributen, einer
Signatur vom Issuer und einem Geheimnis-Feld, welches selbst der Issuer
beim ausstellen (signieren) des U-Proves kennt. So ein U-Prove könnte
z.B. folgendermaßen aussehen:

* 1. Attribut: Gültigkeit des U-Prove (z.B. abhängig davon, für wie
lange man Mitgliedsbeiträge bezahlt hat)
* 2. Attribut: Wofür wurde der U-Prove ausgestellt.
* 3. Attribut: Daten für System 1
* 4. Attribut: Daten für System 2
* Geheim-Attribut: Pseudonym für Forum, LF etc.

Mit so einem U-Prove, kann der Pirat sich dann bei dem entsprechenden
System authentifizieren. Dabei muss er nicht alle Attribut-Werte
übermitteln, sondern er kann selber bestimmen, welche Attribute
übermittelt werden.

So kann das Pseudonym und die Gültigkeitsbestätigung übertragen werden.
Alternativ kann man aber auch nur das 1. und 3. Attribut übertragen,
oder nur das 1. und 4. Attribut (oder aber auch alle Werte).

Ein Pirat, könnte sich aber auch mehrere U-Proves ausstellen lassen,
wenn er z.B. für unterschiedliche Sachen unabhängige Identitäten wünscht
(z.B. bei LF für unterschiedliche Themenbereiche). Der Issuer muss dafür
nur überprüfen, dass der Pirat sich nicht für das gleiche zweimal einen
U-Prove ausstellen lässt.

Falls ein U-Prove ausläuft, könnte man in Kombination mit einem neuen
U-Prove den alten Account verlängern. Alternativ könnte man aber auch
sich einfach einen neuen Account anlegen, wenn man um die Aufdeckung
seiner Identität fürchtet.

Theoretisch ist es also sogar möglich, dass man anonym bleibt, indem man
sich immer nur U-Proves mit sehr kurzer Gültigkeit beschafft und die
alten Accounts nicht verlängert.

Man bemerke: Selbst, wenn Issuer und Verifier kooperieren, können sie
die Identität des Provers nicht herausfinden.

Einzige Schwachstelle: Der Issuer könnte Fake-Accounts erzeugen (indem
er z.B. auch U-Proves signiert, die eigentlich zu keinem Piraten
gehören), da man nachträglich nicht mehr herausfinden kann, zu wem so
ein U-Prove gehört, könnte man sowas nicht aufdecken.

Lösungsmöglichkeit: Der Issuer darf U-Proves nur mit Signaturkarte
signieren. Signaturkarten besitzen (soweit ich weiß) häufig einen
internen Zähler, der zählt, wie häufig mit der Signaturkarten schon
signiert wurde. Wenn man also fordert, dass der Issuer einen Audit-Trail
zu veröffentlichen hat, wo zu jedem signierten U-Prove, der
Signaturzähler und die Mitgliedsnummer des Piraten (oder ein anderes
Identifizierungsmerkmal) aufgelistet ist, so kann der Issuer keine Fakes
erstellen, weil dann die Signaturzähler im Audit-Trail Sprünge aufweist
(oder die Fakes stehen im Audit-Trail, aber dann kann man sie dort
erkennen).

Ich denke es sollte nicht allzu Kostenintensiv sein, für die
Generalsekretäre der LVs Signaturkartenleser und Signaturkarten zu
beschaffen. (Das ganze funktioniert nämlich auch, wenn man mehrere
Issuer (mit unterschiedlichen Schlüsseln) hat, dann würde halt genügen,
wenn einer der Issuer den U-Prove signiert hat).

v.G.
Arne

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil