Vorschlag für eine Produktinnovation
Version 1.1/3.1+, 04.10.2009
Problembewusstsein
Anforderungen | Realisierung | Entwicklungsaufwand und -dauer, Unsicherheit des Entwicklungserfolgs
Vorteile der Innovation und ihr Gewicht | Aufwand-Nutzen-Verhältnis | Nachteile der Innovation | Verbreitung | Alternativen
Durch das Ersetzen der E-Mail-Adressen in öffentlichen OpenPGP-Schlüsseln auf Keyservern durch deren Hash soll dem Missbrauch der Keyserver durch Spammer vorgebeugt werden.
Die Verwendung asymmetrischer Kryptografie setzt die Verfügbarkeit der öffentlichen Schlüssel voraus. Dafür gibt es mit den Keyservern bereits eine brauchbare Lösung. Problematisch an dieser Lösung ist, dass man durch verkettete Abfragen mehr oder weniger alle gespeicherten E-Mail-Adressen eines Keyservers herausbekommen kann.
Auch wenn Kryptografie irgendwann mal ein sehr wirksamer Spamschutz sein kann, kann es nicht Sinn der Sache sein, dem Spammergesocks durch die PGP-Infrastruktur auch noch zu helfen. Derzeit ist das zwar noch kein Problem, weil kaum jemand PGP benutzt; Keyserver abzufragen wäre vermutlich ein sinnlos hoher Aufwand für Spammer. Aber das muss nicht so bleiben.
Da dies bisher kein praktisches, sondern nur ein absehbares Problem ist, scheinen sich darum nicht viele Leute zu kümmern. Die massenhafte Verbreitung von PGP soll aber nicht irgendwann dadurch ins Stocken geraten, dass die User Angst davor haben, ihre Schlüssel zu veröffentlichen.
Es soll eine PKI geschaffen werden, die keine E-Mail-Adressen enthüllt, und das mit minimaler Änderung der bestehenden Technik.
Sollte mit möglichst vielen Mail- und PGP-Programmen funktionieren.
Nötige Anpassungen sollten klein sein.
Man muss lediglich dafür sorgen, dass öffentliche Schlüssel (jedenfalls die, die auf Schlüsselserver hochgeladen werden) keine E-Mail-Adressen mehr enthalten, aber dennoch gefunden werden können, wenn jemand den Schlüssel zu einer E-Mail-Adresse sucht.
Der naheliegende Ansatz ist, alle Identitäten doppelt anzulegen, einmal in der klassischen Variante (Vorname, Name, E-Mail) und einmal nur den Hash der E-Mail-Adresse. Dafür muss man natürlich eine Normalisierung der Schreibweise einführen, damit unabhängig von der Schreibweise immer nach demselben Hash gesucht wird. Strenggenommen unterscheidet SMTP zwar bei normalen Adressen Groß- und Kleinschreibung, in der Praxis passiert das aber nicht. Dieses theoretische Problem entschärft man, indem man zuerst nach dem nichtnormalisierten Hash sucht. Sinnvoll wäre die Normalisierung auf UTF-8-codierte Kleinschreibung.
Die erforderlichen Änderungen kann man an mehreren Stellen durchführen:
Man kann gpg so ändern, dass immer zwei Identitäten erzeugt werden, die normale und dazu eine, die nur aus dem Hash der normalisierten E-Mail-Adresse besteht. Die sicherste Lösung wäre dann, beim Exportieren standardmäßig alle Nicht-Hash-IDs zu löschen. Das könnte Probleme verursachen, weil die Mailclients natürlich noch nicht darauf umgestellt sind, nach dem Hash zu suchen. Dieses Problem wäre aber nicht gravierend, weil sich zumindest die meisten Mailsclients dahingehend konfigurieren lassen, dass einer E-Mail-Adresse ein Schlüssel fest zugeordnet wird. Es könnte zudem weiter entschärft werden, indem gpg den nicht gehashten ID-Wert gesondert speichert (wie heute schon die trust-Werte) und bei Abfragen des Schlüsselbunds einfach die Originalangaben statt des Hashs zurückliefert (oder zusätzlich zu diesem). Wenn gpg den Schlüssel vom Keyserver geholt hat, kennt es zumindest die E-Mail-Adresse. Wenn der Mailclient auch den Namen kennt, sollte er den beim gpg-Aufruf gleich mit übergeben können, damit er mit in diese zusätzliche Datenbank eingetragen wird. Außerdem sollte eine einfache Möglichkeit für andere Software (also vor allem Mailclients) bestehen, Namen und Adressen abzugleichen, so dass Namen, die dieser Software nach dem Schlüsselimport bekannt werden, automatisch in der gpg-Datenbank nachgetragen werden.
Wünschenswert wäre eine Möglichkeit,
Wenn gpg nicht in der genannten Weise geändert wird, kann man natürlich die gehashte ID innerhalb einer Schlüsselverwaltungssoftware erzeugen (die gpg aufruft). Das Exportieren nur der Hash-IDs wäre dann möglich, indem man den Originalschlüssel um die Hash-IDs erweitert, ihn dann kopiert, die Original-IDs aus der Kopie löscht und den Rest auf den Keyserver hochlädt.
Die Keyserver selber müssten nach dem Verständnis des Verfassers nicht geändert werden. Die könnten natürlich den Umstieg auf das neue System beschleunigen, indem sie nur noch Schlüssel mit Hash-IDs annehmen, aber das wird wohl kaum passieren, zumal es jedermanns eigene Entscheidung sein sollte, ob er Spam haben will.
Wenn man allerdings verhindern will, dass aus Unachtsamkeit weiterhin Schlüssel mit ungehashten IDs hochgeladen werden, dann kann man die Serversoftware so modifizieren, dass sie nur noch für solche Schlüssel nichtgehashten UIDs akzeptiert, die einen mit dem Schlüssel selber signierten Hinweis darauf haben, dass dies erlaubt werden soll. Umgekehrt könnte man für die Übergangszeit auch die Möglichkeit schaffen, dies explizit zu verbieten.
Mögliche Kollisionen durch die Verwendung schlechter Hashfunktionen stellen kein Problem dar. Es reicht nicht aus, eine E-Mail-Adresse zu finden, die denselben Hashwert liefert, denn man könnte genauso einen weiteren Schlüssel für die Adresse eines anderen erzeugen und diesen hochladen. Bevor man einen öffentlichen Schlüssel verwendet, muss man sich immer von dessen Authenzität überzeugen. Und wie sollte ein Angreifer die nötigen Signaturen für seine kollidierende E-Mail-Adresse bekommen? Da müssten vertrauenswürdige Leute einen Schlüssel mit falschem oder einen ohne Namen signieren, mit einer so tollen Adresse wie cWhTtnVXAD7ZfHEw@mafia.ru.
Natürlich kann man sich dennoch darauf festlegen, für dieses System keine gefährdeten Hashfunktionen mehr zuzulassen (MD5, SHA-1).
Wenn nichts dergleichen unternommen wird, dann wird die Verbreitung von PGP irgendwann so groß, dass die Keyserver für Spammer interessant werden, und das wird dann die weitere Verbreitung von PGP (auf Keyservern) behindern, weil niemand seine Adresse Spammern zum Fraß vorwerfen will (siehe Usenet).
Der einzige derzeit erkennbare Nachteil ist, dass man einem Schlüssel nicht mehr die E-Mail-Adresse entnehmen kann. Aber der ist nicht relevant. Dafür müsste man einen Schlüssel bekommen haben, den jemand von einem Keyserver geholt hat, ohne die UID mitzuliefern, und dessen E-Mail-Adresse man nicht hat (denn ein Abgleich des Mailclients mit dem Schlüsselbund würde die UID bequem liefern). Warum sollte man so einen Schlüssel bekommen? Sollte man dieses Problem in Einzelfällen mal haben, kann man sich zumeist mit den Signaturen des Schlüssels behelfen; irgendwann trifft man auf jemanden (einen Schlüssel), den man kennt (und wenn nicht, ist der Schlüssel sowieso wertlos).
An der Linux-Front ist die Verbreitungsfrage unkritisch: Da verwenden sowieso alle gpg und werden die meisten Anwender regelmäßig mit neuer Software versorgt. Wenn das Problem in zwei, drei Jahren (es sind eher mehr) mal relevant wird, dann sollten über 90% der Linuxanwender bereits eine angepasste Version von gpg haben.
In der Windows-Welt geht das zwar weniger automatisch, dafür darf man annehmen, dass die Anwender von PGP zu den engagierteren Computernutzern gehören, sich die Neuerung zu Ihnen herumsprechen wird und sie sich auch nicht den Aufwand einer Sicherheitslösung machen, um die Software dann jahrelang nicht zu aktualisieren. Auch dort werden also die meisten eine hinreichend neue Version von gpg haben, bevor das Problem akut wird. Und die anderen werden überwiegend das Update nachholen, sobald sie zum ersten Mal mit einer Hash-ID konfrontiert werden.
Keine bekannt. Der Verfasser bittet um Vorschläge.
Schreiben Sie mir, was Sie von den oben ausgeführten Überlegungen halten!
Wenn Sie Ihre Meinung über dieses Konzept (im Sinne einer Bewertung des Verfassers, der "Qualität" des Grundgedankens) maximal vereinfachend zusammenfassen, finden Sie es dann eher gut oder eher schlecht (unabhängig davon, ob sie glauben, dass die Details korrekt sind und es so insgesamt funktioniert)?
Das ist natürlich erfreulich... Nehmen Sie das doch zum Anlass, sich anzusehen, zu welchen anderen Themen ich Vorschläge veröffentlicht habe. Auch wenn Sie diesen Text positiv bewerten, gibt es sicher Details, die Sie anders sehen. Ich freue mich, wenn Sie mir Ihre Anmerkungen per E-Mail mitteilen.
Und wenn Sie Unternehmer oder in geeigneter Position in einem Unternehmen tätig sind, das an Innovationen interessiert ist, dann sind vielleicht meine kommerziellen (nicht veröffentlichten) Konzepte für Sie von Interesse. Ich freue mich in dem Fall über Ihre Kontaktaufnahme.
Ihre Einschätzung ist für mich natürlich bedauerlich. Aber auch wenn ich wahrscheinlich nicht zu Ihrer Ansicht wechseln werde, möchte ich Sie doch ermuntern, mit per E-Mail mitzuteilen, was Sie problematisch finden (und ggf. warum).
Übersichtsseite aller Versionen dieses Dokuments mit digitalen Signaturen
Wenn in Ihrem Browser Javascript aktiviert ist, können Sie die Absätze, die sich von Version zu Version geändert haben, farblich markieren lassen, um auf einen Blick zu sehen, was zu lesen sich lohnt, wenn Sie einen ältere Version dieses Dokuments bereits kennen.