CN115720176B - 基于Socket通信报文内容的动态加密方法、系统、网络设备及计算机可读存储介质 - Google Patents
基于Socket通信报文内容的动态加密方法、系统、网络设备及计算机可读存储介质 Download PDFInfo
- Publication number
- CN115720176B CN115720176B CN202211670274.2A CN202211670274A CN115720176B CN 115720176 B CN115720176 B CN 115720176B CN 202211670274 A CN202211670274 A CN 202211670274A CN 115720176 B CN115720176 B CN 115720176B
- Authority
- CN
- China
- Prior art keywords
- client
- server
- message
- ptk
- handshake
- 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.)
- Active
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明提供一种基于Socket通信报文内容的动态加密方法,包括服务端创建监听,响应客户端的连接请求,与客户端建立Socket连接,基于该连接,服务端接收并应答客户端发送的握手报文,解析握手报文并计算生成服务端PTK的值;客户端接收并应答服务端发送的握手报文,解析握手报文并计算生成客户端PTK的值;客户端比对报文中PTK校验码与基于客户端PTK的值计算得到的PTK校验码是否一致。本发明通过设定一个约束条件,即通信双方的本机时间戳除以整数N且取整后的值必须一样,故设计存在两次握手,通过对比通信双方PTK校验码是否一致以判断双方的PTK是否一致的方式,达到解决现有技术问题的效果。
Description
技术领域
本发明涉及数据隐私安全计算技术领域,具体为基于Socket通信报文内容的动态加密方法、系统。
背景技术
随着大数据、人工智能等互联网新技术的广泛使用,信息安全问题日益突出。
同时,由于计算机在各个领域都有深入的应用,因此,数据传输的使用场景必不可少,而基于TCP/IP协议的Socket通信是经常会使用的。那么,数据加密是必不可少的技术要点。
目前最直接的加密处理是:客户端和服务端共享一个成对密钥,在通信报文发送前对报文内容加密,对端收到报文后对报文内容解密。
但是,上述方案存有两个缺陷:
1、成对密钥的构造和存储:如果成对密钥是通过预设的方式,存储在某个位置,在程序运行的时候由程序获取,那么,这个成对密钥就有可能被窃取;
2、所有的通信都使用一个成对密钥,一旦加密数据被截取,抵抗暴力破解的能力较低,很容易被破解。
发明内容
针对现有技术存在的不足,本发明目的是提供基于Socket通信报文内容的动态加密方法、系统,通过在两次握手的过程中将密钥通过一些过程元素构造出来的,大大降低了密钥被窃取的风险;同时,由于每个Socket连接在两次握手成功后,传输密钥都是不同的,因此,即使遭遇了暴力破解,获得的成对传输密钥也只对某一个仍然在连接的加密数据有意义,一旦该连接重连后,暴力破解的成果便不再有用,故而本发明大大降低了暴力破解的收益。解决上述背景技术中提出的问题。
为了实现上述目的,本发明是通过如下的技术方案来实现:一种基于Socket通信报文内容的动态加密方法,应用于目标设备中,包括以下步骤:
服务端
创建监听,响应客户端的连接请求,与客户端建立Socket连接,基于该连接,接收并应答所述客户端的握手报文;其中,所述握手报文为客户端与服务端进行握手校验时使用的握手校验TCP/IP传输控制协议中约定的报文格式,所述握手报文中至少携带有客户端报文序号、约定的报文类型、约定的客户端编码;
解析所述握手报文并计算生成服务端PTK的值以及PTK校验码;
客户端
基于所述Socket连接,接收并应答所述服务端发送的握手报文,其中,所述握手报文中至少携带有服务端报文序号、约定的报文类型、约定的服务端编码以及由服务端计算的PTK校验码;
解析所述握手报文并计算生成客户端PTK的值以及PTK校验码;
比对所述服务端PTK校验码与所述客户端PTK校验码是否一致:
若一致,则所述客户端与所述服务端各自计算的PTK一致,双方可使用PTK做加密通信;反之,则基于所述Socket连接,客户端向服务端重试握手。
作为本发明的第二方面,提出了一种基于Socket通信报文内容的动态加密系统,包括客户端和服务端;
所述客户端,向服务端发起Socket连接请求,并与所述服务端建立Socket通信连接;
所述服务端,创建监听,响应客户端的Socket连接请求,并建立与所述客户端之间的Socket通信连接。
作为本发明的第三方面,提出了一种基于Socket通信报文内容的动态加密网络设备,所述网络设备包括相互耦合的处理器及存储器,所述存储器内存储计算机程序,当所述计算机程序被所述处理器执行时,使得所述网络设备执行基于Socket通信报文内容的动态加密方法。
作为本发明的第四方面,提出基于Socket通信报文内容的动态加密的计算机可读存储介质,所述计算机可读存储介质中存储有计算机程序,当所述计算机程序在计算机上运行时,使得所述计算机执行基于Socket通信报文内容的动态加密方法。
与现有技术相比,本发明的有益效果:
1、为降低暴力破解,首先,本发明通过在两次握手的过程中将密钥通过一些过程元素构造出来的,大大降低了密钥被窃取的风险;同时,由于每个Socket连接在两次握手成功后,传输密钥都是不同的,因此,即使遭遇了暴力破解,获得的成对传输密钥也只对某一个仍然在连接的加密数据有意义,一旦该连接重连后,暴力破解的成果便不再有用,故而本发明大大降低了暴力破解的收益;
2、其次,本发明通过设定一个约束条件,即,两次握手如果要成功,通信双方的本机时间戳除以整数N且取整后,必须是一样的,故而就要求通信双方必须有时间同步的功能;且在两个系统时间一致的条件下,设计存在两次握手,通过对比通信双方PTK校验码是否一致以判断双方的PTK是否一致的方式,达到解决现有技术问题的效果,其中,双方构造的PTK不一致的概率与N有关,N越大,概率越低,N越小,概率越高。
附图说明
参照附图来说明本发明的公开内容。应当了解,附图仅仅用于说明目的,而并非意在对本发明的保护范围构成限制,在附图中,相同的附图标记用于指代相同的部件。其中:
图1为本发明一实施例中所提出的基于Socket通信报文内容进行动态加密的时序步骤流程示意图。
具体实施方式
容易理解,根据本发明的技术方案,在不变更本发明实质精神下,本领域的一般技术人员可以提出可相互替换的多种结构方式以及实现方式。因此,以下具体实施方式以及附图仅是对本发明的技术方案的示例性说明,而不应当视为本发明的全部或者视为对本发明技术方案的限定或限制。
以下结合附图对本发明作近一步详细说明,但不作为对本发明的限定。
作为对本发明技术构思以及实现原理的理解,现有手段主要进行加密处理的方式是,客户端和服务端共享一个成对密钥,在通信报文发送前对报文内容加密,对端收到报文后对报文内容解密,但是就存在:若此成对密钥是通过预设的方式存储在某个位置,其在程序运行的时候由程序获取,那么此成对密钥就有可能被窃取;在此之外,由于所有的通信都使用一个成对密钥,一旦加密数据被截取,抵抗暴力破解的能力较低,很容易被破解。
而,为解决现有的技术方案遭遇暴力破解,导致数据泄密被窃取的风险,本发明提出在两次握手(客户端-服务端、服务端-客户端)的过程中,将密钥通过一些过程元素构造出来,大大降低密钥被窃取的风险,从而就达到大大降低暴力破解的收益的目的。即,
可以理解的是,本发明是通过定义必要的报文头文件信息,以及客户端与服务器的两次握手,实现对Socket通信(Socket,即套接字。就是两台主机之间逻辑连接的端点)的报文内容(报文(message)是网络中交换与传输的数据单元,即站点一次性要发送的数据块。报文包含了将要发送的完整的数据信息,其长短很不一致,长度不限且可变)所进行加密的应用。
为更好的对本发明技术构思以及实现原理进行理解,需要说明的是,本发明技术方案中提出的关键字解释包括:
msg_id:报文序号(0~4294967295重复循环);
send_id:发送编码 (0~FFFF);
KEY:当前系统时间戳除以整数N,并取整数;
s_IP:服务端的IP地址;
PMK:成对主密钥,由KEY作为密钥,以s_IP为salt随机盐值“salt”,以某种密钥派生算法,在本发明的一具体实施例中,以“PBKDF2”为例,得到固定长度的Hash值,转为字符串;
s_msg_id:服务端的msg_id;
c_msg_id:客户端的msg_id;
c_send_id:客户端的send_id;
PTK:成对传输密钥,在本发明的一具体实施例中,由PMK作为密钥,以c_msg_id+s_msg_id+c_send_id+s_IP组成字符串为盐,以某种密钥派生算法,在本发明的一具体实施例中,以“PBKDF2”为例,得到固定长度的Hash值,转为字符串;
check_sum:PTK校验码,在本发明的一具体实施例中,其获取方式为将校验内容以8个比特为单位,从高位到低位顺序累加到一个字节中,在全部计算完后,对该字节按位取反。
基于此,在完成定义关键字解释后,接下来就需要进行客户端与服务器的两次握手,实现端与端的Socket通信连接。
为此,如图1所示,作为本发明的一实施例,提出一种基于Socket通信报文内容的动态加密方法,应用于目标设备(客户端和/或服务端)中,包括以下步骤:
第一步,基于服务端,
S1,首先,创建监听,响应客户端的连接请求,与客户端建立Socket通信连接;需要说明的是,服务端建立与客户端之间的Socket通信连接的具体步骤以C语言代码为例,包括:
S1-1,服务端依次调用socket()、bind()以及listen()后,创建监听指定的socket地址;
S1-2,客户端依次调用socket()、connect()后,向服务端发送一连接请求;
S1-3,服务端监听到此请求后,调用accept()获取接收请求,完成与客户端之间的Socket通信连接,当S1步骤完成后,表明客户端与服务端的连接已经建立好。
接下来
S2,需要客户端向服务端发送握手报文A
具体实施时,握手报文A采用的是客户端与服务端进行握手校验时使用的握手校验TCP/IP传输控制协议中约定的报文格式,其中,约定的握手报文格式如下表所示:
在具体实施时,服务端接收的握手报文A中至少携带有客户端msg_id的值、msg_type的值、以及send_id的值,即,客户端按照约定的报文格式向服务端发送msg_type报文类型是0x0100的握手报文A,此时,握手报文A status报文状态是0,send_id客户端编码是其客户端的唯一编号。
举例说明:假设c_send_id(客户端编码)为100,假设c_msg_id(客户端的msg_id值)为999,因为没有报文内容,所以此报文长度data_len是0。而当报文是msg_type为0x0100的握手报文A时,check_sum就作为为PTK校验码,此时PTK为空,check_sum为0xff。当S2步骤完成后,表明客户端已向服务端发送握手报文A。
接下来
S3,需要基于服务端解析握手报文A
具体实施时,包括
S3-1,服务端确认得到的报文为报文类型msg_type为0x0100的握手报文A;
S3-2,服务端解析并保存c_send_id的值和c_msg_id的值后,同时,向客户端返回报文状态status是1,报文类型msg_type是0x0100以及报文序号msg_id为999的握手报文A的应答包,此时就意味着完成第一次握手。
由于本发明是通过设定一个约束条件,即,两次握手如果要成功,客户端和服务端获取的本机时间戳除以整数N且取整后,必须是一样的,故而就要求客户端和服务端必须有时间同步的功能;且在两个系统时间一致的条件下,设计存在两次握手,通过对比通信双方PTK校验码是否一致以判断PTK是否一致,达到解决现有技术问题的目的。
为此,当S3步骤结束后,接下来
S4,需要计算服务端PMK成对主密钥
具体实施时,包括
S4-1,服务端基于获取的系统当前时间戳,计算出密钥KEY后;
S4-2,以服务端的IP地址s_IP为salt随机盐值“salt”,代入Python hashlib加密模块中的函数hashlib.pbkdf2_hmac(),使用HMAC 作为伪随机函数,进行加盐和迭代操作后,哈希密钥KEY,其中,其具体调用方式为:
PMK = hashlib.pbkdf2_hmac('sha256', KEY, s_IP, iterations=500000)(1)
S5,计算服务端成对传输密钥PTK的值:
具体实施时,包括
根据服务端的握手报文A流水号,生成服务端的报文序号s_msg_id,令SALT = c_msg_id + s_msg_id + c_send_id + s_ip;则有,
PTK = hashlib.pbkdf2_hmac('sha256', PMK, SALT, iterations=500000)(2)
式中,c_msg_id 表示为客户端的报文序号;s_msg_id表示为服务端的报文序号;c_send_id表示为客户端的send_id;s_ip表示为服务端的IP地址。
S6,服务端计算PTK成对传输密钥的check_sum校验码:
具体实施时,根据上述check_sum的定义,将PTK成对传输密钥,以8个比特为单位,从高位到低位顺序累加到一个字节中,在全部计算完后,对该字节按位取反。
为更好的理解本发明提出设计成对传输密钥的check sum以应对现有技术问题的思路,(即,若此时服务端的PTK校验码与客户端PTK校验码对比失败,则重试握手):
自定义服务端计算PTK校验码值为0x7F。
因此,如图1所示,本发明继续提出第二步,基于客户端,与服务端check sum进行比对。比对的思路是:比对c_check_sum客户端-校验码与报文(下述由服务端发送的握手报文B)中的check_sum是否一致:如果都是“0x7F”说明客户端与服务端两次握手后,客户端和服务端针对该连接,构造出了符合预期的PTK。反之就要重试握手。
作为本发明的一具体实施例,本发明提出的第二步的步骤为:
S7,基于客户端,接收服务端发送的用于建立Socket通信连接的握手报文B,其中,握手报文B中至少携带有服务端msg_id的值、msg_type的值、send_id的值以及check_sum的值;
可以理解的是,结合步骤S2的示例,那么此时,服务端向客户端发送msg_type报文类型是0x0101的握手报文B,status报文状态是0,send_id是服务端编码;举例说明:自定义握手报文B s_send_id为0,且s_msg_id为888,data_len是0,check_sum为0x7F。
当S7步骤完成后,表明服务端已向客户端发送握手报文B。
接下来
S8,需要基于客户端解析握手报文B
具体实施时,包括
S8-1,客户端确认得到的报文为报文类型msg_type为0x0101的握手报文B;
S8-2,客户端解析并保存s_msg_id的值后,同时,向服务端返回报文状态status是1,报文类型msg_type是0x0101以及报文序号msg_id为888的握手报文B的应答包,完成第二次握手。
同样的,由于本发明是通过设定一个约束条件,即,两次握手如果要成功,客户端和服务端获取的本机时间戳除以整数N且取整后,必须是一样的,故而就要求客户端和服务端必须有时间同步的功能;且在两个系统时间一致的条件下,设计存在两次握手,通过对比通信双方PTK校验码是否一致以判断PTK是否一致,达到解决现有技术问题。
为此,当S8步骤结束后,接下来
S9,需要基于客户端计算PMK成对主密钥
具体实施时,包括
S9-1,客户端基于获取的系统当前时间戳,计算出密钥KEY后,
S9-2,采用与步骤S4-2同样的方式计算出PMK,再采用与步骤S4-2同样的方式根据收到的s_msg_id(服务端的msg_id),可理解的是,此时的 c_msg_id(客户端的msg_id)依然是999。
S10,客户端计算PTK和PTK校验码:
具体实施时,包括
S10-1,采用与步骤S5同样的方式计算出PTK,
S10-2,采用与步骤S6同样的方式计算出PTK校验码c_check_sum。
当经历步骤S1-S10后,对于该Socket通信连接,服务端计算出PTK,并将PTK校验码发送给客户端,同时,客户端也计算出了PTK,接下来就是客户端比对基于服务端PTK的check_sum的值与基于客户端PTK的c_check_sum的值是否一致,若一致,则说明双方计算的PTK一致,接下来可进行基于PTK的加密通信;反之,基于客户端,重试握手。
基于上述技术构思,可以理解的是,比对的目的在于验证本发明通过在两次握手的过程中将密钥通过一些过程元素构造出来的一致性,从而大大降低了密钥被窃取的风险。
在本发明的一实施例中,考虑到本发明对通信性能的影响主要体现在增加的两次握手。每次握手,计算量主要集中在“成对主密钥”,“成对传输密钥”和“校验码”。
为此,本发明还在CPU是AMD Ryzen 5 5625U(CPU max MHz:4388),系统是Ubuntu20.04的环境下,用Python3.9测试了上述三个对象的计算耗时。
发现当Hash算法是“SHA256”时,耗时大约0.03毫秒;进一步,将成对主密钥的Hash算法改为“PBKDF2”且迭代次数为500000时,耗时大约185毫秒。故而从数据结论上看,可以得出本发明提出的动态加密方法对通信性能没有影响。
同时,
作为本发明的第二方面,提出了一种基于Socket通信报文内容的动态加密系统,包括客户端和服务端;客户端,向服务端发送用于建立与服务端之间的传输控制协议TCP/IP连接的握手报文;服务端,响应于接收到客户端发送的握手报文,建立与客户端之间的Socket通信连接。
作为本发明的第三方面,提出了一种基于Socket通信报文内容的动态加密网络设备,网络设备包括相互耦合的处理器及存储器,存储器内存储计算机程序,当计算机程序被处理器执行时,使得网络设备执行基于Socket通信报文内容的动态加密方法。
作为本发明的第四方面,提出基于Socket通信报文内容的动态加密的计算机可读存储介质,计算机可读存储介质中存储有计算机程序,当计算机程序在计算机上运行时,使得计算机执行基于Socket通信报文内容的动态加密方法。
作为本发明的第二实施例,在基于Socket通信报文内容进行动态加密的技术方案中,成对主密钥和成对传输密钥的Hash计算,也快采用其他方式进行计算,如SM3,SHA-2或SHA-3,以及专门为安全密码散列而设计的密钥派生算法,如PBKDF2。
同时,在基于Socket通信报文内容进行动态加密的技术方案中,构造成对主密钥和成对传输密钥的“IP地址”,也可以通过在报文头中添加“发送方ID”来替代,只要通信双方有一个约定好的标识字段即可。
本发明的技术范围不仅仅局限于上述说明中的内容,本领域技术人员可以在不脱离本发明技术思想的前提下,对上述实施例进行多种变形和修改,而这些变形和修改均应当属于本发明的保护范围内。
Claims (8)
1.一种基于Socket通信报文内容的动态加密方法,其特征在于:应用于目标设备中,包括以下步骤:
服务端
创建监听,响应客户端的连接请求,与客户端建立Socket连接,基于该连接,接收并应答所述客户端的握手报文;其中,所述握手报文为客户端与服务端进行握手校验时使用的握手校验TCP/IP传输控制协议中约定的报文格式,所述握手报文中至少携带有客户端报文序号、约定的报文类型、约定的客户端编码;
解析所述握手报文并计算生成服务端PTK的值以及PTK校验码;
当服务端收到所述握手报文后,解析所述握手报文并计算生成服务端PTK的值的具体步骤包括:
首先,服务端确认得到的报文的报文类型为双方约定的握手报文类型;
其次,服务端解析并保存客户端编码和客户端报文序号后,同时,向客户端返回所述报文的应答报文,完成第一次握手;
再次,服务端计算成对主密钥PMK:服务端基于获取的系统当前时间戳,除以整数N并取整后,得到密钥KEY;使用密钥派生函数Key derivation function,以服务端的IP地址为盐,计算得到PMK;使用密钥派生函数,以PMK为KEY,以“c_msg_id + s_msg_id + c_send_id+ s_ip”为盐,得到成对传输密钥PTK,其中c_msg_id 表示为客户端的报文序号;s_msg_id表示为服务端的报文序号;c_send_id表示为双方约定的客户端编码;s_ip表示为服务端的IP地址;
最后,服务端根据PTK的值计算得到PTK校验码;根据服务端的通信流水号,生成服务端的报文序号;
客户端
基于所述Socket连接,接收并应答所述服务端发送的握手报文,其中,所述握手报文中至少携带有服务端报文序号、约定的报文类型、约定的服务端编码以及由服务端计算的PTK校验码;
解析所述握手报文并计算生成客户端PTK的值以及PTK校验码;
比对所述服务端PTK校验码与所述客户端PTK校验码是否一致:
若一致,则所述客户端与所述服务端各自计算的PTK一致,双方可使用PTK做加密通信;反之,则基于所述Socket连接,客户端向服务端重试握手;
当客户端收到所述握手报文后,解析所述握手报文并计算生成客户端PTK的值的具体步骤包括:
首先,客户端确认得到的报文的报文类型为双方约定的握手报文;
其次,客户端解析并保存服务端报文序号后,同时,向服务端返回所述报文的应答报文,完成第二次握手;
最后,客户端计算客户端成对传输密钥PTK的值以及PTK校验码。
2.根据权利要求1所述的一种基于Socket通信报文内容的动态加密方法,其特征在于:服务端创建监听,响应客户端的连接请求,与客户端建立Socket连接的具体步骤包括:
首先,服务端根据约定的端口配置约定的IP地址,在所述IP地址的端口上,创建监听;
其次,客户端根据约定的端口,向所述服务端的IP地址,发送一连接请求;
最后,服务端监听到此请求后,处理接受请求,完成与所述客户端之间的Socket通信连接的建立。
3.根据权利要求1所述的一种基于Socket通信报文内容的动态加密方法,其特征在于:客户端向服务端发送握手报文,其中,所述握手报文的报文类型由通信双方约定。
4.根据权利要求1所述的一种基于Socket通信报文内容的动态加密方法,其特征在于:服务端向客户端发送的握手报文,其中,所述握手报文的报文类型由通信双方约定。
5.根据权利要求1所述的一种基于Socket通信报文内容的动态加密方法,其特征在于:
根据所述服务端或客户端PTK的值计算得到的PTK校验码的具体方式为:
将服务端或客户端PTK的值,作为输入,用一Hash算法,得到固定长度的Hash值,转为字符串。
6.一种基于Socket通信报文内容的动态加密系统,其特征在于:
包括:
客户端和服务端;
所述客户端,向服务端发起Socket连接请求,并与所述服务端建立Socket通信连接;
基于所述Socket连接,接收并应答所述服务端发送的握手报文,其中,所述握手报文中至少携带有服务端报文序号、约定的报文类型、约定的服务端编码以及由服务端计算的PTK校验码;
解析所述握手报文并计算生成客户端PTK的值以及PTK校验码;
比对所述服务端PTK校验码与所述客户端PTK校验码是否一致:
若一致,则所述客户端与所述服务端各自计算的PTK一致,双方可使用PTK做加密通信;反之,则基于所述Socket连接,客户端向服务端重试握手;
当客户端收到所述握手报文后,解析所述握手报文并计算生成客户端PTK的值的具体步骤包括:
首先,客户端确认得到的报文的报文类型为双方约定的握手报文;
其次,客户端解析并保存服务端报文序号后,同时,向服务端返回所述报文的应答报文,完成第二次握手;
最后,客户端计算客户端成对传输密钥PTK的值以及PTK校验码;
所述服务端,创建监听,响应客户端的Socket连接请求,并建立与所述客户端之间的Socket通信连接;基于该连接,接收并应答所述客户端的握手报文;其中,
所述握手报文为客户端与服务端进行握手校验时使用的握手校验TCP/IP传输控制协议中约定的报文格式,所述握手报文中至少携带有客户端报文序号、约定的报文类型、约定的客户端编码;
解析所述握手报文并计算生成服务端PTK的值以及PTK校验码;
当服务端收到所述握手报文后,解析所述握手报文并计算生成服务端PTK的值的具体步骤包括:
首先,服务端确认得到的报文的报文类型为双方约定的握手报文类型;
其次,服务端解析并保存客户端编码和客户端报文序号后,同时,向客户端返回所述报文的应答报文,完成第一次握手;
再次,服务端计算成对主密钥PMK:服务端基于获取的系统当前时间戳,除以整数N并取整后,得到密钥KEY;使用密钥派生函数Key derivation function,以服务端的IP地址为盐,计算得到PMK;使用密钥派生函数,以PMK为KEY,以“c_msg_id + s_msg_id + c_send_id+ s_ip”为盐,得到成对传输密钥PTK,其中c_msg_id 表示为客户端的报文序号;s_msg_id表示为服务端的报文序号;c_send_id表示为双方约定的客户端编码;s_ip表示为服务端的IP地址;
最后,服务端根据PTK的值计算得到PTK校验码;根据服务端的通信流水号,生成服务端的报文序号。
7.一种基于Socket通信报文内容的动态加密网络设备,其特征在于:
所述网络设备包括相互耦合的处理器及存储器,所述存储器内存储计算机程序,当所述计算机程序被所述处理器执行时,使得所述网络设备执行如权利要求1-5中任一项所述的方法。
8.基于Socket通信报文内容的动态加密的计算机可读存储介质,其特征在于,
所述计算机可读存储介质中存储有计算机程序,当所述计算机程序在计算机上运行时,使得所述计算机执行如权利要求1-5中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211670274.2A CN115720176B (zh) | 2022-12-26 | 2022-12-26 | 基于Socket通信报文内容的动态加密方法、系统、网络设备及计算机可读存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211670274.2A CN115720176B (zh) | 2022-12-26 | 2022-12-26 | 基于Socket通信报文内容的动态加密方法、系统、网络设备及计算机可读存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115720176A CN115720176A (zh) | 2023-02-28 |
CN115720176B true CN115720176B (zh) | 2023-09-19 |
Family
ID=85257989
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211670274.2A Active CN115720176B (zh) | 2022-12-26 | 2022-12-26 | 基于Socket通信报文内容的动态加密方法、系统、网络设备及计算机可读存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115720176B (zh) |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104660453A (zh) * | 2015-03-20 | 2015-05-27 | 上海斐讯数据通信技术有限公司 | 服务端端口号协商方法及系统 |
CN109547471A (zh) * | 2018-12-24 | 2019-03-29 | 武汉船舶通信研究所(中国船舶重工集团公司第七二二研究所) | 网络通信方法和装置 |
KR20190034048A (ko) * | 2017-09-22 | 2019-04-01 | 삼성전자주식회사 | 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트의 서버 등록 방법 및 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트와 서버간 무결성 검증 방법 |
WO2019114703A1 (zh) * | 2017-12-15 | 2019-06-20 | 华为技术有限公司 | 一种安全通信的方法、装置和系统 |
CN110839240A (zh) * | 2018-08-17 | 2020-02-25 | 阿里巴巴集团控股有限公司 | 一种建立连接的方法及装置 |
-
2022
- 2022-12-26 CN CN202211670274.2A patent/CN115720176B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104660453A (zh) * | 2015-03-20 | 2015-05-27 | 上海斐讯数据通信技术有限公司 | 服务端端口号协商方法及系统 |
KR20190034048A (ko) * | 2017-09-22 | 2019-04-01 | 삼성전자주식회사 | 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트의 서버 등록 방법 및 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트와 서버간 무결성 검증 방법 |
WO2019114703A1 (zh) * | 2017-12-15 | 2019-06-20 | 华为技术有限公司 | 一种安全通信的方法、装置和系统 |
CN110839240A (zh) * | 2018-08-17 | 2020-02-25 | 阿里巴巴集团控股有限公司 | 一种建立连接的方法及装置 |
CN109547471A (zh) * | 2018-12-24 | 2019-03-29 | 武汉船舶通信研究所(中国船舶重工集团公司第七二二研究所) | 网络通信方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
CN115720176A (zh) | 2023-02-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Yang et al. | Faster authenticated key agreement with perfect forward secrecy for industrial internet-of-things | |
CN113691502B (zh) | 通信方法、装置、网关服务器、客户端及存储介质 | |
CN107483383B (zh) | 一种数据处理方法、终端、后台服务器及存储介质 | |
CN114329599B (zh) | 一种数据查询方法、装置及存储介质 | |
CN113300836B (zh) | 一种基于区块链和ecc的车载网络报文认证方法及系统 | |
WO2016056986A1 (en) | Improved installation of a terminal in a secure system | |
Park | One-time password based on hash chain without shared secret and re-registration | |
CN113612610B (zh) | 一种会话密钥协商方法 | |
CN116321129B (zh) | 一种轻量级的基于动态密钥的电力交易专网通信加密方法 | |
CN113507483B (zh) | 即时通讯方法、装置、服务器及存储介质 | |
US10419212B2 (en) | Methods, systems, apparatuses, and devices for securing network communications using multiple security protocols | |
CN105208005A (zh) | 一种指纹认证方法、连接设备和终端设备 | |
CN109995739A (zh) | 一种信息传输方法、客户端、服务器及存储介质 | |
CN114915396B (zh) | 一种基于国密算法的跳变密钥数字通信加密系统和方法 | |
CN114499857B (zh) | 一种实现大数据量子加解密中数据正确性与一致性的方法 | |
WO2022166214A1 (zh) | 一种密接数据验证方法、客户端、服务器及存储介质 | |
CN113132083A (zh) | 应用于北斗导航系统的安全认证系统、方法和装置 | |
CN113225180A (zh) | 一种通信密钥的保护方法和系统 | |
CN115720176B (zh) | 基于Socket通信报文内容的动态加密方法、系统、网络设备及计算机可读存储介质 | |
CN110417804B (zh) | 一种适于单片机实现的双向身份认证加密通信方法及系统 | |
Kumari et al. | Competing secure text encryption in intranet using elliptic curve cryptography | |
CN111740965A (zh) | 一种基于物理不可克隆方程的物联网设备认证方法 | |
Ding et al. | A lightweight and secure communication protocol for the IoT environment | |
Wang et al. | Application of IoT authentication key management algorithm to personnel information management | |
CN115242392B (zh) | 基于安全传输协议实现工业信息安全传输的方法及系统 |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |