it-swarm.com.de

Wie verwalte ich GPG-Schlüssel auf mehreren Systemen?

Ich bin neu in der Verwendung von GnuPG und versuche zu verstehen, wie man es am besten verwendet. Ich habe Kurze, leicht verständliche Erklärungen zu GPG/PGP für Nicht-Techniker gelesen? , Aber die meisten Anleitungen erklären PGP mit einer Einzelmaschinenperspektive.

Ich möchte GnuPG auf drei Computern verwenden: einem Linux-PC, einem Linux-Laptop und einem Android-Telefon.

Der grundlegende Anwendungsfall ist das Verschlüsseln/Entschlüsseln von E-Mails, die von einem IMAP-Dienst verwaltet werden. Daher benötigen alle Geräte denselben privaten Schlüssel für die Entschlüsselung.

Ich denke, meine Wahlmöglichkeiten sind:

  1. Kopieren Sie einfach alle meine Schlüssel in den Schlüsselbund auf jedem Gerät und verlassen Sie sich zum Schutz hauptsächlich auf das Kennwort des privaten Schlüssels.

  2. Erstellen Sie einen Hauptschlüssel (mit --gen-key), um meine Identität darzustellen, und erstellen Sie dann einen separaten Einwegschlüssel (erneut mit --gen-key) zum Ver-/Entschlüsseln von E-Mails, der mit dem Hauptschlüssel signiert ist. Ersteres befindet sich nur auf meinem PC, letzteres wird auf jedes Gerät verteilt. Solange meine mobilen Geräte nicht gefährdet sind, bleibt der Einwegschlüssel gültig.

Ich mag übermäßig paranoid sein und das komplizierter machen, als es sein muss, aber humor mich bitte. Ich glaube daran, nicht alle Eier in einen Korb zu legen.

Der Hauptschlüssel soll meine digitale Identität sein. Es wird viel Mühe darauf verwendet, Vertrauen in Bezug auf diese Identität aufzubauen, und ich möchte lieber die Unannehmlichkeiten meiner Paranoia in Kauf nehmen, als meinen Schlüssel aus Unachtsamkeit zu verlieren und Vertrauen in Bezug auf einen neuen Hauptschlüssel aufbauen (möglicherweise ist dies nicht der Fall). Es ist so schlimm wie ich denke, aber ich bin neu in diesem .

Es ist wahrscheinlicher, dass ich meinen Laptop oder mein Telefon verliere als meinen PC. Wenn der Verlust == Kompromiss ist, dann verliere ich lieber ein verfügbares Schlüsselpaar (das ich widerrufen kann) als mein Hauptschlüsselpaar. Ich kann einem neuen Einwegschlüssel immer das Vertrauen meines Hauptschlüssels schenken.

Entschuldigung für die wirklich lange Frage. :-)

TL; DR

Reicht ein Passwort aus, um meinen privaten Hauptschlüssel auf mehreren Geräten zu speichern?

Ist mein Plan für Option 2 durchführbar? Habe ich etwas falsch gemacht oder kann es verbessert werden?

Wenn Option 2 eine schlechte Idee ist, was sind dann die Best Practices, wenn GnuPG für einen einzelnen Benutzer auf mehreren Geräten verwendet wird?

99
Justin C

Nun, das ist ein bisschen peinlich. Ich habe über einen Zeitraum von einer Woche Stunden damit verbracht, dieses Problem zu lösen, und die Antwort scheint bei Unterschlüsseln zu liegen - ein Thema, das das GnuPG-Handbuch und FAQ beschönigen.

Während ich nachforschte, was Unterschlüssel sind und warum sie anstelle von --gen-key verwendet werden könnten, stieß ich auf dieses Juwel: http://wiki.debian.org/subkeys .

In Debians Wiki wird erklärt, wie Option 2 (siehe OP) unter Verwendung eines Hauptschlüssels mit Unterschlüsseln implementiert wird, und wie der Hauptschlüssel nach dem Speichern auf einem Sicherungsmedium von einem beliebigen System entfernt wird ( zB ein Flash-Laufwerk). Die Unterschlüssel können dann auf jedem Gerät auf meine Schlüsselringe verteilt werden.

Vorteile:

  1. Verlässt sich nicht hauptsächlich auf ein Passwort, um den Hauptschlüssel zu schützen,

  2. Wenn ein System kompromittiert ist, ist der Hauptschlüssel nicht sofort verfügbar (es sei denn, ich lasse törichterweise mein Flash-Laufwerk eingesteckt oder verbinde es mit einem kompromittierten System).

  3. Dies ist eine Praxis, die vom Debian-Entwicklungsteam implementiert wurde.

  4. Verwendet die Unterschlüsselfunktion von GnuPG. Was scheint ein bisschen organisierter zu sein, als ein Bündel loser Schlüssel am Schlüsselbund zu haben, ja?

