ed25519-sk support?

[Spunkie]

Not sure if this are already been ruled out because it might need a dep on libfido2 but if not... fido2 resident keys are pretty neato

Generate a key that lives on the actual fido2 device with:

ssh-keygen -t ed25519-sk -O resident

And then when working on a new computer you can load the keys into the current session with just:

ssh-add -K

[lonjil]

I don't think the server needs libfido2 or anything like that.

[jo-bitsch]

The server would certainly not need libfido2.

The public key is the just the ssh-ed25519 key, plus an application string (typically ssh:), see https://github.com/openssh/openssh-portable/blob/88351eca17dcc55189991ba60e50819b6d4193c1/PROTOCOL.u2f

The format of a [email protected] public key is:

string		"[email protected]"
string		public key
string		application (user-specified, but typically "ssh:")

For Ed25519 keys the signature is encoded as:

string		"[email protected]"
string		signature
byte		flags
uint32		counter

The signature is over the following blob:

In addition to the message to be signed, the U2F signature operation requires the key handle and a few additional parameters. The signature is signed over a blob that consists of:

byte[32]	SHA256(application)
byte		flags (including "user present", extensions present)
uint32		counter
byte[]		extensions
byte[32]	SHA256(message)

No extensions are yet defined for SSH use. If any are defined in the future, it will be possible to infer their presence from the contents of the "flags" value.

Overall, I think the implementation would be quite small, not requiring any additional cryptographic primitives or additional dependencies. If there is enough interest in this, I would volunteer.

Keep in mind though that most fido2 tokens don't properly support Ed25519, the newer ones (firmware>=5.2.3 released in 2019) from a certain well-known vendor with a y and a few others do though. The Fido Alliance publishes meta data about all certified tokens in a JWT available from https://fidoalliance.org/metadata/. Inside this meta data blob, the supported algorithms are included, search for "alg": -8.

[jo-bitsch]

I experimented a bit with this and came up with an initial patch: https://github.com/jo-bitsch/tinyssh/tree/sk-ed25519

The main change is a new file sshcrypto_key_sk_ed25519.c, which adds the relevant functions for parsing and putting public keys and signatures, as well as the sk_ed25519_open function, that performs the signature check using the existing crypto_sign_ed25519_open for the cryptographic operation.

I had to update a few places, where the code did not distinguish between server side and client side crypto algorithms, as the server cannot create a keypair or perform a signing operation, as it doesn't have a fido key available.

Limitations:

• No end to end test yet, as I don't have a security key with ed25519 available yet. (I did create a test vector with a colleague though.) It might be that the crypto_sign_ed25519_open doesn't put the correct result into m and mlen yet, as I wasn't able to test this yet.
• [email protected] supports an application identifier, which in practice is mostly "ssh:". This commit only allows this application identifier and will not accept public keys with a different one. This is because, I didn't have a good idea yet as to where to store it.
• The code doesn't allow extensions in the signature yet. (Which are not defined yet, so it doesn't really matter).

[jo-bitsch]

I currently don't have a yubikey with the right firmware available, so I'd be very thankful if someone could help in testing. I have a colleague who has one, but he's on vacation, so it's gonna take a few days till I can get around to it.

I'm relatively confident though, that for an initial version there are only very minor things missing. Once I was able to do that, I'll raise a PR.

[jo-bitsch]

I was able to test everything and it seems to work. I therefore raised a PR (#87). Testing or code review by other people is highly appreciated.

[Vusiaa]

I think the server don't needs libfido2 or anything like that.

[jo-bitsch]

I agree, the server does not need libfido2.

The patch I prepared also does not add libfido2 as a dependency. It allows clients that have their ed25519 private keys saved on a (fido2) security key to log in.

So it's the same cryptographic primitives, that are already present with no additional dependencies. The main difference between [email protected] and ssh-ed25519 is that the signature covers a few additional fields as security keys don't produce raw ed25519 signatures.

In the end, it's a strategic decision if tinyssh wants to support keys saved in (fido2) security keys or not. From a cryptographic view, I don't see downsides. From a security point of view, having private keys on the client side in a non-extractable storage seems to be a clear positive to me. As for keeping complexity low, there is an argument to be made. But then again, the implementation (see the raised PR) is quite small and aligns with the stated goals of tinyssh in my opinion.