CN110138805B - 一种设备认证方法、装置和计算机可读储存介质 - Google Patents

Abstract

本申请实施例提供了一种设备认证方法、访问方法、秘钥处理方法及装置、区块链。设备认证方法包括：接收第一设备发送的设备认证请求；对设备认证请求中携带的第一设备的第一ID相关数据进行认证，以及对从第二设备获取的第二设备的第二ID相关数据也进行认证；确定第一ID相关数据和第二ID相关数据均认证通过，向第一设备发送认证通过的结果，使得第一设备基于结果向第二设备发起访问。由于在对第一设备进行认证的同时，也要对应的对第二设备进行认证，在第一设备和第二设备的认证均通过后，才允许第一设备发起对第二设备的访问。因此，通过双向认证可确定发起访问的设备和被访问的设备都是安全的，故提高了访问的安全性。

Description

一种设备认证方法、装置和计算机可读储存介质

技术领域

本申请涉及物联网技术领域，具体而言，涉及一种设备认证方法、访问方法、秘钥处理方法及装置、区块链。

背景技术

在IoT(Internet of Things，物联网)技术中，若设备A需要访问设备 B，那么需要第三方对设备A进行认证，在认证通过后，设备A便可以发起对设备B的访问。这种方式虽然能够保证一定的访问安全，但安全性并不高。

发明内容

本申请在于提供一种设备认证方法、访问方法、秘钥处理方法及装置、区块链，以有效的提高设备访问的安全性。

第一方面，本申请实施例提供了一种设备认证方法，所述方法包括：

接收所述第一设备发送的设备认证请求；

对所述设备认证请求中携带的所述第一设备的第一ID相关数据进行认证，以及对从所述第二设备获取的所述第二设备的第二ID相关数据也进行认证；

确定所述第一ID相关数据和所述第二ID相关数据均认证通过，向所述第一设备发送认证通过的结果，使得所述第一设备基于所述结果向所述第二设备发起访问。

在本申请实施例中，由于在对第一设备进行认证的同时，也要对应的对第二设备进行认证，在第一设备和第二设备的认证均通过后，才允许第一设备发起对第二设备的访问。因此，通过双向认证可确定发起访问的设备和被访问的设备都是安全的，故提高了访问的安全性。

结合第一方面，在第一种可能的实现方式中，所述第一ID相关数据包括所述设备ID、所述预设第一加密数据和所述预设第二加密数据，所述预设第二加密数据为预先通过加密所述设备ID和所述预设第一加密数据获得，对所述设备认证请求中携带的所述第一设备的第一ID相关数据进行认证，包括：

加密所述设备ID和所述预设第一加密数据，生成新的第二加密数据；

将所述新的第二加密数据与所述预设第二加密数据匹配。

在本申请实施例中，通过将新的第二加密数据与预设第二加密数据匹配，能够有效识别出第一设备的设备ID和/或预设第一加密数据是否有被篡改，以防止存在安全隐患的第一设备还能够发起访问。

结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述方法应用于区块链中的任一节点，所述预设第一加密数据为通过加密所述设备ID和子秘钥获得，在将所述新的第二加密数据与所述预设第二加密数据匹配之后，所述方法还包括：

确定所述新的第二加密数据与所述预设第二加密数据匹配，获取所述区块链上至少部分其它节点中每个所述其它节点保存的子秘钥；

通过每个所述其它节点保存的子秘钥，恢复出原秘钥；

通过所述原秘钥解密所述预设第一加密数据，获得解密的所述设备ID 和解密的子秘钥；

将解密的所述设备ID与自身存储的所述第一设备的设备ID匹配，以及将所述解密的子秘钥与从所述区块链上获取的所述第一设备的子秘钥匹配。

在本申请实施例中，一方面，通过区块链上其它节点保存的子秘钥来恢复出原秘钥，其能够保证恢复出的原秘钥是安全可靠的。另一方面，还可以利用原秘钥解密预设第一加密数据，而对解密的设备ID和解密的子秘钥验证，从而进一步提高安全性。

结合第一方面的第二种可能的实现方式，在第三种可能的实现方式中，在确定所述第一ID相关数据和所述第二ID相关数据均认证通过后，所述方法还包括：

生成所述结果的索引值；

将所述索引值同步到所述区块链上所有的所述其它节点，并将所述结果发送到所述区块链下的数据库存储。

在本申请实施例中，区块链在记录认证的结果时，由于其记录的是结果的索引值，而将结果放到链下的数据库存储，故能够有效减少链上的开销。

结合第一方面或第一方面的第一种至第三种中任一种可能的实现方式，在第四种可能的实现方式中，所述第一设备与所述第二设备位于同一信任域内，向所述第一设备发送认证通过的结果之后，所述方法还包括：

在所述第一设备通过访问控制系统访问所述第二设备的过程中，接收所述访问控制系统发送的所述第二设备的属性；

根据所述属性，从预设的控制策略中确定出所述第二设备的控制策略；

将所述第二设备的控制策略发送至所述访问控制系统，使得所述访问控制系统根据所述第二设备的控制策略确定是否允许所述第一设备访问所述第二设备。

在本申请实施例中，由于设备的控制策略存储在区块链上，其可以有效保证控制策略的安全性，避免被篡改。

结合第一方面或第一方面的第一种至第三种中任一种可能的实现方式，在第五种可能的实现方式中，所述第一设备与所述第二设备位于不同的信任域内，向所述第一设备发送认证通过的结果之后，所述方法还包括：

在所述第一设备通过访问控制系统访问所述第二设备的过程中，接收所述访问控制系统发送的所述第二设备的属性、所述第一设备的属性和控制策略；

根据所述第二设备的属性从预设的控制策略中确定出所述第二设备的控制策略；

判断所述第一设备的控制策略与所述第二设备的控制策略的一致性是否满足预设标准；

若不满足所述预设标准，根据所述第一设备的属性，判断是否能够将所述第一设备的控制策略与所述第二设备的控制策略合并；

若能够合并，将所述第一设备的控制策略和所述第二设备的控制策略合并，生成所述第二设备的新的控制策略；

将所述新的控制策略发送至所述访问控制系统，使得所述访问控制系统根据所述新的控制策略确定是否允许所述第一设备访问所述第二设备。

在本申请实施例中，为保证设备跨域访问的成功率，区块链上的节点还可以将第一设备的控制策略与第二设备的控制策略合成，从而生成第二设备的新的控制策略。由于第二设备的新的控制策略结合了第一设备的特点，使得第二设备能够成功的被第一设备访问。

结合第一方面的第四种或第五种可能的实现方式，在第六种可能的实现方式中，所述控制策略包含用于表示访问逻辑的表达式，所述表达式中包含符号和参数。

在本申请实施例中，由于控制策略为通过包含符号和参数的表达式进行表达，这种方式可以有效的降低控制策略的数据量。

第二方面，本申请实施例提供了一种设备访问方法，应用于访问控制系统中的任一节点，方法包括：

接收第一设备发送的访问请求；

根据所述访问请求，从数据库中获取所述第一设备的信任值和第二设备的信任值；

确定所述第一设备的信任值和所述第二设备的信任值均大于预设信任值，获取所述第二设备的控制策略；

确定所述控制策略与所述访问请求中携带的控制策略匹配，并将所述访问请求转发至所述第二设备。

在本申请实施例中，基于确定第一设备的信任值和第二设备的信任值均大于预设信任值，才允许第一设备访问第二设备，故有效提高了访问的安全性。

结合第二方面，在第一种可能的实现方式中，在接收第一设备发送的访问请求之前，所述方法还包括：

接收所述第一设备发送的平台认证请求；

获取所述平台认证请求中携带的第一平台信息，其中，所述第一平台信息为所述第一设备所属的平台的信息；

判断所述第一平台信息与预设的第二平台信息之间是否具有信任关系，其中，所述第二平台信息为所述第二设备所属的平台的信息；

若具有，向所述第一设备发送平台认证通过的结果，使得所述第一设备基于所述结果向所述第二设备发起访问。

在本申请实施例中，除了验证设备的信任值外，还基于确定第一设备所属的平台的第一平台信息与预设的第二平台信息之间具有信任关系，才允许第一设备访问第二设备，故进一步提高了访问的安全性。

第三方面，本申请实施例提供了一种秘钥处理方法，所述方法包括：

生成原秘钥；

根据区块链中节点的数量，将所述原秘钥分割成多个子秘钥；

将每个设备的设备ID与对应的一个所述子秘钥加密，获得每个所述设备的预设第一加密数据；

将所述预设第一加密数据发送给对应的每个所述设备。

在本申请实施例中，通过将原秘钥分割成多个子秘钥，使得每个设备可以基于自身对应的一个子秘钥进行加密，有效保证加密的安全性。

结合第三方面，在第一种可能的实现方式中，在将每个设备的设备ID 与对应的一个所述子秘钥加密，获得每个所述设备的预设第一加密数据之前，所述方法还包括：

从预设的数据库中获取所有的所述设备的信任值；

按所述信任值的高低将所有的所述设备排序，从所述排序中确定出数量与所述子秘钥的数量相同的多个所述设备。

在本申请实施例中，由于不信任的设备上的数据被篡改的可能性较大，通过信任值的高低选择设备，可避免将子秘钥分配给不信任的设备，从而降低子秘钥被篡改的可能性。

结合第三方面的第一种可能的实现方式，在第二种可能的实现方式中，在将所述预设第一加密数据发送给对应的每个所述设备之后，所述方法还包括：

在所述设备访问成功后，接收所述设备发送的信用更新指示；

根据所述信用更新指示，更新所述设备的信任值，并将所述设备更新后的信任值发送到所述数据库。

在本申请实施例中，通过对设备的信任值的实时更新，可有效保证信任值的准确性。

第四方面，本申请实施例提供了一种设备认证装置，所述装置包括：

数据收发模块，用于接收所述第一设备发送的设备认证请求；

数据处理模块，用于对所述设备认证请求中携带的所述第一设备的第一ID相关数据进行认证，以及对从所述第二设备获取的所述第二设备的第二ID相关数据也进行认证；

所述数据收发模块，还用于确定所述第一ID相关数据和所述第二ID 相关数据均认证通过，向所述第一设备发送认证通过的结果，使得所述第一设备基于所述结果向所述第二设备发起访问。

结合第四方面，在第一种可能的实现方式中，所述第一ID相关数据包括所述设备ID、所述预设第一加密数据和所述预设第二加密数据，所述预设第二加密数据为预先通过加密所述设备ID和所述预设第一加密数据获得，

所述数据处理模块，用于加密所述设备ID和所述预设第一加密数据，生成新的第二加密数据；将所述新的第二加密数据与所述预设第二加密数据匹配。

结合第四方面的第一种可能的实现方式，在第二种可能的实现方式中，所述方法应用于区块链中的任一节点，所述预设第一加密数据为通过加密所述设备ID和子秘钥获得，在所述数据处理模块将所述新的第二加密数据与所述预设第二加密数据匹配之后，

所述数据处理模块，还用于确定所述新的第二加密数据与所述预设第二加密数据匹配，获取所述区块链上至少部分其它节点中每个所述其它节点保存的子秘钥；通过每个所述其它节点保存的子秘钥，恢复出原秘钥；通过所述原秘钥解密所述预设第一加密数据，获得解密的所述设备ID和解密的子秘钥；将解密的所述设备ID与自身存储的所述第一设备的设备ID 匹配，以及将所述解密的子秘钥与从所述区块链上获取的所述第一设备的子秘钥匹配。

结合第四方面的第二种可能的实现方式，在第三种可能的实现方式中，在所述数据处理模块确定所述第一ID相关数据和所述第二ID相关数据均认证通过后，

所述数据收发模块，还用于生成所述结果的索引值；将所述索引值同步到所述区块链上所有的所述其它节点，并将所述结果发送到所述区块链下的数据库存储。

结合第四方面或第四方面的第一种至第三种中任一种可能的实现方式，在第四种可能的实现方式中，所述第一设备与所述第二设备位于同一信任域内，在所述数据收发模块向所述第一设备发送认证通过的结果之后，

所述数据收发模块，还用于在所述第一设备通过访问控制系统访问所述第二设备的过程中，接收所述访问控制系统发送的所述第二设备的属性；

所述数据处理模块，还用于根据所述属性，从预设的控制策略中确定出所述第二设备的控制策略；将所述第二设备的控制策略发送至所述访问控制系统，使得所述访问控制系统根据所述第二设备的控制策略确定是否允许所述第一设备访问所述第二设备。

结合第四方面或第四方面的第一种至第三种中任一种可能的实现方式，在第五种可能的实现方式中，所述第一设备与所述第二设备位于不同的信任域内，在所述数据收发模块向所述第一设备发送认证通过的结果之后，

所述数据收发模块，还用于在所述第一设备通过访问控制系统访问所述第二设备的过程中，接收所述访问控制系统发送的所述第二设备的属性、所述第一设备的属性和控制策略；

所述数据处理模块，还用于根据所述第二设备的属性从预设的控制策略中确定出所述第二设备的控制策略；判断所述第一设备的控制策略与所述第二设备的控制策略的一致性是否满足预设标准；若不满足所述预设标准，根据所述第一设备的属性，判断是否能够将所述第一设备的控制策略与所述第二设备的控制策略合并；若能够合并，将所述第一设备的控制策略和所述第二设备的控制策略合并，生成所述第二设备的新的控制策略；

以及，所述数据收发模块，还用于将所述新的控制策略发送至所述访问控制系统，使得所述访问控制系统根据所述新的控制策略确定是否允许所述第一设备访问所述第二设备。

结合第四方面的第四种或第五种可能的实现方式，在第六种可能的实现方式中，所述控制策略包含用于表示访问逻辑的表达式，所述表达式中包含符号和参数。

第五方面，本申请实施例提供了一种设备访问装置，应用于所述访问控制系统中的任一节点，装置包括：

数据收发模块，用于接收第一设备发送的访问请求；

数据处理模块，用于根据所述访问请求，从数据库中获取所述第一设备的信任值和第二设备的信任值；以及，用于确定所述第一设备的信任值和所述第二设备的信任值均大于预设信任值，获取所述第二设备的控制策略；

所述数据收发模块，还用于确定所述控制策略与所述访问请求中携带的控制策略匹配，并将所述访问请求转发至所述第二设备。

结合第五方面，在第一种可能的实现方式中，在所述数据收发模块接收第一设备发送的访问请求之前，

所述数据收发模块，还用于接收所述第一设备发送的平台认证请求；

所述数据处理模块，还用于获取所述平台认证请求中携带的第一平台信息，其中，所述第一平台信息为所述第一设备所属的平台的信息；判断所述第一平台信息与预设的第二平台信息之间是否具有信任关系，其中，所述第二平台信息为所述第二设备所属的平台的信息；

若具有，所述数据收发模块，还用于向所述第一设备发送平台认证通过的结果，使得所述第一设备基于所述结果向所述第二设备发起访问。

第六方面，本申请实施例提供了一种秘钥处理装置，所述装置包括：

秘钥处理模块，用于生成原秘钥；根据区块链中节点的数量，将所述原秘钥分割成多个子秘钥；以及，用于将每个设备的设备ID与对应的一个所述子秘钥加密，获得每个所述设备的预设第一加密数据；

数据发送模块，用于将所述预设第一加密数据发送给对应的每个所述设备。

结合第六方面，在第一种可能的实现方式中，在所述秘钥处理模块将每个设备的设备ID与对应的一个所述子秘钥加密，获得每个所述设备的预设第一加密数据之前，

所述数据发送模块，还用于从预设的数据库中获取所有的所述设备的信任值；

所述秘钥处理模块，还用于按所述信任值的高低将所有的所述设备排序，从所述排序中确定出数量与所述子秘钥的数量相同的多个所述设备。

结合第六方面的第一种可能的实现方式，在第二种可能的实现方式中，在所述数据发送模块将所述预设第一加密数据发送给对应的每个所述设备之后，

在所述设备访问成功后，所述数据发送模块，还用于接收所述设备发送的信用更新指示；根据所述信用更新指示，更新所述设备的信任值，并将所述设备更新后的信任值发送到所述数据库。

第七方面，本申请实施例提供了一种区块链，包括：多个节点，每个所述节点与其它所述节点连接；

所述多个节点中的任一所述节点用于执行如第一方面或第一方面的任一种可能的实现方式所述的设备认证方法。

第八方面，本申请实施例提供了一种访问控制系统，包括：多个节点，每个所述节点与其它所述节点连接；

所述多个节点中的任一所述节点用于执行如第二方面或第二方面的第一种可能的实现方式所述的设备访问方法。

第九方面，本申请实施例提供了一种秘钥服务器，包括：与外部设备连接的通信接口、与所述通信接口连接的存储器、与所述存储器连接的处理器；

所述存储器，用于存储程序；

所述处理器，用于调用并运行所述程序，以执行如第三方面或第三方面的任一种可能的实现方式所述的秘钥处理方法。

第十方面，本申请实施例提供了一种计算机可读储存介质，所述存储介质上存储有程序代码，当所述程序代码被所述计算机运行时，执行如第一方面或第一方面的任一种可能的实现方式所述的设备认证方法，或执行如第二方面或第二方面的第一种可能的实现方式所述的设备访问方法，或执行如第三方面或第三方面的任一种可能的实现方式所述的秘钥处理方法。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的一种分布式访问控制系统的第一结构框图；

图2示出了本申请实施例提供的一种分布式访问控制系统的第二结构框图；

图3示出了本申请实施例提供的一种分布式访问控制系统的第三结构框图；

图4示出了本申请实施例提供的一种分布式访问控制系统的第四结构框图；

图5示出了本申请实施例提供的一种秘钥处理方法的主流程图；

图6示出了本申请实施例提供的一种秘钥处理方法的交互流程图；

图7示出了本申请实施例提供的一种设备认证方法的流程图；

图8示出了本申请实施例提供的一种设备访问方法的主流程图；

图9示出了本申请实施例提供的一种设备访问方法的交互流程图；

图10示出了本申请实施例提供的一种设备访问方法在跨域访问的情况下所对应的结构框图；

图11示出了本申请实施例提供的一种设备认证装置的结构框图；

图12示出了本申请实施例提供的一种设备访问装置的结构框图；

图13示出了本申请实施例提供的一种秘钥处理装置的结构框图。

具体实施方式

下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

请参阅图1，本申请实施例提供了一种分布式访问控制系统10，该分布式访问控制系统10可以包括：秘钥服务器20、区块链30和访问控制系统40。其中，秘钥服务器20与区块链30连接，而区块链30则与访问控制系统40连接。

下面将分别对秘钥服务器20、区块链30和访问控制系统40进行详细说明。

如图2所示，秘钥服务器20可以包括：与外部设备和/或区块链30连接的通信接口21、用于执行程序指令的一个或多个处理器22、总线23、和不同形式的存储器24，例如，磁盘、ROM、或RAM，或其任意组合。示例性地，秘钥服务器20还可以包括存储在ROM、RAM、或其他类型的非暂时性存储介质、或其任意组合中的程序指令。

存储器24用于存储程序，处理器22用于调用并运行存储器24中的程序以执行本实施例所述的秘钥处理方法。

需要说明的是，图2中所示的外部设备为虚线表示，其表示外部设备为逻辑上的概念，例如其可以表示第一设备和第二设备在逻辑上属于为外部设备。此外，外部设备的类型可以是物理网中进行交互各类型的设备，例如：电视机、冰箱、空调、路由器、手机、热水器等。

本实施例中，通过对秘钥处理方法的执行，秘钥服务器20可以根据区块链30中节点的数量将分割原秘钥，并将分割后属于该外部设备的子秘钥加密后发送给该外部设备，以及将分割得到的各子秘钥同步到区块链30上，以便该外部设备后续可以基于该加密后的子秘钥向区块链30请求设备验证。再者，在外部设备的信任值和其他外部设备的信任值足够高，使得外部设备访问其他外部设备成功后，秘钥服务器20可以根据该访问成功的外部设备的请求更新该访问成功的外部设备的信任值，以及还可以根据被访问的其他外部设备的请求而更新该被访问的其他外部设备的信任值。

如图3所示，区块链30可以包括：多个节点31，其中，每个节点31 可以与其它节点31连接。本实施例中，区块链30中任一个节点31可以是终端或者服务器，其中，终端可以是个人电脑(personal computer，PC)、平板电脑、智能手机、个人数字助理(personaldigital assistant，PDA)等；服务器可以为网络服务器、数据库服务器、云服务器或由多个子服务器构成的服务器集群等。

本实施例中，区块链30中任一个节点31可以与秘钥服务器20通信，区块链30中任一个节点31可以获取秘钥服务器20发送的各外部设备的子秘钥，并将各外部设备的子秘钥分布式的存储到各节点31，使得每个外部设备的子秘钥存储在对应的一个节点31上，以保证子秘钥的安全。

区块链30中任一个节点31都可以执行本实施例所述的设备认证方法。通过对设备认证方法的执行，区块链30中任一个节点31可以从其它获取节点31获取子秘钥，从而恢复出原秘钥，以利用该原秘钥对需要认证的外部设备进行设备认证。此外，区块链30中任一个节点31还可以与访问控制系统40通信，区块链30中任一个节点31也通过对设备认证方法的执行，区块链30中任一个节点31可以从对应的数据库中查到被访问的外部设备的控制策略。若区块链30中任一个节点31确定外部设备执行的是域内访问，区块链30中任一个节点31可将被访问的外部设备的控制策略发送给访问控制系统40，以便访问控制系统40确定是否允许发起访问的外部设备访问该被访问的外部设备。而若区块链30中任一个节点31确定外部设备执行的是跨域访问，区块链30中任一个节点31可将发起访问的外部设备的控制策略与被访问的外部设备的控制策略合成为新的控制策略，并将新的控制策略发送给与被访问的外部设备处于同一域的访问控制系统40，以便访问控制系统40确定是否允许发起访问的外部设备访问该被访问的外部设备。

如图4所示，访问控制系统40也可以包括：多个节点41，其中，每个节点41可以与其它节点41连接。本实施例中，访问控制系统40中任一个节点41可以是终端或者服务器，而终端或者服务器的类型可以参考前述理解，在此就不再累述。

值得注意的是，在物理上，访问控制系统40包括多个物理设备，即多个节点41。但在逻辑上，根据访问控制系统40实现的功能，访问控制系统 40还可以包括：PEP(PolicyEnforcement Point，策略执行点)、PAP(Policy Administration Point，策略管理点)、PDP(Policy Decision Point，策略判定点)和PIP(Policy Information Point，策略信息点)。其中，PEP、PAP、PDP和PIP都是程序功能对应的逻辑概念，PEP、PAP、PDP和PIP可以分别部署在访问控制系统40的各物理设备上，即分别部署在访问控制系统40 的各节点41上。理论上，同一节点41上可以部署PEP、PAP、PDP和PIP 中的至少一种。但为实现分布式部署，以降低每个节点41的负荷，可选的，同一节点41上可以部署PEP、PAP、PDP和PIP中任一种。此外，部署有同一种功能的节点41的数量可以不止一个，例如图4所示，节点B1部署有PDP，但节点B6也部署有PDP。

需要说明的是，为便于描述的简洁，在后续描述中，将部署有PEP、 PAP、PDP或PIP的节点41统称为PEP节点41、PAP节点41、PDP节点 41或PIP节点41，例如，访问控制系统40中的PEP节点41即是指代访问控制系统40中部署有PEP的节点41。

本实施例中，访问控制系统40中的任一个PDP节点41都可以执行本实施例中所述的设备访问方法。通过对设备访问方法的执行，任一个PDP 节点41都可以根据发起访问的外部设备的信任值和被访问的外部设备的信任值，确定是否允许发起访问的外部设备的信任值访问该被访问的外部设备。

需要说明的是，为保证分布式访问控制系统10的各流程能够正确执行，参与流程执行每个设备包括但不限于外部设备、秘钥服务器20、区块链30 中每个节点、访问控制系统40中每个节点41的设备ID是全局唯一ID。

下面将通过方法实施例，对秘钥服务器20、区块链30和访问控制系统 40所执行的各流程进行详细的说明。

请参阅图5，本申请实施例提供了一种秘钥处理方法，该秘钥处理方法可以由秘钥服务器20执行，该秘钥处理方法可以包括：步骤S100、步骤 S200、步骤S300和步骤S400。

步骤S100：生成原秘钥。

步骤S200：根据区块链中节点的数量，将所述原秘钥分割成多个子秘钥。

步骤S300：将每个设备的设备ID与对应的一个所述子秘钥加密，获得每个所述设备的预设第一加密数据。

步骤S400：将所述预设第一加密数据发送给对应的每个所述设备。

结合图2和图3，参阅图5和图6，下面依次对秘钥处理方法的各流程进行详细说明。

在外部设备需要利用加密后的子秘钥向区块链30发起设备验证时，外部设备可以检测是否具有加密后的子秘钥。若检测到具有加密后的子秘钥，外部设备便利用该加密后的子秘钥向区块链30发起设备验证的流程(该流程将在后续进行说明)。若检测到自身不具有加密后的子秘钥，外部设备便可以向秘钥服务器20发送加密数据获取请求，其中，为便于秘钥服务器 20识别区分各外部设备，加密数据获取请求中携带有该外部设备唯一设备ID。

相应的，秘钥服务器20可以接收到各外部设备发送的加密数据获取请求。由于秘钥服务器20为各外部设备的子秘钥是基于原秘钥分割而生成的，故需要发送加密数据获取请求的外部设备的数量等于原秘钥分割所需的预设数量，秘钥服务器20才可以进行秘钥分割，其中，预设数量可以大于原秘钥的分割份数，以保证可对发送加密数据获取请求的外部设备进行筛选，提高安全性。基于此，在每一次接收到加密数据获取请求时，秘钥服务器 20都可以判断自上次秘钥分割后所接收的来自不同外部设备的加密数据获取请求的数量是否等于预设数量。

若小于预设数量，秘钥服务器20可以等到下一次接收到加密数据获取请求后再继续进行判断。

若等于预设数量，秘钥服务器20确定本次可以进行秘钥分割。

如图6所示，下面以第一设备、第二设备和第三设备(对于分布式访问控制系统而言，第一设备、第二设备和第三设备均属于外部设备)为例，通过一个示例来进行说明。

自秘钥服务器20上一次秘钥分割后，若第一设备确定自身不具有加密后的子秘钥，第一设备向秘钥服务器20发送携带有自身的设备ID的加密数据获取请求。若第二设备也确定自身不具有加密后的子秘钥，第二设备也向秘钥服务器20发送携带有自身的设备ID的加密数据获取请求。以及，还有第三设备也确定自身不具有加密后的子秘钥，第三设备也向秘钥服务器20发送携带有自身的设备ID的加密数据获取请求。

在预设数量为3个的情况下，秘钥服务器20接收到第三设备的加密数据获取请求，秘钥服务器20可以确定自上一次秘钥分割后接收的加密数据获取请求的数量等于3个。故秘钥服务器20可以执行秘钥分割的流程，即开始执行步骤S100。

步骤S100：生成原秘钥。

秘钥服务器20可以利用预设的秘钥生成工具例如Openssl工具生成所需的原秘钥。可以理解到，为保证安全性，秘钥服务器20每一次生成的原秘钥都与其他时候生成的原秘钥不同。

秘钥服务器20生成原秘钥后，秘钥服务器20可以进一步执行步骤 S200。

步骤S200：根据区块链中节点的数量，将所述原秘钥分割成多个子秘钥。

由于分割出的多个子秘钥还需要一一对应的存储在区块链30的多个节点31中，故秘钥分割的份数不能够超过节点31的数量。在此基础上，秘钥服务器20可以根据预设的区块链30中节点31的数量，以及根据预设数量，确定出不大于节点31的数量且等于预设数量的分割份数。秘钥服务器 20根据分割份数，并利用门限秘钥分割技术将原秘钥分割成多个子秘钥。

与此同时，秘钥服务器20还可以将多个子秘钥发送到区块链30，使得多个子秘钥一一对应的存储在区块链30的多个节点31上。

进一步的，在分割出多个子秘钥后，秘钥服务器20继续执行步骤S300。

步骤S300：将每个设备的设备ID与对应的一个所述子秘钥加密，获得每个所述设备的预设第一加密数据。

由于分割份数与预设数量相同，而发起请求的外部设备的数量也等于预设数量，故秘钥服务器20可以为发起请求的每个外部设备分配对应一个子秘钥，并利用原秘钥加密每个外部设备的设备ID(由于设备ID携带在加密数据获取请求，故秘钥服务器20可以获得设备ID)和该外部设备对应分配一个子秘钥，从而生成每个外部设备的预设第一加密数据，其中，每个外部设备的预设第一加密数据即为前述中所述的加密后的子秘钥。

获得每个外部设备的预设第一加密数据后，秘钥服务器20继续执行步骤S400。

步骤S400：将所述预设第一加密数据发送给对应的每个所述设备。

为避免预设第一加密数据在传输过程中被窃取，秘钥服务器20可以与每个外部设备建立安全信道，从而通过每个外部设备的安全信道，将该外部设备的预设第一加密数据发送至该外部设备。

可以理解到，秘钥处理方法除了上述实现方式外，本实施例还提供了秘钥处理方法的另一种实现方式，下面将就该另一种实现方式与前述实现方式的不同之处进行详细说明。

由于秘钥服务器20还可以用于储存每个外部设备最新的信任值，以便于访问控制系统40根据信任值来确定是否允许发起访问的外部设备访问被访问的外部设备。那么在步骤S300之前，秘钥服务器20可利用信任值选择出信任值高的部分外部设备，并为这部分外部设备分配加密的子秘钥。相应的，由于秘钥服务器20不用为信任值低的外部设备分配加密的子秘钥，信任值低的外部设备则无法向区块链30发起设备验证，使得设备验证流程避免由信任值低的外部设备所带来的风险，提高了设备验证流程安全性。

具体的，作为利用信任值筛选外部设备的示例性方式，秘钥服务器20 中预设有数据库，而数据库中存储了每个外部设备最新的信任值，故秘钥服务器20可以从数据库中获取自上一次秘钥分割后发送了加密数据获取请求的所有设备的信任值。秘钥服务器20可以按信任值由高至低或由低至高的顺序，将所有设备的设备ID排序。这样，秘钥服务器20可以从排序中确定出信任值最高且数量与子秘钥对应的多个设备ID，其中，确定出设备 ID即是确定出对应的外部设备。

在确定出高信任值的外部设备，秘钥服务器20便为高信任值的每个外部设备分配对应的一个子秘钥，并生成高信任值的每个外部设备的预设第一加密数据，以及再将高信任值的每个外部设备的预设第一加密数据发送至该外部设备。其中，秘钥服务器20为高信任值的每个外部设备分配子秘钥、生成并发送高信任值的每个外部设备的预设第一加密数据的具体实现与前述实现方式大致相同，在此不再累述。

需要说明的是，由于筛选出的外部设备的数量与子秘钥的数量相同，为保证发送请求的外部设备中低信任值的外部设备会被筛选掉，因此，在该另一种实现方式中，秘钥服务器20执行步骤S200的过程中，秘钥服务器20需要确定出小于预设数量的分割份数，以保证子秘钥的数量小于发送请求的外部设备的数量。

如图3和图6所示，继续通过前述示例进行说明。

秘钥服务器20可以生成原秘钥Kc。在预设数量为3个，以及在区块链30的节点31的数量为7个情况下，秘钥服务器20可以确定出秘钥的分割份数为2份，并将原秘钥Kc分割为子秘钥K1和子秘钥K2。进一步的，秘钥服务器20可以将子秘钥K1和子秘钥K2发送给区块链30中的节点 A6。节点A6可将子秘钥K1发送给节点A1存储，以及将子秘钥K2保存在自身。

与本实施例中，秘钥服务器20还可根据第一设备的设备ID从数据库中获取到第一设备的信任值为78，以及根据根据第二设备的设备ID从数据库中获取到第二设备的信任值为84，以及还根据第三设备的设备ID从数据库中获取到第三设备的信任值为77。那么按照信任值排序，根据秘钥服务器20便可以筛选出信任值高的外部设备为第一设备和第二设备。秘钥服务器20为第一设备分配子秘钥K1，并利用原秘钥Kc加密子秘钥K1和第一设备的设备ID，生成第一设备的预设第一加密数据为Kc*(K1/id1)。以及，秘钥服务器20还为第二设备分配子秘钥K2，并利用原秘钥Kc加密子秘钥K2和第二设备的设备ID，生成第二设备的预设第一加密数据为Kc* (K2/id2)。最后，秘钥服务器20将Kc*(K1/id1)发送给第一设备，以及将Kc*(K2/id2)发送给第二设备。

请参阅图3和图7，本申请实施例提供了一种设备认证方法，该设备认证方法可以由区块链30中的任一个节点31执行。其中，在任一个外部设备发起对另一个外部设备的访问之前，该外部设备需要先向区块链30中的任一个节点31进行设备认证，并在设备认证通过后，该外部设备才能够发起对另一个外部设备的访问。为便于理解，本实施例以第一设备为需要发起访问的外部设备，第二设备为需要被访问的外部设备为例对设备认证方法进行说明。

具体的，该设备认证方法可以包括：步骤S101、步骤S201和步骤S301。

步骤S101：接收所述第一设备发送的设备认证请求。

步骤S201：对所述设备认证请求中携带的所述第一设备的第一ID相关数据进行认证，以及对从所述第二设备获取的所述第二设备的第二ID相关数据也进行认证。

步骤S301：确定所述第一ID相关数据和所述第二ID相关数据均认证通过，向所述第一设备发送认证通过的结果，使得所述第一设备基于所述结果向所述第二设备发起访问。

由于区块链30中的任一个节点31以执行设备认证方法的流程大致相同，为便于理解，本实施例以区块链30中的节点A1执行该设备认证方法为例，对设备认证方法的各流程进行详细说明。

步骤S101：接收所述第一设备发送的设备认证请求。

在第一设备需要访问第二设备时，第一设备根据自身的控制程序，确定需要先向节点A1发起设备认证。其中，节点A1对第一设备的设备认证本质可以是对第一设备的设备ID进行认证。基于此，第一设备可以生成与自身的设备ID相关的第一ID相关数据，并基于该第一ID相关数据生成携带该第一ID相关数据的设备认证请求。

作为生成第一ID相关数据的示例性方式，第一设备可以利用加密算法例如Hash算法对自身的设备ID和预设第一加密数据进行加密，生成第一设备的预设第二加密数据。从而第一设备便利用自身的设备ID、预设第一加密数据和预设第二加密数据生成设备认证请求，使得设备认证请求中携带该第一设备的设备ID、预设第一加密数据和预设第二加密数据；其中，第一ID相关数据包括该第一设备的设备ID、预设第一加密数据和预设第二加密数据。

第一设备将生成的设备认证请求发送至节点A1，相应的，节点A1便接收到第一设备的设备认证请求。

继续基于前述的示例进行说明。

第一设备通过Hash算法对自身的id1和Kc*(K1/id1)进行加密，生成第一设备的预设第二加密数据为H(Kc*(K1/id1))。第一设备基于第一设备的设备ID为id1、第一设备的预设第一加密数据为Kc*(K1/id1)、第一设备的预设第二加密数据为H(Kc*(K1/id1))，第一设备便可以生成设备认证请求为Msg＝E(id1/Kc*(K1/id1)/H(Kc*(K1/id1)))，并将该Msg发送给节点A1。

进一步的，节点A1在接收到设备认证请求后，节点A1可以继续执行步骤S201。

步骤S201：对所述设备认证请求中携带的所述第一设备的第一ID相关数据进行认证，以及对从所述第二设备获取的所述第二设备的第二ID相关数据也进行认证。

本实施例中，为提高安全性，节点A1不仅需要对第一设备进行认证，节点设备还可以对第二设备也进行认证，并在第一设备和第二设备都认证通过后，第一设备才能够发起对第二设备的访问。那么，节点A1在获取到设备认证请求后，通过对设备认证请求进行解析，节点设备A1可以根据例如设备认证请求的报文类型或报文格式，确定需要向第二设备发送ID相关数据获取请求，以通过获取到第二设备的第二ID相关数据而对第二设备进行认证。

本实施例中，第二设备预先可以利用EDA(Event Driven Architecture，事件驱动架构)向区块链30订阅授权服务事件，使得节点A1可以主动向第二设备发生各种事件的执行结果。基于此，节点A1可以生成ID相关数据获取请求，并基于通过EDA将ID相关数据获取请求发送至第二设备。

相应的，第二设备接收到该相关数据获取请求，接收到相关数据获取请求表示第一设备需要向第二设备发起访问(但现在还未发起)，第二设备可以根据自身的控制程序判断是否允许第一设备访问。

若确定不允许第一设备访问，第二设备向区块链30发送用于表示不允许访问的应答报文。相应的，区块链30中的节点A1可以接收到该用于表示不允许访问的应答报文，根据该用于表示不允许访问的应答报文，节点 A1可以基于EDA直接向第一设备发送认证未通过的认证结果。

若确定允许第一设备访问，第二设备可以生成携带有第二ID相关数据的应答报文，并将该应答报文发送至节点A1，其中，第二设备生成携带有第二ID相关数据的应答报文的方式与第一设备生成设备认证请求方式的方式相同，在此就不再累述。相应的，节点A1接收到该响应报文，并通过解析该响应报文而获得第二设备的第二ID相关数据。

需要说明的是，节点A1对第一设备和第二设备的认证不一定是同步的，也可以是异步的。比如，在同步情况下，节点A1等到获取到响应报文后，同步的对设备认证请求中携带的第一ID相关数据和响应报文中携带的第二ID相关数据进行认证。又比如，在异步情况下，节点A1获取到设备认证请求后，便开始对设备认证请求中携带的第一ID相关数据进行认证，无需等待对响应报文的获取。

下面将分别对节点A1对第一ID相关数据和对第二ID相关数据进行认证的具体流程进行详细说明。

针对第一ID相关数据进行认证：

示例性的，节点A1解析获得第一ID相关数据后，节点A1利用Hash 算法对第一ID相关数据中包含的第一设备的设备ID和第一设备的预设第一加密数据进行加密，从而生成第一设备的新的第二加密数据。那么节点 A1可以将第一设备的新的第二加密数据与第一ID相关数据中包含的第一设备的预设第二加密数据匹配，并判断两者是否匹配。

若节点A1确定第一设备的新的第二加密数据与第一ID相关数据中包含的第一设备的预设第二加密数据不匹配，其表示第一设备上保存的第一 ID相关数据和/或设备ID可能被篡改，因此认证不通过。本实施例中，第一设备预先也可以利用EDA向区块链30订阅授权服务事件，使得节点A1 也可以主动向第一设备发送各种事件的执行结果。故节点A1基于EDA向第一设备发送认证未通过的认证结果，并终止执行第二设备的认证流程。

若节点A1确定第一设备的新的第二加密数据与第一ID相关数据中包含的第一设备的预设第二加密数据匹配，其表示第一设备上保存的第一ID 相关数据和/或设备ID没有被篡改，节点A1可以继续进行接下来的认证流程。

在接下来的认证流程中，节点A1利用子秘钥恢复出原秘钥。需要说明的是，由于在秘钥分割时采用门限秘密分割算法，故在秘钥恢复时，利用分割出的多个子秘钥中的部分子秘钥便可以恢复出原秘钥。对应的，节点A1可以随机的从保存有多个子秘钥的多个节点中确定出至少部分其它节点，并从至少部分其它节点中获取每个其它节点保存的子秘钥。这样，节点A1便可以利用秘钥分割恢复算法对至少部分子秘钥进行处理，从而恢复出原秘钥。

节点A1利用恢复出的原秘钥可以对第一ID相关数据中包含的第一设备的预设第一加密数据进行解密，获得第一设备的解密的设备ID和第一设备的解密的子秘钥。

进一步的，为实现对第一设备的进一步验证，区块链30中每个节点31 的分布式账本中都保存了每个外部设备的设备ID。相应的，节点A1中也保存了第一设备的设备ID。基于此，节点A1可以将第一设备的解密的设备ID与自身存储的该第一设备的设备ID匹配，并判断第一设备的解密的设备ID与自身存储的该第一设备的设备ID是否匹配。节点A1还可以将第一设备的解密的子秘钥与从区块链30上获取的该第一设备的子秘钥匹配，并也判断第一设备的解密的子秘钥与从区块链30上获取的该第一设备的子秘钥是否匹。

若节点A1确定第一设备的解密的设备ID和第一设备的解密的子秘钥中有任一个不匹配，其表示第一设备上保存的设备ID和/或子秘钥可能被篡改，因此认证不通过。故节点A1也基于EDA向第一设备发送认证未通过的认证结果，并终止执行第二设备的认证流程。

若节点A1确定第一设备的解密的设备ID和第一设备的解密的子秘钥均匹配，其表示第一设备上保存的设备ID和/或子秘钥没有被篡改，故可以确定对第一设备的认证通过。

针对第二ID相关数据进行认证：

示例性的，节点A1解析获得第二ID相关数据后，节点A1利用Hash 算法对第二ID相关数据中包含的第二设备的设备ID和第二设备的预设第一加密数据进行加密，从而生成第二设备的新的第二加密数据。那么节点A1可以将第二设备的新的第二加密数据与第二ID相关数据中包含的第二设备的预设第二加密数据匹配，并判断两者是否匹配。

若节点A1确定第二设备的新的第二加密数据与第二ID相关数据中包含的第二设备的预设第二加密数据不匹配，其表示第二设备上保存的第二 ID相关数据和/或设备ID可能被篡改，因此认证不通过。本实施例中，由于第二设备预先利用EDA向区块链30订阅授权服务事件，故节点A1可以主动向第二设备发送各种事件的执行结果。因此，节点A1基于EDA向第二设备发送认证未通过的认证结果，并终止执行第一设备的认证流程。

若节点A1确定第二设备的新的第二加密数据与第二ID相关数据中包含的第二设备的预设第二加密数据匹配，其表示第二设备上保存的第二ID 相关数据和/或设备ID没有被篡改，节点A1可以继续进行接下来的认证流程。

在接下来的认证流程中，节点A1也可以利用子秘钥恢复出原秘钥，但需要说明的是，若节点A1对第二设备认证到当前流程时，节点A1已经在对第一设备的认证流程中回复出了原秘钥，那么节点A1可以直接获取该原秘钥，否则，便需要恢复出原秘钥。节点A1利用恢复出的或者直接获取的原秘钥可以对第二ID相关数据中包含的第二设备的预设第二加密数据进行解密，获得第二设备的解密的设备ID和第二设备的解密的子秘钥。

进一步的，节点A1也可以将第二设备的解密的设备ID与自身存储的该第二设备的设备ID匹配，并判断第二设备的解密的设备ID与自身存储的该第二设备的设备ID是否匹配。节点A1还可以将第二设备的解密的子秘钥与从区块链30上获取的该第二设备的子秘钥匹配，并也判断第二设备的解密的子秘钥与从区块链30上获取的该第二设备的子秘钥是否匹。

若节点A1确定第二设备的解密的设备ID和第二设备的解密的子秘钥中有任一个不匹配，其表示第二设备上保存的设备ID和/或子秘钥可能被篡改，因此认证不通过。故节点A1也基于EDA向第二设备发送认证未通过的认证结果，并终止执行第一设备的认证流程。

若节点A1确定第二设备的解密的设备ID和第二设备的解密的子秘钥均匹配，其表示第二设备上保存的设备ID和/或子秘钥没有被篡改，故可以确定对第二设备的认证通过。

继续基于前述的示例进行说明。

对于第一设备：

