Advertising
BLE device broadcasts advertising packets to anyone listening nearby. (Typically provides basic information like name and services provided.)

Scanning
Complementary process to advertising -- BLE device actively listens for advertising packets in its vicinity

Connecting/Connected
Scanning device finds an advertising device it wants to interact with. This is a request to move from broadcast mode to a dedicated bidirectional channel.

Once connected, devices do not need to move on to pairing/bonding - it could be a temporary connection but next time you want to use that device you have to connect again manually.

Pairing
Process of exchanging security keys. Performed during or immediately after establishing connection for first time, typically involving user interaction (entering PIN or confirming passkey.)

Not useful without bonding / not a separate process. Need to stash the keys (bonding) to be able to re-use them in the future.

Bonding
Storing security keys obtained from pairing process. Allows re-establishing a secure connection without having to repeat the pairing process.

Must have completed pairing - we can't have the keys unless we complete the key exchange.

How is signing something different from encrypting something?
Digital signatures use asymmetric / public-key approach, where data is signed using author's private key and signature is distributed together with the data. Recipient can use the public key to verify signature, proving data came from the owner of the private key (message is authentic) and the data hasn't been altered since being signed (message integrity was maintained.)

Although encryption ensures confidentiality, it doesn't inherently guarantee authenticity/integrity.

How does BLE provide data signing (when not using encryption)?
BLE provides data signing via CSRK (Connection Signature Resolving Key). When device is ready to send data, it generates a signature with the CSRK and attaches to the data. Recipient uses the CSRK to generate their own signature for confirmation.

This mode is used to provide integrity/authentication when not using encryption.

How does BLE provide encryption (and also integrity/auth)?
Symmetric / shared-key approach / AES-128 key.
Plaintext message data is combined with the LTK by AES-CCM algorithm to produce ciphertext:
(1) Create unique key-stream (one-time-use) using the LTK, called a *nonce*. The nonce is a random / near random number which helps secure the encryption process.
(2) AES-CCM reads unencrypted packet in device RAM, encrypts it, and slaps a 4-byte Message Integrity Check (MIC) field onto the packet (and updates packet length to accommodate the new data.) (MIC supports integrity/authenticity).

On the receiving end, AES-CCM will take the encrypted packet, decrypt it, verify its MIC field (recalculate and compare what was sent) and reduce packet length by 4 bytes. (So to the application level it's as if the data was never encrypted?)

The encryption/decryption process is typically done on a per-packet basis.

Temporary & changeable Bluetooth Device Address, which is a privacy control to mitigate unauthorized tracking of a device over time based on its address. (BLE device broadcasts an address when in discoverable state - a static address could theoretically be tracked.)

Leverages the Identity Resolving Key (IRK), (yet another) 128-bit security key which is used to generate RPAs and resolve a device identity given its RPA.

The IRK is shared between devices during pairing/bonding. Devices store the IRK of other known devices that they trust, kept in a 'resolving list', which is a record set within the link layer of the device.

Device Identity Addresses
The device identity addresses is a unique, constant address which is either
(i) Public - assigned during manufacturing by chip manufacturer. Guaranteed to be globally unique
(ii) Static - randomly chosen but constant over device restarts - generated and stored (on first power up?)

Privacy Modes
- Network privacy mode:
    - Only accept advertising packets from devices on resolving list via RPA.
- Device privacy mode:
    - Only accept advertising packets from devices on resolving list. (Either static or an RPA that can be resolved.)
    - ie - Known devices only, but accepts static address

How are RPAs created and verified?
*prand* := pseudorandom

Hash is calculated based on *prand* and source IRK. Hash and *prand* are transmitted together. Target already has IRK from pairing, so it can iterate through its resolving list trying every IRK with the *prand* salt until something matches (or doesn't.)

(So not decrypting/decoding, but rather recalculating and comparing.)

Idea is that you can only figure out the true identity of a device based on its RPA if you are a 'trusted device'.

What is a Man-In-The-Middle (MITM) Attack?
Threat actor intercepts communication between two devices secretly, by capturing, potentially altering and retransmitting to make each party think they're communicating directly with the other.

eg during BLE pairing, threat actor could use a device to intercept advertising packets from IPG and the connection attempt from tablet, and could establish a connection with each quickly before the legitimate connections 'land.'

BLE Security Mode 1, Levels 1 & 2 don't protect against MITM - need levels 3&4 See Bluetooth Security Modes Summary

What compensating controls could mitigate MITM when using Security Level 2?
* OOB
    - proximity based (require close proximity to pair)
    * short window of time when pairing is allowed (reduce window of attack time)
    * design to only pair/bond with a specific device ID
* Derive a key for pairing based on some unique, immutable identifier

Sources:

• Understanding Bluetooth LE Pairing: Step-by-Step
• Understanding Security Keys in Bluetooth Low Energy
• Gemini 2.0 Flash filling in gaps