I have a Nitrokey Storage 16G which seems to work almost fine on Linux, but shows a lot of problems on a Mac running High Sierra. Firmware is 0.48. I did not set up an hidden volume. Works fine as an OpenPGP smart card.
sometimes after connecting the key, the app hangs and I have to restart it;
sometimes, unlocking the encrypted volume takes more time than usual, and fails with Could not unlock encrypted volume: Status code: -1; however the corresponding volume appears in the Finder anyway, empty but with more than 21 GB of free space… which is weird given I have the 16GB model; removing the key and trying again a couple of times will result in the encrypted volume being mounted correctly;
clicking the Eject button in the Finder always result in the volumes (encrypted or unencrypted) reappearing, meaning that I can’t remove the key or lock the encrypted volume safely; the only way I’m able to get the volumes to stay unmounted is by ejecting the “Nitrokey Nitrokey Storage Media” entries from Disk Utility – but this only works sometimes; ejecting works fine on Linux;
possibly related to that, I experienced data corruption with the encrypted volume a couple of times: a volume named “SECRET” with one file appeared as “Untitled”, and empty, after reconnecting the key and successfully unlocking the volume; note that I didn’t do any other “administrative” operation in between (like say, generating GPG keys or factory reset or whatever);
On top of this, I can’t use the Password Safe with Linux or macOS, as attempting to unlock it always result in my personalized User Pin being rejected. Also for these failed unlock attempts, the “Tries left” counter does not decrease. It decreases only if I enter one of the default pins.
I assume the first question will be: Which Version of the App are you using ? It might be the combination of App and FW that leads into a looping re-mount.
I was going back ( but that was 6 months ago ) to FW 0.45 to stop the remount under macOS
Hi fernando,
unfortunately there is a problem with firmware version 0.48 on macOS. We are totally aware of it and are working on this, next release should fix that. Please use version 0.47 instead. This should work fine.
Regarding the password safe: this situation probably could be caused by issuing smartcard reset using gpg-connect-agent. The AES keys got deleted by this action as well. This should be fixed by using the “Destroy encrypted data” function (new keys got generated). This, of course, also deletes the Storage. So with this you would do a reset.
unfortunately there is a problem with firmware version 0.48 on macOS. We are
totally aware of it and are working on this, next release should fix that.
Please use version 0.47 instead. This should work fine.
Good to know, I’ll try over the weekend to see what happens.
Regarding the password safe: this situation probably could be caused by
issuing smartcard reset using gpg-connect-agent. The AES keys got deleted by
this action as well.
Makes sense as I did a reset with GnuPG, some time before trying to use the
safe. Yesterday I did a reset with the NitroKey app and now locking/unlocking
the Password Safe works.
By the way, for resetting I followed the instructions in the FAQ, and I think
they require an update?!
Option 1, if the device is not fully blocked and if you remember the valid
Admin PIN use Nitrokey App to unblock the Nitrokey. Your keys won’t be lost:
Open a terminal (on Windows: Press the Start button and enter “cmd”) and
start the Nitrokey App with “nitrokey-app --admin”. Klick on the Nitrokey
App’s tray icon, select “Configuration” and “factory settings”.
I clicked on “Configure” > “Special Configure” > “Factory reset” (as they were
the menu names most closely matching the FAQ), and after that the GPG keys were
lost. Not a big deal because I’m not really using the device yet, but still a
bit… surprising.
Following the proposed solution of firmware downgrade proposed here, I experienced issues described in Dfu-programmer fails with "no device present" . Once the firmware downgrade issues resolved, I am sorry to report that the majority of the multiple issues described by fernando in that post appear unresolved:
Namely:
Clicking the Eject button or using other GUI means in the Finder to eject disks always result in the volumes (encrypted or unencrypted) reappearing, meaning that one cannot remove the key or lock the encrypted volume safely; the only way one is able to get the volumes to stay unmounted is by ejecting the “Nitrokey Nitrokey Storage Media” entries from Disk Utility – but this only works sometimes; ejecting works fine on Linux – this behavior is unacceptable is unchanged in 0.47.
Data corruption happens between sessions of locking and unlocking the encrypted volume, and appears unrecoverable. It is unsure if this is due to the inevitable unsafe removals described above, or to otherwise faulty software, or both.
The device (the app) reports frequent disconnections and reconnections despite a healthy appearing USB connection (not experienced in other operating systems running on the same hardware, so assumed to be due to flaky coding).
On a good note, the GnuPG integration (on the Mac, using the Suite) appears unaffected by these problems, though I will need to run more tests before permanantly committing keys to this apparently very unreliable device, with a very fragile software implementation.
Connection / disconnection messages are often shown because MacOS is closing connections to all HID devices when any window with enabled Secure Input (like terminal) or generally any password window shows up. This is designed to block keyloggers, but other HID applications get shot too. If you experience other situation when the disconnection message is shown, could you describe it briefly?
the device got reconnected instantly. This is necessary to being able to further work with the device if you e.g. unmount encrypted volume and want to open the hidden device.
I would highly recommend to disable the automount feature of storage devices by macOS. We can not prevent macOS auto mounting the Nitrokey ourselves. This is operating system stuff and not directly related to the Nitrokey. The point is just, that we do different things with the storage of the Nitrokey and therefore want to be able to reconnect device without actually unplugging it. Every time this happens, macOS tries to auto-mount it. I don’t know of any way preventing this.
The problem that existed before (firmware < .50) was indeed a erroneous reconnection of device.
Thanks for the feedback. I think so, too. We’ll think about it and want to improve the general instructions anyway. Point is… some people will generally want to have automount on…
We can not prevent macOS auto mounting the Nitrokey ourselves.
I stumbled on this while reading up on how to disable automount, maybe you can figure out if/how to use it from the Nitro app.
Point is… some people will generally want to have automount on…
It’s… understandable
But here I am with one bug report and a couple of tips for other users!
Bug: the encrypted volume stays visible after locking
To reproduce:
Unlock the encrypted volume
Create a text file on it
Eject the volume from Finder
Wait for it to reappear
Lock the encrypted volume
Go back to the Finder: the volume is still there, you can click on it, see the text file’s icon and name and even open it (with double click)
I did not think about listing the content from the shell, maybe it’s just some Finder shenanigan, however although the content of the file showed as gibberish in TextEdit, I did not get some kind of “file not found” error.
How to deal with automount
There are two options
Disk Arbitrator will prevent any disk from automounting when connected, however the functionality can be accessed from the menu bar and it does not require to open Disk Utility.
An entry in fstab can selectively prevent a volume from automounting
