CN105162796A - 一种数据传输的方法与设备 - Google Patents

一种数据传输的方法与设备 Download PDF

Info

Publication number
CN105162796A
CN105162796A CN201510616052.6A CN201510616052A CN105162796A CN 105162796 A CN105162796 A CN 105162796A CN 201510616052 A CN201510616052 A CN 201510616052A CN 105162796 A CN105162796 A CN 105162796A
Authority
CN
China
Prior art keywords
described packet
packet
server
transmission direction
added
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
CN201510616052.6A
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.)
Upper Marine Infotech Share Co Ltd Of Interrogating
Original Assignee
Upper Marine Infotech Share Co Ltd Of Interrogating
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 Upper Marine Infotech Share Co Ltd Of Interrogating filed Critical Upper Marine Infotech Share Co Ltd Of Interrogating
Priority to CN201510616052.6A priority Critical patent/CN105162796A/zh
Publication of CN105162796A publication Critical patent/CN105162796A/zh
Pending legal-status Critical Current

Links

Classifications

    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请的目的是提供一种数据传输的方法与设备。本申请将接收到的待传输的数据包从内核空间导入至用户空间,然后检测处于用户空间的所述数据包是否待加解密处理,当所述数据包待加解密处理,根据所述数据包的传输方向对所述数据包进行加解密处理,最后通过网关传输经加解密处理后的所述数据包。与现有技术相比,本申请通过对接收自服务器的数据包进行加密处理,对待传输至服务器数据包进行解密处理,使得待加解密处理的所述数据包在网关与用户设备之间的传输过程中处于加密状态,并且以加密状态存储于用户设备,满足了传输安全的需求,保证了所述数据包在用户设备处的存储安全。

Description

