掌桥专利:专业的专利平台
掌桥专利
首页

基于Socket通信报文内容的动态加密方法、系统

文献发布时间:2023-06-19 18:37:28


基于Socket通信报文内容的动态加密方法、系统

技术领域

本发明涉及数据隐私安全计算技术领域,具体为基于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”来替代,只要通信双方有一个约定好的标识字段即可。

本发明的技术范围不仅仅局限于上述说明中的内容,本领域技术人员可以在不脱离本发明技术思想的前提下,对上述实施例进行多种变形和修改,而这些变形和修改均应当属于本发明的保护范围内。

技术分类

06120115638556