FIDO Resident Keys

[schichtnudelauflauf]

Missing feature

When trying to provision a resident key the device says its unsupported.

Justification

My usecase is ssh-keygen's ed25519-sk keys. Because that works with normal ssh-agent.
I do not want to use any custom agent because that precludes usage of other keybearer devices.
I do not want to use the non resident fido keys either because that requires moving auxiliary files around.

Workarounds

None

[My1]

I think the issue is not resident keys as as far as I can see ALL FIDO2 keys on MP are resident (something which I would love not to be the case), but rather the fact that the MP uses internal UV, without fallback to clientPIN (as in, a PIN you literally enter on PC).

basically similar to biometric keys which can use fingerprints in lieu of a clientPIN, but equally fall back to that clientpin if either

1. an application cannot deal with internal UV
2. your fingerprint was not recognized a few times
   the MP only uses internal UV, basically allowing its unlocked state to count as user verification, but cannot fallback to a clientPIN.

the FIDO client within openSSH does not seem to deal with internal UV yet, at least the one I have here.

Resident Keys in general work fine for example on a Website that asks for them (I have a sandbox for that)

[My1]

Update: after running it with verbose it is clear what's going on:

my1@my1-qbp:~$ ssh-keygen -v -t ed25519-sk -O resident -f /tmp/key
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator: 
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper 
debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:", userid "(null)", flags 0x21, challenge len 0
debug1: sshsk_enroll: using random challenge
debug1: sk_probe: 1 device(s) detected
debug1: sk_probe: selecting sk by touch
debug1: ssh_sk_enroll: using device /dev/hidraw3
debug1: ssh_sk_enroll: /dev/hidraw3 does not support credprot, refusing to create unprotected resident/verify-required key
debug1: sshsk_enroll: provider "internal" failure -2
debug1: ssh-sk-helper: Enrollment failed: requested feature not supported
debug1: main: reply len 8
debug1: client_converse: helper returned error -59
Key enrollment failed: requested feature not supported

TLDR the credProtect feature is apparently something openSSH asks for which the MP does not have set as active yet (although considering the way the MP handles UV it's always active

[0x0ptr]

Yes, @My1 is correct. We do not support CredProtect at this time. As far as I remember that takes some considerable work to enable (several dependencies).

[My1]

Yeah i guess. I mean implicitly this device already has credential protection (as it's literally impossible to read anything without it being unlocked) but credprotect is iirc part of ctap2.1 for the first time and ctap2.1 brings along several requirements, some of which (iirc hmac says hello) are also issues here

Although maybe a title change of the issue would be nice.

[spoelstraethan]

I would love to see the Mooltipass BLE support resident keys fully (the more open source projects that can do so the better).

I ran across this AMAZING description of how to get these working with OpenSSH 8.3+ and it might be helpful for other scenarios as well.

betrusted-io/xous-core#209 (comment)

[My1]

as mentioned resident keys in itself fully works. credprotect is a much newer feature which came on CTAP2.1 (and also devices that went ahead and implemented the pre version), while the MP is basically running CTAP2.0 with ALL keys being resident in fact.

this is the same as if you took an older yubikey 5 which was before all the ctap2.1 stuff, it certainly has resident keys but would be too old to have credprotect.

credprotect is not a part of resident keys, it's its own thing.

maybe someone could re-label the issue for example into:

FIDO2: credProtect (required for SSH resident keys)

although this is kinda part of a bigger thing as the current CTAP2.1 spec mandates basically that having one of the major 2.1 features mandates setting the 2.1 flag, and setting the 2.1 flag on the other hand mandates having the other big things too.

https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#mandatory-features

1. hmac-secret (not yet done (see Support hmac-secret FIDO2 extension #304 )
2. clientpin OR UV if RKs are a thing (no problem this thing uses UV using card and internal pin)
3. credMgmt OR internal UI that supports managing RKs one by one (no problem, done via Moolticute)
4. credprotect UNLESS all things are implicitly Level 3 (requires UV) (kinda the exception applies here but still credprotect likely needs to be specifically marked for software interaction purposes)
5. pinUvAuthToken (which likely means an update to the communication security)
6. PinUvAuthProtocol version 2 (another communication security update) (likely both not implemented due to not being a thing in 2.0)