Beacon Jewellery as a Personal Security device

IT World Canada recently reported Telus launches personal security beacons disguised as jewellery.

A problem with beacons is that they tend to look ugly when worn. Telus have solved this problem and have developed an app and service so they can be used as a SOS lifeline.

The Telus SmartWear looks like jewellery or a keychain. It connects using Bluetooth to a smartphone. When the back of the charm is double clicked it sends a alert. Telus will ring you back to confirm you need help and, if necessary, send emergency services.

Bluetooth Vehicle–Pedestrian Collision Warning

There’s recent research by Carleton University, Ottawa, Canada on Investigating Wi-Fi, Bluetooth, and Bluetooth Low-Energy Signal Characteristics for Integration in Vehicle–Pedestrian Collision Warning Systems.

The paper looks into the comparative performance of Wi-Fi, Bluetooth Classic (Bluetooth) and Bluetooth Low Energy (BLE) for integration in vehicle–pedestrian collision warning systems. More specifically, accuracy and functionality are considered with respect to signal strength indicator (RSSI) distance stability, rainfall effects on the signals, motion effects, non-line of sight effects and signal transmission rates.

The experiments identified the overall superiority of Bluetooth LE over Wi-Fi and Classic Bluetooth. Bluetooth LE provides fast collision warnings due to the frequent transmission and provides higher probability of simultaneous signal detection by multiple scanners.

The researchers say the results indicate the possibility of integration of Bluetooth LE technology in the design of vehicle–pedestrian collision warning systems in addition to currently used systems.

Log4j Vulnerability

If you work in IT you will be almost certainly aware of the very recent Log4Shell vulnerability indexed as CVE-2021-44228. The Log4j is used by many popular applications, services and Java components. This vulnerably demands particular attention because it’s implicitly included in lots of software and allows an attacker to execute arbitrary code on affected systems.

We have completed a thorough analysis of our own systems and the software we supply to customers and can declare we have no services, products, or applications that are at risk. We don’t use Java at all and none of the components we use are using it behind the scenes.

Even though Beaconzone systems are not affected, there is the possibility that your other services might be impacted. You should communicate with your IT department to identify and mitigate this vulnerability. The NCSC has released a very large list of known affected software and the steps you can take.

Tracking Bluetooth Devices Without Using MAC Addresses

We often get asked if it’s possible to track smartphones using Bluetooth. For example, a retailer might want to know how long someone stays in their store and whether they visit again.

While iOS devices advertise Bluetooth continuity messages it’s not possible to track iOS devices using their Bluetooth MAC address because the address changes over time in order to defeat such tracking. However, as previously mentioned, Bluetooth MAC randomisation can be defeated. Android devices don’t usually advertise but some do if Covid tracking is on.

There’s a new paper by researchers at UC San Diego on Evaluating Physical-Layer BLE Location Tracking Attacks on Mobile Devices (PDF). It looks into Bluetooth physical-layer patterns to track a variety of device types.

A tool has been created to automate discovery of imperfections in signal modulation.

These imperfections are caused by manufacturing variations in the transmitter hardware.

Some, but not all, devices have unique fingerprints and can be tracked.

Mesh-based Panic Button

There’s an article at business of business on how Yasmine Mustafa has created a new business Roar For Good that supplies smart panic buttons for hotel and hospitality workers.

This is one of the first applications of Bluetooth Mesh outside of lighting. Workers push the panic button if they need help. A nearby beacon is used to identify their location and a notification is sent to security or the hotel manager.

Read about Bluetooth Mesh

Bluetooth LE for Smart Cities

There’s new research on BLE Beacons in the Smart City: Applications, Challenges, and Research Opportunities.

The paper explains how BLE beacons are a promising solution for many smart city applications. It describes BLE beacons, protocols, competing wireless technologies and the types of applications.

The paper covers some applications such as proximity marketing, indoor navigation and location based services.

Security and privacy issues are also mentioned such as cracking, spoofing and piggybacking.

Nordic Semiconductor APPROTECT Compromised

LimitedResults have published details of how they have been able to access what were previously presumed to be protected Nordic Semiconductor nRF52 devices. nRF52 devices are regularly used in beacons and other Bluetooth devices such as fitness trackers. This post summarises the vulnerability, looks LimitedResults claims, Nordic Semiconductor’s response and how that affects those using such devices.

Nordic nRF52 System on a Chip (SoC) devices are small Arm® Cortex™-M4 CPU computers running software. The software is flashed into the devices and authors usually apply what’s called APPROTECT to prevent the software from being read back and the debug port from being used for examining data. The software read back lock is to prevent the software being copied onto non-sanctioned devices or for decompilation to obtain algorithms that might be considered intellectual property (IP). Examining data via the debug port allows access to passwords or data that might be considered to be confidential.

