Bluetooth Service access control

BR/EDR

BLE

Bluetooth services define the permissions that regulate how a device can interact with them, including whether authentication is required and whether read or write operations are allowed. For each exposed service, it is necessary to verify that access control has been correctly implemented.

Because the Bluetooth standard prioritizes interoperability, some services, such as those defined under the GATT profile, may allow access without authentication. In addition, depending on the Feature Exchange during connection setup, a device may require encryption to access certain services. However, not all encryption levels provide the same degree of protection. Some services may require raising the encryption level (e.g., transitioning from Phase 2 to Phase 3 of pairing) before access is granted.

Therefore, it is essential to verify that each service is protected according to its security requirements and that the configured encryption level is appropriate for the sensitivity of the functionality it exposes.

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