1. 前言
在上一篇文章[1]中，我們介紹了BLE的白名單機制，這是一種通過地址進行簡單的訪問控制的安全機制。同時我們也提到了，這種安全機制只防君子，不防小人，試想這樣一種場景：
| A設備表示只信任B、C、D設備，因此就把它們的地址加入到了自己的白名單中，表示只願意和它們溝通。與此同時，E設備對它們的溝通非常感興趣，但A對自己不信任啊，腫么辦？ E眼珠子一轉，想出一個壞主意：把自己的地址偽裝成成B、C、D中任意一個（這個還是很容易辦到的，隨便掃描一下就得它們的地址了）就行了，嘿嘿嘿！ |
那么問題來了，怎么擺脫“小人E“的偷聽呢？不着急，我們還有手段：“鏈路層的Privacy（隱私）機制”。
2. LL Privacy機制介紹
總結來說，LL Privacy機制是白名單（white list）機制的進階和加強，它在白名單的基礎上，將設備地址轉變成Private addresses[2]地址，以降低“小人E“竊得設備地址進而進行偽裝的概率。
從白名單的角度看，Non-resolvable private address和Public Device Address/Static Device Address沒有任何區別，因此LL Privacy機制主要指Resolvable Private Addresses。因此，LL Privacy機制的本質是：
| 通過Resolvable Private Addresses，將在空中傳輸的設備地址加密，讓“小人E”無法竊得，從而增加其偽裝的難度。 |
注1：當然，LL Privacy機制可以脫離白名單機制單獨使用，不過這樣的話好像沒什么威力。
注2：有關Resolvable Private Addresses、Identity Address、IRK（Local/Peer IRK）等概念的詳細介紹，可參考“藍牙協議分析(6)_BLE地址類型[2]”，本文將會直接使用。
3. Resolving List
和白名單機制上的White List類似，如果設備需要使用LL Privacy機制，則需要在Controller端保存一個Resolving List，其思路為：
1）BLE設備要按照[1]中的介紹，配置並使能白名單機制，把那些受信任設備的地址（這里為Identity Address）加入到自己的白名單中，並采用合適的白名單策略。
2）如果設備需要使用LL Privacy策略，保護自己（以及對方）的地址不被竊取，則需要將自己（local）和對方（peer）的地址和加密key保存在一個稱作Resolving List的列表中。
3）Resolving List的每一個條目，都保存了一對BLE設備的key/address信息，其格式為：Local IRK | Peer IRK | Peer Device Identity Address | Address Type。
| Local IRK，本地的IRK，用於將本地設備的Identity Address轉換為Resolvable Private Address。可以為0，表示本地地址直接使用Identity Address； Peer IRK，對端的IRK，用於將對端設備的Resolvable Private Address解析回Identity Address。可以為零，表示對端地址是Identity Address； Peer Device Identity Address、Address Type，對端設備的Identity Address及類型，用於和解析回的Identity Address進行比對。 |
4）Resolving List是Host通過HCI命令提供給Controller的，Controller的LL負責如下事項：
| 發送數據包[3]時： 接收數據包時： |
5）需要重點說明的是，Controller和Host之間所有的事件交互（除了Resolving List操作之外），均使用Identity Address。也就是說，設備地址的加密、解密、比對等操作，都是在controller中完成的，對上層實體（HCI之上）是透明的。
4. 使用場景說明
結合上面2章的解釋，羅列一下LL Privacy策略有關的使用場景（大部分翻譯自藍牙spec）。
4.1 設備處於廣播狀態（Advertising state）時
由[3]中的介紹可知，處於廣播狀態的BLE設備，根據需要可發送ADV_IND、ADV_DIRECT_IND、ADV_NONCONN_IND和ADV_SCAN_IND 4種類型的廣播包，也就是說有4種不同的廣播狀態，它們的LL privacy策略有稍微的不同，下面分別描述。
1）ADV_IND
設備（Advertiser）發送ADV_IND時，其PDU（connectable undirected advertising event PDU）有一個AdvA字段，該字段的填充策略為（由controller的LL執行）：
| 檢查Resolving List，查看是否存在非0的Local IRK條目，如果有，則使用Local IRK將自己的Identity Address加密為Resolvable Private Addresses，並填充到AdvA中。否則，直接使用Identity Address。 |
Advertiser收到連接請求時，請求者的地址會包含在PDU的InitA中，該字段的解析策略為（由controller的LL執行）：
| 如果InitA是Resolvable Private Addresses，且當前使能了地址解析功能，LL會遍歷Resolving List中所有的“Peer IRK | Peer Device Identity Address | Address Type”條目，使用Peer IRK解析出Identity Address后和Peer Device Identity Address做比對，如果匹配，則解析成功，再基於具體的白名單策略，覺得是否接受連接； 如果解析不成功，則無法建立連接； 如果InitA不是Resolvable Private Addresses，則走正常的連接過程。 |
Advertiser收到掃描請求時，對ScanA的處理策略，和InitA類似。
2）ADV_DIRECT_IND
設備（Advertiser）發送ADV_DIRECT_IND 時，其PDU（connectable directed advertising event PDU）包含AdvA和InitA兩個地址，它們填充策略為（由controller的LL執行）：
| 檢查Resolving List，查看是否存在非0的Local IRK條目，如果有，則使用Local IRK將自己的Identity Address加密為Resolvable Private Addresses，並填充到AdvA中。否則，直接使用Identity Address； 檢查Resolving List，查看是否存在非0、和InitA的Identity Address匹配的Peer IRK條目，如果有，則使用Peer IRK將InitA的Identity Address加密為Resolvable Private Addresses，並填充到InitA中。否則，直接使用Identity Address。 |
Advertiser收到連接請求時，請求者的地址會包含在PDU的InitA中，該字段的解析策略為和上面ADV_IND類似，不再詳細說明。
3）ADV_NONCONN_IND and ADV_SCAN_IND
這兩個狀態下，AdvA的填充策略和上面1）和2）一樣，不再詳細說明。
當Advertiser收到SCAN請求時，對ScanA的處理策略，和1）中InitA類似，不再詳細說明。
4.2 設備處於掃描狀態（Scanning state）時
處於Scanning狀態的設備（Scanner）在接收到Advertiser發送的scannable的廣播包時，需要按照4.1中解析InitA的方法，解析廣播包中的AdvA，並根據當前的白名單策略，進行過濾。
Scanner發送scan請求時，需要指定ScanA和AdvA兩個地址。其實ScanA的填充策略和4.1中的AdvA類似，不再詳細說明。而AdvA，需要和接收到的廣播包的AdvA完全一樣，不能有改動。
4.3 設備處於連接狀態（Initiating state）時
處於Initiating狀態的設備（Initiator）在接收到Advertising發送的connectable的廣播包時，需要按照4.1中解析InitA的方法，解析廣播包中的AdvA，並根據當前的白名單策略，進行過濾。
同理，Initiator發送連接請求時，需要指定InitA和AdvA兩個地址。其實InitA的填充策略和4.1中的AdvA類似，不再詳細說明。而AdvA，需要和接收到的廣播包的AdvA完全一樣，不能有改動。
最后，Initiator在接收到Advertising發送的directed connectable廣播包時，除了要解析AdvA，如果InitA是Resolvable Private Addresses，則需要使用Local IRK解析InitA。
5. 和LL Privacy有關的HCI命令
不太想寫了，需要了解的直接去掰spec吧。
6. 參考文檔
[1] 藍牙協議分析(8)_BLE安全機制之白名單
[2] 藍牙協議分析(6)_BLE地址類型
[3] 藍牙協議分析(5)_BLE廣播通信相關的技術分析
原創文章，轉發處蝸窩科技，www.wowotech.net。