Privater Schlüssel von Smart Card in Kleopatra gespeichert

Hallo,

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-----”

Mit freundlichen Grüßen

C. Lauer

Hallo C. Lauer,

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.

Viele Grüße und ein schönes Wochenende!
Christoph

Hallo,

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.

Hi,

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. :slightly_frowning_face:

Hier ist die Sicherheitswarnung: Smartcard key generation keeps an unprotected backup key on disk (auf Englisch) mit der Anleitung und weiteren Details.

Danke nochmals für die damalige Frage!

Viele Grüße,
Bernhard

Hallo @bernhard,

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

Mit freundlichen Grüßen
C. Lauer

Hallo,
hmmm, das sollte wohl nicht sein, ich werde mal die Devs anstupsen.

Danke, dass Du das nochmal berichtest!

Nur zur Überprüfung:

  • Du hast den Rechner nach dem Gpg4win Upgrade mindestens einmal neu gestartet?
  • gpg --version gibt auch 2.4.5 aus?
  • Du hast überprüft, dass in der Export-Datei wirklich der private Schlüssel drin ist?
  • Werden alle SChlüssel als “shadowed” angezeigt oder gibt es noch andere Schlüssel?
  • Hatte gpg-card checkkeys --delete-clear-copy bei Dir ausgegeben, dass es was gelöscht habe? Wie hat das die Anzeige von gpg-card checkkeys geändert?
  • Gibt es Dateien mit dem Muster sk_.gpg bei Dir auf der Platte? Wenn ja, wo?

Viele Grüße
Bernhard

Hallo @bernhard,

  • Den Rechner habe ich neu gestartet.

  • gpg4win ist Version 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.

Mit freundlichen Grüßen

C. Lauer

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.

Gruß,
Bernhard

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)

C:\Users\g10code.WIN-TEST3>gpg -K
[keyboxd]
---------
sec>  brainpoolP256r1 2024-04-05 [SC]
      22E0AE368699E3A30244D43D778A338BC4340A89
      Kartenseriennr. = 0005 00009D40
uid        [ ultimativ ] g10code
ssb>  brainpoolP256r1 2024-04-05 [A]
ssb>  brainpoolP256r1 2024-04-05 [E]

sec   brainpoolP384r1 2023-03-08 [SC]
      F8D51DE0EE16E9B57009B8DE458612006D8E6F0D
uid        [ ultimativ ] Berta Boss <Berta.Boss@demo.gnupg.com>
ssb   brainpoolP384r1 2023-03-08 [E]

Hallo @eebb,

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:

-----BEGIN PGP PRIVATE KEY BLOCK-----

