Emailverschlüsselung

Workshop E-Mail-Verschlüsselung

  • Herzlich willkommen zum Workshop E-Mail-Verschlüsselung!
  • Im Workshop E-Mail-Verschlüsselung geht es darum, Eure Emailprogramme so einzurichten, dass Ihr signierte und verschlüsselte Emails senden und empfangen könnt.

Inhaltsverzeichnis

Inhaltsverzeichnis

Vorwort

  • Dieser Workshop lebt von Eurer Mitarbeit und Eurer eigenen Neugier. Stellt also jederzeit Fragen und wenn Ihr etwas besser zu wissen meint als Euer Betreuer, erklärt die Sache ruhig Eurem Betreuer und Euren Kollegen. Im digitalen Neuland - wie Frau Merkel mal sagte - ist es schwer, immer auf dem neuesten Stand zu sein und in allem der Experte zu sein.
  • Wir würden Euch empfehlen, dass Ihr Euch zu zweit oder zu dritt zusammensetzt und die angesprochenen Schritte und Vorschläge auf dieser Seite mal ausprobiert, wobei gilt, nichts muss, alles kann. Wenn Ihr einen Schritt nicht sinnvoll findet, lasst ihn aus oder probiert etwas anderes aus.
  • Bitte helft einander und tauscht Euch aus, sofern es geht. Erstens lernt man gemeinsam viel schneller und zweitens entlastet dies Euren Betreuer, sodass er sich hauptsächlich um die schwierigeren Fälle kümmern kann.
  • Wir haben uns auch bemüht, viele Begriffe und Themen mit (roten) Links zu versehen, die Euch zu weiteren Informationen führen oder den Begriff genauer erklären. Schaut Euch also ruhig den einen oder anderen verlinkten Artikel mal an. Teilweise verweisen wir auch direkt auf Wikipedia-Artikel, wenn uns dort die Beschreibung geeignet erschien.

