Hardware Reference
In-Depth Information
If no keys at all are exchanged during a bonding procedure, the bond
between the two devices will still be valid, but no security proce‐
dures whatsoever will be available between them.
Since each key is asymmetrical (and therefore the process of key distribution is sym‐
metrical) and thus each bond information stored between two devices can contain up
to two instances of each key (each peer having distributed its own), it's important to
note how keys distributed by each device are used in subsequent connections.
Table 2-2
details this usage based on the distributors and acceptors during the bonding procedure.
Table 2-2. Security Manager key usage
Key
Distributor Usage
Acceptor Usage
LTK, EDIV, Rand (Encryption)
Used to encrypt the link when a slave
Used to encrypt the link when a master
IRK, BD_ADDR (Privacy)
Used to generate resolvable private addresses
Used to resolve resolvable private addresses
CSRK (Signing)
Used to sign data
Used to verify signatures
As an example of a bonding with key distribution, let's assume that two devices, a tablet
acting as a master and a watch acting as a slave, perform a bonding procedure and
exchange encryption keys in both directions. The watch will distribute its own encryp‐
tion keys in the form of encryption information and master identification (let's call them
LTK_EDIV_Rand_watch
) and the tablet will do the same thing in the opposite direction
(
LTK_EDIV_Rand_tablet
).
After the bonding is complete, the link can be disconnected, and then the two devices
might want to reconnect and reuse those keys to reestablish a secure, encrypted con‐
nection without having to go through the bonding procedure again. If the devices re‐
connect in the same configuration as before, with the tablet acting as a master, then both
will use
LTK_EDIV_Rand_watch
to encrypt the link. If, later, the two reconnect with
switched roles (i.e., the watch is this time acting as the master and the table a slave),
LTK_EDIV_Rand_tablet
can then be used to encrypt the link.
Chapter 3
expands on these concepts in more detail.
Generic Attribute Profile (GATT)
The Generic Attribute Profile (GATT) builds on the Attribute Protocol (ATT) and adds
a hierarchy and data abstraction model on top of it. In a way, it can be considered the
backbone of BLE data transfer because it defines how data is organized and exchanged
between applications.
It defines generic data objects that can be used and reused by a variety of application
profiles (known as
GATT-based profiles
). It maintains the same client/server architec‐
