![]() ![]() Is the account listed in Settings on the phone the same as the “Username” in chrome://sync-internals on the desktop? If all that's good then probably you just need to wait because it can take a couple of days for the registration to propagate. On the phone, does Settings say that Sync is on at the top? If not, enable it. If no phones appear as options: you're using Windows, macOS, or Chrome OS, yes? And it's an Android phone? And the machine has working Bluetooth? And Chrome is up to date everywhere? If you navigate to chrome://sync-internals, is the “Transport state” at the top-left reporting “Active”? If not, enable Sync. Some troubleshooting hints if you're having issues because this will be much faster than asking me! I can't promise to respond but I will read everything if you send me an email (agl at chromium dot org) or tweet at me ( agl_). So if you are especially keen about security keys and want to try this out, I’d be interested in your experiences. Aggregated anonymous statistics are useful for many things but in this case they suggest that BLE isn’t always working as well as it should, but don’t tell us why not. Now that the desktop only needs to receive a BLE advert it looks like it could work, but we haven’t flipped that switch yet.Īs I mentioned above, we are interested in whether the underlying infrastructure is plausible. ![]() Historically trying to do the BLE GATT connection would often fail with bluez, and so the phone as a security key infrastructure was disabled on Linux. ![]() This isn’t enabled on Linux at the moment. (But very sadly not on Windows The USB stack there just isn’t designed in the right way for it.) We might also add L2CAP as an option in the future. So you can also connect the phone with a USB cable while the security key operation is running. Needing bilateral internet connectivity is unfortunate though. ![]() That’s the least amount of Bluetooth we could use while still requiring physical proximity. So where we’ve ended up is that all the communication happens over the internet connection, but the phone sends a nonce in a BLE advert and the other end of the channel has to prove receipt. It’s also flaky in the face of MAC address rotation if the devices aren’t paired. BLE L2CAP is supported on iOS, but isn’t supported (in user space) on Windows. We looked at other Bluetooth modes in the hopes that they might work better, but classic Bluetooth RFCOMM isn’t supported on iOS and requires a lot of user interaction on android. (Or at least that the attacker is in control of a BLE radio that is physically close.) So when a phone is acting as a security key it needs to prove that the machine it is talking to is physically close by. For a USB security key the authenticator will only respond to something that is making physical contact with it. The security model demands some proof of physical proximity between the authenticator and the machine that is being authenticated. After quite a lot of work trying to improve the BLE success rate, we didn’t achieve much.īut the use of BLE is more than just a convenience. We have wanted to expand this to the web in general for years, but the success rate that we measured with BLE was poor. This only worked in Chrome and functioned over BLE GATT between the desktop and phone. (More below.)įor signing into Google, it has long been possible to use your phone as a security key. We are interested in whether the communications infrastructure is good enough though. We have plans for addressing this and making this suitable for regular people, and to allow use in other profiles, but we’re not there yet. (You can also lose your credentials if you remove the screen lock, or somehow wipeout Play Services state - e.g. So, just like a regular security key, you should have a back up. Just like a regular security key, if you lose the phone then you lose the credentials. The reason that you are reading about this here and not on an official Google site is that people shouldn’t start registering their phone as a security key unless they have a physical security key as a back up. (But not, which uses a different system.) You should be able to try this out on any WebAuthn using website, for example here. With Chrome 94, if you have an Android phone with Chrome on it, and it’s syncing to the same Google account as Chrome on a Chrome OS/Windows/macOS device, then you’ll be able to use that phone as a security key. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |