Privacy Handbuch

Das Verfahren Autocrypt will den Nutzern den manuellen PGP-Schlüsselaustausch abnehmen und ihn dadurch nutzerfreundlich machen. Der PGP-Schlüssel soll im Header jeder E-Mail mitgesendet werden, damit der Empfänger sofort automatisch verschlüsselt antworten kann, ohne sich um den Schlüsseltausch (und Validierung?) kümmern zu müssen.

Für die theoretische Begründung der Sicherheit greift Autocrypt auf das Konzept Opportunistic Security (RFC 7435) zurück. Das bedeutet, das die Verschlüsselung nur noch gegen passive Angreifer schützt soll aber nicht mehr gegen aktive Angreifer, die sich als Man-in-the-Middle in die Kommunikation einschleichen können.

Wenn jemand Opportunistic Security verspricht, dann funktioniert die Verschlüsselung ganz gut, solange sich niemand ernsthaft für die Kommunikation interessiert. Gegen einen ernsthaften, aktiven Angriff bietet dieses Konzept keinen Schutz und man muss im Zweifel davon ausgehen, dass die Verschlüsselung kompromittiert werden kann.

Opportunistic Security bietet ausdrücklich nur Some Protection Most of the Time. Das Konzept ist unbrauchbar für alle, die aus ersthaften Gründen ihre E-Mail Inhalte verschlüsseln wollen bzw. verschlüsseln müssen und nicht nur aus Spielerei ein bisschen rumdaddeln.

Wie könnte ein bösartigen E-Mail Provider die Verschlüsselung kompromittieren?

Die E-Mail Header werden von den Mailprovidern ständig routiniert manipuliert. Es werden neue Header eingefügt, einige Header werden gelöscht.... In gleicher Weise könnten die Autocrypt Header von den versendenden oder empfangenen E-Mail Providern manipuliert werden und ein falscher Schlüssel eingefügt werden.
Es ist keine kryptografische Validierung der OpenPGP Schlüssel vorgesehen, die im Autocrypt Header gesendet werden. Der E-Mail Client soll den jeweils neuesten Schlüssel ohne Überprüfung akzeptieren. Wenn ein E-Mail Provider den PGP Schlüssel im Autocrypt Header gegen einen falschen Key austauscht, dann wird der Empfänger der Mail diesen falschen Schlüssel mit hoher Wahrscheinlichkeit verwenden.
Wenn ein Antwort geschrieben wird, kann der E-Mail Provider natürlich erkennen, dass eine Mail mit dem Fake Schlüssel verschlüsselt wurde. Er entschlüsselt die Mail, nimmt den Inhalt zu Kenntnis und verschlüsselt sie dann mit dem richtigen Schlüssel, bevor er sie zustellt. Das Opfer bemerkt nicht, dass der PGP Schlüssel ausgetauscht wurde.

Dieses Szenario ist kein Bug sondern ein Feature des zugrunde liegenden Konzeptes.

Das ein solches Szenario nicht nur theoretisch sondern auch in der Praxis relevant sein kann, hat der E-Mail Provider Hushmail demonstriert. 2007 wurde Hushmail von der US-amerikanische DEA gezwungen, die Verschlüsselung für einige Kunden mit gefälschten Schlüsseln zu kompromittieren. Und die Spezialisten der deutschen Behörde ZITiS klatschen bestimmt vor Freude in die Hände, wenn Autocrypt großflächig eingesetzt wird.

Ende-zu-Ende Verschlüsselung soll den Inhalt von E-Mails gegen Beobachtung durch die E-Mail Provider schützen. Der E-Mail Provider ist der potentielle Angreifer, gegen den Ende-zu-Ende Verschlüsselung schützen soll! Eine E2E-Verschlüsselung, die nur unter der Vorraussetzung funktioniert, dass der E-Mail Provider vertrauenswürdig ist, ist Bullshit.

Der Autocrypt Schlüsseltausch erfordert es, dass man dem E-Mail Provider vertrauen muss und führt damit Ende-zu-Ende Verschlüsslung mit OpenPGP ad absurdum. Es kompromittiert die angestrebten Sicherheitsziele zugunsten (zweifelhaften) Vereinfachung der Usability. Leider aktivieren viele OpenPGP Tools Autocrypt standardmäßig.

In der Entwickler Community sind die Ansichten gespalten. Bei dem Mailvelope Browser Add-on wurde Autocrypt implementiert und standardmäßig aktiviert, die Entwickler von KMail arbeiten ebenfalls daran. Die Thunderbird Entwickler ermöglichen den Import der Schlüssel aus dem E-Mail Header aber übernehmen keine Schlüssel automatisch, wie es der Autocrypt Standard vorsieht.