啟動配置流程包括五個階段：

1、發送Beacon信號

2、邀請

3、交換公共密鑰

4、認證

5、啟動配置數據分發

1、發送Beacon信號：如果未經啟動配置的設備支持PB-ADV承載層，則其作為未經啟動配置設備Beacon進行廣播；如果使用的是PB-GATT承載層，則發送可連接的廣播數據包。這就向啟動配置設備（Provisioner）表明未經啟動配置的設備已做好準備，可進入啟動配置流程。

2、邀請：啟動配置設備（Provisioner）邀請未經啟動配置的設備發送自身啟動配置功能信息。

3、交換公共密鑰：在此階段，根據未經啟動配置設備的功能，啟動配置設備（Provisioner）選擇合適的驗證方法，并通知未經啟動配置設備將要采取的方式。之后，啟動配置設備和未經啟動配置設備會創建一個橢圓曲線公私密鑰對并交換公鑰。然后，每臺設備使用自己的私鑰和對等設備的公鑰來計算對稱密鑰，即ECDHSecret。該密鑰用于驗證對端設備的身份。

本文將介紹啟動配置流程的后兩個階段：認證和啟動配置數據分發。

4、認證

在此步驟中，啟動配置設備使用所選的驗證方法，對未經啟動配置設備進行驗證。有三種可用的驗證方法（OOB， Out-Of-Band）：輸出OOB（Output OOB）、輸入OOB（Input OOB）、以及靜態OOB（Static OOB）或無OOB（No OOB）。

輸出帶外（Output OOB）

若選擇的是輸出帶外（Output OOB）驗證方法，則未經啟動配置設備會選擇一個隨機數，并通過與其功能兼容的方式輸出該數字。例如，如果未經啟動配置設備是一個燈泡，則它能夠閃爍指定的次數。如果設備具有LCD屏幕，則可以將隨機數顯示為多位數值。啟動配置設備（Provisioner）的用戶需要輸入觀察到的數字，來驗證未經啟動配置的設備。輸出帶外驗證方法的工作流程如圖1所示。

圖1 – 通過輸出OOB進行驗證

輸入隨機數后，啟動配置設備（Provisioner）生成并檢查確認值。無論采用哪種驗證方式，整個驗證步驟中的檢查確認值（check confirmation value）計算方式都是相同的，請繼續往下看。

輸入帶外（Input OOB）

輸入帶外（Input OOB）驗證方法與輸出帶外（Output OOB）方法類似，但設備的角色相反。啟動配置設備（Provisioner）生成并顯示隨機數，然后提示用戶采取適當的操作，將隨機數輸入未經啟動配置的設備。以照明開關為例，用戶可以在一定時間內數次按下按鈕，以這種形式輸入隨機數。

與輸出帶外驗證（Output OOB）相比，輸入帶外（Input OOB）方法需要發送一個附加的啟動配置協議PDU。在完成認證操作之后，未經啟動配置的設備向啟動配置設備發送一個啟動配置輸入完成PDU（Provisioning Input Complete PDU），通知其隨機數已輸入完成。隨后進入到執行檢查確認值操作的步驟。

圖 2 – 通過輸入OOB進行驗證

靜態帶外（Static OOB） 或無帶外（No OOB）

在輸入帶外或輸出帶外都不可用的情況下，啟動配置設備（Provisioner）和未經啟動配置的設備可采用靜態帶外（Static OOB）驗證或無帶外（No OOB）驗證：采用靜態OOB信息；或靜態OOB信息不可用，直接以數值0代替。在此情況下，啟動配置設備和未經啟動配置的設備各自生成一個隨機數，然后進行檢查確認值操作。

檢查確認值（Check Confirmation Value）

無論采用何種驗證方法，都會進行確認值生成和檢查。根據藍牙mesh規格，啟動配置設備（Provisioner） 和未經啟動配置設備應分別計算確認值。這兩個值被稱為ConfirmationProvisioner和ConfirmationDevice。這兩個值的計算都使用一系列相同的函數，不同之處僅在于所使用的隨機數輸入。

藍牙mesh規格中有兩頁關于計算過程的內容說明。確認值生成函數需要8個參數，參數值來自啟動配置（Provisioning）過程中的后續步驟。可參考規格的5.4.2.4認證和5.4.1啟動配置PDU部分，了解更多詳細信息。（詳見： ）

表1列出了用于確認值生成及其來源的參數。

表1 - 用于確認值計算的參數

讓我們來看看用于確認值生成的算法。圖3是一個流程圖，其中包括了幾輪AES-CMAC和SALT生成［1］。該流程圖對于ConfirmationProvisioner和ConfirmationDevice值均適用。

如果由啟動配置設備（Provisioner）執行輸入，則從一個名為RandomProvisioner的值開始（下圖中以藍色表示），并生成ConfirmationProvisioner值。

如果由未經啟動配置設備執行輸入，則從一個名為RandomDevice的值開始（下圖中以綠色表示），并生成ConfirmationDevice值。

圖 3 – 確認值生成圖

確認值檢查（Confirmation Value Check）

當確認值生成之后，兩臺設備就會進行交換，并且都會檢查接收值的完整性。圖4表示確認值檢查的過程。

確認過程的開始就是啟動配置設備（Provisioner）將其隨機數RandomProvisioner發送到未經啟動配置的設備。未經啟動配置設備使用它來重新計算確認值，并與之前接收的確認值進行比較，進行驗證。

圖 4 –確認值檢查

如果由未經啟動配置設備計算所得的確認值與接收到的ConfirmationProvisioner不匹配，則啟動配置（Provisioning）過程將被中止。

如果由未經啟動配置設備計算所得的確認值與接收到的ConfirmationProvisioner匹配，則未經啟動配置設備將其RandomDevice值發送給啟動配置設備。

然后，啟動配置設備（Provisioner） 使用相同的過程來重新計算確認值，并通過比較計算所得值與先前接收值來進行驗證。

如果由啟動配置設備（Provisioner） 計算所得的確認值與接收到的ConfirmationDevice不匹配，則啟動配置（Provisioning）流程將被中止。

如果由啟動配置設備（Provisioner） 計算所得的確認值與接收到的ConfirmationDevice匹配，則表示驗證成功。后續只要啟動配置設備（Provisioner）和未經啟動配置設備完成啟動配置流程的第五步：啟動配置數據分發，則未經啟動配置設備就能成為藍牙mesh網絡中的節點（node）。

5、啟動配置數據分發

認證步驟完成之后，就可以確保在啟動配置設備（Provisioner）和未經啟動配置設備之間建立的承載層的安全，然后就進入啟動配置（Provisioning）過程中最重要的一步：導出并分發啟動配置數據（provisioning data）。啟動配置設備（Provisioner） 負責生成啟動配置數據，啟動配置數據由多個數據項組成，包括一個稱為網絡密鑰 （NetKey） 的安全密鑰。表2列出了啟動配置數據字段。

表 2 – 啟動配置數據（provisioning data）

為安全地進行啟動配置數據分發，啟動配置設備（Provisioner）采用AES-CCM ［2］，借助共享的會話密鑰（SessionKey）對啟動配置數據（provisioning data）進行加密，啟動配置設備和未經啟動配置設備都會進行計算。 AES-CCM需要三個輸入參數：會話密鑰、會話隨機數和純文本。純文本參數值包含需要被加密的啟動配置數據。設備密鑰（DevKey）、會話密鑰（SessionKey）和會話隨機數（SessionNonce）的值通過圖5所示的過程導出。

圖5 - DevKey / SessionKey / SessionNonce生成過程

從圖5可以看出：

如果將prsk（綠色）的輸入值代入k1函數中，則會生成SessionKey。這是用于啟動配置數據加密的關鍵。

如果將prsn（黃色）的輸入值代入k1函數中，將生成SessionNonce。這是用于啟動配置數據加密的隨機值。

如果將prdk（藍色）的輸入值代入k1函數，則將生成DevKey。

啟動配置設備（Provisioner）和未經啟動配置設備都需要生成會話密鑰（SessionKey）和會話隨機數（SessionNonce）。當SessionKey和SessionNonce值準備就緒時，啟動配置設備將對包含導出啟動配置數據的啟動配置數據PDU （Provisioning Date PDU） 進行加密，并將其發送至未經啟動配置的設備。此處，相同的SessionKey和SessionNonce值也可用來對接收到的數據進行解密。

至此，啟動配置流程完成。兩臺對等設備都已知曉新的設備密鑰（DevKey）和全網的網絡密鑰（NetKey），這就意味著我們的新設備已成為藍牙mesh網絡中的節點（node）和成員。

開發mesh

啟動配置過程是藍牙mesh安全的基礎，讓網絡設備之間能夠可靠安全地進行通信。