warum ist der Private Schlüssel von meiner OpenPGP Smart Card in Kleopatra
gespeichert? Und das auch noch völlig ungeschützt? Ich konnte den Schlüssel in der CMD mittels: gpg --export-secret-key --armor “Fingerabdruck des geheimen Schlüssels” auslesen. Obwohl die Karte nicht eingelegt war und vorher auch nicht benutzt wurde.
Die Key Ausgabe in Base64 begann mit “-----BEGIN PGP PRIVATE KEY BLOCK-----”
wenn Sie den Schlüssel mithilfe von Kleopatra erstellt und dann auf die Smartcard übertragen haben, ist es normal, dass dieser immer noch in Kleopatra bzw. Gpg vorhanden ist. Schließlich könnte es ja auch sein, dass man diesen Schlüssel noch irgendwo anders hinterlegen möchte. Deswegen sollten Sie den Schlüssel manuell löschen. Bitte sorgen Sie aber dafür, dass sie auch einen Fallback haben für den Fall, dass die Smartcard verlieren o.ä.
Dass der Schlüssel ungeschützt ist, liegt vermutlich daran, dass Sie kein Passwort bei der Erstellung des Schlüssels angegeben haben. Soweit ich weiß, braucht man auch kein Passwort, wenn der Schlüssel nur auf einer Smartcard ist. Wenn er aber auch auf einer Festplatte o.ä. als Backup gespeichert wird, ist es sinnvoll, den Schlüssel mit einem Passwort zu versehen.
ich habe den Schlüssel mit Kleopatra unter der Schaltfläche “Smartcards” direkt auf dem Yubikey erstellt, unter der Schaltfläche “Neue Schlüssel erzeugen”. Danach war der Schlüssel auch unter “Zertifikate” zu sehen. Dann hat Kleopatra anscheinend den neu erzeugten Schlüssel auf dem Yubikey in die interne Datenbank übernommen. Das darf doch eigentlich gar nicht sein.
vermutlich werden intern die gleichen Schritte ausgeführt, als wenn man den Schlüssel ganz normal erstellen und dann übertragen würde. Und es macht ja auch Sinn. Stellen Sie sich vor, Sie würden einen Key auf dem Yubikey erstellen und dieser würde nicht in Kleopatra gespeichert sein. Dann hätten Sie nicht mal die Möglichkeit, ein Backup dieses Schlüssels noch zu erstellen. Sollte also Ihr Yubikey auf irgendeine Weise verschwinden, hätten Sie keine Chance mehr, bereits verschlüsselte Dateien zu entschlüsseln.
Es gäbe natürlich die Option, den User beim Erstellen eines Schlüssels auf dem Yubikey zu fragen, ob dieser in Kleopatra gespeichert werden soll (bzw. nach der Übertragung gelöscht werden soll).
Hallo @c.lauer82,
es stellt sich heraus, hier war doch ein Defekt im Spiel. Es tut uns leid, dass wir das nicht schon im März nicht richtig erkannt haben.
ich habe den Sicherheitshinweis der hier veröffentlicht wurde (Smartcard key generation keeps an unprotected backup key on disk) folge geleistet. Leider ohne Erfolg. Leider kann ich immer noch mit:
gpg --export-secret-key --armor “Fingerabdruck des geheimen Schlüssels”,
den privaten Key auslesen, obwohl der Hauptschlüssel mit den Unterschlüsseln
als “shadowed” angezeigt wird. Ich benutze Gpg4win 4.3.1
gpg --export-secret-key --armor “Fingerabdruck des geheimen Schlüssels” erzeugt eine Bildschirmausgabe, die mit: -----BEGIN PGP PRIVATE KEY BLOCK----- anfängt.
Alle Schlüssel werden als “shadowed” angezeigt, auch die Unterschlüssel, insgesamt 3.
Nein alle Schlüssel waren beim ausführen von gpg-card checkkeys --delete-clear-copy bereits als “shadowed” angezeigt. Ich habe zur Sicherheit den Befehl trotzdem ausgeführt.
Nein Dateien mit dem Muster sk_.gpg gibt es nicht.
Hallo @c.lauer82,
danke für die zusätzlichen Informationen, ich frage mal nach, wie wir das weiter analysieren können.
Wenn Du magst, könntest Du beim Export mal mit mehr Diagnoseausgabe laufen lassen und schauen, ob da steht, wo der den geheimen Schlüssel findet. Also gpg -vvv oder gpg --debug-all -vvv.
Es kann dann sein, dass Du diese Optionen auch beim gpg-agent angeben musst, dazu brauchst Du die Konfigurationdatei (oder erstellst sie neben gpg.conf) und bringst diese dort ein.
Weißt Du schon wie das geht, sonst stellen wir Dir das zusammen.
Hi,
erst mal auf die Schnelle, damit du dir keine Sorgen mehr machst:
Das ist normal, der exportierte Secret Key ist nur ein Stub, kein geheimes Schlüsselmaterial. Entscheidend ist das “shadowed”, was bedeutet, dass der Key auf einer Smartcard liegt.
Ich schreibe später noch was ausführlicheres.
Nein alle Schlüssel waren beim ausführen von gpg-card checkkeys --delete-clear-copy bereits als “shadowed” angezeigt. Ich habe zur Sicherheit den Befehl trotzdem ausgeführt.
Dann warst du von vorne herein nicht betroffen, vermutlich weil du den Key nicht mit gpg4win 4.2.0 erzeugt hast, sondern einer anderen, nicht vom Bug betroffenen Version.
Wie gesagt zeigt ein sinnig aussehender Output beim Export nicht an, dass geheimes Schlüsselmaterial vorhanden ist, nur das mindestens ein Stub file existiert, welches anzeigt, dass der Key auf einer Smartcard liegt.
Wenn du dem gpg-card checkkeys Output nicht traust, kannst du auch in die Keyfiles selber reinschauen, wie auch auf der schon erwähnten Seite dazu beschrieben.
Wenn die erste Zeile mit Token: anfängt und die Zeile darunter mit Key: (shadowed-private-key ist alles ok.
Im Normalfall reicht es, dir den Output von gpg -K für den Key anzusehen.
Hier siehts du den Output für einen Key, dessen geheimer Teil nur auf einer Smartcard liegt und darunter einen Key, der auf der Festplatte gespeichert ist.
Zu erkennen daran, das bei dem Key auf der Smartcard vor den (sub)keys ein “<” davor steht (das Zeichen soll die Ecke einer Karte andeuten)
ich kann deine Aussage bestätigen. Ich habe einen Test durchgeführt. Ich habe auf meinem Yubikey 5 ein OpenPGP Zertifikat erstellt und eine Datei damit verschlüsselt. Danach habe ich die Bildschirmausgabe, die “gpg --export-secret-key --armor 0AF00A3F14704B7B” erzeugt, per copy/paste als txt datei gespeichert und in eine *.asc Datei umbenannt. Danach habe ich den Schlüssel vom Yubikey 5 in Kleopatra gelöscht. Nach einem Neustart habe ich dann die *.asc Datei in Kleopatra impotiert und mit meinem eigenen Schlüssel beglaubigt. Ein entschlüsseln der Datei war nicht möglich. Die Bildschirmausgabe, die “gpg --export-secret-key --armor 0AF00A3F14704B7B” erzeugt hat, sah wie folgt aus:
grundsätzlich habe ich angenommen, dass Du den --export-secret-key gemacht hast, als die Smartcart (oder das Token) draußen war.
Dass das Kommando dann doch eine Ausgabe liefert finde ich auch erstmal leicht verwirrend, aber wenn das gemeime Schlüsselmaterial nicht drin ist, passt es ja.
Danke für die Aufklärung @eebb!
das macht keinen Unterschied, Also nicht, wenn die Smartcard schon bekannt ist, weil gpg beim “ersten Kontakt” das Stubfile angelegt.
Dass das Kommando dann doch eine Ausgabe liefert finde ich auch erstmal leicht verwirrend, aber wenn das geheime Schlüsselmaterial nicht drin ist, passt es ja.
Ja, ich war auch zuerst irritiert und habe mich bei Werner rückversichert vor meiner Antwort.
Lohnt da vielleicht ein Problembericht auf dev.gnupg.org, es wäre möglich einen Hinweis auszugeben so als Warnung, ala “exportiere nur den Stub, kein privates Material”. Da könnten wir dazuschreiben, wie eine solche Datei mit privatem Header getestet werden kann, ob überhaupt privates Schlüsselmaterial drin ist oder ein Stub. Vielleicht wäre auch eine Kommentarzeile in der Export-Datei ein guter Hinweis.
Nur zur erklärung, die stub files können auch hilfreich sein. Damit man z.B. in einer anderen installation gleich hinterlegt. Das “Sicherungskopie vom Geheimen Schlüssel erstellen” bieten wir für smartcards nicht an um niemanden zu verwirren. Aber wer sich die Mühe macht und bei den Subkeys exportiert kann das vielleicht gebrauchen.
Ich bin mir nicht sicher ob wir damit nicht die Kompatibilität gefährden. Bei Public Keys hatten wir mit den Kommentaren schon Probleme. Würde ich lieber lassen. Aber wir könnten die Aktion im Subkeywidget entsprechend Umbennen. Von Message Boxen halte ich nach wie vor nichts.
Da habe ich nur laut gedacht, wie wir potentielle Verwirrungen verringern könnten, zB. da liegt eine Datei, ich schau mit dem Editor rein und sehe PGP PRIVATE KEY BLOCK aber da ist kein private Key Material drin.
Ich vermute der Stub ist eh nicht RFC4880 konform, dass bedeutet, eigentlich kann damit nur GnuPG umgehen. Der Comment als Armor Header Key ist jedoch definiert. Zusammen genommen erscheint mir das gangbar, falls Du mit Schwierigkeiten andere Implementierungen gemeint hast. Ich denke GnuPG und Kleopatra muss mit den Kommentaren eh umgehen können. Die ändern ja nichts am Verhalten, helfen nur Leuten die verstehen wollen was vorgeht.