search

Nitrokey / nitrokey-app

Nitrokey's Application (Win, Linux, Mac)
https://www.nitrokey.com/
288 stars 55 forks source link

Some functions not working reliably on openSUSE Tumbleweed #181

Closed heikojansen closed 7 years ago

heikojansen commented 8 years ago

I have a Nitrokey Storage; all tests have been done using v0.5.1 of the app (on all platforms). Stick is usable just fine with openSUSE 42.1 and Windows 10, so it´s apparently not a hardware problem.

On Tumbleweed the app starts and recognizes the key. Next it takes quite a while till the message "Smartcard or SD card not ready" is replaced in the app menu.

Once I can select "Unlock password safe" and do so a password entry dialog appears: "Enter user PIN (Tries left: 88)" - yes, 88. Entering the user PIN apparently unlocks the password safe successfully.

If I select "Unlock encrypted volume" I see a slightly different dialog (the info "Tries left: 3" is positioned in the bottom left corner of the dialog instead after the text "Enter user PIN:"). A few seconds after entering the PIN and clicking "OK" a status message appears "Enabling encrypted volume" which is show for about 35 seconds, then gets replaced by a confirmation dialog: "Either the PIN/password is not correct or the command execution resulted in an error. Please try again." If I try again, PIN entry dialog now shows "Tries left: 88". In the end, retrying never helped and I could not unlock the encrypted volume on Tumbleweed.

Selecting "About Nitrokey" results in the status message "Getting device configuration (BUSY)" which is shown for 60 seconds, then gets replaced by the info window which lacks any info on the key (no card serial number, nothing).

heikojansen commented 8 years ago

Update: I just could unlock the encrypted volume once, but I am not able to reproduce at will. First unlocking the password safe, then locking the device again, then trying to unlock the encrypted volume seems to make some difference. But when trying to reproduce that (after removing an re-inserting the stick) I am now shown an "(IDLE)" progress message for a couple of minutes already...

szszszsz commented 8 years ago

Hi! This looks like a communication issue potentially connected with used libraries. If possible please provide more data to debug:

I will try to reproduce issue later using this information.

These steps could be more time consuming (ca. 1 hour), but you are welcomed to experiment if you would like to (please make sure however previous questions are answered):

  1. Could you rebuild the application from source locally and check once again? (to exclude potential binary incompatibility between your OS and the build service)
  2. (warning! tests will destroy data on device) Could you build nitrokey/libnitrokey locally with make lib and run in /unittests/ directory py.test -v command and attach log as a file here? Please set default PIN for user and admin before within test file (test_bindings.py) or on device for running this if you have changed them already. Running this will show would different implementation work on this setup. If not, it will show what basic functionality is working and what is not.

Regarding (IDLE): If you are shown (IDLE) box for more than 10 seconds then communication link is broken within that session - you have to restart the app.

heikojansen commented 8 years ago

Nitrokey Firmware: 0.38 libusb: libusb-0_1-4 v0.1.13 and libusb-1_0-0 v1.0.20 libhidapi: None, apparently. Qt: 5.7.0 Kernel: 4.8.3 System is up-to-date.

Attached debug corresponds to these steps: 1) Start app 2) Connect key 3) Try to unlock encrypted volume (no success) 4) Try to unlock password safe (reportedly successful) 5) "Konfigurieren" -> "Einmalpasswörter und Passwort Safe" -> entered admin password -> tab "Passwort-Safe": Does not allow to create new entry. 6) Klick "Passwort Safe entsperren" -> entered user password -> reportedly successful unlock -> still not possible to use anything in the "Passwort-Safe" tab. 7) Click "Abbrechen" 8) Tried to unlock encrypted volume -> entered user password -> status info with a few hundred calls of some command -> no success 9 ) Locked device 10) Clicked "About" -> surprisingly works 11) Unlock encrypted volume -> surprisingly works (KDE reports new usb storage device) 12) Locked device 13) Exported debug log nitrokey-debug.txt

Regarding testing (other) functions: I´m just getting my feet wet with nitrokey. Do not yet understand what should work and how (biggest problem for more wide-spread adoption is imho lack of more detailed and especially coherent documentation connecting all the distributed bits and pieces scattered over so many apps and tools).

So far for tonight. Will see what other info I can provide tomorrow.

jans23 commented 8 years ago

Your firmware is old which is a high chance of being the root cause. Please update it and try again. Thanks.

heikojansen commented 8 years ago

Yeah, well, ... was Indigogo backer so got an early version and according to a mail I got a few weeks ago I cannot update the firmware - have to either send my key in for replacement or order a second one on special discount. Wanted to play around with the device prior to making a decision about just that and then things got complicated pretty fast...

jans23 commented 8 years ago

I see. But I don't think its useful to continue debugging with this firmware version. Please replace and test it again. That would be very helpful.

szszszsz commented 8 years ago

As Jan said, the debug info gathered with this firmware version might be misleading. Also the issue might be already fixed with latest firmware. Please reopen in case issue would still appear on Tumbleweed, thank you!

(closing as invalid since registered on old firmware)

szszszsz commented 8 years ago

I have checked the logs BTW and it looks like the issue is on firmware side. I wonder why it behaves differently under Tumbleweed. Might be coincidence.

heikojansen commented 7 years ago

I'm afraid this issue needs to be re-opened.

Got my replacement Nitrokey on Thursday. Connected it to my notebook running Tumbleweed - stick was recognized right away; could open the "About" window without problem and it showed the firmware version (v0.43), serial number etc. I then initialized the stick as recommended; after about one hour it was done, I disconnect and reconnected the stick as ordered. And since then I could not use the stick or even get the app to show the firmware version etc. again! I see the same behavior on another computer also running openSUSE Tumbleweed. On the other hand I could use the stick without problems on a third computer which has both openSUSE 42.1 and Windows 10 on it: opened the "About" window on both OS and saw the firmware number; stored a password in the password safe; formatted the encrypted volume with exFAT on Windows and was able to read a file from it on openSUSE 42.1.

I have attached a new debug log nitrokey-debug-2.txt which corresponds to these steps:

At some time during this process the message "Chipkarte oder Speicher sind nicht bereit" in the app menu gets replaced with the real functions menu; but even when in subsequent tries for the "About" window the "Startup infos (busy)" message is immediately replaced by "Getting device configuration (busy)" the outcome stays the same.

Clicking on "Password-Safe entsperren" does show the pin entry dialog (with "Tries left: 77"!). If I enter the user pin, the app shows a "success" message but at the same time a small progress window with the word "Idle" appears and won´t go away anymore without closing the app.

szszszsz commented 7 years ago

Hi! @heikojansen Sorry to hear that. Thank you for detailed description. Log shows exactly as you described. I will try to reproduce it on Monday. Note to self: device locked up on STICK20_CMD_SEND_STARTUP command.

szszszsz commented 7 years ago

Sorry for delay. I have installed Tumbleweed on Virtual Box and tested stick's behaviour both with your scenario and generally. It worked normally. I had no long delays, encrypted and hidden volumes unlocked correctly. About window shown normally. I had to add iomem=relaxed (as here is mentioned) to kernel's command line to run X, maybe this one helped - could you check?

Specs:

Unfortunately I have little experience with Suse and Tumbleweed being experimental is also not helping.

heikojansen commented 7 years ago

Regarding kernel param: never needed anything like that and cannot imagine it has anything to do with the problem I encounter. I´ll try it tonight anyway and will report back.

Regarding "Tumbleweed being experimental": no, it´s not. Quoting https://en.opensuse.org/Portal:Tumbleweed : "Tumbleweed contains the latest stable applications and is ready and reliable for daily use." I´ve been running it on two computers for about two years now without serious issues.

Regarding using VirtualBox: The other way round does not work. I can access the unencrypted storage of the stick in a Windows 7 VBox guest on a Tumbleweed installation just fine - but password store, encrypted volume, "About" window etc. do not work there, either.