LimitedResults have cleverly managed to disrupt the running of the SoC by removing some circuit capacitors and producing a very short pulse on the power line. This allows bypassing of the APPROTECT, subsequent use of the debug port to control code execution, extraction of the code and ultimately disabling the APPROTECT mechanism. LimitedResults say:

Due to its low-complexity, this attack on the nRF52840 can be reproduced on the field easily

Nordic Semiconductor responded today with an Informational Notice that describes the problem and concludes:

The nRF52-series of SoCs, like many standard microcontroller circuits, are not hardened against fault injection techniques

This puts the onus on companies using the nRF52 to only use it for non-critical uses where a security breach has negligible consequences OR to only use it where it’s known that physical access, required to perform such security breaches, is unlikely or impossible to occur.

What does this mean for users? This affects nRF52-based product owners in that binary code can’t now be considered safe from copying or examination. While this sounds concerning, anyone wishing to take advantage of the vulnerability needs a very high level of skill. Despite LimitedResults saying it can be “reproduced on the field easily”, the ‘easily’ part is contentious. Producing a power spike isn’t easy. Analysing extracted binary code and data also requires a high level of skill. We can’t think of any uses of the nRF52 where it would be worth the effort.

When it comes to the end users, there could be uses, particularly in healthcare, where a vulnerability might be a concern. For example, Nordic devices have been used in heart rate monitors. However, the vulnerability requires removal of components from the circuit board and physically attaching wires to the inside of such devices. With today’s surface mount based PCB designs, it’s difficult to do this in the lab let alone on a user’s device.

As with all security issues, you have to put possible attacks into perspective. The vulnerabilities are difficult to exploit and not worth the effort in most cases. The security of the nRF52 is suitable for the kind of data collection tasks for which it tends to be used.

It’s in security-critical areas such as healthcare and finance that such vulnerabilities need to be taken more seriously. As with some microcontrollers used in finance, extra physical (impossible to get to the circuit) and/or software (self-destruct) protections need to be put in place.

SweynTooth and Beacons

New vulnerabilities, called SweynTooth, have recently been found in Bluetooth LE. The problems aren’t in Bluetooth itself but in software development kits (SDKs) provided by some System on a Chip (SoC) manufacturers.

There are three types of problem that can be triggered by sending particular data to Bluetooth devices: crash, deadlock and security bypass. Only some manufacturer’s SDKs are affected and only some of their SoCs models.

Texas Instruments, NXP, Cypress, Dialog Semiconductors, Microchip, STMicroelectronics and Telink Semiconductor SDKs are affected. The main manufacturer used in beacons in beacons and gateways is Nordic so the majority of beacons are not affected. Nevertheless, there are a few beacon models that use Texas Instruments and Dialog Semiconductors SoCs. Of these, very few use the specific affected SoC models.

The only affected devices we stock are the ABKey01, TON9128, TON9118, TON9108 that use the Dialog DA14580 SoC. You should avoid using these in critical scenarios because they can be caused to crash or deadlock. No beacons are vulnerable to the security bypass vulnerability.

As with all security issues, you have to put the possible attacks into perspective. The vulnerabilities are difficult to exploit in practice and it’s usually much easier to steal a beacon or remove its battery to make it inoperable.

The vulnerabilities are of more concern for critical medical devices such as pacemakers and blood glucose monitors.

Tesla Model 3 is an iBeacon

There’s an article at The Parallax on how the Tesla Model 3 constantly sends out iBeacon advertising. This allows the Android/iOS app to see the car and consequently unlock and start the car without a key. Martin Herfurt, a security expert for Austria, claims this is a security and privacy vulnerability.

Tesla’s response has been:

“BLE tracking is something we’ve discussed internally, and we revisited this discussion after receiving your report. However, our current assessment is that randomizing BLE identifiers would not result in significant privacy gains due to the ubiquity of automated license plate readers”

What Tesla is saying is that there are other ways to track cars so they believe it’s not a issue.

The security researcher can detect cars up to 50m away and said…

“… the range can be easily extended with a directional antenna, possibly to reach up to a mile away”

We would like to know how to ‘easily’ get such a directional antenna as, to our knowledge, no such thing exists. 50m range advertising is just that and can’t be extended significantly by changing the receiver antenna.

However, the Tesla Model 3 being an iBeacon raises the question whether this is a significant privacy concern. Indeed, anything or anyone advertising Bluetooth can turn into a privacy concern. In the article, connected-car security researcher Tim Brom says it can be a concern if you’re a high-value target of any kind or worried about a stalker.

Even when id’s or randomized or cycled, as in the case of Eddystone EID, the mere presence of Bluetooth advertising can reveal the presence of something that needs to be concealed. For example, Wired recently wrote Burglars Really Do Use Bluetooth Scanners to Find Laptops and Phones.

The learning is that you shouldn’t blindly implement Bluetooth without considering the security implications and providing mitigations. In the case of Tesla, they could have had an option for security conscious users to turn off Bluetooth and instead use a key.

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