Page 515 - From GMS to LTE

Bluetooth and Bluetooth Low Energy 501

Bluetooth, similar options exist to perform initial mutual authentication (e.g. checking
PINs on both devices) and to exchange the initial keying material in a secure manner.
As will be discussed shortly in more detail, each attribute that can be read or written
can have its own security and privacy settings. If a connection does not fulfill this
requirement the SMP and GAP layers will be invoked to increase the security and pri-
vacy level as required. If this is not possible, e.g. because bonding has not been per-
formed, access to the attribute will fail. The following security levels are defined for BLE:
Security Mode 1:
Level 1 (no security, not encrypted)
●
Level 2 (unauthenticated encryption)
●
Level 3 (authenticated encryption)
●
Security Mode 2:
Level 1 (unauthenticated data signing)
●
Level 2 (authenticated data signing)
●
A major privacy shortcoming of Wi‐Fi and ‘classic’ Bluetooth today is the use of static
Medium Access (MAC) addresses, which are sent over the air in the clear. This enables
passive observers to track devices. To protect against such tracking, an advertising device
can hide its public Bluetooth address by using a temporary and seemingly random address.
This address can only be mapped to a specific device by a scanning device that has previ-
ously bonded with the device and exchanged an identity‐resolving key (IRK) that is required
to map the received temporary address to the device’s permanent Bluetooth address.

7.7.5 BLE ATT and GATT
Once a connection between a BLE master and a BLE slave device has been established,
user data can be exchanged. Unlike in ‘classic’ Bluetooth or Wi‐Fi, the aim of BLE is not
to establish a transparent channel for data transfer. Instead, BLE has been designed to
transfer small amounts of data as power efficiently as possible. Therefore, data transfer
in BLE is organized in a fashion that programmers would recognize as reading and
writing to variables. In BLE, these variables are referred to as attributes. Consequently,
the transport protocol to read or write attributes is referred to as the Attribute Protocol
(ATT), which is further structured by the Generic Attribute Protocol (GATT) at the
highest layer of the BLE protocol stack. While ATT is responsible for the data transfer,
GATT structures the data exchange, as follows.
In most scenarios there is usually one side that acts as a GATT client and requests to
read or write to an attribute on a remote device referred to as a GATT server. It is also
possible, however, that both sides act as GATT client and server at the same time so
each device can request and modify data on the other device.
Furthermore, the GATT specification defines usage profiles in a similar way to ‘classic’
Bluetooth. Examples of specified BLE profiles are ‘Battery Service’, ‘Current Time Service’,
‘Health Thermometer Profile’, ‘Heart Rate Profile’, ‘HID over GATT’, ‘Proximity Profile’,
‘Phone Alert Service’, and there are many more [27]. In other words, a GATT profile groups
conceptually related attributes (variables) and defines the format of their content and how
they can be identified and accessed. A GATT server can and often does implement several
of these profiles simultaneously. It is also common that BLE devices implement non‐stand-
ardized services. The advantage of standardized profiles is interoperability.