And while I cannot argue with your findings I still experience the problem described previously on two independent computers (one Lenovo notebook, one Fujitsu desktop) running the latest Tumbleweed...

heikojansen commented 7 years ago

I´ve now tested "iomem=relaxed" which did not fix the issue.

Looking through some logs I found these entries in /var/log/messages:

2016-11-23T23:02:45.628783+01:00 mtron kernel: [ 1654.074499] usb 3-2: new high-speed USB device number 6 using xhci_hcd 2016-11-23T23:02:45.768734+01:00 mtron kernel: [ 1654.216042] usb 3-2: config 1 interface 1 altsetting 0 bulk endpoint 0x4 has invalid maxpacket 64 2016-11-23T23:02:45.768774+01:00 mtron kernel: [ 1654.216047] usb 3-2: config 1 interface 1 altsetting 0 bulk endpoint 0x85 has invalid maxpacket 64

No idea what that means but according to some sources on the net, it looks like the Nitrokey as a high-speed device should report "maxpacket 512". Don´t know if that is true and if it is at all related to the problems I described above.

heikojansen commented 7 years ago

Looking at the dmesg output on openSUSE 42.1 (working) and Tumbleweed (not working) I fail to see any significant differences.

There is a difference if I connect the Nitrokey to a USB3 port on my Tumbleweed notebook or to a USB2 port on the same device: With USB3 I get a bunch of these messages:

[ 578.959764] xhci_hcd 0000:00:14.0: WARN Event TRB for slot 2 ep 10 with no TDs queued?

But since the Nitrokey works neither on USB2 nor on USB3 on this notebook / Tumbleweed instance these messages appear to be unrelated to the problem.

szszszsz commented 7 years ago

Hi! Sorry for rather long delay. Again thank you for checking that kernel param and additional observations! Checking on VBox was rather a try to confirm is issue general or specific to driver (this probably) and it does not proves anything (would be easier though to debug if it would occur). Obviously it does not work on your side and that is a fact. I will have to install it then on bare-metal machine (that will take a moment though) and debug there. As for experimental - indeed, sorry, I might probably read some old forum post describing that. Regarding maxpacket 512, it is set to 64 for low speed USB ports and this is why USB3 is complaining probably. It should not be shown on lower speeds USB ports. WARN Event TRB for slot 2 ep 10 with no TDs queued messages should not influence using the device, it will be checked though (https://github.com/Nitrokey/nitrokey-storage-firmware/issues/24).

heikojansen commented 7 years ago

Just to let you know: I´ve just updated the app to v0.6.1 (via https://build.opensuse.org/package/show?project=security&package=nitrokey-app ) but - as expected, given the changelog entries - the problem described in this issue remains unaffected. Hopefully I´ll be able to update the computer currently running openSUSE 42.1 to 42.2 during the next weekend so I can test the device there, too.

heikojansen commented 7 years ago

Took me longer than expected but I finally found time to update one machine to openSUSE 42.2. Using the NitroKey apparently works there (app v0.6.1). As Leap/42.2 uses the somewhat older SLES 12.1 packages as base while Tumbleweed use more current versions the problem may be rooted there. Unfortunately I cannot offer any new clues beyond that.

szszszsz commented 7 years ago

Thank you for checking that. I wonder what are the breaking changes in Tumbleweed. Another thing might be checked - that is running Python tests within libnitrokey project on Tumbleweed. I hope to check that as soon as I finish current tasks. If you would like to you can do it yourself, but beware - these will overwrite your data on the device.

heikojansen commented 7 years ago

Didn't have time to work on this for quite a while but had the opportunity to update my configuration a few days ago; right now I'm using Firmware v0.46 together with App v1.1 on openSUSE Tumbleweed and it seems like the problems described above are gone. I wasn't able to test everything but the device is recognized reliably and I can unlock both the password safe and the encrypted storage. I don't know what changed and when but for now I consider this issue resolved and will close it.

jans23 commented 7 years ago

Thank you for your feedback.