GnuPG: Das Dilemma mit den Schlüsselservern

1. Asymmetrische VerschlüsselungGnuPG Fingerprint

Die Verschlüsselung von E-Mails mit GnuPG (bzw. OpenPGP) fristet noch immer ein Nischendasein. Obwohl Projekte wie Mailvelope oder p≡p Anstrengungen unternommen haben, um die Anwendung benutzerfreundlicher zu gestalten, sind die Hürden für die meisten Anwender dennoch zu groß.

Dabei ist die Verwendung in der Praxis gar nicht so schwer, wenn man einmal das Prinzip vom privaten- und öffentlichen Schlüssel verinnerlicht hat. Binnen weniger Minuten lässt sich bspw. mit Hilfe des Thunderbird-Addons Enigmail ein Schlüsselpärchen erzeugen, das aus einem geheimen (privater Schlüssel) und einem nicht geheimen Teil (öffentlicher Schlüssel) besteht. Was es mit dem Schlüsselpärchen auf sich hat und wie E-Mails verschlüsselt / signiert werden, habe ich bereits im Beitrag »Verschlüsselte E-Mails mit GnuPG als Supergrundrecht« aufgezeigt.

Die Erzeugung eines Schlüsselpärchens ist allerdings nur die halbe Miete, denn in der Praxis lauern einige Fallstricke. Der vorliegende Beitrag wird aufzeigen, weshalb es notwendig ist, den (eindeutigen) Fingerprint eines öffentlichen Schlüssels zu prüfen und welche Problematik mit der Verwendung von Schlüsselservern einhergeht.

2. Fingerprint: Die Verifikation des Schlüssels

Wer E-Mails verschlüsselt, der möchte zunächst einmal sicherstellen, dass der Inhalt von niemandem gelesen werden kann, außer natürlich dem Empfänger. Mit GnuPG kann man allerdings nicht nur die Vertraulichkeit gewährleisten, sondern über die digitale Signatur noch weitere Schutzziele der Informationssicherheit sicherstellen. Sofern GnuPG korrekt angewendet wird, können folgende Schutzziele erreicht werden:

  • Durch das Verschlüsseln von E-Mails:
    • Vertraulichkeit: Daten dürfen lediglich von Berechtigten gelesen bzw. modifiziert werden. Dies gilt sowohl beim Zugriff auf gespeicherte Daten, wie auch während der Datenübertragung.
  • Durch das digitale Signieren (Unterschreiben) von E-Mails:
    • Integrität: Daten dürfen nicht unautorisiert und unbemerkt verändert werden. Alle Änderungen müssen nachvollziehbar sein.
    • Authentizität; Nachweis der Echtheit und Glaubwürdigkeit von Daten oder Subjekten, anhand eindeutiger Identität oder Eigenschaften.
    • Nicht-Abstreitbarkeit: Schutz vor unzulässigem Abstreiten durchgeführter Handlungen bzw. ein Subjekt kann nicht abstreiten, dass eine Aktion durchgeführt wurde.

Damit diese Schutzziele in der Praxis tatsächlich auch erreicht werden, ist die Verifikation des öffentlichen Schlüssels erforderlich.

2.1 Der Fingerprint des öffentlichen Schlüssels

Jeder öffentliche Schlüssel der erzeugt wird hat einen eindeutigen Fingerprint (Fingerabdruck), der vergleichbar mit dem Fingerabdruck eines Menschen ist. Mit Hilfe dieses Merkmals kann die Echtheit eines Schlüssels überprüft werden. Denn woher wisst ihr, dass der öffentliche Schlüssel tatsächlich vom Besitzer stammt? Im Prinzip kann nämlich jeder ein Schlüsselpaar mit einer oder mehreren E-Mail Adressen verknüpfen und den öffentlichen Teil auf einen Schlüsselserver hochladen bzw. irgendwo veröffentlichen. Wenn ihr also sicher sein möchtet, dass der öffentliche Schlüssel tatsächlich zum Ersteller / Besitzer gehört, könnt ihr dies nur dann eindeutig feststellen, wenn ihr den Fingerprint prüft.

Zunächst solltet ihr euch mal den Fingerprint von eurem (öffentlichen) Schlüssel anzeigen lassen. Über die Konsole / Terminal:

gpg --fingerprint eure@mailadresse.de

Fingerprint Terminal

Alternativ funktioniert es auch grafisch über Thunderbird bzw. Enigmail über »Schlüssel verwalten -> euren Schlüssel suchen -> Doppelklick«:

Fingerprint Enigmail

Dieser Fingerprint ist ein relativ kurzer Hash-Wert, mit dem man Schlüssel bzw. den Besitzer verifizieren kann. Es ist praktisch so gut wie ausgeschlossen, dass es einen zweiten Schlüssel mit dem demselben Fingerprint gibt. Man sollte sich immer von der Echtheit eines öffentlichen Schlüssels überzeugen, den man von einem Schlüsselserver, per E-Mail oder einen anderen Quelle erhalten hat. Nur wenn ihr den dazugehörigen Fingerprint prüft bzw. verifiziert, könnt ihr sicher sein mit Person XY zu kommunizieren.

2.2 Fingerprint verifizieren

Die Prüfung des Fingerprints kann auf unterschiedliche Weise erfolgen. Im Idealfall prüft ihr bei einem persönlichen Treffen den Fingerprint eures Kontakts. Es gibt allerdings auch noch weitere Möglichkeiten, die ich kurz skizzieren möchte. Entscheidend ist, dass ihr den Fingerprint Out-of-band, also über einen unabhängigen Kanal prüft – also nicht per E-Mail. Anbei ein paar Ideen:

  • Telefon: Wenn ihr sicher seid, dass ihr mit Person XY kommuniziert, könnt ihr den Fingerprint über das Telefon austauschen.
  • Messenger: Benutzt einen (verschlüsselten) Messenger, bei dem ihr im Idealfall euren Kontakt im Vorfeld verifiziert habt. Auch Messenger bieten es häufig an, dass ihr ähnlich wie bei GnuPG, einen Fingerprint prüfen könnt.
  • Brief: Das dauert zwar etwas länger, aber auch diese Möglichkeit könnt ihr in Betracht ziehen, um den Fingerprint zu verifizieren.
  • Webseite: Sofern die Webseite über TLS verschlüsselt erreichbar ist, besteht auch hier die Möglichkeit den Fingerprint eines Schlüssels zu prüfen. Oftmals wird euch der öffentliche Schlüssel auch direkt zum Download angeboten.

Insbesondere die letzte Variante halte ich für sinnvoll, wenn ihr mit jemandem verschlüsselt in Kontakt treten wollt, zuvor aber den Fingerprint prüfen sollt / müsst. Wenn ihr mir eine verschlüsselte E-Mail zukommen lassen wollt, dann könnt ihr einfach die Kontakt-Seite aufrufen. Hier biete ich euch nicht nur den öffentlichen Schlüssel zum Download an, sondern habe dort auch den Fingerprint des öffentlichen Schlüssels veröffentlicht. Sofern ich die Kontrolle über den Webserver / die Domain »www.kuketz-blog.de« behalte, ist dies eine ideale Variante, um den Fingerprint jedem / bzw. einem großen Publikum zugänglich zu machen. Schließlich möchte ich weder mit jedem Adressaten telefonieren, noch einen Brief schreiben oder im Vorfeld via Messenger kommunizieren.

Fingerprint

Nach dem Herunterladen des Schlüssels könnt ihr den Fingerprint dann entweder wie bereits dargestellt über das Terminal oder Enigmail prüfen. Sofern der Fingerprint des (öffentlichen Schlüssels) mit den Angaben auf der Webseite übereinstimmt, könnt ihr davon ausgehen, dass es sich um den »echten«, also meinen Schlüssel handelt.

3. Schlüsselserver

In der Praxis stoßen wir häufig auf ein Problem, wenn man mit jemandem verschlüsselt via GnuPG kommunizieren möchte. Wir benötigen dazu zunächst seinen öffentlichen Schlüssel. Wie oben im Beispiel aufgezeigt, stelle ich euch meinen öffentlichen Schlüssel als Download (inklusive Fingerprint) zur Verfügung. Es genügt also den Schlüssel herunterzuladen, den Fingerprint zu prüfen und diesen Schlüssel dann für die Verschlüsselung von E-Mails an mich zu nutzen. Vielfach ist der öffentliche Schlüssel allerdings nicht bekannt, weshalb die Schlüsselserver (Keyserver) existieren.

Auf einem Schlüsselserver werden öffentliche Schlüssel zum Download bzw. Import angeboten, um einer Person eine verschlüsselte E-Mail zukommen zu lassen. Die Variante über die Schlüsselserver ist zwar bequem, allerdings leider mit einigen Nachteilen verbunden.

Werfen wir doch mal einen Blick auf die Keyserver, welche öffentlichen Schlüssel wir zu meiner E-Mail-Adresse »webmaster@kuketz-blog.de« finden:

