CN115714681B - 数据验证方法、装置及存储介质 - Google Patents
数据验证方法、装置及存储介质 Download PDFInfo
- Publication number
- CN115714681B CN115714681B CN202211414745.3A CN202211414745A CN115714681B CN 115714681 B CN115714681 B CN 115714681B CN 202211414745 A CN202211414745 A CN 202211414745A CN 115714681 B CN115714681 B CN 115714681B
- Authority
- CN
- China
- Prior art keywords
- data
- verification
- state information
- information
- verified
- 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.)
- Active
Links
- 238000013524 data verification Methods 0.000 title claims abstract description 140
- 238000000034 method Methods 0.000 title claims abstract description 74
- 238000012795 verification Methods 0.000 claims abstract description 121
- 238000004891 communication Methods 0.000 claims abstract description 68
- 238000012545 processing Methods 0.000 claims description 39
- 230000005540 biological transmission Effects 0.000 abstract description 31
- 230000008569 process Effects 0.000 description 19
- 230000006870 function Effects 0.000 description 15
- 230000009286 beneficial effect Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 7
- 230000003993 interaction Effects 0.000 description 7
- 238000002955 isolation Methods 0.000 description 7
- 238000013461 design Methods 0.000 description 5
- 238000004590 computer program Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 230000009545 invasion Effects 0.000 description 3
- 230000003068 static effect Effects 0.000 description 3
- 235000019800 disodium phosphate Nutrition 0.000 description 2
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000033001 locomotion Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000037361 pathway Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Landscapes
- Storage Device Security (AREA)
- Communication Control (AREA)
Abstract
本申请公开了一种数据验证方法、装置及存储介质，涉及通信技术领域，用于防止外部伪造或模拟报文入侵被隔离***。该方法包括：数据校验端接收来自数据发送端的待验证数据；待验证数据包括：第一状态信息和第一校验信息；数据校验端解析待验证数据，获取第一状态信息和第一校验信息；数据校验端根据第一状态信息，和数据发送端与数据接收端之间的握手协议，生成第二校验信息；数据校验端根据第一校验信息和第二校验信息，验证待验证数据的有效性。本申请的实施例应用于数据校验。
Description
技术领域
本申请涉及通信领域，尤其涉及一种数据验证方法、装置及存储介质。
背景技术
虚拟专用通道(OpenVPN，OPN)提供了企业与企业间或企业与个人间的安全数据传输隧道，是目前使用最为广泛的虚拟专用网络(Virtual Private Net work，VPN)开源框架，为用户提供了良好的体验。通过将OpenVPN中的安全传输层协议(Transport LayerSecurity Protocol，TLS)/安全套接层协议(Se cure Sockets Layer，SSL)协议替换为国密握手协议，可以得到国密OpenVPN。
相关技术中，将服务器部署至企业内网，客户端通过隔离验证模块和隔离芯片将安全***与普通***隔离，并在安全域与企业内网间建立安全传输隧道，这样可以强化网络传输安全，保护企业内网数据。然而，客户端无法验证接收到的待传输数据的有效性，从而造成外部伪造或模拟报文入侵被隔离***的风险。
发明内容
本申请提供了一种数据验证方法、装置及存储介质，用于防止外部伪造或模拟报文入侵被隔离***。
为达到上述目的，本申请采用如下技术方案：
第一方面，本申请提供了一种数据验证方法，应用于数据校验端，方法包括：数据校验端接收来自数据发送端的待验证数据；待验证数据包括：第一状态信息和第一校验信息；第一状态信息为数据发送端与数据接收端当前通信的状态信息；第一校验信息为数据发送端根据数据发送端与数据接收端之间的握手协议，以及第一状态信息生成的校验信息；数据校验端解析待验证数据，获取第一状态信息和第一校验信息；数据校验端根据第一状态信息，和数据发送端与数据接收端之间的握手协议，生成第二校验信息；数据校验端根据第一校验信息和第二校验信息，验证待验证数据的有效性。
结合上述第一方面，在一种可能的实现方式中，该方法还包括：数据发送端与数据接收端之间的通信阶段包括：握手阶段、密钥协商阶段、参数协商及策略推送阶段；在握手阶段，第一状态信息用于指示数据发送端与数据接收端当前握手的次数；在密钥协商阶段，第一状态信息用于指示数据发送端与数据接收端的总握手次数，与当前密钥协商次数之和；在参数协商及策略推送阶段，第一状态信息用于指示数据发送端与数据接收端的总握手次数、密钥协商总次数，以及当前参数协商及策略推送次数之和。
结合上述第一方面，在一种可能的实现方式中，该方法还包括：数据校验端确定第一状态信息的取值，以及数据发送端与数据接收端之间的握手协议中的目标字段；采用SM3算法计算第一状态信息，以及握手协议中的目标字段的哈希值，生成第二校验信息。
结合上述第一方面，在一种可能的实现方式中，该方法还包括：若第一校验信息和第二校验信息一致，则待验证数据有效，数据校验端向数据接收端发送待验证数据；若第一校验信息和第二校验信息不一致，则待验证数据无效，数据校验端删除待验证数据。
第二方面，本申请提供了一种数据验证方法，应用于数据发送端，方法包括：数据发送端确定第一状态信息，第一状态信息为数据发送端与数据接收端当前通信时的状态信息；数据发送端根据数据发送端与数据接收端之间的握手协议，以及第一状态信息生成第一校验信息；数据发送端根据第一状态信息和第一校验信息，生成待验证数据；数据发送端向数据校验端发送待验证数据。
结合上述第二方面，在一种可能的实现方式中，该方法还包括：数据校验端确定第一状态信息的取值，以及数据发送端与数据接收端之间的握手协议中的目标字段；数据校验端采用SM3算法计算第一状态信息，以及握手协议中的目标字段的哈希值，生成第一校验信息。
第三方面，本申请实施例提供了一种数据验证装置，该装置包括：通信单元，用于接收来自数据发送端的待验证数据；待验证数据包括：第一状态信息和第一校验信息；第一状态信息为数据发送端与数据接收端当前通信的状态信息；第一校验信息为数据发送端根据数据发送端与数据接收端之间的握手协议，以及第一状态信息生成的校验信息；处理单元，用于解析待验证数据，获取第一状态信息和第一校验信息；处理单元，还用于根据第一状态信息，和数据发送端与数据接收端之间的握手协议，生成第二校验信息；处理单元，还用于根据第一校验信息和第二校验信息，验证待验证数据的有效性。
结合上述第三方面，在一种可能的实现方式中，该装置还包括：数据发送端与数据接收端之间的通信阶段包括：握手阶段、密钥协商阶段、参数协商及策略推送阶段；在握手阶段，第一状态信息用于指示数据发送端与数据接收端当前握手的次数；在密钥协商阶段，第一状态信息用于指示数据发送端与数据接收端的总握手次数，与当前密钥协商次数之和；在参数协商及策略推送阶段，第一状态信息用于指示数据发送端与数据接收端的总握手次数、密钥协商总次数，以及当前参数协商及策略推送次数之和。
结合上述第三方面，在一种可能的实现方式中，该装置还包括：处理单元，还用于确定第一状态信息的取值，以及数据发送端与数据接收端之间的握手协议中的目标字段；采用SM3算法计算第一状态信息，以及握手协议中的目标字段的哈希值，生成第二校验信息。
结合上述第三方面，在一种可能的实现方式中，该装置还包括：处理单元，还用于若第一校验信息和第二校验信息一致，则待验证数据有效，数据校验端向数据接收端发送待验证数据；若第一校验信息和第二校验信息不一致，则待验证数据无效，数据校验端删除待验证数据。
第四方面，本申请实施例提供了一种数据验证装置，该装置包括：处理单元，用于确定第一状态信息，第一状态信息为数据发送端与数据接收端当前通信时的状态信息；处理单元，还用于根据数据发送端与数据接收端之间的握手协议，以及第一状态信息生成第一校验信息；处理单元，还用于根据第一状态信息和第一校验信息，生成待验证数据；通信单元，用于向数据校验端发送待验证数据。
结合上述第四方面，在一种可能的实现方式中，该装置还包括：处理单元，还用于确定第一状态信息的取值，以及数据发送端与数据接收端之间的握手协议中的目标字段；采用SM3算法计算第一状态信息，以及握手协议中的目标字段的哈希值，生成第一校验信息。
第五方面，本申请实施例提供了一种数据验证装置，该数据验证装置包括：处理器以及存储器；其中，存储器用于存储计算机执行指令，当数据验证装置运行时，处理器执行存储器存储的计算机执行指令，以使数据验证装置执行如第一方面和第二方面的任一种可能的实现方式中描述的数据验证方法。
第六方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当计算机可读存储介质中的指令由数据验证装置的处理器执行时，使得数据验证装置能够执行如第一方面和第二方面的任一种可能的实现方式中描述的数据验证方法。
在本公开中，上述数据验证装置的名字对设备或功能模块本身不构成限定，在实际实现中，这些设备或功能模块可以以其他名称出现。只要各个设备或功能模块的功能和本公开类似，属于本公开权利要求及其等同技术的范围之内。
本申请的这些方面或其他方面在以下的描述中会更加简明易懂。
上述方案至少带来以下有益效果：在本申请实施例中，数据校验端接收来自数据发送端的待验证数据。由于待验证数据包括：第一状态信息和第一校验信息，第一校验信息为数据发送端根据数据发送端与数据接收端之间的握手协议，以及第一状态信息生成的校验信息。这样一来，在数据校验端解析待验证数据之后，可以根据第一状态信息，和数据发送端与数据接收端之间的握手协议，生成第二校验信息；进而根据第一校验信息和第二校验信息是否一致，来验证待验证数据的有效性。若第一校验信息和第二校验信息一致，则待验证数据是发送端发送的，则待验证数据有效；若第一校验信息和第二校验信息不一致，则待验证数据不是发送端发送的，则验证数据无效。客户端的隔离***根据待验证数据的有效性，选择性的接收待验证数据，从而避免外部伪造或模拟报文入侵被隔离***。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种数据验证装置的结构示意图；
图2为本申请实施例提供的一种数据验证方法的流程示意图；
图3为本申请实施例提供的又一种数据验证方法的流程示意图；
图4为本申请实施例提供的又一种数据验证方法的流程示意图；
图5为本申请实施例提供的一种数据验证方法的流程示意图；
图6为本申请实施例提供的又一种数据验证方法的流程示意图；
图7为本申请实施例提供的又一种数据验证方法的流程示意图；
图8为本申请实施例提供的又一种数据验证方法的流程示意图；
图9为本申请实施例提供的一种数据验证***的示意图；
图10为本申请实施例提供的一种数据验证装置的结构示意图；
图11为本申请实施例提供的又一种数据验证装置的结构示意图。
具体实施方式
本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
本申请的说明书以及附图中的术语“第一”和“第二”等是用于区别不同的对象，或者用于区别对同一对象的不同处理，而不是用于描述对象的特定顺序。
此外，本申请的描述中所提到的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、***、产品或设备没有限定于已列出的步骤或单元，而是可选的还包括其他没有列出的步骤或单元，或可选的还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
需要说明的是，本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
在本申请的描述中，除非另有说明，“多个”的含义是指两个或两个以上。
本申请实施例的技术方案可用于各种通信***，该通信***可以为第三代合作伙伴计划(third generation partnership project，3GPP)通信***，例如，长期演进(longterm evolution，LTE)***，又可以为5G移动通信***、NR***、新空口车联网(vehicle toeverything，NR V2X)***，还可以应用于LTE和5G混合组网的***中，或者设备到设备(device-to-device，D2D)通信***、机器到机器(machine to machine，M2M)通信***、物联网(Internet of Things，IoT)，以及其他下一代通信***，也可以为非3GPP通信***，不予限制。
本申请实施例的技术方案可以应用于各种通信场景，例如可以应用于以下通信场景中的一种或多种：增强移动宽带(enhanced mobile broadband，eMBB)、超可靠低时延通信(ultra reliable low latency communication，URLLC)、机器类型通信(machine typecommunication，MTC)、大规模机器类型通信(massive machine type communications，mMTC)、SA、D2D、V2X、和IoT等通信场景。
其中，上述适用本申请的通信***和通信场景仅是举例说明，适用本申请的通信***和通信场景不限于此，在此统一说明，以下不再赘述。
在一些实施例中，本申请涉及的终端设备可以是用于实现通信功能的设备。终端设备也可以称为用户设备(user equipment，UE)、终端、接入终端、用户单元、用户站、移动站(mobile station，MS)、远方站、远程终端、移动终端(mobile terminal，MT)、用户终端、无线通信设备、用户代理或用户装置等。终端设备例如可以是IoT、V2X、D2D、M2M、5G网络、或者未来演进的公共陆地移动网络(public land mobile network，PLMN)中的无线终端或有线终端。无线终端可以是指一种具有无线收发功能的设备，可以部署在陆地上，包括室内或室外、手持或车载；也可以部署在水面上(如轮船等)；还可以部署在空中(例如飞机、气球和卫星上等)。
示例性的，终端设备可以是无人机、IoT设备(例如，传感器，电表，水表等)、V2X设备、无线局域网(wireless local area networks，WLAN)中的站点(station，ST)、蜂窝电话、无绳电话、会话启动协议(session initiation protocol，SIP)电话、无线本地环路(wireless local loop，WLL)站、个人数字处理(personal digital assistant，PDA)设备、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备(也可以称为穿戴式智能设备)、平板电脑或带无线收发功能的电脑、虚拟现实(virtual reality，VR)终端、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端、车载终端、具有车对车(vehicle-to-vehicle，V2V)通信能力的车辆、智能网联车、具有无人机对无人机(UAV toUAV，U2U)通信能力的无人机等等。终端可以是移动的，也可以是固定的，本申请对此不作具体限定。
为了实现本申请实施例提供的数据验证方法，本申请实施例提供了一种数据验证装置，用于执行本申请实施例提供的数据验证方法，图1为本申请实施例提供的一种数据验证装置的结构示意图。如图1所示，该数据验证装置100包括至少一个处理器101，通信线路102，以及至少一个通信接口104，还可以包括存储器103。其中，处理器101，存储器103以及通信接口104三者之间可以通过通信线路102连接。
处理器101可以是一个中央处理器(central processing unit，CPU)，也可以是特定集成电路(application specific integrated circuit，ASIC)，或者是被配置成实施本申请实施例的一个或多个集成电路，例如：一个或多个数字信号处理器(digital signalprocessor，DSP)，或，一个或者多个现场可编程门阵列(field programmable gate array，FPGA)。
通信线路102可以包括一通路，用于在上述组件之间传送信息。
通信接口104，用于与其他设备或通信网络通信，可以使用任何收发器一类的装置，如以太网，无线接入网(radio access network，RAN)，WLAN等。
存储器103可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于包括或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。
一种可能的设计中，存储器103可以独立于处理器101存在，即存储器103可以为处理器101外部的存储器，此时，存储器103可以通过通信线路102与处理器101相连接，用于存储执行指令或者应用程序代码，并由处理器101来控制执行，实现本申请下述实施例提供的数据验证方法。又一种可能的设计中，存储器103也可以和处理器101集成在一起，即存储器103可以为处理器101的内部存储器，例如，该存储器103为高速缓存，可以用于暂存一些数据和指令信息等。
作为一种可实现方式，处理器101可以包括一个或多个CPU，例如图1中的CPU0和CPU1。作为另一种可实现方式，数据验证装置100可以包括多个处理器，例如图1中的处理器101和处理器107。作为再一种可实现方式，数据验证装置100还可以包括输出设备105和输入设备106。
以下，对本申请涉及到的名词进行解释。
1、国密OpenVPN建立连接流程
如图2所示，国密OpenVPN建立连接流程分为四个阶段，分别是阶段一：OpenVPN连接初始化阶段、阶段二：国密协议握手阶段、阶段三：OpenVPN密钥协商阶段、阶段四：OpenVPN参数协商以及OpenVPN策略协商阶段。
阶段一、数据发送端接收数据接收端发送的初始化请求消息，数据发送端为新连接的数据接收端所属的客户端初始化。
阶段二、数据接收端和数据发送端互相验证身份合法性，并为OpenVPN密钥协商建立安全的加密通道。
阶段三、数据接收端和数据发送端在加密通道上进行密钥协商，得到OpenVPN。通过OpenVPN记录协议所使用的加密密钥和MAC密钥。
阶段四、通过OpenVPN记录协议协商两端参数以及数据发送端向数据接收端推送的配置策略。
以上对本申请涉及的名词进行了解释，下面对本申请提供的数据验证传输方法进行说明。
现有技术中，将服务器部署至企业内网，客户端通过隔离验证模块和隔离芯片将安全***与普通***隔离，并在安全域与企业内网间建立安全传输隧道，这样可以强化网络传输安全，保护企业内网数据。然而，客户端无法验证接收到的待传输数据的有效性，从而造成外部伪造或模拟报文入侵被隔离***的风险。
为了解决相关技术中存在的技术问题，在本申请实施例中，数据校验端接收来自数据发送端的待验证数据。由于待验证数据包括：第一状态信息和第一校验信息，第一校验信息为数据发送端根据数据发送端与数据接收端之间的握手协议，以及第一状态信息生成的校验信息。这样一来，在数据校验端解析待验证数据之后，可以根据第一状态信息，和数据发送端与数据接收端之间的握手协议，生成第二校验信息；进而根据第一校验信息和第二校验信息是否一致，来验证待验证数据的有效性。若第一校验信息和第二校验信息一致，则待验证数据是发送端发送的，则待验证数据有效；若第一校验信息和第二校验信息不一致，则待验证数据不是发送端发送的，则验证数据无效。客户端的隔离***根据待验证数据的有效性，选择性的接收待验证数据，从而避免外部伪造或模拟报文入侵被隔离***。
以下，结合图3对本申请实施例提供的数据验证方法进行详细说明，如图3所示，该数据验证方法包括：
S301、数据发送端确定第一状态信息。
其中，第一状态信息为数据发送端与数据接收端当前通信的状态信息。
可选的，数据发送端为业务服务器，数据接收端为客户端中安全***的业务应用。安全***包括：至少一个业务应用和数据检验端。其中，数据检验端用于验证数据的有效性，保证客户端中安全***的安全性。
一种可能的实现方式中，在握手阶段，第一状态信息用于指示数据发送端与数据接收端当前握手的次数；在密钥协商阶段，第一状态信息用于指示数据发送端与数据接收端的总握手次数，与当前密钥协商次数之和；在参数协商及策略推送阶段，第一状态信息用于指示数据发送端与数据接收端的总握手次数、密钥协商总次数，以及当前参数协商及策略推送次数之和。
S302、数据发送端根据数据发送端与数据接收端之间的握手协议，以及第一状态信息生成第一校验信息。
可选的，数据发送端与数据接收端之间的握手协议为TLS Record La yer层的Handshake Protocol。
S303、数据发送端向数据校验端发送待验证数据。相应的，数据校验端接收来自数据发送端的待验证数据。
其中，待验证数据包括：第一状态信息和第一校验信息。
S304、数据校验端解析待验证数据，获取第一状态信息和第一校验信息。
一种可能的实现方式中，数据校验端从解析的数据中，选取第一状态信息和第一校验信息。
S305、数据校验端根据第一状态信息，和数据发送端与数据接收端之间的握手协议，生成第二校验信息。
一种可能的实现方式中，在握手阶段，数据发送端与数据接收端之间的握手协议为TLS Record Layer层的Handshake Protocol。
另一种可能的实现方式中，在密钥协商阶段、参数协商阶段及策略推送阶段，数据发送端与数据接收端之间的握手协议为TLS Record Layer层的Encrypted ApplicationData。
S306、数据校验端根据第一校验信息和第二校验信息，验证待验证数据的有效性。
一种可能的实现方式中，数据校验端通过对第一校验信息和第二校验信息进行对比，在对比结果符合预设条件的情况下，确定待验证数据有效。在对比结果不符合预设条件的情况下，确定待验证数据无效。
上述方案至少带来以下有益效果：在本申请实施例中，数据校验端接收来自数据发送端的待验证数据。由于待验证数据包括：第一状态信息和第一校验信息，第一校验信息为数据发送端根据数据发送端与数据接收端之间的握手协议，以及第一状态信息生成的校验信息。这样一来，在数据校验端解析待验证数据之后，可以根据第一状态信息，和数据发送端与数据接收端之间的握手协议，生成第二校验信息；进而根据第一校验信息和第二校验信息是否一致，来验证待验证数据的有效性。若第一校验信息和第二校验信息一致，则待验证数据是发送端发送的，则待验证数据有效；若第一校验信息和第二校验信息不一致，则待验证数据不是发送端发送的，则验证数据无效。客户端的隔离***根据待验证数据的有效性，选择性的接收待验证数据，从而避免外部伪造或模拟报文入侵被隔离***。
结合图3，如图4所示，上述数据发送端根据数据发送端与数据接收端之间的握手协议，以及第一状态信息生成第一校验信息的过程具体可以通过以下S401-S402实现。
S401、数据发送端确定第一状态信息的取值，以及数据发送端与数据接收端之间的握手协议中的目标字段。
可选的，第一状态信息的取值的初始值为0，第一状态信息的取值的最大值为63。
需要解释的是，在握手阶段，数据发送端与数据接收端当前握手的次数大于63，则数据发送端与数据接收端之间的握手次数重置；在密钥协商阶段或参数协商及策略推送阶段，数据发送端与数据接收端的总握手次数，与当前传输次数之和大于63，则数据发送端与数据接收端当前握手重新握手。
S402、数据发送端采用SM3算法计算第一状态信息，以及握手协议中的目标字段的哈希值，生成第一校验信息。
一种可能的实现方式中，TLS Record Layer层的Handshake Protocol部分使用SM3计算其Hash(32)值，具体为：Validity_hash＝hash_sm3(Seq_num||HandshakeProtocol)，其中Seq_num为第一状态信息。
另一种可能的实现方式中，TLS Record Layer层的Encrypted Applic ationData部分使用SM3计算其Hash(32)值，具体为：Validity_hash＝hash_sm3(Seq_num+Encrypted Application Data)。
上述方案至少带来以下有益效果：本申请实施例中，数据发送端采用SM3算法计算第一状态信息，以及握手协议中的目标字段的哈希值，这样一来，可以准确地生成第一校验信息。从而数据发送端可以向数据校验端发送准确的待校验数据。
结合图3，如图5所示，上述数据校验端根据第一状态信息，和数据发送端与数据接收端之间的握手协议，生成第二校验信息的过程具体可以通过以下S501-S502实现。
S501、数据校验端确定第一状态信息的取值，以及数据发送端与数据接收端之间的握手协议中的目标字段。
可选的，握手协议中的目标字段为：TLS Record Layer层的Encrypte dApplication Data的部分字段或者TLS Record Layer层的Handshake Pr otocol的部分字段。
S502、数据校验端采用SM3算法计算第一状态信息，以及握手协议中的目标字段的哈希值，生成第二校验信息。
一种可能的实现方式中，TLS Record Layer层的Handshake Protocol部分使用SM3计算其Hash(32)值，具体为：Validity_hash＝hash_sm3(Seq_num||HandshakeProtocol)，其中Seq_num为第一状态信息。
另一种可能的实现方式中，TLS Record Layer层的Encrypted Applic ationData部分使用SM3计算其Hash(32)值，具体为：Validity_hash＝hash_sm3(Seq_num+Encrypted Application Data)。
上述方案至少带来以下有益效果：本申请实施例中，数据发送端采用SM3算法计算第一状态信息，以及握手协议中的目标字段的哈希值，生成第二校验信息。这样一来，可以生成第二校验信息采用的内容和算法与生成第一校验信息采用的内容和算法一致，进而可以根据第一校验信息和第二校验信息是否一致，来验证待验证数据的有效性。若第一校验信息和第二校验信息一致，则待验证数据是发送端发送的，则待验证数据有效；若第一校验信息和第二校验信息不一致，则待验证数据不是发送端发送的，则验证数据无效。
一种可能的实现方式中，在上述S306之后，数据校验端根据有效性的验证结果，确定是否向数据接收端发送待验证数据。以下，对数据校验端确定是否向数据接收端发送待验证数据的过程进行介绍。
结合图3，如图6所示，上述数据校验端确定是否向数据接收端发送待验证数据的过程具体可以通过以下S601-S602实现。
S601、若第一校验信息和第二校验信息一致，则待验证数据有效，数据校验端向数据接收端发送待验证数据。
S602、若第一校验信息和第二校验信息不一致，则待验证数据无效，数据校验端删除待验证数据。
上述方案至少带来以下有益效果：本申请实施例中，若第一校验信息和第二校验信息一致，则待验证数据有效，数据校验端向数据接收端发送待验证数据，这样一来，实现了国密OpenVPN在“双***”传输。若第一校验信息和第二校验信息一致，则说明待验证数据是发送端发送的，此时待验证数据有效；若第一校验信息和第二校验信息不一致，则说明待验证数据不是发送端发送的，待验证数据可能是外部伪造的，此时待验证数据无效，数据校验端删除待验证数据。这样一来，可以避免无数的待验证数据进入数据接收端，有效地防止了外部伪造或模拟报文入侵数据接收端。
一种可能的实现方式中，数据发送端、数据接收端，以及数据校验端之间交互的过程包括(1)握手阶段，(2)密钥协商阶段(3)参数协商及策略推送阶段。以下，以数据发送端、数据接收端，以及数据校验端之间通过国密OpenVPN进行交互为例，对握手阶段，密钥协商阶段参数协商及策略推送阶段的交互过程进行详细说明。
(1)握手阶段
结合图3，如图7所示，数据发送端、数据接收端，以及数据校验端之间在握手阶段通过国密OpenVPN进行交互的过程具体可以通过以下S701-S726实现。
S701、数据接收端向数据发送端发送第一请求信息。相应的，数据发送端接收第一请求信息。
其中，第一请求信息用于请求加密通信。
一种可能的实现方式中，第一请求信息为Client Hello。
S702、数据发送端根据第一信息生成第一消息体，并根据第一消息体、第二状态信息以及第二校验信息生成第二待验证数据。其中，消息体为用于存储映射客观实体的静止和运动信息的人机信息集合。
其中，第一信息包括以下至少一项：SSL版本号、随机数、加密算法。
S703、数据发送端向数据校验端发送第二待验证数据。相应的，数据校验端接收第二待验证数据。
可选的，第二待验证数据为Server Hello。
示例性的，Server Hello的协议结构为：
S704、数据校验端对第二待验证数据进行校验。
需要说明的是，若第二待验证数据通过验证，则第二待验证数据有效，数据校验端向数据接收端发送第二待验证数据；若第二待验证数据未通过验证，则第二待验证数据无效，数据校验端删除第二待验证数据。
S705、数据发送端根据第二信息生成第二消息体，并根据第二消息体、第三状态信息以及第三校验信息生成第三待验证数据。
其中，第二信息包括以下至少一项：签名证书、加密证书。
S706、数据发送端向数据校验端发送第三待验证数据。相应的，数据校验端接收第三待验证数据。
可选的，第三待验证数据为Certificate。
S707、数据校验端对第三待验证数据进行校验。
需要说明的是，若第三待验证数据通过验证，则第三待验证数据有效，数据校验端向数据接收端发送第三待验证数据；若第三待验证数据未通过验证，则第三待验证数据无效，数据校验端删除第三待验证数据。
S708、数据发送端根据第三信息生成第三消息体，并根据第三消息体、第四状态信息以及第四校验信息生成第四待验证数据。
其中，第三信息包括以下至少一项：密钥交换算法所需要的额外参数。
S709、数据发送端向数据校验端发送第四待验证数据。相应的，数据校验端接收第四待验证数据。
可选的，第四待验证数据为Server Key Exchange。
S710、数据校验端对第四待验证数据进行校验。
需要说明的是，若第四待验证数据通过验证，则第四待验证数据有效，数据校验端向数据接收端发送第四待验证数据；若第四待验证数据未通过验证，则第四待验证数据无效，数据校验端删除第四待验证数据。
S711、数据发送端根据第四信息生成第四消息体，并根据第四消息体、第五状态信息以及第五校验信息生成第五待验证数据。
其中，第四信息包括以下至少一项：要求数据接收上报的证书。
S712、数据发送端向数据校验端发送第五待验证数据。相应的，数据校验端接收第五待验证数据。
可选的，第五待验证数据为Certificate Request。
S713、数据校验端对第五待验证数据进行校验。
需要说明的是，若第五待验证数据通过验证，则第五待验证数据有效，数据校验端向数据接收端发送第五待验证数据；若第五待验证数据未通过验证，则第五待验证数据无效，数据校验端删除第五待验证数据。
S714、数据发送端根据第五信息生成第五消息体，并根据第五消息体、第六状态信息以及第六校验信息生成第六待验证数据。
其中，第五信息用于通知数据接收端已发送完此阶段全部信息。
S715、数据发送端向数据校验端发送第六待验证数据。相应的，数据校验端接收第六待验证数据。
可选的，第六待验证数据为Server Hello Done。
S716、数据校验端对第六待验证数据进行校验。
需要说明的是，若第六待验证数据通过验证，则第六待验证数据有效，数据校验端向数据接收端发送第六待验证数据；若第六待验证数据未通过验证，则第六待验证数据无效，数据校验端删除第六待验证数据。
S717、数据接收端向数据发送端发送第二待验证数据。
可选的，第二待验证数据还包括携带自己公钥的证书。
一种可能的实现方式中，数据接收端通过Certificate消息将携带自己公钥的证书发送给数据发送端。
S718、数据接收端向数据发送端发送第三待验证数据。
可选的，第三待验证数据还包括协商后的密钥。
S719、数据接收端向数据发送端发送测试信息。
其中，测试信息为Change Cipher Spec。
可选的，测试信息用于指示将协商好的密钥和加密套件进行加密和MAC计算。
S720、数据接收端向数据发送端发送指示信息。
其中，指示信息用于指示发送测试信息已完成。
可选的，指示信息为Finished。
一种可能的实现方式中，数据接收端计算已交互的握手信息(除Cha nge CipherSpec消息外全部已交互的信息)的Hash值，利用协商好的密钥和加密套件处理Hash值(计算并加入MAC值、加密)，并通过Finish ed消息发送给数据发送端。
S721、数据发送端根据第六信息生成第六消息体，并根据第六消息体、第七状态信息以及第七校验信息生成第七待验证数据。
其中，第六信息用于通知数据接收端已使用密钥加密。
一种可能的实现方式中，数据发送端利用相同的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，若二者相同，且MAC值验证成功，则密钥和加密套件协商成功。
S722、数据发送端向数据校验端发送第七待验证数据。相应的，数据校验端接收第七待验证数据。
可选的，第七待验证数据为Change Cipher Spec。
可选的，第七待验证数据用于指示数据校验端将协商好的密钥和加密套件进行加密和MAC计算。
S723、数据校验端对第七待验证数据进行校验。
需要说明的是，若第七待验证数据通过验证，则第七待验证数据有效，数据校验端向数据接收端发送第七待验证数据；若第七待验证数据未通过验证，则第七待验证数据无效，数据校验端删除第七待验证数据。
S724、数据发送端根据第七信息生成第七消息体，并根据第七消息体、第八状态信息以及第八校验信息生成第八待验证数据。
其中，第七信息用于通知数据接收端已发送完此阶段全部信息。
S725、数据发送端向数据校验端发送第八待验证数据。相应的，数据校验端接收第八待验证数据。
可选的，第八待验证数据为Finished。
S726、数据校验端对第八待验证数据进行校验。
需要说明的是，若第八待验证数据通过验证，则第八待验证数据有效，数据校验端向数据接收端发送第八待验证数据；若第八待验证数据未通过验证，则第八待验证数据无效，数据校验端删除第八待验证数据。
国密SSL VPN握手的协议结构如下：
其中，Content Type为记录层协议类型。例如，当使用国密算法时，type为GMTLS；
示例性的，层协议类型为：enum{
change_cipher_spec(20)，alert(21)，handshake(22)，application_data(23)，site2site(80)，(255)
}ContentType；
Version为协议的版本，length为单位的片段长度；
Handshake Protocol为握手协议消息体；
示例性的，握手协议消息体为：enum{
ClientHello，ServerHello，Certificate，ServerKeyExchange，CertificateRequest，
ServerHelloDone，CertificateVerify,ClientKeyExchange，Finished
}Handshake。
上述方案至少带来以下有益效果：本申请实施例在数据发送端与数据接收端握手的整个过程中，每次握手时数据发送端均会确定状态信息和校验信息，并将包含有状态信息和校验信息的待验证数据，发送给数据校验端。这样一来，数据发送端与数据接收端每次握手时，数据校验端均会校验待验证数据，提高数据发送端与数据接收端握手的安全性。
(2)密钥协商阶段
结合图3，如图8所示，数据发送端、数据接收端，以及数据校验端之间在密钥协商阶段通过国密OpenVPN进行交互的过程具体可以通过以下S801-S804实现。
S801、数据接收端向数据发送端发送第二请求信息。相应的，数据发送端接收第二请求信息。
其中，第二请求信息用于请求目标信息。
S802、数据发送端根据第二请求信息、第九状态信息以及第九校验信息生成第九待验证数据，并向数据校验端发送第九待验证数据。相应的，数据校验端接收第九待验证数据。
其中，S802的具体实现方式可以参照上述S302，此处不再赘述。
S803、数据校验端对第九待验证数据进行校验。
其中，S803的具体实现方式可以参照上述S303，此处不再赘述。
S804、若第九待验证数据通过验证，则数据校验端向数据接收端发送第九待验证数据。
国密SSL VPN协商的协议结构如下：
字段说明：
Type为记录层协议类型；Protocol Version协议的版本，此处使用国密算法，Type为GMTLS；
length为单位的片段长度；
fragment为传输的数据。
示例性的，记录层协议类型：enum{
change_cipher_spec(20)，alert(21),handshake(22)，application_data(23)，site2site(80)，(255)
}ContentType。
示例性的，OpenVPN密钥协商阶段的协议结构为：
上述方案至少带来以下有益效果：本申请实施例在数据发送端与数据接收端在密钥协商阶段的整个过程中，每次密钥协商时数据发送端均会确定状态信息和校验信息，并将包含有状态信息和校验信息的待验证数据，发送给数据校验端。这样一来，数据发送端与数据接收端每次密钥协商时，数据校验端均会校验待验证数据，提高数据发送端与数据接收端之间密钥协商的安全性。
需要指出的是，阶段四为OpenVPN参数协商以及OpenVPN策略协商；阶段三为OpenVPN密钥协商。阶段四通过国密OpenVPN进行交互的过程与阶段三通过国密OpenVPN进行交互的过程相同，本申请对此不在赘述。
以上对申请实施例提供了数据验证方法进行了介绍，下面对本申请提供的数据验证***进行说明。
以下，结合附图9对本申请实施例提供的另一种数据验证***进行详细说明，如图9所示，该数据验证***包括：数据接收端901、数据发送端902。
其中，数据接收端包括安全***9011和Android***9012以及安全芯片9013。安全***9011包括业务应用9014、内外数据传输模块9015以及数据校验端9016。数据接收端901为客户端，数据校验端9016为VP N协议检验增强模块。
安全***9011，被配置为：接收并处理企业内网发送的待检测数据。
Android***9012，被配置为：接收并处理用户的非隐私信息。
安全芯片9013，被配置为：隔离安全***和Android***，提高用户传输数据的安全性。
业务应用9014，被配置为：处理企业内网发送的有效的待检测数据，并针对有效的待检测数据，显示不同的客户端功能。
内外数据传输模块9015，被配置为：实现内外侧数据的通用转发。
数据校验端9016，被配置为：对待检测数据进行校验，若待验证数据有效，则数据校验端9016通过内外数据传输模块9015向至少一个业务应用9014发送待验证数据；若待验证数据无效，则删除待验证数据。
数据发送端902包括安全接入网关模块9021和业务服务器9022。
安全接入网关9021，被配置为：部署在企业内网环境，实现对特定应用与服务的加密保护。
业务服务器9022，被配置为：生成带有第一状态信息和第一校验信息的待验证数据。
可以看出，上述主要从方法的角度对本申请实施例提供的技术方案进行了介绍。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
本申请实施例可以根据上述方法示例对数据验证装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。可选的，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
如图10所示，为本申请实施例提供的一种数据验证装置100的结构示意图。该数据验证装置100包括：通信单元1001和处理单元1002。
通信单元1001，用于接收来自数据发送端的待验证数据；待验证数据包括：第一状态信息和第一校验信息；第一状态信息为数据发送端与数据接收端当前通信的状态信息；第一校验信息为数据发送端根据数据发送端与数据接收端之间的握手协议，以及第一状态信息生成的校验信息；处理单元1002，用于解析待验证数据，获取第一状态信息和第一校验信息；处理单元1002，还用于根据第一状态信息，和数据发送端与数据接收端之间的握手协议，生成第二校验信息；处理单元1002，还用于根据第一校验信息和第二校验信息，验证待验证数据的有效性。
可选的，数据发送端与数据接收端之间的通信阶段包括：握手阶段、密钥协商阶段、参数协商及策略推送阶段；在握手阶段，第一状态信息用于指示数据发送端与数据接收端当前握手的次数；在密钥协商阶段，第一状态信息用于指示数据发送端与数据接收端的总握手次数，与当前密钥协商次数之和；在参数协商及策略推送阶段，第一状态信息用于指示数据发送端与数据接收端的总握手次数、密钥协商总次数，以及当前参数协商及策略推送次数之和。
可选的，处理单元1002，还用于确定第一状态信息的取值，以及数据发送端与数据接收端之间的握手协议中的目标字段；采用SM3算法计算第一状态信息，以及握手协议中的目标字段的哈希值，生成第二校验信息。
可选的，处理单元1002，还用于若第一校验信息和第二校验信息一致，则待验证数据有效，数据校验端向数据接收端发送待验证数据；若第一校验信息和第二校验信息不一致，则待验证数据无效，数据校验端删除待验证数据。
如图11所示，为本申请实施例提供的一种数据验证装置110的结构示意图。该数据验证装置110包括：通信单元1101和处理单元1102。
处理单元1102，用于确定第一状态信息，第一状态信息为数据发送端与数据接收端当前通信时的状态信息；处理单元1102，还用于根据数据发送端与数据接收端之间的握手协议，以及第一状态信息生成第一校验信息；处理单元1102，还用于根据第一状态信息和第一校验信息，生成待验证数据；通信单元1101，用于向数据校验端发送待验证数据。
可选的，处理单元1102，还用于确定第一状态信息的取值，以及数据发送端与数据接收端之间的握手协议中的目标字段；采用SM3算法计算第一状态信息，以及握手协议中的目标字段的哈希值，生成第一校验信息。
其中，处理单元1002或处理单元1102可以是处理器或控制器。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包括一个或多个微处理器组合，DSP和微处理器的组合等等。通信单元1001或通信单元1101可以是收发电路或通信接口等。存储模块可以是存储器。当处理单元为处理器，通信单元为通信接口，存储模块为存储器时，本申请实施例所涉及的数据验证装置可以为图1所示数据验证装置。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将网络节点的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的***，模块和网络节点的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当计算机执行该指令时，该计算机执行上述方法实施例所示的方法流程中的各个步骤。
本申请实施例还提供一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行计算机程序或指令，以实现上述方法实施例中的数据验证方法。
本申请的实施例提供一种包含指令的计算机程序产品，当指令在计算机上运行时，使得计算机执行上述方法实施例中的数据验证方法。
其中，计算机可读存储介质，例如可以是但不限于电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘。随机存取存储器(Random Access Memory，RAM)、只读存储器(Read-Only Memory，ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、寄存器、硬盘、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的人以合适的组合、或者本领域数值的任何其他形式的计算机可读存储介质。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于特定用途集成电路(Application Specific Integrated Circuit，ASIC)中。在本发明实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。
由于本发明的实施例中的装置、设备、计算机可读存储介质、计算机程序产品可以应用于上述方法，因此，其所能获得的技术效果也可参考上述方法实施例，本申请实施例在此不再赘述。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。
Claims (12)
1.一种数据验证方法，其特征在于，应用于数据校验端，所述数据校验端用于校验数据发送端和数据接收端之间的数据，所述方法包括：
接收来自数据发送端的待验证数据；所述待验证数据包括：第一状态信息和第一校验信息；所述第一状态信息为所述数据发送端与所述数据接收端当前通信的状态信息；所述第一校验信息为所述数据发送端根据所述数据发送端与所述数据接收端之间的握手协议，以及所述第一状态信息生成的校验信息；
解析待验证数据，获取所述第一状态信息和所述第一校验信息；
根据所述第一状态信息，和所述数据发送端与数据接收端之间的握手协议，生成第二校验信息；
根据所述第一校验信息和所述第二校验信息，验证所述待验证数据的有效性；
所述数据发送端与所述数据接收端之间的通信阶段包括：握手阶段、密钥协商阶段、参数协商及策略推送阶段；
在握手阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端当前握手的次数；
在密钥协商阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端的总握手次数，与当前密钥协商次数之和；
在参数协商及策略推送阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端的总握手次数、所述密钥协商总次数，以及当前参数协商及策略推送次数之和。
2.根据权利要求1所述的方法，其特征在于，所述根据所述第一状态信息，和所述数据发送端与数据接收端之间的握手协议，生成第二校验信息，包括：
确定所述第一状态信息的取值，以及所述数据发送端与数据接收端之间的握手协议中的目标字段；
采用SM3算法计算所述第一状态信息，以及所述握手协议中的目标字段的哈希值，生成所述第二校验信息。
3.根据权利要求1所述的方法，其特征在于，所述方法还包括：
若所述第一校验信息和所述第二校验信息一致，则所述待验证数据有效，所述数据校验端向所述数据接收端发送所述待验证数据；
若所述第一校验信息和所述第二校验信息不一致，则所述待验证数据无效，所述数据校验端删除所述待验证数据。
4.一种数据验证方法，其特征在于，所述方法应用于数据发送端，所述方法包括：
确定第一状态信息，所述第一状态信息为所述数据发送端与数据接收端当前通信时的状态信息；
根据所述数据发送端与所述数据接收端之间的握手协议，以及所述第一状态信息生成第一校验信息；
根据所述第一状态信息和所述第一校验信息，生成待验证数据；
向数据校验端发送所述待验证数据；
所述数据发送端与所述数据接收端之间的通信阶段包括：握手阶段、密钥协商阶段、参数协商及策略推送阶段；
在握手阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端当前握手的次数；
在密钥协商阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端的总握手次数，与当前密钥协商次数之和；
在参数协商及策略推送阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端的总握手次数、所述密钥协商总次数，以及当前参数协商及策略推送次数之和。
5.根据权利要求4所述的方法，其特征在于，根据所述数据发送端与所述数据接收端之间的握手协议，以及所述第一状态信息生成第一校验信息，包括：
确定所述第一状态信息的取值，以及所述数据发送端与数据接收端之间的握手协议中的目标字段；
采用SM3算法计算所述第一状态信息，以及所述握手协议中的目标字段的哈希值，生成所述第一校验信息。
6.一种数据验证装置，其特征在于，所述装置包括，通信单元和处理单元：
所述通信单元，用于接收来自数据发送端的待验证数据；所述待验证数据包括：第一状态信息和第一校验信息；所述第一状态信息为所述数据发送端与数据接收端当前通信的状态信息；所述第一校验信息为所述数据发送端根据所述数据发送端与所述数据接收端之间的握手协议，以及所述第一状态信息生成的校验信息；
所述处理单元，用于解析待验证数据，获取所述第一状态信息和所述第一校验信息；
所述处理单元，还用于根据所述第一状态信息，和所述数据发送端与数据接收端之间的握手协议，生成第二校验信息；
所述处理单元，还用于根据所述第一校验信息和所述第二校验信息，验证所述待验证数据的有效性；
所述数据发送端与所述数据接收端之间的通信阶段包括：握手阶段、密钥协商阶段、参数协商及策略推送阶段；
在握手阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端当前握手的次数；
在密钥协商阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端的总握手次数，与当前密钥协商次数之和；
在参数协商及策略推送阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端的总握手次数、所述密钥协商总次数，以及当前参数协商及策略推送次数之和。
7.根据权利要求6所述的装置，其特征在于，所述装置还包括：
所述处理单元，还用于确定所述第一状态信息的取值，以及所述数据发送端与数据接收端之间的握手协议中的目标字段；采用SM3算法计算所述第一状态信息，以及所述握手协议中的目标字段的哈希值，生成所述第二校验信息。
8.根据权利要求6所述的装置，其特征在于，所述装置还包括：所述处理单元，还用于若所述第一校验信息和所述第二校验信息一致，则所述待验证数据有效，数据校验端向所述数据接收端发送所述待验证数据；若所述第一校验信息和所述第二校验信息不一致，则所述待验证数据无效，所述数据校验端删除所述待验证数据。
9.一种数据验证装置，其特征在于，所述装置包括，通信单元和处理单元：
所述处理单元，用于确定第一状态信息，所述第一状态信息为数据发送端与数据接收端当前通信时的状态信息；
所述处理单元，还用于根据所述数据发送端与所述数据接收端之间的握手协议，以及所述第一状态信息生成第一校验信息；
所述处理单元，还用于根据所述第一状态信息和所述第一校验信息，生成待验证数据；
所述通信单元，用于向数据校验端发送所述待验证数据；
所述数据发送端与所述数据接收端之间的通信阶段包括：握手阶段、密钥协商阶段、参数协商及策略推送阶段；
在握手阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端当前握手的次数；
在密钥协商阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端的总握手次数，与当前密钥协商次数之和；
在参数协商及策略推送阶段，所述第一状态信息用于指示所述数据发送端与所述数据接收端的总握手次数、所述密钥协商总次数，以及当前参数协商及策略推送次数之和。
10.根据权利要求9所述的装置，其特征在于，所述装置还包括：
所述处理单元，还用于确定所述第一状态信息的取值，以及所述数据发送端与数据接收端之间的握手协议中的目标字段；采用SM3算法计算所述第一状态信息，以及所述握手协议中的目标字段的哈希值，生成所述第一校验信息。
11.一种数据验证装置，其特征在于，包括：处理器以及存储器；其中，所述存储器用于存储计算机执行指令，当所述数据验证装置运行时，所述处理器执行所述存储器存储的所述计算机执行指令，以使所述数据验证装置执行权利要求1-3或4-5中任一项所述的数据验证方法。
12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括指令，所述指令当被数据验证装置执行时使所述计算机执行如权利要求1-3或4-5中任一项所述的数据验证方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211414745.3A CN115714681B (zh) | 2022-11-11 | 2022-11-11 | 数据验证方法、装置及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211414745.3A CN115714681B (zh) | 2022-11-11 | 2022-11-11 | 数据验证方法、装置及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115714681A CN115714681A (zh) | 2023-02-24 |
| CN115714681B true CN115714681B (zh) | 2024-05-14 |
Family
ID=85232902
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211414745.3A Active CN115714681B (zh) | 2022-11-11 | 2022-11-11 | 数据验证方法、装置及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115714681B (zh) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106060070A (zh) * | 2016-07-01 | 2016-10-26 | 中国人民解放军国防科学技术大学 | 基于身份密码***的tls握手协议 |
| WO2017045552A1 (zh) * | 2015-09-15 | 2017-03-23 | 阿里巴巴集团控股有限公司 | 一种在ssl或tls通信中加载数字证书的方法和装置 |
| CN108429620A (zh) * | 2018-01-25 | 2018-08-21 | 新华三技术有限公司 | 安全连接的建立方法、***、以及客户端和服务端 |
| WO2019114703A1 (zh) * | 2017-12-15 | 2019-06-20 | 华为技术有限公司 | 一种安全通信的方法、装置和*** |
-
2022
- 2022-11-11 CN CN202211414745.3A patent/CN115714681B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017045552A1 (zh) * | 2015-09-15 | 2017-03-23 | 阿里巴巴集团控股有限公司 | 一种在ssl或tls通信中加载数字证书的方法和装置 |
| CN106060070A (zh) * | 2016-07-01 | 2016-10-26 | 中国人民解放军国防科学技术大学 | 基于身份密码***的tls握手协议 |
| WO2019114703A1 (zh) * | 2017-12-15 | 2019-06-20 | 华为技术有限公司 | 一种安全通信的方法、装置和*** |
| CN108429620A (zh) * | 2018-01-25 | 2018-08-21 | 新华三技术有限公司 | 安全连接的建立方法、***、以及客户端和服务端 |
Non-Patent Citations (1)
| Title |
|---|
| 工业以太网信息安全通信方法的研究与实现;王靖然;《控制工程》;20220523;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115714681A (zh) | 2023-02-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Zhang et al. | Edge computing-based privacy-preserving authentication framework and protocol for 5G-enabled vehicular networks | |
| Cao et al. | Fast authentication and data transfer scheme for massive NB-IoT devices in 3GPP 5G network | |
| US10601594B2 (en) | End-to-end service layer authentication | |
| Qazi et al. | Security protocol using elliptic curve cryptography algorithm for wireless sensor networks | |
| Malik et al. | A survey of key bootstrapping protocols based on public key cryptography in the Internet of Things | |
| Cao et al. | GBAAM: group‐based access authentication for MTC in LTE networks | |
| US10790995B2 (en) | Oracle authentication using multiple memory PUFs | |
| Heer et al. | Security Challenges in the IP-based Internet of Things | |
| CN105530238B (zh) | 用于安全对话建立和数据的加密交换的计算机实现***和方法 | |
| EP3308519B1 (en) | System, apparatus and method for transferring ownership of a device from manufacturer to user using an embedded resource | |
| EP3982590B1 (en) | Security authentication method, configuration method, and related device | |
| CN112514436B (zh) | 发起器和响应器之间的安全的、被认证的通信 | |
| CN105530253B (zh) | 基于CA证书的Restful架构下的无线传感器网络接入认证方法 | |
| KR101688118B1 (ko) | 사물인터넷 환경에서의 보안 통신 장치 및 그 방법 | |
| Tanveer et al. | RUAM-IoD: A robust user authentication mechanism for the Internet of Drones | |
| Limbasiya et al. | Iovcom: Reliable comprehensive communication system for internet of vehicles | |
| CN112602290B (zh) | 一种身份验证方法、装置和可读存储介质 | |
| Srikanth et al. | An efficient Key Agreement and Authentication Scheme (KAAS) with enhanced security control for IIoT systems | |
| WO2023083170A1 (zh) | 密钥生成方法、装置、终端设备及服务器 | |
| Schmitt et al. | Two-way authentication for the internet-of-things | |
| Meshram et al. | SBOOSP for Massive Devices in 5G WSNs Using Conformable Chaotic Maps. | |
| CN115714681B (zh) | 数据验证方法、装置及存储介质 | |
| Zhu et al. | Research on authentication mechanism of cognitive radio networks based on certification authority | |
| Boutalbi et al. | Blockchain-based secure handover for IoT using zero-knowledge proof protocol | |
| CN116318795A (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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |