Ok.. release v1.4.2 is up for review by Google.
Let me know if anyone runs into any more bugs or problems!
2 Likes
Ok should be live now. Update and test.
4 Likes
A couple more updates for different Yubikey devices, specifically FIDO2 pre-standardization devices.
v1.4.3 is up for Google review
2 Likes
Avaliable
3 Likes
Webauthin still gives this information for a Samsung phone. I know you said that you ordered a Samsung phone to test. Did you find a way to get Samsung phones working? I’m almost considering getting a nothing phone like you have to ditch the Samsung bs haha.
Description:
device-bound credential of unknown discoverability
Transports:
[“nfc”, “usb”]
Provider Information:
Name: (Unavailable)
AAGUID: 00000000-0000-0000-0000-000000000000
Yes, I did get a Samsung s9+ but I think it doesn’t support Android 14 required for this.
Can you run down the problem for me again?
1 Like
Sure, when trying to use the bridge on samsung phones it never sees the apex flex as a full passkey as it does with another reader such as the ACR122u. I did a whole battery of tests to try to get this working here: Vivokey Apex Flex Android FIDO2 Issues - #9 by gatsu referenced from you response to this post here: VivoKey releases NFC Passkey Bridge - #84 by gatsu The implant works perfectly fine for U2F on android but nothing with resident keys even when using the bridge. I actually seem to have more stability in doing U2F through the built in android NFC feature than even trying to do U2F via the bridge.
After upgrading my phone to android 16 the issues persist. I highly suspect this is just a quirk or some sort of software issue samsung does with their crappy OS tweaks.
1 Like
Hmm ok. Sorry if we’ve gone over this already but can you test the native NFC token support using webauthn.io or webauthn.me with the Apex to ensure the phone can even do it.. then we can move on from there?
1 Like
No problem, all of the tests in this chart Vivokey Apex Flex Android FIDO2 Issues - #9 by gatsu were done on webauthn.io with different settings listed on webauthin.io such as direct or requiring user authentication (first column),
if I was ever prompted to enter a pin and when such as only when registering the key or also when logging in (second column),
OS and browser as self-explanitory (third and fourth columns),
VIA is how the NFC was scanned. Only the first 2 tests were done on my PC the rest were either with the native android OS or using the Bridge app (fith column),
The rest are the results that webauthin.io gave after being able to login or if it failed.
edit: since I made that chart I’ve been able to educate myself a lot on how CTAP works and understand why the native OS never asked for pins because android itself doesn’t support CTAP 2.1 yet. However the data may be useful for you in debugging what voodoo samsung is doing. If you want me to run any additional tests let me know. I’m traveling for work atm but when I get time I’d be happy to do whatever.
1 Like
I saw earlier in the thread a bunch of testing on graphene OS happening. Im running into some issues with both registering from a qr code, and using the bridge in the vanadium browser with webauthn.io
im curious if a solution exists to these issues, or if theres some extra data i can provide to help troubleshoot getting graphene working for everyone with this app.
I saw this thread mentioned above Passkeys as MFA on GrapheneOS: a guide - GrapheneOS Discussion Forum and gave it a shot but no luck. I was able to set up passkeys with bitwarden locally i.e though vanadium but no luck with the bridge to vanadium. So i atleast know passkeys function through other providers.
1 Like
All I can say is - it’s possible. However grapheneOS and the associated browsers and interplay with caBLE protocol is very esoteric. Supporting it directly with how to instructions would seem to have so many caveats it’s impractical.
If you want to explore it, update with everything you’ve done so far with screenshots and clear expert descriptions. Screen record if you have to while you talk through what’s happening.. we’ll try to get things worked out
2 Likes
thanks for the quick reply - ill start compiling evidence today. Perhaps we can break this into two seperate issues and tackle them seperately. One being getting the bridge working locally on the phone its self, and the second remotely with bluetooth.
3 Likes
Sounds good! Let’s see if we can work through these and get it working for you.
2 Likes
Last year, I experimented with YubiKey, the Yubico Authenticator, and GrapheneOS, but couldn’t get it to work. However, there seems to be a general problem, as GOS containerizes all hardware interfaces and certain APIs have not been outsourced separately. For this reason, Bluetooth, location (even with a USB connection), and nearby devices must be enabled for GFS. However, most users are reluctant to use GFS, for example.
Have you perhaps found a way to use it without GFS?
Hover
The alternative would be to implement the proprietary and not well documented caBLE protocol inside the app somehow.. sadly that’s well beyond my skill and patience level at this point.
Does the bridge currently have support for selecting a specific credential when there are multiple enrolled for a single domain?
Ran into an issue where I have multiple accounts on a site enrolled to the same passkey. When signing in with a NFC reader on Windows, a dialog box pops up saying there are multiple credentials with an option to choose the one you want. When using the bridge, it seems to just select the newest/last credential for the given site.
I was able to work around this for the time being by entering my email first, instead of just clicking the “Sign in with passkey” button without entering anything first.
1 Like
yeah should do, as long as those are resident credentials.. otherwise it won’t matter… or shouldn’t.. but you know how implementations can get all.. sideways.
Do you see both creds listed with Passkey Manager?
1 Like
Yup. I see both credentials listed in the passkey manager.
I think I figured part of it out. I went to record a video of the issue and I enabled PIN caching so I didn’t have my recorded PIN in the video. As soon as I enabled PIN caching, I got the popup asking me to choose what credential I wanted to use. Turned off PIN caching, and it went back to using the newest/last credential.
2 Likes
oo shit. good find. fix incoming.
3 Likes
in review…
1 Like