nitrokey-storage-firmware icon indicating copy to clipboard operation
nitrokey-storage-firmware copied to clipboard

Lock the device on host reset cycle

Open oderwat opened this issue 7 years ago • 11 comments

I just saw that rebooting my system (iMac) did not look the NitroKey-Storage. I think this should be changed if possible.

oderwat avatar Jun 21 '18 13:06 oderwat

Hi! Do you mean you would like to boot from it, like from a regular USB storage device? It shows on my setup (Intel PC, UEFI-capable BIOS) during the boot. Perhaps some BIOS setting to change?

szszszsz avatar Jun 21 '18 13:06 szszszsz

No. I mean that when I unlock the secret or a hidden volume and afterwards reboot my computer it stays unlocked. I think it should lock the stick! Mostly because somebody else may reboot the system to attack it and when he succeeds he gets access to the unlocked key. But also because I may let the system reboot to boot another OS (for example after using TAILS). I think that a reboot of the host should imply a "reboot" of the stick.

oderwat avatar Jun 21 '18 17:06 oderwat

I see. I know people, who boots off from the encrypted volume (perhaps hidden as well), so it depends on the use case. In case OS reset is not detectable, would a (optional) timed-lock suffice in your case? E.g. device would lock itself 10 minutes since the last contact with the Nitrokey App.

szszszsz avatar Jun 21 '18 17:06 szszszsz

I usually don't run the nitro key app automatically and also quit it after unlocking. This is because it gives away to much information. I think nobody should be able to see that one has mounted a hidden volume in any way. I remember writing about that before. This kinda defeats having a hidden volume!

Afaik USB defines an idle signal and I think that can be used to identify the host doing a reset. But I am not very knowledgeable about the USB specs.

From my point of view It does make no (security related) sense to boot from the stick without the need to enter a password first (after reboot). How would one protect the system? Encountering such a system one could easily boot into something else (like the real host system) and get access to the data in the encrypted volume for free as this will still be unlocked.

oderwat avatar Jun 21 '18 18:06 oderwat

As far as I know nobody boots that way (that is, unlocking the Nitrokey and keep it unlocked to boot). Some people do use the Nitrokey to unlock a encrypted system on startup though (the PIN is needed, of course).

It remains the question whether the Nitrokey is able to detect a reboot. Most systems do not cut the power when rebooting, otherwise the Nitrokey would get locked anyway (right?). I don't know if there is a unambiguous system message which the Nitrokey can detect on a hardware level to lock itself...

What I am thinking of is the following: the scenario @oderwat is mentioning seems to be the following: a user locks the screen, but does not lock the Nitrokey. An attacker reboots the system in a way she can access the hardware and has an unlocked Nitrokey at hand, right?

One way to look at it would be to say: you lock your screen when leaving the PC, so lock your Nitrokey. Instead, I would like to suggest an option for Nitrokey App to automatically lock the device when locking the screen. This is the default for various password managers/key wallets etc.

What do you think?

alex-nitrokey avatar Jun 25 '18 07:06 alex-nitrokey

If I lock the device when locking the computer I lose access to the files. My computer also locks after 10 minutes inactivity, which happens quite a lot.

I think that a USB device implementor should inform us if there is a way to detect a reboot.

Afaik a USB device does need to answer on enumeration requests and the host will have to re-query all the devices after a reboot or usb bus reset. I also think that it is uncommon, that there will be no data transfers at all while the system runs and therefor it may be possible to detect a reboot because of the "silence" on the USB bus.

oderwat avatar Jun 25 '18 12:06 oderwat

I understand. So what you need is auto-locking of the device in case of the host reboot. I think this feature is justified, but I do not know about its feasibility. Further research is needed.

  • [ ] auto-lock on host reboot
  • [ ] remove HV enabled information from tray menu and About window (to be moved to a separate issue)

szszszsz avatar Jun 25 '18 17:06 szszszsz

I second that the device should be locked when the system goes to S3,S4 or S5 or reboots. It's trivially exploitable by just rebooting from said power states to an unprotected system and reading the data. If the system was in S4, that attack is not even detectable by the user. The PGP smartcard in the Yubikey Neo I own needs to be unlocked again after a reboot, although I'm not sure if that's gpg-agent caching the pin or an actual state machine change in the card.

I'd consider this a critical security issue, and it should be at least have been documented somewhere.

pschyska avatar May 04 '19 18:05 pschyska

Regarding the smart card, I think this is cache related, and no reboot detection is done.

As for the locking, running it automatically on suspend might make the Encrypted Volume's file system broken in case, when the buffers would not be flushed out (same effect, as removing without unmounting). There is also a case, when user has left modified files opened, and the PC was suspended, making the changes lost. Therefore I am not convinced this is a good idea.

szszszsz avatar May 06 '19 07:05 szszszsz

I agree that locking the key on suspend/screen lock is a bad idea. It should be done if the machine is rebooted afterwards though. As long as the machine is locked/suspendended, the operating protects the data with screen locks etc . Do you think it would be hard to detect a reboot?

pschyska avatar May 07 '19 09:05 pschyska

I suspect reboot detection is possible by reading the SCSI events, though I have not researched that in depth. It might be hard due to:

  • different events sequences due to hardware differences (and we might end up supporting only a couple of hardware configurations, giving a false security feeling to the user),
  • avoiding spurious unlocks in case OS would make similar events sequence.

In case you would see any hardware that does such detection, please let me know.

szszszsz avatar May 07 '19 09:05 szszszsz