Tag Archives: GnuPG

HowTo: GnuPG mit unbegrenztem Signing-Key und ablaufendem Encryption-Key

Sperrig, die Überschrift, also worum geht’s? Ich zitiere mal aus dem GnuPG-Handbuch:

Wenn Sie ein neues Schlüsselpaar erzeugen, werden standardmäßig ein DSA-Hauptschlüssel zum Unterschreiben und ein ElGamal-Unterschlüssel zum Entschlüsseln erzeugt. Dies ist von Vorteil, weil die Aufgaben der beiden Schlüssel verschieden sind und es sinnvoll sein könnte, den beiden Schlüsseln verschiedene Verfallsdaten zu geben. Der DSA-Hauptschlüssel wird benutzt, um digitale Unterschriften zu leisten, und er bestätigt Ihre Identität dadurch, daß andere ihn signiert haben. Der ElGamal-Unterschlüssel wird nur benutzt, um an Sie geschickte verschlüsselte Daten zu entschlüsseln. Typischerweise sollte eine digitale Signatur eine lange oder unbegrenzte Gültigkeitsdauer haben; Sie wollen ja auch die Unterschriften auf Ihrem Schlüssel, die Sie mühsam zusammengetragen haben, nicht verlieren. Andererseits sollte der ElGamal-Unterschlüssel in gewissen Zeitabständen gewechselt werden, um Ihre Datensicherheit zu erhöhen, da ein Angreifer, wenn der ElGamal-Unterschlüssel geknackt ist, alle Dokumente lesen kann, die für diesen Schlüssel verschlüsselt worden sind oder es noch werden.

Darauf folgt noch ein kurzer Hinweis, dass das etwas umständlich ist, aber wie genau man das anstellt, ist quasi als Hausaufgabe überlassen und deswegen1 zeige ich das jetzt hier.

Zunächst erstellt man sich einen Schlüssel ohne Ablaufdatum, der Wizard packt sonst auf beide Unterschlüssel ein Ablaufdatum und das wollen wir ja eigentlich nicht:

gpg --gen-key

Heutzutage ist das kein DSA/ElGamal-Paar, sondern beides sind RSA-Schlüssel, aber Details kann man in einem beliebigen HowTo zur Schlüsselerstellung nachlesen. In meinem Fall hab ich zu Testzwecken das hier erhalten:

pub   4096R/8C5DE4C1 2013-09-27
  Schl.-Fingerabdruck = 1EDD 0AF2 9CA3 A110 A30F  D404 3C63 79A9 8C5D E4C1
uid                  Alice (Testschlüssel) 
sub   4096R/79C6C593 2013-09-27

Als nächstes bearbeite ich diesen Schlüssel:

gpg --edit-key 0x8C5DE4C1

Hier gibt es jetzt eine Reihe von Befehlen, die man sich mit help anzeigen lassen kann. Zunächst ist list ganz hilfreich. Die Ausgabe davon:

gpg> list

pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096R/79C6C593  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel) 

Den Unterschlüsseln ist ein »sub« vorangestellt, allerdings nicht nummeriert. Man wählt nun den Encryption-Key aus mit key 1 oder wenn man bereits mehrere Unterschlüssel hat, muss man durchzählen, die sind freundlicherweise geordnet. GnuPG markiert den soeben ausgewählten Unterschlüssel mit einem Sternchen:

gpg> key 1

pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 4096R/79C6C593  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel) 

Der nächste Befehl ist expire. Zuvor kann man sich mit list nochmal überzeugen, dass auch nur der Unterschlüssel ausgewählt ist. GnuPG ist an der Stelle aber so freundlich bei der Nachfrage nochmal klar zu stellen, dass man nur das Ablaufdatum des Unterschlüssels ändert. Sieht dann so aus:

gpg> expire
Ändern des Verfallsdatums des Unterschlüssels.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
        = Schlüssel verfällt nach n Tagen
      w = Schlüssel verfällt nach n Wochen
      m = Schlüssel verfällt nach n Monaten
      y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 2
Key verfällt am So 29 Sep 2013 12:47:52 CEST
Ist dies richtig? (j/N) j

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Alice (Testschlüssel) "
4096-Bit RSA Schlüssel, ID 8C5DE4C1, erzeugt 2013-09-27

                              
pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 4096R/79C6C593  erzeugt: 2013-09-27  verfällt: 2013-09-29  Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel) 

Hier sieht man jetzt, dass der Key, dem das »pub« vorangestellt ist und bei dem es sich um den Signing-Key (SC) handelt, immernoch kein Verfallsdatum hat, der Encryption-Key (E) hingegen schon.

Bis hier hin wäre das das Vorgehen, wenn man sich einen neuen Schlüssel erstellt oder bereits einen hat, der bisher kein Ablaufdatum hat. Hat man seinen Schlüssel bereits auf einen Keyserver geladen, empfehle ich nicht am Ablaufdatum rumzufummeln. Solche Änderungen kommen womöglich nie beim Gegenüber an. Dann lieber neuen Schlüssel machen.

Was nun, wenn der Encryption-Key droht abzulaufen? Man fügt mit addkey einen neuen hinzu. GnuPG fragt dann nach allerlei Details, u.a. wie lange der neue Unterschlüssel gültig sein soll. Bei der Frage, was für ein Unterschlüssel es werden soll, wählt man einen für »nur verschlüsseln« und dort sinnvollerweise die Variante RSA mit der vorgebenen oder einer größeren Schlüssellänge:

gpg> addkey
Schlüssel ist geschützt.

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Alice (Testschlüssel) "
4096-Bit RSA Schlüssel, ID 8C5DE4C1, erzeugt 2013-09-27

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (3) DSA (nur unterschreiben/beglaubigen)
   (4) RSA (nur signieren/beglaubigen)
   (5) Elgamal (nur verschlüsseln)
   (6) RSA (nur verschlüsseln)
Ihre Auswahl? 6
RSA-Schlüssel können zwischen 1024 und 4096 Bit lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 
Die verlangte Schlüssellänge beträgt 2048 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
        = Schlüssel verfällt nach n Tagen
      w = Schlüssel verfällt nach n Wochen
      m = Schlüssel verfällt nach n Monaten
      y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1m
Key verfällt am So 27 Okt 2013 11:57:50 CET
Ist dies richtig? (j/N) j
Wirklich erzeugen? (j/N) j
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
.............+++++
..........+++++

pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 4096R/79C6C593  erzeugt: 2013-09-27  verfällt: 2013-09-29  Aufruf: E   
sub  2048R/C82D05DE  erzeugt: 2013-09-27  verfällt: 2013-10-27  Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel) 

Hier hab ich jetzt gleichzeitig zwei gültige Encryption-Keys, aber das diente ja nur zum Zeigen und Ihr werdet den Key auch auf keinem Keyserver finden.

Mit save verlässt man den Editiermodus und dann lädt man den mit neuem Encryption-Key versehenen Schlüssel wie gewohnt auf den Keyserver hoch.

Übrigens habe ich meinem eigenen PGP-Schlüssel mit dieser Methode auch gerade einen frischen Encryption-Key spendiert. Falls sich Euer Mailprogramm beschwert, dass Ihr mir keine verschlüsselten Mails mehr schicken könnt, ladet Euch mal meinen aktuellen Public-Key! ;-)

  1. und weil ich Frank Lanitz das mal auf einer Keysigningparty bei den Chemnitzer Linux-Tagen versprochen hatte, ach und wegen der im Netz39 bevorstehenden Keysigningparty, na und natürlich, weil der Encryption-Key bei mir bald abläuft … []

IT-Projekte 2009

Das Jahr ist zwar schon etwas fortgeschritten, trotzdem habe ich mir vorgenommen, bis zum Ende des Jahres in meiner Freizeit ein paar IT-Projekte voranzubringen. Aus der doch recht großen Auswahl der Projekte, die mich interessieren, habe ich die folgenden herausgepickt:

  1. IMPULS: Dieses Projekt hat inzwischen doch schon ein paar Jahre hinter sich und es gab diverse Situationen, in denen ich es gebraucht hätte. Bis Ende des Jahres sollten hier ein lauffähiger Daemon (aber auf Java-Basis) und ein paar Clients sowie mindestens ein Reader stehen.
  2. Antiblau: Den Server haben wir seit Ende 2005, aber noch immer sind ein paar Funktionen nicht verfügbar und auch die vorhandene Administrations-Infrastruktur kann mal modernisiert werden.
  3. Debian: Entwickler werde ich wohl in diesem Jahr nicht, aber ein paar Pakete aus eigenen Sachen möchte ich bauen und wenigstens soweit in die Community reinschauen, dass ich sicher entscheiden kann, ob ich überhaupt Entwickler werden will.
  4. QCaff: Eine grafische (Qt-basierte) Variante von CAFF, die sowohl unter Windows als auch unter Linux laufen soll und das Management von GPG-Keys für Jedermann ermöglichen soll. Insbesondere bei der Nachbereitung von Keysigning-Parties besteht hier offenbar Softwarebedarf. Wenn alles klappt, ist das aber trotzdem ein recht überschaubares Tool. Sofern vorhanden, werde ich bestehende Lösungen weiterverwenden.

Weiterhin warten auch bei UniMentor interessante Programmieraufgaben und der FaRaFIN kann ebenfalls mit einem interessanten Projekt aufwarten. Anfang 2010 werden wir sehen, was davon ich umsetzen konnte.

Organisiertes Vertrauen

Eine Idee, die ich heute Nachmittag schon hatte, nachdem Keysigning, GeoCaching und verwandte Dinge gerade mehr oder weniger unsere Gesprächsthemen sind:

Es wäre doch nett, ein Portal zu haben, mit dessen Hilfe man Keysigning-Parties (KSPs) jeglicher Größenordnung organisieren könnte.

Ich stelle mir das so vor:

Man meldet sich dort an und bekommt dann die Möglichkeit, neben seinen aktuellen Schlüsseln auch seinen Aufenthaltsort anzugeben. Damit ist es schonmal leicht, herauszufinden, wer in der Umgebung noch einen PGP-Schlüssel besitzt.

Wer eine KSP organisieren möchte, legt ein entsprechendes Event mit Termin und Austragungsort an. Anschließend können andere Nutzer sich dafür anmelden, wobei sie gegebenenfalls sogar automatisch auf die KSP in ihrer Nähe hingewiesen wurden.

Eine dritte Funktion könnte eine Art Marktplatz sein, auf dem man sich zum Key-Signing verabreden könnte. Wer kein Problem damit hat, mal einen Schlüssel zu verifizieren, gibt das entsprechend bekannt (z.B. durch ein Häkchen im Profil und eine Angabe von Orten, an denen man ihn leicht treffen kann) und wenn man Leute sucht, die einen neuen Key verifizieren, kann man dort einfach auflisten lassen, wer denn in Frage kommt oder eine entsprechende Anfrage stellen und hoffen, dass sich jemand anbietet (auf diese Art lässt sich vermeiden, dass sinnlos Daten ausgespäht werden).

Nebenbei gibt es natürlich Informationen und Tools für KSPs, zum Beispiel eine Möglichkeit, sich ein nett designtes Formular mit allen Fingerprints der KSP-Teilnehmer herunterzuladen oder eine Liste mit Schlüsselschnipseln zum Ausschneiden und Weiterverteilen.

Wenn viel Serverlast ürbrig ist, kann man sogar Vertrauensnetzwerke berechnen und visualisieren. Der Kreativität sind da keine Grenzen gesetzt.

Falls es eine solche Plattform schon gibt oder jemand Lust hat, das umzusetzen: Lasst es mich wissen! Ich habe im Moment leider keine Zeit dazu.