Bluetooth KNOB Attack is for Classic Bluetooth, not Bluetooth LE

There’s a Bluetooth security vulnerability story doing the rounds that, according to the security researchers:

…affects basically all devices that “speak Bluetooth”

This isn’t true. The vulnerability relates to Bluetooth BR/EDR, so called ‘Classic Bluetooth’, and not Bluetooth LE. It isn’t found in beacons or other devices communicating via Bluetooth LE. It also isn’t found in Bluetooth mesh.

Read about Beacons and the Bluetooth Mesh

Bettercap for Debugging Bluetooth LE

There’s a useful tool called bettercap that claims to be the “Swiss Army knife for WiFi, Bluetooth Low Energy, wireless HID hijacking and Ethernet networks reconnaissance and MITM attacks”.

While you might want to use it to test Bluetooth LE security, a more interesting use is for debugging Bluetooth LE. If you are scanning for advertising or creating or using GATT, for example with a beacon, it’s sometimes useful to have a separate way of exercising Bluetooth LE.

Bettercap is written in Go and runs on GNU/Linux, BSD, Android, Apple macOS and the Microsoft Windows. However, a bug in Windows and macOS prevents the Bluetooth commands from working. Hence, it’s for Linux or Android only.

Better caps runs in the browser and you can create scripts.

Bluetooth MAC Randomization Can Be Defeated

The Register has an article Brilliant Boston boffins blow big borehole in Bluetooth’s ballyhooed barricades: MAC addy randomization broken.

Beneath the hyperbolic alliteration is some research (pdf) that Bluetooth MAC randomization isn’t foolproof. Researchers have found that similarities between the non-MAC information in advertising allows devices to be uniquely identified:

“What is perhaps even more concerning, say the Boston Uni trio, is the message Bluetooth vendors are putting out to the public when they advertise Bluetooth LE as being an untrackable standard.”

In actual fact, very few vendors do MAC randomization. The majority of beacon manufacturers don’t because the whole idea of a beacon is that it can be identified via MAC address or iBeacon id. For the same reason, most Bluetooth accessories don’t as they want to be identified via apps. Android smartphones don’t do MAC randomization but iOS and Windows 10 do to improve end-user privacy. It’s mainly iOS devices that will be moving around and possibly tracked in-store or on-site via the ‘vulnerability’ described in the paper.

Guide to Bluetooth Security

We occasionally get asked about the specifics of Bluetooth LE security. This is usually when a project has security requirements or needs to formally document things such as cryptography schemes and vulnerabilities.

The U.S. Department of Commerce National Institute of Standards and Technology (NIST) has an informative Guide to Bluetooth Security (pdf) that provides information on the security features of Bluetooth, vulnerabilities, threats and extensive recommendations.

The following table provides an overview of Bluetooth LE compared ‘Classic’ Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR) protocol:

Bluetooth LE 4.2 and later uses ECDH P-256 Elliptic Curve public key cryptography for protection against passive eavesdropping and man in the middle (MITM) during pairing.

While it’s good for projects to be aware of the underlying mechanisms and their limitations, we find that, in practice, security threats and weaknesses tend to be related more to how Bluetooth LE is used (by software) on a particular project rather than Bluetooth implementation itself. We offer Consultancy for clients wishing to explore project specific security.

Crowd Security with iBeacons

The UK Defence and Security Accelerator (DASA) held a competition to find ideas to reduce the threat of terrorists in public spaces. KSharp created CriB, Crowd Resilience through iBeacons, a system using iBeacons to allow people to report terrorist threats and receive security alerts through an app. This allows venues such as city centres, shopping centres and sports stadiums to improve safety and security. A video has recently become available:

Bluetooth Beacon Security

We sometimes get asked about Beacon security. Beacons use Bluetooth so the underlying security is that provided by Bluetooth 4.0. There’s a great new video by Ellisys, who create Bluetooth test equipment, that explains the threats and mitigations:

In the context of beacons, the mentioned perisistent bonding never happens. Pairing is temporary. Also, beacon manufacturers often layer additional security on top of Bluetooth in the form of pins or passwords required to set up the beacon.

As the underlying Bluetooth communication is relatively secure, the main beacon security issues tend to be related to spoofing (the possibility of beacons pretending to be yours). However, this is usually only pertinent in security sensitive scenarios such as payment. Contact us if you need more advice on beacon security.

Beacons and Physical Web Security Review

Renaud Lifchitz, a security consultant, has some great new slides on Security review of proximity technologies: beacons and physical web.

He mainly concludes that:

  • Beacons can easily be spoofed
  • Beacon passwords are often sent in plain text
  • Web Bluetooth might be used with XSS to allow hacked sites to access local devices via GATT

The spoofing issue is well known and is a necessary consequence of a broadcast, non-connectable, type mechanism. Fortunately, people mainly only use these things for nefarious purposes when there’s a profit motive. Spoofing beacons rarely benefits anyone.

The beacon passwords thing sometimes happens when beacons are set up using the manufacturer app. This is usually a one-off event, when the beacon is first set up, when the user is usually control who in their surroundings. Hence, it’s very unlikely other people will ‘sniff’ the beacon password.

For Web Bluetooth, GATT communications without a known password is benign. You can’t do much by just connecting to a beacon or Bluetooth device. You usually need a password to change or view security sensitive data.

While it’s good to know these things, it’s very unlikely any of these security observations will ever be a problem. Beacons don’t tend to be used in critical or valuable scenarios so the risk of things being subverted is low. There are much easier, more valuable and higher profile targets for hackers in the shape of servers, desktops, laptops and apps. Even if one of the mechanisms mentioned in the slides were used one day, the consequences, for most scenarios, would be minimal.

Paper on Using Eddystone Ephemeral-ID (EID)

There’s a recent paper by Debasis Bhattacharya Mario Canul and Saxon Knight of the University of Hawaii on the Impact of the Physical Web and BLE Beacons (pdf). The paper is based on a project that uses Eddystone Ephemeral-ID (EID). The paper is more a backgrounder and description rather than providing new insights. Nevertheless, it provides a useful description of some security issues with beacons that include tracking of beacon locations, forgery and showrooming.

Secure Location Sensing in Healthcare

A research paper recently became available by Paul D. Martin and Michael Rushanan of Harbor Labs, Thomas Tantillo of Johns Hopkins University, Christoph U. Lehmann of Vanderbilt University and Aviel D. Rubin of Johns Hopkins University. The paper, Applications of Secure Location Sensing in Healthcare is part of the Proceedings of the 7th ACM International Conference on Bioinformatics. There are also some associated slides by Michael Rushanan.

The paper considers the use of beacons to track hospital assets and provide for location-based access to patient records. The tracking of hospital assets is an important usecase because staff spend:

“1 hour per shift searching for equipment and the average hospital owns 35,000 inventory SKUs and utilization hovers around 32-48%, with nearly $4,000 of equipment per bed, lost or stolen each year”

The second use, the reading of patient records based on location, is particularly security sensitive. The paper describes an implementation of what they call Beacon+ that builds on iBeacon advertising to make location sensing more secure.

The Beacon+ system uses “monotonically increasing sequence number and message authentication code (MAC)”. This is similar to the (optional) changing id provided by our Sensoro beacons. The concept is also similar to Eddystone-EID that was announced at about the same time this research was ongoing.
The paper discusses using the Translated Midpoint Method rather than trilateration as a method of determining location based on readings of RSSI of multiple beacons. The accuracy turned out to be 1-2 meters in the best case and 9-10 meters in the worst case that produced a better result than trilateration in their specific experimental situation.

As with this and other security sensitive scenarios, the use of changing UUIDs needs Internet access to reconcile ids. Hospital is a suitable case as it can be arranged to have reliable (WiFi) Internet access available. However, in many other scenarios, such as visitor spaces, particularly indoors or when the user is roaming internationally, Internet access isn’t always available. Also, depending on the quality of the Internet connection, a round trip to the server can slow detection response considerably and affect perceived reliability. Hence, secure rolling UUID schemes should only be used as and when security dictates and not as a matter of course.

The paper also mentions:

“There exists an implicit assumption that devices that can verify Beacon+ advertisements are also trusted”

Not all devices can be trusted. Android and iOS devices can easily be rooted/jailbroken and/or be compromised via malware. Hence, secure rolling beacons are only a part of defining a secure solution. As with other secure scenarios such as banking, apps have to make an self-assessment whether they are running on a compromised device.

Which Beacons to Buy?

There’s a recent thought provoking post at Hotel Online, by Dr. Michael Arner is the Chief Technology Officer of RoamingAround, on How Do You Choose Which Beacons to Have Faith In? The article questions the merits of being tied in to a particular supplier’s hardware or software features.

The article gives the opinions:

“If you’re a beacon merchant, I suppose it’s great to have clients that are willing to shackle themselves to your super-special hardware, but if you’re the consumer, it’s usually best to avoid doing so when you can.”

“In reality, iOS and Android devices can both speak to both protocols and there are very few reasons why you shouldn’t be choosing a solution that’s beacon agnostic.”

On security:

“There exist beacons which maintain proprietary end-to-end encryption, and these should be purchased, in the very rare case they’re needed

On Customer service:

“multiply-source your vendors and then you’ll discover that the decisive factor ends up being not the device stats but the customer service”

Summarising the advice in the article, look beyond what’s being offered or promoted by vendors. They will always be promoting their unique selling points but those might not actually be the decisive factors for your project.