Lost encrypted volume

Nitrokeys
1

Hi,

I hold a Nitrokey storage 16GB on the latest 0.50 firmware and run it with the NitroKey App 1.2 on the latest macOS.

Setting up an encrypted volume (named it NITROKEY) to hold my existing keepass database worked like a charm for the first days, but now the encrypted volume seems to be gone. Instead I see two times the volume called “NITROAPP”. What is wrong?

Another observation: On macOS the volumes immediately get remounted as I unmount them. How should I ever be able to remove the stick safely from my computer if it is simply impossible to unmount them before removing the hardware? Is that the reason why the secured volume crashed?

Trying this stick now on Windows 10 with one volume called “NITROAPP” and one volume where it says that I should insert a medium into the flash reader. What flash reader? There is no flash reader.

I am severely unhappy with this implementation.

BR
Uwe

1 Like
2

Hi!
Sorry for the trouble. Sometimes the unencrypted volume gets doubled on the MacOS with the unknown cause. Reinserting the device should help. If not, you would need to use eject command on the device’s volumes in the Disk Utility system tool.
Registered as Storage#58.

After the attempt of unmounting the volumes they should be synchronized with the write buffers and it should be ready for safe removal.
Auto-mounting is registered as Storage#45.

Device right after insertion presents two disks to the OS - always available unencrypted volume and unlockable encrypted volume. Before unlocking encrypted volume is presented as medium-less (similarly to CD-ROM drive without inserted disc) and this is the source of this message.

3

Thanks for clarification.
After leaving the Nitrokey unmounted for half an hour I tried again and it behaves as expected.
Unable to tell a reason I can confirm: Nothing was lost.
Still the question is how two independent systems (Mac & Windows) had issues.
My impression is that the Key had to cool down (in electrical terms: fully discharge) until it became operational again. But this is just a guess.

Kudos for the prompt support.

BR
Uwe

1 Like
4

Great!

I thought #58 and #45 was occurring only on Mac and not on Windows - have I got this wrong?

I think the cause is more prosaic and the effects are rather not dangerous, but surely confusing.
That reminds me of something - just before issue occurred, have you left the device in the USB port after issuing ‘sleep’ state on Mac, waited for some time and woke it again?
Anyway, please let us know if it would happen again (ideally with reproduction path).

5

Hi Uwe!

Sorry for disturbing, but would you find some time to describe, what were you doing just before the Storage#58 issue has occurred? It would help us to fix it and, as you have mentioned, it is not easily reproducible.

Please make a note of such actions as leaving the Storage device in USB slot (where relevant; these are just ideas):

  • between OS reboots,
  • between sleeping/hibernating your macOS and its waking up,
  • for a longer period, e.g. for a night.

Environment: macOS 10.13, Storage 16GB v0.50, Nitrokey App v1.2

6

Hi Szczepan,

For the Storage#58 issue I can tell you that I used my Mac and the Nitrokey in an ordinary way like: Having my computer up and running and being logged in with my usual user account. Connecting the Nitrokey and immediately stopping the HID detection (keyboard) as described in the instructions for Mac. Nitrokey App v1.2 was installed already before and the Nitrokey was immediately detected and connected with the App. I can’t say exactly, when I observed the double mount for the first time, but that was not giving me a headache. I frequently mount all types of volumes, even from command line. What I can say for sure is, that I did not reboot my Mac and it didn’t go to suspend.
What I can definitely say is that ejecting the drive does not cure the remount behavior. See this example:

mbpuwe-wifi:~ uwe$ mount
/dev/disk1s1 on / (apfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk1s4 on /private/var/vm (apfs, local, noexec, journaled, noatime, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk2s1 on /Volumes/NITROAPP (msdos, local, nodev, nosuid, noowners)
/dev/disk3s1 on /Volumes/NITROKEY 1 (msdos, local, nodev, nosuid, noowners)
mbpuwe-wifi:~ uwe$ sudo diskutil eject disk3
Disk disk3 ejected
mbpuwe-wifi:~ uwe$ mount
/dev/disk1s1 on / (apfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk1s4 on /private/var/vm (apfs, local, noexec, journaled, noatime, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk2s1 on /Volumes/NITROAPP (msdos, local, nodev, nosuid, noowners)
/dev/disk3s1 on /Volumes/NITROKEY 1 (msdos, local, nodev, nosuid, noowners)
mbpuwe-wifi:~ uwe$

Topic 2:
As I describe earlier in this thread, the encrypted volume became unaccessible and was detected a flash card reader under Windows. That happened with having the encrypted volume formatted as “exFAT”. I am not familiar with the details of exFAT, but it looks like ordinary FAT16 or FAT32 volumes are more robust against the Storage#45 behavior.

BR
Uwe

1 Like
7

Today it happened again: The encrypted volume crashed again.

Circumstances as above: Nitrokey storage 16GB on the latest 0.50 firmware and run it with the NitroKey App 1.2 on the latest macOS.

What I did:

  1. Boot MacBook Pro
  2. Log into user account
  3. Connect Nitrokey
  4. Start Nitrokey Application
  5. Unlock encrypted Volume
  6. New volume is mounted with wrong name “Untitled” and empty

The encrypted Volume had a different name before and held a lot of content including Password database file for Keypass.

To check if I can rescue any of my files I connect the stick to my Windows machine and find muesli:

crap
crap.JPG771×589 61.4 KB

This is crap. Seems like this stick is a green banana.

BR
Uwe

8

Hi Uwe!

Sorry to hear that. We started investigating this yesterday. Let us know if you would have any further info (e.g. any reproduction route), so we could reproduce and fix this faster. Perhaps downgrading to firmware v0.45 would help to avoid this issue (as one of the our other forum users, @Peacekeeper, did).

9

Yes, this was the only solution. I think there have been some changes after v0.45 that destroy the encrypted volumes. When I remember right it was a change, how to mount the volumes. Anyhow, v0.45 was so far stable. (Off topic: I am currently not using the stick - Using NK Pro and now try to get NK HSM up and running)