CN115333779A - 一种验证数据的方法、装置及电子设备 - Google Patents

一种验证数据的方法、装置及电子设备 Download PDF

Info

Publication number
CN115333779A
CN115333779A CN202210835649.XA CN202210835649A CN115333779A CN 115333779 A CN115333779 A CN 115333779A CN 202210835649 A CN202210835649 A CN 202210835649A CN 115333779 A CN115333779 A CN 115333779A
Authority
CN
China
Prior art keywords
sender
public key
certificate
data packet
private
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
CN202210835649.XA
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.)
Tianyi Cloud Technology Co Ltd
Original Assignee
Tianyi Cloud Technology Co Ltd
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 Tianyi Cloud Technology Co Ltd filed Critical Tianyi Cloud Technology Co Ltd
Priority to CN202210835649.XA priority Critical patent/CN115333779A/zh
Publication of CN115333779A publication Critical patent/CN115333779A/zh
Pending legal-status Critical Current

Links

Images

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/12—Applying verification of the received information
    • 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
    • H04L63/0435—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 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption

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)
  • Storage Device Security (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种验证数据的方法、装置及电子设备，用以降低单包授权技术的安全风险，从而避免单包授权中发送方的密钥被泄露，导致攻击者基于泄露密钥伪造单数据包针对服务端进行攻击的情况。该方法包括：发送方接收私有证书中心下发的第一证书；其中，所述第一证书包括所述发送方的第一公钥，和所述私有证书中心基于所述第一公钥生成的第一签名；基于第二加密算法针对第一数据包进行加密，得到第二数据包；基于所述发送方的第一私钥确定所述第一数据包的第二签名；向接收方发送验证数据包，使所述接收方确定所述发送方可信；其中，所述验证数据包包括所述第二数据包和所述第二签名。

Description

一种验证数据的方法、装置及电子设备
技术领域
本申请涉及网络安全技术领域，尤其涉及一种验证数据的方法、装置及电子设备。
背景技术
传统保护网络技术是通过防火墙、VPN(Virtual Private Network，虚拟专用网络)等工具为网络划分边界，并在边界处针对外部情求和/或连接进行验证，以保护内部网络的技术。然而，随着互联网技术的发展及企业组织架构的扩大与复杂化，定义网络边界变得越来越难，并且仅通过传统技术划分网络边界进行保护所面临的安全风险也在增长。“零信任”作为一种新型内部网络保护体系应运而生，采用粒度更细的标准针对内部网络进行安全保护。“零信任”体系中不再包括内部网络和外部网络的概念，其假定整个网络都不可信，且攻击者可使用任意IP都可发起攻击，因而“零信任”体系中针对所有连接、请求均进行安全验证。
SPA(Single Packet Authorization，单包授权)技术是零信任体系中保护网络安全的一种技术。客户端在基于TCP(Transmission Control Protocol，传输控制协议)向服务端发起连接之前，首先基于UDP(User Datagram Protocol，用户数据报协议)向服务端发送一个SPA数据包。服务端在接收到该SPA数据包之后进行验证。当该SPA数据包经服务端验证通过之后，服务端向客户端开启TCP端口；客户端通过该TCP端口与服务端建立连接。当该SPA数据包未通过服务端验证时，则服务端丢弃该SPA数据包，同时由于相应端口未开启，客户端也无法扫描到相应端口，因而无法建立连接。为确保SPA数据包中数据的完整性、保密性、不可篡改性，客户端与服务端通过提前共享加密密钥、解密密钥，使得客户端对SAP数据包进行加密后发送，而服务端在接收到SPA数据包之后需使用相应的密钥进行解密后再进行数据验证。这种客户端与服务端提前共享密钥以进行SPA数据包加解密的方法，存在密钥泄露的风险，使得攻击者通过相同密钥伪造任一客户端的SPA数据包达到攻击服务端的目的。
发明内容
本申请提供了一种验证数据的方法、装置及电子设备，用以降低单包授权技术的安全风险，从而避免单包授权中发送方的密钥被泄露，导致攻击者基于泄露密钥伪造单数据包针对服务端进行攻击的情况。
第一方面，本申请提供一种验证数据的方法，包括：
发送方接收私有证书中心下发的第一证书；其中，所述第一证书包括所述发送方的第一公钥，和所述私有证书中心基于所述第一公钥生成的第一签名，所述第一公钥为所述发送方基于第一加密算法所得；
基于第二加密算法针对第一数据包进行加密，得到第二数据包；其中，所述第一数据包包括所述发送方的身份信息、所述第一证书和目标端口，所述目标端口为所述发送方请求访问的端口；
基于所述发送方的第一私钥确定所述第一数据包的第二签名；其中，所述第一私钥与所述第一公钥一一对应；
向接收方发送验证数据包，使所述接收方确定所述发送方可信；其中，所述验证数据包包括所述第二数据包和所述第二签名。
上述申请实施例将私有证书中心签发的第一证书设置于单包授权时的第一数据包中与第二签名组合为验证数据包，发送至接收方，使得接收方基于私有证书中心下发的私有证书中心公钥，验证第一证书中的第一签名与第一公钥后，再验证第二签名，通过私有证书中心下发的第一证书，确保第一公钥不被篡改或更换，从而有效提升了单包授权技术的安全性。
一种可能的实施方式，所述第二加密算法为对称加密算法。
一种可能的实施方式，所述向接收方发送验证数据包之后，还包括：
接收通知信息；其中，所述通知信息指示所述接收方确定所述发送方可信，并向所述发送方开启所述目标端口；
基于所述通知信息，建立与所述目的端口之间的连接；
将所述第一证书和第二公钥发送至所述接收方，使所述接收方确定主密钥；其中，所述第一证书用于所述接收方验证所述发送方身份，所述第二公钥为所述发送方基于第三加密算法所得，所述第二公钥和所述第二私钥一一对应；
接收所述接收方发送的第二证书和第四公钥；其中，所述第二证书包括所述接收方的第三公钥，和所述私有证书中心基于所述第三公钥生成的第三签名，所述第三公钥为所述接收方基于所述第一加密算法所得，所述第四公钥为所述接收方基于所述第三加密算法所得；所述第四公钥和所述第四私钥一一对应；
确定私有证书中心公钥；
基于所述私有证书中心公钥验证所述第二证书中的第三签名，确定所述接收方可信；
基于所述第二公钥和所述第四公钥，利用第三加密算法得到所述主密钥。
第二方面，本申请提供一种验证数据的方法，包括：
接收方确定验证数据包中的第二签名和第二数据包；其中，所述验证数据包由所述发送方将所述第二签名和所述第二数据包组合并发送至所述接收方，所述第二签名由所述发送方基于所述发送方的第一私钥生成，所述第二数据包由所述发送方针对第一数据包加密得到，所述第一数据包包括所述发送方的身份信息、所述第一证书和目标端口，所述目标端口为所述发送方请求访问的端口；
基于第二加密算法，针对所述第二数据包解密，得到所述第一数据包；
在所述第一数据包中提取第一证书；其中，所述第一证书包括所述发送方的第一公钥和所述私有证书中心基于所述第一公钥生成的第一签名，所述第一公钥为所述发送方基于第一加密算法所得；
基于获取到的私有证书中心公钥验证所述第一证书，确定所述发送方可信。
一种可能的实施方式，所述基于获取到的私有证书中心公钥验证所述第一证书，确定所述发送方可信，包括：
基于所述私有证书中心公钥，验证所述第一证书中的第一签名，确定所述第一证书可信；
基于所述第一证书中的第一公钥，验证所述第二签名，确定所述发送方可信。
一种可能的实施方式，所述确定所述发送方可信之后，包括：
在所述第一数据包中，确定所述目的端口；
开启所述目的端口，并向所述发送方发送所述通知信息，使所述发送方基于所述通知信息建立与所述目的端口之间的连接；
接收所述发送方发送的第一证书和第二公钥；其中，所述第二公钥为所述发送方基于第三加密算法所得；
确定所述私有证书中心公钥；
基于所述私有证书中心公钥，验证所述第一证书，确定所述发送方可信；
基于所述第二公钥和第四公钥，利用所述第三加密算法生成主密钥；其中，所述第四公钥为所述接收方基于所述第三加密算法所得；
发送第二证书和第四公钥至所述发送方，使所述发送方确定所述主密钥；其中，所述第二证书包括所述接收方的第三公钥，和所述私有证书中心基于所述第三公钥生成的第三签名，所述第三公钥为所述接收方基于所述第一加密算法所得，所述第四公钥为所述接收方基于所述第三加密算法所得。
第三方面，本申请提供一种验证数据的装置，包括：
证书单元：用于发送方接收私有证书中心下发的第一证书；其中，所述第一证书包括所述发送方的第一公钥和所述私有证书中心基于所述第一公钥生成的第一签名，所述第一公钥为所述发送方基于第一加密算法所得；
加密单元：用于基于第二加密算法针对第一数据包进行加密，得到第二数据包；其中，所述第一数据包包括所述发送方的身份信息、所述第一证书和目标端口，所述目标端口为所述发送方请求访问的端口；
签名单元：用于基于所述发送方的第一私钥确定所述第一数据包的第二签名；其中，所述第一私钥与所述第一公钥一一对应；
发送单元：用于向接收方发送验证数据包，使所述接收方确定所述发送方可信；其中，所述验证数据包包括所述第二数据包和所述第二签名。
第四方面，本申请提供一种验证数据的装置，包括：
接收单元：用于接收方确定验证数据包中的第二签名和第二数据包；其中，所述验证数据包由所述发送方将所述第二签名和所述第二数据包组合并发送至所述接收方，所述第二签名由所述发送方基于所述发送方的第一私钥生成，所述第二数据包由所述发送方针对第一数据包加密得到，所述第一数据包包括所述发送方的身份信息、所述第一证书和目标端口，所述目标端口为所述发送方请求访问的端口；
解密单元：用于基于第二加密算法，针对所述第二数据包解密，得到所述第一数据包；
提取单元：用于在所述第一数据包中提取第一证书；其中，所述第一证书包括所述发送方的第一公钥和所述私有证书中心基于所述第一公钥生成的第一签名，所述第一公钥为所述发送方基于第一加密算法所得；
验证单元：用于基于获取到的私有证书中心公钥验证所述第一证书，确定所述发送方可信。
第五方面，本申请提供一种可读存储介质，包括，
存储器，
所述存储器用于存储指令，当所述指令被处理器执行时，使得包括所述可读存储介质的装置完成如第一方面、第二方面及任一种可能的实施方式所述的方法。
第六方面，本申请提供一种电子设备，包括：
存储器，用于存放计算机程序；
处理器，用于执行所述存储器上所存放的计算机程序时，以实现如第一方面、第二方面及任一种可能的实施方式所述的方法。
附图说明
图1为本申请实施例为发送方所提供的一种验证数据的方法的流程示意图；
图2为本申请实施例为接收方所提供的一种验证数据的方法的流程示意图；
图3为本申请实施例所提供的零信任网络体系结构图；
图4为本申请实施例所提供的mTLS握手流程示意图；
图5为本申请实施例为发送方提供的一种验证数据的装置的结构示意图；
图6为本申请实施例为接收方提供的一种验证数据的装置的结构示意图；
图7为本申请实施例提供的一种验证数据的电子设备的结构示意图。
具体实施方式
针对现有技术中单包授权技术安全风险高的问题，本申请提出一种数据验证方法：通过引入私有证书中心，并通过私有证书中心为所有端下发经私有证书中心私钥加密的证书。客户端在发起单包授权时，使用客户端私钥签名，并将签名和接收到的私有证书中心下发的客户端证书一起发送至服务端。相应地，服务端在接收到客户端所发送的签名以及客户端证书后，先通过私有证书中心公钥针对客户端证书进行验证，继而验证签名，从而确保单包授权发送方(即客户端)可信。即通过私有证书中心签发的证书，针对客户端/服务端公钥进行加密，确保发送方的公钥不被篡改、不被更换，避免公钥泄露引起的安全风险。
需要说明的是，本申请实施例中客户端和服务端仅作为发送方和接收方两种角色的区分，二者可根据发送方或接收方角色的变化而改变。
为了更好的理解上述技术方案，下面通过附图以及具体实施例对本申请技术方案做详细的说明，应当理解本申请实施例以及实施例中的具体特征是对本申请技术方案的详细的说明，而不是对本申请的技术方案的限定，在不冲突的情况下，本申请实施例以及实施例中的技术特征可以相互组合。
请参考图1，本申请提出一种验证数据的方法，用以降低单包授权时网络所面临的安全风险，该方法具体包括以下实现步骤：
步骤101：发送方接收私有证书中心下发的第一证书。
其中，第一证书包括发送方的第一公钥和私有证书中心基于第一公钥生成的第一签名。
该第一签名实际上是由私有证书中心利用私有证书中心私钥针对第一公钥签名所得。第一公钥为所述发送方基于第一加密算法所得。
需要说明的是，本申请实施例中的加密算法(例如，第一加密算法)可以使对称加密算法，也可以是非对称加密算法。当加密算法生成公钥，则意在表明该加密算法可生成密钥对，则该加密算法为非对称加密算法。例如，步骤101所述的第一公钥由第一加密算法所得，则第一公钥为第一加密算法生成的密钥对中的密钥之一，另有第一私钥与第一密钥一一对应，并组成密钥对。
本申请实施例中，在各端(发送方和/或接收方)接收私有证书中心(CertificateAuthority，CA)下发的证书之前，需首先向私有证书中心发起证书签署请求(CertificateSign Request，CSR)。私有证书中心下发的证书为数字证书，用于身份认证和加密。
在本申请的一种实施例中，上述证书(例如，第一证书)均为x.509证书。
以下针对各端(以发送方为例)获取各自证书的方法进行描述：
首先基于第一加密算法生成第一密钥对。第一加密算法可以是RSA(Rivest-Shamir-Adleman Scheme),也可以是ECDSA(Elliptic Curve Digital SignatureAlgorithm，椭圆曲线数字签名算法)。
然后将第一密钥对中的第一公钥以及自身信息以设置顺序拼接，得到第一数据段。前述自身信息可以是用户名、域名等。
接着可针对第一数据段转为设置格式的待验证数据段，并向私有证书中心传输。该设置可使可以是PEM(Privacy Enhanced Mail)格式。
私有证书中心接收到待验证数据段会后，验证其中信息的有效性。例如，用户名是否为组织成员、域名是否为组织资产等。验证通过后则返回签署的证书。该签署的证书中包括两部分内容。其一为私有证书中心使用私有证书中心私钥针对第一公钥进行加密所得的第一签名、第一公钥以及私有证书中心公钥。
步骤102：基于第二加密算法针对第一数据包进行加密，得到第二数据包。
其中，第一数据包包括发送方的身份信息、第一证书和目标端口，所述目标端口为所述发送方请求访问的端口。
第二加密算法可以是发送方和接收方预先协商的。在本申请的一种实施例中，第二加密算法为对称加密算法。
在本申请的一种实施例中，第一数据包还包括安全分值。该安全分值指示发送方所在设备运行时的安全程度；具体可以是在设备运行时，发送方采集到设备运行时安全相关的数据进行计算所得，该分值实际上可反映硬件安全程度。其中，安全相关数据可根据操作系统不定版本、是否存在可疑进程、杀毒软件和防火墙状态等因素得到。
第一数据包中还可以包括版本号、目标地址类型、随机数、时间戳等。同时，为避免字符串中特殊符号(例如，空格等)影响传输，并确保接收方可顺利读取，针对第一数据包中的字符串可使用base64进行编码。表1为本申请实施例中所提供的第一数据包中可包括的字段名，以及是否需要base64编码的设置，请参考表1。
表1
Figure BDA0003747956230000081
Figure BDA0003747956230000091
注：重放攻击指攻击者通过截取第二数据包，重复利用第二数据包与接收方完成mTLS握手。
第一数据包中所有内容以预设顺序排列，并通过预设符号(例如，“：”)分隔，以便于接收方读取。
步骤103：基于所述发送方的第一私钥确定所述第一数据包的第二签名。
其中，所述第一私钥与所述第一公钥一一对应。
步骤104：向接收方发送验证数据包，使所述接收方确定所述发送方可信。
其中，所述验证数据包包括所述第二数据包和所述第二签名。
第二数据包可通过以下公式表示：
SPA＝CPSK(SPA0：...：SPAn)：ECCKs(Hash(SPA0：...：SPAn))；
其中，SPA为验证数据包，CPSK为第二数据包，ECCKS为第二签名。
当接收方确定发送方可信时，则向发送方发出通知信息。其中，通知信息指示接收方确定发送方可信，并进一步向发送方开启目的端口。该目的端口可以是基于TCP的TCP端口。
在本申请的一种实施例中，发送方基于通知信息和TCP协议，建立与接收方TCP端口之间的TCP连接。
在发送方和接收方建立连接之后，需进行TCP握手以及mTLS(mutual TransportLayer Security，双向传输层安全协议)握手进行密钥协商，经密钥协商所得的主密钥可用于握手之后发送方以及接收方之间通信消息的加密。
进一步地，在进行mTLS握手时，发送方同样可将第一证书以及第二公钥一起发送，使得接收方在接收到第一证书和第二公钥后，先针对第一证书进行关于发送方身份的验证，再基于第二公钥进行密钥协商。其中，第二公钥为发送方基于第三加密算法所得的密钥对中的密钥之一，另有第二私钥与第二公钥一一对应。
同时，发送方接收到来自接收方的第二证书和第四公钥。其中，第四公钥为接收方基于第三加密算法所得，第四公钥和第四私钥一一对应。
接着确定私有证书中心公钥，并基于私有证书中心公钥和第二证书，确定接收方可信。确定方法可以是：基于私有证书中心公钥解密第二证书中，私有证书中心利用私有证书中心私钥针对接收方公钥加密所得的第三签名，得到第三签名摘要。基于预设哈希算法(例如，SHA256算法)，针对第三公钥进行加密，得到第三摘要。将第三摘要和第三签名摘要对比，当第三摘要和第三签名摘要相同时，则确定接收方可信。进一步地，可以基于第四公钥和发送方的第二公钥生成上述主密钥。
以上步骤101-104为本申请实施例所提供的发送方进行单包授权时所执行的步骤，以下针对接收方执行本申请所提供的验证数据的方法时的流程进行描述，请参考图2：
步骤201：接收方确定验证数据包中的第二签名和第二数据包。
其中，验证数据包由发送方将第二签名和第二数据包组合并发送至接收方。第二签名由所述发送方基于第一私钥生成，第二数据包由发送方基于针对第一数据包加密得到，第一数据包包括发送方的身份信息、第一证书和目标端口。目标端口为发送方请求访问的端口。
接收方在接受到验证数据包之后，可按照验证数据包的预设排列位置，相应位置上提取第二签名和第二数据包。
步骤202：基于第二加密算法，针对所述第二数据包解密，得到所述第一数据包。
具体地，针对第二数据包，使用步骤102中所述的第二加密算法针对第二数据包解密，得到第一数据包。
步骤203：在所述第一数据包中提取第一证书。
其中，所述证书包括所述发送方的第一公钥和所述私有证书中心基于第一公钥生成的第一签名，第一公钥为发送方基于第一加密算法所得。
与步骤102中所述的第一数据包类型，接收方可从第一数据包中获取如表1所列的数据内容。在本申请的一种实施例中，第一数据包中包括安全分值。该安全分值指示发送方所在设备运行时的安全程度；具体可以是在设备运行时，发送方采集到设备运行时安全相关的数据进行计算所得，该分值实际上可反映硬件安全程度。其中，安全相关数据可根据操作系统不定版本、是否存在可疑进程、杀毒软件和防火墙状态等因素得到。因而，接收方可从第一数据包中提取安全分值，并基于安全分值针对发送方进行安全评估。
步骤204：基于获取到的私有证书中心公钥验证所述第一证书，确定所述发送方可信。
首先基于私有证书中心公钥，验证第一证书中的第一签名，确定第一证书可信。具体的验证方法可以是：利用私有证书中心公钥解密第一证书中的第一签名，得到第一摘要。同时，利用预设哈希算法，针对第一证书中的第一公钥加密，得到第一验证摘要。当第一摘要和第一验证摘要相同时，则可以确定第一证书可信，因而第一证书中的第一公钥可信，即未经攻击者篡改。
然后，基于第一证书中的第一公钥，验证数据包中的第二签名，确定发送方可信。验证方法可以与上述验证第一证书中第一签名步骤一致。具体的验证方法可以是：利用第一公钥解密第二签名，得到第二摘要。同时，利用预设哈希算法，针对第一公钥进行加密，得到第二验证摘要。当第二摘要和第二验证摘要相同时，则可以确定发送方可信，即确定发送方安全。
上述预设哈希算法可以是SHA256算法。
在确定发送方可信后，可进一步在第一数据包中确定目的端口。确定的方法是：根据第一数据包中的分隔符，将所述第一数据包中的数据断开。该分隔符可以由发送方和接收方预先协商。分隔符可以是“：”。然后基于预设排列顺序，在预设位置上提取指示目的端口的数据内容。
然后，开启目的端口，并向发送方发送通知信息，使发送方基于通知信息建立与目的端口之间的连接。该目的端口可以是TCP端口，则连接可以是TCP连接。
接着进行TCP握手以及mTLS握手，以进行主密钥协商，从而能在基于上述连接通信时，基于该主密钥进行通信。在进行mTLS握手时，接收方也进行与发送方想一致的动作，并生成与发送方一致的主密钥。具体地，首先接收发送方发送的第一证书和第二公钥。其中，第二公钥为发送方基于第三加密算法所得。然后，确定由私有证书中心下发的私有证书中心公钥。接着，该私有证书中心公钥，验证第一证书中的第一签名，确定发送方可信。此处验证第一证书中的第一签名的方法与前述验证第一签名的方法步骤一致，此处不再赘述。最后，基于第二公钥和第四公钥，利用第三加密算法生成主密钥。其中，第四公钥为接收方基于第三加密所得的第四密钥对之一，第三密钥对中另一密钥为第四私钥。
在生成主密钥之余，接收方还需向发送方发送第二证书和第四公钥，使发送方确定主密钥，从而达到密钥协商的目的。其中，所述第二证书包括所述接收方的第三公钥，和所述私有证书中心基于所述第三公钥生成的第三签名，所述第三公钥为所述接收方基于所述第一加密算法所得，所述第四公钥为所述接收方基于所述第三加密算法所得。
综上所述，本申请实施例中在单包授权的零信任体系中建立私有证书中心，通过私有证书中心为各端签署证书并下发，使得各端之间通信时，可基于私有证书中心签发的证书对彼此的身份是否安全进行认证，以提高单包授权中建立连接时的安全性。同时，通信各端还可基于私有证书中心签发证书在mTLS握手时进行彼此身份是否安全的验证，以保证各端密钥协商时的安全性，从而有效降低了单包授权所面临的安全风险。
图3为本申请实施例所提供的零信任网络体系结构图，以下将发送方作为客户端，接收方作为服务端，针对零信任体系网络的建立进行说明。假设客户端(发送方)、服务端(接收方)、和私有证书中心构成零信任体系，且私有证书中心下发证书为x.509证书。
如图3所示，私有证书中心在生成包括CA私钥和CA公钥的CA密钥对(即私有证书中心密钥对)之后，根据服务端和/或客户端的证书签署请求进行CA证书签发流程：签署CA证书。客户端作为发送方对应于步骤101-104执行获取私有证书中心下发的客户端证书流程。首先，基于非对称加密算法，生成客户端密钥对。然后，将客户端密钥对中的客户端公钥和客户端信息以PEM格式序列化后，发送至私有证书中心。私有证书中心获取到客户端发送数据后，在数据的预设位置提取客户端信息，并基于客户端信息验证客户端合法。若验证通过，则使用CA私钥签发客户端证书，并发回至客户端。客户端接收到的客户端证书包括了CA公钥，经CA私钥针对客户端公钥加密得到的客户端签名以及客户端公钥。
同理，服务端也可执行如客户端获取客户端证书流程相一致的服务端获取服务端证书流程，以获取服务端证书：首先，生成服务端密钥对。然后，将服务端密钥对中的服务端公钥和服务信息以PEM格式序列化后发送至私有证书中心。私有证书中心验证服务端合法后，使用CA私钥签发服务端证书，即使用CA私钥确定服务端公钥的签名，然后将服务端公钥签名、服务端公钥、和CA公钥作为服务端证书发回服务端，服务端接收到服务端证书后，本申请实施例中所提供的零信任体系构造完成。
进一步地，基于图3所示的零信任体系网络建立客户端与服务端连接之后，进行mTLS握手流程进行举例说明，请参考图4。如图4所示，在服务端验证客户端可信，基于第一数据包中的目的端口，向客户端开启目的端口，并发送通知信息后。客户端可发起TCP连接，服务端接收TCP连接，从而达到建立TCP连接的目的。进一步地，客户端发起mTLS握手：首先，基于ECDH(Elliptic Curve Diffie–Hellman key Exchange，椭圆曲线迪菲-赫尔曼密钥交换)加密算法生成第一ECDH密钥对，并确定椭圆曲线参数。其中，第一ECDH密钥对包括第一ECDH公钥和第一ECDH私钥。而椭圆曲线参数则用于客户端和/或服务端生成各自的密钥对。然后，客户端基于第一ECDH参数和客户端证书生成client hello，并向服务端发送。其中，第一ECDH参数中包括第一ECDH公钥。
服务端接受到client hello之后，基于其中的客户端证书，利用服务端证书中的CA公钥验证客户端可信。然后在确定客户端可信之后，生成第二ECDH密钥对，接着就可基于第二ECDH密钥对中的第二ECDH公钥和第一ECDH公钥，基于ECDH加密算法确定主密钥。同时基于第二ECDH参数和服务端证书生成sever hello，并发送至客户端，使得客户端在接收到sever hello后，基于sever hello中的服务端证书，利用客户端证书中的CA公钥验证服务端可信。继而基于第二ECDH公钥和第一ECDH公钥确定主密钥。
在客户端和服务端完成密钥协商，即确定相同的主密钥之后，mTLS握手结束，则表明安全传输通道建立：客户端和服务端可基于主密钥进行加密通信。
上述实施例中客户端和服务端通过ECDH加密算法进行mTLS握手，达到密钥协商：确定主密钥的目的。在确定主密钥时，通过mTLS握手，确保客户端和服务端在每次接收到对方消息时，都针对对方的证书进行校验，确保对方为安全客户，方才进行消息回应，因而可有效避免恶意端通过伪装介入，导致网络面临安全风险的情况。
基于同一发明构思，本申请实施例中提供一种验证数据的装置，该装置与前述图1所示验证数据的方法对应，该装置的具体实施方式可参见前述方法实施例部分的描述，重复之处不再赘述，参见图5，该装置包括：
证书单元501：用于发送方接收私有证书中心下发的第一证书。
其中，所述第一证书包括所述发送方的第一公钥和所述私有证书中心基于所述第一公钥生成的第一签名，所述第一公钥为所述发送方基于第一加密算法所得。
加密单元502：用于基于第二加密算法针对第一数据包进行加密，得到第二数据包。
其中，所述第一数据包包括所述发送方的身份信息、所述第一证书和目标端口，所述目标端口为所述发送方请求访问的端口。
所述第二加密算法为对称加密算法。
签名单元503：用于基于所述发送方的第一私钥确定所述第一数据包的第二签名。
其中，所述第一私钥与所述第一公钥一一对应。
发送单元504：用于向接收方发送验证数据包，使所述接收方确定所述发送方可信。其中，所述验证数据包包括所述第二数据包和所述第二签名。
所述验证数据的装置还包括发起连接单元，所述发起连接单元具体用于接收通知信息；其中，所述通知信息指示所述接收方确定所述发送方可信，并向所述发送方开启所述目标端口；基于所述通知信息，建立与所述目的端口之间的连接；将所述第一证书和第二公钥发送至所述接收方，使所述接收方确定主密钥；其中，所述第一证书用于所述接收方验证所述发送方身份，所述第二公钥为所述发送方基于第三加密算法所得，所述第二公钥和所述第二私钥一一对应；接收所述接收方发送的第二证书和第四公钥；其中，所述第二证书包括所述接收方的第三公钥，和所述私有证书中心基于所述第三公钥生成的第三签名，所述第三公钥为所述接收方基于所述第一加密算法所得，所述第四公钥为所述接收方基于所述第三加密算法所得；所述第四公钥和所述第四私钥一一对应；确定私有证书中心公钥；基于所述私有证书中心公钥验证所述第二证书中的第三签名，确定所述接收方可信；基于所述第二公钥和所述第四公钥，利用第三加密算法得到所述主密钥。
进一步地，本申请提供一种验证数据的装置，该装置与前述图2所示验证数据的方法对应，该装置的具体实施方式可参见前述方法实施例部分的描述，重复之处不再赘述，参见图6，该装置包括：
接收单元601：用于接收方确定验证数据包中的第二签名和第二数据包。
其中，所述验证数据包由所述发送方将所述第二签名和所述第二数据包组合并发送至所述接收方，所述第二签名由所述发送方基于所述发送方的第一私钥生成，所述第二数据包由所述发送方针对第一数据包加密得到，所述第一数据包包括所述发送方的身份信息、所述第一证书和目标端口，所述目标端口为所述发送方请求访问的端口。
解密单元602：用于基于第二加密算法，针对所述第二数据包解密，得到所述第一数据包。
提取单元603：用于在所述第一数据包中提取第一证书。
其中，所述第一证书包括所述发送方的第一公钥和所述私有证书中心基于所述第一公钥生成的第一签名，所述第一公钥为所述发送方基于第一加密算法所得。
验证单元604：用于基于获取到的私有证书中心公钥验证所述第一证书，确定所述发送方可信。
基于同一发明构思，本申请实施例还提供一种可读存储介质，包括：
存储器，
所述存储器用于存储指令，当所述指令被处理器执行时，使得包括所述可读存储介质的装置完成如上所述的验证数据的方法。
基于与上述验证数据的方法相同的发明构思，本申请实施例中还提供了一种电子设备，所述电子设备可以实现前述一种验证数据的方法的功能，请参考图7，所述电子设备包括：
至少一个处理器701，以及与至少一个处理器701连接的存储器702，本申请实施例中不限定处理器701与存储器702之间的具体连接介质，图7中是以处理器701和存储器702之间通过总线700连接为例。总线700在图7中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线700可以分为地址总线、数据总线、控制总线等，为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。或者，处理器701也可以称为控制器，对于名称不做限制。
在本申请实施例中，存储器702存储有可被至少一个处理器701执行的指令，至少一个处理器701通过执行存储器702存储的指令，可以执行前文论述验证数据的方法。处理器701可以实现图6、图5所示的装置中各个模块的功能。
其中，处理器701是该装置的控制中心，可以利用各种接口和线路连接整个该控制设备的各个部分，通过运行或执行存储在存储器702内的指令以及调用存储在存储器702内的数据，该装置的各种功能和处理数据，从而对该装置进行整体监控。
在一种可能的设计中，处理器701可包括一个或多个处理单元，处理器701可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器701中。在一些实施例中，处理器701和存储器702可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。
处理器701可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的验证数据的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
存储器702作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器702可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等。存储器702是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器702还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
通过对处理器701进行设计编程，可以将前述实施例中介绍的验证数据的方法所对应的代码固化到芯片内，从而使芯片在运行时能够执行图1、图2所示的验证数据的方法的步骤。如何对处理器701进行设计编程为本领域技术人员所公知的技术，这里不再赘述。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：通用串行总线闪存盘(Universal Serial Bus flash disk)、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种验证数据的方法，其特征在于，包括：
发送方接收私有证书中心下发的第一证书；其中，所述第一证书包括所述发送方的第一公钥，和所述私有证书中心基于所述第一公钥生成的第一签名，所述第一公钥为所述发送方基于第一加密算法所得；
基于第二加密算法针对第一数据包进行加密，得到第二数据包；其中，所述第一数据包包括所述发送方的身份信息、所述第一证书和目标端口，所述目标端口为所述发送方请求访问的端口；
基于所述发送方的第一私钥确定所述第一数据包的第二签名；其中，所述第一私钥与所述第一公钥一一对应；
向接收方发送验证数据包，使所述接收方确定所述发送方可信；其中，所述验证数据包包括所述第二数据包和所述第二签名。
2.如权利要求1所述的方法，其特征在于，所述第二加密算法为对称加密算法。
3.如权利要求1或2所述的方法，其特征在于，所述向接收方发送验证数据包之后，还包括：
接收通知信息；其中，所述通知信息指示所述接收方确定所述发送方可信，并向所述发送方开启所述目标端口；
基于所述通知信息，建立与所述目的端口之间的连接；
将所述第一证书和第二公钥发送至所述接收方，使所述接收方确定主密钥；其中，所述第一证书用于所述接收方验证所述发送方身份，所述第二公钥为所述发送方基于第三加密算法所得，所述第二公钥和所述第二私钥一一对应；
接收所述接收方发送的第二证书和第四公钥；其中，所述第二证书包括所述接收方的第三公钥，和所述私有证书中心基于所述第三公钥生成的第三签名，所述第三公钥为所述接收方基于所述第一加密算法所得，所述第四公钥为所述接收方基于所述第三加密算法所得；所述第四公钥和所述第四私钥一一对应；
确定私有证书中心公钥；
基于所述私有证书中心公钥验证所述第二证书中的第三签名，确定所述接收方可信；
基于所述第二公钥和所述第四公钥，利用第三加密算法得到所述主密钥。
4.一种验证数据的方法，其特征在于，包括：
接收方确定验证数据包中的第二签名和第二数据包；其中，所述验证数据包由所述发送方将所述第二签名和所述第二数据包组合并发送至所述接收方，所述第二签名由所述发送方基于所述发送方的第一私钥生成，所述第二数据包由所述发送方针对第一数据包加密得到，所述第一数据包包括所述发送方的身份信息、所述第一证书和目标端口，所述目标端口为所述发送方请求访问的端口；
基于第二加密算法，针对所述第二数据包解密，得到所述第一数据包；
在所述第一数据包中提取第一证书；其中，所述第一证书包括所述发送方的第一公钥和所述私有证书中心基于所述第一公钥生成的第一签名，所述第一公钥为所述发送方基于第一加密算法所得；
基于获取到的私有证书中心公钥验证所述第一证书，确定所述发送方可信。
5.如权利要求4所述的方法，其特征在于，所述基于获取到的私有证书中心公钥验证所述第一证书，确定所述发送方可信，包括：
基于所述私有证书中心公钥，验证所述第一证书中的第一签名，确定所述第一证书可信；
基于所述第一证书中的第一公钥，验证所述第二签名，确定所述发送方可信。
6.如权利要求4或5所述的方法，其特征在于，所述确定所述发送方可信之后，包括：
在所述第一数据包中，确定所述目的端口；
开启所述目的端口，并向所述发送方发送所述通知信息，使所述发送方基于所述通知信息建立与所述目的端口之间的连接；
接收所述发送方发送的第一证书和第二公钥；其中，所述第二公钥为所述发送方基于第三加密算法所得；
确定所述私有证书中心公钥；
基于所述私有证书中心公钥，验证所述第一证书，确定所述发送方可信；
基于所述第二公钥和第四公钥，利用所述第三加密算法生成主密钥；其中，所述第四公钥为所述接收方基于所述第三加密算法所得；
发送第二证书和第四公钥至所述发送方，使所述发送方确定所述主密钥；其中，所述第二证书包括所述接收方的第三公钥，和所述私有证书中心基于所述第三公钥生成的第三签名，所述第三公钥为所述接收方基于所述第一加密算法所得，所述第四公钥为所述接收方基于所述第三加密算法所得。
7.一种验证数据的装置，其特征在于，包括：
证书单元：用于发送方接收私有证书中心下发的第一证书；其中，所述第一证书包括所述发送方的第一公钥和所述私有证书中心基于所述第一公钥生成的第一签名，所述第一公钥为所述发送方基于第一加密算法所得；
加密单元：用于基于第二加密算法针对第一数据包进行加密，得到第二数据包；其中，所述第一数据包包括所述发送方的身份信息、所述第一证书和目标端口，所述目标端口为所述发送方请求访问的端口；
签名单元：用于基于所述发送方的第一私钥确定所述第一数据包的第二签名；其中，所述第一私钥与所述第一公钥一一对应；
发送单元：用于向接收方发送验证数据包，使所述接收方确定所述发送方可信；其中，所述验证数据包包括所述第二数据包和所述第二签名。
8.一种验证数据的装置，其特征在于，包括：
接收单元：用于接收方确定验证数据包中的第二签名和第二数据包；其中，所述验证数据包由所述发送方将所述第二签名和所述第二数据包组合并发送至所述接收方，所述第二签名由所述发送方基于所述发送方的第一私钥生成，所述第二数据包由所述发送方针对第一数据包加密得到，所述第一数据包包括所述发送方的身份信息、所述第一证书和目标端口，所述目标端口为所述发送方请求访问的端口；
解密单元：用于基于第二加密算法，针对所述第二数据包解密，得到所述第一数据包；
提取单元：用于在所述第一数据包中提取第一证书；其中，所述第一证书包括所述发送方的第一公钥和所述私有证书中心基于所述第一公钥生成的第一签名，所述第一公钥为所述发送方基于第一加密算法所得；
验证单元：用于基于获取到的私有证书中心公钥验证所述第一证书，确定所述发送方可信。
9.一种可读存储介质，其特征在于，包括，
存储器，
所述存储器用于存储指令，当所述指令被处理器执行时，使得包括所述可读存储介质的装置完成如权利要求1-6中任一项所述的方法。
10.一种电子设备，其特征在于，包括：
存储器，用于存放计算机程序；
处理器，用于执行所述存储器上所存放的计算机程序时，以实现如权利要求1-6中任一项所述的方法。
CN202210835649.XA 2022-07-15 2022-07-15 一种验证数据的方法、装置及电子设备 Pending CN115333779A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210835649.XA CN115333779A (zh) 2022-07-15 2022-07-15 一种验证数据的方法、装置及电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210835649.XA CN115333779A (zh) 2022-07-15 2022-07-15 一种验证数据的方法、装置及电子设备

Publications (1)

Publication Number Publication Date
CN115333779A true CN115333779A (zh) 2022-11-11

Family

ID=83917791

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210835649.XA Pending CN115333779A (zh) 2022-07-15 2022-07-15 一种验证数据的方法、装置及电子设备

Country Status (1)

Country Link
CN (1) CN115333779A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116074455A (zh) * 2023-02-03 2023-05-05 天翼数字生活科技有限公司 基于1400协议的安全传输方法、视图库平台和系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040250076A1 (en) * 2003-05-23 2004-12-09 Hsiang-Tsung Kung Personal authentication device and system and method thereof
CN110046507A (zh) * 2018-12-12 2019-07-23 阿里巴巴集团控股有限公司 形成可信计算集群的方法及装置
CN112235235A (zh) * 2020-08-28 2021-01-15 中国大唐集团科学技术研究院有限公司 一种基于国密算法的sdp认证协议实现方法
CN112968971A (zh) * 2021-03-15 2021-06-15 北京数字认证股份有限公司 会话连接建立的方法、装置、电子设备和可读存储介质
CN114679293A (zh) * 2021-06-15 2022-06-28 腾讯云计算（北京）有限责任公司 基于零信任安全的访问控制方法、设备及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040250076A1 (en) * 2003-05-23 2004-12-09 Hsiang-Tsung Kung Personal authentication device and system and method thereof
CN110046507A (zh) * 2018-12-12 2019-07-23 阿里巴巴集团控股有限公司 形成可信计算集群的方法及装置
CN112235235A (zh) * 2020-08-28 2021-01-15 中国大唐集团科学技术研究院有限公司 一种基于国密算法的sdp认证协议实现方法
CN112968971A (zh) * 2021-03-15 2021-06-15 北京数字认证股份有限公司 会话连接建立的方法、装置、电子设备和可读存储介质
CN114679293A (zh) * 2021-06-15 2022-06-28 腾讯云计算（北京）有限责任公司 基于零信任安全的访问控制方法、设备及存储介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116074455A (zh) * 2023-02-03 2023-05-05 天翼数字生活科技有限公司 基于1400协议的安全传输方法、视图库平台和系统
CN116074455B (zh) * 2023-02-03 2024-01-19 天翼数字生活科技有限公司 基于1400协议的安全传输方法、视图库平台和系统

Similar Documents

Publication Publication Date Title
US11757662B2 (en) Confidential authentication and provisioning
CN109309565B (zh) 一种安全认证的方法及装置
US11533297B2 (en) Secure communication channel with token renewal mechanism
US11196722B2 (en) Method for mutual symmetric authentication between a first application and a second application
KR101904177B1 (ko) 데이터 처리 방법 및 장치
CN111740844A (zh) 基于硬件的国密算法的ssl通信方法及装置
WO2019085531A1 (zh) 一种终端联网认证的方法和装置
US9531540B2 (en) Secure token-based signature schemes using look-up tables
CN111614621B (zh) 物联网通信方法和系统
CN113806772A (zh) 基于区块链的信息加密传输方法及装置
KR101531662B1 (ko) 사용자 단말과 서버간 상호 인증 방법 및 시스템
WO2022135391A1 (zh) 身份鉴别方法、装置、存储介质、程序、及程序产品
CN113904767A (zh) 一种基于ssl建立通信的系统
CN115333779A (zh) 一种验证数据的方法、装置及电子设备
US20240154949A1 (en) Devices and Methods for Performing Cryptographic Handshaking
WO2023284691A1 (zh) 一种账户的开立方法、系统及装置
Shojaie et al. Enhancing EAP-TLS authentication protocol for IEEE 802.11 i
CN114095229A (zh) 能源互联网的数据传输协议构建方法、装置和系统
CN115549929B (zh) 基于零信任网络隐身的spa单包认证方法及装置
EP4443927A1 (en) Trusted measurement-integrated communication method and apparatus
Jeelani An insight of ssl security attacks
CN117749476A (zh) 基于加密算法的可信安全连接方法及装置、电子设备
CN117728958A (zh) 一种通信方法、装置和系统

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