1.“配網(wǎng)”中的’網(wǎng)‘具體是什么

配網(wǎng)是將未配網(wǎng)設(shè)備加入網(wǎng)絡(luò)，使其成為網(wǎng)絡(luò)中的節(jié)點(diǎn)的過(guò)程。

1.1.未配網(wǎng)設(shè)備在程序中如何表示？

換句話說(shuō)，就是未配網(wǎng)設(shè)備的數(shù)據(jù)結(jié)構(gòu)是什么樣的？可能我們更感興趣的是為什么要選擇這樣的數(shù)據(jù)結(jié)構(gòu)？

在信標(biāo)階段，配網(wǎng)器上掃描到未配網(wǎng)設(shè)備，會(huì)記錄設(shè)備的藍(lán)牙對(duì)象信息，主要包括藍(lán)牙名，藍(lán)牙RSSI，和藍(lán)牙廣播數(shù)據(jù)。藍(lán)牙名和信號(hào)強(qiáng)度RSSI主要是做App內(nèi)顯示用，藍(lán)牙Mesh協(xié)議主要是根據(jù)藍(lán)牙廣播信息創(chuàng)建未配網(wǎng)設(shè)備（UnprovisionedDevice）類的對(duì)象。

在iOS App中，對(duì)未配網(wǎng)設(shè)備的進(jìn)行的封裝如下

//swift語(yǔ)言
typealias DiscoveredPeripheral = (
  device: UnprovisionedDevice,
  peripheral: CBPeripheral,
  rssi: Int
)

在App中，必須根據(jù)廣播數(shù)據(jù)創(chuàng)建 Unprovisioned Device 對(duì)象。 Mesh UUID 和 OOB 信息必須存在于廣播數(shù)據(jù)中，否則對(duì)象創(chuàng)建失敗，配網(wǎng)無(wú)法往下進(jìn)行。

未配網(wǎng)設(shè)備Beacon格式

這里必須得介紹一下未配網(wǎng)設(shè)備Beacon格式，mesh規(guī)范中定義如下：

未配網(wǎng)設(shè)備Beacon格式.png

未配網(wǎng)設(shè)備Beacon中OOB字段的含義：

未配網(wǎng)設(shè)備Beacon中OOB字段的含義.png

目前我司OOB Information的值均是0，未做其他研究。后面部分會(huì)寫《OOB在配網(wǎng)中到底影響的是什么》，知道了原理，任憑形式如何變化，都很容易解決，這里不再做更多解釋。

未配網(wǎng)設(shè)備（UnprovisionedDevice）類在iOS App中的屬性定義：

public var name: String?
public let uuid: UUID
public let oobInformation: OobInformation

未配網(wǎng)設(shè)備（UnprovisionedDevice）類中使用廣播數(shù)據(jù)的方式：

• 取廣播數(shù)據(jù)中服務(wù)為1827的ServiceData部分，得到的就是未配網(wǎng)設(shè)備Beacon。
• 在iOS端收到的數(shù)據(jù)長(zhǎng)度是18字節(jié)，系統(tǒng)層已經(jīng)將數(shù)據(jù)類型過(guò)濾。
• 前16個(gè)字節(jié)就是未配網(wǎng)設(shè)備的Device UUID。
• 后兩個(gè)字節(jié)就是OOB Information。

注意：在手機(jī)系統(tǒng)中，標(biāo)識(shí)一個(gè)藍(lán)牙設(shè)備的唯一性，安卓系統(tǒng)使用的MAC地址，在iOS上使用的是UUID。未配網(wǎng)設(shè)備的Device UUID來(lái)源于廣播數(shù)據(jù)，是在mesh網(wǎng)絡(luò)中使用，并不是手機(jī)系統(tǒng)給分配的標(biāo)識(shí)藍(lán)牙的UUID。

1.2.節(jié)點(diǎn)在程序中如何表示？

上面未配網(wǎng)設(shè)備的數(shù)據(jù)結(jié)構(gòu)是配網(wǎng)前的數(shù)據(jù)。這小節(jié)是在配網(wǎng)后，節(jié)點(diǎn)應(yīng)該包含哪些信息。

根據(jù)角色劃分，網(wǎng)絡(luò)中有兩種節(jié)點(diǎn)：配網(wǎng)器節(jié)點(diǎn)和設(shè)備節(jié)點(diǎn)。配網(wǎng)器節(jié)點(diǎn)是配網(wǎng)器在啟動(dòng)時(shí)自動(dòng)創(chuàng)建。

我們可以通過(guò)App端的導(dǎo)出mesh網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行分析。在這里不對(duì)節(jié)點(diǎn)中每個(gè)字段含義做過(guò)多解釋。

設(shè)備節(jié)點(diǎn)在持久化儲(chǔ)存時(shí)的數(shù)據(jù)結(jié)構(gòu)：

1.2設(shè)備節(jié)點(diǎn).png

appkeys`：節(jié)點(diǎn)的應(yīng)用秘鑰信息。

cid：company id，節(jié)點(diǎn)所用的藍(lán)牙芯片公司，在Sig注冊(cè)的標(biāo)識(shí)符。比如：奉加微的cid是0x0504，對(duì)應(yīng)的公司名是PHYPLUS Inc。

configComplete：節(jié)點(diǎn)的配置是否完成。

crpl：設(shè)備中重放保護(hù)列表項(xiàng)的最小數(shù)量。

defaultTTL：消息在網(wǎng)絡(luò)中的轉(zhuǎn)發(fā)次數(shù)。

deviceKey：設(shè)備密鑰。

elements：節(jié)點(diǎn)的元素。

excluded：密鑰刷新時(shí)，是否已將該設(shè)備排除。

name：節(jié)點(diǎn)名稱，來(lái)自于掃描時(shí)的未配網(wǎng)設(shè)備，也可以修改。

netKeys：網(wǎng)絡(luò)密鑰。

pid：product id，產(chǎn)品ID。

security：節(jié)點(diǎn)的安全等級(jí)。

unicastAddress：節(jié)點(diǎn)單播地址。

UUID：節(jié)點(diǎn)唯一標(biāo)識(shí)。

vid：version id，節(jié)點(diǎn)的版本號(hào)。

1.3.mesh網(wǎng)絡(luò)在程序中如何表示？

在配網(wǎng)器端第一次打開(kāi)APP時(shí)，會(huì)創(chuàng)建一個(gè)網(wǎng)絡(luò)，并持久化儲(chǔ)存這個(gè)網(wǎng)絡(luò)到本地?cái)?shù)據(jù)。這個(gè)本地網(wǎng)絡(luò)數(shù)據(jù)在之后的APP啟動(dòng)時(shí)，都會(huì)重新加載到內(nèi)存。每一個(gè)設(shè)備的加入或者其它密鑰的添加與修改，都會(huì)在一個(gè)操作流程處理完后，立刻保存到本地網(wǎng)絡(luò)數(shù)據(jù)。

1.3 mesh網(wǎng)絡(luò)在程序中的表示.png

appKeys：應(yīng)用程序密鑰。應(yīng)用與上層傳輸層的安全通信。

groups：分組信息。將多個(gè)節(jié)點(diǎn)統(tǒng)一管理，可根據(jù)場(chǎng)景自行設(shè)置。比如將客廳的幾個(gè)燈放在一組，實(shí)現(xiàn)同時(shí)開(kāi)關(guān)燈。

meshName：網(wǎng)絡(luò)名稱。

meshUUID：每個(gè)網(wǎng)絡(luò)的唯一標(biāo)識(shí)符，程序自動(dòng)生成的加密隨機(jī)數(shù)。在網(wǎng)絡(luò)導(dǎo)入時(shí)，可能不是本網(wǎng)絡(luò)的信息，所以需要通過(guò)這個(gè)唯一標(biāo)識(shí)符進(jìn)行過(guò)濾。

netKeys：網(wǎng)絡(luò)密鑰。應(yīng)用于網(wǎng)絡(luò)層的安全通信。

nodes：節(jié)點(diǎn)。

Provisioners：配網(wǎng)器。

scenes：場(chǎng)景。

2.配網(wǎng)流程通信數(shù)據(jù)分析

配網(wǎng)整個(gè)流程.png

2.1信標(biāo)階段

信標(biāo)階段再細(xì)分為兩個(gè)部分。

• 在App中掃描到設(shè)備后，只做顯示，并不會(huì)直接去連接設(shè)備，需要用戶選擇想配網(wǎng)的設(shè)備后，進(jìn)行連接。
• 但在我司gateway方式中，掃描到設(shè)備便會(huì)進(jìn)行連接，實(shí)現(xiàn)自動(dòng)配網(wǎng)。

2.1.1廣播階段

未配網(wǎng)設(shè)備端向周圍發(fā)送廣播，配網(wǎng)器在接收到掃描信息后將未配網(wǎng)設(shè)備的name、meshUUID、oobInformation以及藍(lán)牙對(duì)象保存內(nèi)存?？梢詤⒖?.1。

2.1.2連接階段

這個(gè)階段就是BLE常規(guī)操作：連接，發(fā)現(xiàn)服務(wù)、發(fā)現(xiàn)特性，打開(kāi)特性通知。

在配網(wǎng)器上，需要對(duì)服務(wù)和特性做確認(rèn)，判斷連接的設(shè)備是否具備mesh中需要用到數(shù)據(jù)寫入寫出特性。

配網(wǎng)協(xié)議使用的服務(wù)是1827。

數(shù)據(jù)寫入特性：2ADB。

數(shù)據(jù)寫出特性：2ADC。

用變量記錄寫這些特性，方便在數(shù)據(jù)寫入寫出時(shí)做比較。

這個(gè)部分就是配網(wǎng)承載器中的GATT承載器，手機(jī)端僅支持GATT承載器這一種。

2.2邀請(qǐng)階段

信標(biāo)階段的設(shè)備連接，和邀請(qǐng)階段，是一個(gè)步驟完成。當(dāng)連接設(shè)備完成，打開(kāi)特性通知成功時(shí)，被視為承載器準(zhǔn)備就緒，可以發(fā)送邀請(qǐng)數(shù)據(jù)。上文《配網(wǎng)協(xié)議》->《配網(wǎng)PDU》->《配網(wǎng)邀請(qǐng)》對(duì)這個(gè)指令有詳細(xì)解釋。這個(gè)階段的數(shù)據(jù)是明文。

我司Attention Duration的值默認(rèn)是5秒。

配網(wǎng)器發(fā)送配網(wǎng)邀請(qǐng)指令：0x030005

設(shè)備端返回配網(wǎng)能力給APP端指令：0x03010100010000000000000000

我司目前設(shè)備端返回的設(shè)備能力，代表的意思如下：

Device Capabilities:
  Number of elements: 1
  Algorithms: FIPS P-256 Elliptic Curve
  Public Key Type: None
  Static OOB Type: None
  Output OOB Size: 0
  Output OOB Actions: None
  Input OOB Size: 0
  Input OOB Actions: None received

2.3交換公鑰階段

在這個(gè)階段開(kāi)始時(shí)，需要判斷配網(wǎng)器是否能正常分配單播地址。如果無(wú)法再生成地址，則無(wú)法進(jìn)行配網(wǎng)。這個(gè)階段需要生成密鑰對(duì)和隨機(jī)數(shù)。

我司有兩種配網(wǎng)模式，快速配網(wǎng)和慢速配網(wǎng)。

• 快速模式下，配網(wǎng)器在收到設(shè)備端的配網(wǎng)能力后，會(huì)自動(dòng)發(fā)送配網(wǎng)開(kāi)始命令。
• 在慢速配網(wǎng)模式下，需要手動(dòng)點(diǎn)擊App界面中配網(wǎng)按鈕進(jìn)行指令發(fā)送。
• 注意：我司會(huì)已淘汰慢速配網(wǎng)模式，后續(xù)客戶必須是一鍵自動(dòng)配網(wǎng)。

配網(wǎng)器發(fā)送配網(wǎng)開(kāi)始到設(shè)備端：0x03020000000000

配網(wǎng)器發(fā)送配置公鑰到設(shè)備端：0x0303F494396E480FC7F73BC5ACE37CD06406CE1DAE3F4980F818C383968D1766CBD3514CA87C914ACF4ED5B809D3499E6A2D97A5359E1B47DEBF028571CCE1693FEF

設(shè)備端發(fā)送配置公鑰到配網(wǎng)端：0x0303F48D07966C9AD7005A81F8DB91C06447FF6CC40A94B58006372AF4805B8C79F710D114C80AAF131A2EA7DDD5281DB2E8F30300F600A41C181C3F52998BE32C2E

在配網(wǎng)端發(fā)送配網(wǎng)開(kāi)始指令與配置公鑰指令間，需要有一定的時(shí)間間隔。

密鑰對(duì)包含X和Y兩部分，分別占32字節(jié)。當(dāng)配網(wǎng)開(kāi)始(Provision Start)消息中的公鑰為OOB公鑰時(shí)，配置公鑰消息不存在，雙方通過(guò)諸如二維碼、NFC等OOB方式交互公鑰。

2.4身份認(rèn)證階段

藍(lán)牙m(xù)esh規(guī)范使用的ECDH算法可以較為顯著的對(duì)抗被動(dòng)監(jiān)聽(tīng)及暴力計(jì)算攻擊，但無(wú)法對(duì)抗中間人攻擊，所以需要在ECDH計(jì)算密鑰結(jié)束后對(duì)配網(wǎng)器和未配網(wǎng)設(shè)備進(jìn)行身份認(rèn)證，認(rèn)證的方式是通過(guò)兩者共享的密鑰對(duì)某個(gè)隨機(jī)值進(jìn)行加密計(jì)算并生成確認(rèn)值，然后將這兩個(gè)值都交給對(duì)方設(shè)備進(jìn)行身份認(rèn)證。

在藍(lán)牙m(xù)esh規(guī)范中，身份認(rèn)證過(guò)程包含了對(duì)設(shè)備端和配網(wǎng)器端的認(rèn)證，兩者均會(huì)和對(duì)方交互一個(gè)Confirmation Value，以及生成此Confirmation Value的Random Value，Confirmation value的計(jì)算使用了ECDH秘鑰、配網(wǎng)交互數(shù)據(jù)包及OOB認(rèn)證信息。當(dāng)一方接收到完整的Confirmation Value和Random Value后會(huì)根據(jù)自己的ECDH密鑰、配網(wǎng)交互數(shù)據(jù)包及OOB認(rèn)證信息，對(duì)收到的Random Value重新計(jì)算，生成一個(gè)Confirmation Value，然后與收到的Confirmation Value對(duì)比，如果相同則認(rèn)證成功，如果失敗則退出配網(wǎng)。當(dāng)兩者均完成認(rèn)證后，整個(gè)認(rèn)證流程結(jié)束。

配網(wǎng)器發(fā)送配網(wǎng)確認(rèn)指令到設(shè)備端：0x03055E8E0814BAD9C4E5387D183D3A76A36B

設(shè)備端發(fā)送配網(wǎng)確認(rèn)指令到配網(wǎng)器：0x03050F172A8372F24686D510DFE5223AC3DD

配網(wǎng)器發(fā)送配網(wǎng)隨機(jī)數(shù)指令到設(shè)備端：0x0306FE1B83782226C5B3E6BEFA3476FF28AC

設(shè)備端發(fā)送配網(wǎng)隨機(jī)數(shù)指令到配網(wǎng)器：0x030696EF2DDFB9464EEA24F57A6D95BC2128

2.5分發(fā)配網(wǎng)數(shù)據(jù)

配網(wǎng)器發(fā)送配網(wǎng)數(shù)據(jù)指令到設(shè)備端：0x0307F94C0BCC18558B67E750187CE3EF5CD7E3A74DC8631F9018A053CCE72A599690F4

設(shè)備端發(fā)送配網(wǎng)完成指令到配網(wǎng)器：0x0308

3.4身份驗(yàn)證的代碼邏輯

在mesh規(guī)范中有如下定義

• ConfirmationInputs = ProvisioningInvitePDUValue || ProvisioningCapabilitiesPDUValue || ProvisioningStartPDUValue || PublicKeyProvisioner || PublicKeyDevice
• ConfirmationSalt = s1(ConfirmationInputs)
• ConfirmationKey = k1(ECDHSecret, ConfirmationSalt, “prck”)

下面是具體的計(jì)算方式

3.4.1 ConfirmationInputs的計(jì)算方式

ConfirmationInputs是由整個(gè)配網(wǎng)過(guò)程中的交互數(shù)據(jù)組成，包括Provisioning Invite PDU, Provisioning Capabilities PDU,Provisioning Start PDU, 配網(wǎng)器的 Public Key 和設(shè)備的 Public Key.一共1 + 11 + 5 + 64 + 64 = 145字節(jié)。

配網(wǎng)器發(fā)送配網(wǎng)邀請(qǐng)指令：0x030005

設(shè)備端返回配網(wǎng)能力給APP端指令：0x03010100010000000000000000

配網(wǎng)器發(fā)送配網(wǎng)開(kāi)始到設(shè)備端：0x03020000000000

配網(wǎng)器發(fā)送配置公鑰到設(shè)備端：0x0303F494396E480FC7F73BC5ACE37CD06406CE1DAE3F4980F818C383968D1766CBD3514CA87C914ACF4ED5B809D3499E6A2D97A5359E1B47DEBF028571CCE1693FEF

設(shè)備端發(fā)送配置公鑰到配網(wǎng)端：0x0303F48D07966C9AD7005A81F8DB91C06447FF6CC40A94B58006372AF4805B8C79F710D114C80AAF131A2EA7DDD5281DB2E8F30300F600A41C181C3F52998BE32C2E

最終的結(jié)果是如下字符串

ConfirmationInputs = "05" + "0100010000000000000000" + "0000000000" + "F494396E480FC7F73BC5ACE37CD06406CE1DAE3F4980F818C383968D1766CBD3514CA87C914ACF4ED5B809D3499E6A2D97A5359E1B47DEBF028571CCE1693FEF" + "F48D07966C9AD7005A81F8DB91C06447FF6CC40A94B58006372AF4805B8C79F710D114C80AAF131A2EA7DDD5281DB2E8F30300F600A41C181C3F52998BE32C2E"

3.4.2 ConfirmationSalt的計(jì)算方式

所謂加Salt，就是加點(diǎn)“佐料”。當(dāng)用戶首次提供密碼時(shí)（通常是注冊(cè)時(shí)），由系統(tǒng)自動(dòng)往這個(gè)密碼里加一些“Salt值”，這個(gè)值是由系統(tǒng)隨機(jī)生成的，并且只有系統(tǒng)知道。然后再散列。而當(dāng)用戶登錄時(shí)，系統(tǒng)為用戶提供的代碼撒上同樣的“Salt值”，然后散列，再比較散列值，以確定密碼是否正確。

這樣，即便兩個(gè)用戶使用了同一個(gè)密碼，由于系統(tǒng)為它們生成的salt值不同，他們的散列值也是不同的。即便黑客可以通過(guò)自己的密碼和自己生成的散列值來(lái)找具有特定密碼的用戶，但這個(gè)幾率太小了（密碼和salt值都得和黑客使用的一樣才行）。

ConfirmationSalt = s1(ConfirmationInputs)

具體S1計(jì)算Salt的方式如下：

- (NSData*) calculateSalt: (NSData*) someData {
    //For S1, the key is constant
    unsigned char key[16] = {0x00};
    NSData* keyData = [[NSData alloc] initWithBytes: key length: 16];
    return [self calculateCMAC: someData andKey: keyData];
}

具體計(jì)算流程：ConfirmationInputs作為函數(shù)唯一輸入?yún)?shù)，然后函數(shù)內(nèi)生成16個(gè)字節(jié)的數(shù)組keyData，keyData約定全部賦值為0。計(jì)算一次AES-CMAC算法，ConfirmationInputs作為數(shù)據(jù)段，keyData作為秘鑰。

3.4.3 ConfirmationKey的計(jì)算方法

利用生成的共享密鑰(ECDHSecret) 和 佐料(ConfirmationSalt)，生成通信用的離散密鑰key。

ConfirmationKey = k1(ECDHSecret, ConfirmationSalt, “prck”)

3.4.4 計(jì)算需要發(fā)送的Confirmation值

Calculate the Confirmation Provisioner using CMAC(random + authValue)。計(jì)算以AES-128作為塊密碼功能的基于密文的消息認(rèn)證碼(CMAC)，也稱為AES-CMAC。Calculates Cipher-based Message Authentication Code (CMAC) that uses AES-128 as the block cipher function, also known as AES-CMAC.

（1）隨機(jī)數(shù) 0xC1A844F3D34886D79BBD3F9711C018ED
（2）no OOB的authValue : 16字節(jié)的0
（3）confirmationData = random + authValue
（4）calculateCMAC (confirmationData， confirmationKey)

得到Sending Provisioner Confirmation (0x5E8E0814BAD9C4E5387D183D3A76A36B)

兩端都會(huì)這樣操作。發(fā)送完Confirmation值后，兩端相互給對(duì)方發(fā)送自己的隨機(jī)數(shù)。

3.4.5 通過(guò)Random和authValue驗(yàn)證

配網(wǎng)器收到來(lái)自設(shè)備端的隨機(jī)數(shù)后，根據(jù)deviceRandom和authValue計(jì)算出confirmation：
salt和Confirmation Key這兩步跟上面配網(wǎng)器生成confirmation一樣。不同點(diǎn)在于隨機(jī)數(shù)是設(shè)備端發(fā)來(lái)的隨機(jī)數(shù)。confirmationData = deviceRandom + authValue。

與收到的設(shè)備端confirmation比較，如果相等就說(shuō)明驗(yàn)證成功。發(fā)送Encrypted Provisioning Data。

3.4.6 特別說(shuō)明：OOB方式影響的對(duì)象是AuthValue

AuthValue默認(rèn)是一個(gè)16字節(jié)的字符串。我們項(xiàng)目中默認(rèn)是No OOB模式，那么的它的值就是16個(gè)字節(jié)?度的0。其他三種：靜態(tài)OOB，輸出式OOB，輸入式OOB；也是通過(guò)影響AuthValue來(lái)達(dá)到加強(qiáng)安全性的目的。

一些做了很久藍(lán)牙m(xù)esh的同事，也不太清楚這塊的區(qū)別。

3.5 分發(fā)配網(wǎng)數(shù)據(jù)的詳細(xì)過(guò)程

配網(wǎng)器負(fù)責(zé)生成并分發(fā)配網(wǎng)數(shù)據(jù)到未配網(wǎng)設(shè)備，網(wǎng)絡(luò)數(shù)據(jù)包括如：“Network Key（網(wǎng)絡(luò)密鑰）”以及“Unicast Address（設(shè)備地址）”等重要數(shù)據(jù)。

分發(fā)配網(wǎng)數(shù)據(jù)的加密方式
為了更安全地分發(fā)配網(wǎng)數(shù)據(jù)，配網(wǎng)器需要使用AES-CCM算法來(lái)加密配網(wǎng)數(shù)據(jù)，比如算法涉及兩個(gè)加密密鑰參數(shù)：Session Key和Session Nonce，他們均由ECDH密鑰派生。
配網(wǎng)器將加密后的配網(wǎng)數(shù)據(jù)包發(fā)送給未配網(wǎng)設(shè)備，未配網(wǎng)設(shè)備從數(shù)據(jù)中獲知Unicast Address和Network Key之后，即可加入藍(lán)牙m(xù)esh網(wǎng)絡(luò)，成為網(wǎng)絡(luò)中的一個(gè)節(jié)點(diǎn)。

配網(wǎng)數(shù)據(jù)生成的細(xì)節(jié)：
1.根據(jù)已知的三個(gè)數(shù)據(jù)The Confirmation Inputs、16位Provisioner Random 和 16位device Random，生成三個(gè)新數(shù)據(jù)Session Key, Session Nonce 和 the Device Key

固件端的DeviceKey是固件端自己生成的。DeviceKey在配網(wǎng)客戶端和固件端各自生成。

固件端的NetworkKey、NetworkKey Index和UnicastAddress是在第五步“分發(fā)配網(wǎng)數(shù)據(jù)”時(shí)由APP指定的。

AppKey是在Config階段通過(guò)mesh消息流程由配網(wǎng)客戶端給固件端設(shè)置

（1）根據(jù)confirmationInputs計(jì)算confirmationSalt
let confirmationSalt = helper.calculateSalt(confirmationInputs)!
（2）將剛生成的confirmationSalt和之前的兩個(gè)隨機(jī)數(shù)相加，作為秘鑰生成salt值provisioningSalt。
let provisioningSalt = helper.calculateSalt(confirmationSalt + provisionerRandom! + deviceRandom!)!
（3）根據(jù)共享密鑰sharedSecret、剛生成的provisioningSalt，按AES-CMAC算法傳參Salt K1 計(jì)算衍生值sessionKey，sessionNonce，deviceKey.
sessionKey = helper.calculateK1(withN: sharedSecret!,salt: provisioningSalt,andP: "prsk".data(using: .ascii)!)!
sessionNonce= helper.calculateK1(withN: sharedSecret!,salt: provisioningSalt,andP: "prsn".data(using: .ascii)!)!.dropFirst(3)
deviceKey = helper.calculateK1(withN: sharedSecret!,salt: provisioningSalt,andP: "prdk".data(using: .ascii)!)!

為什么deviceKey的生成是由雙方自己生成？

因?yàn)閐eviceKey的生成與4個(gè)值有關(guān)，confirmationInputs、provisionerRandom、deviceRandom、sharedSecret，這4個(gè)參數(shù)共同確定deviceKey的結(jié)果。confirmationInputs是通信交互中的數(shù)據(jù)，provisionerRandom，deviceRandom是第四步中的隨機(jī)數(shù)，sharedSecret是計(jì)算出來(lái)的共享密鑰。這個(gè)4個(gè)參數(shù)在兩個(gè)端都知道，而且是相同的，所以deviceKey的計(jì)算各自生成就可以了。

2.用ivIndex和networkKey計(jì)算Flags,然后得到計(jì)算出25位的Provision Data
let flags = Flags(ivIndex: ivIndex, networkKey: networkKey)
let data = networkKey.key + networkKey.index.bigEndian + flags.rawValue + ivIndex.index.bigEndian + unicastAddress.bigEndian

networkKey.key：3918C5649E9A1CAB5746B2CF2B2E2397
networkKey.index:0000
flags.rawValue:00
ivIndex.index:00000000
unicastAddress:0004

data:3918C5649E9A1CAB5746B2CF2B2E2397000000000000000004

3.用CBC-MAC（CCM）算法計(jì)算完整的數(shù)據(jù)。參數(shù)分別是25位Provision Data，sessionKey，sessionNonce，指定MIC長(zhǎng)度為8

RFC3610 defines teh AES Counted with CBC-MAC (CCM).

helper.calculateCCM(data, withKey: keys.sessionKey, nonce: keys.sessionNonce, andMICSize: 8, withAdditionalData: nil)

0xF94C0BCC18558B67E750187CE3EF5CD7E3A74DC8631F9018A053CCE72A599690F4