藍芽協議分析(9)_BLE安全機制之LL Privacy
- 前言
在上一篇文章[1]中，我們介紹了BLE的白名單機制，這是一種通過地址進行簡單的訪問控制的安全機制。同時我們也提到了，這種安全機制只防君子，不防小人，試想這樣一種場景：
A裝置表示只信任B、C、D裝置，因此就把它們的地址加入到了自己的白名單中，表示只願意和它們溝通。與此同時，E裝置對它們的溝通非常感興趣，但A對自己不信任啊，腫麼辦？
E眼珠子一轉，想出一個壞主意：把自己的地址偽裝成成B、C、D中任意一個（這個還是很容易辦到的，隨便掃描一下就得它們的地址了）就行了，嘿嘿嘿！
那麼問題來了，怎麼擺脫“小人E“的偷聽呢？不著急，我們還有手段：“鏈路層的Privacy（隱私）機制”。
- 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]”，本文將會直接使用。
- 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]時：
如果有AdvA需要填充，則判斷Resolving List是否有非0的Local IRK，如果有，則使用Local IRK將Identity Address加密為Resolvable Private Address，填充到AdvA中。否則，直接填充Identity Address；
同理，如果有InitA需要填充，則判斷Resolving List是否有匹配的、非0的Peer IRK，如果有，則使用Peer IRK將對端的Identity Address加密為Resolvable Private Address，填充到InitA中。否則，直接填充Identity Address。
接收資料包時：
如果資料包中的AdvA或者InitA為普通的Identity Address，則直接做後續的處理；
如果它們為Resolvable Private Address，則會遍歷Resolving List中所有的“IRK | Identity Address”條目，使用IRK解出Identity Address和條目中的對比，如果匹配，則地址解析成功，可以做進一步處理。如果不匹配，且使能了白名單/LL Privacy策略，則會直接丟棄。
5）需要重點說明的是，Controller和Host之間所有的事件互動（除了Resolving List操作之外），均使用Identity Address。也就是說，裝置地址的加密、解密、比對等操作，都是在controller中完成的，對上層實體（HCI之上）是透明的。
- 使用場景說明
結合上面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。
-
和LL Privacy有關的HCI命令
不太想寫了，需要了解的直接去掰spec吧。 -
參考文件
[1] 藍芽協議分析(8)_BLE安全機制之白名單
[2] 藍芽協議分析(6)_BLE地址型別
[3] 藍芽協議分析(5)_BLE廣播通訊相關的技術分析
轉自 蝸窩科技，www.wowotech.net