技術篇之藍牙Mesh設備是如何加入網絡中

概述

配網(Provisioning)流程屬於藍牙Mesh網絡中的重要一環,正是通過配網流程,才使得藍牙Mesh設備(Device)變成網絡中的一個節點(Node),因此,本文將着重講解配網流程及其相關概念,希望能夠給讀者以清晰的理解。

名詞解釋

  1. 設備(Device)表示處於未配網的實體。
  2. 節點(Node)表示當前已經處於配網狀態的實體。
  3. 配網者(Provisioner)表示具備將其他設備通過配網流程讓其成爲節點的功能的實體。

配網流程

1、設備發送PB-ADV的廣播

如果設備支持PB-ADV配網,也就是如果設備支持通過廣播方式配網的話,其必鬚髮送Unprovisioned Device Beacon,在筆者書寫時,遠程配網還未在正式規範中,因此配置者必須處在設備的廣播範圍內(Single Hop)。設備發送的Unprovisoned Device Beacon 包含該設備的UUID用於唯一標識該設備,包含設備的OOB信息用於描述公鑰傳輸方式,例如:NFC、二維碼等,包括可選的URI信息(用於標識設備,例設備的類型、圖像等),這些信息將在後續步驟中使用。

2、設備發送PB-GATT的廣播

如果設備支持PB-GATT配網,也就是說設備支持通過連接方式配網的話,其必鬚髮送可連接的廣播報文,其發送的廣播信息同樣包括了設備UUID以及設備的OOB信息。注意:如果設備同時支持兩種配網方式,必須交叉發送這兩種廣播報文。

3、配置者發送邀請

首先需要說清的時,只有收到的配網廣播類型與配置者支持PB-ADV或者PB-GATT方式配網能力一致才能進行,也就是說,只支持PB-GATT(大部分的智能手機就是這種)方式的配置者不能通過PB-ADV方式配網設備,即使配置者能夠收到PB-ADV的廣播,反之亦然。

配置者在收到相對應的未配置廣播後,會發送配置邀請(Provision Invite)讓設備進入配網狀態。但是由於PB-ADV與PB-GATT的數據傳輸方式不一致,因此通過PB-ADV方式的配網流程整體複雜度要高與通過連接方式的,限於篇幅,本文將不再詳述,感興趣的讀者自行看規範(Mesh Profile 1.0.1 Section 5 Provisioning)。

4、設備發送配置能力

設備端在收到來自配置者發送的配置邀請後,會將自身的輸入輸出能力通過配置能力(Provision Capability)發送給配置者作爲響應。這種描述設備的輸入輸出能力將會直接影響後續的配置流程。值得一提的是,配置能力包括設備端是否具備公鑰信息帶外傳輸能力(Public Key OOB Information),這種信息與設備在步驟1步驟2中發送的OOB相呼應,還包括設備是否支持靜態認證信息(Static OOB Information),也就是固定的認證值(雙方都必須對應一致的存放才能使用),還包括輸入輸出能力(Input Output OOB Information),最後包括一個描述設備中元素(Element)多少的信息,綜上,這些信息都將傳給配置者。

5、配置者發送配置開始

配置者在收到來自設備發送的配置能力後,需要根據自身與設備的輸入輸出能力決定合適的配置算法來進行安全的認證。例如:配置者會檢查設備與其自身是否都支持公鑰帶外傳輸能力,如果都支持,配置者可以選擇這種方式(OOB Public Key)進行公鑰傳輸,例如:通過二維碼掃描或者NFC讀取等,否則公鑰將通過配網流程(No OOB Public Key)傳輸(這種方式的安全級別當然低於上面的方式)。接着配置者會檢查雙方輸入輸出能力,如果設備支持輸入,配置者有能力輸出的話,可以使用方式(Input OOB authentication)進行安全認證,如果設備支持輸出,配置者有能力輸入的話,可以使用方式(Output OOB authentication)進行安全認證,如果設備支持靜態認證,配置者同樣支持靜態認證,可以使用方式(Static OOB authentication)進行安全認證。最後如果設備與配置者都沒有合適的輸入輸出相呼應,只能通過非安全認證(No OOB authentication)。

根據公鑰帶外傳輸能力,後續公鑰傳輸可以分爲

  1. A1 No OOB Public Key is used
  2. A2 OOB Public Key is used

根據輸入輸出能力,後續認證算法可以分爲:

  1. B1 No OOB authentication is used
  2. B2 Static OOB authentication is used
  3. B3 Output OOB authentication is used
  4. B4 Input OOB authentication is used

後續配置流程將根據配置者的選擇進行,可能存在的路線有:A1B1A1B2A1B3A1B4A2B1A2B2A2B3A2B4 A1B1、A1B2、A1B3、A1B4、A2B1、A2B2、A2B3、A2B4

6、配置者發送公鑰(A1)

如果配置者在步驟5選擇公鑰非帶外傳輸的話,那麼在配置者發送完配置開始後,緊跟着發送配置者公鑰(Provisoner Public Key)。注意:公鑰與私鑰應當在每次配網流程中都必須重新生成。

7、配置者發送公鑰(A2)

如果配置者在步驟5選擇公鑰帶外傳輸的話,其在發送配置開始後,必須通過步驟1步驟2中OOB信息所描述的方式(NFC、二維碼等)來獲取設備端公鑰(Device Public Key)。

8、設備發送公鑰(A1)

如果設備端在步驟5收到來自配置者選擇的公鑰非帶外傳輸後將執行此步驟,其必須等待步驟6配置者發送配置者公鑰後,發送設備公鑰(Provisioning Device Public Key)。

9、配置者發送確認值(B1、B2、B4)

當配置者在步驟6後,應該等待步驟8設備端公鑰,或者當配置者在步驟7後,開始執行生成隨機數(RandomProvisioner )並根據收到的來自設備端公鑰生成ECDHSecret
ECDHSecret=P256(privatekey,peerpublickey)ECDHSecret = P-256(private key, peer public key)

確認值(Confirm)的生成應根據:

如果配置者選擇的算法是非安全認證B1

AESCMACConfirmationKey(RandomProvisioner0x00)AES-CMACConfirmationKey (RandomProvisioner || 0x00)

如果配置者選擇的算法是靜態安全認證B2

AESCMACConfirmationKey(RandomProvisionerStaticKey)AES-CMACConfirmationKey (RandomProvisioner || Static Key)

如果配置者選擇的算法是輸出安全認證B4,配置者應當根據設備顯示的Auth Value

AESCMACConfirmationKey(RandomProvisionerAuthValue)AES-CMACConfirmationKey (RandomProvisioner || Auth Value)

10、配置者發送確認值(B3)

步驟6後,應該等待步驟8設備端公鑰,或者當配置者在步驟7後,開始執行生成隨機數(RandomProvisioner )以及隨機化(Auth Value)並通過步驟5協商的輸出方式輸出出來,並根據收到的來自設備端公鑰生成ECDHSecret
ECDHSecret=P256(privatekey,peerpublickey)ECDHSecret = P-256(private key, peer public key)

確認值(Confirm)的生成應根據:
AESCMACConfirmationKey(RandomProvisionerAuthValue)AES-CMACConfirmationKey (RandomProvisioner || Auth Value)

配置者應當等待來自步驟11的輸入完成(Provision Input Complete)後,發送確認值(Confirm)。

11、設備發送輸入完成(B3)

步驟6步驟7後,開始執行生成隨機數(RandomDevice)並根據收到的來自設備端公鑰生成ECDHSecret
ECDHSecret=P256(privatekey,peerpublickey)ECDHSecret = P-256(private key, peer public key)

設備端應當根據配置者顯示的Auth Value ,應當在設備端確認值生成後發送輸入完成,其中確認值(Confirm)的生成應根據:
AESCMACConfirmationKey(RandomDeviceAuthValue)AES-CMACConfirmationKey (RandomDevice || Auth Value)

12、設備發送確認值

設備端收到來自配置者的確認值後,應當發送設備端確認值。

13、配置者發送隨機數

配置者收到來自設備端的確認值後,應當發送配置者隨機數(RandomProvisioner)。

14、設備發送隨機數

設備端收到來自配置者的隨機數後,應當與之前收到的來自配置者確認值進行校驗,如果匹配,應當發送設備端隨機數(RandomDevice),並根據隨機數生成Device Key:
DevKey=k1(ECDHSecret,ProvisioningSalt,prdk)DevKey = k1(ECDHSecret, ProvisioningSalt, “prdk”)
其中 ProvisioningSalt應當:
ProvisioningSalt=s1(ConfirmationSaltRandomProvisionerRandomDevice)ProvisioningSalt = s1(ConfirmationSalt || RandomProvisioner || RandomDevice)

15、配置者發送配置數據

配置者收到來自設備端的隨機數後,應當與之前收到的來自設備端確認值進行校驗,如果匹配,應當發送配置數據(Provision Data)。

其中配置數據包括:

  1. Network Key 配置者分發的網絡層的密鑰。
  2. Network Index 配置者分發的網絡密鑰索引(其中0x0000爲主網,其餘爲次網)。
  3. Key Reflash Flag 當前的網絡密鑰更新狀態。
  4. IV Update Flag 當前的IV Index更新狀態。
  5. IV Index 當前的IV Index值。
  6. Primary Address 配置者分發給設備的主地址。

注意此數據包通過之前協商的數據進行加密:
ProvisioningSalt=s1(ConfirmationSaltRandomProvisionerRandomDevice)ProvisioningSalt = s1(ConfirmationSalt || RandomProvisioner || RandomDevice)
SessionKey=k1(ECDHSecret,ProvisioningSalt,prsk)SessionKey = k1(ECDHSecret, ProvisioningSalt, “prsk”)
SessionNonce=k1(ECDHSecret,ProvisioningSalt,prsn)SessionNonce = k1(ECDHSecret, ProvisioningSalt, “prsn”)

配置數據原始報文爲:
ProvisioningData=NetworkKeyKeyIndexFlagsIVIndexUnicastAddressProvisioning Data = Network Key || Key Index || Flags || IV Index || Unicast Address

加密後的數據應當爲:
AESCCM(SessionKey,SessionNonce,ProvisioningData)AES-CCM (SessionKey, SessionNonce,Provisioning Data)

16、設備發送配置完成

設備在收到來自配置者發送配置數據併成功解密後,應當發送配置完成(Provision Complete),至此,當前設備已經變成網絡中的一個節點。

藍牙技術中文社區

藍牙交流社區成立啦,不定期有技術乾貨出爐,歡迎各位一起討論展望未來物聯網的新格局。感興趣的可掃我二維碼加我好友,審覈後將拉進社區。
在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章