CN116346877A - 一种远程终端管理方法及系统 - Google Patents

一种远程终端管理方法及系统 Download PDF

Info

Publication number
CN116346877A
CN116346877A CN202211586352.0A CN202211586352A CN116346877A CN 116346877 A CN116346877 A CN 116346877A CN 202211586352 A CN202211586352 A CN 202211586352A CN 116346877 A CN116346877 A CN 116346877A
Authority
CN
China
Prior art keywords
server
client
handshake
initial key
connection
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
Application number
CN202211586352.0A
Other languages
English (en)
Inventor
侯宇鑫
王永勇
黄振江
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Tongze Kangwei Intelligent Technology Co ltd
Original Assignee
Guangzhou Tongkang Chuangzhi Software Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Guangzhou Tongkang Chuangzhi Software Co ltd filed Critical Guangzhou Tongkang Chuangzhi Software Co ltd
Priority to CN202211586352.0A priority Critical patent/CN116346877A/zh
Publication of CN116346877A publication Critical patent/CN116346877A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/141Setup of application sessions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种远程终端管理方法,包括:当客户端需要与服务端建立连接时,客户端向服务端发送QUIC握手请求,以使所述服务端在同意握手后计算出第一初始密钥,并向客户端反馈握手同意信息;客户端生成第二初始密钥,并采用所述第二初始密钥对所述握手同意信息进行解密;当所述客户端成功解密并提取所述临时随机数后,生成第二会话密钥,完成与所述服务端的连接建立;当连接建立完成后,所述客户端与所述服务端设计一个唯一标识符用于标识所述连接,随后在所述连接中建立若干个传输协议流,所述客户端与所述服务端通过所述若干个传输协议流进行通信。本发明能解决TR069协议不能双向实时通信的问题。

Description

