CN106453314A - 数据加解密的方法及装置 - Google Patents
数据加解密的方法及装置 Download PDFInfo
- Publication number
- CN106453314A CN106453314A CN201610898424.3A CN201610898424A CN106453314A CN 106453314 A CN106453314 A CN 106453314A CN 201610898424 A CN201610898424 A CN 201610898424A CN 106453314 A CN106453314 A CN 106453314A
- Authority
- CN
- China
- Prior art keywords
- encryption
- decryption
- packet
- network interface
- interface card
- 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.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/164—Implementing security features at a particular protocol layer at the network layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network 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
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)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种数据加解密的方法及装置,涉及互联网技术领域,解决了现有的VPN在内核态进行数据包加解密的机制降低了加解密数据包收发的效率的问题。本发明的方法包括:建立网络安全协议IPsec连接后,获得IPsec连接对应的加解密算法与数据包封装方式;判断加解密算法与数据包封装方式是否符合预设加解密条件,预设加解密条件为符合网卡加解密的加解密算法以及数据包封装方式;若满足预设加解密条件,则将IPsec连接对应的数据包发送给网卡进行加解密处理。本发明应用于VPN中数据包加解密的过程中。
Description
技术领域
本发明涉及互联网技术领域,尤其涉及一种数据加解密的方法及装置。
背景技术
虚拟专用网络(Virtual Private Network,VPN)技术是指在公用网络上为用户建立的直接连接到虚拟的专用网络,它主要的功能是在公用网络上建立专用网络。为了保证端与端之间数据传输的安全性,通常需要VPN对传输的数据进行加密。而网络安全协议(Internet Protocol Security,IPSec)用以提供公用网络和专用网络的端对端的加密和验证服务。
为了提高VPN中数据包收发的效率,可以基于DPDK技术平台进行数据包的收发,DPDK是一种进行快速数据包处理的库和驱动程序。基于DPDK技术进行的数据包收发的实现在用户态,而采用IPSec协议来实现的VPN技术中,数据包的加解密通常情况下都在内核态,因此在使用DPDK技术进行收发需要加解密的数据包时需要将用户态的需要加解密的数据包交给内核态进行加解密,完成后再返回给用户态的DPDK,使DPDK将数据包发送出去。
由上述加解密的数据包收发的过程可以看到,现有的VPN在内核态进行数据包加解密的机制使加解密的数据包在用户态与内核态之间反复的交互,降低了加解密数据包收发的效率。
发明内容
鉴于上述问题,本发明提供一种数据加解密的方法及装置,用以解决现有VPN在内核态进行数据包加解密的机制降低了加解密数据包收发的效率的问题。
为解决上述技术问题,一方面,本发明提供了一种数据加解密的方法,所述方法包括:
建立网络安全协议IPsec连接后,获得所述IPsec连接对应的加解密算法与数据包封装方式;
判断所述加解密算法与所述数据包封装方式是否符合预设加解密条件,所述预设加解密条件为符合网卡加解密的加解密算法以及数据包封装方式;
若满足预设加解密条件,则将所述IPsec连接对应的数据包发送给网卡进行加解密处理。
可选的,若满足预设加解密条件,所述方法进一步包括:
为所述IPsec连接对应的会话信息上增加网卡加密标识以及网卡解密标识。
可选的,在将所述IPsec连接对应的数据包发送给网卡进行加密处理之前,所述方法进一步包括:
根据所述网卡加密标识设置发送描述符IPsec有效位、与所述数据包对应的IPsec连接对应的安全联盟SA连接序号、加密有效位以及所述数据包对应的IPsec连接的类型,以使所述网卡接收到数据包后根据所述发送描述符IPsec有效位、与所述数据包对应的IPsec连接对应的SA连接序号、加密有效位以及所述数据包对应的IPsec连接的类型确定是否可以对数据包进行加密处理,SA连接序号与IPsec连接一一对应。
可选的,所述方法进一步包括:
在建立IPsec连接后,获取加解密需要的安全关联信息,以使网卡根据所述安全关联信息对数据包进行加解密;
将所述安全关联信息对应写入网卡中,所述安全关联信息与IPsec连接一一对应。
可选的,所述将所述安全关联信息对应写入网卡中,包括:
将安全参数索引SPI、密钥、目的网间协议IP地址以及盐值Salt Value写入网卡中,以使网卡根据密钥以及Salt Value对数据包进行加密,根据安全参数索引SPI、密钥以及目的IP地址对数包进行解密。
可选的,所述方法进一步包括:
根据接收描述符上的已解密标识为数据包添加已解密标识,所述接收描述符上的已解密标识是由网卡对数据包解密之后设置的;
判断数据包上的已解密标识与所述会话信息上的网卡解密标识是否匹配;
若匹配,则确定数据包已被网卡成功解密。
可选的,所述将安全参数索引SPI、密钥、目的IP地址以及盐值SaltValue写入网卡中,包括:
根据对应的SA连接序号将所述安全参数索引SPI对应的写入SPI参数表中;
根据对应的SA连接序号将所述密钥对应的写入密钥表中;
根据对应的SA连接序号将所述目的IP地址对应的写入IP地址表中;
根据对应的SA连接序号将所述Salt Value对应的写入盐值表中。
可选的,所述方法进一步包括:
通过应用程序接口开启网卡的加解密功能。
可选的,所述方法进一步包括:
在所述IPsec连接断开后,将网卡中对应所述IPsec连接的安全关联信息删除。
可选的,所述方法进一步包括:
若不满足预设加解密条件,则将所述IPsec连接对应的数据包发送给内核进行加解密处理。
另一方面,本发明提供了一种数据加解密的装置,所述装置包括:
获得单元,用于建立网络安全协议IPsec连接后,获得所述IPsec连接对应的加解密算法与数据包封装方式;
判断单元,用于判断所述加解密算法与所述数据包封装方式是否符合预设加解密条件,所述预设加解密条件为符合网卡加解密的加解密算法以及数据包封装方式;
网卡发送单元,用于若满足预设加解密条件,则将所述IPsec连接对应的数据包发送给网卡进行加解密处理。
可选的,所述装置进一步包括:
增加单元,用于若满足预设加解密条件,为所述IPsec连接对应的会话信息上增加网卡加密标识以及网卡解密标识。
可选的,所述装置进一步包括:
设置单元,用于在将所述IPsec连接对应的数据包发送给网卡进行加密处理之前,根据所述网卡加密标识设置发送描述符IPsec有效位、与所述数据包对应的IPsec连接对应的安全联盟SA连接序号、加密有效位以及所述数据包对应的IPsec连接的类型,以使所述网卡接收到数据包后根据所述发送描述符IPsec有效位、与所述数据包对应的IPsec连接对应的SA连接序号、加密有效位以及所述数据包对应的IPsec连接的类型确定是否可以对数据包进行加密处理,SA连接序号与IPsec连接一一对应。
可选的,所述装置进一步包括:
获取单元,用于在建立IPsec连接后,获取加解密需要的安全关联信息,以使网卡根据所述安全关联信息对数据包进行加解密;
写入单元,用于将所述安全关联信息对应写入网卡中,所述安全关联信息与IPsec连接一一对应。
可选的,所述写入单元用于:
将安全参数索引SPI、密钥、目的网间协议IP地址以及盐值Salt Value写入网卡中,以使网卡根据密钥以及Salt Value对数据包进行加密,根据安全参数索引SPI、密钥以及目的IP地址对数包进行解密。
可选的,所述装置进一步包括:
添加单元,用于根据接收描述符上的已解密标识为数据包添加已解密标识,所述接收描述符上的已解密标识是由网卡对数据包解密之后设置的;
匹配单元,用于判断数据包上的已解密标识与所述会话信息上的网卡解密标识是否匹配;
确定单元,用于若匹配,则确定数据包已被网卡成功解密。
可选的,所述写入单元包括:
第一写入模块,用于根据对应的SA连接序号将所述安全参数索引SPI对应的写入SPI参数表中;
第二写入模块,用于根据对应的SA连接序号将所述密钥对应的写入密钥表中;
第三写入模块,用于根据对应的SA连接序号将所述目的IP地址对应的写入IP地址表中;
第四写入模块,用于根据对应的SA连接序号将所述Salt Value对应的写入盐值表中。
可选的,所述装置进一步包括:
开启单元,用于通过应用程序接口开启网卡的加解密功能。
可选的,所述装置进一步包括:
删除单元,用于在所述IPsec连接断开后,将网卡中对应所述IPsec连接的安全关联信息删除。
可选的,所述装置进一步包括:
内核发送单元,用于若不满足预设加解密条件,则将所述IPsec连接对应的数据包发送给内核进行加解密处理。
借由上述技术方案,本发明提供的数据加解密的方法及装置,能够在建立IPsec连接后,获得IPsec连接对应的加解密算法与数据包封装方式;判断加解密算法与数据包封装方式是否符合预设加解密条件,预设加解密条件为符合网卡加解密的加解密算法以及数据包封装方式;若满足预设加解密条件,则将IPsec连接对应的数据包发送给网卡进行加解密处理。与现有技术相比,在VPN建立的虚拟专用网络中需要对数据包进行加解密时,可以将满足网卡加解密条件的数据包在网卡中进行加解密,即现有的数据包收发过程由“网卡-快速数据包处理应用-内核(加解密)”变为“网卡(加解密)-快速数据包处理应用”,其中数据包加解密完成后都由快速数据包处理应用发出,可以看到相比将需要加解密的数据包发送给内核进行加解密的处理的方式减少了数据包在内核态和用户态之间的来回交互,因此可以提高加解密数据包处理的效率。
另外在网卡中进行加解密,可以减轻内核计算的负担,减少CPU使用资源,进一步提高整个系统的性能。
上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1示出了本发明实施例提供的一种数据加解密的方法的流程图;
图2示出了本发明实施例提供的另一种数据加解密的方法的流程图;
图3示出了本发明实施例提供的一种数据加解密的装置的组成框图;
图4示出了本发明实施例提供的另一种数据加解密的装置的组成框图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
为解决现有的VPN在内核态进行数据包加解密的机制降低了加解密数据包收发的效率的问题,本发明实施例提供了一种数据加解密的方法,如图1所示,该方法包括:
101、建立IPsec连接后,获得IPsec连接对应的加解密算法与数据包封装方式。
首先需要说明的是,本实施例应用于IPSec VPN技术中。在VPN专属网络中两个交互端进行数据交互之前,需要建立IPsec连接。在建立IPsec的过程中,会经过安全联盟(Security Association,SA)协商来确定在VPN专属网络通信过程中需要使用的加解密算法、加解密的方式以及数据包封装方式等与管理和保护端与端之间通信连接相关的信息。
因此在建立IPsec连接后,可以获得IPsec连接对应的加解密算法与数据包封装方式。
102、判断加解密算法与数据包封装方式是否符合预设加解密条件。
当获取到IPsec连接对应的加解密算法与数据包封装方式之后,判断是否符合网卡加解密的加解密算法以及数据包封装方式。本实施例中符合网卡加解密的加解密算法为AES-128-GMAC和AES-128-GCM(128-bit key),符合网卡加解密的数据包封装方式为隧道模式以及传输模式。另外,由于网卡对数据包加密时,数据包封装方式只支持传输模式,不支持隧道模式,因此在数据包加密时符合网卡加密的数据包封装方式为传输模式。
需要说明的是,若协商确定IPsec连接使用认证头(Authentication Header,AH)或者封装安全负载(Encapsulating Security Payload,ESP)验证,则符和网卡加解密的加解密算法为AES-128-GMAC,若使用ESP进行验证以及加密,则符合网卡加解密的加解密算法为AES-128-GCM。
103、若满足预设加解密条件,则将IPsec连接对应的数据包发送给网卡进行加解密处理。
若IPsec连接对应的加解密算法满足步骤102中网卡加解密的算法,并且IPsec连接对应的数据包封装方式符合网卡加解密的数据包封装方式,则将后续通过该IPsec连接进行传输的数据包发送给网卡,以使网卡对数据包进行加解密处理。
进一步的,当网卡对数据包加解密完成之后,将加解密后的数据包发送给数据包接收对象。其中的接收对象可以是DPDK等转发数据包的应用,由于数据包已经由网卡进行了加解密,因此不需要再将数据包发给内核进行加解密,DPDK直接将数据包发给更上层的应用,减少了数据包在用户态和内核态之间的交互。
本发明实施例提供的数据加解密的方法,能够在建立IPsec连接后,获得IPsec连接对应的加解密算法与数据包封装方式;判断加解密算法与数据包封装方式是否符合预设加解密条件,预设加解密条件为符合网卡加解密的加解密算法以及数据包封装方式;若满足预设加解密条件,则将IPsec连接对应的数据包发送给网卡进行加解密处理;将加解密后的数据包发送给数据包的接收对象。与现有技术相比,在VPN建立的虚拟专用网络中需要对数据包进行加解密时,可以将符合网卡加解密条件的数据包在网卡中进行加解密,即现有的数据包转发过程由“网卡-快速数据包处理应用-内核(加解密)”变为“网卡(加解密)-快速数据包处理应用”,其中数据包加解密完成后都由快速数据包处理应用发出,可以看到相比将需要加解密的数据包发送给内核进行加解密的处理的方式减少了数据包在内核态和用户态之间的来回交互,因此可以提高加解密数据包处理的效率。
进一步的,本发明另一实施例还给出了一种数据加解密的方法,如图2所示,该方法包括:
201、建立IPsec连接。
使用VPN专属网路通道进行通信的一端在与对端进行通信之前,首先需要建立端与端之间的IPsec连接,建立连接后,后续的数据传输都通过该连接进行。建立IPsec连接的具体过程与现有的建立方式相同。
202、获得IPsec连接对应的加解密算法与数据包封装方式以及安全关联信息。
其中安全关联信息包括安全参数索引(Security parameter index,SPI)、密钥、目的网间协议(Internet Protocol,IP)地址以及盐值Salt Value。SPI用于标识安全联盟SA连接,密钥是加解密过程的重要参数,目的IP地址即为IPsec连接中作为通信对端的IP地址。Salt Value是通过在密码任意固定位置插入特定的字符串。需要说明的是IPsec连接与SA连接之间存在对应的关系,具体的给出示例进行说明:若A与B之间建立IPsec连接,由于SA连接为单向逻辑连接,因此A到B的数据流对应一个SA连接,B到A的数据流也对应一个SA连接,但是对于同一IPsec连接的双向数据流分别对应的两个SA连接的序号通常是一致的。因此SA连接序号与IPsec连接是一一对应的关系。
在建立IPsec连接的过程中,会通过安全联盟SA协商好通过VPN通信过程中需要使用的加密算法以及加密的方式、SPI、密钥、目的IP地址等与管理和保护端与端之间通信连接相关的信息。因此可以在建立IPsec连接后可以获得IPsec连接对应的加解密算法与数据包封装方式以及安全关联信息。
203、判断加解密算法与数据包封装方式是否符合预设加解密条件。
该步骤的实现方式与图1步骤102的实现方式相同,此处不再赘述。
204、若满足预设加解密条件,则为IPsec连接对应的会话信息上增加网卡加密标识以及网卡解密标识。
增加网卡加密标识是为了在将IPsec连接对应的数据包发送给网卡进行加密处理之前,根据网卡加密标识设置发送描述符IPsec有效位、与数据包对应的IPsec连接对应的SA连接序号、加密有效位以及数据包对应的IPsec连接的类型,以使网卡接收到数据包后根据发送描述符IPsec有效位、与数据包对应的IPsec连接对应的SA连接序号、加密有效位以及数据包对应的IPsec连接的类型确定是否可以对数据包进行加密处理。其中IPsec连接的类型在本实施例中包括AH类型和ESP类型。
增加网卡解密标识是为了在接收数据包时判断数据包上的已解密标识与所述会话信息上的网卡解密标识是否匹配;若匹配,则确定数据包已被网卡成功解密。其中数据包上的已解密标识是根据接收描述符上的已解密标识添加的,其中接收描述符上的已解密标识是由网卡对数据包解密之后设置的。具体的,在数据包上添加已解密标识是指在数据包flags位打上已解密标识。
另外还需要将安全关联信息对应写入网卡中,以使网卡根据安全关联信息对数据包进行加解密。具体的将安全关联信息对应写入网卡中是指将安全参数索引SPI、密钥、目的IP地址以及盐值Salt Value写入网卡中,以使网卡根据密钥以及Salt Value对数据包进行加密,根据安全参数索引SPI、密钥、目的IP地址对数包进行解密。需要说明的是网卡在加解密过程使用的密钥是对称密钥。
需要说明的是,安全关联信息与IPsec连接一一对应,即每一个IPsec连接对应一组SPI、密钥、目的IP地址以及Salt Value,而每一个IPsec连接对应一个SA,因此在网卡中写入SPI、密钥、目的IP地址以及Salt Value时,需要根据IPsec连接对应的SA连接序号将SPI对应的写入SPI参数表中;根据IPsec连接对应的SA连接序号将密钥对应的写入密钥表中;根据IPsec连接对应的SA连接序号将目的网间协议IP地址对应的写入IP地址表中;根据IPsec连接对应的SA连接序号将Salt Value对应的写入盐值表中。给出具体的示例进行说明,假设IPsec连接对应的SA序号为1,则将SPI参数写入SPI参数表中索引序号为1对应的位置中,将密钥写入密钥表中索引序号为1的位置中,将目的IP地址写入IP地址表中索引序号为1的位置中,将Salt Value写入盐值表中索引序号为1的位置中。可以看到属于一个安全关联信息中的SPI、密钥、目的IP地址以及Salt Value分别对应的索引序号是相同的,并且与安全关联信息对应的IPsec连接对应的SA连接序号也是相同的。
205、在IPsec连接断开后,将网卡中对应IPsec连接的安全关联信息删除。
在SPI参数表中密钥表中IP地址表中以及盐值表中查找与对应IPsec连接对应的SA序号相同的索引序号对应的SPI、密钥、目的IP地址以及Salt Value,并将查找到的SPI、密钥、目的IP地址以及Salt Value删除。在执行删除的动作时通过对应的应用程序接口实现的。
进一步的,若IPsec连接对应的加解密算法不满足预设加解密条件,则将IPsec连接对应的数据包发送给内核进行加解密处理。这样可以保证不满足网卡加密条件的数据包还可以按照现有的数据包加解密的方式在内核中进行加解密。
进一步的,网卡进行加解密的功能在默认状态下是关闭的,因此需要通过对应的应用程序接口开启网卡的加解密功能。具体的是将网卡加解密功能对应的开关的寄存器对应的比特位清除。需要说明的是,在网卡开启加解密功能的过程中,需要网卡暂停收发数据包。
进一步的,作为对上述各实施例的实现,本发明实施例的另一实施例还提供了一种数据加解密的装置,用于实现上述图1和图2所述的方法。如图3所示,该装置包括:获得单元301、判断单元302以及网卡发送单元303。
获得单元301,用于建立网络安全协议IPsec连接后,获得IPsec连接对应的加解密算法与数据包封装方式。
首先需要说明的是,本实施例应用于IPSec VPN技术中。在VPN专属网络中两个交互端进行数据交互之前,需要建立IPsec连接。在建立IPsec的过程中,会经过安全联盟SA协商来确定在VPN专属网络通信过程中需要使用的加解密算法、加解密的方式以及数据包封装方式等与管理和保护端与端之间通信连接相关的信息。
因此在建立IPsec连接后,可以获得IPsec连接对应的加解密算法与数据包封装方式。
判断单元302,用于判断加解密算法与数据包封装方式是否符合预设加解密条件,预设加解密条件为符合网卡加解密的加解密算法以及数据包封装方式。
当获取到IPsec连接对应的加解密算法与数据包封装方式之后,判断是否符合网卡加解密的加解密算法以及数据包封装方式。本实施例中符合网卡加解密的加解密算法为AES-128-GMAC和AES-128-GCM(128-bit key),符合网卡加解密的数据包封装方式为隧道模式以及传输模式。另外,由于网卡对数据包加密时,数据包封装方式只支持传输模式,不支持隧道模式,因此在数据包加密时符合网卡加密的数据包封装方式为传输模式。
需要说明的是,若协商确定IPsec连接使用认证头(Authentication Header,AH)或者封装安全负载(Encapsulating Security Payload,ESP)验证,则符和网卡加解密的加解密算法为AES-128-GMAC,若使用ESP进行验证以及加密,则符合网卡加解密的加解密算法为AES-128-GCM。
网卡发送单元303,用于若满足预设加解密条件,则将IPsec连接对应的数据包发送给网卡进行加解密处理。
进一步的,如图4所示,装置进一步包括:
增加单元304,用于若满足预设加解密条件,为IPsec连接对应的会话信息上增加网卡加密标识以及网卡解密标识。
进一步的,如图4所示,装置进一步包括:
设置单元305,用于在将IPsec连接对应的数据包发送给网卡进行加密处理之前,根据网卡加密标识设置发送描述符IPsec有效位、与数据包对应的IPsec连接对应的安全联盟SA连接序号、加密有效位以及数据包对应的IPsec连接的类型,以使网卡接收到数据包后根据发送描述符IPsec有效位、与数据包对应的IPsec连接对应的SA连接序号、加密有效位以及数据包对应的IPsec连接的类型确定是否可以对数据包进行加密处理,SA连接序号与IPsec连接一一对应。
进一步的,如图4所示,装置进一步包括:
获取单元306,用于在建立IPsec连接后,获取加解密需要的安全关联信息,以使网卡根据安全关联信息对数据包进行加解密;
写入单元307,用于将安全关联信息对应写入网卡中,安全关联信息与IPsec连接一一对应。
进一步的,写入单元307用于:
将安全参数索引SPI、密钥、目的IP地址以及盐值Salt Value写入网卡中,以使网卡根据密钥以及Salt Value对数据包进行加密,根据安全参数索引SPI、密钥以及目的IP地址对数包进行解密。
进一步的,如图4所示,装置进一步包括:
添加单元308,用于根据接收描述符上的已解密标识为数据包添加已解密标识,接收描述符上的已解密标识是由网卡对数据包解密之后设置的;
匹配单元309,用于判断数据包上的已解密标识与会话信息上的网卡解密标识是否匹配;
确定单元310,用于若匹配,则确定数据包已被网卡成功解密。
进一步的,如图4所示,写入单元307包括:
第一写入模块3071,用于根据对应的SA连接序号将安全参数索引SPI对应的写入SPI参数表中;
第二写入模块3072,用于根据对应的SA连接序号将密钥对应的写入密钥表中;
第三写入模块3073,用于根据对应的SA连接序号将目的IP地址对应的写入IP地址表中;
第四写入模块3074,用于根据对应的SA连接序号将Salt Value对应的写入盐值表中。
进一步的,如图4所示,装置进一步包括:
开启单元311,用于通过应用程序接口开启网卡的加解密功能。
网卡进行加解密的功能在默认状态下是关闭的,因此需要通过对应的应用程序接口开启网卡的加解密功能。具体的是将网卡加解密功能对应的开关的寄存器对应的比特位清除。需要说明的是,在网卡开启加解密功能的过程中,需要网卡暂停收发数据包。
进一步的,如图4所示,装置进一步包括:
删除单元312,用于在IPsec连接断开后,将网卡中对应IPsec连接的安全关联信息删除。
在SPI参数表中密钥表中IP地址表中以及盐值表中查找与对应IPsec连接对应的SA序号相同的索引序号对应的SPI、密钥、目的IP地址以及Salt Value,并将查找到的SPI、密钥、目的IP地址以及Salt Value删除。在执行删除的动作时通过对应的应用程序接口实现的。
进一步的,如图4所示,装置进一步包括:
内核发送单元313,用于若不满足预设加解密条件,则将IPsec连接对应的数据包发送给内核进行加解密处理。
将IPsec连接对应的数据包发送给内核进行加解密处理。这样可以保证不满足网卡加密条件的数据包还可以按照现有的数据包加解密的方式在内核中进行加解密。
本发明实施例提供的数据加解密的装置,能够在建立IPsec连接后,获得IPsec连接对应的加解密算法与数据包封装方式;判断加解密算法与数据包封装方式是否符合预设加解密条件,预设加解密条件为符合网卡加解密的加解密算法以及数据包封装方式;若满足预设加解密条件,则将IPsec连接对应的数据包发送给网卡进行加解密处理;将加解密后的数据包发送给数据包的接收对象。与现有技术相比,在VPN建立的虚拟专用网络中需要对数据包进行加解密时,可以将符合网卡加解密条件的数据包在网卡中进行加解密,即现有的数据包转发过程由“网卡-快速数据包处理应用-内核(加解密)”变为“网卡(加解密)-快速数据包处理应用”,其中数据包加解密完成后都由快速数据包处理应用发出,可以看到相比将需要加解密的数据包发送给内核进行加解密的处理的方式减少了数据包在内核态和用户态之间的来回交互,因此可以提高加解密数据包处理的效率。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
可以理解的是,上述方法及装置中的相关特征可以相互参考。另外,上述实施例中的“第一”、“第二”等是用于区分各实施例,而并不代表各实施例的优劣。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述,构造这类系统所要求的结构是显而易见的。此外,本发明也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本发明的内容,并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的发明名称(如数据加解密的装置)中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
Claims (10)
1.一种数据加解密的方法,其特征在于,所述方法包括:
建立网络安全协议IPsec连接后,获得所述IPsec连接对应的加解密算法与数据包封装方式;
判断所述加解密算法与所述数据包封装方式是否符合预设加解密条件,所述预设加解密条件为符合网卡加解密的加解密算法以及数据包封装方式;
若满足预设加解密条件,则将所述IPsec连接对应的数据包发送给网卡进行加解密处理。
2.根据权利要求1所述的方法,其特征在于,若满足预设加解密条件,所述方法进一步包括:
为所述IPsec连接对应的会话信息上增加网卡加密标识以及网卡解密标识。
3.根据权利要求2所述的方法,其特征在于,在将所述IPsec连接对应的数据包发送给网卡进行加密处理之前,所述方法进一步包括:
根据所述网卡加密标识设置发送描述符IPsec有效位、与所述数据包对应的IPsec连接对应的安全联盟SA连接序号、加密有效位以及所述数据包对应的IPsec连接的类型,以使所述网卡接收到数据包后根据所述发送描述符IPsec有效位、与所述数据包对应的IPsec连接对应的SA连接序号、加密有效位以及所述数据包对应的IPsec连接的类型确定是否可以对数据包进行加密处理,SA连接序号与IPsec连接一一对应。
4.根据权利要求1所述的方法,其特征在于,所述方法进一步包括:
在建立IPsec连接后,获取加解密需要的安全关联信息,以使网卡根据所述安全关联信息对数据包进行加解密;
将所述安全关联信息对应写入网卡中,所述安全关联信息与IPsec连接一一对应。
5.根据权利要求4所述的方法,其特征在于,所述将所述安全关联信息对应写入网卡中,包括:
将安全参数索引SPI、密钥、目的网间协议IP地址以及盐值Salt Value写入网卡中,以使网卡根据密钥以及Salt Value对数据包进行加密,根据安全参数索引SPI、密钥以及目的IP地址对数包进行解密。
6.根据权利要求2所述的方法,其特征在于,所述方法进一步包括:
根据接收描述符上的已解密标识为数据包添加已解密标识,所述接收描述符上的已解密标识是由网卡对数据包解密之后设置的;
判断数据包上的已解密标识与所述会话信息上的网卡解密标识是否匹配;
若匹配,则确定数据包已被网卡成功解密。
7.根据权利要求5所述的方法,其特征在于,所述将安全参数索引SPI、密钥、目的IP地址以及盐值Salt Value写入网卡中,包括:
根据对应的SA连接序号将所述安全参数索引SPI对应的写入SPI参数表中;
根据对应的SA连接序号将所述密钥对应的写入密钥表中;
根据对应的SA连接序号将所述目的IP地址对应的写入IP地址表中;
根据对应的SA连接序号将所述Salt Value对应的写入盐值表中。
8.根据权利要求1所述的方法,其特征在于,所述方法进一步包括:
通过应用程序接口开启网卡的加解密功能。
9.根据权利要求4所述的方法,其特征在于,所述方法进一步包括:
在所述IPsec连接断开后,将网卡中对应所述IPsec连接的安全关联信息删除。
10.一种数据加解密的装置,其特征在于,所述装置包括:
获得单元,用于建立网络安全协议IPsec连接后,获得所述IPsec连接对应的加解密算法与数据包封装方式;
判断单元,用于判断所述加解密算法与所述数据包封装方式是否符合预设加解密条件,所述预设加解密条件为符合网卡加解密的加解密算法以及数据包封装方式;
网卡发送单元,用于若满足预设加解密条件,则将所述IPsec连接对应的数据包发送给网卡进行加解密处理。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610898424.3A CN106453314B (zh) | 2016-10-14 | 2016-10-14 | 数据加解密的方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610898424.3A CN106453314B (zh) | 2016-10-14 | 2016-10-14 | 数据加解密的方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN106453314A true CN106453314A (zh) | 2017-02-22 |
CN106453314B CN106453314B (zh) | 2019-07-09 |
Family
ID=58174300
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610898424.3A Active CN106453314B (zh) | 2016-10-14 | 2016-10-14 | 数据加解密的方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN106453314B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108600278A (zh) * | 2018-07-05 | 2018-09-28 | 湖州贝格信息安全科技有限公司 | 非对称加密方法及相关产品 |
CN109040790A (zh) * | 2018-06-28 | 2018-12-18 | 苏州科达科技股份有限公司 | 数据加解密方法、装置及电子设备 |
CN109150688A (zh) * | 2018-10-22 | 2019-01-04 | 网宿科技股份有限公司 | IPSec VPN数据传输方法及装置 |
CN110099062A (zh) * | 2019-05-07 | 2019-08-06 | 山东渔翁信息技术股份有限公司 | 一种网络数据的加密方法、解密方法及相关装置 |
CN110324227A (zh) * | 2019-06-26 | 2019-10-11 | 厦门网宿有限公司 | 一种vpn服务器中的数据传输方法及vpn服务器 |
CN111800436A (zh) * | 2020-07-29 | 2020-10-20 | 郑州信大捷安信息技术股份有限公司 | IPSec隔离网卡设备及安全通信方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030200456A1 (en) * | 2002-04-19 | 2003-10-23 | International Business Machines Corp. | IPSec network adapter verifier |
CN102111321A (zh) * | 2011-03-01 | 2011-06-29 | 汉柏科技有限公司 | 一种用于vpn的加解密芯片驱动方法 |
CN202094926U (zh) * | 2011-05-24 | 2011-12-28 | 上海梓灵电子科技有限公司 | 一种带有IPSec VPN加密通讯的电信3G装置 |
-
2016
- 2016-10-14 CN CN201610898424.3A patent/CN106453314B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030200456A1 (en) * | 2002-04-19 | 2003-10-23 | International Business Machines Corp. | IPSec network adapter verifier |
CN102111321A (zh) * | 2011-03-01 | 2011-06-29 | 汉柏科技有限公司 | 一种用于vpn的加解密芯片驱动方法 |
CN202094926U (zh) * | 2011-05-24 | 2011-12-28 | 上海梓灵电子科技有限公司 | 一种带有IPSec VPN加密通讯的电信3G装置 |
Non-Patent Citations (2)
Title |
---|
YAN SHEN: "《A Multi-tunnel VPN Concurrent System for New Generation Network Based on User Space》", 《2012 IEEE 11TH INTERNATIONAL CONFERENCE ON TRUST, SECURITY AND PRIVACY IN COMPUTING AND COMMUNICATIONS》 * |
吴承: "《用户态IPSec协议栈的研究与实现》", 《信息科技辑》 * |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109040790A (zh) * | 2018-06-28 | 2018-12-18 | 苏州科达科技股份有限公司 | 数据加解密方法、装置及电子设备 |
CN108600278A (zh) * | 2018-07-05 | 2018-09-28 | 湖州贝格信息安全科技有限公司 | 非对称加密方法及相关产品 |
CN109150688A (zh) * | 2018-10-22 | 2019-01-04 | 网宿科技股份有限公司 | IPSec VPN数据传输方法及装置 |
CN109150688B (zh) * | 2018-10-22 | 2021-07-09 | 网宿科技股份有限公司 | IPSec VPN数据传输方法及装置 |
CN110099062A (zh) * | 2019-05-07 | 2019-08-06 | 山东渔翁信息技术股份有限公司 | 一种网络数据的加密方法、解密方法及相关装置 |
CN110324227A (zh) * | 2019-06-26 | 2019-10-11 | 厦门网宿有限公司 | 一种vpn服务器中的数据传输方法及vpn服务器 |
CN111800436A (zh) * | 2020-07-29 | 2020-10-20 | 郑州信大捷安信息技术股份有限公司 | IPSec隔离网卡设备及安全通信方法 |
CN111800436B (zh) * | 2020-07-29 | 2022-04-08 | 郑州信大捷安信息技术股份有限公司 | IPSec隔离网卡设备及安全通信方法 |
Also Published As
Publication number | Publication date |
---|---|
CN106453314B (zh) | 2019-07-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106453314A (zh) | 数据加解密的方法及装置 | |
CN102035814B (zh) | 通过vpn ipsec隧道确保服务质量 | |
CN102932349B (zh) | 一种数据传输方法、装置及系统 | |
CN105357218B (zh) | 一种具备硬件加解密功能的路由器及其加解密方法 | |
CN104394148B (zh) | IPv6下IPSec协议外出处理硬件实现系统 | |
CN108762791A (zh) | 固件升级方法及装置 | |
CN106487749A (zh) | 密钥生成方法及装置 | |
CN102625995A (zh) | 无线网络中的伽罗瓦/计数器模式加密 | |
CN107454590A (zh) | 一种数据加密方法、解密方法及无线路由器 | |
CN105897748B (zh) | 一种对称密钥的传输方法及设备 | |
CN112653719A (zh) | 汽车信息安全存储方法、装置、电子设备和存储介质 | |
CN107483192A (zh) | 一种基于量子通讯的数据传输方法及装置 | |
CN102970228B (zh) | 一种基于IPsec的报文传输方法和设备 | |
CN109831775B (zh) | 一种处理器、基带芯片以及sim卡信息传输方法 | |
CN107896222A (zh) | 一种数据处理方法及系统 | |
CN106657085A (zh) | 数据处理方法和装置及加密装置 | |
CN109409109A (zh) | 网络服务中的数据处理方法、装置、处理器及服务器 | |
CN109495885A (zh) | 认证方法、移动终端、管理系统及蓝牙ic卡 | |
CN106209384B (zh) | 使用安全机制的客户终端与充电装置的通信认证方法 | |
CN105227569B (zh) | 应用的数据包传输方法及装置 | |
CN108111515B (zh) | 一种适用于卫星通信的端到端安全通信加密方法 | |
CN107454116A (zh) | 单隧道模式下IPsec ESP协议的优化方法及装置 | |
CN109145620A (zh) | 数据流分流处理方法及装置 | |
CN202713365U (zh) | 一种对网络数据流硬件加密的系统 | |
CN106055989B (zh) | 一种数据传递方法及终端 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |