Bluetooth

From MgmtWiki
Jump to: navigation, search

Full Title

A data interchange standard using a radio with limited range.

Context

  • In the late 1990's big companies like Intel were trying to find a mechanism that could be used to transfer more data than NFC that consumed low power.

Low Energy

BLE or Bluetooth Low Energy.[1][2]

Also excited by a stationary antenna that causes the smartphone to respond
Needs to have an app on a smartphone that is powered up and has Bluetooth enabled that responds to the message with a UUID
Operations at 2.4 GHz at about 70 meters between device and antenna.

Host Controller Interface (HCI)

The host controller interface (HCI) layer is a thin layer which transports commands and events between the host and controller elements of the Bluetooth protocol stack. In a pure network processor application (that is, the host_test project), the HCI layer is implemented through a transport protocol such as SPI or UART.[3]

Logical Link Control and Adaptation Layer Protocol (L2CAP)

The L2CAP layer sits on top of the HCI layer on the host side and transfers data between the upper layers of the host (GAP, GATT, application) and the lower layer protocol stack. This layer is responsible for protocol multiplexing capability, segmentation, and reassembly operation for data exchanged between the host and the protocol stack. L2CAP permits higher-level protocols and applications to transmit and receive upper layer data packets (L2CAP service data units, SDU) up to 64KB long.[4]

Security

The Bluetooth security model for both versions of Bluetooth Classic and Bluetooth Low Energy (BLE) includes the following distinct security features: Pairing: The process for creating one or more shared secret keys Bonding: The act of storing the keys created during pairing for use in subsequent connections to form a trusted device pair Authentication: Verifying that the two devices have the same keys Encryption: Message confidentiality Message integrity: Protection against message forgeries Secure Simple Pairing: Protection against passive eavesdropping and protection against man-in-the-middle attacks.[5][6]

Problems

  • Security was not designed into the protocol at the beginning.

Attacks

Beacons

While beacons using Bluetooth was introduced to solve a problem, but it just substituted one problem for another. This attack was published in late 2021:[7]
Bluetooth hardware contains a security flaw that may compromise about 40% of mobile devices, according to University of California, San Diego (UCSD) researchers. The hardware underlies the operation of phone-tracking applications, which UCSD's Nishant Bhaskar said "require frequent and constant transmission of Bluetooth beacons to be detected by nearby devices. Unfortunately, this also means that an adversary can also find out where we are at all times by simply listening to the Bluetooth transmissions from our personal devices." Defects or imperfections during manufacture can slightly distort Bluetooth signals from individual devices, resulting in the generation of a unique signature. Experiments showed approximately 40% of mobile devices could be identified individually within crowds based on their Bluetooth signal signatures.

Some Solutions

  • Web Serial support for Bluetooth RFCOMM services Explainer
    Although most current development activity on Bluetooth technology focuses on Bluetooth Low Energy (BLE) and mesh, active development still exists on Bluetooth BR/EDR (AKA "classic"). The Bluetooth classic Serial Port Profile (SPP) remains a popular profile, has support from currently shipping hardware, and at present has no suitable replacement in BLE. SPP is implemented using the lower-level Radio Frequency Communication (RFCOMM) protocol designed to emulate RS-232 serial ports. New hardware is still being introduced with performance characteristics that need the latency & bandwidth of SPP and RFCOMM. We can address this need by exposing serial connections via the Web Serial API.
  • Shiny.BluetoothLE and other comms packages for .NET achived & inactive on 2023-06-22
  • OpenID for Verifiable Presentations over BLE - draft 00 This document defines how Bluetooth Low Energy (BLE) can be used to request the presentation of verifiable credentials. It uses the request and response syntax as defined in [OpenID4VP].

References

  1. IoT Security Using BLE Encryption https://www.networkcomputing.com/wireless-infrastructure/iot-security-using-ble-encryption
  2. TI, Bluetooth https://software-dl.ti.com/lprf/simplelink_cc2640r2_latest/docs/blestack/ble_user_guide/html/ble-stack-3.x/overview.html?highlight=bluetooth%20link%20key#null
  3. TI Host Controller Interface (HCI) https://software-dl.ti.com/lprf/simplelink_cc2640r2_latest/docs/blestack/ble_user_guide/html/ble-stack-3.x/hci.html
  4. TI, Logical Link Control and Adaptation Layer Protocol (L2CAP) https://software-dl.ti.com/lprf/simplelink_cc2640r2_latest/docs/blestack/ble_user_guide/html/ble-stack-3.x/l2cap.html
  5. Apple Bluetooth security https://support.apple.com/guide/security/bluetooth-security-sec82597d97e/web
  6. Methods for Accessing a Link Key https://www.ellisys.com/technology/een_bt09.pdf
  7. Michelle Hampson Widespread Vulnerability Identified in Phones and Bluetooth Devices (2021-11-04) IEEE Spectrum https://spectrum.ieee.org/bluetooth-security