age-plugin-yubikey VS yubikey-agent

_o/ hi all, age author here!

The OP link is the spec, here's a few other things you might find interesting

- the Go reference implementation https://age-encryption.org

- the Go library docs https://pkg.go.dev/filippo.io/age

- the CLI man page https://filippo.io/age/age.1

- an interoperable Rust implementation by @str4d https://github.com/str4d/rage

- a YubiKey plugin by @str4d https://github.com/str4d/age-plugin-yubikey

- the draft plugin protocol specification (which we should really merge) https://github.com/C2SP/C2SP/pull/5/files?short_path=07bf8cc...

- a Windows GUI by @spieglt https://github.com/spieglt/winage

- a discussion of the authentication properties of age https://words.filippo.io/dispatches/age-authentication/

- a discussion of a potential post-quantum plugin https://words.filippo.io/dispatches/post-quantum-age/

- a password-store fork that uses age instead of gpg https://github.com/FiloSottile/passage (see also: how I use it with a YubiKey https://words.filippo.io/dispatches/passage/)

I am using the yubikey plug-in for age (https://github.com/str4d/age-plugin-yubikey). It creates a private key and writes it to one of the retired PIV slot. What I want to do is to write the same private key to two different Yubikeys.

So with age I can also just use my ssh public key to encrypt and my ssh private key to decrypt my files. If I want to get fancy, I can use something like https://github.com/str4d/age-plugin-yubikey to provide the key material for my age operations (which should compose with age.el quite well also, i.e. you can have every decrypt operation have a touch requirement in Emacs that way).

> A good feature of PIV applet of Yubikey 5 is that it stores 24 keys.

Note that not all 24 of those keys are suitable for age usage. The 4 main keys have specific usage definitions in the PIV specification that mean hardware tokens alter how those key slots behave. Only one of them (the KeyManagement slot) has a definition that allows encryption, and even that I was somewhat suspicious of overlapping with, as I couldn't predict how those existing keys were being used, and didn't want to support every possible key type that might be in that slot (which users likely wouldn't be able to alter).

age-plugin-yubikey avoids this complexity by only interacting with the 20 "retired" slots, which have no constraining definitions. (I am considering adding restricted support for the KeyManagement slot specifically for CAC card users who aren't allowed to add new keys to their cards [0], but this would be behind a default-off feature flag to keep the primary UX simple.)

[0] https://github.com/str4d/age-plugin-yubikey/issues/62

We designed the plugin protocol (https://hackmd.io/@str4d/age-plugin-spec) and generally the age recipient/identity structure specifically to enable the use of hardware or remote keys!

For example, https://github.com/str4d/age-plugin-yubikey makes it very easy to use PIV tokens, including YubiKeys, with age. (Well, for now with rage, since plugin support is coming in age v1.1.0.)

I argue against password-protecting keys by default because, unlike using hardware tokens, it doesn't protect against many threat models.

Hardware? I assume if someone was concerned about key access they wouldn't want keys on their filesystem at all but move them into an HSM instead. Since age identities can come from standard input I assume it'd be feasible to put together a workflow there coming from one of the various cli utilities for interacting with keys. There is already a YubiKey specific age plugin [0] getting worked on as well. Currently in beta but looks interesting. Hopefully that will continue to expand to cover other common options. HSM support is pretty important for a modern encryption utility IMO but unfortunately the landscape is pretty all over the place too, so makes sense to just leave it to plugins or as part of a unix flow.

----

0: https://github.com/str4d/age-plugin-yubikey

age also has a notion of plugins, one of which is age-plugin-yubikey (written in Rust, there is also yubage written in Go) which allows you to create an age identity whose private key is stored via PIV.

This is a great idea. I now exclusively use SSH keys on hardware security modules of some kind. I use "Secretive", a mac app that does the same, plus a yubikey using yubikey-agent (https://github.com/FiloSottile/yubikey-agent; there are too many complicated ways to use SSH keys with a yubikey this is one of the friendliest ones). Depending on the security and frequency of which I access the service impacts whether I need presence confirmation or use secretive versus the yubikey.

I would be remiss to mention there are existing SSH TPM projects, not sure how this one differentiates. It seems to at least have the user experience pretty simple, similar to yubikey-agent (and secretive), and unlike some of the existing solutions which have quite a few extra steps:

Also check out https://github.com/FiloSottile/yubikey-agent which simplifies the setup quite a bit.

I'm using it on nixOS and macOS, via Nix Packages and Homebrew respectively. It's this - https://github.com/FiloSottile/yubikey-agent I'm realizing from this thread that it's not an official package. I'll go closer to the source with ykman. Thanks!

I think the Ledger Manager only interfaces with the GPG and SSH agents, neither of which age take advantage of. But age does have support for Yubikeys (see https://github.com/FiloSottile/yubikey-agent). If you can interface with the Ledger hardware device as a Yubikey, this might work. I don't have experience here, just a thought.

You can use PIV for SSH just fine.

It's not OpenSSH's weird FIDO mode, but I don't like the FIDO mode anyway because it requires storing a file on the computer.

https://github.com/FiloSottile/yubikey-agent

I have the same concern. I modified Pageant (Windows agent) so that it prompts me before signing anything which helps ease my mind, I only approve when I know I'm connecting to a new server. There are also options like requiring a Yubikey too (https://github.com/FiloSottile/yubikey-agent)

Aging MBP, Intel based, Monterey 12.3.1 uname -v Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 brew info yubikey-agent yubikey-agent: stable 0.1.5 (bottled), HEAD Seamless ssh-agent for YubiKeys and other PIV tokens https://filippo.io/yubikey-agent /usr/local/Cellar/yubikey-agent/0.1.5 (7 files, 4.8MB) * ...

Unless I've missed something, SSH keys stored on Yubikeys are still hampered because you aren't allowed to a touch policy of "touch never".

Imagine needing to touch the Yubikey with each "git pull" or using Ansible to operate over SSH on a dozen servers in parallel, and needing to touch the Yubikey once for each server.

The feature request I'm tracking is here: https://github.com/FiloSottile/yubikey-agent/issues/95

The proposed feature would allow setting a touch policy for the SSH key.

If you can do ssh, you can sign messages: https://github.com/FiloSottile/yubikey-agent