Hello, I am using a Nitrokey Storage (60Gb / Firmware Version: 0.54). All in all I am very happy with the device! I think it is a great product.
However, sometimes when I want to lock the device (which I always do before I quit the app in order to shut down my computer) the app crashes during the locking process. I realised that on my Mac this crash happens for sure always after my Mac has been in sleep modus, but sometimes (not always) also without my Mac entering sleep modus. Before it crashes I always manage to dismount the hidden volume and then I terminate VeraCrypt. Also locking the encrypted partition works fine. Yet as soon as I try to lock the device after my Mac has been suspended, the Nitrokey App crashes. Then, in order to shut down my Mac I have to first force quit the Nitrokey App. Also as soon as I try to re-open the Nitrokey App it immediately crashes again. Only after switching the Mac off and on it can be started normally (the problem persists across a normal reboot). The only other way to restart the Nitrokey App is by doing a force quit, then I physically unplug the Nitrokey and plug it back in and then I start the Nitrokey App again. Next thing is that the Nitrokey (Unencrypted Volume) cannot be ejected like a normal USB drive - force eject only works via the command line (diskutil unmount /dev/disk*s1). While the Nitrokey App crashes, its logfile grows to a up to 7MB in size…
Am I doing something wrong?
Is there something I can do to fix this?
Or is this a bug that you can perhaps fix in a future firmware update?
Regards,
Term7
Here is a link to my logfile (I did an early force quit):
Sorry for the trouble!
I have looked into the log - apparently the device has locked itself. The only way to unlock it now, is to a make power cycle by reinserting the device to the USB port. The Nitrokey App should catch up with the re-connected device. One should first unmount any used volumes from the Storage stick, to avoid data loss.
In the future release, Nitrokey App v1.5.0, the macOS compatibility will be focused on and issues like this should be eliminated. The Storage firmware will be probably updated later as well to address that.
Possible workarounds for the time being:
Nitrokey App v1.3.2 (releases page) is reported as more stable by other forum users. However OTP writing operations are not available there (see Storage-releases), though regular OTP usage should work.
Disabling smart card access from the OS, in case this feature is not used at all. I do not know at the moment though, how to do it.
Thanks for the quick response.
I will try Nitrokey App v1.3.2 to test if it is more stable - as long as regular OTP usage still works.
Disabling smart card access is not really an option. I am actively using it (PGP with Enigmail) and it works like a charm!
The device was supposed to be locked! I used the option in the Nitrokey App Menu to lock the device. Yet at the same time clicking this option causes the app to crash.
About dismounting: I always dismount any encrypted storage volume before I try to lock the device. So far I have not suffered any data loss on the hidden or on the encrypted volume. And yes - after the app crashes the only way to get the Nitrokey back to working again is to unplug it and plug it back in (interrupt its power supply).
Just the unencrypted 2GB Volume cannot easily be dismounted. This only works via the command line.
Thank you again for your suggestions. I am looking forward to the next Nitrokey App v1.5.0 release!
Sorry, I have used wrong words. I meant rather, that it locks-up, as in stopping responding to commands due to an internal issue, before receiving the actual lock command and executing it (briefly firmware waits infinitely for the smart card to be released by the OS, to execute further commands).
The locking procedure execution is not required to be run before disconnecting the device, though it is recommended. The actual volume unmounting from the OS side is more crucial here, to keep the data synchronized.
About the unencrypted volume (UV), AFAIR it is actually remounted back after a successful unmounting, which should not be an issue. Running the command line unmount will make sure though, that the volume would not be left in the ‘opened’ state during the device disconnection, thus not making the OS complaining about this. Hopefully this issue will be solved in the next firmware updates.
I am glad Enigmail works for you! In case I would come up with any other workaround, I will post it here.
Will keep you updated about the further releases as well.
In generic, there is also another way of a work-around in case you don’t use storage and keys simultaneous: you could use a VM to access the storage and NK app under Windows or another OS. After usage you could eject the NK from the VM and re-mount it under macOS for use with your email program.
And yes, it is more complex and I would not recommend to do it, when you often need the storage part of NK. More for once a day …
