NDN数字签名编码结构、物联网设备签名验证方法及系统

文档序号:24824663发布日期:2021-04-27 15:38阅读:241来源:国知局
NDN数字签名编码结构、物联网设备签名验证方法及系统
ndn数字签名编码结构、物联网设备签名验证方法及系统
技术领域
1.本发明涉及ndn(命名数据网络)物联网设备组网、信任管理和安全通信领域,特别是一种命名数据网络、物联网设备通信的方法及系统


背景技术:

2.5g通信和新型网络架构技术的快速发展为物联网带来了更多的应用场景和广阔的发展前景。当前,人们的日常生活中已充斥着各种智能设备,如:手机、可穿戴设备、智能路由器等,能感知的内容也不断增多,周边环境也不断被数字化、智能化。然而,不断涌现的应用场景和需求对物联网提出了新的挑战,特别是关于网络安全和信息隐私的需求越来越高。
3.传统tcp/ip网络中,主流安全模型是基于信道的安全(如tls和dtls),其核心是通过建立安全的通信信道来保证资源服务器与客户端之间能安全的通信。然而,经过两轮或者更多轮安全握手来建立可信信道产生的额外开销对于物联网中的小型设备间大量小数据传输性价比太低。在ndn网络中,关注焦点由数据存放位置、数据通道转移到数据内容。用户只需关心数据内容以及数据安全,而不需要知道内容在哪里以及如何获取。如此实现安全通信更为直接。此外,传统基于pki的信任管理模式依赖于第三方,在家联网这种以本地通信为主的场景会增加不必要的外部依赖,且增加了暴露家庭隐私的渠道。而ndn支持以本地信源来驱动本地化通信过程中的本地化信任管理。因此,ndn非常适合来解决物联网特别是家联网中日益增长的安全通信和隐私保护需求。
4.ndn网络通信中涉及两种主要的网络报文:兴趣包和数据包。一般情况下,兴趣包携带所请求的数据的名字和相关信息;数据包作为对兴趣包的响应携带着数据内容以及数据生产者的数字签名。数据消费者通过验证数据生产者的数字签名来确认收到的数据是真实的、完整的,而无需担心数据来源以及数据通路是否安全。
5.ndn数据包的报文格式中主要包含四部分内容:(1)数据名,用来标识数据、匹配兴趣包和指导数据包转发;(2)数据内容,携带数据原始内容或者加密内容的字节流;(3)签名元数据信息,如签名所用的密钥名字、算法参数等;(4)数字签名,将前三部分作为整体进行签名。ndn默认采用非对称密码技术进行签名。在验证数据包签名的时候,需要根据签名元数据信息获取签名用的密钥名字已确认本地是否有验证该签名所需的数字证书。若本地没有需向网络中请求该数字证书。在ndn中,数字证书也按照数据包格式进行维护,其中数据名即为数字证书名,数据内容为该数字证书认证的公钥,数字签名几位该证书签发机构或者设备生成的数字签名。获取到数字证书后需像处理数据包一样先验证数字签名。因此,在ndn安全通信过程中涉及多轮“获取数据

认证签名”的通信和计算,形成一条签名验证链。具体实现过程如下:收包方收到数据包p后,根据p的签名元数据信息向网络中请求签名密钥k的数字证书c用以验证x中携带的数字签名;c本身也是一个数据包,收包方需要进一步验证c的签名信息,因此需要向网络中请求为c签名的密钥对应的数字证书;如此反复形成一条签名验证链,直到需要用到的某个数字证书在收包方本地有存储(可信)即可结束验
证。在智能家居场景下,除数据获取外还涉及远程执行操作,比如开/关灯等。在最新的ndn架构中,采用pub

sub模式来支持这类通信。被操作设备(如智能灯)向网络中发送长期保存的兴趣包以注册服务;操作发起设备(如智能手机)向网络中发送数据包来申请服务执行相关操作。被操作设备收到相应的数据包后进行签名验证以确保信任对方再允许执行操作。
6.ndn要求在通信过程中进行数据包签名验证,且数字证书也组织成数据包在网络中传输,因此不依赖于类似pki的第三方新人管理和证书发放机构。ndn支持在本地设置根密钥和根数字证书作为信任源,通过层级化签名来生成设备密钥和设备数字证书,并根据签名链通过数据包的签名元数据信息反向构造验证链实现签名验证。由同一设备签发数字证书的两个设备可借助签发者的公钥互相验证签名建立基本信任。
7.由于ndn目前采用单一签名方式,只能构建单维验证链,即一个设备的证书只能由唯一设备签发。因此,只能进行树形信任管理。
8.目前,基于ndn物联网安全通信的本地信任管理模型研究尚少,主要基于单一签名模式进行树形信任管理,即从一个单一信源出发,通过逐层签发数字证书构造一棵信任树,具有相同父节点的两个节点互相信任可直接验证签名。在ndn安全通信过程中涉及跨父节点的签名验证,则需要从树上某个节点开始向着树根逐层进行签名验证。
9.在物联网特别是智能家居场景中,需要保障通信安全和通信隐私,同时尽量降低设备计算、通信开销和能耗。传统的基于信道的安全通信机制、基于pki的信任管理机制以及基于树形信任管理的ndn本地化信任管理机制都难以满足。
10.(1)传统的基于信道的安全通信机制,需要额外的计算和通信开销来建立安全信道;在频繁移动场景下因链路切换需重新建立安全信道,进一步增加了设备开销。
11.(2)传统的基于pki的信任管理机制依赖于第三方发放数据证书和辅助进行签名验证。而物联网特别是智能家居场景下大多是本地设备间的通信,采用传统pki机制增加了没有必要的外部依赖,也增大了隐私泄露的风险。
12.(3)ndn网络下基于传统单签名模式的树型信任管理机制容易造成根节点的拥塞进而影响整体性能。而且,若树的层次较少,则信任管理的粒度太粗。比如退化为“点-星”式,则所有设备有一个共同的父节点,互相信任且可直接验证签名,虽然效率高但本质上等同于无内部信任管理。另一方面,若树的层次较多,两叶子节点间的安全通信可能需要在树上绕一大圈进行签名验证,会大量增加不必要的通信开销。此外,智能家居中智能设备之间同时存在不只一个信任体系,比如同房间、同厂商、同类型等都可能提升信任度。这样多维度的复杂信任体系难以直接通过树型信任管理机制实现。


技术实现要素:

