CN101222512A - 加解密卡及加密方法和解密方法 - Google Patents
加解密卡及加密方法和解密方法 Download PDFInfo
- Publication number
- CN101222512A CN101222512A CNA2008100568940A CN200810056894A CN101222512A CN 101222512 A CN101222512 A CN 101222512A CN A2008100568940 A CNA2008100568940 A CN A2008100568940A CN 200810056894 A CN200810056894 A CN 200810056894A CN 101222512 A CN101222512 A CN 101222512A
- Authority
- CN
- China
- Prior art keywords
- encryption
- message
- decryption
- card
- processing unit
- 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
Landscapes
- Small-Scale Networks (AREA)
Abstract
本发明涉及一种加解密卡及加密方法和解密方法，其中加解密卡包括：专用CPU，用于与对端设备进行密钥协商；加解密芯片，用于根据由专用CPU协商确定的密钥对待加密报文进行加密，并对经过报文重组后的已加密报文进行解密；报文处理单元，用于将由加解密芯片加密的已加密报文和解密后的明文发送给所述网络处理器。通过本发明，由于加解密过程无需经过系统主CPU，因此减少了系统主CPU的负担；由于加解密过程只通过卡内高速接口实现，因此不会受到系统PCI总线带宽的限制，提高了运算速度和加密性能；并且，采用该加解密卡进行加解密无需对对端设备进行任何改变，因此也不会存在不同厂商的设备之间的互通问题。
Description
技术领域
本发明涉及一种加解密技术，尤其涉及一种应用于IP安全协议技术中的加解密卡及加密方法和解密方法。
背景技术
IP安全(IP Security，以下简称：IPSec)协议族是互联网工程任务组(Internet Engineering Task Force，简称：IETF)制定的一系列协议，它为IP数据报提供了高质量、可互操作、基于密码学的安全性策略，为IP层或IP层之上提供了保护。特定的通信双方之间在IP层通过加密与数据源验证等方式，来保证数据报在网络上传输时的私有性、完整性、真实性和防重放。
现有IPSec主要通过认证头(Authentication Header，简称：AH)协议和封装安全载荷(Encapsulating Security Payload，简称：ESP)协议这两个安全协议来实现上述目标。并且还可以通过因特网密钥交换(Internet KeyExchange，简称：IKE)协议为IPSec提供了自动协商交换密钥、建立和维护安全联盟的服务，以简化IPSec的使用和管理。
现有的上述IPSec协议族也经常被应用于IPSec虚拟私有网络(VirtualPrivate Network，以下简称：VPN)中。IPSec VPN的性能与密码算法的性能密切相关。IPSec常用的密码算法，如数据加密标准(Data Encryption Standard，简称：DES)、3DES、高级加密标准(Advanced Encryption Standard，简称：AES)等都需要大量的计算密集性操作，对系统性能提出了很高的要求。因此，很多厂商均推出了基于硬件加速的IPSec加密卡。
用于上述IPSec VPN的加密卡主要分为用于低端设备的加密卡和用于高端设备的加密卡。其中，用于低端设备的加密卡一般通过系统PCI总线将加密芯片连接到系统，由主CPU参与加解密运算。因此，加解密运算过程会受限于系统PCI总线带宽性能的限制，使系统整体的加解密性能较低，影响加解密运算的速度，并且，也增加了系统主CPU的负担。
另外，用于高端设备的加密卡一般通过网络处理器进行报文转发，网络处理器将数据通过千兆以太网(Gigabit Ethernet，简称：GE)接口等高速接口与加密芯片连接，确保加解密所需的带宽。这种方案可以提高IPSec的吞吐量，但是，IKE协商仍然需要在主CPU上完成，因此，仍然需要占用主CPU大量的处理时间，对大量并发的IPSec协商仍然是瓶颈。
另外，采用现有IPSec加密技术进行加密后的加密报文在隧道中进行传输时很容易产生大量分片。这是由于在对原始报文进行加密后，由于加密报文中增加了认证头等附加信息，因此使得加密报文的数据长度更长。当在隧道中进行传输的IP报文超过一定长度时，根据现有技术，会对其进行分片，使得原本不需要进行分片的原始报文，经加密成为加密报文后产生了大量的分片。由于分片的存在，在隧道的另一端需要进行报文重组，以恢复分片前的加密报文。根据现有技术，报文重组仍然是由系统的主CPU完成的，因此在加解密吞吐量要求较高的网络中，通过CPU进行重组的加密性能是难以保证的。另外，虽然网络处理器也可以完成报文重组，但是网络处理器的指令空间非常有限，报文重组会占用网络处理器的宝贵的指令空间，使设备功能的扩展将会受到严重制约。
另外，为了解决报文重组的问题，现有技术中也可以采用IPSec路径最大传输单位(Path Maximum Transfer Unit，以下简称：PMTU)发现机制对IPSec的加密报文分片问题进行规避。但是，现有标准并没有强制规定PMTU的实现，因此，PMTU发现机制尚未被所有厂商采用，使得不同厂商的设备之间进行互通仍然可能存在问题。
发明内容
本发明实施例提供了一种加解密卡，以便于在现有报文重组及加解密过程减少对系统主CPU的大量资源的占用。
本发明实施例提供的加解密卡，与网络处理器相连，该加解密卡包括：
专用CPU，用于与对端设备进行密钥协商；
加解密芯片，用于根据由专用CPU协商确定的密钥对待加密报文进行加密，并对经过报文重组后的已加密报文进行解密；
报文处理单元，用于将由加解密芯片加密的已加密报文和解密后的明文发送给所述网络处理器。
本发明实施例还提供了一种加密方法，其中包括：
专用CPU与对端设备进行密钥协商；
加解密芯片根据由专用CPU协商确定的密钥对待加密报文进行加密；
报文处理单元将由加解密芯片加密的已加密报文发送给所述网络处理器。
本发明实施例还提供了一种解密方法，其中包括：
报文处理单元将来自于网络处理器的分片的已加密报文进行报文重组，并发送给加解密芯片；
加解密芯片根据由专用CPU协商确定的密钥对经过报文重组后的已加密报文进行解密；
报文处理单元将解密后的明文发送给网络处理器。
通过本发明，由于加解密过程是在专用CPU的控制下完成的，无需经过系统主CPU，因此减少了系统主CPU的负担；由于加解密过程只通过卡内高速接口实现，因此不会受到系统PCI总线带宽的限制，提高了运算速度和加密性能；并且，采用该加解密卡进行加解密无需对对端设备进行任何改变，因此也不会存在不同厂商的设备之间的互通问题。
下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。
附图说明
图1为本发明实施例所述加解密卡的结构示意图。
具体实施方式
本实施例提供了一种加解密卡，如图1所示，加解密卡10包括：专用CPU11、加解密芯片12和报文处理单元14，可以采用总线连接方式等多种方式对专用CPU11、加解密芯片12和报文处理单元14进行连接。具体地，在图1中，专用CPU11、加解密芯片12和报文处理单元14，都连接于卡内总线13上。该卡内总线13可以为卡内周边元件扩展接口(Peripheral ComponentInterconnect，以下简称：PCI)总线。报文处理单元14通过吉比特媒体独立接口(Gigabit Media Independent Interface，以下简称：GMII)与加解密卡10外部的网络处理器相连。其工作原理如下：
在进行加密时，专用CPU11与对端设备进行密钥协商，具体地，可以基于IKE协议进行密钥协商；协商完成后，通过卡内总线13将待加密报文发送给加解密芯片12；加解密芯片12根据由专用CPU11协商确定的密钥对待加密报文进行加密，加密完成后，将已加密报文发送给报文处理单元14；报文处理单元14中的报文发送模块141将由加解密芯片12加密的已加密报文发送给网络处理器，再通过网络处理器对已加密报文进行分片传输操作，将分片的已加密报文发送给对端设备。
在进行解密时，报文处理单元14中的报文重组模块142将来自于网络处理器的分片的已加密报文进行报文重组，恢复成分片前的已加密报文，并发送给加解密芯片12；加解密芯片12根据预先协商好的密钥对已加密报文进行解密，并将解密后的明文通过网络处理器转发给内网中的其他设备进行相关处理。具体地，报文处理单元14可以通过现场可编程门阵列(FieldProgrammable Gate Array，以下简称：FPGA)实现。FPGA可以通过GMII等高速接口与加解密芯片12连接。其中，FPGA是在多种可编程器件的基础上发展的具有高集成度的专用集成电路。采用FPGA来开发报文处理单元14可以大大缩短设计时间，减少印刷电路板的面积，提高系统的运行速度及可靠性。
通过本实施例所述加解密卡，由于加解密过程是在专用CPU的控制下完成的，无需经过系统主CPU，因此减少了系统主CPU的负担；由于加解密过程只通过卡内高速接口实现，因此不会受到系统PCI总线带宽的限制，提高了运算速度和加密性能；由于对分片报文的重组操作是加解密卡内部的FPGA实现的，无需系统主CPU的参与，因此不会增加系统主CPU的负担；并且，采用该加解密卡进行加解密无需对对端设备进行任何改变，因此也不会存在不同厂商的设备之间的互通问题。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (10)
1.一种加解密卡，与网络处理器相连，其特征在于，该加解密卡包括：
专用CPU，用于与对端设备进行密钥协商；
加解密芯片，用于根据由专用CPU协商确定的密钥对待加密报文进行加密，并对经过报文重组后的已加密报文进行解密；
报文处理单元，用于将由加解密芯片加密的已加密报文和解密后的明文发送给所述网络处理器。
2.根据权利要求1所述的加解密卡，其特征在于所述报文处理单元包括：报文发送模块，用于将由加解密芯片加密的已加密报文。
3.根据权利要求2所述的加解密卡，其特征在于所述报文处理单元还包括：报文重组模块，用于将来自于所述网络处理器的分片的已加密报文进行报文重组，并发送给所述加解密芯片。
4.根据权利要求1至2任一所述的加解密卡，其特征在于所述报文处理单元通过现场可编程门阵列FPGA实现。
5.根据权利要求4所述的加解密卡，其特征在于所述FPGA通过高速接口与所述加解密芯片连接。
6.根据权利要求4所述的加解密卡，其特征在于所述专用CPU、报文处理单元及加解密芯片连接于卡内总线上。
7.根据权利要求6所述的加解密卡，其特征在于所述卡内总线为卡内PCI总线。
8.根据权利要求1至3任一所述的加解密卡，其特征在于所述报文处理单元通过吉比特媒体独立接口与所述网络处理器相连。
9.一种加密方法，其特征在于包括：
专用CPU与对端设备进行密钥协商；
加解密芯片根据由专用CPU协商确定的密钥对待加密报文进行加密；
报文处理单元将由加解密芯片加密的已加密报文发送给所述网络处理器。
10.一种解密方法，其特征在于包括：
报文处理单元将来自于网络处理器的分片的已加密报文进行报文重组，并发送给加解密芯片；
加解密芯片根据由专用CPU协商确定的密钥对经过报文重组后的已加密报文进行解密；
报文处理单元将解密后的明文发送给网络处理器。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2008100568940A CN101222512A (zh) | 2008-01-25 | 2008-01-25 | 加解密卡及加密方法和解密方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2008100568940A CN101222512A (zh) | 2008-01-25 | 2008-01-25 | 加解密卡及加密方法和解密方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101222512A true CN101222512A (zh) | 2008-07-16 |
Family
ID=39632080
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2008100568940A Pending CN101222512A (zh) | 2008-01-25 | 2008-01-25 | 加解密卡及加密方法和解密方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101222512A (zh) |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102065021A (zh) * | 2011-01-28 | 2011-05-18 | 北京交通大学 | 基于NetFPGA的IPSecVPN实现系统及方法 |
| CN102223309A (zh) * | 2011-07-07 | 2011-10-19 | 谢海春 | 基于报文载荷分片、加密、重排序的安全通讯系统及其实现方法 |
| CN102843235A (zh) * | 2012-09-06 | 2012-12-26 | 汉柏科技有限公司 | 一种报文加/解密方法 |
| CN105610790A (zh) * | 2015-12-17 | 2016-05-25 | 武汉邮电科学研究院 | IPSec加密卡与CPU协同的用户面数据处理方法 |
| CN107147673A (zh) * | 2017-06-21 | 2017-09-08 | 中国电子信息产业集团有限公司第六研究所 | 基于灵活加密解密卡的远程无线加密通信技术 |
| CN108390847A (zh) * | 2017-12-29 | 2018-08-10 | 上海顶竹通讯技术有限公司 | 一种无线专网实时通信业务加密方法及系统 |
| CN108616355A (zh) * | 2018-05-03 | 2018-10-02 | 盛科网络（苏州）有限公司 | 软件握手协商硬件加解密的capwap隧道dtls加解密方法 |
| CN109756505A (zh) * | 2019-01-16 | 2019-05-14 | 北京左江科技股份有限公司 | 一种对终端设备透明的tcp/ip网络传输报文重组方法 |
| CN111241603A (zh) * | 2020-01-07 | 2020-06-05 | 北京智芯微电子科技有限公司 | 基于PCIe接口的加密卡架构、加密卡及电子设备 |
| CN112260926A (zh) * | 2020-10-16 | 2021-01-22 | 上海叠念信息科技有限公司 | 虚拟专用网络的数据传输系统、方法、装置、设备及存储介质 |
| CN113194097A (zh) * | 2021-04-30 | 2021-07-30 | 北京数盾信息科技有限公司 | 一种安全网关的数据处理方法、装置及安全网关 |
-
2008
- 2008-01-25 CN CNA2008100568940A patent/CN101222512A/zh active Pending
Cited By (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102065021A (zh) * | 2011-01-28 | 2011-05-18 | 北京交通大学 | 基于NetFPGA的IPSecVPN实现系统及方法 |
| CN102065021B (zh) * | 2011-01-28 | 2012-12-26 | 北京交通大学 | 基于NetFPGA的IPSecVPN实现系统及方法 |
| CN102223309A (zh) * | 2011-07-07 | 2011-10-19 | 谢海春 | 基于报文载荷分片、加密、重排序的安全通讯系统及其实现方法 |
| CN102843235A (zh) * | 2012-09-06 | 2012-12-26 | 汉柏科技有限公司 | 一种报文加/解密方法 |
| CN105610790B (zh) * | 2015-12-17 | 2019-01-18 | 武汉邮电科学研究院有限公司 | IPSec加密卡与CPU协同的用户面数据处理方法 |
| CN105610790A (zh) * | 2015-12-17 | 2016-05-25 | 武汉邮电科学研究院 | IPSec加密卡与CPU协同的用户面数据处理方法 |
| CN107147673A (zh) * | 2017-06-21 | 2017-09-08 | 中国电子信息产业集团有限公司第六研究所 | 基于灵活加密解密卡的远程无线加密通信技术 |
| CN108390847A (zh) * | 2017-12-29 | 2018-08-10 | 上海顶竹通讯技术有限公司 | 一种无线专网实时通信业务加密方法及系统 |
| CN108390847B (zh) * | 2017-12-29 | 2020-08-25 | 上海顶竹通讯技术有限公司 | 一种无线专网实时通信业务加密方法及系统 |
| CN108616355A (zh) * | 2018-05-03 | 2018-10-02 | 盛科网络（苏州）有限公司 | 软件握手协商硬件加解密的capwap隧道dtls加解密方法 |
| CN109756505A (zh) * | 2019-01-16 | 2019-05-14 | 北京左江科技股份有限公司 | 一种对终端设备透明的tcp/ip网络传输报文重组方法 |
| CN111241603A (zh) * | 2020-01-07 | 2020-06-05 | 北京智芯微电子科技有限公司 | 基于PCIe接口的加密卡架构、加密卡及电子设备 |
| CN112260926A (zh) * | 2020-10-16 | 2021-01-22 | 上海叠念信息科技有限公司 | 虚拟专用网络的数据传输系统、方法、装置、设备及存储介质 |
| CN112260926B (zh) * | 2020-10-16 | 2022-06-03 | 上海叠念信息科技有限公司 | 虚拟专用网络的数据传输系统、方法、装置、设备及存储介质 |
| CN113194097A (zh) * | 2021-04-30 | 2021-07-30 | 北京数盾信息科技有限公司 | 一种安全网关的数据处理方法、装置及安全网关 |
| CN113194097B (zh) * | 2021-04-30 | 2022-02-11 | 北京数盾信息科技有限公司 | 一种安全网关的数据处理方法、装置及安全网关 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101222512A (zh) | 加解密卡及加密方法和解密方法 | |
| CN110999248B (zh) | 使用片上系统(SoC)体系结构的安全通信加速 | |
| EP3286896B1 (en) | Scalable intermediate network device leveraging ssl session ticket extension | |
| US6996842B2 (en) | Processing internet protocol security traffic | |
| JP2023116573A (ja) | クライアント－クラウドまたはリモートサーバーの安全なデータまたはファイル・オブジェクト暗号化ゲートウェイ | |
| Zelle et al. | On using TLS to secure in-vehicle networks | |
| US8843747B2 (en) | Communication apparatus and communication system | |
| WO2005034412A2 (en) | Method and apparatus of communicating security/encryption information to a physical layer transceiver | |
| EP3613195A1 (en) | Cloud storage using encryption gateway with certificate authority identification | |
| CN106254231A (zh) | 一种基于状态的工业安全加密网关及其实现方法 | |
| CN114422256B (zh) | 一种基于ssal/ssl协议的高性能安全接入方法及装置 | |
| CN101861712A (zh) | 基于移动因特网协议的服务器的安全方法 | |
| KR101448866B1 (ko) | 웹 보안 프로토콜에 따른 암호화 데이터를 복호화하는 보안 장치 및 그것의 동작 방법 | |
| WO2016165277A1 (zh) | 一种实现IPsec分流的方法和装置 | |
| Siddiqui et al. | A secure communication framework for ecus | |
| JP2008154103A (ja) | 通信中継装置 | |
| US20160366191A1 (en) | Single Proxies in Secure Communication Using Service Function Chaining | |
| WO2014137351A1 (en) | Routing a data packet to a shared security engine | |
| Zuo et al. | A novel software-defined network packet security tunnel forwarding mechanism | |
| Luo et al. | Routing and security mechanisms design for automotive tsn/can fd security gateway | |
| CN202713365U (zh) | 一种对网络数据流硬件加密的系统 | |
| EP1668807B1 (en) | Method and apparatus of integrating link layer security into a physical layer transceiver | |
| Hohendorf et al. | Secure end-to-end transport over sctp | |
| EP4346255A1 (en) | Encrypted satellite communications | |
| Hao et al. | WB-GWS: An IoT-Oriented Lightweight Gateway System Based on White-Box Cryptography |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| ASS | Succession or assignment of patent right |
Owner name: CHENGDU CITY HUAWEI SAIMENTEKE SCIENCE CO., LTD. Free format text: FORMER OWNER: HUAWEI TECHNOLOGY CO., LTD. Effective date: 20090424 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20090424 Address after: Qingshui River District, Chengdu high tech Zone, Sichuan Province, China: 611731 Applicant after: Chengdu Huawei Symantec Technologies Co., Ltd. Address before: Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Province, China: 518129 Applicant before: Huawei Technologies Co., Ltd. |
|
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Open date: 20080716 |