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:

IDDescription
BSAM-SE-01Hidden Bluetooth SDP services
BSAM-SE-02Hidden GATT Bluetooth services

Other related documentation:

IDDescription
DocumentationBluetooth 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 ResponseMeaning
Read ResponseThe Handle is readable without permissions
Insufficient authorization errorThe Handle needs authorization to be read
Insufficient authentication errorThe Handle needs authentication to be read
Encryption key size too short errorThe Handle needs encryption with a longer password
Insufficient encryption errorThe Handle needs a higher encryption level (i.e., upgrade from Legacy to Secure pairing)
Invalid Handle errorThe Handle does not exist
Read not permitted errorThe Handle is not readable

The responses to a write request can be:

Write ResponseMeaning
Write ResponseHandle is writeable without permissions
Invalid length errorThe Handle is writeable but the length is incorrect
Insufficient authorization errorYou need to be authorized to write the Handle
Insufficient authentication errorAuthentication required to write the Handle
Encryption key size too short errroLonger key is needed to write in the Handle
Insufficient encryption errorThe Handle needs a higher encryption level (i.e., move from Legacy to Secure pairing)
Invalid Handle errorThe Handle does not exist
Write not permitted errorThe 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