E-Mail-Verschluesselung und -Signierung ohne Zutun des Anwenders? (was: [Lösung Subjectwechsel])

[Helmut Waitzmann]

Michael Pachta <mip...@gmx.de>:

Zunächst:  Ich schlage den Umzug zu de.comp.security.misc vor, weil
mir das ein vom Mailer‐Programm unabhängiges Thema zu sein scheint.

>E-Mail-Verschlüsselung (und Signierung) wird sich erst dann auf
>breiter Front durchsetzen, wenn dies ohne Zutun des Anwenders
>läuft, also völlig transparent.

Wenn ein Schlüsselpaar einem Anwender (und nicht etwa einem Gerät,
einer Telefonnummer oder einer E‐Mail‐Adresse) zugeordnet sein soll,
muss der Anwender den Fingerprint selber prüfen.  Das geht ohne
Zutun des Anwenders nicht.

Wenn E‐Mail‐Verschlüsselung (und Signierung) ohne Zutun des
Anwenders läuft, macht er die Schlüsselverwaltung nicht mehr selber.

Beispielsweise könnten die Ver‐ und Entschlüsselung und die
Signatur‐Erstellung und ‐Prüfung vom E‐Mail‐Provider vorgenommen
werden, damit sich der Anwender nicht mehr darum kümmern muss.  Das
bedeutet, dass der private Schlüssel beim E‐Mail‐Provider liegen
muss.

Weil der Anwender sich aber nicht mehr darum kümmern will, bedeutet
das, dass der private Schlüssel nicht vom Anwender selbst erzeugt
und zum E‐Mail‐Provider hochgeladen wird, sondern vom
E‐Mail‐Provider an des Anwenders statt erzeugt werden muss.

Auch bedeutet es, dass die Anwender die öffentlichen Schlüssel ihrer
Kommunikationspartner nicht kennen, weil sie sich ja nicht mehr
darum kümmern müssen und wollen.  Damit werden
Man‐in‐the‐Middle‐Angriffe leicht möglich.


Ein Beispiel:


Alice <al...@provider1.example> und Bob <b...@provider2.example>
stehen miteinander in E‐Mail‐Kontakt.  Sie lassen die Ver‐ und
Entschlüsselung sowie die Signatur‐Erstellung und ‐Prüfung
transparent von ihren E‐Mail‐Providern erledigen:  Zum Versand
eingelieferte Nachrichten unterschreibt und verschlüsselt der
E‐Mail‐Provider automatisch; bei empfangenen Nachrichten prüft er,
ob sie eine ungebrochene Signatur tragen (und warnt anderenfalls).

Deshalb haben Alice und Bob mit dem öffentlichen Schlüssel ihres
Kommunikationspartners nichts zu tun und kennen ihn auch nicht.

Und nun stelle man sich vor, was geschieht, wenn Bob eines Tages
eine Nachricht (im folgenden Nachricht_1 genannt) von
<al...@provider3.example> erhält:

From: Alice <al...@provider3.example>
To: Bob <b...@provider2.example>
Subject: Ich habe eine neue E‐Mail‐Adresse

Hallo, Bob, ich habe eine neue E‐Mail‐Adresse:
<al...@provider3.example>

Viele Grüße

Alice

Bob wird von seinem E‐Mail‐Provider (wie bei jeder Nachricht, die
ihn unverfälscht erreicht) die Information erhalten, dass die
Nachricht die Signaturprüfung bestanden hat (denn der
provider3.example hat sie mit einem eigenen (neuen) Schlüssel, den
er für <al...@provider3.example> erzeugt hat, signiert).

Also schließt Bob, der sich mit Public‐Key‐Kryptografie nicht weiter
befassen will, messerscharf:  Mit der Nachricht ist alles in
Ordnung.  Er wird in sein Adressbuch als Alice' E‐Mail‐Adresse
<al...@provider3.example> eintragen und ihr vielleicht eine Antwort
(Nachricht_2) schicken:

From: Bob <b...@provider2.example>
To: Alice <al...@provider3.example>
Subject: Re: Ich habe eine neue E‐Mail‐Adresse

Hallo, Alice, Du schreibst:
>Hallo, Bob, ich habe eine neue E‐Mail‐Adresse:
><al...@provider3.example>