一种远程终端管理方法及系统
技术领域
本发明涉及远程终端管理技术领域,尤其涉及一种远程终端管理方法及系统。
背景技术
TR-069是DSL(Di gi ta l Subscr i ber's Li ne,数字用户线路)论坛发起开发的技术规范,编号为TR-069,又被称为TR-069协议。它提供了对下一代网络中家庭网络设备进行管理配置的通用框架、消息规范、管理方法和数据模型。在TR-069协议中通过应用层协议HTTP(Hypertext Transfer Protoco l,超文本传输协议)传输数据,传输层协议使用的是TCP(Transmi ss i on Contro l Protoco l,传输控制协议)协议。
由于TR-069协议是基于HTTP1.1协议进行传输通信,而HTTP1.1协议是基于TCP作为传输层协议的,因此存在下列技术问题:
(1)HTTP1.1协议不支持双向通信,仅支持从客户端一侧发起请求进行回复,实时性不佳。
(2)TCP在移动场景下网络切换时存在连接迁移的问题,也就是四元组信息变化引起重连,而重连代价很高:终端重连之间后将需要重新三次握手以及TLS握手,也就是重连代价是TCP三次握手、TLS(Transport Layer Secur ity,传输层安全性协议)四次握手。
(3)TCP存在队头阻塞的问题:当传输过程中丢失一个可靠序列中的段,导致已经到达的段无法被读取。
QU I C(Qu i ck Udp I nternet Connect i on,快速UDP互联网连接)是由googl e提出的使用UDP(User Datagram Protoco l,用户数据包协议)进行多路并发传输的协议。
发明内容
本发明实施例提供一种远程终端管理方法及系统,能解决TR069协议不能双向实时通信的问题,提升交互的便捷性。
本发明一实施例提供一种远程终端管理方法,包括:
当客户端需要与服务端建立连接时,客户端向服务端发送QUI C握手请求,以使所述服务端在同意握手时,根据本地存储的第一服务端配置参数和所述握手请求中的公开数,计算出第一初始密钥,并向客户端反馈握手同意信息;其中,所述握手同意信息是根据所述第一初始密钥和临时随机数而加密生成;所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥;
客户端根据预存的第二服务端配置参数和所述公开数,生成第二初始密钥,并采用所述第二初始密钥对所述握手同意信息进行解密;
当所述客户端成功解密并提取所述临时随机数后,根据所述临时随机数和第二初始密钥,生成第二会话密钥,完成与所述服务端的连接建立;
当连接建立完成后,所述客户端与所述服务端设计一个唯一标识符用于标识所述连接,随后在所述连接中建立若干个传输协议流,每个传输协议流各自配置一个唯一标识数值,所述客户端与所述服务端通过所述若干个传输协议流进行通信;其中,所述客户端通过所述第二会话密钥对通信数据进行加密或解密;所述服务端通过所述第一会话密钥对通信数据进行加密或解密。
与现有技术相比,本发明实施例公开的一种远程终端管理方法通过客户端和服务端共同协商初始密钥,再由所述初始密钥计算会话密钥完成双方的连接建立,最后在双方的连接中建立多个传输协议流,各传输协议流可设置为不同类型,解决了TR069协议不能双向实时通信的问题,提升交互的便捷性。
进一步的,所述客户端根据预存的第二服务端配置参数和所述公开数,生成第二初始密钥,并采用所述第二初始密钥对所述握手同意信息进行解密,具体包括:
客户端在发送QUI C握手请求后,利用自身预存的服务端配置参数和所述QUI C握手请求中包含的公开数计算第二初始密钥;
客户端在收到服务端发送的握手同意信息后,利用所述第二初始密钥对所述握手同意信息进行解密;
若解密成功,则提取所述握手同意信息中的临时随机数继续进行第二会话密钥的计算;
若解密失败,则向服务端发送配置参数请求信息,请求服务端传输配置参数,随后继续利用所述配置参数和所述公开数计算第二初始密钥对握手同意信息进行解密;
重复向服务端发送所述配置参数请求信息,直至成功解密所述握手同意信息。
通过服务端利用第一初始密钥对握手同意信息进行加密,同时客户端利用第二初始密钥进行解密,保证了使客户端解密成功的第二初始密钥与第一初始密钥相同,为后续计算会话密钥作下铺垫。
进一步的,所述当所述客户端成功解密并提取所述临时随机数后,根据所述临时随机数和第二初始密钥,生成第二会话密钥以及所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥,具体包括:
客户端收到由服务端发送的握手同意信息后,利用所述第二初始密钥解密并从所述握手同意信息中提取出临时随机数;
客户端根据所述临时随机数和第二初始密钥,基于SHA-256算法推导出第二会话密钥;
服务端根据所述临时随机数和第一初始密钥,基于SHA-256算法推导出第一会话密钥。
双方各自基于相同算法计算第一和第二会话密钥,由于有初始密钥的铺垫,第一会话密钥与第二会话密钥也应相同,此后双方舍弃初始密钥,改为使用会话密钥进行通信,提高了连接的可靠性。
进一步的,所述当连接建立完成后,所述客户端与所述服务端设计一个唯一标识符用于标识所述连接,具体包括:
当连接建立完成后,所述连接将由一个唯一标识符进行标识,所述唯一标识符分别保存在所述客户端与所述服务端中,当客户端端口发生变化时,所述客户端向服务端发送所述标识符以使服务端确认标识符后继续进行数据传输。
通过设计专属标识符标识连接,避免当客户端端口发生变化时需要重新建立与服务端的连接,降低了弱网络或移动场景下的TCP和TLS重连代价。
进一步的,所述每个传输协议流各自配置一个唯一标识数值,具体包括:
所述若干个传输协议流分别以若干个一一对应的标识数值进行标识,所述若干个标识数值各不相同,且所述标识数值的编码为一个可变长度整型;
所述标识数值的最小有效位标识流的发起者,若所述传输协议流为客户端发起的流,则将所述最小有效位设置为第一阈值,若所述传输协议流为服务端发起的流,则将所述最小有效位设置为第二阈值;
所述标识数值的次小有效位标识流的通信类型,若所述传输协议流为双向流,则将所述次小有效位设置为第三阈值,若所述传输协议流为单向流,则将所述次小有效为设置为第四阈值。
设计若干个与传输协议流一一对应的标识数值对传输协议流进行标识,再通过设置所述标识数值的最小有效位及次小有效位将其对应的传输协议流变为包括双向通信类型的各种类型,实现了客户端与服务端之间的双向实时通信,提升了交互的便捷性。
作为一个优选的实施例,所述若干个传输协议流相互独立且各自拥有一个独立的滑动窗口,所述若干个传输协议流的标识数值由所述客户端与所述服务端共同决定,各传输协议流对应的标识数值各不相同。
通过在连接中设置多个相互独立的流通道并行发送业务信息,解决TCP存在的队头阻塞问题,提高了连接的便捷性。
进一步的,所述客户端与所述服务端通过所述若干个传输协议流进行通信,具体包括:
所述客户端通过所述若干个传输协议流与所述服务端连接,所述服务端通过连接的所述唯一标识符与传输协议流的所述唯一标识数值对所述客户端进行绑定,在通信过程中,所述客户端与服务端使用QU I C作为传输协议,所述通信数据为TR069协议信令数据。
本发明另一实施例对应提供了一种远程终端管理系统,包括:客户端、服务端、若干个QUI C通信模块以及连接平台;
所述客户端用于执行如上述发明实施例所述的一种远程终端管理方法;
所述服务端用于当客户端需要与服务端建立连接时,接收客户端发送的QUI C握手请求,在同意握手后,服务端根据本地存储的第一服务端配置参数和所述握手请求中的公开数,计算出第一初始密钥,并向客户端反馈握手同意信息;其中,所述握手同意信息是根据所述第一初始密钥和临时随机数而加密生成;所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥;
所述若干个QUI C通信模块分别位于客户端与服务端,所述客户端与服务端通过所述若干个QUI C通信模块进行通信;
所述连接平台依靠互联网进行搭建,用于承载所述客户端与服务端之间的连接,以使所述客户端与所述服务端通过所述连接中的若干个传输协议流进行通信。
与现有技术相比,本发明实施例公开的一种远程终端管理系统通过客户端和服务端共同协商初始密钥,再由所述初始密钥计算会话密钥完成双方的连接建立,最后在双方的连接中建立多个传输协议流,各传输协议流可设置为不同类型,解决了TR069协议不能双向实时通信的问题,提升交互的便捷性。
进一步的,当所述客户端与所述服务端的连接建立完成后,设计一个唯一标识符用于标识所述连接,随后在所述连接中建立若干个传输协议流,每个传输协议流各自配置一个唯一标识数值,所述客户端与所述服务端通过所述若干个传输协议流进行通信;其中,所述客户端通过第二会话密钥对通信数据进行加密或解密;所述服务端通过所述第一会话密钥对通信数据进行加密或解密。
作为一个优选的实施例,所述客户端通过第二会话密钥对通信数据进行加密或解密,具体包括:
客户端在发送QUI C握手请求后,利用自身预存的服务端配置参数和所述QUI C握手请求中包含的公开数计算第二初始密钥;
客户端收到由服务端发送的握手同意信息后,利用所述第二初始密钥解密并从所述握手同意信息中提取出临时随机数;
客户端根据所述临时随机数和第二初始密钥,基于SHA-256算法推导出第二会话密钥。
附图说明
图1是本发明一实施例提供的一种远程终端管理方法的流程示意图。
图2是本发明一实施例提供的一种远程终端管理方法的整体网络拓扑图。
图3是本发明一实施例提供的一种远程终端管理系统的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
参见图1,是本发明一实施例提供的一种远程终端管理方法的流程示意图,包括步骤S101至步骤S104。各步骤具体如下:
S101:当客户端需要与服务端建立连接时,客户端向服务端发送QUI C握手请求,以使服务端在同意握手时,根据本地存储的第一服务端配置参数和握手请求中的公开数,计算出第一初始密钥,并向客户端反馈握手同意信息;其中,握手同意信息是根据第一初始密钥和临时随机数而加密生成;服务端还根据第一初始密钥和临时随机数生成第一会话密钥;
S102:客户端根据预存的第二服务端配置参数和公开数,生成第二初始密钥,并采用第二初始密钥对握手同意信息进行解密;
S103:当所述客户端成功解密并提取临时随机数后,根据临时随机数和第二初始密钥,生成第二会话密钥,完成与服务端的连接建立;
S104:当连接建立完成后,客户端与服务端设计一个唯一标识符用于标识连接,随后在连接中建立若干个传输协议流,每个传输协议流各自配置一个唯一标识数值,客户端与服务端通过若干个传输协议流进行通信;其中,客户端通过第二会话密钥对通信数据进行加密或解密;服务端通过第一会话密钥对通信数据进行加密或解密。
本发明实施例公开的一种远程终端管理方法通过客户端和服务端共同协商初始密钥,再由所述初始密钥计算会话密钥完成双方的连接建立,最后在双方的连接中建立多个传输协议流,各传输协议流可设置为不同类型,解决了TR069协议不能双向实时通信的问题,提升交互的便捷性。
对于步骤S101,具体的,客户端与服务端协商初始密钥的过程如下:
(1)客户端判断本地是否已有服务端的全部配置参数,如果有则直接跳转到(5),否则继续;
(2)客户端向服务端发送i nchoate c l i ent he l l o(CHLO)消息,请求服务端传输配置参数;
(3)服务端收到CHLO,回复reject i on(REJ)消息,其中包含服务端的部分配置参数;
(4)客户端收到REJ,提取并存储服务端配置参数,跳回到(1);
(5)客户端向服务端发送fu l l c l i ent he l l o消息,开始正式握手,消息中包括客户端选择的公开数;
(6)服务端收到fu l l c l i ent he l l o,如果不同意连接就回复REJ,同(3);如果同意连接,根据客户端的公开数计算出初始密钥,回复server he l l o(SHLO)消息,SHLO用初始密钥加密,并且其中包含服务端选择的一个临时公开数。
通过服务端利用第一初始密钥对握手同意信息进行加密,同时客户端利用第二初始密钥进行解密,保证了使客户端解密成功的第二初始密钥与第一初始密钥相同,为后续计算会话密钥作下铺垫。
对于步骤S102,具体的,所述客户端根据预存的第二服务端配置参数和所述公开数,生成第二初始密钥,并采用所述第二初始密钥对所述握手同意信息进行解密,具体包括:
客户端在发送QU I C握手请求后,利用自身预存的服务端配置参数和所述QU I C握手请求中包含的公开数计算第二初始密钥;
客户端在收到服务端发送的握手同意信息后,利用所述第二初始密钥对所述握手同意信息进行解密;
若解密成功,则提取所述握手同意信息中的临时随机数继续进行第二会话密钥的计算;
若解密失败,则向服务端发送配置参数请求信息,请求服务端传输配置参数,随后继续利用所述配置参数和所述公开数计算第二初始密钥对握手同意信息进行解密;
重复向服务端发送所述配置参数请求信息,直至成功解密所述握手同意信息。
在一个优选的实施例中,客户端在向服务端发送fu l l c l ient he l l o消息后,客户端即可根据获取的服务端配置参数和自己选择的公开数计算出初始密钥。然后,客户端利用该初始密钥对服务端发送过来的SHLO消息进行解密,若解密成功则说明客户端计算的初始密钥与服务端计算的初始密钥相同。
对于步骤S103,具体的,所述当所述客户端成功解密并提取所述临时随机数后,根据所述临时随机数和第二初始密钥,生成第二会话密钥,具体包括:
客户端收到由服务端发送的握手同意信息后,利用所述第二初始密钥解密并从所述握手同意信息中提取出临时随机数;
客户端根据所述临时随机数和第二初始密钥,基于SHA-256算法推导出第二会话密钥;
同时,对于步骤S101中所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥,具体包括:所述服务端根据所述临时随机数和第一初始密钥,基于SHA-256算法推导出第一会话密钥。
在一个优选的实施例中,当客户端解密SHLO消息完成后,从SHLO消息中提取出服务端选择的一个临时随机数,此时客户端和服务器根据临时随机数和初始密钥,各自基于SHA-256算法推导出会话密钥。此后,双方更换为使用会话密钥通信,初始密钥此时已无用,QU I C握手过程完毕。之后会话密钥更新的流程与以上过程类似,只是数据包中的某些字段略有不同。
双方各自基于相同算法计算第一和第二会话密钥,由于有初始密钥的铺垫,第一会话密钥与第二会话密钥也应相同,此后双方舍弃初始密钥,改为使用会话密钥进行通信,提高了连接的可靠性。
对于步骤S104,具体的,所述当连接建立完成后,所述客户端与所述服务端设计一个唯一标识符用于标识所述连接,具体包括:
当连接建立完成后,所述连接将由一个唯一标识符进行标识,所述唯一标识符分别保存在所述客户端与所述服务端中,当客户端端口发生变化时,所述客户端向服务端发送所述标识符以使服务端确认标识符后继续进行数据传输。
在一个优选的实施例中,通过设计一个标识符(Connect i on I D)来标识客户端与服务端之间的连接,当QUI C连接进行连接迁移,也就是在四元组发生变化时,QUI C使用Connect ion I D来“保留”断开之前的连接,从而维持数据传输不中断。QUI C协议连接不再以I P及端口四元组标识,而是以一个64位的Connect ion I D作为I D来标识,这样就算I P或者端口发生变化时,只要I D不变,这条连接依然维持着,上层业务逻辑感知不到变化,不会中断,也就不需要重连。也就是说,当客户端之前已连接过服务端,客户端将服务端传输配置参数和加密公钥等信息保存在客户端,当客户端后续再重新连接的时,便无需再进行配置参数和加密公钥等信息的交互,可以立即传输数据,实现0RTT(Round-Tr ipTime,往返时延)发送业务数据的效果。
通过设计专属标识符标识连接,避免当客户端端口发生变化时需要重新建立与服务端的连接,降低了弱网络或移动场景下的TCP和TLS重连代价。
对于步骤S104,具体的,所述每个传输协议流各自配置一个唯一标识数值,具体包括:
所述若干个传输协议流分别以若干个一一对应的标识数值进行标识,所述若干个标识数值各不相同,且所述标识数值的编码为一个可变长度整型;
所述标识数值的最小有效位标识流的发起者,若所述传输协议流为客户端发起的流,则将所述最小有效位设置为第一阈值,若所述传输协议流为服务端发起的流,则将所述最小有效位设置为第二阈值;
所述标识数值的次小有效位标识流的通信类型,若所述传输协议流为双向流,则将所述次小有效位设置为第三阈值,若所述传输协议流为单向流,则将所述次小有效为设置为第四阈值。
在一个优选的实施例中,完成QU I C握手之后,需要对传输协议流(Stream)进行申请和建立,建立过程中需要设置Stream为双向通信类型,即可使QU I C连接支持双向实时通信。流可以是单向或双向的,单向流往一个方向传输数据,双向流允许双端向对端发送数据。
在连接中,流以一个数字值标识,称为Stream I D。一个Stream I D与同连接中其他流的Stream I D严格区分。Stream I D编码为一个可变长度整型。一个QU I C终端必须不能在同一个连接的不同流上重复使用同一个数值作为Stream I D。
Stream I D的最小有效位(0x01)标识流的发起者。客户端发起的流的I D是偶数(该位被置为0),服务端发起的流的I D是奇数(该位被置为1)。
Stream I D的次小有效位(0x02)标识流是双向流(该位被置为0)抑或单向流(该位被置为1)。
也就是说,Stream I D的最小两个有效位用来标识一条流是总共四种流类型中的哪一种,总结在如下表:
Figure BDA0003990825150000111
Figure BDA0003990825150000121
于是,在申请流过程中,如果需要QU I C连接支持双向实时通信,则设置Stream ID次小有效位=0x00即可。
进一步的,所述若干个传输协议流相互独立且各自拥有一个独立的滑动窗口,所述若干个传输协议流的标识数值由所述客户端与所述服务端共同决定,各传输协议流对应的标识数值各不相同。
在一个优选的实施例中,一条QU I C连接上可以通过若干个传输协议流并行发送多个请求。每一个传输协议流都分配了一个独立的滑动窗口,这样使得一个连接上的多个传输协议流之间没有依赖关系,都是相互独立的,当出现某个传输协议流丢失数据时,不会影响其他传输协议流,其他传输协议流中的数据可以顺利提交给应用层处理。
通过在连接中设置多个相互独立的流通道并行发送业务信息,解决TCP存在的队头阻塞问题,提高了连接的便捷性。
对于步骤S104,具体的,所述客户端与所述服务端通过所述若干个传输协议流进行通信,具体包括:
所述客户端通过所述若干个传输协议流与所述服务端连接,所述服务端通过连接的所述唯一标识符与传输协议流的所述唯一标识数值对所述客户端进行绑定,在通信过程中,所述客户端与服务端使用QU I C作为传输协议,所述通信数据为TR069协议信令数据。
在一个优选的实施例中,当QU I C连接建立完后,服务端主要是通过标识符Connect i on I D来标识与CPE设备的QU I C网络连接,另外结合标识数值StreamI D标识与客户端的业务数据的网络传输通道,服务端通过内存存储Connect i on I D对客户端设备进行绑定,然后利用Stream I D找到对应的传输协议流,即可向客户端设备实时发送数据。
在一个优选的实施例中,参见图2,在双方通信的过程中,客户端设备通过互联网与服务端连接,使用QUI C作为传输协议,QU I C负载的内容为TR069协议信令数据。在现有技术中,TR069协议是使用HTTP1.1协议作为传输协议进行传输通信,而在本发明提供的一实施例中,将TR069协议的传输协议HTTP1.1协议替换为QUI C协议,由于HTTP和QUI C协议都是点对点通信的协议,因此除了替换对应的发送和接收模块外,替换完成后TR069协议的其他整体框架没有变化。
参见图3,本发明另一实施例对应提供了一种远程终端管理系统,包括:客户端301、服务端302、若干个QUI C通信模块303以及连接平台304;
所述客户端301用于执行如上述发明实施例所述的一种远程终端管理方法;
所述服务端302用于当客户端需要与服务端建立连接时,接收客户端发送的QUI C握手请求,在同意握手后,服务端根据本地存储的第一服务端配置参数和所述握手请求中的公开数,计算出第一初始密钥,并向客户端反馈握手同意信息;其中,所述握手同意信息是根据所述第一初始密钥和临时随机数而加密生成;所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥;
所述若干个QUI C通信模块303分别位于客户端与服务端,所述客户端与服务端通过所述若干个QUI C通信模块进行通信;
所述连接平台304依靠互联网进行搭建,用于承载所述客户端与服务端之间的连接,以使所述客户端与所述服务端通过所述连接中的若干个传输协议流进行通信。
与现有技术相比,本发明实施例公开的一种远程终端管理系统通过客户端和服务端共同协商初始密钥,再由所述初始密钥计算会话密钥完成双方的连接建立,最后在双方的连接中建立多个传输协议流,各传输协议流可设置为不同类型,解决了TR069协议不能双向实时通信的问题,提升交互的便捷性。
需说明的是,本发明方法不仅适用于5G网络通信场景,也适用于有线WAN、4G、WI FI、Lora等网络场景。本发明方法实现以CPE设备为例,实际上可替换为任意支持TR069功能的路由设备,如企业路由器、家庭路由器设备、W I F I路由器、光路由、4G/5G CPE、VO I P设备、M I F I等设备。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也视为本发明的保护范围。

Claims (10)

1.一种远程终端管理方法,其特征在于,包括:
当客户端需要与服务端建立连接时,客户端向服务端发送QUIC握手请求,以使所述服务端在同意握手时,根据本地存储的第一服务端配置参数和所述握手请求中的公开数,计算出第一初始密钥,并向客户端反馈握手同意信息;其中,所述握手同意信息是根据所述第一初始密钥和临时随机数而加密生成;所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥;
客户端根据预存的第二服务端配置参数和所述公开数,生成第二初始密钥,并采用所述第二初始密钥对所述握手同意信息进行解密;
当所述客户端成功解密并提取所述临时随机数后,根据所述临时随机数和第二初始密钥,生成第二会话密钥,完成与所述服务端的连接建立;
当连接建立完成后,所述客户端与所述服务端设计一个唯一标识符用于标识所述连接,随后在所述连接中建立若干个传输协议流,每个传输协议流各自配置一个唯一标识数值,所述客户端与所述服务端通过所述若干个传输协议流进行通信;其中,所述客户端通过所述第二会话密钥对通信数据进行加密或解密;所述服务端通过所述第一会话密钥对通信数据进行加密或解密。
2.如权利要求1所述的一种远程终端管理方法,其特征在于,所述客户端根据预存的第二服务端配置参数和所述公开数,生成第二初始密钥,并采用所述第二初始密钥对所述握手同意信息进行解密,具体包括:
客户端在发送QUIC握手请求后,利用自身预存的服务端配置参数和所述QUIC握手请求中包含的公开数计算第二初始密钥;
客户端在收到服务端发送的握手同意信息后,利用所述第二初始密钥对所述握手同意信息进行解密;
若解密成功,则提取所述握手同意信息中的临时随机数继续进行第二会话密钥的计算;
若解密失败,则向服务端发送配置参数请求信息,请求服务端传输配置参数,随后继续利用所述配置参数和所述公开数计算第二初始密钥对握手同意信息进行解密;
重复向服务端发送所述配置参数请求信息,直至成功解密所述握手同意信息。
3.如权利要求1所述的一种远程终端管理方法,其特征在于,所述当所述客户端成功解密并提取所述临时随机数后,根据所述临时随机数和第二初始密钥,生成第二会话密钥以及所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥,具体包括:
客户端收到由服务端发送的握手同意信息后,利用所述第二初始密钥解密并从所述握手同意信息中提取出临时随机数;
客户端根据所述临时随机数和第二初始密钥,基于SHA-256算法推导出第二会话密钥;
服务端根据所述临时随机数和第一初始密钥,基于SHA-256算法推导出第一会话密钥。
4.如权利要求1所述的一种远程终端管理方法,其特征在于,所述当连接建立完成后,所述客户端与所述服务端设计一个唯一标识符用于标识所述连接,具体包括:
当连接建立完成后,所述连接将由一个唯一标识符进行标识,所述唯一标识符分别保存在所述客户端与所述服务端中,当客户端端口发生变化时,所述客户端向服务端发送所述标识符以使服务端确认标识符后继续进行数据传输。
5.如权利要求1所述的一种远程终端管理方法,其特征在于,所述每个传输协议流各自配置一个唯一标识数值,具体包括:
所述若干个传输协议流分别以若干个一一对应的标识数值进行标识,所述若干个标识数值各不相同,且所述标识数值的编码为一个可变长度整型;
所述标识数值的最小有效位标识流的发起者,若所述传输协议流为客户端发起的流,则将所述最小有效位设置为第一阈值,若所述传输协议流为服务端发起的流,则将所述最小有效位设置为第二阈值;
所述标识数值的次小有效位标识流的通信类型,若所述传输协议流为双向流,则将所述次小有效位设置为第三阈值,若所述传输协议流为单向流,则将所述次小有效为设置为第四阈值。
6.如权利要求5所述的一种远程终端管理方法,其特征在于,还包括:
所述若干个传输协议流相互独立且各自拥有一个独立的滑动窗口,所述若干个传输协议流的标识数值由所述客户端与所述服务端共同决定,各传输协议流对应的标识数值各不相同。
7.如权利要求1所述的一种远程终端管理方法,其特征在于,所述客户端与所述服务端通过所述若干个传输协议流进行通信,具体包括:
所述客户端通过所述若干个传输协议流与所述服务端连接,所述服务端通过连接的所述唯一标识符与传输协议流的所述唯一标识数值对所述客户端进行绑定,在通信过程中,所述客户端与服务端使用QUIC作为传输协议,所述通信数据为TR069协议信令数据。
8.一种远程终端管理系统,其特征在于,包括客户端、服务端、若干个QUIC通信模块以及连接平台;
所述客户端用于执行如权利要求1-7任一项所述的远程终端管理方法;
所述服务端用于当客户端需要与服务端建立连接时,接收客户端发送的QUIC握手请求,在同意握手后,服务端根据本地存储的第一服务端配置参数和所述握手请求中的公开数,计算出第一初始密钥,并向客户端反馈握手同意信息;其中,所述握手同意信息是根据所述第一初始密钥和临时随机数而加密生成;所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥;
所述若干个QUIC通信模块分别位于客户端与服务端,所述客户端与服务端通过所述若干个QUIC通信模块进行通信;
所述连接平台依靠互联网进行搭建,用于承载所述客户端与服务端之间的连接,以使所述客户端与所述服务端通过所述连接中的若干个传输协议流进行通信。
9.如权利要求8所述的一种远程终端管理系统,其特征在于,还包括:
当所述客户端与所述服务端的连接建立完成后,设计一个唯一标识符用于标识所述连接,随后在所述连接中建立若干个传输协议流,每个传输协议流各自配置一个唯一标识数值,所述客户端与所述服务端通过所述若干个传输协议流进行通信;其中,所述客户端通过第二会话密钥对通信数据进行加密或解密;所述服务端通过所述第一会话密钥对通信数据进行加密或解密。
10.如权利要求9所述的一种远程终端管理系统,其特征在于,所述客户端通过第二会话密钥对通信数据进行加密或解密,具体包括:
客户端在发送QUIC握手请求后,利用自身预存的服务端配置参数和所述QUIC握手请求中包含的公开数计算第二初始密钥;
客户端收到由服务端发送的握手同意信息后,利用所述第二初始密钥解密并从所述握手同意信息中提取出临时随机数;
客户端根据所述临时随机数和第二初始密钥,基于SHA-256算法推导出第二会话密钥。
CN202211586352.0A 2022-12-09 2022-12-09 一种远程终端管理方法及系统 Pending CN116346877A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211586352.0A CN116346877A (zh) 2022-12-09 2022-12-09 一种远程终端管理方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211586352.0A CN116346877A (zh) 2022-12-09 2022-12-09 一种远程终端管理方法及系统

Publications (1)

Publication Number Publication Date
CN116346877A true CN116346877A (zh) 2023-06-27

Family

ID=86888228

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211586352.0A Pending CN116346877A (zh) 2022-12-09 2022-12-09 一种远程终端管理方法及系统

Country Status (1)

Country Link
CN (1) CN116346877A (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102833253A (zh) * 2012-08-29 2012-12-19 五八同城信息技术有限公司 建立客户端与服务器安全连接的方法及服务器
CN111064792A (zh) * 2019-12-19 2020-04-24 北京航天云路有限公司 一种基于quic协议加快传感器设备数据采集的方法
CN112738004A (zh) * 2019-10-14 2021-04-30 上海哔哩哔哩科技有限公司 基于quic传输协议的通信方法和系统
US20210409447A1 (en) * 2020-06-25 2021-12-30 Nokia Solutions And Networks Oy Multilayer tunneling of protocols over quic
CN114185582A (zh) * 2021-10-27 2022-03-15 岚图汽车科技有限公司 基于quic协议的汽车软件在线升级系统及方法
CN114679314A (zh) * 2022-03-23 2022-06-28 腾讯科技(深圳)有限公司 数据解密的方法、装置、设备及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102833253A (zh) * 2012-08-29 2012-12-19 五八同城信息技术有限公司 建立客户端与服务器安全连接的方法及服务器
CN112738004A (zh) * 2019-10-14 2021-04-30 上海哔哩哔哩科技有限公司 基于quic传输协议的通信方法和系统
CN111064792A (zh) * 2019-12-19 2020-04-24 北京航天云路有限公司 一种基于quic协议加快传感器设备数据采集的方法
US20210409447A1 (en) * 2020-06-25 2021-12-30 Nokia Solutions And Networks Oy Multilayer tunneling of protocols over quic
CN114185582A (zh) * 2021-10-27 2022-03-15 岚图汽车科技有限公司 基于quic协议的汽车软件在线升级系统及方法
CN114679314A (zh) * 2022-03-23 2022-06-28 腾讯科技(深圳)有限公司 数据解密的方法、装置、设备及存储介质

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
JINGJING ZHANG等: "Formal Analysis of QUIC Handshake Protocol Using Symbolic Model Checking", IEEE ACCESS *
吴春敏;唐慧佳;: "TR-069会话中SSL/TLS协议的研究与应用", 成都信息工程学院学报, no. 05, pages 530 - 536 *
李学兵;陈阳;周孟莹;王新;: "互联网数据传输协议QUIC研究综述", 计算机研究与发展, no. 09 *

Similar Documents

Publication Publication Date Title
US11316730B2 (en) Cross-stratum optimization protocol across an interface between the service stratum and the transport stratum
US8510549B2 (en) Transmission of packet data over a network with security protocol
US7991993B2 (en) Telecommunication system, for example an IP telecommunication system, and equipment units for use in the system
US11962685B2 (en) High availability secure network including dual mode authentication
CN100539577C (zh) 在通信网中利用已验证的业务质量传输信息
BRPI0407702B1 (pt) método para criar e distribuir chaves criptográficas em um sistema de rádio móvel e sistema de rádio móvel
KR101369793B1 (ko) 미디어 데이터를 인코딩 및 디코딩하기 위한 방법, 장치들 및 컴퓨터 프로그램 제품
CN108964888B (zh) 一种基于对称密钥池和中继通信的改进型aka身份认证系统和方法
Maurhart QKD networks based on Q3P
KR101627256B1 (ko) 다수 분산서버를 구비한 네트워크 통신의 세션 이양 방법
WO2009043238A1 (fr) Procédé, dispositif et système pour la gestion de services multimédia
CN103516573B (zh) 受限网络中客户端之间的数据传输方法和客户端
CN112202826B (zh) 支持分控的视联网跨域通信方法、装置、设备及介质
CN115883478B (zh) 一种多标识网络体系中安全高效的传输控制方法及系统
CN102469063B (zh) 路由协议安全联盟管理方法、装置及系统
US7577837B1 (en) Method and apparatus for encrypted unicast group communication
CN108040042B (zh) 一种针对多播情况下CoAP协议的安全方法
CN116346877A (zh) 一种远程终端管理方法及系统
Hohendorf et al. Secure End-to-End Transport Over SCTP.
CN108306772A (zh) 一种分布式高可靠终端设备可认证基础数据的分发方法及系统
Wei et al. A secure and stable multicast overlay network with load balancing for scalable IPTV services
CN108737091B (zh) 一种基于对称密钥池和中继通信的类aka身份认证系统和方法
EP2846510A1 (en) SRTP protocol extension
Jennings et al. RFC 8870: Encrypted Key Transport for DTLS and Secure RTP
Zhang et al. Joint Network Coding and Opportunistic Forwarding

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
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20230721

Address after: 510000 room 1301, No. 37, Jinlong street, Xiangjiang financial and business center, Nansha District, Guangzhou City, Guangdong Province (office only)

Applicant after: Guangzhou Tongze Kangwei Intelligent Technology Co.,Ltd.

Address before: Room 1304, No. 37, Jinlong Road, Nansha Street, Nansha District, Guangzhou, Guangdong 510000 (office only)

Applicant before: Guangzhou Tongkang Chuangzhi Software Co.,Ltd.

CB02 Change of applicant information
CB02 Change of applicant information

Address after: 510000 room 1301, No. 37, Jinlong street, Xiangjiang financial and business center, Nansha District, Guangzhou City, Guangdong Province (office only)

Applicant after: Guangzhou Tongze Kangwei Technology Co.,Ltd.

Address before: 510000 room 1301, No. 37, Jinlong street, Xiangjiang financial and business center, Nansha District, Guangzhou City, Guangdong Province (office only)

Applicant before: Guangzhou Tongze Kangwei Intelligent Technology Co.,Ltd.