Bluetooth Service access control

BR/EDR

BLE

Bluetooth services have a number of permissions so that you can limit how you can interact with them, whether you need to authenticate first, whether you can read or write.

For each Bluetooth service exposed on a device, it is necessary to verify if access control has been implemented correctly.

This is because the standard is focused on interoperability, and there are services in which interoperability takes precedence and should allow access without authentication, as can be the case with the GATT profile service.

A device, due to the exchange of features (Feature Exchange), may have required encryption to establish the connection and access the GATT profile. However, since there are various types of encryption, it is possible that it may not provide a sufficient level of security to access a Service that requires higher protection. Similarly, it may happen that, to access certain functionalities exposed in a Service from the general attribute profile, it may be necessary to even raise the encryption level, moving from Phase 2 to Phase 3 of pairing in order to access said Service.

Therefore, it is important to verify the encryption configured for each security level implemented on the device.

Description

To perform this check a list of available devices must be elaborated. For further information on the topic check BSAM-SE-01 (Hidden Bluetooth SDP services) and BSAM-SE-02 (Hidden GATT Bluetooth services).

For each exposed service a check on what resources can be accessed and modified must be performed. This requires certain adaptation to conform to the protocols that expose the service. Some examples ilustrate this need:

  • For any GATT service it must be checked wether attributes can be read, written or notified depending on our level of security/authentication. For each result one must consider whether that access is adecuate or not for the data it exposes.
  • For each RFCOMM it must be checked wether an user can read or write to that service for each level of security available in that service. It must be evaluated if exposed data is adecuate for the security level and authentication.
  • For the SDP protocol it must be verified if it is desirable to obtain access to the service without authentication and/or encryption at Bluetooth level.
  • It is important to verify what functionalities of the SMP protocol can be accessed without authentication and/or encryption at Bluetooth level.

To check this control, the following resources may be useful:

ID Description
BSAM-SE-01 Hidden Bluetooth SDP services
BSAM-SE-02 Hidden GATT Bluetooth services

Other related documentation:

ID Description
Documentation Bluetooth LE connection mode

Example case

The correct configuration (read/write) of GATT services on a device with BLE connectivity will be tested. The tests will be carried out with a computer that will connect (without authorization, without authentication and without encryption) to the audited device. We will use Wireshark with BTVS (btvs.exe -Mode wireshark) to perform packet capture for analysis.

The GATT profile describes how data is exchanged with the profiles (Profile). In it, the Profile are defined, which group a set of services (Service). These Service, in turn, are composed of characteristics (Characteristic), and these Characteristic have descriptors (Descriptor).

Permissions to read, write or perform specific actions with each service and feature depends on authorization, authentication and encryption. These requirements (authorization, authentication and encryption) are device-specific and set by the device developer.

The Bluetooth driver internally lists the GATT services via the Handle or UUID field. The standard has limited the number of services, features and descriptors for a device to 65.535 (0xFFFF), equivalent to traversing from value 1 to 65.535 (0xFFFF) Handle values. To each Handle corresponds a UUID and vice versa. There is a list of UUIDs associated with a particular function in the Bluetooth SIG document Assigned Numbers.

The computer and the audited device will be connected and a Read and Write request will be made with Scapy, or some similar tool, for each Handle.The possible cases of response to a read / write request, according to the ATT protocol, will allow to know the configuration of each Handle.

The responses to a read request can be:

Read Response Meaning
Read Response The Handle is readable without permissions
Insufficient authorization error The Handle needs authorization to be read
Insufficient authentication error The Handle needs authentication to be read
Encryption key size too short error The Handle needs encryption with a longer password
Insufficient encryption error The Handle needs a higher encryption level (i.e., upgrade from Legacy to Secure pairing)
Invalid Handle error The Handle does not exist
Read not permitted error The Handle is not readable

The responses to a write request can be:

Write Response Meaning
Write Response Handle is writeable without permissions
Invalid length error The Handle is writeable but the length is incorrect
Insufficient authorization error You need to be authorized to write the Handle
Insufficient authentication error Authentication required to write the Handle
Encryption key size too short errro Longer key is needed to write in the Handle
Insufficient encryption error The Handle needs a higher encryption level (i.e., move from Legacy to Secure pairing)
Invalid Handle error The Handle does not exist
Write not permitted error The Handle cannot be written

Each configuration is checked for the device to ensure that it is correct by checking it against the Bluetooth SIG’s Assigned Numbers document with the NIST Bluetooth Security Guide.

The check control FAIL when a Handle has the incorrect permissions for the type of operation assigned based on the device type per NIST specifications.

  • Bluetooth Core V5.3, Vol. 3, Part H, Section 2 SECURITY MANAGER
  • Bluetooth Core V5.3, Vol. 3, Part H, Section 2.1 INTRODUCTION
  • Bluetooth Core V5.3, Vol. 3, Part H, Section 3 SECURITY MANAGER PROTOCOL
  • Bluetooth Core V5.3, Vol. 3, Part H, Section 3.6 SECURITY IN BLUETOOTH LOW ENERGY