一种数据传输的方法与设备
技术领域
本申请涉及计算机与通信领域,尤其涉及一种数据传输的技术。
背景技术
随着计算机与信息技术尤其是网络技术的飞速发展,数据信息已经成为整个社会最为关键的资源之一,企事业单位需要共享访问的数据信息越来越多,并且越来越重要,如何保证这些私密数据信息在网络传输时的安全,已经成为亟待解决的重大问题。
目前,为了保护基于网络传输时的文件内容安全,主要采用以下五种方法:(1)端对端传输通道TLS/SSL(TransportLayerSecurity/SecureSocketsLayer,传输层安全/安全套接层)加密。服务器和客户端之间的数据传输使用加密通道,服务器和客户端上的数据为明文,在通信通道中传输的数据为密文。(2)对服务器设置访问来源限制。针对不同访问来源设置不同的限制策略,并在其连接服务器之前进行访问来源合法性检测。(3)对数据设置访问权限,进行访问控制。针对不同的用户设置不同的访问权限,并在其访问私密数据之前对其身份进行合法性验证。(4)完整的存储/传输加密。数据存储及传输过程均以密文形式存在。(5)使用代理进行数据加解密和访问控制。客户端通过代理服务器连接数据服务器,在代理服务器上进行数据加解密并转发。
然而,现有技术的几种方法均存在一些不足之处:(1)采用端对端传输通道TLS/SSL加密技术,当数据进入传输通道时进行加密,在数据离开传输通道时进行解密。这种实现方法保证了私密数据网络传输的安全性,但并没有对私密数据存储的安全性进行处理,因此,一旦客户端存储私密数据的存储设备暴露,或不受信任的客户端接入网络,私密数据的泄漏是显而易见的。(2)采用服务器访问来源限制技术,控制访问来源为信任区域,丢弃任何非信任来源的访问请求。该方法需要设置信任区域,在当前网络入侵、内网渗透流行的网络安全形势下,该方法过于理想化,已经无法满足现实需求。(3)采用访问控制,针对不同用户的私密数据设置不同的访问权限,以保证每个用户只能访问自己的私密数据。显然,这种方法不能保证私密数据的存储和网络传输安全。(4)完整的存储/传输加密方案。服务器及客户端数据均加密存储,传输信道中数据也是加密数据。该方法可保证数据存储及传输过程中的安全性,但是部署复杂,对现有的服务器升级技术难度较大,消耗时间过长。(5)采用代理进行数据加解密技术和访问控制。该方法在服务器前设置代理服务器,所有客户端连接均通过代理服务器进行,由代理服务器进行数据加解密。该方法保证了由服务器流向客户端的数据的安全性,但由于采用代理机制,要做到对服务器网络透明的话,技术流程较复杂,而且代理方式资源占用率高,对硬件设备要求较高。
发明内容
本申请的一个目的是提供一种数据传输的方法与设备。
根据本申请的一个方面,提供了一种数据传输方法,其中,该方法包括:
a通过网关接收待传输的数据包;
b将所述数据包从内核空间导入至用户空间;
c检测处于用户空间的所述数据包是否待加解密处理;
d当所述数据包待加解密处理,根据所述数据包的传输方向对所述数据包进行加解密处理;
e通过所述网关传输经加解密处理后的所述数据包。
进一步地,所述根据所述数据包的传输方向对所述数据包进行加解密处理包括:若所述数据包为明文数据包且接收自服务器,对所述数据包进行加密处理;或者若所述数据包为密文数据包且待传输至服务器,对所述数据包进行解密处理。
进一步地,所述步骤d包括:当所述数据包待加解密处理,根据所述数据包的目的地址或源地址确定所述数据包的传输方向;根据所述数据包的传输方向对所述数据包进行加解密处理。
进一步地,所述根据所述数据包的目的地址或源地址确定所述数据包的传输方向包括:若所述数据包的目的地址属于服务器地址范围,确定所述数据包的传输方向为待传输至服务器;或者若所述数据包的源地址属于服务器地址范围,确定所述数据包的传输方向为接收自服务器。
进一步地,所述步骤c包括:根据处于用户空间的所述数据包所使用的传输协议,确定所述数据包是否待加解密处理。
进一步地,所述步骤c包括:根据处于用户空间的所述数据包的文件类型,确定所述数据包是否待加解密处理。
根据本申请的另一个方面,提供了一种数据传输设备,其中,该设备包括:
第一装置,用于通过网关接收待传输的数据包;
第二装置,用于将所述数据包从内核空间导入至用户空间;
第三装置,用于检测处于用户空间的所述数据包是否待加解密处理;
第四装置,用于当所述数据包待加解密处理,根据所述数据包的传输方向对所述数据包进行加解密处理;
第五装置,用于通过所述网关传输经加解密处理后的所述数据包。
进一步地,所述根据所述数据包的传输方向对所述数据包进行加解密处理包括:若所述数据包为明文数据包且接收自服务器,对所述数据包进行加密处理;或者若所述数据包为密文数据包且待传输至服务器,对所述数据包进行解密处理。
进一步地,所述第四装置用于:当所述数据包待加解密处理,根据所述数据包的目的地址或源地址确定所述数据包的传输方向;根据所述数据包的传输方向对所述数据包进行加解密处理。
进一步地,所述根据所述数据包的目的地址或源地址确定所述数据包的传输方向包括:若所述数据包的目的地址属于服务器地址范围,确定所述数据包的传输方向为待传输至服务器;或者若所述数据包的源地址属于服务器地址范围,确定所述数据包的传输方向为接收自服务器。
进一步地,所述第三装置用于:根据处于用户空间的所述数据包所使用的传输协议,确定所述数据包是否待加解密处理。
进一步地,所述第三装置用于:根据处于用户空间的所述数据包的文件类型,确定所述数据包是否待加解密处理。
与现有技术相比,本申请将接收到的待传输的数据包从内核空间导入至用户空间,然后检测处于用户空间的所述数据包是否待加解密处理,当所述数据包待加解密处理,根据所述数据包的传输方向对所述数据包进行加解密处理,最后通过网关传输经加解密处理后的所述数据包。本申请通过对接收自服务器的数据包进行加密处理,对待传输至服务器数据包进行解密处理,使得待加解密处理的所述数据包在网关与用户设备之间的传输过程中处于加密状态,并且以加密状态存储于用户设备,满足了传输安全的需求,保证了所述数据包在用户设备处的存储安全。进一步地,根据所述数据包所使用的传输协议和/或所述数据包的文件类型,确定所述数据包是否待加解密处理,可满足根据实际情况灵活配置的需求,提升用户体验。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显:
图1示出根据本申请一个方面的一种用于数据传输的系统拓扑示意图;
图2示出根据本申请另一个方面的一种用于数据传输的设备示意图;
图3示出根据本申请一个方面的一种用于数据传输的方法流程图。
附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
下面结合附图对本申请作进一步详细描述。
在本申请一个典型的配置中,终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据包结构、程序的模块或其他数据包。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitorymedia),如调制的数据包信号和载波。
图1示出根据本申请一个方面的一种用于数据传输的系统拓扑示意图。
一个或多个用户设备经由网关和设备1,与一个或多个服务器之间进行数据传输。其中,设备1为根据本申请另一个方面的一种用于数据传输的设备。具体地,从用户设备发送至服务器或从服务器发送至用户设备的数据包通过网关进行转发。设备1通过网关接收待传输的数据包;然后将所述数据包从内核空间导入至用户空间;接着检测处于用户空间的所述数据包是否待加解密处理;当所述数据包待加解密处理,根据所述数据包的传输方向对所述数据包进行加解密处理;最后通过所述网关传输经加解密处理后的所述数据包,将所述数据包按其目的地址转发至服务器或用户设备,完成数据传输。
在此,网关是具备路由功能的计算机系统或设备,包括但不限于路由器、交换机等。设备1可以独立运行,也可以与网关相结合。用户设备包括但不限于电脑、智能手机、平板电脑等;服务器包括但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(CloudComputing)的由大量计算机或网络服务器构成的云,其中,云计算是分布式计算的一种,由一群松散耦合的计算机集组成的一个超级虚拟计算机。这些用户设备或服务器可通过接入网络并与网络中的其他设备的交互操作来实现本申请。其中,所述网络包括但不限于互联网、广域网、城域网、局域网、VPN网络等。
需要说明的是,所述用户设备、服务器等仅为举例,其他现有的或今后可能出现的计算机设备或网络如可适用于本申请,也应包含在本申请保护范围以内,并以引用方式包含于此。
图2示出根据本申请另一个方面的一种用于数据传输的设备1,其中,设备1包括第一装置11、第二装置12、第三装置13、第四装置14和第五装置15。
具体地,所述第一装置11通过网关接收待传输的数据包;所述第二装置12将所述数据包从内核空间导入至用户空间;所述第三装置13检测处于用户空间的所述数据包是否待加解密处理;所述第四装置14当所述数据包待加解密处理,根据所述数据包的传输方向对所述数据包进行加解密处理;所述第五装置15通过所述网关传输经加解密处理后的所述数据包。
在此,所述设备1包括但不限于用户设备、网络设备、或用户设备与网络设备通过网络相集成所构成的设备。所述用户设备其包括但不限于任何一种可与用户通过触摸板进行人机交互的移动电子产品,例如智能手机、平板电脑等,所述移动电子产品可以采用任意操作系统,如android(安卓)操作系统、iOS操作系统(苹果公司的移动操作系统)等。其中,所述网络设备包括一种能够按照事先设定或存储的指令,自动进行数值计算和信息处理的电子设备,其硬件包括但不限于微处理器、专用集成电路(ASIC)、可编程门阵列(FPGA)、数字处理器(DSP)、嵌入式设备等。所述网络设备其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云;在此,云由基于云计算(CloudComputing)的大量计算机或网络服务器构成,其中,云计算是分布式计算的一种,由一群松散耦合的计算机集组成的一个虚拟超级计算机。所述网络包括但不限于互联网、广域网、城域网、局域网、VPN网络、无线自组织网络(AdHoc网络)等。优选地,设备1还可以是运行于所述用户设备、网络设备、或用户设备与网络设备、网络设备、触摸终端或网络设备与触摸终端通过网络相集成所构成的设备上的脚本程序。当然,本领域技术人员应能理解上述设备1仅为举例,其他现有的或今后可能出现的设备1如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
上述各装置之间是持续不断工作的,在此,本领域技术人员应理解“持续”是指上述各装置分别实时地或者按照设定的或实时调整的工作模式要求,例如所述第一装置11持续通过网关接收待传输的数据包;所述第二装置12持续将所述数据包从内核空间导入至用户空间;所述第三装置13持续检测处于用户空间的所述数据包是否待加解密处理;当所述数据包待加解密处理,所述第四装置14持续根据所述数据包的传输方向对所述数据包进行加解密处理;所述第五装置15通过所述网关传输经加解密处理后的所述数据包;直至所述第一装置11停止通过网关接收待传输的数据包。
所述第一装置11通过网关接收待传输的数据包。
在此,所述待传输的数据包包括从用户设备发送至服务器(即待传输至服务器)的数据包和从服务器发送至用户设备(即接收自服务器)的数据包,其中,所述网关起到中转站的作用。网关又称网间连接器、协议转换器。网关在网络层以上实现网络互连,既可以用于广域网互连,也可以用于局域网互连。网关是一种充当转换重任的计算机系统或设备(例如路由器),使用在不同的通信协议、数据格式或语言,甚至体系结构完全不同的两种系统之间,网关是一个翻译器。与网桥只是简单地传达信息不同,网关对收到的信息要重新打包,以适应目的系统的需求。
所述第二装置12将所述数据包从内核空间导入至用户空间。
在此,操作系统(例如Linux操作系统)的虚拟内存划分为内核空间与用户空间,运行在内核空间的核心软件拥有访问硬件设备的所有权限,具有较高的特权级别;运行在用户空间的普通应用程序只能看到允许它们使用的部分系统资源,并且不能使用某些特定的系统功能,也不能直接访问内核空间和硬件设备。
在具体的实施例中,可以通过iptables(IP信息包过滤系统及防火墙)中的NFQUEUE模块将所述数据包从内核空间导入至用户空间,然后对所述数据包进行后续处理。
所述第三装置13检测处于用户空间的所述数据包是否待加解密处理。
在此,并非所有的所述数据包都属于待加解密处理的数据包,经过检测后,对满足预设条件的所述数据包进行加解密处理,对于不满足预设条件的所述数据包可以不经过加解密处理而直接进行传输。
在具体的实施例中,所述数据包中包括其目的地址和源地址。可以根据所述数据包的目的地址或源地址,确定所述数据包是否待加解密处理。例如,判断所述数据包的目的地址是否属于待加解密处理的目的IP地址范围和/或判断所述数据包的源地址是否属于待加解密处理的源IP地址范围。
优选地,所述第三装置13根据处于用户空间的所述数据包所使用的传输协议,确定所述数据包是否待加解密处理。
例如,若所述数据包所使用的传输协议包括服务器信息块协议(SMB)、文件传输协议(FTP)和超文本传输协议(HTTP)中的至少任一种,则所述数据包待加解密处理。当然,也可以根据不同的需求相应地设置待加解密处理的所述数据包所使用的传输协议类型。本领域技术人员应能理解上述传输协议仅为举例,其他现有的或今后可能出现的传输协议如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
优选地,所述第三装置13根据处于用户空间的所述数据包的文件类型,确定所述数据包是否待加解密处理。
例如,可以根据用户自定义的文件类型,若所述数据包的文件类型属于用户自定义的需要进行加解密处理的文件类型,则所述数据包待加解密处理。
所述第四装置14当所述数据包待加解密处理,根据所述数据包的传输方向对所述数据包进行加解密处理。
在具体的实施例中,对所述数据包进行加解密处理包括:对于待加密处理的所述数据包,根据加密算法在原数据包中添加密钥,然后进行数据压缩,以保持加密前后数据包的大小不变;对于待解密处理的所述数据包,先对原数据包进行解压缩,然后根据所使用的加密算法进行解密处理。在一个优选的实施例中,所述加密算法可以是256位的RC4加密算法。在此,RC4加密算法是RonaldRivest在1987年设计的密钥长度可变的流加密算法簇。
当然,所述加密算法也可以是DES(DataEncryptionStandard,即数据加密标准,是一种使用密钥加密的块算法,在1976年被美国联邦政府的国家标准局确定为联邦资料处理标准)、3DES(或称TripleDES,相当于对每个数据块应用三次DES加密算法)、AES(AdvancedEncryptionStandard,即高级加密标准,是美国联邦政府采用的一种区块加密标准,被用来替代原先的DES加密算法)、RC5(RonaldL.Rivest教授在1994年设计的参数可变的分组密码算法)、Blowfish(一个64位分组及可变密钥长度的对称密钥分组密码算法,可用来加密64比特长度的字符串)等其他种类的加密算法。本领域技术人员应能理解上述加密算法仅为举例,其他现有的或今后可能出现的加密算法如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
具体地,所述根据所述数据包的传输方向对所述数据包进行加解密处理包括:若所述数据包为明文数据包且接收自服务器,对所述数据包进行加密处理;或者,若所述数据包为密文数据包且待传输至服务器,对所述数据包进行解密处理。
在此,对于接收自服务器的所述数据包,若该数据包为明文数据包,则进行加密处理,若该数据包已经是密文数据包,则无需进行加密处理;对于待传输至服务器的所述数据包,若该数据包为密文数据包,则进行解密处理,若该数据包是明文数据包,则无需进行解密处理。
具体地,所述第四装置14当所述数据包待加解密处理,根据所述数据包的目的地址或源地址确定所述数据包的传输方向;根据所述数据包的传输方向对所述数据包进行加解密处理。
在具体的实施例中,根据所述数据包的目的地址或源地址即可确定所述数据包的传输方向。例如,若所述数据包的目的地址为服务器,则该数据包的传输方向为从用户设备至服务器;若所述数据包的目的地址为用户设备,则该数据包的传输方向为从服务器至用户设备;若所述数据包的源地址为服务器,则该数据包的传输方向为从服务器至用户设备;若所述数据包的源地址为用户设备,则该数据包的传输方向为从用户设备至服务器。
优选地,所述根据所述数据包的目的地址或源地址确定所述数据包的传输方向包括:若所述数据包的目的地址属于服务器地址范围,确定所述数据包的传输方向为待传输至服务器;或者,若所述数据包的源地址属于服务器地址范围,确定所述数据包的传输方向为接收自服务器。
在此,所述服务器地址范围包括一个或多个服务器的IP地址。若所述数据包的目的地址属于服务器地址范围,则该数据包的传输方向为从用户设备至服务器,即待传输至服务器;若所述数据包的源地址属于服务器地址范围,则该数据包的传输方向为从服务器至用户设备,即接收自服务器。
所述第五装置15通过所述网关传输经加解密处理后的所述数据包。
在此,所述网关起到传输过程中的中转站的作用。对接收自服务器的数据包进行加密处理,对待传输至服务器数据包进行解密处理,那么对于符合预设条件(即待加解密处理)的所述数据包,其在网关与用户设备之间的传输过程中处于加密状态,并且以加密状态存储于用户设备,满足了传输安全的需求,保证了所述数据包在用户设备处的存储安全。
图3示出根据本申请另一个方面的一种用于数据传输的方法流程图。
该方法包括步骤S11、步骤S12、步骤S13、步骤S14和步骤S15。具体地,在步骤S11中,设备1通过网关接收待传输的数据包;在步骤S12中,设备1将所述数据包从内核空间导入至用户空间;在步骤S13中,设备1检测处于用户空间的所述数据包是否待加解密处理;在步骤S14中,设备1当所述数据包待加解密处理,根据所述数据包的传输方向对所述数据包进行加解密处理;在步骤S15中,设备1通过所述网关传输经加解密处理后的所述数据包。
在此,所述设备1包括但不限于用户设备、网络设备、或用户设备与网络设备通过网络相集成所构成的设备。所述用户设备其包括但不限于任何一种可与用户通过触摸板进行人机交互的移动电子产品,例如智能手机、平板电脑等,所述移动电子产品可以采用任意操作系统,如android(安卓)操作系统、iOS操作系统(苹果公司的移动操作系统)等。其中,所述网络设备包括一种能够按照事先设定或存储的指令,自动进行数值计算和信息处理的电子设备,其硬件包括但不限于微处理器、专用集成电路(ASIC)、可编程门阵列(FPGA)、数字处理器(DSP)、嵌入式设备等。所述网络设备其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云;在此,云由基于云计算(CloudComputing)的大量计算机或网络服务器构成,其中,云计算是分布式计算的一种,由一群松散耦合的计算机集组成的一个虚拟超级计算机。所述网络包括但不限于互联网、广域网、城域网、局域网、VPN网络、无线自组织网络(AdHoc网络)等。优选地,设备1还可以是运行于所述用户设备、网络设备、或用户设备与网络设备、网络设备、触摸终端或网络设备与触摸终端通过网络相集成所构成的设备上的脚本程序。当然,本领域技术人员应能理解上述设备1仅为举例,其他现有的或今后可能出现的设备1如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
设备1的各个步骤之间是持续不断工作的。具体地,在步骤S11中,设备1持续通过网关接收待传输的数据包;在步骤S12中,设备1持续将所述数据包从内核空间导入至用户空间;在步骤S13中,设备1持续检测处于用户空间的所述数据包是否待加解密处理;在步骤S14中,当所述数据包待加解密处理,设备1持续根据所述数据包的传输方向对所述数据包进行加解密处理;在步骤S15中,设备1通过所述网关传输经加解密处理后的所述数据包;直至步骤S11中设备1停止通过网关接收待传输的数据包。
在步骤S11中,设备1通过网关接收待传输的数据包。
在此,所述待传输的数据包包括从用户设备发送至服务器(即待传输至服务器)的数据包和从服务器发送至用户设备(即接收自服务器)的数据包,其中,所述网关起到中转站的作用。网关又称网间连接器、协议转换器。网关在网络层以上实现网络互连,既可以用于广域网互连,也可以用于局域网互连。网关是一种充当转换重任的计算机系统或设备(例如路由器),使用在不同的通信协议、数据格式或语言,甚至体系结构完全不同的两种系统之间,网关是一个翻译器。与网桥只是简单地传达信息不同,网关对收到的信息要重新打包,以适应目的系统的需求。
在步骤S12中,设备1将所述数据包从内核空间导入至用户空间。
在此,操作系统(例如Linux操作系统)的虚拟内存划分为内核空间与用户空间,运行在内核空间的核心软件拥有访问硬件设备的所有权限,具有较高的特权级别;运行在用户空间的普通应用程序只能看到允许它们使用的部分系统资源,并且不能使用某些特定的系统功能,也不能直接访问内核空间和硬件设备。
在具体的实施例中,可以通过iptables(IP信息包过滤系统及防火墙)中的NFQUEUE模块将所述数据包从内核空间导入至用户空间,然后对所述数据包进行后续处理。
在步骤S13中,设备1检测处于用户空间的所述数据包是否待加解密处理。
在此,并非所有的所述数据包都属于待加解密处理的数据包,经过检测后,对满足预设条件的所述数据包进行加解密处理,对于不满足预设条件的所述数据包可以不经过加解密处理而直接进行传输。
在具体的实施例中,所述数据包中包括其目的地址和源地址。可以根据所述数据包的目的地址或源地址,确定所述数据包是否待加解密处理。例如,判断所述数据包的目的地址是否属于待加解密处理的目的IP地址范围和/或判断所述数据包的源地址是否属于待加解密处理的源IP地址范围。
优选地,在步骤S13中,设备1根据处于用户空间的所述数据包所使用的传输协议,确定所述数据包是否待加解密处理。
例如,若所述数据包所使用的传输协议包括服务器信息块协议(SMB)、文件传输协议(FTP)和超文本传输协议(HTTP)中的至少任一种,则所述数据包待加解密处理。当然,也可以根据不同的需求相应地设置待加解密处理的所述数据包所使用的传输协议类型。本领域技术人员应能理解上述传输协议仅为举例,其他现有的或今后可能出现的传输协议如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
优选地,在步骤S13中,设备1根据处于用户空间的所述数据包的文件类型,确定所述数据包是否待加解密处理。
例如,可以根据用户自定义的文件类型,若所述数据包的文件类型属于用户自定义的需要进行加解密处理的文件类型,则所述数据包待加解密处理。
在步骤S14中,设备1当所述数据包待加解密处理,根据所述数据包的传输方向对所述数据包进行加解密处理。
在具体的实施例中,对所述数据包进行加解密处理包括:对于待加密处理的所述数据包,根据加密算法在原数据包中添加密钥,然后进行数据压缩,以保持加密前后数据包的大小不变;对于待解密处理的所述数据包,先对原数据包进行解压缩,然后根据所使用的加密算法进行解密处理。在一个优选的实施例中,所述加密算法可以是256位的RC4加密算法。在此,RC4加密算法是RonaldRivest在1987年设计的密钥长度可变的流加密算法簇。
当然,所述加密算法也可以是DES(DataEncryptionStandard,即数据加密标准,是一种使用密钥加密的块算法,在1976年被美国联邦政府的国家标准局确定为联邦资料处理标准)、3DES(或称TripleDES,相当于对每个数据块应用三次DES加密算法)、AES(AdvancedEncryptionStandard,即高级加密标准,是美国联邦政府采用的一种区块加密标准,被用来替代原先的DES加密算法)、RC5(RonaldL.Rivest教授在1994年设计的参数可变的分组密码算法)、Blowfish(一个64位分组及可变密钥长度的对称密钥分组密码算法,可用来加密64比特长度的字符串)等其他种类的加密算法。本领域技术人员应能理解上述加密算法仅为举例,其他现有的或今后可能出现的加密算法如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
具体地,所述根据所述数据包的传输方向对所述数据包进行加解密处理包括:若所述数据包为明文数据包且接收自服务器,对所述数据包进行加密处理;或者,若所述数据包为密文数据包且待传输至服务器,对所述数据包进行解密处理。
在此,对于接收自服务器的所述数据包,若该数据包为明文数据包,则进行加密处理,若该数据包已经是密文数据包,则无需进行加密处理;对于待传输至服务器的所述数据包,若该数据包为密文数据包,则进行解密处理,若该数据包是明文数据包,则无需进行解密处理。
具体地,在步骤S14中,设备1当所述数据包待加解密处理,根据所述数据包的目的地址或源地址确定所述数据包的传输方向;根据所述数据包的传输方向对所述数据包进行加解密处理。
在具体的实施例中,根据所述数据包的目的地址或源地址即可确定所述数据包的传输方向。例如,若所述数据包的目的地址为服务器,则该数据包的传输方向为从用户设备至服务器;若所述数据包的目的地址为用户设备,则该数据包的传输方向为从服务器至用户设备;若所述数据包的源地址为服务器,则该数据包的传输方向为从服务器至用户设备;若所述数据包的源地址为用户设备,则该数据包的传输方向为从用户设备至服务器。
优选地,所述根据所述数据包的目的地址或源地址确定所述数据包的传输方向包括:若所述数据包的目的地址属于服务器地址范围,确定所述数据包的传输方向为待传输至服务器;或者,若所述数据包的源地址属于服务器地址范围,确定所述数据包的传输方向为接收自服务器。
在此,所述服务器地址范围包括一个或多个服务器的IP地址。若所述数据包的目的地址属于服务器地址范围,则该数据包的传输方向为从用户设备至服务器,即待传输至服务器;若所述数据包的源地址属于服务器地址范围,则该数据包的传输方向为从服务器至用户设备,即接收自服务器。
在步骤S15中,设备1通过所述网关传输经加解密处理后的所述数据包。
在此,所述网关起到传输过程中的中转站的作用。对接收自服务器的数据包进行加密处理,对待传输至服务器数据包进行解密处理,那么对于符合预设条件(即待加解密处理)的所述数据包,其在网关与用户设备之间的传输过程中处于加密状态,并且以加密状态存储于用户设备,满足了传输安全的需求,保证了所述数据包在用户设备处的存储安全。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
需要注意的是,本申请可在软件和/或软件与硬件的组合体中被实施,例如,可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中,本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地,本申请的软件程序(包括相关的数据包结构)可以被存储到计算机可读记录介质中,例如,RAM存储器,磁或光驱动器或软磁盘及类似设备。另外,本申请的一些步骤或功能可采用硬件来实现,例如,作为与处理器配合从而执行各个步骤或功能的电路。
另外,本申请的一部分可被应用为计算机程序产品,例如计算机程序指令,当其被计算机执行时,通过该计算机的操作,可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令,可能被存储在固定的或可移动的记录介质中,和/或通过广播或其他信号承载媒体中的数据包流而被传输,和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此,根据本申请的一个实施例包括一个装置,该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器,其中,当该计算机程序指令被该处理器执行时,触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。
对于本领域技术人员而言,显然本申请不限于上述示范性实施例的细节,而且在不背离本申请的精神或基本特征的情况下,能够以其他的具体形式实现本申请。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本申请的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外,显然“包括”一词不排除其他单元或步骤,单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一,第二等词语用来表示名称,而并不表示任何特定的顺序。