13.本发明所要解决的技术问题是,针对现有技术不足,提供一种ndn数字签名编码结构、物联网设备签名验证的方法及系统,有效提升通信安全性。
14.为解决上述技术问题,本发明所采用的技术方案是:一种命名数据网络数字签名编码,包括用于存放数字证书内数字签名的字节流的签名值域和用于存放与所述数字签名有关的各种信息的签名值域;所述签名信息内设置有验证链域;所述验证链域内存放有多条验证链;每一条验证链对应一个信任体系,并用于记录对应的信任体系下从根密钥到产生数字签名的密钥涉及的所有密钥。
15.本发明采用ndn网络,能有效保护物联网特别是智能家居的安全性和隐私性。采用ndn进行网络通信,签名信息内设置验证链域,能有效提升通信安全性。
16.每个所述密钥只记录散列值。减少通信开销。
17.所述数字证书的数字签名包括签发该数字证书的密钥,且该密钥为所述数字签名的前缀。
18.本发明还提供了一种利用上述所述命名数据网络实现物联网设备安全通信的方法,其包括:
19.1)待入网设备在获得登录口令后向命名数据网络中广播一个兴趣包,以发起入网请求;
20.2)命名数据网络收到入网请求后,为待入网设备指定数据名,并根据需要在一个或多个信任体系中为待入网设备选择一个最佳的信任锚点;
21.3)为待入网设备生成密钥对,并将生成的密钥对用设备的登录口令加密后发回给该待入网设备,并在发回的数据包中携带所述最佳的信任锚点的名字;
22.4)待入网设备向所述信任锚点发送证书申请请求;每一个信任锚点收到证书申请请求后各自为该待入网设备签发命名数据网络数字证书返回给该待入网设备,承载所述数字证书的数据包携带有待入网设备的公钥。所述最佳的信任锚点为使得所述待入网设备到多个信任体系根密钥的平均验证链长度最短的锚点。在签名验证过程中不论选择哪个信任体系来验证签名,验证路径都不会太长。
23.本发明的方法还包括:当待入网设备完成入网,开始与其他设备进行通信时,每次收到数据包p均进行签名验证,具体实现过程包括:
24.5)从数据包p的签名信息域中提取为该数据包签名的密钥k的名字;
25.6)判断本地是否有k的已经验证过的数字证书,如有则跳转到步骤12),否则进入步骤13);
26.7)向网络发送以k的名字命名的兴趣包,请求k的数字证书;
27.8)收到k的数字证书c;
28.9)判断当前是否正在进行k的数字证书认证,如正在进行则进入步骤10),否则跳转到步骤12);
29.10)假设当前正在验证的数字证书为c1,对比c1和c,选择验证链较短者继续验证;
30.11)设c2是c1和c中验证链较短者,若c2与c1相同,则不做任何操作,等收到新的数字证书后回到步骤8);否则,进入步骤12);
31.12)从c2的签名信息域中提取签发c2的密钥的名字k1,返回步骤6);
32.13)重复步骤5)~12),直到数据包p的签名验证完成。
33.通过上述步骤,可以在验证签名的过程中动态选择最短的验证路径,以减少验证开销。
34.步骤6)中,选择验证链较短者的具体实现过程包括:定义两条签名验证链的交叉验证开销为该两条签名验证链离各自尾部最近的公共点到两条签名验证链链尾的距离之和,验证开销小的签名验证链即为验证链较短者。本发明始终选择验证链较短者,即选择一条涉及密钥数较少的验证路径,减少验证过程中的通信和计算开销。
35.作为一个发明构思,本发明还提供了一种物联网设备通信系统,其包括计算机设
备;所述计算机设备被配置或编程为用于执行上述方法的步骤。
36.与现有技术相比,本发明所具有的有益效果为:
37.1、本发明采用ndn网络,支持基于数据的安全通信和本地化信任管理,能有效保护物联网特别是智能家居的安全性和隐私性。采用ndn进行网络通信,在通信的过程中自动嵌入了安全验证操作,能有效提升通信安全性;采用基于本地信源的本地化信任管理,不需要依赖第三方机构或者远端云服务就能完成身份认证和信任管理,有效保护本地数据的隐私。
38.2、基于ndn安全通信框架提出多路签名验证机制,可实现图化信任管理以支持多维信任体系并存。允许用户以更灵活的方式来进行更复杂的信任管理,能更好的支撑未来智能家居或者工业互联网等安全隐私要求高、且越来越复杂的应用场景。
39.3、动态地从多信任体系下的验证链中选择较短者推进签名验证,可有效减少签名验证开销。在通信过程中,随着网络链路状态、设备当前位置以及设备可用程度等因素都有可能导致原来选定的最优验证链不再可用或者通信延迟增大,每一步都动态选择能一支保持按当前最优的方案的推进,有效降低签名验证开销。
40.4、在安全通信过程中需要验证签名时,根据验证链域记录的验证链信息选取最短的验证链推进签名验证,能有效提升安全通信的效率,以高效保护物联网特别是智能家居的安全和隐私。
附图说明
41.图1为多路签名示意图;
42.图2为本发明实施例验证数据包签名时获取多个数字证书;
43.图3为本发明实施例ndn数据包签名格式的扩展示意图;
44.图4为本发明实施例设备入网流程示意图;
45.图5为本发明签名验证流程图;
46.图6为本发明实施例智能家居场景示例图;
47.图7为本发明实施例只考虑区域信任体系的信任关系图;
48.图8为本发明实施例同时考虑区域信任体系和厂商信任体系的信任关系图。
具体实施方式
49.为支持多维信任体系,本发明在ndn安全通信框架基础上增加多路签名验证机制。
50.如图1所示,ndn设备都拥有至少一对公钥/私钥,其中私钥用来为数据包签名,公钥会包裹在由上级信任设备签发的数字证书里发布到网络中;其他设备可从网络中获取该设备公钥对应的数字证书并提取出公钥来验证对应私钥产生的数字签名。由于多维信任体系的存在,同一设备公钥可以包裹在不同的数字证书中,由不同信任体系下的上级设备进行签发。
51.在ndn中,数字证书的名字包含签发该证书的密钥的名字作为前缀。如图2中所示,数字证书“/device/key001/certx”是由密钥“/device/key001”签发,后者的名字是前者名字的前缀。由于ndn在发送兴趣包获取数据包时采用最长前缀匹配,即在兴趣包中填写某公钥名字,则可能获取到所有包裹该公钥的数字证书(如图2所示)。
52.为在获取到多个数字证书后动态选取最优验证路径,本发明方案扩展ndn数据包签名信息域(signatureinfo),增加一个域——verificationchain来记录验证链信息。如图3所示,ndn的数据包签名由两部分组成:签名信息域(signatureinfo)和签名值域(signaturevalue)。其中签名值域用于存放数字签名的字节流,而签名信息域则用于存放与签名有关的各种信息。其中签名类型(siganturetype)是必选项,其他皆为可选项。本发明要扩展签名信息域的可选项,增加验证链域(verificationchain)。这个域可以存放多条验证链,每一条对应一个信任体系,记录这个信任体系下从根密钥到产生这个签名的密钥涉及的所有密钥;每个密钥只记录散列值(4字节)。比如,在某信任体系下,根密钥x0签发了密钥x1的数字证书;密钥x1又签发了密钥x2的数字证书。如果密钥x2为某个数据包签名,则在这个数据包的签名信息域中则会记录下hash(x0)