Keyserver

Aktuell (01.08.2017) sind mit der E-Mail Adresse »webmaster@kuketz-blog.de« insgesamt 6 Schlüssel verknüpft – allerdings ist nur einer davon der »echte« Schlüssel. Wie aber weiß jemand, welcher nun der richtige Schlüssel ist? Im Prinzip gar nicht, weil jeder für eine E-Mail Adresse einen öffentlichen Schlüssel generieren und diesen anschließend über die Schlüsselserver publik machen kann.

Unterstütze den Blog mit einem Dauerauftrag!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

3.1 Das Dilemma

Im Idealfall ist auf einem Schlüsselserver jedem Teilnehmer von GnuPG ein eindeutiger öffentlicher Schlüssel zugeordnet, der mit einer E-Mail Adresse (oder mehreren) verknüpft ist. Die Realität sieht leider anders aus. Auf den Schlüsselservern liegen eine Menge veralteter, nicht zurückgezogener (falls kompromittiert) oder »gefälschter« Schlüssel, die es vielfach unmöglich machen, den einen, »echten« Schlüssel ausfindig zu machen.

Wer mir bspw. eine verschlüsselte E-Mail zukommen lassen möchte, allerdings noch nicht meinen öffentlichen Schlüssel besitzt, der ist schlecht beraten, wenn er diesen über einen Schlüsselserver bezieht. Addons wie Enigmail werden einfach jenen öffentlichen Schlüssel importieren, der am aktuellsten ist – in meinem Fall also einen Schlüssel, den ich weder generiert, noch auf die Schlüsselserver hochgeladen habe. Jede E-Mail, die mit diesem Schlüssel verschlüsselt wurde ist für mich nicht lesbar bzw. entschlüsselbar. Mir fehlt es schlicht am dazu passenden, privaten Schlüssel (der Falltür der Einwegfunktion).

Die Nachteile auf einen Blick:

  • Jeder kann öffentliche Schlüssel für eine E-Mail Adresse generieren und diese über die Schlüsselserver (oder einen anderen Weg) in Umlauf bringen
  • Schlüsselserver können als Quelle für den Versand von Spam missbraucht werden, da jeder den Datenbestand (auch E-Mail Adressen) einsehen kann
  • Es ist unmöglich einen veröffentlichten Schlüssel zu entfernen, da die Schlüsselserver untereinander abgleichen und das Löschen daher nicht möglich / nicht vorgesehen ist (man kann ihn allerdings mit einem Widerrufszertifikat zurückrufen)

Die Schlüsselserver lösen also das Problem der »Schlüsselverteilung«, schaffen allerdings zahlreiche Probleme, die den Nutzen in der Praxis stark einschränken. Insbesondere wenn irgendwelche Personen für »fremde« E-Mail Adressen Schlüssel generieren und diese anschließend auf die Schlüsselserver hochladen, ist das Verfahren praktisch nutzlos, da niemand weiß, welcher nun der »echte« Schlüssel ist.

Hinweis

Die IETF beschreibt im RFC 7929 (DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP) einen Ansatz, bei dem die zu einer E-Mail-Adresse passenden (öffentlichen) Schlüssel via DNS veröffentlicht / verbreitet werden. Die DNS-Zone sollte dazu mit DNSSEC abgesichert sein, damit sichergestellt ist, dass die Key-Informationen wirklich vom Schlüsselbesitzer stammen.

4. Fazit

Die Schlüsselserver sind zwar praktisch, wenn man den öffentlichen Schlüssel einer Person noch nicht besitzt, allerdings in der Praxis nur eingeschränkt »vertrauenswürdig«. Die eingangs vorgestellten vier Schutzziele (Vertraulichkeit, Integrität, Authentizität und Nicht-Abstreitbarkeit) der Informationssicherheit lassen sich nur dann erreichen, wenn man seinen Gegenüber bzw. Korrespondenten verifiziert. Bei GnuPG funktioniert das über den vorgestellten Fingerprint des öffentlichen Schlüssels.

Generell solltet ihr eure Kontakte (nach Möglichkeit) nicht nur bei der E-Mail Verschlüsselung, sondern bspw. auch bei der Nutzung von Messengern, immer verifizieren. Messenger, die Wert auf Sicherheit legen, bieten euch entsprechende Möglichkeiten an. Conversations arbeitet bspw. mit den OMEMO-Fingerprints, die ein Gerät eindeutig identifizierbar machen. (siehe Ziffer 4.5).

