Verfahren zu PGP-Schlüsseln

Added by Nicolai Parlog over 5 years ago

Im Rahmen der Entwicklung der Kommunikationsrichtlinie haben wir auch über Verschlüsselung gesprochen. Prinzipiell wollen wir für die Do-FOSS-Adressen PGP-Schlüssel anlegen, um verschlüsselte Kommunikation mit uns zu erlauben und außerdem die Bedeutung von Datenschutz und -sicherheit zu betonen. Dabei gibt es mehrere Fragen zu klären. Die vielleicht wichtigste:

Soll jeder seinen eigenen Schlüssel erhalten?

Die naheliegende Antwort ist "Ja, klar!", aber die andere Variante hätte auch Vorteile. Z.B. müsste nicht jeder, der verschlüsselt und signiert mit uns kommunizieren will, für jeden Gesprächspartner einen neuen Schlüssel besorgen und verifizieren. Muss jemand mehrere Adressen verwalten (z.B. und ), müsste er dennoch nur einen Schlüssel kennen. Außerdem würde es uns im Zweifelsfall vereinfachen, gegenseitig in unsere Postfächer zu gucken, falls das notwendig sein sollte.

Der offensichtliche Nachteil ist, dass das Geheimnis weniger geheim ist, was insbesondere bei Fluktuationen in der Gruppe jener, die es kennen müssen zu Problemen führen kann. Dem kann man ein wenig entgegen wirken, indem wir jeden Schlüssel von vornherein z.B. nach einem Jahr ablaufen lassen.

Was ist eure Meinung?


Replies (14)

RE: Verfahren zu PGP-Schlüsseln - Added by Till Schäfer over 5 years ago

Wir sollten meiner Meinung nach mit einem guten Beispiel voran gehen und die jeder mit @do-foss Adresse sollte einen eigenen Key haben.
Wir sollten die Keys auch auf der Website direkt verlinken und einen Fingerprint dahinter schreiben.

Ich halte nichts vom Key-Sharing zwischen uns. Besser keine Sicherheit als Pseudo-Sicherheit, wenn irgendwann keiner mehr weiß, wer alles mitliest. Vor allem, was macht man in dem Fall in dem eine Person mal nicht mehr mitlesen soll? Für alle den Key wechseln?
Einen Key welcher fest mit der Redaktion verknüpft wir und im Zweifelsfalle an eine neue "Redaktion" weitergegeben wird halte ich jedoch für unkritisch.

Wenn wir uns alle gegenseitig signieren, dann ist das Problem mit dem "ich muss 100 Keys verifizieren" auch Geschichte.

RE: Verfahren zu PGP-Schlüsseln - Added by Denis Kurz over 5 years ago

Geht es in dieser Diskussion auch um die personalisierten E-Mailadressen? Wenn jemand eine verschlüsselte E-Mail an schickt, sollte er meiner Meinung nach auf jeden Fall sicher sein können, dass nur ich sie auch lesen kann.

Bei den Topic-Adressen bin ich mir nicht so sicher. Ich würde einem privaten Schlüssel, der von mehr als einer Person genutzt werden kann, automatisch weniger trauen. Je mehr Benutzer, desto größer die Chance, dass der Schlüssel kompromittiert ist. Auf der anderen Seite sollten wir Verschlüsselungs-Neulingen nicht signalisieren, dass geteilte Schlüssel eine gute Idee sind.

Ich wäre wohl am ehesten dafür, dass es für die personalisierten Adressen je einen Schlüssel gibt, der mit niemandem nie nicht geteilt wird. Für alle anderen Adressen sollte es keinen Schlüssel geben. Stattdessen machen wir irgendwie deutlich, an wen man schreiben muss, wenn man doch mal eine verschlüsselte Mail an schicken muss. Blöderweise ist das nicht so einfach umzusetzen wie es sich anhört. Die nicht-personalisierten Adressen können sonstwo auftauchen, und jedes Mal diesen Hinweis dazuzusetzen wäre aufwendig und hässlich. Das könnte man evtl. mit einer mehr oder weniger prominent platzierten PGP-Wiki-Seite umgehen. Andere Lösungen fänd ich zumindest aus Krypto-Sicht deutlich schlimmer.

Ich weiß auch nicht, ob ich jemals einen geteilten privaten Schlüssel signieren werde.

RE: Verfahren zu PGP-Schlüsseln - Added by Nicolai Parlog over 5 years ago

Geteilte Schlüssel

