前言
在本文的第1 部分中,介绍了配置承载层和蓝牙®MESH网络配置过程的前三个阶段:信标、邀请和交换公钥。
信标:如果支持 PB-ADV 承载,未配置的设备会发送未配置的设备信标,或者如果使用 PB-GATT,则它会发送可连接的广告数据包。这向供应商表明它已准备好配置。
邀请:供应商邀请未配置的设备发送其配置能力信息。
交换 公钥:在此阶段,根据未配置设备的能力,配置者选择合适的身份验证方法并通知未配置设备要采取的方法。之后,供应商和未配置设备创建椭圆曲线公私钥对并交换公钥。然后,每个设备使用自己的私钥和对等设备的公钥计算一个对称密钥,称为 ECDHSecret。从现在开始,此密钥用于保护两个设备之间的通信。
本文介绍了配置过程的其余两个阶段:身份验证和配置数据的分发。
验证
在此步骤中,供应商使用选定的身份验证方法对未配置的设备进行身份验证。有三种可用的身份验证方法:输出 OOB、输入 OOB 和静态 OOB 或无 OOB。
输出OOB
如果选择了输出 OOB(带外)身份验证方法,则未配置的设备会选择一个随机数并以与其功能兼容的方式输出该数字。例如,如果未配置的设备是一个灯泡,它可以闪烁给定的次数。如果设备有 LCD 屏幕,它可以将随机数显示为多位数字值。供应商的用户输入观察到的号码来验证未配置的设备。输出 OOB 身份验证方法的工作流程如图 1所示。
图 1 – 使用输出 OOB 的身份验证。
在输入随机数之后,配置程序生成并检查一个确认值。不管使用何种身份验证方法,检查确认值操作在整个身份验证步骤中都是相同的,下文将对此进行描述。
输入对象
输入 OOB 身份验证方法类似于输出 OOB 方法,但设备角色相反。配置器生成一个随机数,显示它,然后提示用户使用适当的动作将随机数输入到未配置的设备中。例如,电灯开关可以允许用户通过在特定时间段内按下按钮适当次数来输入随机数。
与输出 OOB 相比,输入 OOB 方法需要发送一个额外的配置协议 PDU。在完成认证动作后,未配置的设备向配置者发送一个配置输入完成 PDU,通知它已经输入了随机数。该过程继续检查确认值操作。
图 2 – 使用输入 OOB 进行身份验证。
静态 OOB 或无 OOB
在输入 OOB 或输出 OOB 都不可能的情况下,供应商和未配置设备可以使用静态 OOB 身份验证或无 OOB 身份验证。在这种情况下,供应商和未配置设备各自生成一个随机数,然后进行检查确认值操作。
检查确认值
无论使用何种身份验证方法,都会发生确认值生成和检查。根据蓝牙MESH网络规范,供应商和未配置设备应分别计算确认值。这两个值被称为Confirmation Provisioner和Confirmation Device。这两个值在计算中使用相同的函数流,仅在使用不同的随机数输入时有所不同。
该规范包括两页,说明了计算程序。确认值生成功能需要八个参数,其值来自配置过程中的后续步骤。您将在规范部分 5.4.2.4 身份验证和 5.4.1 配置 PDU 中找到更多详细信息。
下表列出了用于生成确认值的参数及其来源。
表 1 – 用于确认值计算的参数。
范围 | 步骤 |
---|---|
准备邀请PDU值、配置能力PDU值 | 步骤2 |
配置开始PDU值、公钥配置者、公钥设备 | 步骤3 |
ECDHSecret | 步骤3 |
验证内容 | 步骤4,当采用Output OOB或Input OOB方式时,验证内容为用户输入的值。 |
配置者随机数 | 步骤4:配置器中的随机数。 |
配置设备随机数 | 步骤4:从未配置的设备上取随机数。 |
让我们看看用于生成确认值的算法。图3提供了一个流程图,其中包括几轮AES-CMAC和SALT生成。流程图适用于ConfirmationProvisioner 和 ConfirmationDevice 值。
如果输入是由配置程序执行的,那么我们从一个名为randomprovider的值开始(如下面的蓝色部分所示),然后生成confirationprovider。
如果输入是由未配置的设备执行的,我们从一个称为RandomDevice的值开始(如下图中绿色部分所示),并生成一个ConfirmationDevice值。
图 3 – 确认值生成图表。
确认值检查
当确认值准备好时,它们由两个设备交换,每个设备检查接收值的完整性。图 4说明了确认值检查过程。
确认过程从供应商向未配置的设备发送其随机数 RandomProvisioner 开始。未配置的设备使用它来重新计算确认值并通过将其与之前收到的确认值进行比较来验证它。
图 4 – 确认值检查。
- 如果未配置设备计算的确认值与接收到的 ConfirmationProvisioner 不匹配,则配置过程将中止。
- 如果未配置设备计算出的确认值与接收到的 ConfirmationProvisioner 匹配,则未配置设备将其 RandomDevice 值发送给配置程序。
然后,供应商使用相同的过程重新计算确认值,并通过将计算出的值与先前接收到的值进行比较来进行验证。
- 如果配置者计算的确认值与收到的 ConfirmationDevice 不匹配,则配置过程将中止。
- 如果provisioner计算的确认值与接收到的ConfirmationDevice匹配,则表示认证成功。通过供应商和未配置设备完成配置过程的第五步:配置数据的分发,未配置设备现在可以成为蓝牙MESH网络中的节点。
配置数据的分布
身份验证步骤完成后,在配置过程中最重要的步骤:派生和分发配置数据,可以保护在供应商和未配置设备之间建立的承载。配置者负责生成配置数据,该数据由许多数据项组成,包括称为网络密钥的安全密钥。表 2列出了配置数据字段。
表 2 – 配置数据
场地 | 大小(8字节) | 笔记 |
---|---|---|
网络密钥 | 简称 NetKey。NetKey 确保网络层的通信安全,并在网络中的所有节点之间共享。拥有给定的 NetKey 定义了给定蓝牙MESH网络或子网的成员资格。为设备配备网络的 NetKey 是配置过程的主要结果之一。供应商在配置要添加到网络的第一个设备时创建 NetKey。 | |
设备密钥 | 仅由供应商和被配置的设备拥有的唯一安全密钥。 | |
关键索引 | NetKeys 太长,无法在单段消息中传输。为了尽可能提高消息传递的效率,为密钥分配了一个全局唯一的 12 位索引值,称为密钥索引,用作密钥的短标识符。消息包括键索引值,这些值可以被配置客户端维护的键列表引用。 | |
Flags | 标志位掩码------表示关联密钥的状态。 | |
IV指数 | IV(初始化向量)索引是一个 32 位值,由网络中的所有节点共享。其目的是在消息随机数值的计算中提供熵(随机性)。 | |
单播地址 | 新节点的主要元素的单播地址。 |
为了安全地分发配置数据,供应商使用 AES-CCM 使用共享的 SessionKey 加密配置数据,供应商和未配置的设备都会计算该密钥。AES-CCM 需要三个输入参数:会话密钥、会话随机数和明文。明文参数值包含需要加密的配置数据。设备密钥、会话密钥和会话随机数值由图 5中描绘的过程导出。
图 5 – DevKey/SessionKey/SessionNonce 生成过程
从图 5 中我们可以看出:
- 如果将prsk(绿色)的输入值传递给k1函数,则会生成一个SessionKey。这是用于提供数据加密的密钥。
- 如果将prsn(黄色)的输入值传递给k1函数,则会生成一个SessionNonce。这是用于提供数据加密的 nonce 值。
- 如果将prdk(蓝色)的输入值传递给k1函数,则会生成一个DevKey。
供应商和未配置设备都需要生成 SessionKey 和 SessionNonce。当 SessionKey 和 SessionNonce 值准备好时,供应商加密并将包含派生的配置数据的配置数据 PDU 发送到未配置的设备。这里使用对应的相同 SessionKey 和 SessionNonce 值对接收到的数据进行解密。
至此,配置过程结束。两个对等设备都知道新的 DevKey 和全局 NetKey,这使我们的新设备成为蓝牙MESH网络的节点和成员。
开发MESH
配置过程是蓝牙®MESH网络安全的基石,它使网络设备能够可靠、安全地相互通信。如果您想了解有关蓝牙MESH网络的更多信息,您可以下载规范并获得开发下一个蓝牙MESH网络创新所需的一切。
BLE MESH组网(一)简介
BLE MESH组网(二)友谊功能和设备管理
BLE MESH组网(三)普通BLE如何添加到网络
BLE MESH组网(四)安全概述
BLE MESH组网(五)配置BLE MESH
BLE MESH组网(六)配置BLE MESH