lQEmBGYRIF0BCACZs7IdANGTXiuXUVky57ByoMjhk9gY8Tx/bX+0vmNMrLAcPJt5
pMrlRL0gHNaQLK78I1eUaErYeoCHTKKLADksEPIfYAAktOo/aHw4q5222jLuM68s
4t8TvntyddxlWuLxZrMb2ikP8TDCItqH2pqejih+iJaIDiSxymwQzmBSD+fOSLVZ
q1A1cnlSeMzPkw/laIsHiHO6g3rkPAWQk8dsxJId5SKeuISHQo3ttTyAD7yMVx1J
3XM+jevuRE39iYykS+qPJPPjdRata3YRqDszBAviLbR/f1gUK1C/z4nee2JGf+I5
b4UGxxtjX2wGksRRmj4lq/ADov9EjQWcbpSxABEBAAH/AGUAR05VAhDSdgABJAEA
AAAGCZInlAAAtC1NYXggTXVzdGVybWFubiA8bWF4Lm11c3Rlcm1hbm5AbXVzdGVy
bWFubi5kZT6JAVEEEwEIADsWIQT4G7EfB/8KAGxy2XMK8Ao/FHBLewUCZhEgXQIb
AwULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAKCRAK8Ao/FHBLe+5ACACGcg9F
sTWS+7SQhjerkYp1ORqCTg+Mb9YeHhcnOOrQXtXKro13loHicZbRVNWQ2EVN6V6N
dhpblHIz0PVgC1tSdiTXz+ybJ1YOAgl6zwwG8FO6stsgo96AZYVepkQHi3TyfWCH
hCpV7R9r4LZ/KmfFwNEmQT14wc+zvp98ZHOg9p4k6sgLn9KM9QLdaECqKCJgw2ZI
VKbLY1w5C3jbBTs6G6WJi4CXWkzDywAA6O31uNqiOnVhxZKfzgiJ5EGIAtnj1VX+
CiyIWTgL5lgoPWqpSqkWcSZPn6cpPiQxvWvvsBZMLoPiTZyt6jElD9OdBdzt9Lk0
HJJAB0Jb4Hx3MgJnnQEmBGYRIF0BCACpN+BsL/H24Cgfw6zB3RNm69q8TmrI5YqV
2Xkcg1azrxNB27YOShVkhj4JMv8qycdfsyShkbcA1asjHbGmSva3a0eZdMxnZAGi
Fcv+d+k2o9EhoovSHULrKQGAYbjthJNH3hHqe3mtAVB1HRDzrm6UKk4hsJ+ebQ8k
ut84HMPIUl0h9Uh1sX7hWBMyX9var0iuQTVGR+2uVt0yBA1j8ShQpniM/b1+Zfw0
Dy8wUjoPV88wCz2m8jdB23PQPAOBRiOKM5/pqevJz+3k9BvMyltDaZH7ZdJFHM+l
JvNLcMj41WiQiwhafgjCA3pyTECeupbJNG+pJdW0J/cieMes4h+VABEBAAH/AGUA
R05VAhDSdgABJAEAAAAGCZInlAAAiQE2BBgBCAAgFiEE+BuxHwf/CgBsctlzCvAK
PxRwS3sFAmYRIF0CGyAACgkQCvAKPxRwS3tX0wf/eDQq7ktZQz9mVu3+5fct/trq
hOpwYHL3Wbhfxqzeiob+uKdwjX8saB5/OplkJeO8z8T4sYUJ7rly39CG9lBXTIZ8
65dz+BidjJTgvf9WbRguKnxFq/qLex9/rsfEhUPDLw0zhCCZ1EftLi/V2dmRmgJF
FSMGIVgxKtFPZzRt13Wi9nmwyjVnzhL5oKZdkO4LVsVG1L+Z1vv811Y4WPK+H/HH
g9f0Qx68ZEvxhgpQaNJAZ06LTfVHrYTqkG5dnWWzbEUZajMhk7YSyj/PzQefOoYw
6TFsC0u3NjXr15ggEk/7BGHKVTRWbloV9hrK/h7ZzZuqiIshY+5Ht5qXiXhmFZ0B
JgRmESBdAQgAwnfxYV2q4lZeSL9FN4hyqJa9HNepDOHgBB0ey4PV+gWNd2lCf+W+
yXdsi0LDHCMKcdv1I6SQ5wXHPdxOh49KN9vnE1SSKtXn+uPV3JKikNuupX2ryEfZ
VdohLw8BJilZGpjE4I5kFAuOAm8WnfoGBCcBl8wjW6R9j5veEVE0fYCqbxR2ZkV9
InOXDNrjxiCJwj5LYiau8NDgzbkuMn3Dhhd9YD1f/53zQFe9jCJI9mdtT75eDEOs
3zaqi00249iAHyTC3qJJHvfwMQfi/FIYrltf3u79+ngx0GOjLL78J7FMPRRwEM7N
+RUMR12HAUecFxBIWZfyZ4r6Nv6d1/lBGwARAQAB/wBlAEdOVQIQ0nYAASQBAAAA
BgmSJ5QAAIkBNgQYAQgAIBYhBPgbsR8H/woAbHLZcwrwCj8UcEt7BQJmESBdAhsM
AAoJEArwCj8UcEt7PtoH/0XaTtp93agG4E/oMPVf/v4JXwSlpB+1iZ2sSMBP1Axb
2Jf2Pn9bHP+TOcEXDHWbOPUBDan9nJmwcvwhV3vOq0Fl582Oe4yCeJ3eC4ZpwYu4
bfo7Lx8Oi44s0Kss5XxUWgTzwVrt54RQN2MC7KmfJs9nIrDikSxGjrFsi3sk83tU
P7TJHEmr1OA14I2uGaJx4R+MLzENpJnVei/sS1Jd28reo5XowBcyZvAKX0R/KEZJ
/4mczaoaHEXjzQO/vEOd3Cb4EiQwiJ9I+cSLCNygt+aCSR6QiEiB0RvIA2FVCC3y
v9mJpZ622leaIgOHR+7YkHSwQWKipMh/4PHMwebJwPY=
=0+8y
-----END PGP PRIVATE KEY BLOCK-----

Es handelte sich dabei um ein RSA 2048 bit Zertifikat.

mit freundlichen Grüßen

C. Lauer

Hallo @c.lauer82,

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!

Gruß

Hi Bernhard,

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.

Und gerne!

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. :thinking:

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.