[tor-relays] TorVault: Storing Relay Ed25519 Identity Keys on a Yubikey

Clara_Engler · February 24, 2025, 2:32pm

Hi tor-relays@,
I am Clara and work for The Tor Project, Inc. as part of the network team.

As some of you may know, Tor supports a feature called "OfflineMasterKey"[1],
which allows you to store the long-term Ed25519 identity key of a relay
on a cold device, from which you will generate from time to time a
medium-term signing key alongside a certificate signed by the identity
key.

While moving my server and re-installing my relay, I thought about using
this feature, the recommended approach of using an offline computer
seemed rather burdensome to me though.

This made me think about how we could solve that issue by storing the
Ed25519 identity key on a Yubikey and let it sign the relevant
certificates.

After a week, I came up with a tool called: TorVault[2]. It allows you
to use the PIV module on your Yubikey for storing the identity key and
signing medium-term certificates. The application itself handles the
generation and signing of the medium-term key.

The usage of the program is interactive and as follows:

$ go build -o torvault cmd/torvault/*.go
$ ./torvault
1. Yubico YubiKey OTP+FIDO+CCID
choose a smart card: 1
choose a slot [9c]:
choose an expiration date [2025-05-24]:
choose a path for the identity public key [ed25519_master_id_public_key]:
choose a path for the signing secret key [ed25519_signing_secret_key]:
choose a path for the signing cert [ed25519_signing_cert]:

================================
smart card:			Yubico YubiKey OTP+FIDO+CCID 31892185
slot:				0x9c
public key:			EVLS6NL8wastoApvJUPDzYxJ7FAdOx22RFpqtlzFGpA
expiration date:		Sat, 24 May 2025 00:00:00 UTC (1748044800)
identity public key path:	ed25519_master_id_public_key
signing secret key path:	ed25519_signing_secret_key
signing cert path:		ed25519_signing_cert
================================

is this correct? (y/n): y
enter PIN:
success! 🧅
$ systemctl stop tor
$ cp ed25519_* /path/to/your/relay/keys
$ systemctl start tor

In theory, one Yubikey can store up to 17 relay identity keys, before
reaching its limit. Unfortunately, Ed25519 support is rather new in
Yubikeys, so you will probably need a newer one (I developed it with
firmware 5.7).

Another thing you have to keep in mind is, that it is *not possible* to
move an existing Ed25519 identity key to a Yubikey. This is a
historical limitation of the way on how ctor stores Ed25519 keys. This
means, you can only secure new relays with this feature, but not
existing ones.

Please also keep in mind that this feature requires you to keep an eye
on the expiry date, as an expired certificate will render the relay to
be unusable, which will in the long run result in its loss of the guard
and other flags.

I am also already using this in production for my own relay.

Feedback is gladly welcome.

Thank You
Clara

[1]: OfflineKeys · Wiki · Legacy / Trac · GitLab
[2]: Clara Engler / TorVault · GitLab

···

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

nusenu · February 25, 2025, 12:50am

Hi Clara,

thanks for creating this.

Will this become an official torproject product which will be maintained long term?

I'm asking because I would consider integrating it with ansible-relayor [1]

In theory, one Yubikey can store up to 17 relay identity keys

For large operators, this is a show stopper.
Will this limit likely be (significantly) increased in future yubikey releases?

kind regards,
nusenu

[1] GitHub - nusenu/ansible-relayor: An Ansible Role for Tor Relay Operators

···

--
https://nusenu.github.io

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

lists · February 25, 2025, 10:56am

This made me think about how we could solve that issue by storing the
Ed25519 identity key on a Yubikey and let it sign the relevant
certificates.

Nice feature, has been requested by some in recent years.

In theory, one Yubikey can store up to 17 relay identity keys, before

Nitrokey 3 (27 ECC keys)
Nitrokey HSM 2 (55 ECC keys)
Onlykey Pro is in development. It is intended to offer plenty of storage space
for password managers and will probably be able to store many ECC keys.
(Will hopefully be released on Kickstarter in a few months)

reaching its limit. Unfortunately, Ed25519 support is rather new in
Yubikeys, so you will probably need a newer one (I developed it with
firmware 5.7).

e.g:
ed25519-sk key-pair is only supported by new YubiKeys with firmware 5.2.3

gist.github.com

https://gist.github.com/boldsuck/905c2c01e596e5673340216089366b76

guide.md

### General Note
Make sure to check out NitroKeys, OnlyKeys or SoloKeys. They are based on open-source hardware and firmware while YubiKey's are closed source.
ssh-keygen is able to generate FIDO authenticator-backed keys which can be either an ecdsa-sk or an ed25519-sk key-pair. The sk extension stands for security key. Note that an ed25519-sk key-pair is only supported by new YubiKeys with firmware 5.2.3 or higher which supports FIDO2. This means YubiKeys with firmware below 5.2.3 are only compatible with ecdsa-sk key-pairs. If possible, generate an ed25519-sk SSH key-pair for [this reason](https://cryptsus.com/blog/how-to-secure-your-ssh-server-with-public-key-elliptic-curve-ed25519-crypto.html).

We can check the firmware version of a YubiKey with the following command.
```bash
$ lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{print $2}'

4.37
```

This file has been truncated. show original

This is exactly why I don't buy Yubikeys anymore. You don't know what firmware
you're getting before you buy it. Firmware can't be updated. Every time I buy
one, months later I find that a new feature is missing.

Nitro-, Solo-, Onlykeys are open source & fw upgrade able. Backup and upload
to new key(s) is possible.

···

On Monday, 24 February 2025 15:32 Clara Engler via tor-relays wrote:

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

Clara_Engler · February 26, 2025, 8:49am

Will this become an official torproject product which will be maintained long term?

I have talked with the team about this yesterday.

It will be an official Tor product, but the software is still considered
experimental at the moment. This is why the README now contains a new
section regarding the key generation. The recommended approach is now
to generate the key on a live system, backup it to an external storage
device and import it to the Yubikey in the end. This ensures that if
the software stops working for whatever reason, you still have access to
the private key material and use it as ordinary.

The long-term plan is to eventually integrate this into arti, but this
requires further work on both ends: arti and the Rust-Yubikey ecosystem.

For large operators, this is a show stopper.
Will this limit likely be (significantly) increased in future yubikey releases?

Unfortunately I do not have information on this.

It might be worth looking into key derivation here in order to
deterministically derive an unlimited number of private keys from a
Yubikey. This is however something where I feel my knowledge is quite
limited and it would probably destroy a few security guarantees of a
hardware module.

Thank You
Clara

···

On Tue, Feb 25, 2025 at 01:50:26AM +0100, nusenu via tor-relays wrote:
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org