Motivation

  • Tagtäglich senden und empfangen wir dutzende Emails. Aber sind wir uns immer sicher, dass die Emails, die wir empfangen, vom eigentlichen Adressaten stammen und wollen wirklich, dass jeder Serverbetreiber - falls er möchte - all unsere Emails problemlos mitlesen kann?
  • Zwar rufen die meisten von uns Ihre Emails mittels einer SSL-verschlüsselten Verbindung vom Server Ihres Emailanbieters ab und versenden Ihre Emails unter Verwendung einer TLS-verschlüsselten Verbindung (TLS = Weiterentwickelte Version von SSL), aber das bedeutet nur, dass die Emails zwischen Euch und dem Server Eures Emailanbieters verschlüsselt und damit gesichert übertragen werden. Dies bezeichnet man als Ende-zu-Server Verschlüsselung.
  • Dummerweise werden die Emails, die von einem Emailanbieter (z.B. Googlemail) an einen anderen Emailanbieter (z.B. Web.de) weitergereicht / gesendet werden, überhaupt nicht verschlüsselt übertragen.
  • Also gibt es bei normalen Emails leider keine sogenannte Ende-zu-Ende Verschlüsselung, bei der die Email über den gesamten Weg vom Absender bis Empfänger verschlüsselt übertragen wird.
  • Eine solche Ende-zu-Ende Verschlüsselung sieht nämlich der SMTP-Standard, der für das Versenden von Emails verwendet wird, nicht vor. Zu seiner Verteidigung: Die erste Email wurde bereits 1971 verschickt und der Standard selbst wurde bereits 1982 verabschiedet wurde - damals war Netzsicherheit noch kein großes Thema.
  • Selbst wenn man nur Emails innerhalb eines Anbieters versendet oder Emails nur zwischen den Anbietern von "E-Mail made in Germany" (GMX, Telekom, Web.de, Freenet, Strato, 1und1), so kann sie der Serverbetreiber immer noch lesen, sofern er dies möchte. Dies bedeutet im Umkehrschluss aber auch, falls jemand irgendwann den Server Eures Emailanbieters hackt, kann er mit aller Wahrscheinlichkeit all Eure Emails lesen, die auf dem Server gespeichert sind.
  • Sobald der Hacker Zugriff auf Euer Emailkonto hat, wird er vermutlich Euer Adressbuch nutzen, um Spammails oder Schlimmeres unter Verwendung Eures Absenders an alle Kontakte zu schicken. Derartiges kam erst kürzlich bei T-Online vor.
  • Darüber hinaus kann euer Emailaccount genutzt werden, um die Passwörter alll Eurer anderen Internetbenutzerkonten in Erfahrung zu bringen. Zum Glück ist dies den meisten Hackern aber zu viel Aufwand für unbedeutende Einzelpersonen.
  • Nebenbemerkung: Dennoch sollte euch bewusst sein, dass Euer Emailpasswort eines der wichtigsten und vor allem schützenswertesten Passwörter überhaupt ist! Denn wie viele Passwörter von anderen Internetbenutzerkonten wie Facebook, Amazon, Dropbox usw. habt Ihr schon unter Verwendung Eures Emailaccounts zurückgesetzt? Euer Emailaccount ist der Schlüssel zu allen Euren Internetaktivitäten und trotzdem gebt Ihr dieses Passwort (vermutlich mehrmals die Woche) im Internetbrowser ein, weil Ihr mal schnell über die Weboberfläche Eures Emailanbieters Emails checken wollt.
  • Pro-Tipp: Keylogger und Trojaner warten heutzutage nur darauf, Zugriff zu eurem Emailkonto zu erlangen, indem sie Euren Benutzernamen und Euer Passwort beim Eintippen in die Weboberfläche auslesen. Solltet Ihr Euch also irgendwann mal einen Trojaner einfangen, ist häufig relativ bald auch Euer Emailpostfach betroffen. Deshalb: Verzichtet besser auf die Weboberfläche. Nur in dringenden Fällen und wenn Ihr wisst, dass der jeweilige PC wirklich sauber ist, solltet Ihr diese Zugriffsmöglichkeit nutzen - denn die eigentlichen Emailprogramme sind sehr viel besser geeignet: Sie speichern Eure Emailzugangsdaten verschlüsselt, sodass jeder Trojaner erst einmal außen vor ist.
  • Gegen das Versenden von Emails unter falscher Absenderemailadresse, das sogenannte E-Mail-Spoofing, wurden seit ca. 2004 erste Schritte von Seiten der Emailanbieter unternommen, indem das sogenannte Sender Policy Framework (SPF) eingeführt wurde.
  • Bei SPF wird für jede Internetdomain der zugehörige Emailserver im Domain Naming System (DNS), dem globalen Verzeichnis aller Domains, hinterlegt. Dadurch kann jeder Emailserver, der eine Email (z.B. mit Absender moc.inmulabal|inmulabal#moc.inmulabal|inmulabal) erhält, überprüfen, ob der Ursprungsserver (boeserserver.de) der Email dazu berechtigt war, eine Email mit dem betreffenden Absender (moc.inmulabal|inmulabal#moc.inmulabal|inmulabal) zu senden. Falls nicht (labalumni.com ungleich boeserserver.de), lehnt der Empfängerserver die Email ab.
  • Leider unterstützten manche Emailanbieter, wie die Telekom (Stand: Juli 2014), bis heute dieses Verfahren nicht, sodass deren Nutzer immer noch Emails mit gefälschten Absender erhalten können. Dies wird dann auch gerne zum Phishing, dem Abgreifen von Benutzerdaten durch Versenden gefälschter Emails, genutzt.
  • Da viele Firmen aber selber auch keinen SPF-Eintrag im DNS-System setzen, kann jeder von uns leider auch gefälschte Emails im Namen dieser Firmen erhalten.
  • Die einzige sichere Abhilfe bislang ist, dass jeder von uns seine Emails mit Hilfe von PGP/GPG oder S/MIME zumindest signiert, sodass der Empfänger jeweils selbst überprüfen kann, ob die Email wirklich vom Sender stammt.
  • Dieses Signieren von Emails werden wir in diesem Workshop kennenlernen.
  • Vom Emailsignieren ist es dann auch nur noch ein kleiner Schritt zur Emailverschlüsselung, bei der wir eine echte Ende-zu-Ende Verschlüsselung verwenden werden.
  • Übrigens: Zugegebenermaßen gibt es aber auch ein paar Nachteile bei der Verwendung von OpenPGP und S/MIME, auf die wir noch später zu sprechen kommen. Doch selbst wenn jemand die Emailverschlüsselung für zu umständlich halten sollte, so ist auf jeden Fall das Signieren von Emails empfehlenswert, da damit der Absender immer klar ersichtlich ist.

Nebenbemerkung zum Verweisen auf Grafiken statt dem Einbinden derselben

  • Auf Grund des Urheberrechtes und den vielen daraus resultierenden Fragen beim Einbinden von Grafiken, werden wir hier auf Grafiken immer nur verweisen.
  • Allerdings werden wir die eine oder andere Grafik verwenden, um Euch zu verdeutlichen, worum es geht, wie zum Beispiel im nächsten Abschnitt.

Grundsätzliches Prinzip bei Ende-zu-Ende Verschlüsselung und bei Emailverschlüsselung

Symmetrische Verschlüsselung

  • Schaut Euch bitte die folgende Grafik auf der folgenden Webseite an.
  • Die oben genannte Grafik zeigt schematisch, wie das Verschlüsseln und Entschlüsseln eines Textes prinzipiell abläuft. Der Text wird zusammen mit einem geheimen Schlüssel an einen Verschlüsselungsalgorithmus übergeben, abhängig vom verwendeten Schlüssel wird daraus ein chiffrierter Text erzeugt:
    • In der einfachsten Form würde der Versender einer Email diesen chiffrierten Text erst lokal auf seinem Rechner erzeugen und danach den chiffrierten Text in eine Email kopieren und an den Empfänger senden.
    • Der Empfänger müsste dann den geheimen Schlüssel kennen, um mittels des gleichen, in umgekehrter Reihenfolge ausgeführten Algorithmus aus dem chiffrierten Text und dem geheimen Schlüssel wieder den ursprünglichen Text zu erhalten.
  • Gute Verschlüsselungsalgorithmen zeichnen sich nun dadurch aus, dass es eine fast unbegrenzte Anzahl an möglichen Schlüsseln gibt und dass es nahezu unmöglich ist, nur durch Ausprobieren auf den richtigen geheimen Schlüssel zu kommen und damit den ursprünglichen Text zu erhalten.
  • Das Verfahren, welches wir eben kennengelernt haben, nennt man symmetrische Verschlüsselung, da sowohl Sender als auch Empfänger den geheimen Schlüssel kennen müssen.
  • Es ist zu bemerken, dass beide Parteien unter Verwendung desselben geheimen Schlüssels sowohl Sender als auch Empfänger sein können.
  • Problematisch an diesem Verfahren ist, dass man natürlich auf irgendeinem Weg mal den geheimen Schlüssel ausgetauscht haben muss. Dies macht man natürlich am besten auf einem anderen Kommunikationskanal (z.B. Nennen des geheimen Schlüssels am Telefon statt Senden per Email). Denn falls man denselben Kommunikationskanal verwenden würde, müsste ein Dritter nur zum richtigen Zeitpunkt gelauscht haben und würde neben den chiffrierten Nachrichten auch den geheimen Schlüssel kennen.
  • In der Praxis hat sich dieses Verfahren daher als eher unpraktisch erwiesen.
  • Ein Vorteil an diesem Verfahren, auf den wir gleich noch genauer zu sprechen kommen, ist jedoch, dass das symmetrische Ver- und Entschlüsseln sehr wenig Rechenzeit benötigt.

Asymmetrische Verschlüsselung

  • Schaut Euch nun bitte die nachfolgende Grafik auf der folgenden Seite an.
  • Ihr seht hier eine Darstellung der sogenannten asymmetrischen Verschlüsselung.
  • Zunächst schauen wir uns den oberen Weg an:
    • Hier will die linke Partei, nennen wir sie - wie in der Informatik gebräuchlich - Alice, einen Text an die andere Partei, in der Informatik häufig Bob genannt, schicken.
    • Alice besitzt dafür den sogenannten öffentlichen Schlüssel von Bob. Dieser Schlüssel heißt öffentlich, weil jeder ihn kennen darf.
    • Mit dem öffentlichen Schlüssel und einem Algorithmus verschlüsselt Alice nun ihren Text an Bob und erhält einen chiffrierten Text.
    • Diesen chiffrierten Text sendet Alice nun z.B. in einer normalen Email an Bob.
    • Bob verwendet nun seinen geheimen, sogenannten privaten Schlüssel und einen anderen Algorithmus, um den chiffrierten Text zu entschlüsseln und wieder den ursprünglichen Text zu erhalten.
    • Wichtig ist hierbei, dass der private Schlüssel von Bob geheim bleiben sollte, da man nur mit dem privaten Schlüssel den chiffrierten Text entschlüsseln kann.
    • Währenddessen sollte möglichst jeder Bobs öffentlichen Schlüssel kennen, da damit jeder Nachrichten an Bob verschlüsseln kann.
    • Man teilt also gegenüber der symmetrischen Verschlüsselung das Ver- und Entschlüsseln bzw. genauer die dafür benötigten Schlüssel auf - in einen öffentlichen und einen privaten Schlüssel.
  • Da momentan Alice nur Nachrichten verschlüsseln kann und Bob nur entschlüsseln, gibt es nun auch noch den unteren Weg, über den auch Bob an Alice verschlüsselte Nachrichten schicken kann:
    • Hierbei besitzt Alice einen eigenen, anderen privaten Schlüssel und Bob kennt den zugehörigen öffentlichen Schlüssel.
    • Unter Verwendung von Alice öffentlichen Schlüssel und dem Verschlüsselungsalgorithmus kann Bob Nachrichten nun chiffrieren, die anschließend Alice mit dem privaten Schlüssel und dem Entschlüsselungsalgorithmus wieder entschlüsseln kann.
  • Das Interessante an asymmetrischer Verschlüsselung ist also, dass immer nur eine Seite den geheimen Schlüssel kennen muss und der öffentliche Schlüssel problemlos publik gemacht werden kann.
  • Es ist daher nicht notwendig (und sollte auch unterlassen werden), auf irgendeine Weise die geheimen Schlüssel auszutauschen.
  • Die asymmetrischen Verschlüsselungsalgorithmen sie sind jedoch im Gegensatz zur symmetrischen Verschlüsselung sehr rechenintensiv und damit langsam, wenn größere Datenmengen ver- und entschlüsselt werden müssen.
  • Aus diesem Grund hat man eine Mischform aus beiden Verschlüsselungsvarianten entwickelt - das Beste aus beiden Welten sozusagen. Diese wird nachfolgend dargestellt.
  • Bitte beachtet, dass man bei asymmetrischer Verschlüsselung immer von einem öffentlichen und einem privaten Schlüssel spricht, wobei letzterer geheim bleiben muss.
  • Währenddessen spricht man bei symmetrischer Verschlüsselung immer nur von einem geheimen Schlüssel.
  • Gerade im nächsten Abschnitt wird es wichtig beides auseinanderzuhalten.

Asymmetrische Verschlüsselung für den Austausch eines symmetrischen Schlüssels

  • Zur Erklärung dieser Mischform gehen wir wieder von der obigen Grafik und unserem Beispiel mit Alice und Bob aus.
  • Weiterhin stellen wir uns vor, dass Alice einen wirklich langen Text oder eine sehr große Datei an Bob schicken will. Wegen der Größe des Textes ist die asymmetrische Verschlüsselung des ganzen Textes keine Option, daher folgendes Vorgehen:
    • Im Unterschied zu vorhin überlegt sich Alice zunächst willkürlich einen geheimen Schlüssel und verwendet diesen geheimen Schlüssel zusammen mit der schnellen symmetrischen Verschlüsselung, um den langen Text zu verschlüsseln.
    • Gemäß unseren Überlegungen zur symmetrischen Verschlüsselung würde es nun reichen, wenn Bob den geheimen Schlüssel (sym. Verschlüsselung) kennen würde, damit er (ebenfalls sehr schnell) den Text wieder entschlüsseln kann.
    • Statt eines herkömmlichen Schlüsselaustauschs nutzen wir jetzt allerdings die asymmetrische Verschlüsselung, um Bob den geheimen Schlüssel (sym. Verschlüsselung) mitzuteilen.
    • Alice nutzt jetzt Bobs öffentlichen Schlüssel (Achtung: Asymmetrische Verschlüsselung), um damit den willkürlichen und temporär erzeugten geheimen Schlüssel (sym. Verschlüsselung) auch noch (mittels dem anderen asymmetrischen Verschlüsselungsalgorithmus) zu verschlüsseln.
    • Anschließend kann Alice den symmetrisch verschlüsselten Text und den asymmetrisch verschlüsselten, geheimen Schlüssel an Bob schicken.
    • Bob nutzt dann seinen privaten Schlüssel (Asymmetrische Verschlüsselung), um erst einmal nur den asymmetrisch verschlüsselten, geheimen Schlüssel zu entschlüsseln.
    • Sobald Bob den geheimen Schlüssel kennt - derjenige, den Alice und Bob auf asymmetrisch verschlüsselte Weise ausgetauscht haben - kann Bob mit diesem den symmetrisch verschlüsselten Text entschlüsseln.
  • Bei diesem Verfahren wird als nur der geheime Schlüssel, der relativ klein und daher schnell ver- und entschlüsselt werden kann, asymmetrisch verschlüsselt und ausgetauscht, während der große Text symmetrisch mit einem temporären geheimen Schlüssel ver- und entschlüsselt wird.
  • Vorteilhaft ist also der sichere Schlüsselaustausch dank Einsatz der asymmetrischen Verschlüsselung und die zügige Ver- und Entschlüsselung durch Verwendung von symmetrischer Verschlüsselung für den eigentlichen Inhalt.
  • Man spricht bei diesem Verfahren auch von "hybrider Verschlüsselung", weil man beide Verschlüsselungsarten miteinander kombiniert.
  • Wenn Ihr dies verstanden habt, habt Ihr wirklich die wichtigsten Grundlagen von Ende-zu-Ende Verschlüsselung und damit auch von Emailverschlüsselung sowie der verschlüsselten Datenübertragung im Internet begriffen! Respekt!
  • Dieser Erkenntnisgewinn wird Euch auch beim Verstehen vieler anderer Abläufe wie zum Beispiel der Verschlüsselung von Webseiten zwischen Server und Eurem Internetbrowser sehr helfen, denn im Prinzip kommt in allen Bereichen, wo heutzutage Verschlüsselung eingesetzt wird, eines der drei Verfahren zum Einsatz. Sehr häufig, aus den zuvor genannten Gründen, die zuletzt besprochene Mischform / hybride Verschlüsselung.
  • Im Einzelnen unterscheiden sich die eingesetzten Verfahren dann hinsichtlich der konkreten Algorithmen (RSA und Blowfish sind z.B. bekannte Algorithmen). Ein weiterer Unterschied ist das Verfahren zur Verteilung und Beglaubigung der öffentlichen Schlüssel.

Verteilen und Beglaubigen von Schlüsseln

Warum ist Verteilen der Schlüssel wichtig?

  • Jeder der Euch eine verschlüsselte Nachricht senden oder eine von Euch signierte Email prüfen möchte, muss Euren öffentlichen Schlüssel kennen - daher solltet Ihr diesen immer mitsenden! Allerdings erscheint der öffentliche Schlüssel bei den meisten Emailprogrammen des Empfängers dann als Anhang und nimmt somit natürlich zusätzlichen Platz weg.
  • Alternativ könnt Ihr Euren öffentlichen Schlüssel auch auf einen öffentlichen Schlüsselserver hochladen. Allerdings solltet Ihr Euch dann dessen bewusst sein, dass damit auch Eure Emailadresse öffentlich im Internet bekannt ist und damit tendenziell die Menge an Spam ansteigt. Dies ist aber in der Regel kaum ein Problem, wenn Ihr ohnehin einen Spamfilter eingestellt habt. Zusätzlich filtern die großen Emailanbieter in der Regel solche Spammails recht zuverlässig raus.

Warum ist Beglaubigen der Schlüssel wichtig?

  • Stellen wir uns einmal eine sogenannte Man-in-the-Middle Attacke vor, während Alice Ihrem geliebten Bob eine verschlüsselte Nachricht zukommen lassen will, die auch geheim bleiben soll:
    • Entsprechend der folgenden Abbildung, die von der folgenden Wikipedia-Seite stammt, klinkt sich Mallory ein in die Verbindung zwischen Alice und Bob.
    • Nehmen wir jetzt weiter an, dass Alice den öffentlichen Schlüssel von Bob nicht kennt und daher Bob erst danach fragen muss.
    • Wenn Alice Bob jetzt mittels einer unverschlüsselten Emailnachricht nach Bob's öffentlichem Schlüssel fragen würde, würde Mallory dies mitbekommen.
    • Bob wird nach Alice Aufforderung ebenfalls in einer unverschlüsselten Emailnachricht seinen öffentlichen Schlüssel in Richtung von Alice losschicken.
    • Allerdings sitzt Mallory zwischen den beiden und nimmt Bob's öffentlichen Schlüssel entgegen und speichert ihn.
    • Statt Bob's öffentlichen Schlüssel aber weiterzusenden, erzeugt er selber einen öffentlichen Schlüssel samt zugehörigem privaten Schlüssel (sogenanntes Schlüsselpaar) und schickt diesen öffentlichen Schlüssel (sogenanter Fake-Schlüssel) stattdessen an Alice.
    • Unter der Annahme, dass Alice keine andere Möglichkeit hat, um zu überprüfen, dass der öffentliche Schlüssel, den sie erhalten hat, auch wirklich von Bob stammt, wird sie es wohl einfach glauben.
    • Alice verschlüsselt also eine Nachricht mit dem Fake-Schlüssel und schickt sie in Richtung von Bob.
    • Jedoch nimmt statt Bob erst Mallory Alice verschlüsselte Nachricht entgegen und entschlüsselt sie, da er ja zu seinem öffentlichen Fake-Schlüssel auch den privaten Schlüssel kennt. Damit kann er die Nachricht problemlos lesen.
    • Anschließend verschlüsselt er die Nachricht wieder, dieses Mal aber mit Bob's öffentlichem Schlüssel, und schickt sie an Bob weiter.
    • Wenn dann Bob die Nachricht erhält, kann er die Nachricht problemlos mit seinem privaten Schlüssel entschlüsseln und wird keinen Unterschied bemerkt haben.
    • Alice und Bob gehen also davon aus, dass sie sicher und verschlüsselt miteinander kommunizieren und niemand mitlesen kann, während Mallory in Wahrheit ihre gesame Kommunikation belauscht.
    • Schematisch ist dies auch in der folgenden Grafik, die auf der nachfolgenden Webseite zu finden ist, nochmals dargestellt.
  • Der Fehler, der diesen Man-in-the-Middle Angriff ermöglicht hat, war, dass Alice einfach geglaubt hat, dass der ihr zugestellte öffentliche Schlüssel von Bob stammte.
  • Dieser Fehler kann auch auftreten, wenn jemand einfach einen Fake-Schlüssel für Bob's Emailadresse verbreiten würde, indem er ihn zum Beispiel auf einem Schlüsselserver hochlädt.
  • Irgendwie muss man also sicherstellen, dass der öffentliche Schlüssel auch zur jeweiligen Person bzw. Emailadresse gehört.
  • Dies erfolgt durch das sogenannte Beglaubigen des Schlüssels (englisch Keysigning). Dabei bestätigt eine andere Person mittels einer digitalen Unterschrift bzw. in der Fachsprache digitalen Signatur, dass der öffentliche Schlüssel auch wirklich zur jeweiligen Person gehört.
  • Wichtig zu wissen ist jetzt noch, dass jedes Schlüsselpaar, also jeder öffentliche und zugehörige private Schlüssel, eine eindeutige Identifikationsnummer, den sogenannten Fingerprint hat.
  • Dieser Fingerprint ist einmalig und relativ kurz im Gegensatz zum relativ langen öffentlichen Schlüssel, den er repräsentiert.
  • Man kann also einen öffentlichen Schlüssel an Hand seines Fingerprints eindeutig identifizieren.
  • Gäbe es Fingerprints nicht, müsste man öffentliche Schlüssel Zeichen für Zeichen vergleichen, um feststellen zu können, ob es jeweils der gleiche öffentliche Schlüssel ist. Das wäre echt ein ganz schöner Aufwand, da öffentliche Schlüssel in der Regel einige Dutzend Zeilen lang sind und aus allen möglichen Zeichen bestehen.
  • Stellen wir uns nun vor folgende Situation vor, in der das Beglaubigen eingeführt wird:
    • Alice und Bob wohnen weit weg voneinander, d.h. sie können sich nicht treffen und kennen auch sonst keinen sicheren Weg, um sich gegenseitig den Fingerprint ihres öffentlichen Schlüssels oder direkt ihren öffentlichen Schlüssel mitzuteilen.
    • Alice und Bob kennen aber beide Conrad und wissen, dass er seinen Reisen immer mal wieder beide besuchen kommt.
    • Alice wird sich daher persönlich mit Conrad treffen.
    • Conrad lässt sich dann von Alice den Fingerprint von ihrem öffentlichen Schlüssel zeigen und merkt ihn sich, da er Alice gut kennt, verzichtet er auch auf eine Identitätsfeststellung mittels Personalausweis.
    • Sobald Conrad Bob nun trifft, wird er Bob den Fingerprint von Alice öffentlichen Schlüssel mitteilen und steif und fest schwören, dass genau dieser Fingerprint zu Alice Schlüsselpaar gehört. Er beglaubigt also Alice Schlüssel.
    • Jetzt weiß Bob sicher, welcher öffentliche Schlüssel zu Alice gehört, und er wird seine Nachrichten an Alice auch nur noch mit diesem öffentlichen Schlüssel verschlüsseln.
    • Mallory kann nun auch machen, was er will: Er wird nur noch feststellen, dass Bob eine verschlüsselte Nachricht an Alice sendet, aber er weiß nicht, was. Hinweis: Der Austausch von Metadaten zwischen den beiden ist also weiter ersichtlich und daher kommunizieren, die beiden nicht anonym miteinander, aber immerhin verschlüsselt.
    • Gleichzeitig weiß Bob auch sicher, dass eine Nachricht nicht von Alice stammen kann, wenn sie mit einem anderen Schlüsselpaar verschlüsselt oder signiert wurde (zum Signieren kommen wir gleich).
    • Da Conrad sich nun auch noch in analoger Weise den Fingerprint von Bob's öffentlichen Schlüssel merkt und beim nächsten Mal Alice mitteilt, können die beiden zukünftig sicher miteinander kommunizieren.
  • Das ganze Prozedere ist zugebenermaßen etwas umständlich und nur schwer zu realisieren, wenn man nicht nur seinen Freunden, sondern vielleicht auch einem Geschäftspartner auf einem anderen Kontinent eine verschlüsselte Email schicken will.
  • Aus diesem Grund wurde das sogenannte Web of Trust entwickelt.

Das Web of Trust (WOT)

  • Das Web of Trust oder wörtlich "Netz des Vertrauens" beschreibt einen Mechanismus oder eigentlich genauer gesagt zwei Mechanismen, darin unterscheiden sich nämlich der OpenPGP und der S/MIME Standard, die es ermöglichen in großen und sogar wechselnden Gruppen öffentliche Schlüssel zu beglaubigen und untereinander auszutauschen.
  • Wie bereits oben erwähnt, ist es in großen Gruppen, die sich vielleicht sogar immer wieder ändern (Bestes Beispiel: Die Teilnehmer an Alumni-Seminaren), nahezu unmöglich alle öffentlichen Schlüssel zu beglaubigen und jedem mitzuteilen.
  • Im Web of Trust ist dies nicht notwendig, da dort eine Vertrauenskette aufgebaut und verwendet wird. Ein Beispiel:
    • Alice besitzt den öffentlichen Schlüssel von Bob.
    • Alice kann diesen öffentlichen Schlüssel nun mit ihrer digitalen Signatur beglaubigen. Das sollte sie allerdings nur machen, wenn sie sicher weiß, dass es der öffentliche Schlüssel von Bob ist.
    • Anschließend kann sie diesen öffentlichen Schlüssel, der nun mit ihrer Unterschrift versehen ist, weiterreichen oder auf einem Schlüsselserver hochladen.
    • Conrad beglaubigt ebenfalls Bob's öffentlichen Schlüssel und lädt ihn auch einen Schlüsselserver hoch.
    • Nehmen wir nun an Daniel, ein Kollege von Bob, möchte Bob eine verschlüsselte Nachricht senden und benötigt daher Bob's öffentlichen Schlüssel.
    • Da Daniel Bob's öffentlichen Schlüssel bislang nicht hat, schaut er auf einem Schlüsselserver nach und findet dort Bob's öffentlichen Schlüssel.
    • Es könnte sich jetzt natürlich auch um einen Fake-Schlüssel handeln, den jemand anderes wie Mallory hochgeladen hat.
    • Aber Daniel stellt fest, dass seine entfernte Verwandte Alice den Schlüssel von Bob beglaubigt hat.
    • Da Daniel weiß, dass Alice immer sehr gewissenhaft ist, vertraut er Alice und daher auch dem von Alice beglaubigten öffentlichen Schlüssel von Bob.
  • Der absolute Dreh- und Angelpunkt des Web of Trust und auch seine größte Schwachstelle ist also die Vertrauenswürdigkeit der beteiligten Personen (OpenPGP Verfahren) oder der beteiligten Institutionen (S/MIME Verfahren).
  • Nur wenn jeder Teilnehmer am Web of Trust nicht leichtfertig öffentliche Schlüssel anderer Teilnehmer beglaubigt, also immer sorgsam deren Identität und den Fingerprint ihres öffentlichen Schlüssels prüft, kann die Vertrauenskette funktionieren.
  • In Bezug auf das Web of Trust und den Aufbau und das Erhalten der Vertrauenskette sowie bei Mißbrauch dem Entzug des Vertrauens schlagen der OpenPGP und der S/MIME Standard jeweils unterschiedliche Wege ein.

Der OpenPGP Standard

  • Der OpenPGP Standard, der auf der 1991 entwickelten Software "Pretty Good Standard" (PGP) aufbaut, stellt die Benutzer in die Verantwortung, dass sie die öffentlichen Schlüssel beglaubigen und verifizieren, und ist dezentral aufgebaut.
  • Die Benutzer sind also dazu angehalten, gegenseitig ihre öffentlichen Schlüssel zu beglaubigen und zu verteilen.
  • Es gibt zwar ein paar öffentliche, kostenfreie Schlüsselserver, aber diese sind für das Funktionieren nicht unbedingt erforderlich, sondern erleichtern nur den Schlüsselaustausch und nehmen keinerlei Aufsichtsfunktion wahr.
  • Dies bedeutet auch, dass die Benutzer selber entscheiden müssen, wem sie vertrauen.
  • Dieser Standard bietet also sehr viele Freiheiten für die Benutzer, fordert aber auch eigenständigere Entscheidungen.

Vorteile des OpenPGP Standards

  • Er ist absolut kostenfrei.
  • Er bedarf keiner höhergeordneten Einrichtungen oder einer bestimmten Infrastruktur für sein Funktionieren.
  • Man kann einen öffentlichen Schlüssel für mehrere Emailadressen verwenden.

Nachteile des OpenPGP Standards

  • Der Benutzer muss sich selber um die Einrichtung und Erstellung seines Schlüsselpaares kümmern.
  • Der Aufwand bei der Einrichtung ist am Anfang in der Regel größer.
  • Es gibt zwar Schlüsselserver, aber trotzdem gibt es keinen einheitlichen Weg einen öffentlichen Schlüssel zu überprüfen.

Der S/MIME Standard

  • Der S/MIME Standard vertraut dahingehend auf höhergeordnete Zertifizierungsstellen, die sogenannte Root-Zertifikate ausstellen, von diesen Root-Zertifikaten werden dann Unterzertifikate wie die Zertifikate für die einzelnen Emailadressen abgeleitet.
  • Dieses System ist eng verwandt mit den für die HTTPS-Verschlüsselung notwendigen Webserver-Zertifikaten.
  • Im Gegensatz oder zur Abgrenzung von OpenPGP spricht man bei S/MIME *nicht* von Schlüsseln, sondern von Zertifikaten.
  • Statt dem privaten Schlüssel gibt es dann einen privaten Teil des Zertifikats, der auch wie ein privater Schlüssel geheim gehalten werden muss, und einen öffentlichen Teil des Zertifikats, der dem öffentlichen Schlüssel entspricht.
  • Die Entscheidung, ob einem Zertifikat vertraut wird, trifft in der Regel nicht der Benutzer oder eine Gruppe von Benutzern durch das Beglaubigen, sondern das Emailprogramm indirekt dadurch, dass es von verschiedenen Zertifizierungsstellen deren Root-Zertifikate in seinen sogenannten Zertifikatespeicher aufnimmt.
  • Das Emailprogramm legt durch die Aufnahme der Root-Zertifikate also explizit fest, welcher Zertifizierungsstelle es vertraut.
  • Die Zertifizierungsstelle stellen dann meist gegen Gebühr, für Privatanwender aber auch zum Teil kostenlos (siehe unten), vom Root-Zertifikat abgeleitete Zertifikate nach einer mehr oder weniger umfangreichen Prüfung der Identität und Berechtigung des Antragstellers aus.
  • Wenn das Emailprogramm nun eine Email erhält, die auch den öffentlichen Teil des Senderzertifikats erhält, so wird das Emailprogramm das Zertifikat wie folgt prüfen:
    • Jedes Zertifikat enthält die digitale Signatur der ausstellenden Zertifizierungsstelle und ein Datum, bis wann das Zertifikat gültig ist.
    • Das Emailprogramm prüft nun zunächst, ob es die Zertifizierungsstelle bzw. deren Root-Zertifikat in seinem Zertifikatespeicher findet und ob es damit der Zertifizierungsstelle vertraut.
    • Falls das Emailprogramm der Zertifizierungsstelle nicht vertraut, wird es eine Warnung ausgeben.
    • Falls es der Zertifizierungsstelle vertraut, wird es bei der Zertifizierungsstelle automatisch nachfragen, ob die Zertifizierungsstelle wirklich das Zertifikat ausgestellt hat.
    • Falls das Zertifikat nur vorgibt, von der Zertifizierungsstelle ausgestellt worden zu sein, ist dies ein deutlicher Indiz für ein Phishing- oder ähnlichen Betrugsversuch und das Programm wird ebenfalls eine Warnung ausgeben.
    • Andererseits: Falls das Zertifikat von der Zertifizierungsstelle stammt, wird es als verifiziert eingestuft.
    • Am Schluss prüft das Emailprogramm aber noch, ob das Zertifikat noch gültig ist, d.h. dass die Lebensdauer des ausgestellten Zertifikats noch nicht überschritten ist.
    • Dies bedeutet, dass im besten Fall, ein Zertifikat sowohl gültig als auch verifiziert ist.

Vorteile des S/MIME Standards

  • Ein Vorteil des S/MIME Standards ist, dass die Zertifizierungsstellen, die davon leben, dass möglichst viele Programmen ihnen Vertrauen schenken und sie damit werben können, einen großen Anreiz haben, beim Ausstellen von abgeleiteten Zertifikaten eine umfangreiche Berechtigungsprüfung durchzuführen.
    • Man kann also bei den großen anerkannten Zertifizierungsstellen und den von ihnen ausgestellten Zertifikaten davon ausgehen, dass zumindest eine Überprüfung der Emailadresse des Antragstellers erfolgt ist.
    • In diesem Zusammenhang sollte auch erwähnt werden, dass es verschiedene Klassen von Zertifikaten gibt, die sich hinsichtlich ihrer Ansprüche an die Identitätsprüfung unterscheiden:
      • Klasse I Zertifikat: Hier wird nur die Emailadresse überprüft und ins Zertifikat übernehmen.
      • Klasse II Zertifikat: Hier wird die Emailadresse und der Name des Besitzers in das Zertifikat übernommen. Dafür muss der Antragsteller eine Ausweiskopie oder ähnliches einreichen.
      • Klasse III Zertifikat: Bei dieser Zertifikatklasse muss sich der Antragsteller persönlich zum Beispiel durch das PostIdent-Verfahren ausweisen.
  • Weiterhin sollte erwähnt werden, dass man bei S/MIME eigentlich nicht von einem Web of Trust, sondern von einer Public-Key-Infrastruktur spricht, da durch die Wichtigkeit der Zertifizierungsstellen bei der Vertrauenskette und mit dem Ableiten der Nutzerzertifikate von den Root-Zertifikaten defacto eine feste Infrastruktur existiert.

Nachteile des S/MIME Standards

  • Man vertraut nahezu blind den Zertifizierungsstellen und deren Berechtigungsprüfung.
  • Ein Geheimdienst könnte eine Zertifizierungsstelle zwingen, ein gefälschtes Zertifikat für ihn auszustellen und damit einen Man-in-the-Middle Angriff starten.
  • In Bezug auf die Zertifizierungsstellen muss auch noch erwähnt werden, dass theoretisch quasi jeder eine Zertifizierungsstelle betreiben kann (viele Unis machen dies auch).
  • Allerdings werden von solchen Zertifizierungsstellen ausgestellte Zertifikate standardmäßig in den Emailprogrammen nicht akzeptiert und ergeben erst einmal eine Warnung.
  • Zudem ist es meist sehr umständlich ein Root-Zertifikat einer Zertifizierungsstelle zu importieren, weswegen es in der Regel nur Sinn macht, Zertifikate anerkannter Zertifizierungsstellen zu benutzen.

Unterschiede zwischen den beiden Standards OpenPGP und S/MIME

Signieren von Emails

  • Bislang haben wir immer nur vom Verschlüsseln von Emails gesprochen.
  • Man kann die Schlüsselpaare aber auch Nutzen, um Nachrichten zu signieren.
  • Mit Signieren ist gemeint, dass der Sender die Emailnachricht mittels seinen privaten Schlüssels mit einer sogenannten Signatur versieht.
  • Der Empfänger, der den beglaubigten öffentlichen Schlüssel des Senders besitzt, kann dann sicher überprüfen, dass die Nachricht auch wirklich vom Sender stammt.
  • Zum Signieren findet die Verschlüsselung quasi in umgekehrter Richtung statt:
    • Der Sender erzeugt einen sogenannten Hash für seinen Text. Dabei handelt es sich um eine eindeutige Prüfsumme, die für jeden Text einzigartig ist.
    • Anschließend speichert er die Prüfsumme / den Hash in einer kleinen Textdatei und verschlüsselt diese Textdatei mit seinem privaten Schlüssel.
    • Nun sendet er seinen unverschlüsselten Text und den verschlüsselten Hash an den Empfänger.
    • Der Empfänger kann den Text sofort lesen, aber weiß er, ob nicht jemand den Text verändert oder ausgetauscht hat?
    • Ja! Denn er kann nun mit dem ihm bekannten öffentlichen Schlüssel den verschlüsselten Hash entschlüsseln und kennt nun die Prüfsumme.
    • Anschließend berechnet er selber den Hash des ihm vorliegenden Textes.
    • Stimmen beide Hashes überein, stammt der Text wirklich vom Sender.
  • Das Tolle an diesem Verfahren ist, dass nur wenn der Hash mit dem privaten Schlüssel des Senders verschlüsselt wurde, der Empfänger mit seinem öffentlichen Schlüssel einen gültigen Hash erhalten kann.
  • Sollte also jemand anderes mit einem anderen privaten Schlüssel einen Hash verschlüsseln, fällt dies dem Empfänger auf, weil dann die Entschlüsselung mit seinem öffentlichen Schlüssel einen Fehler liefert.
  • Durch diesen Weg kann man also immer ganz leicht sicherstellen, dass die Email in unverfälschter Weise auch wirklich vom Sender stammt.
  • Das Signieren von Emails ist daher eine Sache, die man immer machen sollte, da damit der Identitätsdiebstahl ausgeschlossen wird, sofern der Empfänger immer auf das Erhalten einer gültigen Emailsignatur achtet.

Technische Umsetzung von OpenPGP zur Emailsignierung/-verschlüsselung (Einfache Variante)

Vor- und Nachteile

  • Pro: Einfache Einrichtung
  • Pro: Mit einem Mausklick verschlüsselte Email an andere Web.de und GMX Adressen senden, sofern diese Empfänger auch Emailverschlüsselung beherrschen und einmal einen öffentlichen Schlüssel erzeugt haben.
  • Contra: Diese Variante funktioniert nur mit den Webmailern von Web.de und GMX sowie deren eigenen Android- und iOS-Apps.
  • Contra: Die öffentlichen Schlüssel Eurer Kontakte und aller bei OpenPGP mitmachenden Web.de- und GMX-Nutzer werden nur auf einem Schlüsselserver der beiden Anbieter gespeichert. D.h. das Euer öffentlicher Schlüssel nicht allgemein verfügbar ist. Ihr müsst Euren öffentlichen Schlüssel daher selbst erst auf einen öffentlichen Schlüsselserver hochladen, sofern Ihr verschlüsselte Emails von Emailadressen anderer Emailanbieter (z.B. Googlemail) empfangen wollt.
  • Contra: Web.de und GMX greifen für das Ermitteln von öffentlichen Schlüsseln nur auf Ihren eigenen Schlüsselserver zu. Wenn ein Freund von Euch, also eine Emailadresse bei einem anderen Emailanbieter (Googlemail) hat, und seinen öffentlichen Schlüssel auf einem der üblichen weltweit öffentlichen Schlüsselserver hochgeladen hat, wird dieser öffentliche Schlüssel nicht von der Mailvelope Erweiterung oder der Web.de/GMX App gefunden. Ihr müsst den öffentlichen Schlüssel dann erst händisch vom Schlüsselserver herunterladen und in Mailvelope bzw. die App importieren. Das ist Aufwand.

Einrichtung der OpenPGP Verschlüsselung für Web.de und GMX Emailadressen

Technische Umsetzung von OpenPGP zur Emailsignierung/-verschlüsselung (Allgemeinere Variante)

Vor- und Nachteie

  • Pro: Funktioniert mit jeder Emailadresse.
  • Pro: Man kann in der Regel direkt öffentliche Schlüssel von einem Schlüsselserver abrufen lassen und spart sich damit das Importieren von öffentlichen Schlüsseln.
  • Contra: Bei der Einrichtung komplizierter als die Web.de und GMX Variante.
  • Contra: Unter Android nur schwierig in dieser Form einzurichten und einzusetzen.

Einrichtung der OpenPGP Verschlüsselung mit dem Mailvelope Browserplugin

  • Gleiches Plugin wie oben, nur dieses Mal muss man es händisch einrichten.
  • Falls man eine Web.de oder GMX Adresse hat, verwendet man am besten das Web.de oder GMX Mailvelope Plugin. Die Funktionalität ist dann nahezu gleich, man spart sich nur das Einrichten.
  • Anleitung
  • Anleitung
  • Anleitung
  • Anleitung

Einrichtung der OpenPGP Verschlüsselung in Thunderbird

Einrichtung der OpenPGP Verschlüsselung in AppleMail

Einrichtung der OpenPGP Verschlüsselung in Outlook

Einrichtung der OpenPGP Verschlüsselung in Evolution

Einrichtung der OpenPGP Verschlüsselung in Android

Einrichtung der OpenPGP Verschlüsselung in iOS

Technische Umsetzung von S/MIME zur Emailsignierung/-verschlüsselung

Erhalten eines S/MIME Emailzertifikats

  • Es gibt verschiedene Möglichkeiten ein S/MIME Emailzertifikat zu erhalten.
  • So bieten zwar viele Hochschulen und andere staatliche Einrichtungen wie die Fraunhofer-Gesellschaft ihren Studenten und Mitarbeitern auch S/MIME Zertifikate für den privaten Gebrauch an, allerdings ist das Root-Zertifikat der betreffenden Einrichtung dann meist nicht im Emailprogramm hinterlegt, was beim Empfänger der signierten oder verschlüsselten Email zu einer Warnung vor einem unbestätigten bzw. unbeglaubigten Zertifikat führt.
  • Aufgrund derartiger Warnmeldungen ist es wichtig, dass das S/MIME Emailzertifikat von möglichst vielen Emailprogrammen akzeptiert wird. Folglich sollte es möglichst von einem allgemein anerkannten Root-Zertifikat abgeleitet sein.
  • Leider bedeutet dies gleichzeitig, dass das Zertifikat meist von einer der wenigen weltweit agierenden, kommerziellen Zertifizierungsstellen stammen muss, da nur deren Root-Zertifikate in vielen Programmen hinterlegt sind.
  • Normalerweise kostet ein S/MIME Emailzertifikat bei seiner Zertifizierungsstelle sehr viel Geld, da die Anbieter selbst relativ viel Geld aufwenden, um eben in möglichst vielen Programmen hinterlegt zu sein und damit eine breite Akzeptanz zu erreichen.
  • Zum Glück gibt es kommerzielle Anbieter, die für Privatnutzer ein kostenloses S/MIME Emailzertifikat unter Angabe ein paar persönlicher Daten für (in der Regel) ein Jahr ausstellen:
    • Kostenloses Emailzertifikat von StartSSL
      • Hinweis: Aufrufen des Registrierungsprozesses mit Firefox kann problematisch sein - lieber Chromium dafür verwenden.
      • Der Registrierungsprozess bei StartSSL ist rasch erledigt, allerdings kann das Freischalten zwischen ein paar Minuten und ein paar Stunden dauern, da Eure Daten kurz auf Konsistenz geprüft werden.
      • Unter folgendem Link ist der Registrierungsprozess auch nochmals ausführlich erläutert.
    • Kostenloses Emailzertifikat von Comodo
      • Hinweis: Wir haben selbst lange keine Registrierung bei Comodo mehr durchgeführt, können also nichts zum Ablauf der Registrierung sagen.
  • Alle Betreiber eines Servers unter Euch sollten sich jedoch einmal Let's encrypt anschauen, da man dort demnächst kostenlose S/MIME Zertifikate für Webserver auf einfache Weise erhalten kann.

Verwenden des S/MIME Emailzertifikats in Thunderbird

Verwenden des S/MIME Emailzertifikats in AppleMail

Verwenden des S/MIME Emailzertifikats in Outlook und Outlook Web Access (OWA)

Verwenden des S/MIME Emailzertifikats in Evolution

Verwenden des S/MIME Emailzertifikats in iOS

Verwenden des S/MIME Emailzertifikats in Android

Nachteile von Verschlüsselung

  • Zuletzt möchten wir Euch fairerweise noch ein paar der Nachteile der Emailverschlüsselung nennen:
    • Zum Entschlüsseln einer verschlüsselten Email braucht man immer den privaten Schlüssel. Sollte man also mal kurz vom Computer eines Freundes auf seine verschlüsselten Emails zugreifen wollen, so wird dies in der Regel nicht funktionieren. Zum einen braucht man immer ein Programm oder eine Browsererweiterung zum Entschlüsseln und zum anderen muss man immer seinen privaten Schlüssel parat haben.
    • Verschlüsselte Emails sind nicht durchsuchbar, da sie in der Regel erst beim Aufrufen der Email temporär entschlüsselt werden.
    • Inhalte von verschlüsselten Emails können durch Virenscanner nicht automatisch überprüft werden. Dies bedeutet, dass erst nachdem Ihr den Inhalt einer verschlüsselten Email, z.B. eine Datei, lokal gespeichert habt, kann der Virenscanner die Nachricht prüfen.
    • Der ausgetauschte Inhalt ist zwar verschlüsselt, aber es kann immer noch mittels der sogenannten Metadaten nachvollzogen werden, wer wem eine Email verschickt hat. Der Inhalt ist also geheim, aber der Austausch erfolgt nicht anonym.

Linksammlung

http://www.heise.de/ct/ausgabe/2012-18-Mail-Verschluesselung-auf-dem-Rechner-und-mobil-anwenden-2340656.html
https://de.wikibooks.org/wiki/Linux-Praxisbuch:_Das_Kapitel_GnuPG
http://www.pro-linux.de/artikel/2/187/der-gnu-privacy-guard.html
http://wiki.ubuntuusers.de/GnuPG
http://www.heise.de/newsticker/meldung/Analyse-Firefox-und-das-Problem-mit-der-Online-Werbung-2913144.html
https://www.heinlein-support.de/blog/security/e-mail-verschluesselung-site-to-site-per-pgp-gpg-smime-oder-ssl-tls/
https://www.zehe-edv.de/2015/01/05/grundlagen-zur-e-mail-verschluesselung-mit-openpgp/
https://www.zehe-edv.de/2015/01/18/e-mail-verschluesselung-mit-smime/
http://www.computerwoche.de/a/sichere-mails-fuer-alle,2510521,5
http://www.msxfaq.de/signcrypt/smimepgp.htm
http://www.tomshardware.de/email-verschluesselung-openpgp-smime-gpg4win,testberichte-238735-4.html
http://www.tomshardware.de/email-verschluesselung-openpgp-smime-gpg4win,testberichte-238735-5.html
http://www.openpgp-schulungen.de/kurzinfo/openpgp-smime/
http://www.openpgp-schulungen.de/kurzinfo/
http://www.computerwoche.de/a/sichere-mails-fuer-alle,2510521,5

Sofern nicht anders angegeben, steht der Inhalt dieser Seite unter Lizenz Creative Commons Attribution-ShareAlike 3.0 License