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: ```sh $ 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]: https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorRelaySecurity/Offli... [2]: https://gitlab.torproject.org/cve/torvault
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
On Monday, 24 February 2025 15:32 Clara Engler via tor-relays wrote:
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 https://gist.github.com/boldsuck/905c2c01e596e5673340216089366b76
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 Tue, Feb 25, 2025 at 01:50:26AM +0100, nusenu via tor-relays wrote:
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
tor-relays@lists.torproject.org
-
boldsuck -
Clara Engler -
nusenu