Hacker News new | past | comments | ask | show | jobs | submit login

Yes, I have seen this recently. Google is so unsatisfied with BLE in FIDO2 so they removed support for it from the Chrome browser.

Yubico has said from the very beginning that they will stick to NFC because Bluetooth is not secure.

Bluetooth is a 3000+ pages spec that's a mess and will likely always remain a mess. Maybe it's time for something better?

I'm using a bluetooth keyboard and I type my passwords in plain text. I don't think that public key sent over bluetooth is less secure. So it's a very tricky topic and I think it's more about corporate insterests that actual security.

Bluetooth security has always been a mess and even the specification itself has had egregious bugs that almost all devices were and often are still vulnerable to: you can force 8bit symmetric keys if you like: https://knobattack.com

I would never trust any wireless keyboard or mouse on any even marginally important computer. Bluetooth security is a broken mess, and taken together with the mess most bluetooth functionality is (e.g. perpetually broken, laggy, stuttering, forgetful, lofi audio profiles) bluetooth needs to die asap.

Is Bluetooth not encrypted? It would be disastrous if just anyone could read what your Bluetooth keyboard is sending.

It is encrypted with MITM protection. That's why I do not believe in severe security issues in BLE. There can be problems with particular implementations, but in general it should not be less secure that typing password on a keyboard.

Your keyboard very likely isn't using BLE (Bluetooth Low-Energy). The issue appears specific to BLE which behaves differently than Bluetooth X (4.0, 4.1, 5.0, etc) "proper" and has a different security profile.

Just so we're on the same page, "Bluetooth X" was discontinued at 3.0 -- it's now named "Classic Bluetooth."

Bluetooth 4.0 (4.1, 4.2, 5.0, 5.1) are almost exclusively the artist formerly known as Bluetooth LE. LE is a totally different standard than classic Bluetooth, and was developed by Nokia ("Wibree") and dropped on the desk of the SIG with a big thud. Nokia told the SIG this was Bluetooth now, and they adopted it as "LE" and it forms the core of all version of Bluetooth 4.0 and later.

4.0 and later specs include "LE", "Classic" and "High-Speed". It's very unlikely developers are building for Classic mode anymore, that protocol is an utter nightmare. I don't know anyone building High-Speed devices.

I'd be surprised if a new keyboard opted for anything other than LE. That's just the kind of embedded system it was designed for.

Thanks for the clarification. That's interesting, I had wondered why I always "felt" Bluetooth had gotten slower lately, but thought it was just me!

Perhaps you can clarify whether I was barking up the wrong tree in my original comment; My understanding is that keyboards, HID devices in general, are usually using something like "Classic mode" or perhaps even actual classic Bluetooth (particularly cheaper/older hardware)

The security keys like the are using the "modern" type, which is a different "spec". I don't know if it's using something like like (G)ATT, but it's not the same spec/tech?

I'm not sure where the industry is at these days, to be honest. So as far as I know all LE devices use the GATT profile (though I wonder about headphones). The LE spec includes HOGP (HID over GATT Profile) which defines a set of services and characteristics for LE HID devices. [1]

Older devices almost certainly use a Classic Bluetooth HID profile, but newer devices like the Apple Magic Keyboard are LE HOGP devices. It uses much less energy so IMO a battery-powered HID device would be pretty nutty to implement using Classic Bluetooth in this day and age.

Interestingly there's no concept of "pairing" in LE devices, just "bonding" (where previously derived keys are persisted and re-used as an optimization). All LE peripherals operate in promiscuous mode by default and vendors have to implement their own pairing system -- or piggyback off bonding.

[1] Warning PDF link: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...

You are probably right. However, the BLE transport was not removed from the 2.1 specification and supported by Microsoft Hello. And, anyways, for Arduino based DIY project existing security is more than enough.

That's what I thought, thank you.

What about Google's use of "Smart Lock" via bluetooth to secure each sign on attempt with Google Advanced Protection?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact