所有的 Bluetooth 設備地址 (BD_ADDR) 雖然都固定為 48-bit，但是它們細分下來卻有 5 種。下面將分別討論這 5 種 BD_ADDR。
BR/EDR 設備地址
在 BR/EDR (Basic Rate/Enhanced Data Rate) 的世界中，每個設備的 BD_ADDR 都應該是唯一的。其格式符合 EUI-48 規範：
<code>MSBitLSBit+-----------------+| EUI-48|+-----------------+| OUI |||-----------|-----|| NAP | UAP | LAP ||-----|-----------||| SAP | |-----|-----------||2 B |1 B |3 B |+-----------------+/<code>
先簡單說明上面的部分字段：
- OUI, Organization Unique Identifier該字段被 IEEE 管理，由 NAP + UAP 組成，用於標識藍牙設備的廠商。
- NAP, Non-significant Address PartBaseband 定義的 FHS (Frequency Hop Synchronization) packet 會攜帶 NAP。這個 packet 主要用於在 piconet 信道建立之前或是切換 piconet 時，同步設備間的跳頻：
- UAP, Upper Address Part一些 BR/EDR baseband 定義的重要算法需要 UAP 的參與，比如自適應跳頻選擇算法的輸入值之一就有 UAP（也有 LAP）：
- SAP, Significant Address PartUAP 與 LAP 組成了與 NAP 對立的字段 SAP。
下面單獨說明 LAP 字段。
LAP
LAP (Lower Address Part) 由廠商分配給自己生產的設備。不過在 LAP 的值域中，有 64 個值被保留使用，它們是 0x9E8B00-0x9E8B3F。
BR/EDR 設備在不同的 link controller 狀態中傳輸 baseband packet 時，將攜帶不同的 access code。LAP 則會參與這些 access code 的計算。Link controller 狀態機如下：
當設備處於 page, page scan 以及 page response 狀態時，baseband 上傳輸的 packet 將攜帶 DAC (Device Access Code)。該值的計算需要被 page 設備的 BD_ADDR 參與（相當於 LAP 需要參與）。
當設備處於 connection, synchronization train 以及 synchronization scan 狀態時，baseband 上傳輸的 packet 將攜帶 CAC (Channel Access Code)。該值的計算需要 master 設備地址的 LAP 參與。
當設備處於 inquiry 狀態時，若使用 general inquiry，則 baseband 上傳輸的 packet 需要攜帶 GIAC (General Inquiry Access Code)。該值與 LAP 保留值 0x9e8b33 相關；若使用 dedicated inquiry，則 packet 需要攜帶 DIAC (Dedicated Inquiry Access Code)。該值與剩下的 63 個 LAP 保留值相關。
BLE 設備地址
在 BLE (Bluetooth Low Energy) 的世界中，設備地址有如下 4 種：
- Public Device Address
- Static Device Address
- Resolvable Private Address
- Non-resolvable Private Address
它們之間的關係如下：
Public Device Address
Public device address 與 static device address 同屬於 identity address。擁有 identity address 是使用 RPA (Resolvable Private Address) 的前提。
Public device address 大體遵循 BR/EDR device address 規範。唯一的不同是 public device address 可以無視 BR/EDR BD_ADDR 規範對 LAP 的限制，除非該地址同時作為 BR/EDR BD_ADDR 使用。
Static Devcie Address
Static devcie address 的格式如下。其中 random part 需至少有一個為 1 的 bit，也需至少有一個為 0 的 bit：
<code>MSBit48-bit LSBit+---------------------+|1|1| random part |+---------------------+/<code>
如果 BLE 設備使用 static device address，那麼在每次上電時它都應該生成一個新的 static device address。而且在一個上電週期中，該地址不應該被改變。Static device address 也有在設備出廠時被寫死的情況。在實際場景中，這種地址大概率上可以保證地址的唯一性，同時不像 public device address 需要花錢向 IEEE 購買。
作為遠端設備則無法區分一個設備地址是 static device address 還是 public device address。
Non-resolvable Private Address
這種類型的地址格式如下。其中 random part 中需至少有一個為 1 的 bit，也需至少有一個為 0 的 bit：
<code>MSBit48-bit LSBit+---------------------+|0|0| random part |+---------------------+/<code>
若 BLE 設備使用 non-resolvable private address，那麼它在每次連接時，都需要改變該地址。因此該地址隨機性更強，可以保護 BLE 設備的隱私，使其難以被追蹤，但同時也讓合法的設備難以自動識別自己。
Resolvable Private Address
Resolvable private address 是 BLE 設備實現隱私策略的關鍵。若僅使用 identity address，BLE 設備在 advertising 時可能被惡意追蹤。因為在一定程度上 identity address 是固定的；若使用 non-resolvable private address 又會導致地址隨機化太強，對應用造成不變。Resolvable private address 則可以很好地解決這些問題。其格式如下，其中有 hash = ah(IRK, prand)（IRK 在後面解釋）：
<code>MSBbit48-bit LSBbit+------------------------------+| prand 24-bit | hash ||---------------------|--------||0|1| random part |24-bit |+------------------------------+/<code>
要使用 resolvable private address 就需要引入 BLE pairing 的概念。當兩個 BLE 設備完成配對後，會交換存儲各自的 IRK (Identity Resolving Key) 和 identity address：
之後對端設備收到一個包含 RPA 的 advertising PDU 後，會嘗試使用本地存儲的 IRK (peer IRK) 計算 localHash = ah(IRK, prand)（其中 prand 從 RPA 中提取），然後將結果 localHash 與 RPA 中包含的 hash 比對。如果兩者相同，那麼地址解析成功。之後再找到與 peer IRK 對應的 peer device identity address 就可發起連接。
雖然 resolvable private address 也經常發生變化，但結合解析機制後，可以讓受信的設備自動識別並連接自己。
插曲：BlueZ 定義的 bdaddr_t 類型
BlueZ 為 BD_ADDR 定義了專門的類型 bdaddr_t，並提供了將字符串形式的 BD_ADDR 轉為 bdaddr_t 的函數 str2ba：
<code>#include<bluetooth>bdaddr_t bdaddr;str2ba("11:22:33:44:55:66",&bdaddr);/<bluetooth>/<code>References
- BLE v4.2: Creating Faster, More Secure, Power-Efficient Designs—Part 2
- 1.2 BLUETOOTH DEVICE ADDRESSING, BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 2, Part B page 416
- 藍牙協議分析(6)_BLE地址類型
- Bluetooth: Defining NAP + UAP + LAP
- An Overview of Addressing and Privacy for Laird’s BLE Modules
- 5.4.5 Privacy feature, BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 1, Part A page 278
HatLab知識星球
閱讀更多 E安全 的文章