Habe ich notiert.

Herzliche Grüße

Bob


Daraufhin erhält Bob noch eine Nachricht (Nachricht_3):


To: Bob <b...@provider2.example>
From: Alice <al...@provider3.example>
Subject: Re: Ich habe eine neue E‐Mail‐Adresse

Hallo, Bob, Du schreibst:
>Hallo, Alice, Du schreibst:
>>Hallo, Bob, ich habe eine neue E‐Mail‐Adresse:
>><al...@provider3.example>
>
>Habe ich notiert.
>
>Herzliche Grüße
>
>Bob

Danke!

Viele Grüße

Alice


Alles ist gut? – Denkste!


In Wahrheit kommt die Nachricht, die Alice' neue E‐Mail‐Adresse
bekannt gibt, nämlich nicht von Alice sondern von Mallory, die sich
beim E‐Mail‐Provider provider3.example die E‐Mail‐Adresse
<al...@provider3.example> zugelegt hat.

Natürlich schickt Mallory Bobs Antwort (Nachricht_2) nicht Alice
<al...@provider1.example>, sondern bewahrt sie nur auf und erstellt
aus ihr die Nachricht_3, die sie Bob schickt.

Bob merkt nicht, dass er hinters Licht geführt worden ist, weil er
Alice' Zertifikat (den öffentlichen Schlüssel) nicht kennt und nicht
prüft – denn das macht ja sein E‐Mail‐Provider transparent für ihn.

Alice kann nichts merken, denn sie hat weder Bobs Antwort
(Nachricht_2) erhalten, noch hat sie die Nachricht_1 und die
Nachricht_3 zu Gesicht bekommen.

Wenn jetzt Mallory auf dem Posten ist, wird Bob auch in Zukunft
nichts merken:  Jede Nachricht, die Bob zukünftig Alice an
<al...@provider3.example> schreibt, kommt natürlich bei Mallory an. 
Mallory kann die Nachricht lesen (denn provider2.example hat sie
„transparent“ signiert und für sie verschlüsselt).  Dann erstellt
sie eine Kopie der Nachricht, ändert darin aber die
Adressaten‐Adresse von <al...@provider3.example> in
<al...@provider1.example> um.  Dann verschlüsselt sie sie für
<alice.provider1.example> und schickt sie Alice an
<alice.provider1.example>.

Jetzt muss Mallory dasselbe Spiel nochmal mit vertauschten Rollen
von Alice und Bob spielen und auch für Bob eine neue E‐Mail‐Adresse,
<rob...@provider2.example>, anlegen.  Dazu schickt sie Alice die
folgende Nachricht (Nachricht_4):

From: Bob <rob...@provider2.example>
To: Alice <al...@provider1.example>
Subject: Meine neue E‐Mail‐Adresse

Hallo, Alice,
ich habe eine neue E‐Mail‐Adresse:

<rob...@provider2.example>

Herzliche Grüße

Bob


Möglicherweise wird Alice antworten:


From: Alice <al...@provider1.example>
To: Bob <rob...@provider2.example>
Subject: Re: Meine neue E‐Mail‐Adresse

>Hallo, Alice,
>ich habe eine neue E‐Mail‐Adresse:
>
><rob...@provider2.example>

Ok.  Aber warum das denn?
Gefällt Dir <b...@provider2.example> nicht mehr?

Alice


Und Mallory wird zurückschreiben:


From: Bob <rob...@provider2.example>
To: Alice <al...@provider1.example>
Subject: Re: Meine neue E‐Mail‐Adresse

>>Hallo, Alice,
>>ich habe eine neue E‐Mail‐Adresse:
>>
>><rob...@provider2.example>
>
>Ok.  Aber warum das denn?
>Gefällt Dir <b...@provider2.example> nicht mehr?

Ich habe das Passwort der alten verloren und hatte weder eine
Sicherheitsabfrage noch eine Telefonnummer hinterlegt.


Beobachtungen:

Alle Nachrichten sind korrekt signiert und verschlüsselt.  Die
E‐Mail‐Provider werden also keinen Alarm schlagen.