Claims (12)

1.一种数据传输方法,其中,该方法包括:
a通过网关接收待传输的数据包;
b将所述数据包从内核空间导入至用户空间;
c检测处于用户空间的所述数据包是否待加解密处理;
d当所述数据包待加解密处理,根据所述数据包的传输方向对所述数据包进行加解密处理;
e通过所述网关传输经加解密处理后的所述数据包。
2.根据权利要求1所述的方法,其中,所述根据所述数据包的传输方向对所述数据包进行加解密处理包括:
若所述数据包为明文数据包且接收自服务器,对所述数据包进行加密处理;或者
若所述数据包为密文数据包且待传输至服务器,对所述数据包进行解密处理。
3.根据权利要求1或2所述的方法,其中,所述步骤d包括:
当所述数据包待加解密处理,根据所述数据包的目的地址或源地址确定所述数据包的传输方向;
根据所述数据包的传输方向对所述数据包进行加解密处理。
4.根据权利要求3所述的方法,其中,所述根据所述数据包的目的地址或源地址确定所述数据包的传输方向包括:
若所述数据包的目的地址属于服务器地址范围,确定所述数据包的传输方向为待传输至服务器;或者
若所述数据包的源地址属于服务器地址范围,确定所述数据包的传输方向为接收自服务器。
5.根据权利要求1至4中任一项所述的方法,其中,所述步骤c包括:
根据处于用户空间的所述数据包所使用的传输协议,确定所述数据包是否待加解密处理。
6.根据权利要求1至5中任一项所述的方法,其中,所述步骤c包括:
根据处于用户空间的所述数据包的文件类型,确定所述数据包是否待加解密处理。
7.一种数据传输设备,其中,该设备包括:
第一装置,用于通过网关接收待传输的数据包;
第二装置,用于将所述数据包从内核空间导入至用户空间;
第三装置,用于检测处于用户空间的所述数据包是否待加解密处理;
第四装置,用于当所述数据包待加解密处理,根据所述数据包的传输方向对所述数据包进行加解密处理;
第五装置,用于通过所述网关传输经加解密处理后的所述数据包。
8.根据权利要求7所述的设备,其中,所述根据所述数据包的传输方向对所述数据包进行加解密处理包括:
若所述数据包为明文数据包且接收自服务器,对所述数据包进行加密处理;或者
若所述数据包为密文数据包且待传输至服务器,对所述数据包进行解密处理。
9.根据权利要求7或8所述的设备,其中,所述第四装置用于:
当所述数据包待加解密处理,根据所述数据包的目的地址或源地址确定所述数据包的传输方向;
根据所述数据包的传输方向对所述数据包进行加解密处理。
10.根据权利要求9所述的设备,其中,所述根据所述数据包的目的地址或源地址确定所述数据包的传输方向包括:
若所述数据包的目的地址属于服务器地址范围,确定所述数据包的传输方向为待传输至服务器;或者
若所述数据包的源地址属于服务器地址范围,确定所述数据包的传输方向为接收自服务器。
11.根据权利要求7至10中任一项所述的设备,其中,所述第三装置用于:
根据处于用户空间的所述数据包所使用的传输协议,确定所述数据包是否待加解密处理。
12.根据权利要求7至11中任一项所述的设备,其中,所述第三装置用于:
根据处于用户空间的所述数据包的文件类型,确定所述数据包是否待加解密处理。
CN201510616052.6A 2015-09-24 2015-09-24 一种数据传输的方法与设备 Pending CN105162796A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510616052.6A CN105162796A (zh) 2015-09-24 2015-09-24 一种数据传输的方法与设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510616052.6A CN105162796A (zh) 2015-09-24 2015-09-24 一种数据传输的方法与设备

