Issues on Chrome / New Edge Dev

[onlykey]

Has anyone else noticed that this no longer works in Chrome. Recently it looks like Chrome changed how they do FIDO2, maybe to add resident key support? The browser now sends out a getinfo request first, then it does the CTAP_GET_ASSERTION. Anyway it looks like the update site doesn't work anymore.

[sersorrel]

I'm using Chrome Dev 78.0.3895.5, and it's not working for me either – it just hangs here when I press "Update Solo Secure":

[nickray]

Will check. Is it working for you two on other browsers?

[sersorrel]

Works fine on Firefox 68.0.2.

[nickray]

I can confirm the issue (Debian Buster, Chrome 78.0.3895.5). We get stuck on "BOOT CHECK". @conorpp any ideas?

[szszszsz]

I thought this might be connected with https://github.com/solokeys/solo-webupdate/commit/a9899b4c05f67f61a7e9d115b2d2d1bde4a6e4e9, but the original report is older. Anyway, FYI, I have just made my hacker/development sample not enumerating anymore with [1]. The update went much faster, than in Firefox 68.0.2, which made me believe Chromium was not waiting for the confirmation, and some write requests were skipped. As far as I see the checksums are not checked for the hacker release upon write finishing, hence it is possible to run incomplete firmware with it, or run into weird issues.

It has worked well with Firefox 68.0.2 on the current web-update master.

I can imagine this was the case here https://github.com/solokeys/solo-webupdate/issues/3 - I had the same 'Something went wrong' message.

[1] Chromium Version 75.0.3770.100 (Developer Build) Fedora Project (64-bit)

[My1]

@szszszsz "As far as I see the checksums are not checked for the hacker release upon write finishing"

really, ouch. I think the hacker should also at least check the checksum of a firmware written to it to make sure there have been no errors (note to some technically illiterate people, who might be reading along: a checksum is NOT the same as a signature. A signature is a checksum with the verification that it was made by some specific entity (like solo in the case of solo secure), but sending a checksum can generally help against errors in transit)

regarding the skipped confirmation on some parts I was totally WTF'ed myself too but maybe it is because solo is using Webauthn for custom commands there already and the solo says on those specific (probably harmless) commands that presence isnt needed, similar to when you run an update, where it literally spams those requests and it would kinda suck if you would have to push a button for each one.

[szszszsz]

regarding the skipped confirmation on some parts I was totally WTF'ed myself too but maybe it is because solo is using Webauthn for custom commands there already and the solo says on those specific (probably harmless) commands that presence isnt needed, similar to when you run an update, where it literally spams those requests and it would kinda suck if you would have to push a button for each one.

Original issues were reported earlier, so user presence skip is probably not the cause. Would be nice to test it out though.

As for the general Hacker edition and its audience, this is not a big deal I guess, since users are expected to know how to handle the hardware, and connect the debugger when required. I just wanted to signalize such can happen. The only thing the issue may arise is for the 'upgraded' Hacker editions to regular Solos, where the bootloader will not confirm the validity of the firmware, and the debugger access will be locked by the previous updates. This would make this specific device unusable on the invalid firmware write.

Edit: I should have probably create a new ticket, since in my case the writing was in progress, whereas in this ticket original description it has not started at all. Please move it, when time permits.

[szszszsz]

Any news on this? I do not see any warnings on https://update.solokeys.com, when using Chromium - is it working now?

From my experiments the communication works on Chromium [1], if the chunk size is limited to 40 bytes. Perhaps this would work for now. Otherwise I get DomException. Firefox [2] seems to work as-is.

[1] Chromium Version 77.0.3865.90 (Developer Build) Fedora Project (64-bit) [2] Firefox 69.0.1 (64-bit)

[onlykey]

Just saw thought I'd post an update and some info that might help. Still not working here on Mac, full disclosure I haven't even tried troubleshooting it but it looks like "BOOT CHECK" issue:

So for info that might help, for OnlyKey we just released FIDO2 support and WebCrypt 2.0. We are using ported solo firmware for FIDO2 support (BTW Thanks! Good Work) In order for WebCrypt to work this required modifying firmware a bit, the custom extension is here. WebCrypt 2.0 uses a similar approach as https://github.com/solokeys/solo-webupdate and has been tested to support Firefox, Chrome, Brave, Edge (new), this wasn't easy to do because there are some issues to design around:

• Windows 10 FIDO2 appears to have a bug where all FIDO messages are sent twice. This means the FIDO messages if used to transfer data have to have some kind of sequence number so you know to ignore duplicates.
• Firefox for Windows seems to use slightly different FIDO2 implementation than Firefox for other OSes, probably had to in order to use the Windows FIDO2 API, Windows blocks apps that are not running as admin from USB access to device unless they use the Windows FIDO API.
• I believe the keyhandle value used with navigator.credentials.get has to be less than 255 bytes or Firefox has issues.

Hope this helps a little bit.

[conorpp]

Since the key handle tunneling approach is hard to maintain, and Chrome is actually going to prevent it later this year, I think it’s best to ditch support for it in favor of a native app which will be easier to maintain and be better UX. WebUSB could be an option, but it can’t use the FIDO HID interface.

I started a “solo-desktop” electron app. I figure it can handle testing, verification, and updates. Probably also PIN & credential management. Would be great to design the app to be able to various keys. What do you all think?

On Fri, Oct 18, 2019 at 6:35 PM onlykey notifications@github.com wrote:

Just saw thought I'd post an update and some info that might help. Still not working here on Mac, full disclosure I haven't even tried troubleshooting it but it looks like "BOOT CHECK" issue: [image: image] https://user-images.githubusercontent.com/18121756/67110136-04da7d80-f1a0-11e9-9a62-a34b68b9f5d0.png

So for info that might help, for OnlyKey we just released FIDO2 support and WebCrypt 2.0. We are using ported solo firmware for FIDO2 support (BTW Thanks! Good Work) In order for WebCrypt https://docs.crp.to/webcrypt.html to work this required modifying firmware a bit, the custom extension is here https://github.com/trustcrypto/libraries/blob/master/fido2/ok_extension.cpp. WebCrypt 2.0 uses a similar approach as https://github.com/solokeys/solo-webupdate and has been tested to support Firefox, Chrome, Brave, Edge (new), this wasn't easy to do because there are some issues to design around:

• Windows 10 FIDO2 appears to have a bug where all FIDO messages are sent twice. This means the FIDO messages if used to transfer data have to have some kind of sequence number so you know to ignore duplicates.
• Firefox for Windows seems to use slightly different FIDO2 implementation than Firefox for other OSes, probably had to in order to use the Windows FIDO2 API, Windows blocks apps that are not running as admin from USB access to device unless they use the Windows FIDO API.
• I believe the keyhandle value used with navigator.credentials.get has to be less than 255 bytes or Firefox has issues.

Hope this helps a little bit.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/solokeys/solo-webupdate/issues/15?email_source=notifications&email_token=AA6CN5M2XCFFNGJC2X7CR6LQPHQVPA5CNFSM4ILMOW6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBVCC6I#issuecomment-543826297, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6CN5NWB3J3PGEDMTI7NUTQPHQVPANCNFSM4ILMOW6A .

[onlykey]

@conorpp It would be interesting to see how Chrome is going to prevent this. It is impossible to distinguish whether the challenge and keyhandle is random data or encrypted data. They could definitely limit the size of keyhandle but that would just force encoding the data in smaller chunks.

UPDATE - I tested webcrypt on chrome canary just to verify, its still working there. I will have to keep an eye out for these changes, thanks for the heads up!

UPDATE Again - For your question, we manage a desktop app and its kind of a pain to manage but yeah there needs to be a way to visually manage the credentials. I am planning on implementing a feature in our app to allow viewing resident keys (just a label, maybe the RP) and deleting RKs because once RKs become mainstream people are going to run out of space (this could easily be years though before RKs catch on). You will have to have another Interface though, Win 10 will not permit your app to communicate with the key unless it's run as admin. We now have 3 interfaces, keyboard, FIDO HID, Raw HID, and will probably have a 4th for CCID at some point. The other way you could do your app without adding an interface is to do a config mode, i.e. hold button down for 5+ sec, device reboots with different interface config i.e. not using Usage 0xFID0, then your app in Windows wont need admin privileges to talk to it. This approach also provides extra security as its hard to accidentally put device in config mode and malware on the computer could not force config mode to do bad things.

[My1]

@conorpp an application for managing fido keys of many types sounds interesting

@onlykey chrome can probably just block it in a relatively easy way which becomes obvious when you just look at the solo webpdater isnt that popup spam meaning, you are literally pushing through like a metric f-ton of request with each their own cred-ID (each of which contains a part of the update data)? so by limiting the amount of requests you can do would easily kill this. you probably wont see authenticating a user more than once every 10 sec or so.

I am planning on implementing a feature in our app to allow viewing resident keys (just a label, maybe the RP) and deleting RKs because once RKs become mainstream people are going to run out of space (this could easily be years though before RKs catch on)

now THAT sounds great, because currently you cannot grill single RKs and especially on yubis which only have 25 slots this sux in particular, and having a feature to grill RKs is also really helpful in dev because at least last time I checked chrome gets totally stuck and cancels when you have multiple RKs for the same RP loaded, while edge on windows 10 apparently spawns a question dialog (edge insider on windows 8.1 apparently not though)

[onlykey]

@My1 I guess I was thinking more in terms of chrome blocking for our webcrypt app (only uses 2-3 FIDO messages) I can see how it could block for firmware update which is 100s of KBs in size.

chrome gets totally stuck and cancels when you have multiple RKs for the same RP loaded

^ I have seen this too, it makes testing difficult

Another thing I thought of that might be easier than a desktop app is to just create a web app. You could always easily turn it into a desktop app with something like this - https://github.com/jiahaog/nativefier

If you are only using one FIDO message (one call to navigator.credentials.get) I don't see how chrome can block this, this message would be used to read some data like label of RK in slot X, and then the user can select to wipe by holding down button for 5+ sec that would probably work well. Similar thing could be done for changing PINs or other tasks, only using one FIDO message at a time. User presence would need to be involved and probably some other security controls like only allowing certain origin web site in firmware. If you go with this approach we could probably collaborate as this is something we would add to our existing web app.

[My1]

sure rate-limits while using only a few reqs is basically only making it a bit more annoying to use, but honestly I dont even get WHY chrome blocks these? I mean it's a very fun way to work with limited resources.

using webapps and then creating them into a more or less native app using at least for electron iirc is something I dont really love because it basically brings along its own browser needing a ton more resources than a real native software (discord for example runs on 4 processes with almost 350 MB ram for me, which seems quite a lot for me), no idea how nativefier handles that though.

^ I have seen this too, it makes testing difficult

full ack, I dont even know how often I reset my hack-solo just because of that, and it makes using a device you normally use for dev really hard especially since the reset also knocks down the master secret for "remote credentials" aka infinite mode. listing and axing RKs is like one of the biggest and most obvious oversights in Fido2 imo (especially considering UAF has something for that)

no idea what all the things chrome wants to kill are but couldnt webusb with non-FIDO USB commands work, at least if there are any places for "custom" or "vendor" commands, maybe raw HID has some, no idea.