Nitrokey3 and Cryptomator

Nitrokey Generic
1

Hallo,

after successful integration of keepassXC with Nitrokey3, I wonder if a similar thing can be done with Cryptomator (https://cryptomator.org/)? Cryptomator is an open source file encryption service, where you can create containers end they are end to end encrypted in any cloud storage.

Similar to Keepass it would be desirable if one can add multiple hardware keys to one encrypted container containing file. Additionally, of course it would be nice to encrypt each Cryptomator container with a different derived key (maybe via FIDO2-hmac-secret?).

Just some idea for future use cases.

2

Would be a nice feature but there is not much pull.

3

Yes, that would be very interesting. I wonder how they’d implement it, though, given they also have a team-based implementation.

An open-source project that supports FIDO2 to unlock a filesystem-based encryption is gocryptfs. Since it is fuse-based, it supports reverse-mounting a local directory with a remote (cloud) encrypted counterpart.

4

Hi,
I can confirm that Nitrokey Passkeys work with gocryptfs
(on Debian Linux (following those instructions: gocryptfs/Documentation/MANPAGE.md at master · rfjakob/gocryptfs · GitHub))

I just didn’t manage to use the " fido2-assert-option" which would be needed to force the PIN.

Anybody with any clues on that option?

1 Like
5

Nice find. Do you have by any chance a log of all commands you used to initialize and mount the filesystem? This would be a good addition to the howto section of the Nitrokey documentation.

Also like that the key material is not exposed via a pipe.

6

Great tool indeed and it’s extremely easy to use:

mkdir enc dec
gocryptfs -fido2 /dev/hidraw0 -init enc dec

to init, it outputs the secret for backup during init. Afterwards you can mount with gocryptfs -fido2 /dev/hidraw0 enc decand dismount fusermount -u dec.

Another great option it has is reverse mount, i.e. you can create a mount of a regular directory to e.g. /tmp/enc (or any fuse mount) and sync this encrypted view to your cloud. It brings you an encrypted backup with least local space overhead.

7

When I looked into it a while back, they had skipped implementing it, see this issue.

8

Yes, they skipped the implementation 3 years ago :-(.
The problem is, that gocryptfs is useless as long as you can’t make sure -durig initialization- that the PIN-option (or user interaction) is mandatory.
What can we do about this? Any options/safeguards from fido2-tools/fido-2-cred to force the PIN anyway?
And any good tutorials on how to use those fido2-tools on Linux with the Nitrokey Passkeys?

9

If the project decided not to implement more than U2F because they can’t support it, there is nothing we can do to force a PIN.

Touch (user presence) is mandatory when I use it with an NK3. Does the Passkey not require touch?

10

Yes, but it ONLY requires a touch. So if the passkey gets stolen … no security…
I tried again, to force a pin via the fido2-tools, but it seems not possible. You CAN set a pin but gocryptfs just doesn’t care while authenticating.
With fido2-token -I /dev/hidraw1 it says “options: rk, up, noplat, credMgmt, clientPin, nolargeBlobs, credentialMgmtPreview”
Does that mean, the the PIN-option pin=true is not possible by firmware?
Pretty frustrating.

11

It’s getting weird.
I tried the Nitrokey Passkey PIN-problem with LUKS via systemd-cryptenroll and same problem here: Although it requests the PIN on init-procedure, you can afterwards open the LUKS-container WITHOUT Pin, see output below:

sudo systemd-cryptenroll /dev/sdc1 --fido2-device=auto --fido2-with-client-pin=yes
:closed_lock_with_key: Please enter current passphrase for disk /dev/sdc1: ****
Initializing FIDO2 credential on security token.
:point_up_2: (Hint: This might require confirmation of user presence on security token.)
:closed_lock_with_key: Please enter security token PIN: *******
Generating secret key on FIDO2 security token.
:point_up_2: In order to allow secret key generation, please confirm presence on security token.
New FIDO2 token enrolled as key slot 1.
(and then I can open it with just a password …)
(script taken from here: Token2 | Unlock Linux LUKS encrypted drives with Token2 FIDO2 Security keys | Token2 Store | programmable hardware token, FIDO2 key, U2F key, TOTP,)

12

Maybe PIN gets cached?

13

Just in case, I just tried myself and the PIN does not get cached here.

Try something like cryptsetup open --token-only /dev/loop0 test, otherwise cryptsetup may ask for a passphrase if the token is not found.

14

Thanks for this input. Summarized as I understand it - at least for gocryptfs and LUKS/cryptsetup on Debian:

  • You can’t be sure that a Nitrokey Passkey really provides strong 2FA in those two programs.

No matter if its due

  • to PIN-cashing (how and where could I safely disable it if not during creation?)
    or due
  • to FIDO2-regulations (found that in an old thread: Nitrokey FIDO2 PIN creating - #13 by szszszsz). But allowing no PIN enforcement in this situation reduces 2FA to 1FA.

Seems like we have to wait for those softwares to tighten security on their side as passkeys dont upgrade firmware?!

15

For gocryptfs we already established the project skipped implementation of 2FA features.

For cryptsetup I’m not sure your testing is suitable: See, if your /dev/sdc1 is automounted during boot (e.g. via crypttab/fstab entries), systemd may simply fallback to passphrase in case the token secret is inaccessible (without PIN). To draw your conclusion, it is important to test with a manually mounted luks device (see how my above --token-only suggestion references a /dev/loop device). Only in case such a test fails with the passkey, the conclusion is valid. If the PIN is asked for a manual mount but not an automatic, the problem lies in system setup.