Vorschlag für eine Produktinnovation
Version 1.0/3.1, 06.07.2008
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 kein Problem, weil kaum jemand PGP benutzt. Keyserver abzufragen wäre vermutlich ein sinnlos hoher Aufwand für Spammer.
Da dies bisher kein praktisches, sondern nur ein absehbares Problem ist, scheinen sich darum nicht viele Leute zu kümmern.
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.
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. Es spricht außerdem nichts dagegen, zuerst nach dem nichtnormalisierten Hash zu suchen. 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 und bei Abfragen des Schlüsselbunds einfach die Originalangaben statt des Hashs zurückliefert.
Wenn gpg nicht in der genannten Weise geändert wird, kann man natürlich die gehashte ID manuell erzeugen. Das Exportieren nur der Hash-IDs wäre dann zwar aufwendig, aber das könnte zur Not ein Schlüsselverwaltungsprogramm erledigen. Auf jeden Fall sollte die Software, die das Hochladen der öffentlichen Schlüssel auf die Keyserver übernimmt, so modifiziert werden, dass sie keine Nicht-Hash-IDs hochlädt, wenn sie in dem jeweiligen Schlüssel auch (passende) Hash-IDs findet. Zumindest sollte der Benutzer gewarnt werden und den Vorgang bestätigen müssen.
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.
Der Aufwand ist minimal.
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. 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.
An der Linux-Front ist die Verbreitungsfrage unkritisch: Da werden sowieso die meisten Anwender regelmäßig mit neuer Software versorgt. Wenn das Problem in zwei, drei Jahren 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.