Publications (1)

Publication Number Publication Date
CN105162796A true CN105162796A (zh) 2015-12-16

Family

ID=54803550

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510616052.6A Pending CN105162796A (zh) 2015-09-24 2015-09-24 一种数据传输的方法与设备

Country Status (1)

Country Link
CN (1) CN105162796A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108173828A (zh) * 2017-12-22 2018-06-15 北京知道创宇信息技术有限公司 数据传输方法、装置及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101068229A (zh) * 2007-06-08 2007-11-07 北京工业大学 一种基于网络过滤器的内容过滤网关实现方法
CN101135980A (zh) * 2006-08-29 2008-03-05 飞塔信息科技(北京)有限公司 一种基于Linux操作系统实现零拷贝的装置和方法
CN202713365U (zh) * 2012-05-17 2013-01-30 杭州晟元芯片技术有限公司 一种对网络数据流硬件加密的系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101135980A (zh) * 2006-08-29 2008-03-05 飞塔信息科技(北京)有限公司 一种基于Linux操作系统实现零拷贝的装置和方法
CN101068229A (zh) * 2007-06-08 2007-11-07 北京工业大学 一种基于网络过滤器的内容过滤网关实现方法
CN202713365U (zh) * 2012-05-17 2013-01-30 杭州晟元芯片技术有限公司 一种对网络数据流硬件加密的系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108173828A (zh) * 2017-12-22 2018-06-15 北京知道创宇信息技术有限公司 数据传输方法、装置及存储介质
CN108173828B (zh) * 2017-12-22 2021-01-12 北京知道创宇信息技术股份有限公司 数据传输方法、装置及存储介质

