Die Schlüssel-Falle

Di Feb 24 11:06:17 CET 2015

[ Dies ist die Textversion des Artikels
  http://rem.eifzilla.de/archives/2015/02/24/re-die-schlssel-falle ]

                   RE: DIE SCHLÜSSEL-FALLE

In der c't 6/2015 vom 21. Februar fordert Redakteur Jürgen Schmidt in
seinem Editorial: „Lasst PGP sterben“.  Er hält PGP (also den OpenPGP
Standard) für technisch veraltet und einen „lahmen Dinosaurier“.  Dabei
vergleicht er PGP mit Online Diensten von Apple sowie mit TextSecure
Chat-Dienst.  Mal ganz abgesehen davon, daß alle amerikanischen Firmen
gezwungen sein können, Hintertüren in Ihre Anwendungen einzubauen,
werden hier Güterzüge mit U-Booten verglichen.  Gut, sie werden beide
aus Metall gebaut und könne Dinge transportieren, aber damit hört es
dann schon auf.  In dem Artikel /Die Schlüssel-Fälle/ auf Seite 160
versucht er sodann die Probleme zu erläutern.

Online Protokolle wie TextSecure mit Offline Protokollen wie OpenPGP
oder S/MIME zu vergleichen ist keine lautere Argumentation.  Ein
Meeting, ob direkt oder per Videokonferenz, hat offensichtlich ja auch
ganz andere Erfordernisse als ein Briefwechsel.  Viele Angelegenheiten
können in einem direkten Gespräch viel einfacher geklärt werden als
durch eine zeitlich versetzte Diskussion per Mail.  Aber damit werden
Briefe/Mails und Berichte noch lange nicht überflüssig; nur durch diese
Offline Kommunikation können Information auch (vertraulich) aufbewahrt
werden und stehen für spatere bearbeitung noch zur Verfügung.

Wir benötigen Offline Protokolle, da sie auch funktionieren wenn das
Netz zusammengebrochen ist.  Auch ist das „Sneakernet” in vielen Fällen
günstiger (hohe Bandbreite, vgl. Backups) und sicherer als eine
Onlineverbindung.  Wer /Citizen Four/ gesehen hat wird sich daran
erinnern, wie Snowden zwischen Online und Offline Laptop unterscheidet.
Im Übrigen ist Email qua Architektur Offline.

Im Gegensatz zu S/MIME, dem anderen Offline Protokoll, ist OpenPGP
dezentral und hat damit große Vorteile: Man kann es überall benutzen und
braucht nicht erst eine CA.  Die Zusammenkünfte mit anderen Menschen muß
man sich ja auch nicht vorab vom Einwohnermeldeamt (dem Pendant zu einer
CA) bestätigen lassen.

Die Forderung, Keyserver sollen einen Upload nur zulassen, nachdem sie
eine Mail Bestätigung eingeholt haben, zielt wiederum auf ein
zentralisiertes System und geht damit vollkommen an der Realität der
de-zentralen Architektur von OpenPGP vorbei.  Bei zentralen Diensten
kann man das halt machen aber nicht bei de-zentralen replizierten
Diensten, die absichtlich nicht unter einer gemeinsame Kontrolle stehen.

Die lästigen Probleme, die Jürgen Schmidt offenbar mit
nicht-enschlüsselbaren Mails hat, könnte man seht leicht abmildern,
indem die c't im Impressum und auf der Webseite auch die notwendigen
Kontaktdaten angibt: Also nicht nur Mailadresse sondern zumindest auch
die lange KeyID oder den Fingerprint sowie die direkte URL zum
Schlüssel.

Auf die gleichartigen Probleme bei S/MIME ist gar nicht eingegangen
worden, obgleich dies das andere und angeblich gängigere
Mailverschlüsselunsgprotokoll ist.  Dies wundert umso mehr, als die c't
seit einigen Jahren immer wieder S/MIME als einfache Lösung propagiert.
Nur, wie findet man damit den Schlüssel wenn er einem nicht in einer
ersten Mail geschickt wird?  Die vermeintlichen vertrauenswürdigen CAs
sind ein Scherz.  Mit deren Hilfe kann jede staatliche oder private
Spionageorganisation sich beliebige Zertifikate für beliebige Adressen
ausstellen lassen.  Das sind dann zwar nicht so offensichtlich falsche
Schlüssel wie bei den Keyservern aber freut um so mehr die NSA, den
GCHQ, und den BND.

Das direkte Webinterface der Keyserver zu benutzen, um so angebliche
„falsche“ Schlüssel aufzuzeigen, ist eine unsinnige Vorgehensweise da
Keyserver keine kryptographischen Prüfungen durchführen können
(bzw. wollen).  Das sollte dem Autor des Artikels bekannt sein,
inbesondere da er mich noch einige Tage vorher danach gefragt hatte.
Bei der Benutzung von OpenPGP Software wird sich schnell herausstellen,
was ein „gefälschter Schlüssel” ist - so ein Schlüssel bzw. User-Id wird
erst gar nicht importiert oder in einer Schlüsselliste angezeigt.

Selbstverständlich kann man beliebige Schlüssel anlegen.  Beliebtes
Beispiel is `president at whitehouse.gov' mit zirka 27 Schlüsseln.  Das ist
ja nun wirklich nichts Neues und etwas was man auf jeder Crypto-Part
lernt.  Deswegen gibt es aber auch die Fingerprints in manchen
Zeitschriften und auf vielen Visitenkarten.  Eingeweihte haben dann auch
noch die Keysigning-Parties (obgleich diese mehr ein Gesellschaftsspiel
sind als einem Massenpublikum dienlich).

Anstatt über Keyserver und OpenPGP allgemein herzuziehen wäre mehr
erreicht, die Mail-Provider aufzufordern, etwas zu tun: Mailadressen
sind einzig über das DNS festgelegt und deswegen kann und sollte man
auch das DNS benutzen um an einen passenden Schlüssel zu gelangen.  Der
kann zwar immer noch gefälscht sein, da DNS nicht wirklich sicher ist,
aber immerhin gäbe es dann einen passenden Schlüssel zu jeder
Mailadresse.  Dazu gibt es seit Jahren RFCs und GnuPG hat es seit 2006
implementiert (vgl. [GUUG FFG Vortrag]).  In 2012 habe ich hierzu mit
meinem Kollegen Marcus Brinkmann ein Konzept unter dem Namen [Steed]
veröffentlicht, wozu es in der c't den größtenteils korrekten Artikel
[Vertrauen auf den ersten Blick] gab.

Leider wollen die Provider dabei nicht mitmachen und lullen die
Öffentlichkeit in Sicherheit durch Schwachsinn wie /Email made in
Germany/ oder gar dem Verweis auf den Hintertürdienst /De-Mail/ ein.

[GUUG FFG Vortrag]
http://www.guug.de/veranstaltungen/ffg2006/abstracts.html#4_2_2

[Steed] http://g10code.com/steed.html

[Vertrauen auf den ersten Blick]
http://www.heise.de/artikel-archiv/ct/2012/20/190_Vertrauen-auf-den-ersten-Blick

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.