Looking for an alternative to my #LibremKey usb-a I've been watching the development of #Nitrokey 3 usb-c a while.

Finally I got one.

a lot cooler than expected

Playing around with the new #nitrokey 3 I found that it offers a great new feature: you have to touch the key when trying to get an otp or trying to use the gpg keys stored on it.

Even if your computer might get compromised and the key is connected to it you'll not only be aware of activity (blinking led like on my former nitrokey pro), but you'll also have to touch the casing over the blue blinking led when the feature is enabled.

Using firmware v1.5.0 and an actual #PureBoot it also works as a replacement for the #LibremKey to check my bios for tampering and blinking the led green if everything is o.k.

new command line tool nitropy

On my notebook I run #PureOS Crimson which is based on Debian #Bookworm. I ran into two issues trying to use the new Nitrokey 3.

To use the key there's a new command line tool called nitropy. Generally I like the idea of using a command line tool. The new gui Nitrokey App 2 which is based on the command line tool still doesn't support all of its options.

The installation of #nitropy Gon Debian Bookworm worked flawless, but the tool showed an error when called to list all available nitrokeys.

nitropy patch for bookworms openssl version

As described in this issue one of the libs used in the new tool doesn't accept the version of openssl in bookworm. The solution is quite simple:

After installing via pipx like described in the nitropy manual edit .local/pipx/venvs/pynitrokey/lib/python3.11/site-packages/oscrypto/_openssl/_libcrypto_cffi.py and find the line…

version_match = re.search('\\b(\\d\\.\\d\\.\\d[a-z]*)\\b', version_string)

…and change it to the following:

version_match = re.search('\\b(\\d+\\.\\d+\\.\\d+[a-z]*)\\b', version_string)

Now your nitropy should work even if your OpenSSL versoin is 3.0.11.

otp: one time passwords

A lot of services offer the use of one time passwords to protect the login. People use their always online phones based on operating systems for which security issue after security issue becomes public, they use an authenticator app running on the same computer from which they login or they use cool gagets.

The former two methods are better than nothing for sure. But having my 2nd factor generated from a device that is most of the time online and which is controlled by the big surveillance capitalism players does not correlate with my philosophy.

Also having a second factor stored on the same computer I use to login is obviously not really protecting the services I use: if somehow my computer is compromised the username/password can be read from its keyboard or memory and the 2nd factor could be generated as well in the otp app I use.

I use my smartphone - a #Librem5 - often docked to keyboard and monitor to do the same stuff as on my notebook. In fact it is the backup or ultra portable counterpart for my notebook. Not good as a 2nd factor neither.

Some cool gadgets to use:

Sensor Watch can be found on crowdsupply and offers totp as a watch face

• Precursor a secure and open platform
• Nitrokeys - open source and open hardware

Since I received a #LibremKey (#NitrokeyPro) with my notebook I ended up using it.

nitrokeys otp

I already had most otp slots filled on my #LibremKey. The only thing I always wondered has been if this would really be secure if my computer would get compromised. If I'd not notice activity on the token (blinking led) someone could have grabbed my pin to unlock the otp when I entered it and generate an otp on my computer to login from elsewhere with my also stolen credentials.

Not that I think I'm that kind of target, but working in the field of security I'm used to ponder these possibilities.

When I tried to configure otp on my new nitrokey3 for one of my accounts I stumbled over this output:

$ nitropy nk3 secrets add-otp --help
Command line tool to interact with Nitrokey devices 0.4.41
Usage: nitropy nk3 secrets add-otp [OPTIONS] NAME SECRET

  Register OTP credential.

  Write credential under the NAME. Secret should be base32 encoded.

Options:
  --digits-str [6|8]              Digits count
  --kind [HOTP|TOTP|HOTP_REVERSE|HMAC]
                                  OTP mechanism to use. Case insensitive.
  --hash [SHA1|SHA256]            Hash algorithm to use
  --counter-start INTEGER         Starting value for the counter (HOTP only)
  --touch-button                  This credential requires button press before
                                  use
  --protect-with-pin              This credential should be additionally
                                  encrypted with a PIN, which will be required
                                  before each use
  --help                          Show this message and exit.