Relevanter Teil aus dem Debian-Subkey-Wiki

  1. Erstellen Sie Backups Ihrer vorhandenen GnuPG-Dateien ($ HOME/.gnupg). Bewahre sie gut auf. Wenn während der folgenden Schritte ein Fehler auftritt, benötigen Sie diesen möglicherweise, um an einen bekannten guten Ort zurückzukehren. (Hinweis: umask 077 führt zu eingeschränkten Berechtigungen für die Sicherung.)

    • umask 077; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg
  2. Erstellen Sie einen neuen Unterschlüssel zum Signieren.

    • Finden Sie Ihre Schlüssel-ID: gpg --list-keys yourname
    • gpg --edit-key YOURMASTERKEYID
    • An der Eingabeaufforderung gpg>: addkey
    • Hier werden Sie nach Ihrer Passphrase gefragt. Geben Sie sie ein.
    • Wählen Sie den Schlüsseltyp "RSA (nur Vorzeichen)".
    • Es wäre ratsam, eine Bit-Schlüsselgröße von 4096 (oder 2048) zu wählen.
    • Wählen Sie ein Ablaufdatum (Sie können Ihre Unterschlüssel häufiger als die Hauptschlüssel drehen oder sie für die Dauer des Hauptschlüssels ohne Ablaufdatum aufbewahren).
    • GnuPG erstellt (irgendwann) einen Schlüssel, aber Sie müssen möglicherweise warten, bis er genügend Entropie enthält.
    • Speichern Sie den Schlüssel: save
  3. Sie können dies wiederholen und bei Bedarf auch einen Unterschlüssel "RSA (Encrypt Only)" erstellen.

  4. Kopieren Sie nun $HOME/.gnupg auf Ihre USB-Sticks.

  5. Hier kommt der schwierige Teil. Sie müssen den privaten Hauptschlüssel entfernen, und GnuPG bietet leider keine bequeme Möglichkeit, dies zu tun. Wir müssen den Unterschlüssel exportieren, den privaten Schlüssel entfernen und den Unterschlüssel wieder importieren.

    • Exportieren Sie die Unterschlüssel: gpg --export-secret-subkeys YOURMASTERKEYID >secret-subkeys (um auszuwählen, welche Unterschlüssel exportiert werden sollen, geben Sie die Unterschlüssel-IDs an, denen jeweils ein Ausrufezeichen folgt: gpg --export-secret-subkeys SUBKEYID! [SUBKEYID! ..])
    • Entfernen Sie Ihren geheimen Hauptschlüssel: gpg --delete-secret-key YOURMASTERKEYID
    • Importieren Sie die Unterschlüssel zurück: gpg --import secret-subkeys
    • Vergewissern Sie sich, dass in gpg -K ein sec# und nicht nur eine sec für Ihren privaten Schlüssel angezeigt wird. Das heißt, der geheime Schlüssel ist nicht wirklich da. (Siehe auch das Vorhandensein eines Dummy-OpenPGP-Pakets in der Ausgabe von gpg --export-secret-key YOURMASTERKEYID | gpg --list-packets).
    • Ändern Sie optional die Passphrase, die die Unterschlüssel schützt: gpg --edit-key YOURMASTERKEYID passwd. (Beachten Sie, dass das private Schlüsselmaterial auf der Sicherung, einschließlich des privaten Hauptschlüssels, durch die alte Passphrase geschützt bleibt.)

Ihr Computer ist jetzt für den normalen Gebrauch bereit.

Wenn Sie die Hauptschlüssel verwenden müssen, hängen Sie das verschlüsselte USB-Laufwerk ein und legen Sie die Umgebungsvariable GNUPGHOME fest:

export GNUPGHOME=/media/something
gpg -K

oder verwenden Sie das Befehlszeilenargument --home:

gpg --home=/media/something -K

Der letztere Befehl sollte jetzt Ihren privaten Schlüssel mit sec und nicht mit sec# auflisten.

Mehrere Unterschlüssel pro Computer im Vergleich zu einem einzelnen Unterschlüssel für alle Computer

Auszug aus dem Debian-Unterschlüssel-Wiki. Ursprünglich in Kommentaren vermerkt. [Paraphrasierung] und Betonung meiner.

Möglicherweise ist man versucht, einen Unterschlüssel pro Computer zu haben, sodass Sie nur den möglicherweise gefährdeten Unterschlüssel dieses Computers austauschen müssen. Im Fall eines einzelnen Unterschlüssels, der auf allen Computern verwendet wird, muss dieser auf allen Computern ausgetauscht werden [wenn dieser einzelne Unterschlüssel kompromittiert wird oder vermutet wird].

