Support for ecdsa-sk keys?

[Andrew Garrett]

Hi folks --

OpenSSH v8.2 adds support for SSH keys stored on U2F/FIDO compatible security keys (ecdsa-sk).

I understand that nassh doesn't even support generating its own keypair (which might be a prerequisite), but I wonder if there's been any thought on what it would take to support ecdsa-sk keys.

This would be helpful for SSH'ing more securely from devices that I don't trust as unconditionally as my personal laptop.

[Mike Frysinger]

we're aware of the new functionality but we haven't implemented it as of yet, nor is there an immediate schedule for it.  we did some light initial investigation, so we think it should be feasible with current platform APIs, but it's not straightforward.

-mike

--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hter...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/6f353f58-273d-40ef-965e-ee3ca0cf4ba7n%40chromium.org.

[Will Young]

I don't see any mention in release notes, so I don't think there's any change?

I doubt on-chromeos keypair generation was determined to be a prerequisite in the initial investigation, but if so there is now the option to implement resident key support first.

[dragon788]

Looking forward to this being supported at some point because I don't think WebAuthn/FIDO2 functionality of USB keys (Yubikey/Nitrokey/Titan/etc) will EVER be forwarded into the Crostini VM (since it breaks the controlled access via browser required to ensure something hasn't tampered with the key), and being able to use a simple/cheap Security Key for connecting into the Crostini VM and forwarding the agent to allow seamless git operations would be excellent.

I utilize my Yubikey 5 series a lot, but a simple key without requiring the fairly heavy setup of GPG or PIV keys and managing their expiration/lifecycle, and if being properly paranoid is difficult to do on a Chromebook. It might be possible in Crostini now that the Yubikeys appear to be mapping correctly again, but on Chromebooks without Crostini it requires Developer Mode to install Crouton and fetch all the required software.

[Peter Huang]

when you say the yubikey 5 is mapping correctly crostini correctly, what do you mean by that?   I have a chromebook on stable channel (99) and I see yubikey as USB device can be mapped,  however, I cannot see it in linux dev environment  (opensc-tool report no reader) and I cannot to sk-ecdsa key gen, I do see OTP code coming thru.   I also doid not see way in android app space (yubiky authenticator where I know it can work with regular android phone).  so what do I miss here?

[Greg Steuck]

Is the state of ecdsa-sk support still as it was 3 years ago? Looks like between this issue and https://bugs.chromium.org/p/chromium/issues/detail?id=1030778 we don't have a publicly available option to use ChromeOS for authenticating securely to remote SSH servers with U2F tokens. It's kinda sad.

Thanks

Greg

[dragon788]

It appears there is actually an option to generate the keys as resident keys (aka Discoverable Credentials in the latest WebAuthN specs) at least on Yubikey 5 series, which might solve the issue by importing with `ssh-add -K` or `ssh-keygen -K` vs needing to generate new keys per ChromeOS device and logged in user account.

https://www.guyrutenberg.com/2022/04/02/creating-fido2-ssh-keys-using-ssh-keygen/#:~:text=Moving%20keys%20to%20a%20new%20computer

https://www.reddit.com/r/yubikey/comments/x1sz99/comment/imgf3e5/

https://www.yubico.com/blog/github-now-supports-ssh-security-keys/#:~:text=FIDO2%20resident%20key.-,Using%20resident%20keys,-If%20your%20security

[dragon788]

@vapier, how tough would it be to add in the `ssh-add -K` as an option to the Import, maybe as a second button called Import WebAuthN/FIDO2 resident keys?

This should prompt for a PIN (similar to how the GPG keys do) because according to the spec as I understand it, CTAP2.x devices aren't supposed to allow access to or enumerating resident keys WITHOUT a PIN being set to protect them.

Here's some discussion about how using the Google OpenSK library the Precursor FPGA secret manager was able to get CTAP2.1 working with their device, and a pretty much bog standard OpenSSH 8.3+ installation on Ubuntu/Debian (on Alpine / postmarketOS I had to add the separate openssh-sk-helper binary separately).

https://github.com/betrusted-io/xous-core/issues/209#issuecomment-1203338599

[dragon788]

I realized recently that the hold up is likely that OpenSSH included with ChromeOS is still at 8.1 which was before the security keys and their helpers were included. Hopefully it'll get upgraded soon to enable security keys or passkeys to be used.

[Mike Frysinger]

the crux of the issue is still the same: cross-compiling the required libraries (libfido2) for the web target (WASM), and then connecting to the web platform APIs as makes sense (WebUSB / WebAuthn).  since Google has no need for this functionality internally, no one has requested it, and i def don't have the cycles to investigate it.  i haven't worked with this particular stack before, so it isn't just a "turn this thing on" kind of situation.  so for now, this feature request is falling into the "patches welcome" bucket.

-mike

[Mike Frysinger]

err, we've been at 8.8p1 for 2 years now.  granted, that's still behind current versions (9.4), but certainly newer than 8.1 from 2019.

we'll prob be riding the 8.8p1 train for the next 6 months as we shake out WASM perf & stability.  once that's finally done, and we can drop NaCl, we'd prob look at updating our syscall layers that newer openssh needs (select -> poll).

-mike

[Maciej Żenczykowski]

It's no secret we're using secure shell with physical keys...
and I know I have it working against some bog standard fedora VMs...
(touching the chromebook's power button is required to ssh in)

# uname -r
6.4.12-200.fc38.x86_64
# ssh-add -l
256 SHA256:X...w publickey (ECDSA)
256 SHA256:o...k corp/normal (ECDSA-CERT)

This is probably just using the ECDSA key stored in the dragonfly's power button
(possibly relies on crosh u2f_flags g2f ?), but I know I also had cert
based auth working
on a physical fedora machine at some point in the past (it's offline
atm, so can't check,
it was trivial to setup - just a few (possibly 1) lines to configure)
- though that was I think with some physical non-power button key
(probably doesn't matter).

The only hack appears to be '--config=google --no-proxy-host', and
possibly the gnubbyd chrome extension
(listed in some secure shell docs)

How does that differ from what is being asked here?

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CAAbOSckWDYL5r2h0zg3xCeLYizSCjYJ9B3QFvtM__8A8QyfNdA%40mail.gmail.com.Maciej Żenczykowski, Kernel Networking Developer @ Google

[Mike Frysinger]

the gnubby/GSKE Chrome extension exposes an ssh-agent and handles all of the messy USB/HID/button pushing logic.  Secure Shell just sees an ssh-agent stream, and it forwards that to the remote.

-mike