Add support for sk- (hardware-backed) ed25519 keys

[anoadragon453]

OpenSSH 8.2 or higher supports hardware-backed variants of ed25519 and ecdsa SSH key types, otherwise known as "secure key" (sk) variants.

I have a Yubikey and use its FIDO2 support to store a sk-ed25519 SSH key on the device. It is not (supposedly) possible to get access to the private keys of this variant, but you can access the public key of course.

I use this key to authenticate to my servers, and I'd like to use it with sops-nix as well. However, it appears that ssh-to-age does not support the -sk variant of ed25519 keys, so I get an error:

$ ssh-to-age -i ~/.ssh/id_ed25519_sk_rk.pub
ssh-to-age: failed to convert 'sk-ssh-ed25519@openssh.com AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc2guY29tAAAAIGVdcgCRUwCd83w5L+k5yhDHrLDF88GgDWdhvMqYAUiAAAAABHNzaDo= ssh:': failed to parse ssh public key: illegal base64 data at input byte 3

which I believe is due to the check for the "ssh-" prefix here:

ssh-to-age/convert.go

Lines 99 to 103 in 3d775f6

	if strings.HasPrefix(string(sshKey), "ssh-") {
	pk, _, _, _, err = ssh.ParseAuthorizedKey(sshKey)
	} else {
	_, _, pk, _, _, err = ssh.ParseKnownHosts(sshKey)
	}

If we expand it to:

	if strings.HasPrefix(string(sshKey), "ssh-") || strings.HasPrefix(string(sshKey), "sk-ssh-") {
		pk, _, _, _, err = ssh.ParseAuthorizedKey(sshKey)
	} else {
		_, _, pk, _, _, err = ssh.ParseKnownHosts(sshKey)
	}

then we predictably get:

$ ssh-to-age -i ~/.ssh/id_ed25519_sk_rk.pub  
skipped key: got sk-ssh-ed25519@openssh.com key type, but only ed25519 keys are supported

due to:

ssh-to-age/convert.go

Lines 107 to 110 in 3d775f6

	// We only care about ed25519
	if pk.Type() != ssh.KeyAlgoED25519 {
	return nil, fmt.Errorf("got %s key type, but %w", pk.Type(), UnsupportedKeyType)
	}

if we then expand that code to:

	// We only care about ed25519 (and the secure key variant)
	if pk.Type() != ssh.KeyAlgoED25519 && pk.Type() != ssh.KeyAlgoSKED25519 {
		return nil, fmt.Errorf("got %s key type, but %w", pk.Type(), UnsupportedKeyType)
	}

we then get:

$ ssh-to-age -i ~/.ssh/id_ed25519_sk_rk.pub
/nix/store/lngv3dl3yal64xripysv284781qrpxj9-ssh-to-age-1.1.1/bin/ssh-to-age: failed to convert 'sk-ssh-ed25519@openssh.com AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc2guY29tAAAAIGVdcgCRUwCd83w5L+k5yhDHrLDF88GgDWdhvMqYAUiAAAAABHNzaDo= ssh:': BUG! public key does not implement ssh.CryptoPublicKey

which makes sense. ssh.skEd25519PublicKey does not implement ssh.CryptoPublicKey, while ssh.ed25519PublicKey does.

I'm wondering if it's still possible to get the elliptic curve points out of pk and convert it to an age key regardless? Or am I barking up the wrong tree and should go pester to go devs to implement ssh.CryptoPublicKey on ssh.skEd25519PublicKey? :)

[Mic92]

The bigger issue here is that sops also needs to support the yubikey for encryption, which is currently not the case: getsops/sops#1103
So yes we could add the conversion here but we would still need support in sops's age implementation to make actually use of it.

[anoadragon453]

I see, and apologies, I've now found #25, which I missed in an initial search of the repo, asking for the same functionality.

The bigger issue here is that sops also needs to support the yubikey for encryption

I'm confused though - the public key is entirely stored in a file on my computer (~/.ssh/id_ed25519_sk_rk.pub). The yubikey should not be required to be plugged in in order to encrypt content with that public key, is that right?

Or is the issue that the public key types don't match up? Why does the user in getsops/sops#1103 have a age1yubikey type key, rather than just an age type?

Is it an additional problem that sops doesn't engage with the yubikey (or any agent?) in order to decrypt the content?

Or alternatively to all that, do you agree with the way forward laid out in #25 (comment), and we should just use a plugin based approach with sops instead? :)

[Mic92]

Sops cannot decrypt because it would have to reach out for the yubikey, which is not implemented. I am not sure what you mean by a plugin based approach.

[anoadragon453]

Right, that part makes sense to me. Thanks for responding.

I'll wait on that front first then. Feel free to leave this issue open in the meantime or close it if you like.

[Mic92]

I'll keep it open because otherwise someone else will just come again with the same issue.

[tiferrei]

Hello, thank you very much for your work on this!

I was just wondering if this would be possible now that things seem to be evolving to support TPM SSH-based age keys. I think getsops/sops#1103 has been closed by merging getsops/sops#1641 so support should be coming soon! Thanks :)

[haslersn]

AFAIK, what this issue asks for is impossible: Even if ssh-to-age would support converting the public part of a hardware-backed key, the Yubikey won't let you convert the private key and won't let you do the operation required for decryption with that key.

ssh-to-age converts an ed25519 key (usable for signing) to an x25519 key (usable for Diffie-Hellman key exchange and thus for things like encryption). Both the public and private key need to be converted. The Yubikey only allows to sign things with the ed25519 private key. It won't let you convert the private key and won't let you do the Diffie-Hellman key exchange required for decryption.

Correct me if I'm wrong.

[gauravjuvekar]

Yes haslersn is correct. sk- variants are fido based and the security key will only generate signatures from the token's private key. It will not decrypt anything (or allow the private key to leave the hardware token obviously).

You will have to use PGP / PIV based hardware tokens (some of which support generating and sealing the private key entirely on the hardware token resulting in a similar security posture) for decryption.

[Mic92]

Sops now supports age plugins. So instead of sk-ed25519 keys I would suggest using https://github.com/olastor/age-plugin-fido2-hmac

[gauravjuvekar]

Note, in fido2-hmac, the private key of the recipient leaves the hardware token.

[Mic92]

Note, in fido2-hmac, the private key of the recipient leaves the hardware token.

Which doesn't really makes a big difference because the sops private key is symmetric and stored in the document.