Bildquellen:

Server: Madebyoliver from www.flaticon.com is licensed by CC 3.0 BY
Key: Pixel Buddha from www.flaticon.com is licensed by CC 3.0 BY

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

31 Ergänzungen zu “GnuPG: Das Dilemma mit den Schlüsselservern”

  1. Comment Avatar Helmut Nir sagt:

    Danke!
    Ja, die Schlüsselserver sind ein Problem in der Praxis.
    So bekomme ich Emails, die ich nicht entschlüsseln kann, weil ich dort meine alten Schlüssel nicht löschen kann. Das Löschverfahren ist mir aber umständlich. Die beste Lösung wäre gewesen, ich hätte immer nur zeitlich befristete Schlüssel erzeugt.
    Die Absender, stolz eine verschlüsselte Email hingekriegt zu haben, reagieren frustriert, wenn ich sie dennoch nicht lesen kann. Ich glaub, es wäre besser, man würde Anfängern raten, die Schlüsselserver zu deaktivieren.

    Ansonsten signiere und verschlüssele ich alltäglich mit einigen wichtigen Kontakten ohne es zu bemerken.
    Es funktioniert reibungslos (Email-Client Evolution auf Linux).

    Auf dem Android-Phone gelang es mir nur für zwei, drei Mails mal vor drei Jahren. Danach war es wieder … ‚broken‘ und hätte des Frickelns bedurft, zu der ich mir keine Zeit nehmen wollte.
    Natürlich halte ich es für Unfug, auf einem Standard-Google-Android verschüsseln zu wollen, ebenso wie auf einem Windows. Aber, doch, zum Üben kann man es machen! ;-)

    Das Wichtigste, was ich aber sagen will:

    Schreibt bitte in eure Email-Signaturen einen freundlichen Hinweis, dass ihr gern Verschlüsselung anbietet.

    Nur dann hat es eine Chance auf Verbreitung.

  2. Comment Avatar Jacob sagt:

    Danke für den Artikel. Ein in meinen Augen interessanter Dienst, der versucht, die von dir beschriebenen Probleme des Keyserver-Konzepts zu umgehen, ist übrigens Keybase. Leider befindet sich Keybase aber noch in einer Art Open-Beta-Phase, soweit ich weiß.

  3. Comment Avatar Deus Figendi sagt:

    Jeder kann öffentliche Schlüssel für eine E-Mail Adresse generieren und diese über die Schlüsselserver (oder einen anderen Weg) in Umlauf bringen

    Das Problem war mir gar nicht so bewusst, ach du scheiße, stimmt. Naja, aber z.B. keybase versucht(e) das ja zu lösen, ich weiß nur nicht ob die jemals der Beta entwachsen sind.

    Die beste Lösung wäre gewesen, ich hätte immer nur zeitlich befristete Schlüssel erzeugt.

    Joa, ich mach seit ich pgp benutze immer 2 Jahre, das ist lang genug, damit es nicht nervt und kurz genug, dass man ein verlorenes revoke-Zertifikat einfach aussitzen kann.
    Nach ca. 15-20 Monaten erstelle ich mir einen neuen Schlüssel, unterschreibe ihn mit meinem alten und bringe den neuen unters Volk.

    Ich versende meinen Schlüssel einfach per Mail und ggf. Keysever und verschiedenen anderen Stellen. Dann ist er schonmal verteilt, muss aber noch verifiziert werden. Aber dafür hat es ja das trust-Modell.

  4. Comment Avatar Marcel sagt:

    Danke für die Zusammenfassung, auch wenn Schlüsselserver heutzutage in meinen Augen nur noch wenig Relevanz haben.

    Obwohl Projekte wie Mailvelope oder p≡p Anstrengungen unternommen haben, um die Anwendung benutzerfreundlicher zu gestalten, sind die Hürden für die meisten Anwender dennoch zu groß.

    Leider sind weniger technikaffine Personen wenig bzw. nicht an sicherer Kommunikation interessiert und deshalb auch nicht bereit, jegliche Form von Aufwand zu betreiben. One-Click Lösungen wie Signal oder Threema sind bei weitem nicht perfekt, konnten auf Grund der Einfachheit auch mehr „einfache“ Nutzer anziehen.
    GPG-verschlüsselte Mails oder Conversations sind (leider) nur in einer sehr beschränkten Filterblase nutzbar. Hier kann man imho die Public Keys auch von Hand austauschen, und benötigt keine Schlüsselserver.

  5. Comment Avatar THLK sagt:

    Also ich mag Verschlüsselung und würde irgendwie auch gerne alles verschlüsseln. Aber trotz der Tatsache, dass ich selbst einen PGP-Key habe, besitzt einfach sonst niemand so einen Key. Und die meisten Leute beschäftigen sich auch einfach gar nicht damit. Das ganze Schlüsselmanagement ist leider einfach zu aufwendig.

    Irgendwie müsste vielleicht mal was neues her.

  6. Comment Avatar jh sagt:

    Ein interessanter Artikel. Wäre denn die Veröffentlichung des öffentl. Keys einschließlich Fingerprint auf einer (eigenen) Webseite eine sicherere Alternative?

    • Comment Avatar Mike Kuketz sagt:

      Sagen wir mal so: It depends…

      Ich persönlich halte das für eine gute Variante, kann im Gegenzug aber auch für die Sicherheit des Servers / der Webseite »garantieren«. Sprich ich verfüge über das Know-How, dass der öffentliche Schlüssel inklusive Fingerprint nicht einfach mal eben ausgetauscht wird, ohne das ich es mitbekommen würde.

      Das bedeutet: Gute Variante, falls du bzw. der Anbieter in der Lage ist, entsprechende Sicherheitsmaßnahmen aufzubieten.

    • Comment Avatar savant sagt:

      jh: Nein.

      Im Prinzip kann nämlich jeder ein Schlüsselpaar mit einer oder mehreren E-Mail Adressen verknüpfen und den öffentlichen Teil auf einen Schlüsselserver hochladen bzw. irgendwo veröffentlichen. Wenn ihr also sicher sein möchtet, dass der öffentliche Schlüssel tatsächlich zum Ersteller / Besitzer gehört, könnt ihr dies nur dann eindeutig feststellen, wenn ihr den Fingerprint prüft.

      Abgesehen davon kann die Seite auch kompromittiert werden. Ein Angreifer müsste dann lediglich den auf deiner Seite hinterlegten PGP Public Key durch seinen gefälschten PGP Public Key austauschen. Das kann unter Umständen einfacher sein als du denkst. So etwas ähnliches ist passiert als die Homepage von Linux Mint gehackt wurde. Da haben Angreifer nämlich die passenden Hash-Werte zu den infizierten ISOs hinterlegt.

      • Comment Avatar GPG Nutzer sagt:

        Ich habe das für mich so gelöst das ich den Key auf meiner Webseite veröffentlicht habe und den Fingerprint habe ich in meiner Mailsignatur.

        Das halte ich für nicht perfekt aber relativ sicher.

        Ein potentieller Angreifer müsst den Key auf meiner Webseite austauschen und meine Mailpostfach kompromitieren.
        Sicher machbar aber aufwändig vermute ich.

        Oder?

  7. Comment Avatar Anonymous sagt:

    Ich nutze aus einem weiteren Grund kein GnuPG Keyserver:

    Die Keyserver speichern für immer personenbezogene Daten und wenn jemand Keys von Freunden signiert auch öffentlich einsehbar Beziehungen.

    Noch zu TLS: Mike du schreibst, wenn der Server unter deiner Kontrolle bleibt. Aber auch den Key muss unter Kontrolle bleiben.

    • Comment Avatar Mike Kuketz sagt:

      Der (private) Key befindet sich auf dem Server. Wenn ich also die Kontrolle über den Server behalte, dann impliziert das auch den privaten Schlüssel.

      • Comment Avatar Anonymous sagt:

        Hmm ich meinte den private GnuPG Key. Speicherst du den auf dem Server? Ich hoffe nicht.

        Ich meinte dass du neben dem Server auch den privaten GnuPG Key kontrollieren musst. Woher weißt du in der Regel dass der nie kopiert wurde?

        Der andere Fall ist klar: Jemand hackt z.B. den Kuketz-Webserver und tauscht die Schlüsselinfos aus. War doch bei Linux Mint mit Hashes ähnlich.

        • Comment Avatar Mike Kuketz sagt:

          Natürlich nicht. Du hast vor deinen Satz aber TLS gestellt, da bin ich vom privaten Schlüssel für eine verschlüsselte Client zu Serververbindung ausgegangen.

  8. Comment Avatar k378551 sagt:

    Der Artikel beschreibt sehr gut, warum sich die Verschlüsselung von Emails niemals in der breiten Masse durchsetzen wird. Sie bleibt eine Nische für wenige Anwender, weil es *für den normalen Nutzer* Alternativen gibt: Threema, Telegram und sogar Whatsapp.

    Threema und Whatsapp sind nicht Open Source, beide behaupten, sie seien Ende zu Ende verschlüsselt und der Anbieter könne nicht mitlesen. Threema glaube ich dies mehr als Whatsapp, aber im Prinzip ist es genau das, was „die Leute“ wollen:

    Ein simples Kommunikationsmittel, was die Nachrichten vor zufälligem Publikwerden oder dem Abschnüffeln im Arbeitsplatznetzwerk oder Zug schützt. Diese Aufgabe wird erfüllt.

    Denn seien wir mal ehrlich: Wenn jemand an eure Daten will, kompromittiert er entweder den PC des Senders oder Empfängers oder haut euch so lange auf die Mütze, bis ihr das Passwort verratet – Verschlüsselung hin oder her. Wenn man ein Unternehmen hat (so wie ich), ist es noch einfacher: Man „findet“ Kinderporno – Links auf der Firmenwebsite, die natürlich nie gefunden werden, wenn man kooperiert. Oder die Steuerprüfung kommt jedes Jahr…alles in allem kann man nur zu folgendem Schluss kommen:

    Seid so uninteressant wie möglich für einen Algorhythmus: Keine Email – Verschlüsselung, keine verschlüsselten Telefonate, ein langweiliger Facebookaccount, ein Account auf Instagram mit drei Fotos, bei Google Streetview ein sichtbares Haus (nur die verpixelten fallen auf), ab und zu mal eine Pornoseite öffnen…so wie 500 Mio. andere Nutzer gleichzeitig.

    Wirklich wichtiges bespricht man persönlich nach Verabredung, tauscht es offline aus oder meinetwegen noch per Brief (Restrisiko bleibt.). Aber lasst die Email das sein, was sie ist: Eine Postkarte. Der Aufwand ist für Lieschen Müller viel zu hoch, sodass es nur eine massentaugliche Lösung gibt:

    Keine sensiblen Informationen über Email schicken.

    Ich denke in Schichten – Öffentliche Schicht –> semiöffentliche Schicht –> private Schicht –> hochsensible Informationen. Schicht 1 kann ruhig per Email verteilt werden, bei Schicht 2 würde ich auf Whatsapp zurückgreifen, bei Schicht 3 auf Threema und Schicht 4 nur persönlich und offline.

    Trotzdem danke für den Artikel, der mir wieder einmal vor Augen führt, dass man ab einem gewissen Punkt einfach „vertrauen“ muss. Wer garantiert mir denn, dass kuketz-blog.de nicht ein BND – kompromittierter Scam ist, der dann auch den Fingerprint des PGP Schlüssels kompromittiert? Niemand…(nicht böse gemeint, Mike, dein Blog gehört zu meinen Lieblingsblogs)

    • Comment Avatar savant sagt:

      Seid so uninteressant wie möglich für einen Algorhythmus: Keine Email – Verschlüsselung, keine verschlüsselten Telefonate, ein langweiliger Facebookaccount, ein Account auf Instagram mit drei Fotos, bei Google Streetview ein sichtbares Haus (nur die verpixelten fallen auf), ab und zu mal eine Pornoseite öffnen…so wie 500 Mio. andere Nutzer gleichzeitig.

      Traurige Schlussfolgerung.

      Es ist schon klar, dass man wenig gegen zielgerichtete Überwachung unternehmen kann, sollte man nicht ein absoluter Crack in dem Thema sein. Darum geht es aber auch nicht wirklich. Es geht vor allem darum, sich gegen Massenüberwachung zu schützen, und da hilft GnuPG bzw. E2EE durchaus. Andersfalls bräuchten wir ja gar nichts mehr zu verschlüsseln. Außerdem ist es mir völlig egal, ob ich aus der Masse der Schafe heraussteche oder nicht. So lange ich mir nichts zu schulden kommen lasse, wird man nicht viel gegen mich und meinen Wunsch zu verschlüsseln unternehmen.

  9. Comment Avatar Arne sagt:

    Wichtig wäre hier auch die ct‘ [bzw. Heise.de] zu erwähnen.

    https://www.heise.de/security/dienste/Krypto-Kampagne-2111.html

    Da sie unabhängig die Personen bezogenen Daten und die E-mail Adressen Prüfen, kann man Schlüsseln die von denen Unterschrieben wurden schon sehr vertrauen.

    Auch gibt es eine Seite bei der man den Abstand zwischen zwei Keys herausfinden kann. Dies spiegelt den Web of Trust Gedanken wieder. Wenn ich Person A vertraue und A dann B vertraut und B dann C, dann kann ich mit hoher Wahrscheinlichkeit auch C vertrauen.

    • Comment Avatar Olaf sagt:

      Wichtiger wäre aber zu erwähnen, daß PGP/GPG fundamentale Schwächen hat wie kein PFS und das es deshalb fast fahrläßig ist, dies zu benutzen. Was bringt heute ein 4k-Key wenn in 20 Jahren sämtliche aufgezeichnete Kommunikation im NSA Keller entschlüßelt werden kann??

  10. Comment Avatar Reklow sagt:

    Hallo Mike,

    das die Keyserver, aufgrund der fehlenden Identitätsprüfung der Email-Adress zu einem eingereichten Schlüssel, kein Ort sind von dem man bisher unbekannte Schlüssel von Kommunikationspartnern beziehen sollte hast Du gut dar gelegt.

    Allerdings vermisse ich einen Hinweis darauf, warum die Keyserver sich so designed worden sind und wieso man trotzdem seine auf anderem Weg bezogenen öffentlichen Schlüssel der Kommunikationspartner regelmäßig aus dem Keyserver-Verbund aktualisieren sollte.

    Der Grund dafür, dass jede Person ohne Identitätsprüfung beliebige öffentliche Schlüssel auf die Keyserver hochladen kann liegt aus meiner Sicht darin, dass über diesen Weg die Signaturen eines Schlüssels durch andere PGP-Nutzer ergänzt werden können. Dieses ist die Grundlage des „Web-of-Trust“ mit dem im PGP-Konzept eine Vertrauensstellung von nicht persönlich über Fingerprint-Vergleich verifizierbarer Schlüssel realisiert werden soll.

    Der Grund, warum man regelmäßig die gesammelten öffentlichen Schlüssel, von den Keyservern aktualisieren sollte ist, dass die Keyserver der einzige sinnvolle Weg zur Verteilung von Widerrufen von Schlüsseln (dem Hinweis, dass ein Schlüssel nicht mehr genutzt werden sollte) darstellt. Dieses ist insbesondere dafür wichtig wenn ein Schlüssel kompromitiert (in die falschen Hände gelangt ist) wurde und deshalb nicht mehr für Vertrauliche Kommunikation genutzt werden sollte.

    Aus meiner Sicht gilt daher:
    – Fehlende Schlüssel direkt vom Kommunikationspartner beziehen (per Email, von der Webseite)
    – Vor Nutzung der Schlüssel, die Authentizität des Schlüssels durch Fingerprint-Vergleich persönlich mit dem Kommunikationspartner vergleichen
    – Regelmäßig die gesammelten Schlüssel von den Keyservern aktualisieren um Schlüsselwiderrufe mit zu bekommen.
    – den eigenen öffentlichen Schlüssel im Falle einer Kompromittierung widerrufen (revoken) und diesen auf den Keyserver-Verbund hochladen

    Reklow

    • Comment Avatar Mike Kuketz sagt:

      Danke für die Ergänzung Reklow.

    • Comment Avatar Christian sagt:

      Die Beschreibung stimmt schon:
      „Der Grund dafür, dass jede Person ohne Identitätsprüfung beliebige öffentliche Schlüssel auf die Keyserver hochladen kann liegt aus meiner Sicht darin, dass über diesen Weg die Signaturen eines Schlüssels durch andere PGP-Nutzer ergänzt werden können.“

      Allerdings ist das kein technischer Grund, beim erstmaligen Upload eines Schlüssels (der Fingerprint ändert sich ja später nicht, wenn der Schlüssel noch von weiteren Leuten signiert wird) auf eine (zumindest oberflächliche) Überprüfung zu verzichten.

      Ein Keyserver könnte z.B. eine Mail mit einem Bestätigungscode an die zugehörige Adresse schicken. Damit wäre das Hochladen von Schlüsseln für fremde Mailadressen zumindest erheblich erschwert.

      Leider ist mir kein keyserver bekannt, der das so praktiziert. Wenn es das irgendwo gibt, würde ich mich über einen Hinweis hier freuen

  11. Comment Avatar Dennis sagt:

    Ich kann via Thunderbird ja meinen öffentlichen Schlüssel dem gegenüber mitsenden, macht das jetzt sinn was die Verifizierung angeht?

    • Comment Avatar Mike Kuketz sagt:

      Natürlich kannst du deinen öffentlichen Schlüssel jemandem auch per E-Mail zukommen lassen. Verifizieren (also Fingerprint prüfen) sollte dein Gegenüber deinen Schlüssel dann aber über einen anderen Kanal. Es macht also keinen Sinn einen Schlüssel + dazu passender Fingerprint per E-Mail zu versenden.

  12. Comment Avatar Danilo sagt:

    Hallo Mike,

    danke für diesen aufschlußreichen Blogbeitrag! Dieser hat auch mir einmal mehr vor Augen geführt, wie sensibel anfällig das Keyserver-Schlüssel-Management sein kann. Ein besseres Beispiel als das der Plagiat-Keys hättest du an dieser Stelle nicht wählen können. Danke dafür! Aber wäre es in diesem Zusammenhang nicht sinnvoll, auch unter „https://www.kuketz-blog.de/kontakt/“ auf die Plagiat-Schlüssel hinzuweisen?

    PS: Ich bin zwar relativ neu dazugestoßen, aber inzwischen zu einem begeisterten Leser des „kuketz-blog.de“ geworden. Weiterempfehlung versteht sich von selbst. :)

    Mit besten Grüssen nach Karlsruh‘

    Danilo

  13. Comment Avatar Martin sagt:

    Hallo Mike,

    wahrscheinlich habe ich es nur überlesen, aber wie ich Posteo verstanden habe (sorry sollte keine Werbung sein ;-)) gibt es hier neue Standards für genau dieses Problem, d.h. Veröffentlichung des Schlüssels im DNS (ähnlich DANE) per OPENPGPKEY (rfc7929):

    https://posteo.de/site/verschluesselung#posteo-keys

    Just my 2 cent.

    Martin

    • Comment Avatar Mike Kuketz sagt:

      Stimmt Martin. Da es sich um einen Draft bzw. Entwurf handelt, habe ich euch das allerdings unterschlagen. Habe es jetzt aber noch unter 3.1 als Info hinzugefügt.

  14. Comment Avatar David sagt:

    Ich bin mir sehr unsicher, ob den Verweiß auf DNS/DNSSEC nicht irreführt. Klar, solange man dem Provider bzw. den Registrar traut ist alles Okay. Aber wenn mein Gesprächspartner aus einem Land kommt bei der z.B. auch staatliche Stellen bzw. staatsnahe Unternehmen schon nachweislich gefälschte Zertifikate ausstellen, kann der Glaube an die Validierung per DNSSEC dazu führen, das „die Welt“ dem DNSSEC Schlüssel zu unrecht trauen.

    Ich weiß nicht ob es besser ist doch den Aufwand in kauf zu nehmen auf anderen Weg (bzw. mehreren wegen) auf den gültigen Fingerprint zu kommen.

  15. Comment Avatar Nikname sagt:

    Wie sieht es denn mit dem Standard WebKeyDirectory aus, wo die Domain der Mailadresse selbst das Schlüsselmaterial zur Verfügung stellt?
    Da standardisiert dürfte das besser sein als den öffentlichen Schlüssel irgendwo auf der Webseite anzugeben. So kann er von E-Mail-Programmen automatisch ausgelesen und verwendet werden ohne manuellen Import.

    • Comment Avatar David sagt:

      Muss man da nicht TLS-Registries trauen, die in den Browser registriert sind, dass diese nicht auch einer falschen Website die Gültigkeit attestieren? Man könnte schon meinen, dass es vielleicht etwas besser ist das jeder etwas hoch laden kann… aber aber wer eine gültige Registry betriebt (wie viele Staaten) könnten dann auch einen DoS Angriff machen indem sie einen „falschen“ Schlüssel als echt vortäuschen, damit sie Mails z.B. edward@snowden.com abfangen können. Letztendlich gibt es nur den Fingerprint der auf einer vertrauenswürdige Weise übermittelt werden muss… am besten Face2Face.

  16. Comment Avatar Dietmar sagt:

    Hallo Mike,

    vielen Dank für den Artikel, der an Status Quo der Verteilung der öffentlichen Schlüssel gut wieder gibt. Neben dem schon erwähnten Ansatz von Posteo in Richtung Verteilung über DNS gibt es auch noch einen well-formed URL-Ansatz. Beide Ansätze befinden sich nicht nur in der Standardisierung sondern auch schon in der kommenden gnupg Version 3.0 und sind Teil einer Initiative zur Vereinfachung der Schlüsselverteilung: https://wiki.gnupg.org/EasyGpg2016

    Viele Grüße

    Dietmar

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.