Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native age identity support #174

Open
str4d opened this issue Apr 2, 2024 · 3 comments
Open

Native age identity support #174

str4d opened this issue Apr 2, 2024 · 3 comments
Labels
S-blocked-on-hw Status: We need to own a specific YubiKey version to make progress on this issue.

Comments

@str4d
Copy link
Owner

str4d commented Apr 2, 2024

YubiKeys with firmware 5.7.0 and above have support for X25519 (thanks smlx/piv-agent#134 for making me aware of this).

It should be possible to generate native age identities in PIV slots, and use them just like P-256 identities on the decryption side (our identity format points to a specific YubiKey serial and slot, from which we can then determine whether or not the key is P-256 or X25519). On the encryption side, these would just be regular native age recipients (and thus not require a plugin to encrypt to).

The downside is that because native age identities do not include any sort of tag, we would need to assume that any X25519 YubiKey slot could potentially match, which means in multi-key settings the UX is not as great, but that is a trade-off we can probably explain in the setup TUI.

@pinpox
Copy link

pinpox commented Apr 11, 2024

Would this allow for using existing age (or ssh) keys on the yubikey? I"m searching for a solution that let's me use the yubikey for age encryption/decryption while having a offline (printed out) backup of my key so that I can restore it on a new yubikey in case of I lose it.

@dlubawy
Copy link

dlubawy commented Jul 19, 2024

This is definitely possible. I created a PR over at yubikey.rs to add curve 25519 support to the underlying yubikey crate. I then forked this repo on a new branch to test it all out together. It seems to work alright (though the code isn't great since I'm still new to Rust).

Some things to consider:

  • X25519 keys cannot sign certs so I had the plugin export an attestation cert and import to the key's slot on build instead
    • This additionally means that X25519 keys cannot be named using TAG_HEX
    • Any X25519 key with an attestation cert from YubiKey is considered a valid age identity for the plugin
  • Native age keys are supported through this, but it requires some effort since they cannot sign themselves. Steps are:
    • Decode the bech32 of an age identity to get the X25519 private key
    • Generate a self-signed certificate (using another key capable of signing) for the corresponding public key (Organization set to 'age-plugin-yubikey' for it to show in the --list)
    • Import the key/cert pair to slot of choice

I made a Python script to convert age identities to key/cert PEM files for upload to a YubiKey which can then be used with the branch I made.

Additionally, I tested using native keys in the original format on another branch and it's definitely doable with the same caveat listed above. It has the exact problem that was described whereby the identities and recipients won't match due to a tag not being included within native age. I had to assume all YubiKey slots could match when no tag was included in the RecipientLine. This means one has to touch the key 'N = Slot Number'. Not the best UX.

@str4d str4d added the S-blocked-on-hw Status: We need to own a specific YubiKey version to make progress on this issue. label Aug 4, 2024
@pinpox
Copy link

pinpox commented Aug 20, 2024

@str4d Would you be interested/have the time to implement this? If it's just having a new yubi that's missing for this, I would offer to sponsor one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-blocked-on-hw Status: We need to own a specific YubiKey version to make progress on this issue.
Projects
None yet
Development

No branches or pull requests

3 participants