Alice und Bob verwenden beide ihre bisherige E‐Mail‐Adresse
weiterhin, aber schreiben ihre Briefe an eine vermeintliche neue
E‐Mail‐Adresse ihres Briefkontakts.

Sie sind leichtgläubig der Nachricht von einer neuen E‐Mail‐Adresse
auf den Leim gegangen, anstatt bei der alten nachzufragen, ob das so
richtig ist.  Schließlich ist das doch gängige Praxis:  Jemand
verliert das Passwort für und somit den Zugriff auf seine bisherige
E‐Mail‐Adresse und benachrichtigt seine Kommunikationspartner –
natürlich von der neuen E‐Mail‐Adresse aus, denn die bisherige kann
er nicht mehr nutzen.

Dadurch, dass der E‐Mail‐Provider und nicht der Absender die
Nachricht signiert und verschlüsselt, wird mit dem Auswechseln der
E‐Mail‐Adresse zwangsläufig auch das Schlüsselpaar ausgetauscht.  Da
das ohne Zutun des Absenders geschieht und die Empfängerin die
Schlüssel sowieso nicht kennt, bemerkt sie das nicht einmal.

Wenn hingegen die Schlüsselverwaltung bei Alice selbst liegt, wird
sie sofort bemerken, dass sie Bobs neues Zertifikat nicht kennt,
genauer: nicht selbst zertifiziert hat und auch im Web of Trust
keine Verbindung zu ihm findet.  Damit weiß sie:  Die Nachricht
stammt höchstwahrscheinlich nicht von Bob sondern ist möglicherweise
ein Man‐in‐the‐middle‐Angriff.  Wenn sie jetzt Bob
<b...@provider2.example> eine für Bobs bisherigen Schlüssel
verschlüsselte signierte Rückfrage schreibt, fällt Bob aus allen
Wolken, und sie erhält eine Antwort von ihm – natürlich mit seinem
bisherigen Schlüssel unterschrieben – und es kommt an den Tag:  Da
versucht jemand, Alice einen falschen Schlüssel für Bob
unterzujubeln.

Dasselbe geschieht umgekehrt mit vertauschten Rollen von Alice und
Bob, wenn Bob die Schlüsselverwaltung selber macht.

[Christian Garbs]

Mahlzeit!

Helmut Waitzmann <nn.th...@xoxy.net> wrote:
> Michael Pachta <mip...@gmx.de>:
>
> Zunächst:  Ich schlage den Umzug zu de.comp.security.misc vor, weil
> mir das ein vom Mailer‐Programm unabhängiges Thema zu sein scheint.
>
>>E-Mail-Verschlüsselung (und Signierung) wird sich erst dann auf
>>breiter Front durchsetzen, wenn dies ohne Zutun des Anwenders
>>läuft, also völlig transparent.
>
> Wenn ein Schlüsselpaar einem Anwender (und nicht etwa einem Gerät,
> einer Telefonnummer oder einer E‐Mail‐Adresse) zugeordnet sein soll,
> muss der Anwender den Fingerprint selber prüfen.  Das geht ohne
> Zutun des Anwenders nicht.
>
> Wenn E‐Mail‐Verschlüsselung (und Signierung) ohne Zutun des
> Anwenders läuft, macht er die Schlüsselverwaltung nicht mehr selber.
>
> Beispielsweise könnten die Ver‐ und Entschlüsselung und die
> Signatur‐Erstellung und ‐Prüfung vom E‐Mail‐Provider vorgenommen
> werden, damit sich der Anwender nicht mehr darum kümmern muss.  Das
> bedeutet, dass der private Schlüssel beim E‐Mail‐Provider liegen
> muss.

Hier kann man glaube ich abkürzen und sagen, dass das grob¹ auf TLS
zwischen den beteiligten Mailservern hinausläuft, also ungefähr den
Status quo, den es zu verbessern gilt ;-)

Gruß
Christian

¹ Das bisherige Server-Zertifikat entspräche dann vielleicht einem
Intermediate, unter dem pro Mailadresse ein Zertifikat generiert wird.
Da der Empfänger-Server aber maximal das Intermediate "kennt" (falls
es ihm sein Admin manuell eingetragen hat), bleibt alles beim alten.
--
....Christian.Garbs....................................https://www.cgarbs.de
hash bang slash bin slash bash