CN114238894A - 一种物联网公钥验证系统、方法、电子设备及存储介质 - Google Patents
一种物联网公钥验证系统、方法、电子设备及存储介质 Download PDFInfo
- Publication number
- CN114238894A CN114238894A CN202111574326.1A CN202111574326A CN114238894A CN 114238894 A CN114238894 A CN 114238894A CN 202111574326 A CN202111574326 A CN 202111574326A CN 114238894 A CN114238894 A CN 114238894A
- Authority
- CN
- China
- Prior art keywords
- internet
- things
- server
- access authorization
- authorization certificate
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请实施例提供一种物联网公钥验证系统、方法、电子设备及存储介质,涉及物联网技术领域。该系统包括受限物联网设备,接收所述服务器发送的所述临时访问授权证书并进行验证,并在验证成功后与所述受限物联网设备建立APK‑DTLS连接;物联网信任锚设备,与所述受限物联网设备处于同一管理域中,与所述受限物联网设备具有信任关系且通信连接,与所述服务器具有信任关系且通信连接,接收服务器发起的TLS连接请求,以与所述服务器建立TLS连接,并生成访问所述受限物联网设备所需的临时访问授权证书,将所述临时访问授权证书和所述公钥发送至所述服务器,解决现有方法需要占用较大内存且公钥需要额外验证的问题。
Description
技术领域
本申请涉及物联网技术领域,具体而言,涉及一种物联网公钥验证系统、方法、电子设备及存储介质。
背景技术
为了在物联网(IoT)中提供端到端的安全连接,传统的端到端IP安全协议的变体,如DTLS、最小IKEv2等,已经用于受限物联网,且这些协议变体在其协议设计中都考虑了公钥密码技术,并且基于证书公钥密码技术较成熟,能够提供高的安全性保证。但在受限物联网环境中使用基于证书的公钥密码技术机制,存在如下缺点:会产生大量的处理和传输开销,实现需要占用较大的RAM和ROM,能耗高。但采用基于原始公开密钥机制的RPK-DTLS(RFC7250)协议提供端到端的安全连接,需要公钥额外验证的问题。
发明内容
本申请实施例的目的在于提供一种物联网公钥验证系统、方法、电子设备及存储介质,服务器可利用物联网信任锚设备获取临时访问授权证书,从而与受限物联网设备建立端到端的DTLS安全通信连接,进行公钥验证,无需通信双方预置已经验证的对方的公钥,解决现有方法需要占用较大内存且公钥需要额外验证的问题。
本申请实施例提供了一种物联网公钥验证系统,所述系统包括:
受限物联网设备,接收所述服务器发送的所述临时访问授权证书并进行验证,并在验证成功后与所述受限物联网设备建立APK-DTLS连接;
物联网信任锚设备,与所述受限物联网设备处于同一管理域中,与所述受限物联网设备具有信任关系且通信连接,与所述服务器具有信任关系且通信连接,接收服务器发起的TLS连接请求,以与所述服务器建立TLS连接,并生成访问所述受限物联网设备所需的临时访问授权证书,将所述临时访问授权证书和所述公钥发送至所述服务器。
在上述实现过程中,该系统可以使受限物联网设备与服务器采用APK-DTLS协议实现端到端的安全通信,只在受限物联网设备和它所信任的物联网信任锚设备之间共享密钥,共享密钥只用于生成和验证临时访问授权证书,不在网络上传输,提高了共享密钥的安全性,解决了现有方法需要占用较大内存且公钥需要额外验证(RPK-DTLS协议本身不包括公钥验证的方法,需要通过其他方式进行验证)的问题。
进一步地,所述受限物联网设备包括验证模块,所述验证模块用于:
判断所述临时访问授权证书中的物联网信任锚设备ID是否存在于预设的物联网信任锚列表中;
若是,则判断所述临时访问授权证书中的序列号是否大于TAitem.SequenceNumber;
若是,则判断所述临时访问授权证书中的公钥是否与所述受限物联网设备中的公钥是否配置一致;
若是,则基于所述临时访问授权证书中的MAC算法、TAitem.Ki计算得到MAC值,以判断是否与所述临时访问授权证书中的MAC相同;
若是,则验证成功。
在上述实现过程中,通过临时访问授权证书中的物联网信任锚设备ID的有效性、序列号的有效性、公钥的有效性以及临时访问授权证书的真实性和完整性等几方面来对临时访问授权证书进行验证,从而保证临时访问授权证书的安全、可靠。
本申请实施例还提供一种物联网公钥验证方法,所述方法包括:
物联网信任锚设备,接收服务器发起的TLS连接请求,以与所述服务器建立TLS连接,并生成访问所述受限物联网设备所需的临时访问授权证书,将所述临时访问授权证书和所述公钥发送至所述服务器;
受限物联网设备,接收所述服务器发送的所述临时访问授权证书并进行验证,并在验证成功后与所述受限物联网设备建立APK-DTLS连接。
在上述实现过程中,该方法使受限物联网设备与服务器采用APK-DTLS协议实现端到端的安全通信,只在受限物联网设备和它所信任的物联网信任锚设备之间共享密钥,共享密钥只用于生成和验证临时访问授权证书,不在网络上传输,提高了共享密钥的安全性,解决了现有方法需要占用较大内存且公钥需要额外验证的问题。
进一步地,所述生成访问所述受限物联网设备所需的临时访问授权证书,包括:
对所述服务器进行认证,并在认证成功后向所述服务器发送客户端ID;
接收所述服务器发送的ReqAPK,以获取访问所述受限物联网设备所需的临时访问授权证书;
查找受限物联网访问授权信息,以确定所述服务器的访问权限,所述受限物联网访问授权信息包括客户端端ID、账号、密码和允许访问的受限物联网设备;
若有,则生成临时访问授权证书并发送至所述服务器。
在上述实现过程中,通过对服务器进行认证,在认证成功后生成服务器访问受限物联网设备所需的临时访问授权证书。
进一步地,所述生成临时访问授权证书并发送至所述服务器,包括:
从物联网设备数据库获取受限物联网设备信息,所述受限物联网设备信息包括SN值、MAC算法、MAC长度;
基于所述受限物联网设备信息生成临时访问授权证书;
将所述临时访问授权证书发送至所述服务器,并将物联网设备数据库中受限物联网设备的SN值加1。
在上述实现过程中,利用受限物联网设备信息生成临时访问授权证书,从而使得服务器利用临时访问授权证书实现与受限物联网设备的连接。
进一步地,受限物联网设备,对所述临时访问授权证书进行验证,包括:
判断所述临时访问授权证书中的物联网信任锚设备ID是否存在于预设的物联网信任锚列表中;
若是,则判断所述临时访问授权证书中的序列号是否大于TAitem.SequenceNumber;
若是,则判断所述临时访问授权证书中的公钥是否与所述受限物联网设备中的公钥是否配置一致;
若是,则基于所述临时访问授权证书中的MAC算法、TAitem.Ki计算得到MAC值,以判断是否与所述临时访问授权证书中的MAC相同;
若是,则验证成功。
在上述实现过程中,通过临时访问授权证书中的物联网信任锚设备ID的有效性、序列号的有效性、公钥的有效性以及临时访问授权证书的真实性和完整性等几方面来对临时访问授权证书进行验证,从而保证临时访问授权证书的安全、可靠。
进一步地,所述在验证成功后与所述受限物联网设备建立APK-DTLS连接,包括:
所述服务器获取所述受限物联网设备的IP地址并发送访问请求;
所述受限物联网设备基于所述访问请求返回访问验证请求;
所述服务器重新发送访问请求;
所述受限物联网设备接收所述服务器发送的临时访问授权证书并进行验证,验证成功后建立APK-DTLS连接。
在上述实现过程中,在建立APK-DTLS连接之前需要对服务器进行验证,以确保安全性。
进一步地,在所述物联网信任锚设备接收服务器发起的TLS连接请求之前,所述方法还包括:
物联网信任锚设备接收受限物联网设备的信息并存入物联网设备数据库中,以建立与所述受限物联网设备之间的信任关系,所述信息包括受限物联网设备ID、主对称密钥和公钥,所述物联网设备数据库包括受限物联网设备ID、IP、公钥、主对称密钥、MAC算法和MAC长度。
在上述实现过程中,给出了物联网信任锚设备的初始化过程,实现对物联网信任锚设备的数据配置。
本申请实施例还提供一种电子设备,所述电子设备包括存储器以及处理器,所述存储器用于存储计算机程序,所述处理器运行计算机程序以使计算机设备执行上述中任一项所述的物联网公钥验证方法。
本申请实施例还提供一种可读存储介质,所述可读存储介质中存储有计算机程序指令,所述计算机程序指令被一处理器读取并运行时,执行上述中任一项所述的物联网公钥验证方法。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对本申请实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1为本申请实施例提供的一种物联网公钥验证系统的结构框图;
图2为本申请实施例提供的另一种物联网公钥验证系统的结构框图;
图3为本申请实施例提供的物联网公钥验证方法的流程图;
图4为本申请实施例提供的服务器S从物联网信任锚设备TA上获取访问受限物联网设备Di所需的临时访问授权证书的流程图;
图5为本申请实施例提供的受限物联网设备对临时访问授权证书进行验证的流程图;
图6为本申请实施例提供的APK-DTLS连接建立流程图。
图标:
100-受限物联网设备;110-验证模块;120-证书生成模块;200-物联网信任锚设备;300-服务器。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。同时,在本申请的描述中,术语“第一”、“第二”等仅用于区分描述,而不能理解为指示或暗示相对重要性。
请参看图1,图1为本申请实施例提供的一种物联网公钥验证系统的结构框图。该系统包括:
受限物联网设备100,接收所述服务器300发送的所述临时访问授权证书并进行验证,并在验证成功后与所述受限物联网设备100建立APK-DTLS连接;
物联网信任锚设备200,与所述受限物联网设备100处于同一管理域中,与所述受限物联网设备100具有信任关系且通信连接,与所述服务器300具有信任关系且通信连接,接收服务器300发起的TLS连接请求,以与所述服务器300建立TLS连接,并生成访问所述受限物联网设备100所需的临时访问授权证书,将所述临时访问授权证书和所述公钥发送至所述服务器300。
如图2所示,为另一种物联网公钥验证系统的结构框图,在图1的基础上,所述受限物联网设备100包括验证模块110,所述验证模块110用于:
判断所述临时访问授权证书中的物联网信任锚设备ID是否存在于预设的物联网信任锚列表中;
若是,则判断所述临时访问授权证书中的序列号是否大于TAitem.SequenceNumber;
若是,则判断所述临时访问授权证书中的公钥是否与所述受限物联网设备100中的公钥是否配置一致;
若是,则基于所述临时访问授权证书中的MAC算法、TAitem.Ki计算得到MAC值,以判断是否与所述临时访问授权证书中的MAC相同;
若是,则验证成功。
具体地,通过在受限物联网中引入新的通信实体-物联网信任锚设备TA从而使得受限物联网设备Di与物联网信任锚设备TA建立信任关系;服务器S可通过物联网信任锚设备TA获取经验证的待访问受限物联网设备Di的公钥和服务器300所需的临时访问授权证书APKCert;服务器S使用APK-DTLS与受限物联网设备Di建立端到端的DTLS安全通信连接;APK-DTLS是对RPK-DTLS标准实现进行修改,增加了对临时访问授权证书APKCert的支持。
物联网信任锚设备TA和其所管理的受限物联网设备Di处于同一管理域中。物联网信任锚设备TA是一台资源丰富的设备,具有较强的计算、存储和通行能力。TA也可以是一台服务器,也可以是一台专门的设备,还可以以模块的方式内嵌于其他网络设备中,如物联网网关GW,在此不做限定。物联网信任锚设备TA部署在有物理保护措施的环境中,如企业的办公大楼中。
物联网信任锚设备TA与受限物联网设备Di之间具有信任关系;物联网信任锚设备TA与服务器S之间具备信任关系;物联网信任锚设备TA与服务器S之间通过IP协议连接;受限物联网设备Di和服务器S之间通过IP协议连接;物联网网关GW实现IP路由转发功能。
此外,物联网信任锚设备200还包括证书生成模块120:
对所述服务器300进行认证,并在认证成功后向所述服务器300发送客户端ID;
接收所述服务器300发送的ReqAPK,以获取访问所述受限物联网设备100所需的共享秘钥;
查找受限物联网访问授权信息,以确定所述服务器300的访问权限,所述受限物联网访问授权信息包括客户端端ID、账号、密码和允许访问的受限物联网设备100;
若有,则生成临时访问授权证书并发送至所述服务器300。
对于具体过程已经在方法实施例中描述,在此不再赘述。
本申请实施例还提供一种物联网公钥验证方法,如图3所示,为物联网公钥验证方法的流程图,该方法具体包括以下步骤:
步骤S100:物联网信任锚设备,接收服务器300发起的TLS连接请求,以与所述服务器300建立TLS连接,并生成访问所述受限物联网设备100所需的临时访问授权证书,将所述临时访问授权证书和所述公钥发送至所述服务器300;
步骤S200:受限物联网设备100,接收所述服务器300发送的所述临时访问授权证书并进行验证,并在验证成功后与所述受限物联网设备100建立APK-DTLS连接。
具体地,通过在受限物联网中引入物联网信任锚设备TA,受限物联网设备Di与物联网信任锚设备TA共享相同的主对称密钥Ki,受物联网设备Di的公钥Pi存储在物联网信任锚设备TA中。
服务器S在与受限物联网设备Di建立APK-DTLS握手之前,从物联网信任锚设备TA获取到受限物联网设备Di的公钥;物联网信任锚设备TA对服务器S进行认证和授权后,向服务器S发放用于访问受限物联网设备Di的临时访问授权证书APKCert,使用受限物联网设备Di拥有的主对称密钥Ki对临时访问授权证书APKCert做完整性保护;在受限物联网设备Di对临时访问授权证书APKCert进行验证之后,服务器S使用所获得的临时访问授权证书APKCert,并基于APK-DTLS协议建立与受限物联网设备Di的端到端的DTLS安全通信连接。
在步骤S100之前,所述方法还包括:
物联网信任锚设备接收受限物联网设备100的信息并存入物联网设备数据库中,以建立与所述受限物联网设备100之间的信任关系,所述信息包括受限物联网设备ID、主对称密钥和公钥,所述物联网设备数据库包括受限物联网设备ID、IP、公钥、主对称密钥、MAC算法和MAC长度。
具体地,在部署受限物联网设备Di之前,需要先配置受限物联网设备Di的主对称密钥Ki和公私密钥对{Pi、Si}。对于配置方法,示例地,客户自主的安全的生成密钥并委托设备制造商使用客户的安全设备将密钥烧录于受限物联网设备100;生产厂商安全的生成密钥并将密钥烧录于受限物联网设备100,并用安全的手段如加密邮件告知客户物联网设备的Ki和公钥Pi,对于具体配置方法在此不做限定。
初始化物联网信任锚设备TA:将待部署的受限物联网设备Di的信息存入在物联网信任锚设备TA的物联网设备数据库中,包括:受限物联网设备100的IDi,受限物联网设备100的主对称密钥Ki、受限物联网设备100的公钥Pi,此为,还需为物联网信任锚设备TA部署证书,配置服务器S的访问受限物联网设备100的权限。
物联网信任锚设备TA具有物联网设备数据库DeviceTable,如表1所示,为物联网设备数据库DeviceTable中的任意受限物联网设备100的Di的结构示意图:
表1物联网设备数据库DeviceTabl
具体包括:
DeviceTable存储物联网信任锚设备TA所管理的受限物联网设备100的信息,表项的内容包括:受限物联网设备100的DevID、DevIP、DevKey、PubKey、SN、MACAlgorithm和MAClength。其中,DevID是受限物联网设备100Di的IDi,DevIP是受限物联网设备Di的IP地址,DevKey是受限物联网设备Di的Ki,PubKey是受限物联网设备Di的公钥Pi,MACAlgorithm和MACLength是物联网设备支持的MAC(消息认证码)的算法及MAC长度。SN的初始值为0。
此外,初始化过程还包括物联网信任锚设备TA中的受限物联网访问授权信息AuthorizeTable的初始化,如表2所示,为受限物联网访问授权信息表:
ClientID | Account | Password | PermitIDs |
ID<sub>1</sub> | ×× | ×× | {ID<sub>1</sub>} |
…… | …… | …… | …… |
ID<sub>n</sub> | ×× | ×× | {ID<sub>S</sub>} |
表2受限物联网访问授权信息表
其中,AuthorizeTable存储允许访问受限物联网设备100的客户信息:客户端的ClientID、账号Account、密码Password、允许访问的受限物联网设备PermitIDs。
具体地,步骤S100中的生成访问所述受限物联网设备100所需的临时访问授权证书,如图4所示,为服务器S从物联网信任锚设备TA上获取访问受限物联网设备Di所需的临时访问授权证书的流程图,具体包括以下步骤:
步骤S111:对所述服务器300进行认证,并在认证成功后向所述服务器300发送客户端ID;
其中,服务器S的公私钥对为{Ps,Ss},受限物联网设备Di存储在物联网信任锚设备TA上的公钥为Pi,受限物联网设备Di与TA共享的对称密钥为Ki。
服务器S与物联网信任锚设备TA建立TLS安全连接,服务器S使用证书机制对TA进行认证,此处的TLS安全连接为S和TA之间的交换信息的保护通道。
此处的认证方式有多种,如采用口令/密码的客户端(服务器S)认证方式,认证成功后,服务器S得到ClientID,通过验证服务器S的身份,将服务器S的身份与S持有的公钥绑定。
步骤S112:接收所述服务器300发送的ReqAPK,以获取访问所述受限物联网设备100所需的共享秘钥临时访问授权证书;
其中,ReqAPK为消息名称,用于请求获得访问受限物联网设备Di所需的临时访问授权证书。
服务器S向物联网信任锚设备TA发送ReqAPK(ClientID、IDi、Ps),请求访问受限物联网设备Di所用的共享密钥临时访问授权证书。
步骤S113:查找受限物联网访问授权信息,以确定所述服务器300的访问权限,所述受限物联网访问授权信息包括客户端ID、账号、密码和允许访问的受限物联网设备100;
物联网信任锚设备TA查找受限物联网访问授权信息AT(AuthorizeTable),确定服务器S有访问Di的权限。如果S没有访问Di的权限,TA向S发送RejectAPK(ClientID、IDi),结束。
其中,RejectAPK为消息名称,表示拒绝提供临时访问授权证书。
步骤S114:若有,则从物联网设备数据库DeviceTable中获取受限物联网设备信息,受限物联网设备信息包括SN值、MAC算法、MAC长度。
步骤S115:基于所述受限物联网设备信息生成临时访问授权证书;
物联网信任锚设备TA从DT(DeviceTable)中获取物联网设备Di的信息,具体为SN、MACAlgorithm、MAClength和服务器S的公钥Pserver,按照下述MacCert的数据结构和MAC计算方法,生成临时授权证书TempAPK。
临时访问授权证书MacCert的数据结构如下所示:
struct{
opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;
opaque trust_anchor_id;
uint32 sequence_number;
MACAlgorithm mac_algorithm;
uint8 mac_length;
opaque MAC[mac_length];
}MacCert;
其中,ASN.1_subjectPublicKeyInfo用于描述所使用的公钥、算法和参数,其具体内容和结构与RFC7250中的RawPublicKe的定义相同,在此不做赘述。
trust_anchor_id为颁发临时访问授权证书的物联网信任锚设备TA的ID;sequence_number为临时访问授权证书的序列号;mac_algorithm即临时访问授权证书所使用的MAC算法(消息验证码算法),也使用RFC5246中的MACAlgorithm的定义;mac_length为消息认证码MAC的长度;MAC[mac_length]为临时访问授权证书的消息认证码MAC,使用受限物联网设备Di拥有的Ki实现临时访问授权证书的完整性保护。
临时访问授权证书MacCert中消息认证码MAC的计算方法为:若mac_algorithm为hmac_sha256,则mac_length=256,MAC=hmac_sha256(Key=Ki,Message),此处的Ki为受限物联网设备Di的主对称密钥Ki,Message为MAC为空时的临时访问授权证书MacCert。
需要说明的是,物联网信任锚设备TA是向持有公钥Ps、得到身份认证、具有访问物联网设备Di权限的服务器S颁发访问物联网设备Di的临时访问授权证书TempAPK,临时访问授权证书TempAPK使用Di的密钥Ki进行完整性保护。
步骤S116:将所述临时访问授权证书发送至所述服务器300,并将DeviceTable中受限物联网设备100的SN值加1。
物联网信任锚设备TA向服务器S发送ResAPK(TempAPK,Pi),Pi为物联网设备的公钥,物联网信任锚设备S存储{IDi、Pi、TempAPK}信息。TA更新DeviceTable中Di的SN值,即SN=SN+1。
本申请中的AuthPublicKey(是一种新增加的数据类型ID,为一个数字,表示使用的证书为MacCert类型),是一种区别于RFC7250证书数据结构的证书类型,具体如下:
struct{
select(certificate_type){
//AuthPublicKey
case AuthPublicKey:
MacCert certificate;
//RawPublicKey certificate defined in[RFC7250]
case RawPublicKey:
opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;
//X.509certificate defined in[RFC 5246]
case X.509:
ASN.1Cert certificate_list<0..2^24-1>;
//Additional certificate type based on TLS
//Certificate Type Registry
};
}Certificate;
步骤S200中的受限物联网设备100对临时访问授权证书进行验证,如图5所示,为受限物联网设备100对临时访问授权证书进行验证的流程图。
证书验证者(受限物联网设备Di)拥有一个物联网信任锚TA的列表TAList,在TAList中的表项内容包括:TAid、所使用的主密钥Ki,以及序列号SequenceNumber和滑动窗口SlideWindow,该列表TAList可用于对临时访问授权证书进行验证。具体包括以下步骤:
步骤S211:判断所述临时访问授权证书中的物联网信任锚设备ID是否存在于预设的物联网信任锚列表中;
判定临时访问授权证书MacCert中的trust_anchor_id的有效性,在TAList中查找TAid=MacCert.trust_anchor_id,将得到的表项存储在TAitem中,如果在TAList中无法查到,结束并返回错误。
受限物联网设备100与多个物联网信任锚设备TA建立了信任关系,并将所信任的物联网信任锚设备TA的信息存储在TAList中,TAitem用于临时存储在TAList中所查到的物联网信任锚设备TA的信息内容。
该步骤的作用是确定临时访问授权证书是物联网信任锚设备TA发放的。
步骤S212:若是,则判断所述临时访问授权证书中的序列号是否大于TAitem.SequenceNumber;
判断临时访问授权证书MacCert中的sequence_number的有效性,即MacCert.sequence_number>TAitem.SequenceNumber;MacCert.sequence_number处于滑动窗口SlideWindow中;否则,结束并返回错误。
该步骤的作用是保证持有临时访问授权证书的访问者只能使用一次临时访问授权证书。
步骤S213:若是,则判断所述临时访问授权证书中的公钥是否与所述受限物联网设备100中的公钥是否配置一致;
判断证书MacCert中所存储的公钥ASN.1_subjectPublicKeyInfo的有效性。检测内容包括:公钥的长度、加密算法和参数与证书验证人(Di)配置是否一致;否则,结束并返回错误。
该步骤的作用是使物联网设备Di和临时访问授权证书的持有者使用相同的公钥算法。
步骤S214:若是,则基于所述临时访问授权证书中的MAC算法、TAitem.Ki计算得到MAC值,以判断是否与所述临时访问授权证书中的MAC相同;若是,则验证成功。
验证临时访问授权证书的真实性和完整性,使用证书MacCert中MacCert.mac_algorithm指定的MAC算法、MacCert证书和TAitem.Ki,计算出MAC值;判断MAC值是否与MacCert.MAC相同;如果相同,则返回成功;否则,结束并返回错误。
该步骤的作用是保证临时访问授权证书的真实性和完整性,确保是TA发放的、没有篡改的。
在步骤S200中,在验证成功后与所述受限物联网设备100建立APK-DTLS连接,具体包括以下步骤:
步骤S221:服务器300获取所述受限物联网设备100的IP地址并发送访问请求;
该方法给出了一种APK-DTLS的消息交互方法,如图6所示,为APK-DTLS连接建立流程图,具体地:
服务器S持有从TA获得的受限物联网设备Di的临时访问授权证书TempAPK和物联网设备Di的公钥Pi。
服务器S获得受限物联网设备Di的IP地址,如:通过RD(资源目录服务器)获得受限物联网设备Di的IP地址。
步骤S222:受限物联网设备100基于所述访问请求返回访问验证请求;
服务器S向受限物联网设备Di发送ClientHello,其中client_certificate_type=AuthPublicKey。
受限物联网设备Di发送HelloVerifyRequest。
步骤S223:服务器300重新发送访问请求;
服务器S向受限物联网设备Di重新发送ClientHello,其中client_certificate_type=AuthPublicKey。
重新发送访问请求的方式是一种基于UDP协议实现DTLS连接所需要的保护手段,用于防止对服务器发起DDoS拒绝服务攻击。
步骤S224:受限物联网设备100接收所述服务器300发送的临时访问授权证书并进行验证,验证成功后建立APK-DTLS连接。
受限物联网设备Di在ServerHello中,指定server_certificate_type=X.509;Certificate中的证书列表为空,client_certificate_type=AuthPublicKey,要求客户端发送AuthPublicKey类型的证书;因为服务器S已经获得了受限物联网设备Di的公钥Pi,所以不发送受限物联网设备Di的证书。
在基于DTLS的协议中,Certificate用于发送证书列表,APK-DTLS为了减少对DTLS代码的更改量,使用了DTLS协议中已经定义的消息结构,但在消息内容上进行了修改,因此,此处不需要受限物联网设备Di提供X.509证书,所以Certificate这项为空。
受限物联网设备Di收到服务器S发来的临时访问授权证书TempAPK后,使用本发明中描述的方法验证临时访问授权证书TempAPK;验证成功后,受限物联网设备Di向服务器S发送ChangeCipherSpec和Finished消息。
ChangeCipherSpec和Finished是DTLS协议中的消息,表示已经确认了密码算法和参数,加密密钥已经生成。
该方法使受限物联网设备100与任意的服务器S,采用APK-DTLS协议实现端到端的安全通信,解决了基于RFC 7250中需要的公钥额外验证的问题。
该方法只在受限物联网设备100和它所信任的物联网信任锚设备200之间共享密钥,共享密钥只用于生成和验证临时授权证书,不在网络上传输,提高了共享密钥的安全性;该方法还具有良好的扩展性,可以大规模物联网应用的环境中。
本申请实施例还提供一种电子设备,所述电子设备包括存储器以及处理器,所述存储器用于存储计算机程序,所述处理器运行计算机程序以使计算机设备执行上述的物联网公钥验证方法。
本申请实施例还提供一种可读存储介质,所述可读存储介质中存储有计算机程序指令,所述计算机程序指令被一处理器读取并运行时,执行权利要求上述的物联网公钥验证方法。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现方式中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
另外,在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或两个以上模块集成形成一个独立的部分。
所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本申请的实施例而已,并不用于限制本申请的保护范围,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应所述以权利要求的保护范围为准。
需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
Claims (10)
1.一种物联网公钥验证系统,其特征在于,所述系统包括:
受限物联网设备,接收服务器发送的临时访问授权证书并进行验证,并在验证成功后与所述受限物联网设备建立APK-DTLS连接;
物联网信任锚设备,与所述受限物联网设备处于同一管理域中,与所述受限物联网设备具有信任关系且通信连接,与所述服务器具有信任关系且通信连接,接收服务器发起的TLS连接请求,以与所述服务器建立TLS连接,并生成访问所述受限物联网设备所需的临时访问授权证书,将所述临时访问授权证书和所述公钥发送至所述服务器。
2.根据权利要求1所述的物联网公钥验证系统,其特征在于,所述受限物联网设备包括验证模块,所述验证模块用于:
判断所述临时访问授权证书中的物联网信任锚设备ID是否存在于预设的物联网信任锚列表中;
若是,则判断所述临时访问授权证书中的序列号是否大于TAitem.SequenceNumber;
若是,则判断所述临时访问授权证书中的公钥是否与所述受限物联网设备中的公钥是否配置一致;
若是,则基于所述临时访问授权证书中的MAC算法、TAitem.Ki计算得到MAC值,以判断是否与所述临时访问授权证书中的MAC相同;
若是,则验证成功。
3.一种物联网公钥验证方法,其特征在于,所述方法包括:
物联网信任锚设备,接收服务器发起的TLS连接请求,以与所述服务器建立TLS连接,并生成访问受限物联网设备所需的临时访问授权证书,将所述临时访问授权证书和所述公钥发送至所述服务器;
受限物联网设备,接收所述服务器发送的所述临时访问授权证书并进行验证,并在验证成功后与所述受限物联网设备建立APK-DTLS连接。
4.根据权利要求3所述的物联网公钥验证方法,其特征在于,所述物联网信任锚设备生成访问所述受限物联网设备所需的临时访问授权证书,包括:
对所述服务器进行认证,并在认证成功后向所述服务器发送客户端ID;
接收所述服务器发送的ReqAPK,以获取访问所述受限物联网设备所需的临时访问授权证书;
查找受限物联网访问授权信息,以确定所述服务器的访问权限,所述受限物联网访问授权信息包括客户端端ID、账号、密码和允许访问的受限物联网设备;
若有,则生成临时访问授权证书并发送至所述服务器。
5.根据权利要求4所述的物联网公钥验证方法,其特征在于,所述生成临时访问授权证书并发送至所述服务器,包括:
从物联网设备数据库获取受限物联网设备信息,所述受限物联网设备信息包括SN值、MAC算法、MAC长度;
基于所述受限物联网设备信息生成临时访问授权证书;
将所述临时访问授权证书发送至所述服务器,并将物联网设备数据库中受限物联网设备的SN值加1。
6.根据权利要求3所述的物联网公钥验证方法,其特征在于,受限物联网设备,对所述临时访问授权证书进行验证,包括:
判断所述临时访问授权证书中的物联网信任锚设备ID是否存在于预设的物联网信任锚列表中;
若是,则判断所述临时访问授权证书中的序列号是否大于TAitem.SequenceNumber;
若是,则判断所述临时访问授权证书中的公钥是否与所述受限物联网设备中的公钥是否配置一致;
若是,则基于所述临时访问授权证书中的MAC算法、TAitem.Ki计算得到MAC值,以判断是否与所述临时访问授权证书中的MAC相同;
若是,则验证成功。
7.根据权利要求3所述的物联网公钥验证方法,其特征在于,所述在验证成功后与所述受限物联网设备建立APK-DTLS连接,包括:
所述服务器获取所述受限物联网设备的IP地址并发送访问请求;
所述受限物联网设备基于所述访问请求返回访问验证请求;
所述服务器重新发送访问请求;
所述受限物联网设备接收所述服务器发送的临时访问授权证书并进行验证,验证成功后建立APK-DTLS连接。
8.根据权利要求3所述的物联网公钥验证方法,其特征在于,在所述物联网信任锚设备接收服务器发起的TLS连接请求之前,所述方法还包括扩:
物联网信任锚设备接收受限物联网设备的信息并存入物联网设备数据库中,以建立与所述受限物联网设备之间的信任关系,所述信息包括受限物联网设备ID、主对称密钥和公钥,所述物联网设备数据库包括受限物联网设备ID、IP、公钥、主对称密钥、MAC算法和MAC长度。
9.一种电子设备,其特征在于,所述电子设备包括存储器以及处理器,所述存储器用于存储计算机程序,所述处理器运行计算机程序以使计算机设备执行根据权利要求3至8中任一项所述的物联网公钥验证方法。
10.一种可读存储介质,其特征在于,所述可读存储介质中存储有计算机程序指令,所述计算机程序指令被一处理器读取并运行时,执行权利要求3至8任一项所述的物联网公钥验证方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111574326.1A CN114238894A (zh) | 2021-12-21 | 2021-12-21 | 一种物联网公钥验证系统、方法、电子设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111574326.1A CN114238894A (zh) | 2021-12-21 | 2021-12-21 | 一种物联网公钥验证系统、方法、电子设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114238894A true CN114238894A (zh) | 2022-03-25 |
Family
ID=80760662
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111574326.1A Pending CN114238894A (zh) | 2021-12-21 | 2021-12-21 | 一种物联网公钥验证系统、方法、电子设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114238894A (zh) |
-
2021
- 2021-12-21 CN CN202111574326.1A patent/CN114238894A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4801147B2 (ja) | 証明を配送するための方法、システム、ネットワーク・ノード及びコンピュータ・プログラム | |
US9537861B2 (en) | Method of mutual verification between a client and a server | |
US8281127B2 (en) | Method for digital identity authentication | |
US7992193B2 (en) | Method and apparatus to secure AAA protocol messages | |
US20060143442A1 (en) | Automated issuance of SSL certificates | |
US20090240936A1 (en) | System and method for storing client-side certificate credentials | |
WO2001082037A2 (en) | Security link management in dynamic networks | |
JP2018117340A (ja) | コンピュータネットワーク内のユーザの認証 | |
JP4783340B2 (ja) | 移動ネットワーク環境におけるデータトラフィックの保護方法 | |
CN111935213A (zh) | 一种基于分布式的可信认证虚拟组网系统及方法 | |
EP3328025B1 (en) | Accessing hosts in a hybrid computer network | |
CN114553480B (zh) | 跨域单点登录方法、装置、电子设备及可读存储介质 | |
JP2024506915A (ja) | ゼロ信頼認証 | |
Nongbri et al. | A survey on single sign-on | |
JP5186648B2 (ja) | 安全なオンライン取引を容易にするシステム及び方法 | |
KR20090054774A (ko) | 분산 네트워크 환경에서의 통합 보안 관리 방법 | |
KR100819024B1 (ko) | 아이디/패스워드를 이용한 사용자 인증 방법 | |
Binu et al. | A mobile based remote user authentication scheme without verifier table for cloud based services | |
EP1836559B1 (en) | Apparatus and method for traversing gateway device using a plurality of batons | |
US11870899B2 (en) | Secure device access recovery based on validating encrypted target password from secure recovery container in trusted recovery device | |
Bavishi et al. | Scalable and efficient mutual authentication strategy in fog computing | |
CN114238894A (zh) | 一种物联网公钥验证系统、方法、电子设备及存储介质 | |
Abdelkader et al. | A new strong user authentication scheme with local certification authority for internet of things based cloud computing services | |
KR20170111809A (ko) | 대칭키 기반의 보안 토큰을 이용한 양방향 인증 방법 | |
Azizul et al. | Authentication and Authorization Design in Honeybee Computing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |