CN109040059A - 受保护的tcp通信方法、通信装置及存储介质 - Google Patents
受保护的tcp通信方法、通信装置及存储介质 Download PDFInfo
- Publication number
- CN109040059A CN109040059A CN201810862167.7A CN201810862167A CN109040059A CN 109040059 A CN109040059 A CN 109040059A CN 201810862167 A CN201810862167 A CN 201810862167A CN 109040059 A CN109040059 A CN 109040059A
- Authority
- CN
- China
- Prior art keywords
- transmitting terminal
- receiving end
- fields
- sequence number
- response message
- 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/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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
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)
- Mobile Radio Communication Systems (AREA)
Abstract
本公开涉及受保护的TCP通信方法、通信装置及存储介质。在一个实施例中,该通信方法用于由发送端建立与接收端的安全连接,包括在发送端处:向接收端发送第一请求消息以请求在发送端和接收端之间建立连接,第一请求消息至少包括一个或多个字段;接收来自接收端的第一响应消息,其中第一响应消息包括针对第一请求消息的第一确认号,第一确认号已用所述一个或多个字段作为密钥被加密;用所述一个或多个字段作为密钥对第一确认号解密,以获得经解密的第一确认号;以及判断经解密的第一确认号是否与预期的确认号一致,并且如果一致,则与接收端建立安全连接。
Description
技术领域
本公开一般地涉及计算机网络通信,并具体地涉及受保护的传输控制协议(TCP)通信领域。
背景技术
计算机通信协议是指计算机通信网中两台计算机之间能够借以进行通信的规则集合,其决定了计算机是否能与其他计算机或路由通信链接或计算机是否能接入因特网中。在实际通信过程中,用户通过内置通信协议的操作***实现信息的通信,并将信息通过网络传输给用户或其他计算机。计算机通信的网络体系结构实际上是结构化功能分层和通信协议的集合。在计算机体系结构中,基于7层开放***互联(OSI)的参考模型用于异种计算机应用进程间的通信,其第四层,也就是传输层,是基于网络层协议将信息进行打包和传输的可识别网络层,为高低层间提供接口与服务,并在现行的通信网络体系模型中起核心关键作用。
而因特网同样使用分层协议体系结构,它执行TCP/IP协议栈,并定义任何可传输分组的通信***均可视为网络。如同OSI参考模型,基于硬件层次上执行TCP/IP协议栈的因特网自上而下分为应用层、传输层、IP层和网络接口层。其中传输层提供端到端应用进程之间的通信,该层的通信协议包括传输控制协议TCP。传输控制协议TCP提供可靠的信息流传输服务,关于TCP协议的介绍可参考文献“CERF V.,AND R.KAHN,《A Protocol for PacketNetwork Intercommunication》,IEEE Transactions on Communications,COM 22,no.5,5May 1974”和“POSTEL J.,《INTERNET PROTOCOL-DARPA INTERNET PROGRAM PROTOCOLS》,COMPUTER NETWORKS,VOL.2,NO.6,pp.454-473,DECEMBER 1978”。
由于通信过程的完成取决于通信协议所包含的一系列规则,一旦在任何地方任何所使用的通信协议发生改变,则其对应的传输服务结果也发生改变。例如,当模型第四层即传输层协议发生改变,其执行的功能不同于传统的TCP层,其提供一系列不同于传统传输的服务,因此也得到与使用传统TCP协议的传输层传输的完全不同的传输结果。
网络技术发展到现在已将近40年,其始于最开始网络产生之初建立的一系列数据通信的核心规则,即用于不同计算机之间进行相同通信的各类通信协议,例如TCP/IP通信协议。这类通信规则作为通信方式的核心规则已有将近40年,虽然这些规则是符合40年前那时人们希望实现的网络功能的。但当前世界的计算机与网络技术的发展已远远超过了40年前TPC协议刚开始发展时候的技术,另一方面,TCP/IP协议的设定之初本身就不是立足于安全,而是为了解决网络间的通信问题,因此基于TCP/IP协议的网络通信存在越来越多的危险和漏洞,例如网络的普及也导致大量的黑客(CRAKER)或信息侵入者的存在,利用通信协议的传输机制等网络漏洞截取或盗取用户隐私数据和通信数据等。关于TCP/IP协议的不足和缺陷可参考文献“《Security Problems in the TCP/IP Protocol Suite》,S.M.Bellovin,Computer Communication Review,Vol.19,No.2,PP.32-48,April 1989”。计算机网络和通信的安全性成为通信网络领域和用户最为关心的问题之一。因此与世界大环境的发展相对应,TCP传输控制协议也应当在数据安全和传输可靠性方面进行改进,以符合当前技术的发展。
现有技术中有些方案中使用IPSEC或SSL等加密方式,IPSEC加密是对第三层,即IP层数据进行加密,其生成公用的单独的密钥并随数据包传输,而SSL加密方式位于第五层,即应用层,必须经过特别的服务器才能通信,并且在诸多通信应用场景中存在限制。
为解决上述现有技术中的不足,本发明提供一种用于第四层,即传输层,的传输协议和加密通信的方法,用于对加密数据的安全传输和执行数据接收方授权的可靠步骤。
发明内容
本公开的一个方面涉及一种受保护的传输控制协议(TCP)通信方法,所述方法用于由发送端建立与接收端的安全连接,包括在发送端处:向接收端发送第一请求消息以请求在发送端和接收端之间建立连接,第一请求消息至少包括一个或多个字段;接收来自接收端的第一响应消息,其中第一响应消息包括针对第一请求消息的第一ACK确认号,第一ACK确认号已用所述一个或多个字段作为密钥被加密;用所述一个或多个字段作为密钥对第一ACK确认号解密,以获得经解密的第一ACK确认号;以及判断经解密的第一ACK确认号是否与预期的ACK确认号一致,并且如果一致,则与接收端建立安全连接。
本公开的另一个方面涉及一种受保护的传输控制协议(TCP)通信方法,所述方法用于由接收端响应于发送端的请求而建立安全连接,包括在接收端处:接收来自发送端的第一请求消息,并获得第一请求消息中的一个或多个字段,其中所述第一请求消息用于请求在发送端和接收端之间建立连接;以及用所述一个或多个字段作为密钥对第一响应消息中的针对第一请求消息的第一ACK确认号加密,并向发送端发送第一响应消息。
本公开的另一个方面涉及一种通信装置,包括处理器计算机可读介质。计算机可读介质与处理器耦接并且包括处理器可执行的指令。指令在由处理器执行时使处理器执行根据本公开的各种方法。本公开的又一个方面可以涉及这种计算机可读存储介质。
提供上述方案概述仅为了提供对本文所描述的主题的各方面的基本理解。因此,上述方案中的技术特征仅是示例并且不应被解释为以任何方式限制本文所描述的主题的范围或精神。本文所描述的主题的其他特征、方面和优点将从以下结合附图描述的具体实施方式而变得明晰。
附图说明
当结合附图考虑实施例的以下具体描述时,可以获得对本公开内容更好的理解。其中:
图1为基于实施例的协议建立网络连接的示意图。
图2为基于实施例的建立多个网络连接的示意图。
图3为基于实施例的传输层协议的通信示意图。
图4为基于实施例的通信***的存储结构图。
图5为基于实施例的TCP数据报头格式。
图6为基于实施例的用于建立同步连接的示例处理。
图7为基于实施例的用于建立同步连接的另一示例处理。
图8A至图8D为基于实施例的图7中各数据包的TCP报头中的一些字段的示例取值。
图9A为基于实施例的用于发送端的示例通信方法。
图9B为基于实施例的用于接收端的示例通信方法。
图10为基于实施例的用作发送端和/或接收端的示例性通信装置。
具体实施方式
本发明提供了一种受保护的传输控制协议以及基于该协议的安全通信***,以及相关的装置和方法。在本文中,该受保护的传输控制协议有时也可以称为L4SOS(Layer 4Secure Operating System)。L4SOS运行在OSI模型第四层,即传输层,代替现有TCP协议并与IP网络协议连接实现数据传输和网络连接。为基于本发明提供的传输通信协议来建立两个网络节点之间的网络连接,需要至少两台计算机和一个网络路由,如图1所示,路由本身并不会关注所接收的消息是来自L4SOS协议还是来自TCP协议,其仅仅专注于将接收的数据传输至特定的接收地址处,该地址被预先存储在接口地址结构中。而L4SOS和TCP这两种通信协议能发现消息来源的不同,并且只有运行有L4SOS协议的***能获取到解密L4SOS数据包的必要工具和密钥,并因此实现解密,而基于TCP协议的***即使接收到L4SOS数据包也不能对其进行解码和破解。在这种情况下,接收方计算机***的会话层、表示层、应用层也都不能获取到数据包的内容。除此之外,L4SOS还包括另外的认证传输协议,并基于此对接收方认证是否为用于进行解密和操作的目标接收方。
L4SOS是一个提供中央操作平台的安全传输控制通信协议,并能基于该协议以及对应的通信***涉及和构建一系列通信网络。如图2所示,主要有三个通过运行L4SOS协议的通信***构建的网络A、B、C,每一个主要的网络能相互之间组成内部网络AB、AB、BC、ABC,这些网络之间最大的区别决定于是否能传输和接收L4SOS数据包。例如,位于主要网络C(或者是网络A、B、C、AB、AB、BC、ABC或其他网络)中的主机上运行有基于L4SOS协议的通信***,并基于该通信***进行传输和接收L4SOS数据包。L4SOS也可以在高安全等级的设定条件下,在传输加密操作之前对发送方进行认证,因此该选项的提供可以避免许多不必要的网络攻击。而基于网络层的IP数据包是可以传输到任意网关并到达任意接收方的目的地址处。
此外对于运行有L4SOS协议的接收端,还可以允许有来自不安全传输的接收的选型,从而该接收方还可以通过IP网络接收到基于现有传输协议的TCP协议数据包。
术语解释
网络(INTERNET):又称因特网或互联网,包括由广域网、城域网、局域网等网络及计算机、计算机终端、客户端、服务端等按照一定的通讯协议组成用于数据包交换的计算机网络。
协议(PROTOCOL):通信协议是指双方实体完成通信或服务所必须遵循的规则和约定。协议定义了数据单元使用的格式,信息单元应该包含的信息与含义,连接方式,信息发送和接收的时序,从而确保网络中数据顺利地传送到确定的地方。在计算机通信中,通信协议用于实现计算机与网络连接之间的标准,网络如果没有统一的通信协议,电脑之间的信息传递就无法识别。通信协议是指通信各方事前约定的通信规则,可以简单地理解为各计算机之间进行相互会话所使用的共同语言。两台计算机在进行通信时,必须使用的通信协议。
数据包(PACKET):在包交换网络里,单个消息被划分为多个数据块,这些数据块称为包,它包含发送者和接收者的地址信息。这些包然后沿着不同的路径在一个或多个网络中传输,并且在目的地重新组合。
主机(HOST):在互联网协议中,host表示能够同其他机器互相访问的本地计算机。一台本地机有唯一标志代码,同网络掩码一起组成IP地址,如果通过点到点协议通过ISP访问互联网,那么在连接期间将会拥有唯一的IP地址,这段时间内,你的主机就是一个host。在这种情况下,host表示一个网络节点。host是根据TCP/IP for Windows的标准来工作的,它的作用是包含IP地址和Host name(主机名)的映射关系,是一个映射IP地址和Host name(主机名)的规定,规定要求每段只能包括一个映射关系,IP地址要放在每段的最前面,空格后再写上映射的Host name主机名。
进程(PROCESS):进程是一个具有独立功能的程序关于某个数据集合的一次运行活动。它可以申请和拥有***资源,是一个动态的概念,是一个活动的实体。它不只是程序的代码,还包括当前的活动,通过程序计数器的值和处理寄存器的内容来表示。
接口(SOCKET):网络上的两个程序通过一个双向的通信连接实现数据的交换,这个连接的一端称为一个接口。
基于L4SOS协议的操作***模型概述
主机的进程通过传输作为参数的缓存数据从而将数据传输至已建立好的与L4SOS连接的接口地址。L4SOS认证的功能是通过***登陆证书、用户名、密码以及相对应的进程实现的。所述进程用于接收缓存数据,进而基于空间的加密方式将所有接收的缓存数据进行加密,加密后得到用于通信传输的片段,并生成规定格式的数据包。之后通过网络层将数据片段发送给接收方的L4SOS***进行接收,接收方获取发送方的传输数据块并解码数据块,从而获取发送方想要传输的信息,参考图3中的传输通信过程。
实质上,L4SOS可以被认为是一个与通用计算机操作***进行辅助的操作***,参考图4,并且都在主机上运行;进一步的,在安装的过程中还将存储介质分为两部分并划分出第二存储介质,用于在通用计算机操作***之上提供进一步的安全保障。计算机应用由计算机操作***内核进程执行,并基于内部处理通信装置连接到L4SOSO***。这种设计能通过仅允许给予计算机授权用户使用IPC接口认证来增强网络的安全性。所述认证是由L4SOS管理,以及基于安全许可来连接到通用计算机操作***的用户认证数据结构来管理其安全性和传输认证。
而对应于基于L4SOS的通信控制传输协议的进一步应用,是提供了一种安全传输的网络连接,既能够向一个国家提供安全的构建网络的环境,也可以给商业团队提供保护其商业秘密的网络环境。
基于L4SOS协议的操作***模型的扩展实施例可至少包括以下几部分:
(1)受保护的传输层控制协议,该协议可替换传统的TCP协议并用于通信传输;
(2)基于受保护的传输控制协议的网络连接模型;
(3)对应的计算机主机装置及其操作***模型;
(4)受保护的传输控制协议之间的连接接口;
(5)由受保护的传输层控制协议规定的信息加密和解密方式。
如图5为传统TCP协议定义的数据包格式,其中包括传统“序列号”、“确认号”和“数据”等字段。TCP协议需要按照规定的这个格式生成相应的TCP数据包,包括需要设定序列号和确认号,也是与基于TCP协议的通信中的三次握手机制相配合的设定。而本发明提供的受保护的传输控制协议对数据包的格式做了新的规定:首先设定源端口号和目的端口号,然后将加密密文的片段从“序列”开始填充,并依次填充“确认号”和“数据”,对于每一个数据包头格式其长度为32位,因此每一个密文片段的长度也为32位,并且每一个数据片段的末尾3个字节是下一个数据片段的头3个字节;“数据”段中存储空间为固定的,基于此可以计算出对于待传输的密文需要的数据包数量。而“数据”段还需要同时存储加密密文的片段和伪明文的序列片段,因此填入“数据”空间的密文数据片段在最后一个数据片段的末尾需要加上用于判断结束的验证序列,在一个实施例中该验证序列为“000”。该验证序列即标志着密文数据的填充结束以及伪装明文开始填充到剩余的数据空间中,并且下一个数据包也重复同样的数据加载方法。
本公开的一些实施例涉及受保护的传输控制协议(TCP)通信方法以及相应的通信收发装置,如下文具体描述的。仍然参考图5,在传统的TCP报头(header)中,包括源端口号、目的端口号、序列号(包括初始序列号)、确认号以及控制比特等重要字段。例如,源端口号和目的端口号均可以用16个比特表示相应的端口号。在TCP数据包是用于同步SYN目的的情况下,在目的端口号之后的32个比特表示初始序列号(ISN);在其他情况下,在目的端口号之后的32个比特一般表示序列号(SN),即数据段中的第一元组数据(例如data octet)的序列号。接下来的32个比特是ACK控制比特,也即ACK确认号。该字段的取值表示发送包含该字段的TCP数据包的发送方预期接收到的下一个数据包的序列号。控制比特包含6个比特,每个比特具有特定的控制含义。例如,TCP数据包是用于建立同步的情况下,SYN比特(左起第5个比特)可以被设置为真,否则被设置为假。在TCP数据包包含ACK确认号时,ACK比特(左起第2个比特)可以被设置为真,否则被设置为假。如已知的,在发送端与接收端之间进行数据包收发之前,需要在这两者之间建立同步的连接。同步的一个目的是使发送端与接收端彼此知晓序列号,以便能够从TCP数据包中正确地恢复原始数据。TCP报头中的这些字段可以便于在发送端与接收端之间建立同步连接。
图6示出了基于本公开实施例的用于建立同步连接的示例处理。如图6所示,在1002处,发送端向接收端发送第一请求消息(即TCP数据包)。其中,TCP报头的控制比特中的SYN比特为真表示该消息是用于在发送端和接收端之间建立同步连接的。此时,序列号应理解为发送端的初始序列号,并且在图6中表示为SEQ=100。
接着,接收端接收到1002中的第一请求消息并对其进行响应。具体地,接收端可以通过SYN比特知晓该第一请求消息是用于建立同步连接的,并获得初始序列号SEQ=100。在1004处,接收端可以向发送端发送第一响应消息,作为对第一请求消息的响应。如图6所示,在第一响应消息中,TCP报头的控制比特中的SYN比特和ACK比特均为真,这表示该第一响应消息是用于在发送端和接收端之间建立同步连接的,并且该第一响应消息中包含ACK确认号。在该示例中,接收端的序列号SEQ=300,确认号为ACK=101。确认号为101表示第一响应消息是对来自发送端的序列号为100的数据包(即101的前一个)的确认,并且接收端预期接收的来自该发送端的下一个数据包的序列号应为SEQ=101。
接着,发送端接收到1004中的第一响应消息并对其进行响应。具体地,发送端可以通过SYN比特知晓该消息也是用于建立同步连接的,并获得接收端的序列号SEQ=300。至此,发送端和接收端都知晓了有关对方的序列号的信息,具备了在两者之间建立同步连接的条件。而且,发送端可以通过ACK比特知晓该消息包含确认号,并获得第一响应消息中的确认号为101,这与发送端本应要发送的数据包的序列号(即100的下一个)是一致的。因此,发送端可以判断该接收端确实是自己要与之建立同步连接的通信实体。在1006处,发送端可以通过向接收端发送第二响应消息以作为对第一响应消息的响应,从而推进同步连接的建立过程。如图6所示,在第二响应消息中,发送端的序列号被设置为101,TCP报头的控制比特中的ACK比特为真,表示该第二响应消息中包含ACK确认号,并且确认号为ACK=301。确认号为301表示第二响应消息是对来自接收端的序列号为300的数据包(即301的前一个)的确认,并且发送端预期接收的来自该接收端的下一个数据包的序列号应为301。
当接收端接收到第二响应消息时,可以完成同步连接的建立过程。在该示例中,接收端可以通过第二响应消息中的ACK比特知晓该消息包含确认号,并获得第二响应消息中的确认号为ACK=301,这与接收端本应要发送的数据包的序列号(即300的下一个)是一致的。因此,接收端可以判断该发送端确实是要与自己建立同步连接的通信实体。至此,发送端和接收端都将对方视为要与之建立同步连接的通信实体,并且彼此都知晓有关对方的序列号的信息,从而完成了同步连接的建立过程。接下来,如1008处所示,发送端可以向接收端发送包含数据内容的消息。
在一些实施例中,为了提高发送端和接收端之间的通信安全性,可以对它们之间的通信进行加密处理。例如,可以对发送端和接收端之间的数据传输进行加密处理。又例如,可以对收发两端之间的同步连接建立过程进行加密处理。由于同步连接建立是收发两端进行数据传输的初始过程,保证该过程的安全性因此具有更重要的意义。在本公开的一些实施例中,通过加密可以保证同步连接建立的信息不被窃取,从而确保在真正的收发双方(即任一方不会被第三方冒充)之间建立安全的同步连接。
图7示出了基于本公开实施例的用于建立同步连接的另一示例处理。在该示例中,可以在收发两端之间建立更安全的同步连接。如图7所示,在1102处,发送端向接收端发送第一请求消息(即TCP数据包)。其中,TCP报头的控制比特中的SYN比特为真表示该消息是用于在发送端和接收端之间建立同步连接的,并且发送端的初始序列号为SEQ=100。
接着,接收端接收到1102中的第一请求消息并对其进行响应。具体地,接收端可以通过SYN比特知晓该第一请求消息是用于建立同步连接的,并获得初始序列号。在1104处,接收端可以向发送端发送第一响应消息,作为对第一请求消息的响应。如图7所示,在第一响应消息中,TCP报头的控制比特中的SYN比特和ACK比特都为真,这表示该第一响应消息是用于在发送端和接收端之间建立同步连接的,并且该第一响应消息中包含ACK确认号。在该示例中,接收端的序列号为SEQ=300,确认号的实际值为ACK=101(确认号为101表示第一响应消息是对来自发送端的序列号为100的数据包(即101的前一个)的确认,并且接收端预期接收的来自该发送端的下一个数据包的序列号应为101)。在本公开的实施例中,确认号101可以用来自第一请求消息的一个或多个字段作为密钥被加密为ACK1。这一个或多个字段例如是初始序列号和源端口号(以及任何的其他字段)中的一者或多者。
在一个实施例中,这一个或多个字段可以是协议(例如类似TCP的协议)规定的用作密钥的字段。这些字段可以是强制的,根据该协议操作的通信装置必须使用这些字段作为密钥;或者这些字段可以是任意性的,根据该协议操作的通信装置可以在这些字段中协商选择作为密钥的字段。附加地或者另选地,收发两端可以在协议的规定之外任意协商一个或多个字段,以便在一定的时间段内作为密钥使用。这样,由于发送端已经知晓用作密钥的字段,因此在接收到第一响应消息时可以从ACK1中解密出确认号的实际值101。
接着,发送端接收到1104中的第一响应消息并对其进行响应。具体地,发送端可以通过SYN比特知晓该消息也是用于建立同步连接的,并获得接收端的序列号SEQ=300。而且,发送端可以通过ACK比特知晓该消息包含确认号,并通过相应的密钥从ACK1中获得第一响应消息中的实际确认号为101,这与发送端本应要发送的数据包的序列号(即100的下一个)是一致的。因此,发送端可以判断该接收端确实是自己要与之建立同步连接的通信实体。相反,对于冒充此处的接收端的任何其他设备,其可能仅知晓通过使确认号等于101来伪装该接收端,但不知晓需要对确认号进行加密(和/或不知晓密钥)。这样,发送端在对确认号101解密后获得的值与预期的确认号并不一致,从而可以判断相应设备为冒充设备。这样,在1106处,发送端可以向接收端发送第二响应消息以作为对第一响应消息的响应,从而推进同步连接的建立过程。如图7所示,在第二响应消息中,发送端的序列号被设置为101,TCP报头的控制比特中的ACK比特为真,表示该第二响应消息中包含ACK确认号,并且确认号的实际值为301(确认号的实际值为301表示第二响应消息是对来自接收端的序列号为300的数据包(即301的前一个)的确认,并且发送端预期接收的来自该接收端的下一个数据包的序列号应为301)。在本公开的实施例中,确认号301用与1104处的密钥相同的密钥被加密为ACK2。
当接收端接收到第二响应消息时,可以完成同步连接的建立过程。在该示例中,接收端可以通过第二响应消息中的ACK比特知晓该消息包含确认号,并用与1104处的密钥相同的密钥从ACK2中获得第二响应消息中的确认号的实际值为301,这与接收端本应要发送的数据包的序列号(即300的下一个)是一致的。因此,接收端可以判断该发送端确实是要与自己建立同步连接的通信实体。与1104处同样的原理,接收端也可以识别伪装设备。至此,发送端和接收端都将对方视为要与之建立同步连接的通信实体,并且彼此都知晓有关对方的序列号的信息,从而完成了同步连接的建立过程。接下来,如1108处所示,发送端可以向接收端发送包含数据内容的消息。在1108以及之后的通信中,收发双方的数据包中的确认号字段都可以用类似的方法进行加密,从而也提高数据通信过程中的安全性。
在图7的示例中,可以防止不知晓对确认号进行加解密的密钥的第三方(例如,由于其运行不同的通信协议,或者没有进行过密钥协商等)与发送端或接收端建立同步连接。例如,如果该第三方要冒充接收端以与发送端建立同步连接,那么在接收到第一请求消息之后,该第三方不知晓要对第一响应消息中的确认号进行加密或者不知晓密钥。因此,发送端在接收到第一响应消息之后,可以判断解密出的确认号与预期的不一致,并相应地不对该第三方进行响应。又例如,如果该第三方要冒充发送端以与接收端建立同步连接,那么一方面,在接收到第一响应消息之后,该第三方不知晓要对第一响应消息中的确认号进行解密或者不知晓密钥,也就无法获得第一响应消息中的确认号。另一方面,该第三方也不知晓要对第二响应消息中的确认号进行加密或者不知晓密钥。因此,接收端在接收到第二响应消息之后,可以判断解密出的确认号与预期的不一致,并相应地不对该第三方进行响应。可见,在任一情况下,发送端与接收端之间的同步建立过程都会更安全。
图8A至图8D示出了基于本公开实施例的同步建立过程中数据包的TCP报头中的一些字段的示例取值。图8A示出了以第一请求消息中的初始序列号作为密钥、各ACK确认号为加密对象的示例情况。如图8A所示,在由发送端发送给接收端的第一请求消息中,源端口号为“01”,目的端口号为“05”,初始序列号为“100”。初始序列号“100”为密钥。在由接收端发送给发送端的第一响应消息中,源端口号为“05”,目的端口号为“01”,序列号“300”,确认号的实际值“101”用“100”作为密钥被加密。在由发送端发送给接收端的第二响应消息中,源端口号为“01”,目的端口号为“05”,序列号“101”,确认号的实际值“301”用“100”作为密钥被加密。
除了使用初始序列号作为加密密钥之外,在本公开的实施例中,还可以使用第一请求消息中的任何其他的一个或多个字段作为加密密钥,从而增强操作的灵活性和安全性。图8B示出了以第一请求消息中的初始序列号和源端口号作为密钥、各ACK确认号为加密对象的示例情况。如图8B所示,在由发送端发送给接收端的第一请求消息中,源端口号为“01”,目的端口号为“05”,初始序列号为“100”。初始序列号“100”和源端口号“01”为密钥。在由接收端发送给发送端的第一响应消息中,源端口号为“05”,目的端口号为“01”,序列号“300”,确认号的实际值“101”用“100”和“01”作为密钥被加密。在由发送端发送给接收端的第二响应消息中,源端口号为“01”,目的端口号为“05”,序列号“101”,确认号的实际值“301”用“100”和“01”作为密钥被加密。
除了对数据包中的确认号字段进行加密之外,在本公开的实施例中,还可以对数据包中的任何其他的一个或多个字段进行加密,从而增强操作的灵活性和安全性。图8C示出了以第一请求消息中的初始序列号作为密钥、各ACK确认号、源端口号和序列号均为加密对象的示例情况。如图8C所示,在由发送端发送给接收端的第一请求消息中,源端口号为“01”,目的端口号为“05”,初始序列号为“100”。初始序列号“100”为密钥。在由接收端发送给发送端的第一响应消息中,实际的源端口号为“05”、序列号“300”和确认号“101”均用“100”作为密钥被加密,目的端口号为“01”。在由发送端发送给接收端的第二响应消息中,实际的源端口号为“01”、序列号“101”和确认号“301”均用“100”作为密钥被加密,目的端口号为“05”。
图8D示出了以第一请求消息中的初始序列号和源端口号作为密钥,ACK确认号、源端口号和序列号均为加密对象的示例情况。可以参照图8B和图8C类似地理解图8D中的示例。
需说明的是,用作密钥的字段不限于初始序列号和源端口号字段,其可以是TCP报头中的其他适当的字段。本公开实施例中可以采用任何适当的加密算法(例如AES),即在具体加密处理方面可以不受限制。在一些实例中,在有多个字段作为密钥的情况下,可以在密钥之间进行加密。例如,发送端可以用一个字段(如初始序列号)对另一个字段(如源端口号)进行加密,从而进一步增强安全性。相应地,接收端可以通过相反的操作恢复出用作密钥的各字段。
图9A示出了基于本公开实施例的用于发送端的示例通信方法。该方法可以例如用于由发送端建立与接收端的安全TCP连接。具体地,在1302处,发送端可以向接收端发送第一请求消息以请求在发送端和接收端之间建立连接,第一请求消息至少包括一个或多个字段。在1304处,发送端可以接收来自接收端的第一响应消息。其中,第一响应消息包括针对第一请求消息的第一ACK确认号,第一ACK确认号已用所述一个或多个字段作为密钥被加密。在1306处,发送端可以用所述一个或多个字段作为密钥对第一ACK确认号解密,以获得经解密的第一ACK确认号。在1308处,发送端可以判断经解密的第一ACK确认号是否与预期的ACK确认号一致,并且如果一致,则与接收端建立安全连接。
在一个实施例中,发送端还可以向接收端发送第二响应消息,其中第二响应消息包括针对第一响应消息的第二ACK确认号,第二ACK确认号用所述一个或多个字段作为密钥被加密。
在一个实施例中,所述一个或多个字段包括发送端的初始序列号和源端口号中的至少一者。
在一个实施例中,在第一请求消息中,初始序列号用源端口号作为密钥被加密,或者源端口号用初始序列号作为密钥被加密。
在一个实施例中,第一响应消息还包括接收端的初始序列号和源端口号,并且接收端的初始序列号和源端口号中的至少一者也用所述一个或多个字段作为密钥而被加密。该方法还可以包括用所述一个或多个字段作为密钥对接收端的初始序列号和源端口号中的所述至少一者解密,以获得经解密的接收端的初始序列号和源端口号中的所述至少一者。
在一个实施例中,第二响应消息还包括发送端的序列号和源端口号。所述方法还可以包括用所述一个或多个字段作为密钥对发送端的序列号和源端口号中的至少一者加密。
图9B示出了基于本公开实施例的用于接收端的示例通信方法。该方法可以例如用于由接收端响应于发送端的请求而建立安全TCP连接。具体地,在1352处,接收端可以接收来自发送端的第一请求消息,并获得第一请求消息中的一个或多个字段,其中所述第一请求消息用于请求在发送端和接收端之间建立连接。在1354处,用所述一个或多个字段作为密钥对第一响应消息中的针对第一请求消息的第一ACK确认号加密,并向发送端发送第一响应消息。
在一个实施例中,接收端还可以接收来自发送端的第二响应消息,并用所述一个或多个字段作为密钥对第二响应消息中的针对第一响应消息的第二ACK确认号解密,以获得经解密的第二ACK确认号。而且,接收端还可以判断经解密的第二ACK确认号是否与预期的ACK确认号一致,并且如果一致,则与发送端建立安全连接。
在一个实施例中,所述一个或多个字段包括发送端的初始序列号和源端口号中的至少一者。
在一个实施例中,可以用源端口号作为密钥对初始序列号解密,或者用初始序列号作为密钥对源端口号解密。
在一个实施例中,第一响应消息还包括接收端的初始序列号和源端口号,所述方法还包括用所述一个或多个字段作为密钥而对接收端的初始序列号和源端口号中的至少一者加密。
在一个实施例中,第二响应消息还包括发送端的序列号和源端口号,并且发送端的序列号和源端口号中的至少一者也用所述一个或多个字段作为密钥而被加密,所述方法还包括用所述一个或多个字段作为密钥对发送端的初始序列号和源端口号解密中的所述至少一者,以获得经解密的发送端的初始序列号和源端口号中的所述至少一者。
如前所述,可以对发送端和接收端之间的数据传输进行加密处理,从而提高发送端和接收端之间的通信安全性。例如,在发送端和接收端建立了同步连接之后,在它们之间发送的数据一般可以存储在缓冲区中。在一些实施例中,可以对缓冲区中的数据作为整体进行加密,从而可以进一步提升数据安全。在一个实施例中,另选或附加地,本公开的通信方法可以包括用另一密钥对用于发送端的数据缓冲区进行加密,并且将所述另一密钥发送给接收端(例如通过第一请求消息,例如在第一请求消息的数据字段中)。相应地,接收端可以例如从第一请求消息的数据字段中获得该另一密钥。在接收端接收到与发送端的缓冲区对应的数据之后,可以用该另一密钥对这些数据解密以恢复出实际数据。
图10是基于本公开实施例的用作发送端和/或接收端的示例性通信装置。通信装置1400可以是或可以包括可通过网络进行通信的任何设备,诸如个人计算机(PC)、电话、蜂窝电话、个人数字助理(PDA)、平板设备、笔记本设备、智能电话、智能电视、语音助理设备等。在一些实施例中,通信装置1400可以包括存储设备1402、处理器1404、收发器1406、I/O接口1408和子处理模块1410。在其他实施例中,通信装置1400可以包括执行功能所必需的附加组件。如图10所示,通信装置1400的各种部件可以通过总线以任何适当的方式互连。
存储设备1402可以是各种类型的存储器或存储设备中的任何一种。例如,存储设备1402可以包括安装介质(例如CD-ROM、软盘或磁带设备)、随机存取存储器(诸如DRAM、DDRRAM、SRAM、EDO RAM、Rambus RAM等)、非易失性存储器(诸如闪存、磁介质或光学存储装置)、寄存器或其他类似类型的存储器元件等。存储设备1402还可以包括其他类型的存储器或其组合。在本公开的实施例中,存储设备1402可以存储程序指令(例如用于执行相应操作的指令),以便以软件、硬件或软件硬件相结合的方式来实现基于本公开实施例的方法。
处理器1404可以是诸如微处理器、数字信号处理器、微控制器、多核处理器、专用处理器、用于网络通信的接口等的任何处理器。处理器1404可以运行存储设备1402中所存储的各种程序指令,以执行相应的操作。
收发器1406可以是可用于发送和接收数据流的任何部件。收发器1406可以便于通信装置1400与其他装置进行通信。在本公开的实施例中,收发器1406可以根据任何适当的有线和/或无线通信协议进行消息和数据包的收发。
I/O接口1408可以是可向通信装置1400输入信息和/或可从通信装置1400输出信息的任何部件。I/O接口1408可以包括例如键盘、小键盘、触摸接口、有线接口(例如USB接口)等等。
子处理模块1410可以用于执行基于本公开实施例中的与三次握手机制相关的操作,如参考图7至图9B所描述的一些或全部。子处理模块1410可以实现为专用或通用的软件或硬件模块。在图10中,虽然子处理模块1410被示为处理器1404的一部分,但是在其他实施例中,子处理模块1410可以单独实现为一个或多个实体,如集成电路(IC)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)以及它们的任意组合等。在一个实施例中,本发明还提供用于实现该通信方法的通信程序,其位于存储介质中并通过在计算机上运行实现所述通信方法的相应功能。
本说明书中公开的所有特征,或公开的所有方法或过程中的步骤,除了互相排斥的特征和/或步骤以外,均可以以任何方式组合。
本说明书(包括任何附加权利要求、摘要)中公开的任一特征,除非特别叙述,均可被其他等效或具有类似目的的替代特征加以替换。即,除非特别叙述,每个特征只是一系列等效或类似特征中的一个例子而已。
本发明并不局限于前述的具体实施方式。本发明扩展到任何在本说明书中披露的新特征或任何新的组合,以及披露的任一新的方法或过程的步骤或任何新的组合。本公开旨在获得权利,该权利应当包括在允许范围内的替代实施例、配置或方面,包括与所要求保护的那些结构、功能、范围或步骤的替代的、可互换的和/或等效的结构、功能、范围或步骤,无论这些替代的、可互换的和/或等效的结构、功能、范围或步骤是否在本文中具体说明。本文不旨在公开地贡献任何可取得专利的技术方案。
Claims (17)
1.一种受保护的传输控制协议(TCP)通信方法,所述方法用于由发送端建立与接收端的安全连接,包括在发送端处:
向接收端发送第一请求消息以请求在发送端和接收端之间建立连接,第一请求消息至少包括一个或多个字段;
接收来自接收端的第一响应消息,其中第一响应消息包括针对第一请求消息的第一确认号,第一确认号已用所述一个或多个字段作为密钥被加密;
用所述一个或多个字段作为密钥对第一确认号解密,以获得经解密的第一确认号;以及
判断经解密的第一确认号是否与预期的确认号一致,并且如果一致,则与接收端建立安全连接。
2.如权利要求1所述的通信方法,还包括:
向接收端发送第二响应消息,其中第二响应消息包括针对第一响应消息的第二确认号,第二确认号用所述一个或多个字段作为密钥被加密。
3.如权利要求2所述的通信方法,其中,所述一个或多个字段包括发送端的初始序列号和源端口号中的至少一者。
4.如权利要求3所述的通信方法,其中,在第一请求消息中,初始序列号用源端口号作为密钥被加密,或者源端口号用初始序列号作为密钥被加密。
5.如权利要求1所述的通信方法,其中,第一响应消息还包括接收端的初始序列号和源端口号,并且接收端的初始序列号和源端口号中的至少一者也用所述一个或多个字段作为密钥而被加密,所述方法还包括:
用所述一个或多个字段作为密钥对接收端的初始序列号和源端口号中的所述至少一者解密,以获得经解密的接收端的初始序列号和源端口号中的所述至少一者。
6.如权利要求2所述的通信方法,其中,第二响应消息还包括发送端的序列号和源端口号,所述方法还包括用所述一个或多个字段作为密钥对发送端的序列号和源端口号中的至少一者加密。
7.如权利要求1至6中任一项所述的通信方法,还包括用另一密钥对用于发送端的数据缓冲区加密,并且将所述另一密钥通过第一请求消息发送给接收端。
8.一种受保护的传输控制协议(TCP)通信方法,所述方法用于由接收端响应于发送端的请求而建立安全连接,包括在接收端处:
接收来自发送端的第一请求消息,并获得第一请求消息中的一个或多个字段,其中所述第一请求消息用于请求在发送端和接收端之间建立连接;以及
用所述一个或多个字段作为密钥对第一响应消息中的针对第一请求消息的第一确认号加密,并向发送端发送第一响应消息。
9.如权利要求8所述的通信方法,还包括:
接收来自发送端的第二响应消息,并用所述一个或多个字段作为密钥对第二响应消息中的针对第一响应消息的第二确认号解密,以获得经解密的第二确认号;以及
判断经解密的第二确认号是否与预期的确认号一致,并且如果一致,则与发送端建立安全连接。
10.如权利要求9所述的通信方法,其中,所述一个或多个字段包括发送端的初始序列号和源端口号中的至少一者。
11.如权利要求10所述的通信方法,还包括:
用源端口号作为密钥对初始序列号解密,或者用初始序列号作为密钥对源端口号解密。
12.如权利要求8所述的通信方法,其中,第一响应消息还包括接收端的初始序列号和源端口号,所述方法还包括用所述一个或多个字段作为密钥而对接收端的初始序列号和源端口号中的至少一者加密。
13.如权利要求9所述的通信方法,其中,第二响应消息还包括发送端的序列号和源端口号,并且发送端的序列号和源端口号中的至少一者也用所述一个或多个字段作为密钥而被加密,所述方法还包括:
用所述一个或多个字段作为密钥对发送端的初始序列号和源端口号解密中的所述至少一者,以获得经解密的发送端的初始序列号和源端口号中的所述至少一者。
14.如权利要求8至13中任一项所述的通信方法,还包括从第一请求消息中获得另一密钥,并用所述另一密钥对从发送端接收的数据解密以恢复出实际数据。
15.一种通信装置,包括:
处理器;和
计算机可读介质,所述计算机可读介质与所述处理器耦接并且包括处理器可执行的指令,所述指令在由处理器执行时使所述处理器执行如权利要求1至14中任一项所述的方法。
16.一种计算机可读存储介质,其上存储有可执行指令,所述指令在由处理器执行时,实现如权利要求1至14中任一项所述的方法。
17.一种用于通信的装置,包括用于执行如权利要求1至14中任一项所述的方法的单元。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2018100134663 | 2018-01-05 | ||
CN201810013466 | 2018-01-05 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109040059A true CN109040059A (zh) | 2018-12-18 |
CN109040059B CN109040059B (zh) | 2020-09-04 |
Family
ID=64353011
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810862167.7A Active CN109040059B (zh) | 2018-01-05 | 2018-07-31 | 受保护的tcp通信方法、通信装置及存储介质 |
CN201810862639.9A Active CN108900532B (zh) | 2018-01-05 | 2018-07-31 | 用于消息处理的电子设备、方法、存储介质和装置 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810862639.9A Active CN108900532B (zh) | 2018-01-05 | 2018-07-31 | 用于消息处理的电子设备、方法、存储介质和装置 |
Country Status (1)
Country | Link |
---|---|
CN (2) | CN109040059B (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111107167A (zh) * | 2020-01-03 | 2020-05-05 | 中仿智能科技(上海)股份有限公司 | 一种飞行模拟器仿真***的网络通信装置 |
CN113055535A (zh) * | 2019-12-26 | 2021-06-29 | 中国电信股份有限公司 | 用于生成5g端到端话单的方法和*** |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109117678A (zh) * | 2018-08-10 | 2019-01-01 | 天地融科技股份有限公司 | 一种信息传输方法及*** |
CN109344608B (zh) * | 2018-08-10 | 2021-09-21 | 天地融科技股份有限公司 | 一种信息传输方法及*** |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1909551A (zh) * | 2005-08-03 | 2007-02-07 | 北京航空航天大学 | 基于Web服务的数据交换方法 |
CN103024736A (zh) * | 2011-09-28 | 2013-04-03 | 国民技术股份有限公司 | 一种通信连接方法及装置 |
WO2013055091A1 (ko) * | 2011-10-10 | 2013-04-18 | 고려대학교 산학협력단 | Tcp통신을 이용한 정보 저장방법 및 시스템 |
CN103391289A (zh) * | 2013-07-16 | 2013-11-13 | 中船重工(武汉)凌久高科有限公司 | 一种基于完成端口模型的多链路安全通信方法 |
CN107612679A (zh) * | 2017-09-05 | 2018-01-19 | 北京天芯微鸿科技有限公司 | 一种基于国密算法的安全以太网桥加扰终端 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102711065A (zh) * | 2012-04-11 | 2012-10-03 | 佳都新太科技股份有限公司 | 一种使用原被叫字段来传输短信验证码的方法 |
CN105763516B (zh) * | 2014-12-17 | 2019-11-29 | 深圳市腾讯计算机***有限公司 | 从无线局域网内终端向网外设备发送数据的方法和装置 |
WO2017061017A1 (ja) * | 2015-10-08 | 2017-04-13 | 三菱電機株式会社 | 暗号システム、準同型署名方法及び準同型署名プログラム |
CN106535144A (zh) * | 2016-10-27 | 2017-03-22 | 珠海格力电器股份有限公司 | 一种加密短信息的发送方法及终端 |
-
2018
- 2018-07-31 CN CN201810862167.7A patent/CN109040059B/zh active Active
- 2018-07-31 CN CN201810862639.9A patent/CN108900532B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1909551A (zh) * | 2005-08-03 | 2007-02-07 | 北京航空航天大学 | 基于Web服务的数据交换方法 |
CN103024736A (zh) * | 2011-09-28 | 2013-04-03 | 国民技术股份有限公司 | 一种通信连接方法及装置 |
WO2013055091A1 (ko) * | 2011-10-10 | 2013-04-18 | 고려대학교 산학협력단 | Tcp통신을 이용한 정보 저장방법 및 시스템 |
CN103391289A (zh) * | 2013-07-16 | 2013-11-13 | 中船重工(武汉)凌久高科有限公司 | 一种基于完成端口模型的多链路安全通信方法 |
CN107612679A (zh) * | 2017-09-05 | 2018-01-19 | 北京天芯微鸿科技有限公司 | 一种基于国密算法的安全以太网桥加扰终端 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113055535A (zh) * | 2019-12-26 | 2021-06-29 | 中国电信股份有限公司 | 用于生成5g端到端话单的方法和*** |
CN113055535B (zh) * | 2019-12-26 | 2022-06-24 | 中国电信股份有限公司 | 用于生成5g端到端话单的方法和*** |
CN111107167A (zh) * | 2020-01-03 | 2020-05-05 | 中仿智能科技(上海)股份有限公司 | 一种飞行模拟器仿真***的网络通信装置 |
CN111107167B (zh) * | 2020-01-03 | 2022-04-29 | 中仿智能科技(上海)股份有限公司 | 一种飞行模拟器仿真***的网络通信装置 |
Also Published As
Publication number | Publication date |
---|---|
CN109040059B (zh) | 2020-09-04 |
CN108900532A (zh) | 2018-11-27 |
CN108900532B (zh) | 2020-10-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7660980B2 (en) | Establishing secure TCP/IP communications using embedded IDs | |
CN1578218B (zh) | 用透明虚拟专用网络减少网络配置复杂性 | |
CN108111301B (zh) | 基于后量子密钥交换实现ssh协议的方法及其*** | |
CN104067595B (zh) | 用于在网络环境中的传输层安全会话票证的创新管理的***和方法 | |
JP2023116573A (ja) | クライアント-クラウドまたはリモートサーバーの安全なデータまたはファイル・オブジェクト暗号化ゲートウェイ | |
Jangirala et al. | A multi-server environment with secure and efficient remote user authentication scheme based on dynamic ID using smart cards | |
CN109040059A (zh) | 受保护的tcp通信方法、通信装置及存储介质 | |
Saha et al. | Consortium blockchain‐enabled access control mechanism in edge computing based generic Internet of Things environment | |
EP1913728A1 (en) | Total exchange session security | |
CN101978650A (zh) | 安全的网络认证***和方法 | |
CN111835499A (zh) | 一种基于高性能计算的l2tp/ipsec破解方法及*** | |
CN106789524A (zh) | Vpn加密通道的高速解析与还原方法 | |
Angelo | Secure Protocols And Virtual Private Networks: An Evaluation. | |
CN114584386B (zh) | 全局多级加密网络通信方法 | |
CN211352206U (zh) | 基于量子密钥分发的IPSec VPN密码机 | |
Wu et al. | Internet of Things Security | |
CN107276996A (zh) | 一种日志文件的传输方法及*** | |
Costea et al. | Secure opportunistic multipath key exchange | |
US20070067464A1 (en) | Authentication Protection Apparatus and Method | |
WO2023036348A1 (zh) | 一种加密通信方法、装置、设备及介质 | |
CN110417804A (zh) | 一种适于单片机实现的双向身份认证加密通信方法及*** | |
Youssef et al. | Securing authentication of TCP/IP layer two by modifying challenge-handshake authentication protocol | |
Ajay et al. | Packet encryption for securing real-time Mobile cloud applications | |
CN107786507A (zh) | 一种确保http数据传输安全的方法 | |
Alhumrani et al. | Cryptographic protocols for secure cloud computing |
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 |