节点A1解析第一设备发送的设备认证请求Msg＝E(id1/Kc*(K1/id1) /H(Kc*(K1/id1)))，节点A1可以获得第一设备的设备ID为id1、第一设备的预设第一加密数据为Kc*(K1/id1)、第一设备的预设第二加密数据为H(Kc*(K1/id1))。节点A1通过Hash加密id1和Kc*(K1/id1)，生成第一设备的新的第二加密数据为H’(Kc*(K1/id1))。若节点A1确定H’(Kc*(K1/id1)与H(Kc*(K1/id1))相同，节点A1可以从节点 A6获取节点A6存储的子秘钥K2，并利用自身存储的子秘钥K1和获取的子秘钥K2恢复出原秘钥Kc。节点A1利用原秘钥Kc解密Kc*(K1/id1)，获得第一设备的解密的设备ID为id1’，并获得第一设备的解密的子秘钥K1’。若节点A1确定id1’与自身存储的第一设备的设备ID为id1相同，以及确定K1’与自身存储的第一设备的子秘钥K1相同，节点A1确定第一设备认证通过。

对于第二设备：

节点A1解析第二设备发送的应答报文Msg＝E(id2/Kc*(K2/id2)/H (Kc*(K2/id2)))，节点A1可以获得第二设备的设备ID为id2、第二设备的预设第一加密数据为Kc*(K2/id2)、第二设备的预设第二加密数据为H(Kc*(K2/id2))。节点A1通过Hash加密id2和Kc*(K2/id2)，生成第二设备的新的第二加密数据为H’(Kc*(K2/id2))。若节点A1确定H’(Kc*(K2/id2)与H(Kc*(K2/id2))相同，且节点A1在对第一设备的认证过程中已经先恢复出了原秘钥，节点A1则直接利用原秘钥Kc解密Kc*(K2/id2)，获得第二设备的解密的设备ID为id2’，并获得第二设备的解密的子秘钥K2’。若节点A1确定id2’与自身存储的第二设备的设备 ID为id2相同，以及确定K2’与获取的第二设备的子秘钥K2相同，节点 A1则确定第二设备认证通过。

节点A1确定第一设备和第二设备认证通过后，便向第一设备和第二设备发送用于表示认证通过的认证结果，相应的，第一设备获取认证通过的认证结果，可以确定向第二设备发起访问。

请参阅图8，本申请实施例提供了一种设备访问方法，设备访问方法可以由访问控制系统40中多个节点41中的任一个节点41执行，该设备访问方法可以包括：步骤S110、步骤S210、步骤S310和步骤S410。

步骤S110：接收第一设备发送的访问请求。

步骤S210：根据所述访问请求，从数据库中获取所述第一设备的信任值和第二设备的信任值。

步骤S310：确定所述第一设备的信任值和所述第二设备的信任值均大于预设信任值，获取所述第二设备的控制策略。

步骤S410：确定所述控制策略与所述访问请求中携带的控制策略匹配，并将所述访问请求转发至所述第二设备。

结合参阅图3、图4、图8和图9，由于任一个节点41以执行执行设备访问方法的流程大致相同，为便于理解，本实施例以访问控制系统40中的 PDP节点B1、PEP节点B2、PAP节点B3和PIP节点B4如何配合执行该设备认证方法为例进行说明。需要说明的是，由于PDP、PEP、PAP、PIP 可以分布式部署在不同的物理节点41上，或者也可以集中式的部署在同一物理节点41上，因此，PDP节点B1、PEP节点B2、PAP节点B3和PIP 节点B4可以理解为不同的各物理节点41或者理解为同一物理节点41，对此，本实施例并不作具体限定。

在第一设备获得认证通过的认证结果后，为进一步提高访问的安全性，第一设备可以先生成平台认证请求，并向PEP节点B2发送该平台认证请求，其中，平台认证请求中携带有第一设备的认证结果、第一设备所属平台的第一平台信息和第二设备所属平台的第二平台信息，平台可以是设备的制造商例如第一设备为空调，第一设备所属平台可以为X空调企业。

相应的，PEP节点B2接收该平台认证请求，并通过解析该平台认证请求获取到第一设备的认证结果、第一平台信息和第二平台信息。PEP节点 B2基于该第一设备的认证结果可以确定第一设备通过了设备认证，PEP节点B2便可以进一步处理第一平台信息和第二平台信息。

本实施例中，访问控制系统40内预设了平台信息数据库，该平台信息数据库可以部署在访问控制系统40的任一个节点41上，该平台信息数据库中存储有每个外部设备所属平台的平台信息，以及还存储每个平台信息关联的其它平台的平台信息。其中，平台信息数据库中两个平台信息具有关联关系则表示对应的两个平台互信。

PEP节点B2在确定第一设备通过了设备认证后，PEP节点B2通过平台信息数据库，在平台信息数据库中查找第一平台信息和第二平台信息的关联关系。

若在平台信息数据库未查找第一平台信息和第二平台信息的关联关系，其表示平台认证失败，PEP节点B2可以生成用于表示平台认证失败的认证结果，并将认证结果发送至第一设备。

若在平台信息数据库查找第一平台信息和第二平台信息的关联关系，其表示平台认证成功，PEP节点B2可以生成用于表示平台认证成功的认证结果，并将认证结果发送至第一设备。

相应的，若第一设备接收到用于表示平台认证失败的认证结果，其表示第一设备无法向第二设备发起访问，第一设备终止执行对第二设备的访问流程。

若第一设备接收到用于表示平台认证成功的认证结果，其表示第一设备可以向第二设备发起访问，第一设备继续执行对第二设备的访问流程。

第一设备通过继续执行对第二设备的访问流程，第一设备可以生成访问请求，并将访问请求发送至PEP节点B2。其中，该访问请求中可以携带第一设备的设备ID、第二设备的设备ID和对第二设备的控制策略。

相应的，PEP节点B2获取到该访问请求，并将访问请求转发给PDP 节点B1，使得PDP节点B1执行步骤S110。

步骤S110：接收第一设备发送的访问请求。

PDP节点B1可以将该访问请求进行报文格式转换，转换成PAP节点 B4能够发起数据查询的报文格式，例如转换成AAR(Access Attribute Request，访问控制属性请求)。PDP节点B1将访问请求转换后，便将转换后的访问请求转发至PAP节点B4，使得PAP节点B4继续执行步骤S210。

步骤S210：根据所述访问请求，从数据库中获取所述第一设备的信任值和第二设备的信任值。

本实施例中，访问控制系统40内还预设了设备属性数据库、信任值数据库和环境属性数据库，该设备属性数据库、信任值数据库和环境属性数据库可以部署在访问控制系统40中的同一个节点41上，或还可以分别部署在不同的各节点41上。其中，设备属性数据库中存储了每个外部设备全部的属性，外部设备的属性可以用于表示外部设备可以处于哪种状态，例如，外部设备为空调，空调的属性可以包括：运行、关闭、制冷、制热、送风、除湿、风速低、风速中和风速高等；信任值数据库中存储了每个外部设备的信任值；以及，环境属性数据库中则存储外部环境的属性，外部环境的属性可以用于表示外部环境可以处于哪种状态，例如，外部环境的属性可以包括：环境温度、环境湿度和风速等。

于本实施例中，PAP节点B4可以基于转换后的访问请求，访问属性数据库、信任值数据库和环境属性数据库，以从属性数据库、信任值数据库和环境属性数据库中查询到第一设备的信任值、第二设备的信任值、第二设备的属性和环境属性。PAP节点B4还可以将查询到第一设备的信任值、第二设备的信任值、第二设备的属性和环境属性反馈给PDP节点B1，以便 PDP节点B1继续执行步骤S310。

步骤S310：确定所述第一设备的信任值和所述第二设备的信任值均大于预设信任值，获取所述第二设备的控制策略。

PDP节点B1中预先设置有预设信任值，利用该预设信任值，PDP节点 B1可以判断第一设备的信任值和第二设备的信任值是否均大于预设信任值。

若PDP节点B1确定第一设备的信任值和第二设备的信任值中任一个不大于预设信任值，其表示信任值低于预设信任值的第一设备或第二设备的信任度较低，不允许进行访问。PEP节点B2可以生成用于表示信任度认证失败的认证结果，并将认证结果发送至第一设备，使得第一设备终止执行对第二设备的访问流程。

若PDP节点B1确定第一设备的信任值和第二设备的信任均大于预设信任值，其表示第一设备或第二设备的信任度均较高，允许进行访问。PEP 节点B2可以将第二设备的属性和环境属性发送给PAP节点B3，使得PAP 节点B3将第二设备的属性和环境属性发送到区块链30上，并使得区块链 30上的某一个节点31例如节点A1获取到该第二设备的属性和环境属性。

继续对前述的示例进行说明。

PDP节点B1预先设置的预设信任值为75，而第一设备的信任值为78 且第二设备的信任值为84。故通过匹配，PDP节点B1可以确定第一设备的信任值78且第二设备的信任值84均大于预设信任值75。

本实施例中，区块链30内预设了控制策略数据库，该控制策略数据库可以部署在区块链30中的任一个节点31上，该控制策略数据库中存储有每个外部设备的控制策略。其中，控制策略可以表示该外部设备在各情况下的运行逻辑。

继续对前述示例性进行说明，例如第二设备为空调，第二设备的控制策略可以包括：在处于关闭时调整为运行，并在环境温度低于10℃时进行制热。

本实施例中，为提高控制策略数据库存储效率，控制策略数据库中存储的控制策略可以包含用于表示访问逻辑的表达式，而表达式中则包含符号和参数。

继续对前述示例性进行说明，在第二设备为空调的基础上，前述的控制策略可以具体表示为：down→up，t＜10→heat。

可以理解到，控制策略采用这种表示方式可以在表示出运行逻辑的基础上进一步简化，缩小其字节大小，实现提高控制策略数据库存储效率。

进一步的，节点A1获取到该第二设备的属性和环境属性，节点A1可以访问控制策略数据库，并判断是否能够从控制策略数据库中预设的控制策略中查找到与第二设备的属性和环境属性匹配的第二设备的控制策略。

需要说明的是，节点A1从控制策略数据库查找匹配的第二设备的控制策略的前提为第一设备和第二设备处于同一信任域，若第一设备和第二设备处于不同的信任域，节点A1无法从控制策略数据库查找匹配的第二设备的控制策略。其中，设备位于同一信任域内表示所有设备相互之间都可以是可信的；但若设备位于不同信任域，那么来自不同信任域的设备相互之间则不一定是可信的。一个信任域所涵盖的设备数量可根据实际需求进行选择，例如本实施例中，一个信任域可以涵盖对应的一个分布式访问控制系统10中所有设备，即一个分布式访问控制系统10中所有设备都属于同一信任域内，但来自不同分布式访问控制系统10中设备则属于不同的信任域。

但值得注意的是，信任域所涵盖的设备的范围并不限于本实施例中所述的范围。例如，第一设备、分布式访问控制系统10中的秘钥服务器20 和访问控制系统40可以属于一个信任域；而第二设备、其它的分布式访问控制系统中的秘钥服务器和访问控制系统可以属于另一个信任域。这种情况下，区块链30可以是独立与两个信任域的存在。可以理解为，区块链30 同时服务于两个信任域，即区块链30也同时服务于访问控制系统40和其它访问控制系统，换言之，访问控制系统40和其它访问控制系统共用一个区块链30。

为便于更好的理解本方案，下面以各自的信任域拥有各自对应的区块链为例(即每个分布式访问控制系统都包含对应的一个区块链)，分别对第一设备和第二设备处于同一信任域，以及不同信任域处如何进行访问控制进行详细说明。

结合图2至图4，参阅图8和图9，若节点A1从控制策略数据库查找到与第二设备的属性和环境属性匹配的第二设备的控制策略，其表示第一设备和第二设备处于同一信任域。那么，节点A1可以将查找到的第二设备的控制策略发送给PAP节点B3，使得PAP节点B3将第二设备的控制策略转发给PDP节点B1。

进一步的，PDP节点B1可以继续执行步骤S410。

步骤S410：确定所述控制策略与所述访问请求中携带的控制策略匹配，并将所述访问请求转发至所述第二设备。

若确定控制策略与访问请求中携带的对第二设备的控制策略不匹配，其表示第一设备对第二设备的访问控制不满足第二设备自身的运行逻辑，故PDP节点B1可以通过PEP节点B2向第一设备和第二设备发送用于表示不允许访问的匹配结果。

继续对前述示例性进行说明，若访问请求中携带的对第二设备的控制策略具体表示为：down→up，t＜10→cold。故PDP节点B1可以确定“down →up，t＜10→cold”与“down→up，t＜10→heat”不匹配。

若确定控制策略与访问请求中携带的对第二设备的控制策略匹配，其表示第一设备对第二设备的访问控制满足第二设备自身的运行逻辑，故PDP节点B1通过PEP节点B2可以向第一设备发送用于表示允许访问的匹配结果。此外，故PDP节点B1还将第一设备发送访问请求通过PEP节点 B2转发至第二设备，使得第二设备根据该访问请求执行相应的动作。

继续对前述示例性进行说明，若访问请求中携带的对第二设备的控制策略具体表示为：down→up，t＜10→heat。故PDP节点B1可以确定“down →up，t＜10→cold”与“down→up，t＜10→heat”匹配。PDP节点B1还将访问请求通过PEP节点B2转发至第二设备(空调)，那么第二设备(空调)通过执行该访问请求中的控制策略，第二设备(空调)便开始运行，并开始制热。

本实施例中，第一设备接收的用于表示允许访问的匹配结果，其表示对第二设备的访问成功，第一设备可以向秘钥服务器20发送信用更新指示。秘钥服务器20可以根据信用更新指示，更新第一设备的信任值，并将第一设备更新后的信任值发送到信任值数据库，使得信任值数据库也对应更新。

与此同时，在第二设备根据该访问请求成功执行相应的动作后，其表示第二设备被访问成功，第二设备也可以向秘钥服务器20发送信用更新指示。秘钥服务器20可以根据信用更新指示，更新第二设备的信任值，并也将第二设备更新后的信任值发送到信任值数据库，使得信任值数据库也对应更新。

继续对前述示例性进行说明，秘钥服务器20接收到第一设备发送的信用更新指示，以及接收到第二设备发送的信用更新指示。秘钥服务器20可以将第一设备的信任值从78更新为79，以及将第二设备的信任值从84更新为85，并将更新后的信任值79和更新后的信任值85同步到信任值数据库，使得信任值数据库中也对应更新。

结合图2至图4，参阅图10，若节点A1从控制策略数据库无法查找到与第二设备的属性和环境属性匹配的第二设备的控制策略，其表示第一设备和第二设备处于不同一信任域，例如第一设备处于第一信任域而第二设备处于第二信任域。那么，节点A1可以从控制策略中查找到第一设备的控制策略，并将查询到的第一设备的控制策略返回给PAP节点B3，使得PAP 节点B3将该查询结果转发至PDP节点B1。

相应的，PDP节点B1接收到第一设备的控制策略，其表示第二设备与第一设备不属于同一信任域，需要发起跨域访问。因此，PDP节点B1可以向跨域认证系统50发送跨域认证请求。其中，该跨域认证请求中携带有第一设备的设备ID和第二设备的设备ID。

本实施例中，跨域认证系统50可以部署在独立于信任域存在的物理设备上，该物理设备可以是终端或者服务器，其中，终端或者服务器的类型可以参考前述，在此就不再累述。跨域认证系统50中存储了每个信任域的参数例如信任域包含的设备数量和信任域的综合信任值等。跨域认证系统 50接收到跨域认证请求后，跨域认证系统50通过解析跨域认证请求获取到第一设备的设备ID和第二设备的设备ID。跨域认证系统50根据第一设备的设备ID可以确定第一设备属于第一信任域，以及根据第二设备的设备ID 可以确定第二设备属于第二信任域。

进一步的，跨域认证系统50可以根据第一信任域的参数和第二信任域的参数，确定出第一信任域和第二信任域相互之间的域间信任值。其中，确定域间信任值的具体流程可以参考现有的流程进行理解，本实施例就不再累述。

跨域认证系统50中也预设有域间信任阈值，并通过该域间信任阈值判断确定出域间信任值是否大于该预设的域间信任阈值。

若确定域间信任值不大于预设的域间信任阈值，其表示第一信任域和第二信任域之间的信任度无法满足设备的跨域访问。跨域认证系统50可以生成用于表示跨域访问认证失败的认证结果，并将其发送至PDP节点B1。以通过PDP节点B1和PEP节点B2将该认证结果转发至第一设备，使得第以设备获取访问失败。

若确定域间信任值大于预设的域间信任阈值，其表示第一信任域和第二信任域之间的信任度满足设备的跨域访问。跨域认证系统50可以生成用于表示跨域访问认证成功的认证结果，并将其发送至PDP节点B1。

相应的，PDP节点B1接收到用于表示跨域访问认证成功的认证结果后， PDP节点B1可以向PIP节点B4发送第一设备的属性获取请求，使得PIP 节点B4从设备属性数据库中查询到送第一设备的属性，并将第一设备的属性返回给PDP节点B1。PDP节点B1再将第一设备发送的访问请求、第一设备的属性和控制策略一并发送给跨域认证系统50。

跨域认证系统50接收到第一设备发送的访问请求、第一设备的属性和控制策略后、跨域认证系统50可以将第一设备发送的访问请求、第一设备的属性和控制策略转发至属于第二信任域的分布式控制访问系统60。

本实施例中，分布式控制访问系统60包括：访问控制系统70、区块链 80和秘钥服务器(图中未示出)。

相应的，访问控制系统70中的PEP节点B8可以接收到跨域认证系统 50转发的第一设备发送的访问请求、第一设备的属性和控制策略。由于跨域的两个设备的运行逻辑可能有所差异，而为实现成功访问第二设备，可以利用区块链80将第一设备的控制策略与第二设备的控制策略合并，使得获得的第二设备的新的控制策略与第一设备相关，从而实现第一设备成功的访问第二设备。

具体的，PEP节点B8可以将第一设备发送的访问请求、第一设备的属性和控制策略一并转发至PDP节点B9。PDP节点B9也将该访问请求进行格式转换，并将转换后的访问请求发送至PIP节点B11。PIP节点B11根据转换后的访问请求中携带的第二设备的设备ID，可以从属于访问控制系统 70的设备属性数据库中查询到第二设备的属性，并将查找到第二设备的属性返回给PDP节点B9。其中，属于访问控制系统70的设备属性数据库的部署方式可以参阅前述理解，在此不再累述。

进一步的，PDP节点B9可以将第二设备的属性、第一设备的属性和控制策略通过PAP节点B10一并发送到区块链80上的任一节点81例如发送到节点A8。

相应的，节点A8可以根据第二设备的属性，可以从属于区块链80的控制策略数据库中预设的控制策略中查询到第二设备的控制策略。其中，属于区块链80的控制策略数据库的部署方式可以参阅前述理解，在此也不再累述。

节点A8基于获取的第一设备的控制策略和查询到的第二设备的控制策略，可以判断第一设备的控制策略与第二设备的控制策略的一致性是否满足预设标准。其中，判断两种控制策略的一致性的具体流程可以参考现有的流程进行理解，本实施例就不再累述。

若节点A8确定一致性满足预设标准，其表示第一设备的控制策略与第二设备的控制策略在控制逻辑比较接近，无需进行控制逻辑的合成，可以利用第二设备的控制逻辑直接执行访问。基于此，节点A8可以将第二设备的控制策略发送至PAP节点B10，使得PAP节点B10将第二设备的控制策略再转发给PDP节点B9。

类似于前述的流程，PDP节点B9可以判断访问请求中携带的对第二设备的控制策略是否与接收的第二设备的控制策略匹配。若匹配，PDP节点 B9通过PEP节点B8将访问请求转发至第二设备，使得第二设备根据访问请求执行相应的动作。与此同时，PDP节点B9还生成用于表示允许访问的匹配结果，并依次通过第二信任域中各设备、跨域认证系统50和第一信任域中各设备转发该匹配结果，使得第一信任域内的第一设备获取到该匹配结果。若不匹配，PDP节点B9则生成用于表示不允许访问的匹配结果，并依次通过第二信任域中各设备、跨域认证系统50和第一信任域中各设备转发该匹配结果，使得第一信任域内的第一设备获取到该匹配结果。

若节点A8确定一致性不满足预设标准，其表示第一设备的控制策略与第二设备的控制策略在控制逻辑上并不相似，需要进行控制逻辑的合成。基于此，节点A8可以根据第一设备的属性，进一步判断是否能够将第一设备的控制策略与第二设备的控制策略合并。其中，根据第一设备的属性判断是否能够将第一设备的控制策略与第二设备的控制策略合并的具体流程可以参考现有的流程进行理解，本实施例就不再累述。

若确定不能够合并，其表示第一设备无法访问第二设备，因此，节点 A8可以生成用于表示不无法访问的判断结果，并依次通过第二信任域中各设备、跨域认证系统50和第一信任域中各设备转发该判断结果，使得第一信任域内的第一设备获取到该判断结果。

若确定能够合并，其表示通过策略合并可以使得第一设备访问第二设备。因此，节点A8可以将第一设备的控制策略和第二设备的控制策略合并，生成第二设备的新的控制策略。其中，控制策略合并的具体流程可以参考现有的流程进行理解，本实施例就不再累述。获得新的控制策略后，节点 A8不仅可以将新的控制策略同步更新到属于区块链80的控制策略数据库中，还可以将新的控制策略通过PAP节点B10发送给PDP节点B9。

相应的，类似于前述的流程，PDP节点B9可以判断访问请求中携带的对第二设备的控制策略是否与新的控制策略匹配。若匹配，PDP节点B9通过PEP节点B8将访问请求转发至第二设备，使得第二设备根据访问请求执行相应的动作。与此同时，PDP节点B9还生成用于表示允许访问的匹配结果，并依次通过第二信任域中各设备、跨域认证系统50和第一信任域中各设备转发该匹配结果，使得第一信任域内的第一设备获取到该匹配结果。若不匹配，PDP节点B9则生成用于表示不允许访问的匹配结果，并依次通过第二信任域中各设备、跨域认证系统50和第一信任域中各设备转发该匹配结果，使得第一信任域内的第一设备获取到该匹配结果。

需要说明的是，执行跨域访问时，若第一设备成功访问第二设备，第一设备在获取用于表示允许访问的匹配结果后，可以在属于第一信任域的秘钥服务器20中更新自身的信任值，而第二设备则在成功执行相应的控制动作后，在属于第二信任域的秘钥服务器(图中未示出)中更新自身的信任值。或者，若第一设备访问第二设备失败，第一设备在获取用于表示不允许访问的匹配结果后，可以在属于第一信任域的秘钥服务器20中更新自身的信任值；此时，第二设备不进行信任值的更新。

还需要说明的是，为节约区块链30和区块链80的开销，区块链30中预设有对应的事件数据库，以及区块链80中也预设有对应的事件数据库。由于区块链30和区块链80的原理大致相同，为避免累述，下面将以区块链30为例，对如何节约开销进行说明。

区块链30对应的事件数据库可以部署在区块链30中的任一个节点上。区块链30中的任一个节点31每一次执行一个事件操作后，任一个节点31 可以生成该事件操作的索引值，一方面将索引值同步到区块链30上其它节点31(即上链存储)，而另一方面则将该事件操作本身的相关数据发送到事件数据库中存储(即链下存储)，由于索引值的字节非常小，故可以有效降低链上的开销。

例如节点A1在确定第一ID相关数据和第二ID相关数据均认证通过后，节点A1生成用于表示认证通过的认证结果，节点A1生成认证结果的索引值，并将索引值上链，使得节点A1-节点A7中每个节点31均存储该索引值。而与此同时，节点A1将认证结果发送到事件数据库，以实现链下存储。

还需要说明的是，为实现安全的更新外部设备的属性和控制策略，在本实施例中，可以允许外部设备自身、外部设备所属的平台中的其它外部设备、或成功访问过该外部设备的其它外部设备去更新该外部设备的属性和控制策略。例如，第一设备成功访问了第二设备，那么第一设备便可以更新的第二设备的属性和控制策略，反之亦然。若更新了的属性，则发起更新的外部设备需要将更新后的属性同步到设备属性数据库中存储。若更新了的控制策略，则发起更新的外部设备需要将更新后的制策略发送到被更新的外部设备所属信任域内的区块链，例如区块链30或区块链80。

请参阅图11，本申请实施例提供了一种设备认证装置100，设备认证装置100可以应用区块链30中的任一节点31或区块链80中的任一节点81，设备认证装置100包括。

数据收发模块110，用于接收所述第一设备发送的设备认证请求；

数据处理模块120，用于对所述设备认证请求中携带的所述第一设备的第一ID相关数据进行认证，以及对从所述第二设备获取的所述第二设备的第二ID相关数据也进行认证。

所述数据收发模块110，还用于确定所述第一ID相关数据和所述第二 ID相关数据均认证通过，向所述第一设备发送认证通过的结果，使得所述第一设备基于所述结果向所述第二设备发起访问。

请参阅图12，本申请实施例提供了一种设备访问装置200，设备访问装置200应用于访问控制系统40中的任一节点41或访问控制系统70中的任一节点71，设备访问装置200包括：

数据收发模块210，用于接收第一设备发送的访问请求。

数据处理模块220，用于根据所述访问请求，从数据库中获取所述第一设备的信任值和第二设备的信任值；以及，用于确定所述第一设备的信任值和所述第二设备的信任值均大于预设信任值，获取所述第二设备的控制策略。

所述数据收发模块210，还用于确定所述控制策略与所述访问请求中携带的控制策略匹配，并将所述访问请求转发至所述第二设备。

请参阅图13，本申请实施例提供了一种秘钥处理装置300，秘钥处理装置300应用于秘钥服务器20或秘钥服务器(图中未示出)，秘钥处理装置300包括：

秘钥处理模块310，用于生成原秘钥；根据区块链中节点的数量，将所述原秘钥分割成多个子秘钥；以及，用于将每个设备的设备ID与对应的一个所述子秘钥加密，获得每个所述设备的预设第一加密数据。

数据发送模块320，用于将所述预设第一加密数据发送给对应的每个所述设备。

需要说明的是，由于所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请一些实施例还提供了一种计算机可执行的非易失的程序代码的计算机可读储存介质，该计算机可读存储介质上存储有程序代码，该程序代码被计算机运行时执行上述任一实施方式的设备认证方法的步骤、设备访问方法的步骤或秘钥处理方法的步骤。

本申请实施例所提供的设备认证方法、设备访问方法或秘钥处理方法的程序代码产品，包括存储了程序代码的计算机可读存储介质，程序代码包括的指令可用于执行前面方法实施例中的方法，具体实现可参见方法实施例，在此不再赘述。

综上所述，本申请实施例提供了一种设备认证方法、访问方法、秘钥处理方法及装置、区块链。由于在对第一设备进行认证的同时，也要对应的对第二设备进行认证，在第一设备和第二设备的认证均通过后，才允许第一设备发起对第二设备的访问。因此，通过双向认证可确定发起访问的设备和被访问的设备都是安全的，故提高了访问的安全性。

以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (13)

1.一种设备认证方法，其特征在于，所述方法包括：

接收第一设备发送的设备认证请求；

对所述设备认证请求中携带的所述第一设备的第一ID相关数据进行认证，以及对从第二设备获取的所述第二设备的第二ID相关数据也进行认证；

确定所述第一ID相关数据和所述第二ID相关数据均认证通过，向所述第一设备发送认证通过的结果，使得所述第一设备基于所述结果向所述第二设备发起访问；

在确定所述第一ID相关数据和所述第二ID相关数据均认证通过，向所述第一设备发送认证通过的结果之后，所述方法还包括：

接收所述第一设备发送的访问请求；

根据所述访问请求，从数据库中获取所述第一设备的信任值和所述第二设备的信任值；

确定所述第一设备的信任值和所述第二设备的信任值均大于预设信任值，获取所述第二设备的控制策略；

确定所述控制策略与所述访问请求中携带的控制策略匹配，并将所述访问请求转发至所述第二设备。

2.根据权利要求1所述的设备认证方法，其特征在于，所述第一ID相关数据包括设备ID、预设第一加密数据和预设第二加密数据，所述预设第二加密数据为预先通过加密所述设备ID和所述预设第一加密数据获得，对所述设备认证请求中携带的所述第一设备的第一ID相关数据进行认证，包括：

加密所述设备ID和所述预设第一加密数据，生成新的第二加密数据；

将所述新的第二加密数据与所述预设第二加密数据匹配。

3.根据权利要求2所述的设备认证方法，其特征在于，所述方法应用于区块链中的任一节点，所述预设第一加密数据为通过加密所述设备ID和子秘钥获得，在将所述新的第二加密数据与所述预设第二加密数据匹配之后，所述方法还包括：

确定所述新的第二加密数据与所述预设第二加密数据匹配，获取所述区块链上至少部分其它节点中每个所述其它节点保存的子秘钥，其中，所述子秘钥，为原秘钥根据所述区块链节点数量分割后，同步到所述区块链上的子秘钥；

通过每个所述其它节点保存的子秘钥，恢复出所述原秘钥；

通过所述原秘钥解密所述预设第一加密数据，获得解密的所述设备ID和解密的子秘钥；

将解密的所述设备ID与自身存储的所述第一设备的设备ID匹配，以及将所述解密的子秘钥与从所述区块链上获取的所述第一设备的子秘钥匹配；

对应的，在接收所述第一设备发送的设备认证请求之前，所述方法还包括：

生成所述原秘钥；

根据区块链中节点的数量，将所述原秘钥分割成多个子秘钥；

将每个设备的设备ID与所述多个子秘钥中对应的一个所述子秘钥加密，获得每个所述设备的预设第一加密数据；

将所述预设第一加密数据发送给对应的每个所述设备。

4.根据权利要求3所述的设备认证方法，其特征在于，在确定所述第一ID相关数据和所述第二ID相关数据均认证通过后，所述方法还包括：

生成所述结果的索引值；

将所述索引值同步到所述区块链上所有的所述其它节点，并将所述结果发送到所述区块链下的数据库存储。

5.根据权利要求1-3任一权利要求所述的设备认证方法，其特征在于，所述第一设备与所述第二设备位于同一信任域内，向所述第一设备发送认证通过的结果之后，所述方法还包括：

在所述第一设备通过访问控制系统访问所述第二设备的过程中，接收所述访问控制系统发送的所述第二设备的属性；

根据所述属性，从预设的控制策略中确定出所述第二设备的控制策略；

将所述第二设备的控制策略发送至所述访问控制系统，使得所述访问控制系统根据所述第二设备的控制策略确定是否允许所述第一设备访问所述第二设备。

6.根据权利要求1-3任一权利要求所述的设备认证方法，其特征在于，所述第一设备与所述第二设备位于不同的信任域内，向所述第一设备发送认证通过的结果之后，所述方法还包括：

在所述第一设备通过访问控制系统访问所述第二设备的过程中，接收所述访问控制系统发送的所述第二设备的属性、所述第一设备的属性和控制策略；

根据所述第二设备的属性从预设的控制策略中确定出所述第二设备的控制策略；

判断所述第一设备的控制策略与所述第二设备的控制策略的一致性是否满足预设标准；

若不满足所述预设标准，根据所述第一设备的属性，判断是否能够将所述第一设备的控制策略与所述第二设备的控制策略合并；

若能够合并，将所述第一设备的控制策略和所述第二设备的控制策略合并，生成所述第二设备的新的控制策略；

将所述新的控制策略发送至所述访问控制系统，使得所述访问控制系统根据所述新的控制策略确定是否允许所述第一设备访问所述第二设备。

7.根据权利要求5所述的设备认证方法，其特征在于，所述控制策略包含用于表示访问逻辑的表达式，所述表达式中包含符号和参数。

8.根据权利要求6所述的设备认证方法，其特征在于，所述控制策略包含用于表示访问逻辑的表达式，所述表达式中包含符号和参数。

9.根据权利要求1所述的设备认证方法，其特征在于，在接收第一设备发送的访问请求之前，所述方法还包括：

接收所述第一设备发送的平台认证请求；

获取所述平台认证请求中携带的第一平台信息，其中，所述第一平台信息为所述第一设备所属的平台的信息；

判断所述第一平台信息与预设的第二平台信息之间是否具有信任关系，其中，所述第二平台信息为所述第二设备所属的平台的信息；

若具有，向所述第一设备发送平台认证通过的结果，使得所述第一设备基于所述结果向所述第二设备发起访问。

10.根据权利要求3所述的设备认证方法，其特征在于，在将每个设备的设备ID与对应的一个所述子秘钥加密，获得每个所述设备的预设第一加密数据之前，所述方法还包括：

从预设的数据库中获取所有的所述设备的信任值；

按所述信任值的高低将所有的所述设备排序，从所述排序中确定出数量与所述子秘钥的数量相同的多个所述设备。

11.根据权利要求10所述的设备认证方法，其特征在于，在将所述预设第一加密数据发送给对应的每个所述设备之后，所述方法还包括：

在所述设备访问成功后，接收所述设备发送的信用更新指示；

根据所述信用更新指示，更新所述设备的信任值，并将所述设备更新后的信任值发送到所述数据库。

12.一种设备认证装置，其特征在于，所述装置包括：

数据收发模块，用于接收所述第一设备发送的设备认证请求；

数据处理模块，用于对所述设备认证请求中携带的所述第一设备的第一ID相关数据进行认证，以及对从所述第二设备获取的所述第二设备的第二ID相关数据也进行认证；

所述数据收发模块，还用于确定所述第一ID相关数据和所述第二ID相关数据均认证通过，向所述第一设备发送认证通过的结果，使得所述第一设备基于所述结果向所述第二设备发起访问；

所述装置还包括：

数据收发模块，用于接收第一设备发送的访问请求；

数据处理模块，用于根据所述访问请求，从数据库中获取所述第一设备的信任值和第二设备的信任值；以及，用于确定所述第一设备的信任值和所述第二设备的信任值均大于预设信任值，获取所述第二设备的控制策略；

所述数据收发模块，还用于确定所述控制策略与所述访问请求中携带的控制策略匹配，并将所述访问请求转发至所述第二设备。

13.一种计算机可读储存介质，其特征在于，所述存储介质上存储有程序代码，当所述程序代码被所述计算机运行时，执行如权利要求1-9中任一权利要求所述的设备认证方法。

Images