Feature request: backlight on FIDO prompt

[DigitalBrains1]

Thank you for working on this awesome project!

I have turned on "Auto-Backlight" in "Preferences". I'd like to suggest to turn on the backlight in this case when a U2F, Webauthn or SSH key request pops up on the screen. It would make it easier to read, and you can't turn on the backlight by a keypress because that would either accept or decline the FIDO request.

[bunnie]

that request makes sense. need to think about how it should be implemented, because the auto-backlight feature is managed in the status engine, a different program altogether, but perhaps having two programs manage the backlight isn't terrible -- worst case, you just get a double-turn-off which is harmless?

[bunnie]

I've got a pull request (#489) that should implement the requested feature.

Unfortunately, I'm not able to test it with U2F for lack of a suitable test site (the test sites I normally use have bit-rotted and throw various combinations of XSS-ish errors or rely on out of dated demo protocols that are now deprecated).

I was able to confirm the backlight does turn on with a webauthn/FIDO2 request, however.

The main concern about this patch is that it sends a ping to the status server to turn on the back light on every USB packet, which can be a lot of traffic in the case that the host is polling for a touch. I think it should be OK, but would like to get validation on a U2F site (which is very poll-intensive) that this works before I merge.

@DigitalBrains1 I presume you're not actually set up to compile/absorb dev builds from this project correct? No worries if you're not, and I don't think it's worth it for you to install all the tooling just to test this, but just in case you are it'd be nice to see if this solves your problem before I merge it.

Either way, once it's merged, this will drop into a fairly comprehensive CTAP2 test suite so presumably any major compatibility issues would sort out there.

[DigitalBrains1]

I have not done the dev build dance yet, but I do have Vivado 2022.1 installed and I'd be happy to upgrade to the latest Vivado since that is probably something I would do at some point anyway. So that's part of the tooling already available (and a pretty annoying one at that).

I have a discoverable WebAuthn credential on GitHub, but if I choose "FIDO2 WebAuthn" as a second factor with Bitwarden, it will use a non-discoverable credential; that is, it is not listed in the Betrusted Key Vault app so I'm guessing that is the reason. I'm not sure if I have any accounts that use actual U2F.

[bunnie]

I think the backlight should turn on in all those cases -- in fact, if anything, the backlight will turn on more often than just that. It's hooked to turn on anytime something comes over the U2F listener interface, which includes all FIDO traffic (I think).

I'll go ahead and merge this and let it drop into the CI pipe; it'll make it easier for you to test it by just updating to the "bleeding-edge" release. Before trying it just check and make sure this dashboard is all green checks: https://ci.betrusted.io/view/Enabled/ (an orange check on the TRNG test is "normal", that occasionally fails due to a problem in the test host USB stack not liking the way we virtually power down the target over and over again, that is resolved by physically unplugging the cable and plugging it back in again).

If the patch works for you, please go ahead and close out the issue.

[DigitalBrains1]

It works, thanks!

I tried to test U2F. I installed libu2f-server and libu2f-host, simply by installing the Debian bookworm/stable packages. The documentation for libfido2 mentions that you can use the CLI switch -u to use the old U2F protocol, but I couldn't quickly determine how to actually use those CLI tools :-), and I could for libu2f-{server,host}.

The backlight seems to work correctly also when starting U2F registration. But I can't get further than that.

It works correctly with my Nitrokey 3, but with both the stable Precursor release as well as the bleeding edge one, I cannot actually register. I invoke:

$ u2f-host -aregister -o https://digitalbrains.com
{ "challenge": "q5q6jb6c5mMk8FtBk2UgAj0MqNwaj9tL-BAL1bxDvs4", "version": "U2F_V2", "appId": "https:\/\/digitalbrains.com" }

(that's on stdin with newline-EOF at the end, challenge obtained from u2f-server)

and the Precursor prompts me with

but when I accept u2f-host exits with:

error (-2): error in transport layer

so I can't actually go on and test U2F authentication. The Precursor however is happy to save the U2F credential (named test:)

but since the U2F server didn't get the registration response it cannot present a challenge.

Once again, this doesn't work with both Precursor stable and Precursor bleeding edge, but it does work with my Nitrokey 3. I can do the full challenge thing with that. And on the Precursor, the backlight seems to do the correct thing, which is what this GitHub issue is about.

Shall I open an issue for this?

[bunnie]

Hmm...yes, please open an issue for this, along with the routines needed to generate the U2F test stuff. I guess since I can't get websites to work I'd have to roll my own U2F test bench.

I think it'd be good to have an issue open for this so I can remember how to reproduce later on, but if nobody has noticed this problem yet it might be for a workflow that is deprecated and nobody uses anymore, so I would de-prioritize resolving it until it actually does have a user impact.

[DigitalBrains1]

The backlight works fine!