Hardware Reference
In-Depth Information
relatively common practice to hold off until a GATT data access actually requires
a higher security mode than the one currently in force.
Authentication procedure
As mentioned in
“Authentication” on page 45
, the authentication procedure enfor‐
ces the transition to a security mode on a connection currently in a lower security
mode. This enforcement can come in the form of a pairing or bonding procedure
or, if encryption keys are already available and sufficiently authenticated on both
sides, in the form of an encryption procedure.
Authorization procedure
Authorization in BLE and GAP refers to giving the application and, ultimately, the
user the opportunity to accept or reject a particular transaction. This might take
the shape of an internal application check if the device does not have a user interface,
or if it does, it can ask the user for permission directly.
Encryption procedure
This procedure uses the Link Layer's built-in encryption capabilities to start the
encryption of all traffic over the current connection, as described in
“Connec‐
tions” on page 22
and
“Security Procedures” on page 29
. Although the central is the
only one able to initiate an encryption procedure, the peripheral can request the
central to do so by means of the
security request
mentioned in
“Security Manager
(SM)” on page 28
.
Although not strictly a mode or procedure, the
privacy
feature deserves a few words in
the section on GAP security. Privacy was one of the aspects of the BLE specification that
underwent a substantial modification between versions 4.0 and 4.1. The feature was
simplified and the specification text was adapted to reflect what implementations had
been using in practice for years, acommodating itself to the established status quo
among currently shipping devices.
This revision was named
Privacy 1.1
and was actually listed as a new feature in the 4.1
release, replacing the old privacy section. When using the privacy feature, a device
periodically generates a new resolvable private address (see
“Address Types” on page
44
) and sets it as its own. The only way for a peer to identify it is to resolve the address
using an IRK, because all resolvable private addresses are temporary in nature and it
makes no sense to store them permanently.
Instead, an IRK (see
“Security Keys” on page 31
) previously shared and stored by both
devices is used to generate the address in the device, protecting its identity and resolving
it on the device trying to identify it. This feature can be used in all GAP roles concur‐
rently and prevents malicious devices deprived of the shared IRK from identifying and
tracking a particular device using its Bluetooth device address.