I had never read somewhere before that this new option --touch-button would be available. When trying to get an otp by nitropy nk3 secrets get-otp test I have to enter my PIN and the nitrokeys led starts blinking blue. I needed to touch the casing near the blue blinking led to get an otp otherwise Authentication failed with error: "SecretsAppException(code=6982/SecurityStatusNotSatisfied)" Please make sure the provided PIN is correct. Aborted!.

Great improvement!

pgp keys

After having tested the otp generation I wondered whether there might be a similar feature to protect the use of the stored gpg keys.

In Nitrokeys manual I found a chapter about User Interaction Flags. Nice.

The OpenPGPcard part of the nitrokey 3 can be configured to make touching the device to allow the use of the stored pgp keys mandatory.

The difficult part has been: "With GnuPG 2.3 or more recent" on Bookwork or Bullseye. Both offer a gpg version lower than 2.3.

A quick look at Alpine Linux revealed that it'd bring an actual gpg version to let me at least configure UIF. Using distrobox it's fast and easy to fire up a different distribution using your home directory.

I killed scdaemon and gpg-agent running on my Debian to make room for the versions coming with Alpine.

This is what I had to do to make it work after installing distrobox from the repository of my distribution:

distrobox create --image alpine:latest --name alpine
distrobox enter alpine
gpg --version

Actually I had to enter alpine twice if I remember correctly. The prompts changes to read user@alpine when it worked. O.k. here we got a new version of gpg. Let's make it work with the nitrokey:

cat .gnupg/scdaemon.conf shows on my installation that scdaemon would try to use /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0 as pcsc-driver. This path doesn't exist in Alpine.

O.k., let's install scdaemon and the driver in Alpine. A symlink in the place my Debian gnupg configuration file is pointing to makes the driver available to the scdaemon I need to start in the alpine distrobox.

sudo apk add gnupg-scdaemon
sudo apk add pcsc-lite-libs
sudo mkdir -p /usr/lib/x86_64-linux-gnu/
sudo ln -s /usr/lib/libpcsclite.so /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0
ls -l /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0

Starting scdaemon using /usr/libexec/scdaemon --multi-server worked just fine and I put it in the background. A gpg --card-status showed that the nitrokey is already recognized by the alpines newer gpg version. If there's no pin set on the nitrokey it could already work, but I had to enter my admin pin and that needs a pinentry program.

sudo apk add pinentry
cat .gnupg/gpg-agent.conf

Same problem as with the driver - the path is different in my debians home configuration. Symlinking...

sudo ln -s /usr/bin/pinentry /usr/bin/pinentry-gnome3
pkill gpg-agent
gpg-agent --homedir /home/cvogel/.gnupg --daemon

After stopping and starting gpg-agent (I do not really know whether this has been necessary, I just assumed that it might not look for the pinentry program again) I could finally configure nitrokeys OpenPGPcard using gpg --card-edit.

Following nitrokeys manual I linked above I enabled UIF for all uses of the OpenPGPcard part of it.

After killing alpines scdaemon and gpg-agent I left the alpine distrobox to test whether my older debain bookworm gpg version < 2.3 would work with the enabled UIF: echo "test" | gpg --clearsign .

Blinking blue led and after a touch of the nitrokey: yep, here we go.

And the Librem5 or any other ARM device?

At time of writing the documentation states "Arm Not Supported Currently, recent nitropy versions cannot be installed on Arm platforms due to a dependency issue…".

After reading in the mentioned github issue that the problem should be resloved I just installed nitropy on my Librem5 and it worked. Slow. Very slow. But it worked.

Would be nice to get nitropy work faster on the Librem5, but it works and is usable.

Great update

Now my PGP keys and my OTP generator cannot be used without direct interaction with the device if the firmware cannot be broken into. This is close to having a #SensorWatch which isn't connected to the computer or any network at all.

Anyway - sometimes I'll get around to try a Sensor Watch for the fun of it...·