[Berlin-wireless] BBB verschlüsseln ...

[Paul Hänsch]

On Sat, 28 Jun 2014 21:14:49 +0200
"Volker Ernst" <lists at sysve.de> wrote:
> > Eine große Frage wird dann auch sein: Wer entscheidet, ob jemand
> > anderes "vertrauenswürdig" ist und anhand welcher Kriterien trifft
> > wer diese Entscheidung?
> 
> Na wer sich mit einer "punkt-zu-punkt"-Verbindung (und nur um die
> geht es) verbinden will kriegt den Key, fertig. Das sind normal ja eh
> nur 2 Leute.

2 Standortbetreiber bestehend aus jeweils n Leuten. Aber die "kriegen"
nicht beide den Key. Wenn sie ihn nämlich beide entgegennehmen, dann
gibt es eine dritte Partei, die ihn vergibt. Wer ist das?

Oder generiert einer der beiden, sagen wir der mit dem MasterAP, den
Key, und gibt ihn dann ohne Beteiligung anderer Freifunklinge an die
Clientbetreiber?
Publizieren wir dann irgendwo, wer alles einen Key für welche
Verbindung hat, oder läuft das unter der Hand?

Soweit ich weiß gibt es etliche Türme, an denen mehrere ClientAPs dran
hängen. Wie ist die Policy, schreiben die Betreiber jeweils ne Mail
wegen des Keys? Kommen sie zum Treffen? Wer darf ihnen antworten, eine
beliebige Person die diesen Key hat?

Bevor du Antworten auf alle diese Fragen auflistest, das geht
natürlich, hast du vor diese Policy an alle neuen Teilnehmer mit
Backbone-Zugang zu vermitteln? Du hast im Nu ein Gesetzbuch voller
Formalitäten geschrieben, das ist eine Einstiegshürde, nicht im
formalen Sinne, du willst ja niemanden ausschließen, sondern in der
praktischen Anwendung. Du lässt Zeit verstreichen, bevor der Schlüssel
ausgetauscht ist - das nimmt Motivation. Zugang zu den Backbonelinks
wird in den Augen von Neulingen zum Privileg - das macht den Einstieg
weniger komfortabel.

Ist das die Sicherheit wert? Ist es der Mangel an Verschlüsselung, der
zu dem Internet geführt hat, das wir heute neu formen wollen, oder ist
es die immer zentralisiertere Architektur? Ich denke es ist letzteres
und ich denke diese *Architektur* müssen wir überwinden, unabhängig
davon *wer* sie baut. Zentralismus im Aufbau von Berliner Freifunklinks
ist genau so schädlich wie Zentralismus in der globalen Adress- und
Namensvergabe, auch wenn die Leute hier länger Haare haben. Wenn wir
Elite schaffen in der Infrastruktur, verlieren wir Sicherheit für alle.

Verschlüsselung schützt Menschen nur dort, wo sie in den Händen der
Sprechenden liegt, nicht in den Händen der Infrastrukturbetreiber.
Ja wir brauchen Verschlüsselung, wir brauchen Verschlüsselung an allen
Endpunkten, in deinem Browser, in deinem Emailclient. Um die musst du
dich selbst kümmern. Ja es ist gut, wenn wir dabei helfen. Du findest
das ist kompliziert und wir sind in der Pflicht, anderen Leuten diese
Aufgabe abzunehmen? Du kannst Verschlüsselung niemandem abnehmen, ohne
dich selbst in eine Machtposition zu bringen. Das macht DE-Mail, die
sollen von mir aus die einzigen bleiben.

Eine Infrastruktur, in der wir die Vergabe von Crypto-Keys regeln
bringt uns nicht weiter. Ich bin dagegen.
Von mir aus würfel die Keys aus und mach sie alle öffentlich. Für jeden
der nachfragt beim Wikiserver, ohne menschliche Interaktion.
Dann können wir die Keys auch gleich alle auf "freifunk" setzten. Wobei,
zumindest heißt auswürfeln und öffentlich machen, dass du einmal ins
Wiki musst und die Keys nicht ständig rum erzählt werden.

*Nicht* zu verschlüsseln hieße, wir haben Smartphones die uns
versehentlich die Bandbreite kaputt machen ohne was davon zu haben.
Wenn es einen Weg gäbe das zu unterbinden, ohne Crypto zu benutzen,
hätte hier auch niemand irgendwas mit Crypto angesprochen.
Aber um Himmels willen, lasst niemanden irgendwo hinkommen und
nachfragen müssen um an die Backbones ran zu kommen. Beim Freifunk
mitzumachen ist für Neueinsteiger schon kompliziert genug, wir müssen
das nicht mit sozialen Hürden verstärken.

--
Paul
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 836 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140629/524b0c53/attachment.pgp>