Version 1.2, 13.03.2014
Mailprovider sind aus mehreren Gründen wichtig für die Verbreitung von Kryptografie-Know-How:
Sie haben den idealen Zugriff auf die Nutzer: Sie können – ganz unaufdringlich nebenbei – im passenden Moment (der Nutzer ist gedanklich bei der Einrichtung seiner Mailsoftware) Informationen über das Thema anbieten.
Nur sie können die technischen Änderungen vornehmen, die für manche Fortschritte auf diesem Gebiet nötig sind.
Deshalb sind an Mailprovider spezielle Forderungen zu richten, über die an normale Internetunternehmen hinaus.
Auf den Verwaltungsseiten für Mailaccounts soll in geeigneter Weise auf das Thema Kryptografie hingewiesen werden. Ein einzelner Link Informationen über E-Mail-Verschlüsselung
auf eine entsprechende Hilfe-Seite wäre ausreichend; die Usability der Seite würde also nicht beeinträchtigt.
Auf dieser Seite sollten dann (eventuell neben einem selbstverfassten Text zum Thema) Links zu drei Kategorien stehen, weil Schulungsmöglichkeiten und die Steigerung der Präsenz des Themas ähnlich wichtig sind wie die Informationen selber:
| Informationen | http://www.openpgp-schulungen.de/fuer/alle/ |
|---|---|
| Schulungsangebote | https://www.cryptoparty.in/location#germany |
| Förderung | http://www.openpgp-schulungen.de/fuer/unterstuetzer/ |
Sollte der Provider spezielle Angebote bezüglich dieses Themas haben (oder planen), sollten die dort natürlich auch erwähnt werden.
Die Kunden sollten ihre Mailboxen (oder Adressen, also auch Weiterleitungen) so konfigurieren können, dass eingehende Mails, die nicht verschlüsselt sind, vor der Einlieferung verschlüsselt werden. Man könnte das so handhaben, dass der Kunde ein dediziertes Schlüsselpaar für diesen Zweck generiert, dessen "öffentlicher" Schlüssel nur dem Mailprovider bekannt ist; dadurch könnte der Empfänger trivial erkennen, ob die Mail vom Absender oder dem Mailprovider verschlüsselt wurde. Die Länge dieses Mailprovider-Schlüssels könnte man auf das Minimum dessen begrenzen, was die maßgebliche Software (also GnuPG) bei der Erzeugung unterstützt (also derzeit 1024 Bit für RSA und ElGamal/DH), um die dadurch anfallende CPU-Last zu minimieren.
Vorstellbar ist (etwa für ein kostenloses Angebot) auch, dies dadurch noch weiter zu optimieren, dass der session key mehrfach verwendet wird (dafür müsste GnuPG gepatcht werden), also in einer Phase minimaler Rechnerauslastung für diese Kunden session keys generiert werden, die dann für etwa 24 h verwendet werden. So ist es nicht gedacht, aber das gilt ja auch schon für den Umstand, dass nicht der Absender die Mail verschlüsselt, und besser als nichts ist es allemal.
Dadurch würde verhindert, dass die Behörden bei einer Abhöranordnung (oder mit einem Durchsuchungsbeschluss) die Mailkorrespondenz bis in eine beliebige Vergangenheit nachvollziehen könnten. Wenn jemand seit 20 Jahren dieselbe IMAP-Mailbox verwendet und die mehrere 10.000 Mails enthält, dann ist das ein ganzes digitales Leben. Es ist rechtsstaatlich kaum zu begründen, warum die Behörden darauf einfach mal so Zugriff bekommen sollen. Dass sie den bei einer Hausdurchsuchung hätten, ist kein Argument. Den heimischen Rechner kann man verschlüsseln, den Providerserver nicht (strenggenommen kann man natürlich eingehende Mails mit ihrer verschlüsselten Version unterschreiben, ändert damit aber deren Zeitstempel).
Man sollte leicht nachweisen können, dass man eine Mail in genau dieser Form bekommen hat, und das sollte man auch dann können, wenn die Mail nicht mehr auf dem Server des Providers liegt (oder der nicht ausschließen kann, dass man sie nicht per IMAP verändert hat).
Die aufwendige Möglichkeit, dies zu erreichen, ist die Erzeugung einer Signatur für alle eingehenden Mails. Das erzeugt aber beachtlichen Rechenaufwand und brächte allerlei technische Probleme mit sich. Alternativ könnte der Provider einfach einen sicheren Hashwert für die Mail erzeugen, so, wie sie aussieht, wenn sie in der Mailbox des Kunden landet. Diese Hashwerte könnten dann gesammelt werden, und einmal am Tag, wenn die Auslastung der Systeme minimal ist, würde die Hashliste der letzten 24 h signiert und dem Kunden gemailt.
Wer nur Webmail nutzt, aber selber noch kein Schlüsselpaar hat, sollte dem Mailprovider öffentliche Schlüssel seiner regelmäßigen Kontakte übermitteln können. Der Mailprovider würde dann eventuell vorhandene Signaturen gegen diese Liste prüfen und anzeigen, von welchem Schlüssel eine Mail signiert wurde. Auf diese Weise wären die Kunden vor bestimmten Angriffen geschützt.
Manche Webmailprovider machen Ähnliches bereits ohne Signaturen: Sie prüfen auf andere Weise, ob eine Mail von einer Whitelist von Absendern stammt und zeigen das entsprechend an.
Wer nur Webmail nutzt, aber selber noch kein Schlüsselpaar hat, sollte dem Mailprovider öffentliche Schlüssel seiner regelmäßigen Kontakte übermitteln können. Mails an diese Empfänger könnte der Mailprovider dann auf fallweisen Wunsch verschlüsselt versenden.
Der Webmailprovider könnte ein Schlüsselpaar erzeugen, das klar als solches erkennbar ist etwa:
Max Mustermann (ISP key / Schlüssel des Mailproviders) <max.mustermann@example.com>
Auch technisch würde der Schlüssel als nicht allein im Besitz des Mailempfängers markiert (group key (RfC 4880 (5.2.3.21)).
Dann könnte der Kunde – mit entsprechend reduzierter Sicherheit – alles machen. Der Reiz dieser Lösung liegt darin, dass sie schlagartig einer großen Menge an Nutzern zur Verfügung stünde.
Die Provider sollten die Möglichkeit schaffen, (per Webinterface) einer Adresse ein Zertifikat zuzuordnen, und die zu dieser Adresse gehörende(n) UIDs des Zertifikats entsprechend signieren. Der dafür verwendete Schlüssel sollte nur für diesen Zweck verwendet werden, und die Signatur sollte eine policy URL und eine (idealerweise standardisierte) notation bekommen, die deutlich macht, dass nur die E-Mail-Adresse bestätigt wird.
Man braucht dann zwar in den meisten Fällen nur das E-Mail-Passwort, um an diese Zertifizierung zu kommen, aber das ist kein Problem, denn damit kann man auch die übliche Variante der E-Mail-Verifizierung aushebeln. Der Provider ist gegenüber den anderen Zertifizierern dahingehend im Vorteil, dass er über einen längeren Zeitraum sicherstellen kann, dass das hinterlegte Zertifikat korrekt ist. Wenn er entsprechenden Aufwand treiben möchte, schickt er über einen entsprechend langen Zeitraum wöchentlich oder monatlich eine Mail (das dürfte einfacher sein als eine Änderung des Webinterface), die der Nutzer nicht löschen oder verschieben kann und die darauf hinweist, dass dieses Zertifikat hinterlegt wurde. Der Provider könnte die Zertifizierung auch verzögern, bis dieser Prüfzeitraum abgelaufen ist.
13.02.2014
Für einzelne Adressen sollte der Nutzer konfigurieren können, dass Mails, die nicht verschlüsselt oder signiert ist, nicht zugestellt wird. Das löst (auf absehbare Zeit) wirksam das Spam-Problem und ist außerdem ein hilfreiches Signal. Wer sich diese Haltung leisten kann (z.B. Prominente), leistet einen Beitrag zur Kryptoverbreitung, wenn er nur noch in dieser Weise (ohne Umwege) erreichbar ist. Alleine schon die Einrichtung einer zweiten E-Mail-Adresse, die bevorzugt behandelt wird, dürfte eine Menge bewirken. Ein solcher Filtermechanismus wäre für die Willigen eine erhebliche Erleichterung. Eine nette Ergänzung wäre, dass der Nutzer die Fehlermeldung vorgeben kann.
Eine naheliegende Ergänzung dieser Funktion ist, dass nur solche E-Mails zugestellt werden, die von einem Schlüssel signiert sind, der auf der jeweiligen Whitelist steht. Das ist derzeit bei verschlüsselten Mails problematisch. Es ist wünschenswert, dass die Mailprovider sich mit den Entwicklern der Krypto-Mailclients zusammensetzen, um sich auf die Gestaltung einer immer unverschlüsselten "Transport-Signatur" zu einigen, die einerseits die Headerinformationen sichert und andererseits auch bei verschlüsselten Nachrichten den Absender authentifiziert.