ich habe einen Nitrokey Storage, den ich jetzt seit ca. Februar benutze. Vorher hatte ich ca. 1.5 Jahre den Nitrokey Pro. Ich benutze ihn fast ausschließlich unter Arch Linux und ganz selten Windows 7. Vor ca. fünf Tagen habe ich die Nitrokey.App über Arch AUR geupdatet, wobei es nur bei der Library geklappt hat, die jetzt auf Version 3.3 ist, während die App noch 1.2 ist. Ich habe es aber eben unter Windows 7 mit der neuesten App probiert, die man auf der Webseite findet mit gleichem Ergebnis.
Völlig unvermittelt reagiert der Key sehr seltsam. Der unverschlüsselte Storage wird sofort erkannt, sowohl unter Windows als auch Linux. Unter Linux zeigt mir gpg --card-status alle Infos an wie üblich. Versuche ich dann eine Nachricht über mein Mailprogramm zu signieren oder eine verschlüsselte Nachricht zu entschlüsseln, erscheint der PIN-Dialog und ich gebe wie üblich meine User-PIN ein. Diese wird aber nicht akzeptiert, obwohl sie richtig ist (habs mehrfach gecheckt). Spannend ist, dass der Zähler für die möglichen PIN-Eingaben auf 2 steht und sich auch nicht ändert, egal ob man die richtige oder falsche PIN eingibt. Ein Ändern die User-PIN ist nicht möglich. Versuche ich das verschlüsselte Volumen zu entsperren, kommt ebenfalls die Meldung mit der falschen PIN.
Mein Problem hier besteht darin, dass auf dem Storage wichtige Daten sind, zum Beispiel ein Key-File zur Entsperrung einer Keepass-Datenbank mit Zugangsdaten für ca. 4000 Systeme und dutzender Services. Das wäre zwar alles einzeln wiederherstellbar, aber dafür müsste ich jedes System einzeln anfassen bzw. die Zugangsdaten aus der Offline-Doku holen. Das Key-File ist aus Sicherheitsgründen nicht nochmal irgendwo gespeichert, weil genau dafür legt man sich ja die dedizierte Hardware in Form eines Nitrokeys zu.
Ein Factory-Reset würde mich vermutlich Wochen an Arbeit kosten und ich hoffe, dass es eine weitere Möglichkeit gibt das zu entsperren. Admin- und User-PIN sind mir ja bekannt, es scheint eher so zu sein, dass irgendwas auf dem Key hängt.
App-Version 1.3 unter Windows, 1.2 unter Arch Linux (die App 1.3 baut nicht richtig, Lib ist 3.3) Die Firmware des Keys ist 0.50.
Kann es eventuell daran liegen, dass die App nicht mit der etwas neueren Lib klarkommt? Wenn ja, dann erwartet mal besser noch mehr Leute, die unter Arch genau in dieses Problem laufen.
soweit ich das sehe, sind hier verschiedene Dinge am Werk. Beim Entsperren des Speichers verwendest du die App und libnitrokey. Wenn du in deinem Mailprogramm Mails signieren oder entschlüsseln willst, nutzt du aber ausschließlich GnuPG, so dass deine Probleme vermutlich nichts mit der Software zu tun haben, sondern auf Smartcard Ebene bereits bestehen (meine Vermutung).
Dennoch zunächst zur App: Vermutlich musst du deine libnitrokey Version (oder libnitrokey-git) zunächst deinstallieren und dann libnitrokey neu bauen, damit das ordentlich läuft. Zumindest gab es da in der Vergangenheit eins zwei mal Probleme. Bei mir läuft libnitrokey 3.3 und App 1.3.
$ sudo pacman -Qs nitrokey
local/libnitrokey 3.3-3
Communicate with Nitrokey stick devices in a clean and easy manner
local/nitrokey-app 1.3-3
Nitrokey management application
Aber wie gesagt, ich denke, dass das nicht wirklich dein Problem ist. Was sagt denn
gpg --card-status
genau? Dort müsstest du sehen könnnen, welchen Status deine ‘PIN retry counter’ haben.
Selbst wenn deine User PIN geblock ist (erst Zahl in der Reihe ist ‘0’), dann kannst du das Gerät mittels admin PIN wieder unblocken. Hierfür müsstest du ‘gpg --card-edit’ -> ‘admin’ -> ‘passwd’ -> ‘2’ auswählen und deine admin PIN eingeben. Aber vielleicht pastest du erst einmal deine Ausgabe für ‘gpg --card-status’ hierher.
Mh, das sieht komisch aus. Es scheint so, als wenn der Zugriff auf deine OpenPGP Card nicht funktioniert. Das erklärt dann natürlich auch, warum der key counter nicht mehr herunter zählt.
Ich nehme an du erhältst das gleiche Fehlerbild auch auf einem anderen System? Also ich meine jetzt insbesondere die Kommunikation via gpg wie zum Beispiel das unblocking?
Wie ich oben geschrieben habe, ist es auf mehreren Systemen so, sowohl unter Linux als auf Windows. Linux habe ich Arch auf mehrere Workstations und Laptops, die weitestgehend taeglich aktualisiert werden, maximal 2-3 Tage, also immer recht aktuell. Unter Ubuntu wie Debian habe ich es auch probiert, gleicher Effekt.
Hast Du Nitrokey App auf anderen Systemen probiert oder auch das Zurücksetzen der PIN mit GnuPG? Versuch doch bitte, die PIN mit GnuPG2 auf einem anderen System zurück zu setzen.
Genau, ich meinte libnitrokey 3.3. Ich habe das auf den anderen Systemen sowohl mit gnupg als auch der NitrokeyApp versucht.
Gestern Abend habe ich auch nochmal einen Raspberry Pi aufgesetzt und es mit dem versucht. Gleiches Ergebnis mit gnupg wie auch der manuell gebauten Nitrokeyapp.
Ich habe die Lösung inzwischen gefunden. Bitte stabil hinsetzen.
Nachdem ich die letzten Tage ohne Erfolg an dem Key herumgedoktert habe, hatte ich gestern den Durchbruch. An einem FreeBSD war die Smartcard plötzlich ansprechbar. Es war nicht nötig den Zähler zurückzusetzen oder ähnliches. Danach hat es auch unter Windows wie auch Ubuntu funktioniert. Sobald ich den Nitrokey in ein Arch Linux gesteckt habe, wurde er nach ein paar Zugriffen “gebrickt” und hat sich dann verhalten wie zuvor. Der Fehler war reproduzierbar. FreeBSd hat das dann jedes Mal unbricked.
Dann habe ich mich hingesetzt und die Unterschiede zwischen Arch und Ubuntu angeschaut. Dann ist mir aufgefallen, dass bei Ubuntu der pcscd als Service gestartet wird, während er bei Arch als Socket lauscht. Das ist auch laut Arch Wiki ok so:
GnuPG with pcscd (PCSC Lite)
Note: pcsclite and ccid have to be installed, and the contained systemd service pcscd.service has to be running, or the socket pcscd.socket has to be listening.
Das lief mehrere Jahre ohne Probleme, auch mit anderen GnuPG-Smartcards. Nachdem ich unter Arch den Service gestartet und den Socket deaktiviert hatte, läuft es. Leider geht aus keinem Log etwas hervor, was die Ursache des Problems war. Möglicherweise hat eine Kombination aus Softwareupdates dazu geführt. Falls ihr eine Erklärung dafür habt, würde mich die wirklich interessieren. Ich denke, dass irgendwas auf der Karte nicht richtig geschrieben wurde durch einen Kommunikationsfehler, wie oben schon vermutet.
Das ist mir bisher nicht untergekommen, aber ich nutzte den pcscd auch nur, wenn ich gerade OpenSC nutze, ansonsten ist der bei mir aus, weshalb ich in der Regel auch nicht in diesen Fehler laufen kann. Wenn du nicht OpenSC oder einen pkcs11 Dienst nutzt, würde ich an deiner Stelle pcsc deinstallieren. Für “normale” GnuPG Anwendungen brauchst du diesen Dienst nicht.
Ich frage mich gerade ob man (wo) einen Bug Report dazu öffnen könnte. Du scheinst das ja reproduzierbar hinzubekommen. Ich wüsste jetzt aber nicht, wie ich das Problem bei mir direkt nachstellen könnte… Irgendwelche “Tipps”?
Ich werde übers Wochenende mal ein frisches Arch aufsetzen. Durchaus möglich, dass es eine Sache ist, die erst durch die monatelangen rolling updates entstanden ist. Eine andere Idee, der ich noch nachgehen will, ist meine Puppet-Konfiguration, über die ich neue Rechner aufsetze. Das halte ich zwar für recht unwahrscheinlich, weil das alles ziemlich nahe am Standard ist, aber da es auf allen meinen Arch-Systemen so ist, würde ich das auch nicht ausschließen wollen. Mein Tip derzeit ist eine Abhängigkeit zwischen Paketen, die in letzter Zeit aktualisiert wurden. Schwer zu sagen wo man da einen Bugreport eröffnet, wenn überhaupt ein einzelnes Paket verantwortlich sein sollte.
Das sollte eigentlich nie Probleme machen und gilt ja für alle Arch Systeme. Auf meinen Dienst- und Privatrechner hatte ich bisher diese Probleme nicht.
Sag bescheid, wenn du dazu etwas herausfinden solltest.
Auf jeden Fall erst einmal gut, dass du den Fehler finden konntest. Ich hätte erst einmal vermutlich nicht helfen können…