Dies funktioniert jedoch nur zum Signieren von Unterschlüsseln . Wenn Sie mehrere Verschlüsselungsunterschlüssel haben, wird von gpg gesagt, dass es nur für den neuesten Verschlüsselungsunterschlüssel und nicht für alle bekannten und nicht gesperrten Verschlüsselungsunterschlüssel verschlüsselt.

58
Justin C

Als jemand, der auch keine Single Points of Failure mag (einschließlich Hauptschlüssel und insbesondere Passwörter), ist dies die Art und Weise, wie ich es tun würde. Damit können Geräte über ein Web of Trust betrieben werden, ohne dass eine dezentrale Identität erforderlich ist.

Ich weiß nicht, ob es dafür bereits ein System gibt, aber ich denke, es könnte wahrscheinlich mit einem Cron-Job und ein paar Zeilen Bash zusammen gescrobbelt werden.

In diesem System gibt es zwei Klassen von Schlüsselpaaren: Geräte-Schlüsselpaare und Zeitrahmen-Schlüsselpaare . Auf jedem Gerät wird ein Geräte-Schlüsselpaar für den Benutzer generiert, das für die gesamte Lebensdauer auf diesem Gerät verbleibt. Ein Zeitrahmen-Schlüsselpaar wird von einem zentralen Server in regelmäßigen Abständen (monatlich, täglich, stündlich - je nachdem, wie paranoid Sie sein möchten) generiert. Der öffentliche Schlüssel wird öffentlich bekannt gegeben (der Server selbst verfügt über ein eigenes Geräte-Schlüsselpaar zum Signieren), und der private Schlüssel wird verschlüsselt mit dem öffentlichen Schlüssel jedes Geräts verteilt, das Zugriff auf diesen Schlüssel haben soll. (Diese Verteilung sollte so privat wie möglich sein, z. B. wenn Geräte direkt mit dem Server verbunden sind.)

Zum Signieren von Nachrichten verwenden Sie den Geräteschlüssel des Geräts, von dem Sie die Nachricht senden. Wenn jemand Ihnen eine Nachricht senden möchte, kann er diese mit Ihrem aktuellen öffentlichen Zeitrahmenschlüssel signieren. (Sie sollten über ein automatisiertes System verfügen, um mit den Ansagen Schritt zu halten.) Sie können ihre Nachricht dann von jedem Gerät aus lesen.

Zum Lesen älterer verschlüsselter Nachrichten werden ältere Zeitrahmen-Schlüsselpaare auf jedem Gerät gemäß einer geeigneten Strategie gesichert (einschließlich des Zeitrahmen-Schlüsselpaar-Generierungsservers, wenn Sie dies wünschen - wiederum abhängig von Ihrer Paranoia-Stufe), auf dem Sie einen anderen Satz haben von passwortgeschützten Schlüsselpaaren, die die älteren Schlüssel schützen (mit so vielen Passwörtern im Laufe der Zeit, wie Sie sich gerne merken).

Wenn ein Gerät gestohlen oder anderweitig kompromittiert wird, können Sie ein anderes Ihrer öffentlich vertrauenswürdigen Geräte verwenden, um eine öffentlich signierte Nachricht zu erstellen, in der Ihre Identität überprüft wird (z. B. durch Feststellung, dass Sie an einem öffentlichen Treffen teilnehmen und/oder Lassen Sie sich von einem vertrauenswürdigen Freund persönlich verifizieren) und widerrufen Sie den gefährdeten Geräteschlüssel und alle Zeitrahmenschlüssel, auf die er Zugriff hatte. Wenn Sie den Schlüssel widerrufen, entfernen Sie das gestohlene Gerät auch aus der Liste der vertrauenswürdigen Geräte des Servers (mit einem Kennwort und Ihrem vertrauenswürdigen Geräteschlüssel).

Die Richtlinie für das Vertrauen in neu angekündigte Geräteschlüssel sollte etwa den aktuellen Vertrauensrichtlinien entsprechen. Ich glaube, dass eine angemessene Richtlinie darin besteht, dem generierenden Server, einem mobilen Gerät und einem großen und schweren Gerät zu vertrauen, da es schwer zu stehlen/zu infiltrieren ist Das Telefon eines Benutzers, ein Desktop-PC und VPS in einem gemeinsamen Überfall, bevor der Benutzer es bemerkt.

Wenn Ihr Server kompromittiert ist, widerrufen Sie ihn einfach mit demselben Verfahren, das für jedes andere kompromittierte Gerät beschrieben wurde (möglicherweise mit einer strengeren Richtlinie, die der zum Hinzufügen eines neuen Geräts ähnelt), und verwenden Sie einen neu gesicherten oder insgesamt neuen Server (mit einem) neues Geräte-Schlüsselpaar).

9