Similar Documents

Publication Publication Date Title
US9838434B2 (en) Creating and managing a network security tag
CN106713320B (zh) 终端数据传输的方法和装置
CA2912608C (en) Selectively performing man in the middle decryption
US9781082B2 (en) Selectively performing man in the middle decryption
CN107666383B (zh) 基于https协议的报文处理方法以及装置
CA2909799C (en) Selectively performing man in the middle decryption
KR101982960B1 (ko) 불필요한 기능의 비활성화를 통한 가상화 애플리케이션 성능 개선
US11063917B2 (en) Communication network with rolling encryption keys and data exfiltration control
CN104662551A (zh) 在网络环境中对加密的数据的检查
KR101847636B1 (ko) 암호화 트래픽을 감시하기 위한 방법 및 장치
US10015208B2 (en) Single proxies in secure communication using service function chaining
US20240106811A1 (en) Systems and methods for network privacy
US20210218709A1 (en) Secure low-latency trapdoor proxy
CN105162796A (zh) 一种数据传输的方法与设备
Ajay et al. Packet encryption for securing real-time Mobile cloud applications
CN108809888B (zh) 一种基于安全模块的安全网络构建方法和系统
Mohamed et al. An authentication mechanism for accessing mobile web services
CN102857507A (zh) 磁盘映射方法及磁盘映射系统
Alhibshi Encryption algorithms for data security in Local Area Network
CN114268499A (zh) 数据传输方法、装置、系统、设备和存储介质
CN114978736A (zh) 基于负载均衡设备进行cookie加密的方法及装置

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20151216