hash(x1)

hash(x2)这个序列,其中hash(x)表示密钥x的散列值。获取到多个数字证书后,根据本设备数字证书携带的验证链信息与获取到的数字证书的验证链信息进行综合判断,选取最短的验证链继续推进验证。具体分析判断过程如下。假定某设备自身的数字证书c1携带一条签名验证链:k1

k2

k3;获取到的两个数字证书c2、c3对应的签名验证链为:i1

i2

i3

i4和j1

j2

j3。我们定义两条签名验证链的交叉验证开销为验证链离尾部最近的公共点到两条链尾的距离之和。比如,若k1=i1=j1,k2=i4=j2,那么k1

k2

k3与i1

i2

i3

i4的交叉验证开销(选取k2,i4作为公共点)为1(k2到尾部的距离)+0(i4到尾部的距离)=1;同理,k1

k2

k3与j1

j2

j3的交叉验证开销则为2。因为c2对应的证书与本设备证书的交叉验证开销更小,因此选择c2继续推进验证。在ndn中,设备组网需解决的基本问题是新设备安全入网,即向网络中发送入网请求,然后获取到该设备在此网络中进行安全通信所需的密钥对以及由管理员指定信任锚点签发的数字证书。为实现本发明方案的信任管理系统和装置,设备入网需进行如图4所示两个阶段四个步骤的操作。
53.阶段一:处理入网请求。
54.步骤一:新设备在获得登录口令后向网络中广播一个兴趣包以发起入网请求;
55.步骤二:网络控制器收到设备入网请求后,通知管理员进行处理;管理员通过控制器(如手机、电脑等)为新设备指定数据名,并根据需要在一个或多个信任体系中为其选择一个最佳的信任锚点。每个信任体系下应选择一个锚点,由该锚点负责签发该设备的密钥的数字证书。选择信任锚点时可自由选择,也可选用系统默认的选择策略,如使得该设备到多个信任体系根密钥的平均验证链长度最短。比如,有两个信任体系x,y,当某设备d申请入网时,有a、b、c三个设备都可以作为其信任锚点。假设d通过这三个设备到达两个信任体系根密钥的验证链长度分别为a(x:3,y:无有效路径)、b(x:1,y:6)、c(x:3,y:5),则通过a到多个信任体系根密钥的平均验证链长度为3,通过b的平均验证链长度为3.5,通过c的平均验证链长度为4。因此,应选择a作为设备d的信任锚点。信任
56.步骤三:管理员操作完毕后,控制器为设备生成密钥对,并将生成的密钥对用设备的登录口令加密后发回给该设备,并在发回的数据包中携带选定的信任锚点的名字。
57.阶段二:处理证书申请。
58.步骤四:设备向信任锚点发送证书申请请求,并在该数据包中携带设备的公钥。每一个信任锚点收到证书申请请求后各自为该设备签发数字证书,并返回给该设备。
59.ndn中数据包的签名认证是实施访问控制的基础,即先验证身份才能管理权限。在
基于多路签名的多维信任管理模式下,本发明方案可动态在多条验证路径中选择较短者进行验证,以减少签名验证的开销。当设备收到数据包后进行签名验证的流程如图5所示。
60.步骤一:验证开始,从数据包的签名元数据信息域中提取为该数据包签名的密钥k的名字;
61.步骤二:判断本地是否有k的已经验证过的数字证书,如有则跳转到步骤九,否则进入下一步;
62.步骤三:向网络中请求k数字证书;
63.步骤四:收到返回的包裹有k的数字证书c;
64.步骤五:判断当前是否正在进行k的数字证书认证,如正在进行则进入下一步,否则跳转到步骤八;
65.步骤六:对比当前正在进行验证的数字证书c1和c,选择验证链较短者c2继续验证;
66.步骤七:判断c2与当前正在进行验证的数字证书c1是否相同,如不同则进入下一步;
67.步骤八:从c2的签名元数据信息中提取签发c2的密钥的名字k1,回到步骤二。
68.步骤九:迭代进行多层数字证书和数据包的验证,在本地缓存已验证的数字证书。验证结束。
69.本发明基于ndn安全通信框架设计多路签名机制,突破传统树形信任管理瓶颈,实现图化信任管理,以支持多信任体系的多维信任管理。扩展ndn数据包格式,增加多信任体系下的签名链信息,用于在进行签名验证时冬天选择较短路径进行验证,减小签名验证开销。
70.本发明设计主要针对智能家居场景。考虑如图6所示家庭场景,将生活区域划分为卧室、书房和客厅三大区域。其中,智能设备主要有电脑、智能手机、电视、智能电灯、空调等设备。考虑两种信任体系:(1)区域,同房间的设备互相信任;(2)厂商,同厂商设备互相信任。
71.实施例1:只考虑区域信任
72.这是最基本的信任体系。每个房间都设置有该区域的根密钥和根证书作为区域信任源,并存储在该房间的空调中(空调即信任锚点,并负责操作区域根密钥)。每一个区域的设备都由该区域的信任锚点(即空调)来签发数字证书;同区域的设备互相信任,且借助根数字帧数即可实现互相验证。此外,整个家庭设置了一个家庭根密钥和根证书,由用户手机代管(作为控制器和家庭信任锚点)。各房间的区域根证书都有家庭信任锚点签发。总体信任关系如图7所示。
73.如果通信双方处于同一房间,如通过客厅的电视来操作客厅的灯,则因为二者的数字证书都由客厅的根密钥签发,且根证书由客厅空调代管,因此此时二者进行安全通信的签名验证链长度为2(“客厅电视
”‑“
客厅空调”)。
74.如果通信双方不在同一房间,如通过客厅的电视来操作卧室的灯,当卧室灯收到该请求后需要验证客厅电视的签名。因为客厅电视与卧室灯位于不同区域,卧室灯在验证客厅电视签名时还需验证客厅根证书签名。由于书房根证书和客厅根证书都有家庭根证书签发,所以可以互相验证。因此,在此情形下的验证链长度为3(“客厅电视
”‑“
客厅空调
”‑

控制器”)。
75.实施例2:同时虑区域信任和厂商信任
76.如图8所示,客厅电视和卧室灯来自同一厂商,且厂商根密钥和根证书由客厅电视代管。还是考虑上述通过客厅电视来操作卧室灯的例子。此时,虽然两个设备在区域信任体系下的签名验证链长度为3,但因为同属于同一厂商,且在这一信任体系属于直接信任关系,因此签名链长度仅为1(“客厅电视”)。在进行签名验证时,根据本方案信任管理模式,可动态选择厂商信任体系进行验证,可以大幅减小验证开销。
77.实施例3:一栋楼数百房间、上千设备,涉及十个不同厂商
78.按照本发明方案进行多维信任体系并存的多维图化信任管理,随机生成设备信任关系和设备通信案例,计算平均每次通信验证次数为3.4,相比于单纯树形信任管理模式验证开销减少45%。
当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1