Ich habe mir schon gedacht, dass ihr geteilte Schlüssel nicht gut findet, aber ich wollte mal nachhorchen, ob ihr nicht doch Möglichkeiten seht, das einigermaßen sicher zu gestalten. Anscheinend aber nicht und eure Einwände sind richtig und wichtig und deswegen machen wir das nicht.

Denis Kurz schrieb:

Ich wäre wohl am ehesten dafür, dass es für die personalisierten Adressen je einen Schlüssel gibt, der mit niemandem nie nicht geteilt wird. Für alle anderen Adressen sollte es keinen Schlüssel geben. Stattdessen machen wir irgendwie deutlich, an wen man schreiben muss, wenn man doch mal eine verschlüsselte Mail an schicken muss.

Stattdessen machen wir es so. Also erst mal Schlüssel nur für die personalisierten Adressen; ich kann mir tatsächlich vorstellen, dass die rollenorientierten keinen brauchen.
Es gibt auch schon das Vorhaben einen Artikel zu den Ansprechpartnern zu verfassen (siehe #25). Dort soll beschrieben werden, wer wofür ansprechbar ist und dann können ebenfalls die Schlüssel eingefügt, angehängt oder verlinkt werden. Diesen Artikel kann man natürlich nicht überall verlinken, wo die Adressen auftauchen, aber wenn jemand uns so sensible Informationen schicken möchte, dass Verschlüsselung erforderlich ist, macht er das hoffentlich eh nicht an .

Verschlüsselung

Wollen wir vorschreiben wie Do-FOSS-Absender verschlüsseln sollen? INLINE oder MIME? Falls INLINE, mit Anhängen oder ohne. Machen wir Vorgaben zur Schlüssellänge? Seit 2.2.0 kann Kleopatra unter Windows auch 4096-bit-Schlüssel erstellen.

Ich persönlich finde die "INLINE vs MIME"-Problematik ziemlich anstrengend und je nach E-Mail-Programm werden solche Mails auch unterschiedlich gut angezeigt. Deswegen steht mir nicht gerade der Sinn nach einer Diskussion zu dem Thema. Aber eigentlich ist es gerade deswegen umso wichtiger, dass wir uns auf was einigen, damit alle unsere Empfänger zumindest einheitlich zerschossene Mails bekommen (z.B. mit signature.asc).
Bei der Schlüssellänge sehe ich keinen Grund, nicht 4096 bit vorzuschreiben.

RE: Verfahren zu PGP-Schlüsseln - Added by Till Schäfer about 5 years ago

Soweit ich weis sieht die Diskussion zum Thema sehr kurz zusammengefasst folgendermaßen aus:

  • INLINE:
    • altes Verfahren, speichert Verschlüsselungsinformationen direkt im Text-Body (dadurch immer Krypto-Salat in der Mail beim lesen ohne PGP-Inline fähigem Client).
    • Problematisch bei Anhängen: Jeder Anhang muss einzeln verschlüsselt und signiert werden (und damit auch entschlüsselt werden). Von dem Standard werden verschlüsselte Anhänge eigentlich gar nicht berücksichtigt, man kann aber natürlich trotzdem verschlüsselte Dateien anhängen.
  • PGP/MIME
    • neueres Verfahren, soll INLINE ablösen und löst verschiedene Probleme von PGP-INLINE
    • speichert Signaturen getrennt von dem Inhalt (kein Krypto-Salat, dafür aber ein Krypto-Anhang)
    • verschlüsselt Anhänge
    • Problematisch: nicht alle Clients sind aktuell PGP/MIME fähig.
      • z.B. gibt es aktuell keinen FOSS-Client für Android der PGP/MIME unterstützt.
      • ältere Outlookversionen (aber noch gebräuchliche) können das nicht.

=> aus technischer Sicht würde ich PGP/MIME verwenden, aus Kompatibilitätsgründen könnte PGP-INLINE jedoch in einigen Fällen notwendig sein.

Vorschlag: Wir verwenden PGP/MIME. Wenn jemand die Mail nicht lesen kann wird er sich hoffentlich schon beschweren und wir senden die Mail dann halt noch mal im INLINE Format.

RE: Verfahren zu PGP-Schlüsseln - Added by Till Schäfer about 5 years ago

Ich habe noch mal drüber nachgedacht und ich denke, dass wir doch lieber INLINE-PGP verwenden sollten um die Hemmschwelle verschlüsselt zu kommunizieren niedrig zu halten. Soweit ich weiß ist INLINE-PGP nicht prinzipiell unsicherer und Anhänge werden wir wohl auch eher selten verschicken. Hinzu kommt, dass uns ja weiterhin Leute PGP/MIME Mail schicken können.

RE: Verfahren zu PGP-Schlüsseln - Added by Nicolai Parlog about 5 years ago

Also 4096 bit und INLINE-PGP? Bin ich für.

Sowohl im Blog als in Redmine sollen die öffentlichen Schlüssel verfügbar sein. Gibt es da einen präferierten Weg? Mein Vorschlag wäre (alles davon!):
  • Angabe des langen Fingerprint
  • Link zu einem Key-Server (welcher?)
  • Download als Datei

Außerdem schlage ich vor, dass auch bei rollenbasierten Adressen signiert wird. So kann ein Empfänger zwischen Nicolai schreibt von redaktion@ und Till schreibt von redaktion@ besser unterscheiden.

RE: Verfahren zu PGP-Schlüsseln - Added by Denis Kurz about 5 years ago

Eigentlich bin ich immer gegen die Verwendung von schon abgelösten Technologien. Dass wir aber an einem PGP/MIME-unfähigen Client scheitern könnten, ist leider ein gutes Argument. Ich könnte also ausnahmsweise mit INLINE—PGP leben. Man könnte sich natürlich fragen, ob jemand, der 1337 genug ist, seine Mails zu verschlüsseln, überhaupt Outlook benutzen oder seinen privaten Schlüssel auf ein Smartphone laden würde :p

Bei der Schlüssellänge gab es bisher keine Gegenstimmen, oder? Ich bin auch für 4096b.

Auch bei den Kanälen für die öffentlichen Schlüssel kann ich nur zustimmen. Je mehr Kanäle, desto schwieriger ist es, jeden davon zu kontrollieren. Ist es sinnvoll, den öffentlichen Schlüssel (zumindest beim Erstkontakt) per Mail-Anhang (separat verschlüsselt ;) mitzuschicken?

Bei Nicolais Signatur-Vorschlag (Mails von mit dem Schlüssel des Senders zu signieren) wittere ich zwei Probleme:

  1. Der Mail-Client könnte sich wehren, wenn man eine Mail, die als verschickt wird, mit dem Schlüssel für nicolai.parlog@do-foss signiert werden soll.
  2. (gravierender) Schafft man es doch, sich dem Protest des Mail-Clients beim Versenden zu widersetzen, wird die Signatur beim Empfänger wahrscheinlich als ungültig und die Mail damit als Betrugsversuch angezeigt.

Das könnte man dadurch umgehen, dass ein eigenes Schlüsselpaar generiert, mit separaten Unterschlüsseln für die, die damit signieren wollen. Wir haben uns aber schon mal gegen Schlüsselpaare für geteilte Adressen entschieden.

RE: Verfahren zu PGP-Schlüsseln - Added by Nicolai Parlog about 5 years ago

Auch bei den Kanälen für die öffentlichen Schlüssel kann ich nur zustimmen. Je mehr Kanäle, desto schwieriger ist es, jeden davon zu kontrollieren. Ist es sinnvoll, den öffentlichen Schlüssel (zumindest beim Erstkontakt) per Mail-Anhang (separat verschlüsselt ;) mitzuschicken?

Da kann ich nicht ganz folgen. Wer versucht in dem Satz die Kanäle zu kontrollieren? Ein potentieller Angreifer?
Verstehe ich dich also richtig, dass du meine drei Kanäle unterstützt?

1. Der Mail-Client könnte sich wehren, wenn man eine Mail, die als verschickt wird, mit dem Schlüssel für nicolai.parlog@do-foss signiert werden soll.

Zumindest Thunderbird hat sogar eine Einstellung dafür. Da kann man beim Konto statt der Standardeinstellung E-Mail-Adresse eines Kontos verwenden, um OpenPGP-Schlüssel zu identifizieren einen konkreten Schlüssel angeben, der für das gesamte Konto, also alle Identitäten, zu verwenden.

2. (gravierender) Schafft man es doch, sich dem Protest des Mail-Clients beim Versenden zu widersetzen, wird die Signatur beim Empfänger wahrscheinlich als ungültig und die Mail damit als Betrugsversuch angezeigt.

Good Point. Habe Denis und mir eben eine Test-Mail geschickt...

RE: Verfahren zu PGP-Schlüsseln - Added by Denis Kurz about 5 years ago

Da kann ich nicht ganz folgen. Wer versucht in dem Satz die Kanäle zu kontrollieren? Ein potentieller Angreifer?
Verstehe ich dich also richtig, dass du meine drei Kanäle unterstützt?

Genau.

Good Point. Habe Denis und mir eben eine Test-Mail geschickt...

Funktioniert bei KMail einwandfrei. Bei Thunderbird anscheinend auch.

RE: Verfahren zu PGP-Schlüsseln - Added by Till Schäfer about 5 years ago

  1. Der Mail-Client könnte sich wehren, wenn man eine Mail, die als verschickt wird, mit dem Schlüssel für nicolai.parlog@do-foss signiert werden soll.
  2. (gravierender) Schafft man es doch, sich dem Protest des Mail-Clients beim Versenden zu widersetzen, wird die Signatur beim Empfänger wahrscheinlich als ungültig und die Mail damit als Betrugsversuch angezeigt.

Nicolai und ich müssen dann halt nur die redaktion@... E-Mail unserem Schlüssel hinzufügen, oder? Ich kann ja auch persönlich später meinen Schlüssel für eine bestehende E-Mail ändern. D.h. es gibt nur eine Zuordnung Schlüssel (+ Identität) -> E-Mail, aber nicht anders herum.

RE: Verfahren zu PGP-Schlüsseln - Added by Nicolai Parlog about 5 years ago

@Till:
Es scheint nicht notwendig zu sein, die redaktion@-Adresse zum Schlüssel hinzuzufügen. Weder KMail noch Thunderbird machen beim Versand oder beim Empfang einer Mail, die von redaktion@ verschickt, aber mit some.guy@ signiert wurde, Probleme.
Im Gegenteil sollen wir den Schlüssel keinesfalls mit der Adresse verknüpfen. Sonst würde man beim Versand an die Adresse zwei potentielle Schlüssel zur Auswahl haben. Und egal welchen man wählt: nur einer von uns kann die Mail dann lesen.

@All:
Wenn ich genauer drüber nachdenke, ist das sogar ein Argument gegen das signieren... Es könnte Empfänger dazu verleiten, Mails an die Adresse mit dem Schlüssel, mit dem signiert wurde, auch zu verschlüsseln.

RE: Verfahren zu PGP-Schlüsseln - Added by Nicolai Parlog about 5 years ago

Im gestrigen Telefonat haben wir folgendes beschlossen:

  • es wird weiterhin keine Schlüssel für geteilte Adressen geben
  • Nachrichten von geteilten Adressen werden nicht signiert - in der Kommunikationsrichtlinie ist bereits festgehalten, dass von diesen Adressen keine "persönlichen Gespräche" geführt werden sollen.
  • ein Hinweis, dass für private Adressen ein Schlüssel existiert, muss prominent platziert werden
  • im Profil der Mitglieder soll der Schlüssel auf drei Wegen angegeben werden:
    • Angabe des langen Fingerprint
    • Link zu einem Key Server
    • Download als Datei

@Till: Kannst du bitte Standards für den Key Server (also welchen wir angeben) und die Dateien (Dateiname und -endung; eventuell weitere Eigenschaften wie Kodierung, ...) definieren?

RE: Verfahren zu PGP-Schlüsseln - Added by Till Schäfer about 5 years ago

Es gibt im wesentlichen zwei Formate für PGP-Keys:

  • Der binäre Schlüssel (Standarddateiendung: ".key")
  • Der ASCI armor konvertierte Schlüssel (Standarddateiendung: ".asc")

Binäre Schlüssel sind etwas kleiner, können aber nicht einfach per copy und paste über Text-Only Kanäle (IM, Mail) geschickt werden oder Textuell auf der Website gezeigt werden. Da wir die Schlüssel zum direkten Download anbieten wollen, kommen beide Formate in Betracht. In der aktuellen Zeit kodiert auch der Mailclient eine Binärdatei von selbst. Eigentlich sehe ich daher keine Gründe die ASCI-Armor-Variante zu nehmen. Trotzdem verwendet fast jede Anleitung im Internet die ASCI-Armor-Variante. Von daher würde ich vorschlagen es genau so zu machen (vielleicht habe ich da irgendwelche Kompatibilitätssachen übersehen).

Befehl um den Schlüssel zu exportieren (mit Namensschema ähnlich zu dem Mailadressennamenschema)

gpg -a --output <vorname>.<nachname>-key.asc --export <Schlüssel-ID> 

RE: Verfahren zu PGP-Schlüsseln - Added by Nicolai Parlog almost 5 years ago

Beim Treffen am 06.09.2014 wurde beschlossen:
  • wir verwenden die oben beschriebenen ASCI armor keys
  • falls ein Key Server benötigt wird, wird der vom MIT verwendet

Alles hier entschlossene findet sich in der Kommunikationsrichtlinie. Damit ist das Thema bis auf weiteres abgeschlossen.

(1-14/14)

Add picture from clipboard (Maximum size: 300 MB)