数据完整性验证方法、装置及存储介质与流程

1.本技术涉及通信技术领域，尤其涉及一种数据完整性验证方法、装置及存储介质。


背景技术：

2.相关技术中，数据发送端采集数据之后，往往需要将数据发送到特定终端中，由特定终端将数据转发或者流转给数据接收端。但是数据接收端接收到数据之后无法验证接收到的数据的数据完整性。进而导致数据接收到无法确定接收到的数据是否为数据发送端发送的原始数据，特定终端在转发过程中是否为数据进行了篡改。因此，数据接收端如何验证接收到的数据的数据完整性成为当前亟待解决的问题。


技术实现要素：

3.本技术提供一种数据完整性验证方法、装置及存储介质，在数据接收端接收到数据之后，验证数据的数据完整性。
4.为达到上述目的，本技术采用如下技术方案：
5.第一方面，本公开提供一种数据完整性验证方法，该方法包括：接收来自数据接收端的第一指示信息；第一指示信息用于指示数据完整性验证服务器divs as查询第一标识对应的数据完整性验证信息，第一标识为数据发送端的数据完整性验证信息在divs as中的存储标识；查询第一标识对应的数据完整性验证信息；向数据接收端发送数据完整性验证信息。
6.结合上述第一方面，在一种可能的实现方式中，第一标识归属于数据发送端向数据接收端发送的目标数据；目标数据包括待验证数据、第一数字签名和第一标识；第一数字签名为根据第一私钥对待验证数据签名后生成的数字签名；第一私钥为数据发送端生成的第一密钥对中的私钥；数据完整性验证信息包括第一公钥，第一公钥为数据发送端生成的第一密钥对中的公钥。
7.结合上述第一方面，在一种可能的实现方式中，该方法还包括：接收来自数据发送端的第二指示信息；第二指示信息用于承载第一数据；第一数据包括第一公钥，数据发送端支持的签名算法集和数据发送端的第一终端信息；根据第二指示信息中的第一终端信息，获取数据发送端的签约信息；签约信息包括：数据发送端的签约有效性信息；根据第一数据和签约信息，确定数据完整性验证信息；将数据完整性验证信息存储在区块链中。
8.结合上述第一方面，在一种可能的实现方式中，根据第一终端信息，获取数据发送端的签约信息，包括：向能力开放平台nef发送签约信息获取请求；签约信息获取请求中包括第一终端信息；接收来自nef的签约信息；签约信息为nef返回的根据第一终端信息在用户数据管理网元udm中获取的数据发送端的签约信息。
9.结合上述第一方面，在一种可能的实现方式中，第一数据中还包括第二数字签名；第二数字签名为根据第一公钥和第一签名算法对第一公钥和第一终端信息签名后生成的数字签名；在接收来自数据发送端的第二指示信息之后，该方法还包括：根据第一公钥和第
一签名算法，验证第二数字签名；在第二数字签名验证通过的情况下，获取第一数据中的第一终端信息；根据第一终端信息生成签约信息获取请求。
10.结合上述第一方面，在一种可能的实现方式中，根据第一数据和签约信息，确定数据完整性验证信息，包括：根据第一数据和签约数据生成第一待签名数据集；根据第二私钥和第二签名算法对第一待签名数据集签名，确定第三数字签名；第二私钥归属于divs as生成的第二密钥对；根据第一待签名数据集、第二私钥对应的证书、以及第三数字签名，确定数据完整性验证信息。
11.结合上述第一方面，在一种可能的实现方式中，该方法还包括：向数据发送端发送第一交易标识；其中，第一交易标识用于表征数据完整性验证信息在区块链中的存储信息。
12.结合上述第一方面，在一种可能的实现方式中，该方法还包括：向数据发送端发送第一地址信息；其中，第一地址信息为存储第一交易标识对应的数据完整性验证信息的divs as的地址信息。
13.结合上述第一方面，在一种可能的实现方式中，该方法还包括：接收来自nef的签约信息更新消息；签约信息更新消息包括：第二终端信息，以及数据发送端更新后的签约信息；查询区块链中包括第二终端信息的最新目标数据完整性验证信息；根据更新后的签约信息，更新最新目标数据完整性验证信息；将更新后的最新目标数据完整性验证信息存储在区块链中。
14.结合上述第一方面，在一种可能的实现方式中，根据更新后的签约信息，更新最新目标数据完整性验证信息，包括：对最新目标数据完整性验证信息执行第一操作，确定更新后的最新目标数据完整性验证信息；第一操作包括：根据第一数据和更新后的签约信息，生成第二待验证数据集；根据第二私钥和第二签名算法对第二待签名数据集签名，确定第四数据签名；根据第二待签名数据集，第二私钥对应的证书，以及第四数字签名，确定更新后的最新目标数据完整性验证信息。
15.结合上述第一方面，在一种可能的实现方式中，该方法还包括：向数据发送端发送第二交易标识；其中，第二交易标识用于表征更新后的最新目标数据完整性验证信息在区块链中的存储信息。
16.结合上述第一方面，在一种可能的实现方式中，该方法还包括：向数据发送端发送第二地址信息；其中，第二地址信息为存储更新后的最新目标数据完整性验证信息的divs as的地址信息。
17.第二方面，提供一种数据完整性验证方法，包括：接收来自数据发送端的目标数据；目标数据包括：待验证数据、第一数字签名和第一标识；其中，第一数字签名为根据第一私钥对待验证数据进行签名确定的数字签名；第一标识为数据发送端的数据完整性验证信息在divs as中的存储标识；第一私钥为数据发送端生成的第一密钥对中的私钥；向divs as发送第一指示信息；第一指示信息用于指示divs as查询第一标识对应的数据完整性验证信息；接收来自divs as的数据完整性验证信息。
18.结合上述第二方面，在一种可能的实现方式中，数据完整性验证信息中包括第一公钥；第一公钥为数据发送端生成的第一密钥对中的公钥；该方法还包括：根据数据完整性验证信息中的第一公钥，验证第一数字签名；根据第一数字签名的验证结果，确定待验证数据的数据完整性。
19.结合上述第二方面，在一种可能的实现方式中，目标数据还包括第一数字签名的时间戳；数据完整性验证信息还包括：数据发送端的签约有效期；该方法还包括：确定第一数字签名的时间戳是否在数据发送端的签约有效期内；若是，则确定待验证数据的数据完整性验证成功。
20.结合上述第二方面，在一种可能的实现方式中，数据完整性验证信息具体包括：第一待签名数据集，第二私钥对应的证书，第三数字签名；其中，第一待签名数据集包括第一数据和签约信息；第一数据包括第一公钥，数据发送端支持的签名算法集和数据发送端的第一终端信息；签约信息包括：数据发送端的签约有效性信息和数据发送端的第二终端信息；第二私钥为divs as生成的第二密钥对中的私钥；第三数字签名为根据第二私钥和第二签名算法对第一待签名数据集签名后生成的数字签名；在接收来自divs as的数据完整性验证信息之后，该方法还包括：根据第二私钥对应的证书和第二签名算法验证第三数字签名；在第三数字签名验证成功的情况下，获取第一待签名数据集中的第一公钥。
21.第三方面，提供一种数据完整性验证方法，包括：生成目标数据；其中，目标数据包括待验证数据，第一数字签名和第一标识；第一数字签名为根据第一私钥对待验证数据签名后生成的数字签名；第一私钥为数据发送端生成的第一密钥对中的私钥；第一标识为数据发送端的数据完整性验证信息在divs as中的存储标识；向数据接收端发送目标数据，以使得数据接收端根据第一标识和第一数字签名确定待验证数据的数据完整性。
22.结合上述第三方面，在一种可能的实现方式中，该方法还包括：生成第一数据；第一数据包括第一公钥，数据发送端支持的签名算法集和数据发送端的第一终端信息；生成包括第一数据的第二指示信息；向divs as发送第二指示信息。
23.结合上述第三方面，在一种可能的实现方式中，生成第一数据包括：生成第一密钥对；第一密钥对包括第一公钥和第一私钥；获取数据发送端的第一终端信息；根据第一私钥和第一签名算法对第一公钥和第一终端信息签名，确定第二数字签名；根据第一公钥，第一终端信息，数据发送端支持的签名算法集，和第二数字签名生成第一数据。
24.结合上述第三方面，在一种可能的实现方式中，该方法还包括：接收来自divs as的第一交易标识和第二交易标识中的至少之一；第一交易标识为根据数据完整性验证信息在区块链中的存储信息生成的交易标识；第二交易标识为根据更新后的数据完整性验证信息在区块链中的存储信息生成的交易标识；根据第一交易标识和第二交易标识中的最新的交易标识，生成第一标识。
25.结合上述第三方面，在一种可能的实现方式中，目标数据还包括验证访问地址；验证访问地址用于表征存储数据发送端的数据完整性验证信息的divs as的地址；该方法还包括：接收来自divs as的第一地址信息和第二地址信息中的至少之一；第一地址信息为存储第一交易标识对应的数据完整性验证信息的divs as的地址信息；第二地址信息为存储第二交易标识对应的更新后的数据完整性验证信息的divs as的地址信息；根据第一地址信息和第二地址信息中的最新的地址生成验证访问地址。
26.结合上述第三方面，在一种可能的实现方式中，第一终端信息包括数据发送端的嵌入式通用集成电路卡标识euicc id/集成电路卡识别码iccid、国际移动设备识别码imei和移动用户号码msisdn的至少之一。
27.第四方面，提供一种数据完整性验证装置，包括：通信单元和处理单元；通信单元，
用于接收来自数据接收端的第一指示信息；第一指示信息用于指示数据完整性验证服务器divs as查询第一标识对应的数据完整性验证信息，第一标识为数据发送端的数据完整性验证信息在divs as中的存储标识；处理单元，用于查询第一标识对应的数据完整性验证信息；处理单元，还用于指示通信单元向数据接收端发送数据完整性验证信息。
28.结合上述第四方面，在一种可能的实现方式中，第一标识归属于数据发送端向数据接收端发送的目标数据；目标数据包括待验证数据、第一数字签名和第一标识；第一数字签名为根据第一私钥对待验证数据签名后生成的数字签名；第一私钥为数据发送端生成的第一密钥对中的私钥；数据完整性验证信息包括第一公钥，第一公钥为数据发送端生成的第一密钥对中的公钥。
29.结合上述第四方面，在一种可能的实现方式中，该装置还包括：通信单元，还用于接收来自数据发送端的第二指示信息；第二指示信息用于承载第一数据；第一数据包括第一公钥，数据发送端支持的签名算法集和数据发送端的第一终端信息；通信单元，还用于根据第二指示信息中的第一终端信息，获取数据发送端的签约信息；签约信息包括：数据发送端的签约有效性信息；处理单元，还用于根据第一数据和签约信息，确定数据完整性验证信息；处理单元，还用于将数据完整性验证信息存储在区块链中。
30.结合上述第四方面，在一种可能的实现方式中，通信单元，具体用于：向能力开放平台nef发送签约信息获取请求；签约信息获取请求中包括第一终端信息；接收来自nef的签约信息；签约信息为nef返回的根据第一终端信息在用户数据管理网元udm中获取的数据发送端的签约信息。
31.结合上述第四方面，在一种可能的实现方式中，第一数据中还包括第二数字签名；第二数字签名为根据第一公钥和第一签名算法对第一公钥和第一终端信息签名后生成的数字签名；处理单元，还用于：根据第一公钥和第一签名算法，验证第二数字签名；在第二数字签名验证通过的情况下，获取第一数据中的第一终端信息；根据第一终端信息生成签约信息获取请求。
32.结合上述第四方面，在一种可能的实现方式中，处理单元，具体用于：根据第一数据和签约数据生成第一待签名数据集；根据第二私钥和第二签名算法对第一待签名数据集签名，确定第三数字签名；第二私钥归属于divs as生成的第二密钥对；根据第一待签名数据集、第二私钥对应的证书、以及第三数字签名，确定数据完整性验证信息。
33.结合上述第四方面，在一种可能的实现方式中，通信单元，还用于：向数据发送端发送第一交易标识；其中，第一交易标识用于表征数据完整性验证信息在区块链中的存储信息。
34.结合上述第四方面，在一种可能的实现方式中，通信单元，还用于：向数据发送端发送第一地址信息；其中，第一地址信息为存储第一交易标识对应的数据完整性验证信息的divs as的地址信息。
35.结合上述第四方面，在一种可能的实现方式中，通信单元，还用于：接收来自nef的签约信息更新消息；签约信息更新消息包括：第二终端信息，以及数据发送端更新后的签约信息；处理单元，还用于查询区块链中包括第二终端信息的最新目标数据完整性验证信息；处理单元，还用于根据更新后的签约信息，更新最新目标数据完整性验证信息；处理单元，还用于将更新后的最新目标数据完整性验证信息存储在区块链中。
36.结合上述第四方面，在一种可能的实现方式中，处理单元，还用于：对最新目标数据完整性验证信息执行第一操作，确定更新后的最新目标数据完整性验证信息；第一操作包括：根据第一数据和更新后的签约信息，生成第二待验证数据集；根据第二私钥和第二签名算法对第二待签名数据集签名，确定第四数据签名；根据第二待签名数据集，第二私钥对应的证书，以及第四数字签名，确定更新后的最新目标数据完整性验证信息。
37.结合上述第四方面，在一种可能的实现方式中，通信单元，还用于：向数据发送端发送第二交易标识；其中，第二交易标识用于表征更新后的最新目标数据完整性验证信息在区块链中的存储信息。
38.结合上述第四方面，在一种可能的实现方式中，通信单元，还用于：向数据发送端发送第二地址信息；其中，第二地址信息为存储更新后的最新目标数据完整性验证信息的divs as的地址信息。
39.第五方面，提供一种数据完整性验证装置，包括：通信单元和处理单元；通信单元，用于接收来自数据发送端的目标数据；目标数据包括：待验证数据、第一数字签名和第一标识；其中，第一数字签名为根据第一私钥对待验证数据进行签名确定的数字签名；第一标识为数据发送端的数据完整性验证信息在divs as中的存储标识；第一私钥为数据发送端生成的第一密钥对中的私钥；处理单元，用于指示通信单元向divs as发送第一指示信息；述第一指示信息用于指示divs as查询第一标识对应的数据完整性验证信息；处理单元，还用于指示通信单元接收来自divs as的数据完整性验证信息。
40.结合上述第五方面，在一种可能的实现方式中，数据完整性验证信息中包括第一公钥；第一公钥为数据发送端生成的第一密钥对中的公钥；处理单元，还用于：根据数据完整性验证信息中的第一公钥，验证第一数字签名；根据第一数字签名的验证结果，确定待验证数据的数据完整性。
41.结合上述第五方面，在一种可能的实现方式中，目标数据还包括第一数字签名的时间戳；数据完整性验证信息还包括：数据发送端的签约有效期；处理单元，还用于：确定第一数字签名的时间戳是否在数据发送端的签约有效期内；若是，则确定待验证数据的数据完整性验证成功。
42.结合上述第五方面，在一种可能的实现方式中，数据完整性验证信息具体包括：第一待签名数据集，第二私钥对应的证书，第三数字签名；其中，第一待签名数据集包括第一数据和签约信息；第一数据包括第一公钥，数据发送端支持的签名算法集和数据发送端的第一终端信息；签约信息包括：数据发送端的签约有效性信息和数据发送端的第二终端信息；第二私钥为divs as生成的第二密钥对中的私钥；第三数字签名为根据第二私钥和第二签名算法对第一待签名数据集签名后生成的数字签名；处理单元，还用于：根据第二私钥对应的证书和第二签名算法验证第三数字签名；在第三数字签名验证成功的情况下，获取第一待签名数据集中的第一公钥。
43.第六方面，提供一种数据完整性验证装置，包括：通信单元和处理单元；处理单元，用于生成目标数据；其中，目标数据包括待验证数据，第一数字签名和第一标识；第一数字签名为根据第一私钥对待验证数据签名后生成的数字签名；第一私钥为数据发送端生成的第一密钥对中的私钥；第一标识为数据发送端的数据完整性验证信息在divs as中的存储标识；通信单元，用于向数据接收端发送目标数据，以使得数据接收端根据第一标识和第一
数字签名确定待验证数据的数据完整性。
44.结合上述第六方面，在一种可能的实现方式中，处理单元，还用于生成第一数据；第一数据包括第一公钥，数据发送端支持的签名算法集和数据发送端的第一终端信息；处理单元，还用于生成包括第一数据的第二指示信息；通信单元，还用于向divs as发送第二指示信息。
45.结合上述第六方面，在一种可能的实现方式中，处理单元，具体用于：生成第一密钥对；第一密钥对包括第一公钥和第一私钥；获取数据发送端的第一终端信息；根据第一私钥和第一签名算法对第一公钥和第一终端信息签名，确定第二数字签名；根据第一公钥，第一终端信息，数据发送端支持的签名算法集，和第二数字签名生成第一数据。
46.结合上述第六方面，在一种可能的实现方式中，通信单元，还用于接收来自divs as的第一交易标识和第二交易标识中的至少之一；第一交易标识为根据数据完整性验证信息在区块链中的存储信息生成的交易标识；第二交易标识为根据更新后的数据完整性验证信息在区块链中的存储信息生成的交易标识；处理单元，还用于根据第一交易标识和第二交易标识中的最新的交易标识，生成第一标识。
47.结合上述第六方面，在一种可能的实现方式中，目标数据还包括验证访问地址；验证访问地址用于表征存储数据发送端的数据完整性验证信息的divs as的地址；通信单元，还用于接收来自divs as的第一地址信息和第二地址信息中的至少之一；第一地址信息为存储第一交易标识对应的数据完整性验证信息的divs as的地址信息；第二地址信息为存储第二交易标识对应的更新后的数据完整性验证信息的divs as的地址信息；处理单元，还用于根据第一地址信息和第二地址信息中的最新的地址生成验证访问地址。
48.结合上述第六方面，在一种可能的实现方式中，第一终端信息包括数据发送端的嵌入式通用集成电路卡标识euicc id/集成电路卡识别码iccid、国际移动设备识别码imei和移动用户号码msisdn的至少之一。
49.第七方面，本技术提供了一种数据完整性验证装置，该数据完整性验证装置包括：处理器和通信接口；通信接口和处理器耦合，处理器用于运行计算机程序或指令，以实现如第一方面和第一方面的任一种可能的实现方式中所描述的数据完整性验证方法。
50.第八方面，本技术提供了一种数据完整性验证装置，该数据完整性验证装置包括：处理器和通信接口；通信接口和处理器耦合，处理器用于运行计算机程序或指令，以实现如第二方面和第二方面的任一种可能的实现方式中所描述的数据完整性验证方法。
51.第九方面，本技术提供了一种数据完整性验证装置，该数据完整性验证装置包括：处理器和通信接口；通信接口和处理器耦合，处理器用于运行计算机程序或指令，以实现如第三方面和第三方面的任一种可能的实现方式中所描述的数据完整性验证方法。
52.第十方面，本技术提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当计算机可读存储介质中的指令由数据完整性验证装置的处理器执行时，使得数据完整性验证装置能够执行如第一方面和第一方面的任一种可能的实现方式中描述的数据完整性验证方法。
53.第十一方面，本技术提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当计算机可读存储介质中的指令由数据完整性验证装置的处理器执行时，使得数据完整性验证装置能够执行如第二方面和第二方面的任一种可能的实现方式中描述的
数据完整性验证方法。
54.第十二方面，本技术提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当计算机可读存储介质中的指令由数据完整性验证装置的处理器执行时，使得数据完整性验证装置能够执行如第三方面和第三方面的任一种可能的实现方式中描述的数据完整性验证方法。
55.在本技术中，上述数据完整性验证装置的名字对设备或功能模块本身不构成限定，在实际实现中，这些设备或功能模块可以以其他名称出现。只要各个设备或功能模块的功能和本发明类似，属于本发明权利要求及其等同技术的范围之内。
56.本发明的这些方面或其他方面在以下的描述中会更加简明易懂。
57.本技术提供的技术方案至少带来以下有益效果：在本公开实施例中数据发送端在采集到数据之后，采用第一私钥对数据进行数字签名，然后将数字签名和待验证数据统一发送给数据接收端。数据接收端接收到数据之后，从divs as中获取数据发送端的数据完整性验证信息，利用数据完整性验证信息中的第一公钥对第一数字签名进行验证，若验证成功，则表示根据第一数字签名为根据第一私钥进行的签名，而第一私钥为数据发送端内部的密钥，不会被外部窃取。因此在第一数字签名验证成功的情况下，说明该第一数字签名为数据发送端对待验证数据进行签名后得到的数字签名，因此待验证数据为数据发送端发送的原始数据。基于此，数据接收端能够根据该方法确定接收到的数据是否为数据发送端发送的原始数据，从而有效验证了待验证数据的数据完整性。
58.在本技术中，上述数据完整性验证装置的名字对设备或功能模块本身不构成限定，在实际实现中，这些设备或功能模块可以以其他名称出现。只要各个设备或功能模块的功能和本发明类似，属于本发明权利要求及其等同技术的范围之内。
附图说明
59.图1为本技术提供的一种5g能力开放架构的系统架构图；
60.图2为本技术提供的一种区块链的结构示意图；
61.图3为本技术提供的在垂直行业场景下的一种数据完整性验证系统的系统架构图；
62.图4为本技术提供的一种数据完整性验证方法的流程示意图；
63.图5为本技术提供的又一种数据完整性验证方法的流程示意图；
64.图6为本技术提供的又一种数据完整性验证方法的流程示意图；
65.图7为本技术提供的又一种数据完整性验证方法的流程示意图；
66.图8为本技术提供的又一种数据完整性验证方法的流程示意图；
67.图9为本公开提供的一种数据发送端在运营商网络中签约的流程示意图；
68.图10为本公开提供的一种数据完整性验证信息上链的流程示意图；
69.图11为本公开提供的一种数据完整性验证信息更新的流程示意图；
70.图12为本公开提供的一种数据完整性验证的流程示意图；
71.图13为本公开提供的一种数据完整性验证装置的结构示意图；
72.图14为本公开提供的一种数据完整性验证装置的结构示意图；
73.图15为本公开提供的一种数据完整性验证装置的结构示意图；
74.图16为本公开提供的一种电子设备的结构示意图。
具体实施方式
75.下面结合附图对本技术实施例提供的数据完整性验证系统进行详细地描述。
76.本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。
77.本技术的说明书以及附图中的术语“第一”和“第二”等是用于区别不同的对象，或者用于区别对同一对象的不同处理，而不是用于描述对象的特定顺序。
78.此外，本技术的描述中所提到的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括其他没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
79.需要说明的是，本技术实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本技术实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
80.以下，为便于理解，首先对本技术实施例涉及到的名词进行解释。
81.1、机器类型终端
82.机器类型终端通常用于采集生成的数据，在垂直行业应用比较广泛。机器类型终端的应用有效促进了如农业、物流、交通、医疗、环境、供应链金融、智慧城市等垂直行业的数字化转型。
83.随着5g网络的发展，机器类型终端的应用越来越广泛，海量机器类型终端采集数据之后，将数据发送至业务提供商终端，由业务提供商终端对采集数据进行收集、汇总和分析。此外，业务提供商终端还可以将机器类型终端采集的数据转发给上游的数据消费者终端。数据消费者终端可以通过分析数据获取行业内的有价值数据。例如，在农业行业，数据消费终端可以基于机器类型终端采集的数据确定用于农业保险的环境数据(如温度和风速)。在二手车行业，数据消费终端可以基于机器类型终端采集的数据确定用于二手交易车辆的驾驶行为数据。在交通行业，数据消费终端可以基于机器类型终端采集的数据确定用于ai算法训练的交通数据。
84.当前机器类型终端采集数据之后直接向业务提供商终端上报采集数据，而不会将数据直接提供给数据消费终端。数据消费终端只能从业务提供商终端获取采集数据，而无法直接从机器类型终端获取数据。但是数据消费终端在接收到采集数据之后，无法确定业务提供商终端提供的数据是否被篡改、难以验证接收到的采集数据是否为机器类型终端采集的原始数据。
85.而在很多行业内如农业保险和分布式人工智能应用，对数据完整性(数据真实性)要求非常高，如果这些行业内的数据消费终端基于篡改后的数据进行数据分析和决策，将可能会导致不必要的经济损失，遭受安全攻击。因此，对于数据消费终端来说，如何对获取到的数据进行数据完整性验证，保证获取到的数据为源端采集的原始数据、数据未经过篡改，成为当前亟待解决的问题。
86.2、数据完整性
87.在本公开实施例中，数据完整性主要用于数据接收端(例如以上记载的数据消费终端)验证接收到的数据是否为数据发送端(例如以上记载的机器类型终端)发送的原始数据。防止数据在中间转发的过程中被篡改。基于上述在机器类型终端中的描述可知，当前数据消费终端存在验证业务提供商终端提供的数据的数据完整性的需求。
88.相关技术中，可以通过使用对称密钥+单向hash函数或者非对称密钥hash方式验证数据完整性。但是这些方案至少存在如下问题。
89.采用对称密钥+单向hash函数的数据完整性验证方式仅能验证数据在点到点传输过程中的数据完整性，而无法验证数据是否为源端提供的原始数据。这可能会导致业务提供商终端在向数据消费终端发送数据之前对数据进行篡改，而数据消费终端无法验证数据是否被篡改。
90.采用非对称密钥hash的数据完整性验证方式的过程中，通过采用私钥签名+公钥验签的方式验证数据完整性(例如，itu-t x.509、ietf rfc4880)。但是在该方式中，同样无法验证数据是否为源端提供的原始数据。例如，在机器类型终端采集数据之后，由业务提供商终端将采集数据转发给数据消费终端。数据消费终端只能以接收到的数据为原始数据进行后续处理，或者通过声明及合约的方式约束业务提供商提供原始数据。但是这些方式都无法避免业务提供商终端提供的是原始数据，也就难以确保数据完整性。
91.3、嵌入式用户身份识别模块(embedded subscriber identity module，esim)及可信执行环境(trusted execution environment，tee)技术。
92.esim和tee可以在机器类型终端存储机密数据及执行可信运算，例如，在机器类型终端的esim中生成公私密钥对，或者通过ota的方式将公钥背书信息下发到esim中。
93.在机器类型终端中，当机器类型终端需要发送数据时，机器类型终端可以通过os调用预定接口使用存储在tee或者esim中的私钥对采集的数据进行签名，然后将签名后的数据发送给业务提供商终端。
94.4、5g开放能力架构
95.如图1所示，为本技术实施例提供的5g能力开放架构的系统架构图。在图1所示的5g能力开放架构中，包括：应用服务器(application server，as)、网元功能(network element function，nef)、统一数据管理功能(unified data management，udm)、策略控制功能(policy control function，pcf)、接入和移动管理功能(access and mobility management function，amf)、会话管理功能(session management function，smf)、网络仓库功能(network repository function，nrf)、network entity。
96.其中，as为运营商的应用服务器或者第三方应用服务器，用于提供运营商的网络服务能力或者第三方应用的服务能力。as通过nnef接入运营商5g网络的nef的api接口，通过api接口与nef进行通信。
97.nef为运营商的能力开放网元，用于将运营商的网络能力开放给第三方服务，将核心网中的数据(如位置信息)开放给as，或者将as的业务需求(如qos策略)传输给5g核心网中的网元。
98.nef通过nudm接口与udm连接，通过npcf接口与pcf连接，通过namf与amf连接，通过nsmf与smf连接，通过nnrf与nrf连接，通过3gpp interface与network entity连接。
99.需要指出的是，在本公开实施例中，可以通过运营商的as功能，为机器类型终端采集的数据提供长期的数据完整性验证服务。
100.5、区块链
101.区块链是一种由多方共同维护、以块链结构存储数据、使用密码学保证传输和访问安全的数据存储技术。通过区块链技术能够实现数据一致存储、无法篡改、无法抵赖的效果。
102.区块链中通常包括多个区块链节点，该多个节点分别存储区块链中的账本，并使用p2p技术进行账本的同步，保证每个节点的存储的账本的一致性。当账本中的数据需要更新时，多个节点采用共识机制对写入账本的记录进行确认。这样，可以保证写入账本的数据是在多个节点共同确认的情况下写入的，未经过多个节点共同确认的数据将无法写入，保证了区块链账本中写入的数据是不可被篡改的且数据是可溯源的。
103.区块链根据允许接入用户的类型划分为：公有链、联盟链和私有链三种类型的区块链。其中，公有链允许任何终端接入并使用账本记账。联盟链仅允许特定的个人的终端或特定的企业的终端接入并使用账本记账。私有链仅允许企业内部节点维护和使用区块链。
104.如图2所示，为本公开实施例提供的一种区块链的结构示意图。如图2所示，区块链中包括多个区块链节点peer，各个区块链节点之间互相连接。区块链节点中设置有智能合约(图中仅以区块链节点3为例示出，其他节点与区块链节点3类似)。
105.各个区块链节点中包括区块链账本(ledger)，区块链账本用于存储数据，例如以哈希的形式存储数据。
106.需要指出的是，在本公开实施例中可以通过区块链技术存储数据完整性验证信息。例如公钥信息、移动台国际用户号码(mobile station international subscriber directory number，msisdn)、集成电路卡识别码(integrate circuit card identity，iccid)、设备序列信息、hash算法、时间戳等信息，并通过5g网络的开放能力为终端提供数据完整性验证服务器。从而保证垂直行业通过机器类型终端采集数据时整个数据生命周期的数据完整性验证，降低数据流转和再应用过程中产生的信任成本，促进垂直行业数字化转型和数据应用。
107.以上，对本技术实施例涉及到的技术名词进行了详细说明。
108.根据上述对机器类型终端和数据完整性验证的描述可知，在当前的数据传输过程中(尤其是存在第三方转发数据的过程中)，数据接收端存在验证接收数据的数据完整性的需求。
109.例如，在垂直行业的应用场景中，机器类型终端将采集的数据发送给业务提供商终端，由业务提供商终端将数据转发给数据消费终端。在该场景下，数据消费终端难以验证业务提供商终端是否篡改了机器类型终端采集的数据。导致数据消费终端无法确定接收到的数据的数据完整性。
110.为解决相关技术中存在的问题，本技术实施例提供了一种数据完整性验证系统，数据完整性验证服务器divs as中存储数据发送端的数据完整性验证信息，在数据接收端接收到待验证数据及待验证数据的第一数字签名之后，从divs as中获取数据发送端的数据完整性验证信息，根据数据完整性验证信息验证第一数字签名，在第一数字签名验证通过的情况下，表示该数据为数据采集终端采集到的原始数据，进而表示该数据的数据完整
性验证成功。
111.如图3所示，为在垂直行业场景下，本技术实施例提供的一种数据完整性验证系统的系统架构图。
112.如图3所示，该数据完整性验证系统包括机器类型终端301、数据完整性验证服务器(data integrity verification service application server，divs as)302、数据消费终端303、能力开放功能网元304、用户数据存储网元305、其他数据完整性验证服务网元306。
113.其中，机器类型终端301内安装有app，用于实现不同的应用功能。机器类型终端内置有操作系统os。机器类型终端中安装有esim，这样可以使得机器类型终端通过运营商网络(例如5g网络)传输数据。机器类型终端esim中还可以安装applet，applet用于生成密钥对(例如上述第一公钥和第一私钥)。其中第一私钥始终保存在applet中，避免第一私钥泄露，第一公钥可以发送给其他终端，以使得其他终端根据第一公钥对第一私钥加密的数据进行解密。可选的，机器类型终端中还可以集成5g通信模组，和嵌入式通用集成电路卡标识(embedded universal integrated circuit card，euicc)euicc，使得机器类型终端具备5g通信能力。
114.数据完整性验证服务器302，用于存储数据发送端的数据完整性验证信息，并为数据接收端提供数据完整性验证信息。可选的，数据完整性验证服务器可以是在运营商网络中部署的第三方实体。数据完整性验证服务器302中具体可以包括信令处理模块3021、接入控制模块3022、数据管理模块3023、区块链账本3024。
115.数据消费终端303为用于收集、使用、流转机器类型终端采集的数据的第三方终端。例如，可以是个人的终端或者企业中的终端。
116.能力开放功能网元304示例性的可以为5g核心网中的能力开放功能网元，例如nef，用于实现第三方应用(如数据完整性验证服务器)与运营商核心网之间的通信。
117.用户数据存储网元305，用于存储用户终端的数据，例如在本公开实施例中用户数据存储网元305用于存储机器类型终端的签约信息。
118.其他数据完整性验证服务网元306为部署于同一运营商不同核心网的数据完整性验证服务器，或者其他运营商的数据完整性验证服务器；数据完整性验证服务器的区块链账本功能组成区块链网络。
119.以上，对在垂直行业场景下的一种数据完整性验证系统的系统架构图进行了详细说明。
120.以下，对本技术实施例涉及的数据完整性验证方法进行详细说明。
121.图4为本技术实施例提供的一种数据完整性验证方法，如图4所示，该方法包括以下步骤：
122.s401、数据发送端生成目标数据。
123.其中，目标数据包括待验证数据，第一数字签名和第一标识；第一数字签名为根据第一私钥对待验证数据签名后生成的数字签名；第一私钥为数据发送端生成的第一密钥对中的私钥；第一标识为数据发送端的数据完整性验证信息在divs as中的存储标识。
124.一种具体的实现方式中，数据发送端采集数据，将采集的数据作为待验证数据。数据发送端采用第一私钥对待验证数据签名，生成第一数字签名。数据发送端获取用于表示
数据发送端的数据完整性验证信息在divs as中的存储的第一标识。
125.数据发送端将待验证数据、第一数字签名和第一标识作为目标数据。
126.一种可能的实现方式中，目标数据中还包括第一数字签名的时间戳。第一数字签名的时间戳用于表示第一数字签名的生成时间。
127.s402、数据发送端向数据接收端发送目标数据。相应的，数据接收端接收来自数据发送端发送的目标数据。
128.一种可能的实现方式中，数据发送端可以通过运营商网络向数据接收端发送目标数据。
129.或者，数据发送端将目标数据发送给数据转发设备，由数据转发设备将目标数据发送给数据接收端。
130.例如，在垂直行业场景中，数据发送端(机器类型终端)将目标数据发送给业务提供商终端，由业务提供商终端将数据转发给数据接收端(数据消费终端)。
131.需要指出的是，数据发送端还可以采用其他方式向数据接收端发送目标数据，本技术对此不做限定。
132.s403、数据接收端向divs as发送第一指示信息。相应的，divs as接收来自数据接收端的第一指示信息。
133.其中，第一指示信息用于指示divs as查询第一标识对应的数据完整性验证信息；数据完整性验证信息中包括第一公钥；第一公钥为数据发送端生成的第一密钥对中的公钥。
134.一种具体的实现方式中，数据接收端接收到目标数据后，提取目标数据中的第一标识，并根据第一标识生成第一指示信息。数据接收端向divs as发送第一指示信息。
135.一种可能的实现方式中，数据完整性验证信息中还可以包括数据发送端的签约有效期。
136.s404、divs as查询第一标识对应的数据完整性验证信息。
137.一种可能的实现方式中，divs as中包括区块链账本，区块链账本用于存储至少一个数据发送端的数据完整性验证信息。
138.divs as接收到第一标识之后，根据第一标识查询区块链账本中与第一标识对应的数据完整性验证信息。
139.405、divs as向数据接收端发送数据完整性验证信息。相应的，数据接收端接收来自divs as的数据完整性验证信息。
140.需要指出的是，数据接收到在接收到来自divs as的数据完整性验证信息之后，可以通过数据完整性验证信息验证接收到的来自数据发送端的数据，从而完成对待验证数据的数据完整性验证。
141.上述方案至少带来以下有益效果：在本公开实施例中数据发送端在采集到数据之后，采用第一私钥对数据进行数字签名，然后将数字签名和待验证数据统一发送给数据接收端。数据接收端接收到数据之后，从divs as中获取数据发送端的数据完整性验证信息，利用数据完整性验证信息中的第一公钥对第一数字签名进行验证，若验证成功，则表示根据第一数字签名为根据第一私钥进行的签名，而第一私钥为数据发送端内部的密钥，不易被外部窃取。因此在第一数字签名验证成功的情况下，说明该第一数字签名为数据发送端
对待验证数据进行签名后得到的数字签名，因此待验证数据为数据发送端发送的原始数据。基于此，数据接收端能够根据该方法确定接收到的数据是否为数据发送端发送的原始数据，从而有效验证了待验证数据的数据完整性。
142.一种可能的实现方式中，如图4所示，在上述s405之后，该方法还包括：
143.s406、数据接收端根据数据完整性验证信息中的第一公钥，验证第一数字签名。
144.一种可能的实现方式中，数据发送端在生成目标数据时，根据第一私钥和第一签名算法对待验证数据(或者待验证数据的哈希)签名，生成第一数字签名。
145.数据接收端根据第一公钥和第一签名算法对第一数字签名进行解析，确定解析出来的数据与待验证数据(或者待验证数据的哈希)是否一致。若一致，则确定第一数字签名有效。若不一致，则确定第一数字签名无效。
146.s407、数据接收端根据第一数字签名的验证结果，确定待验证数据的数据完整性。
147.数据接收端在第一数字签名有效的情况下，确定待验证数据的数据完整性验证成功。在第一数字签名无效的情况下，确定带验证数据的数据完整性验证失败。
148.一种可能的实现方式中，在目标数据还包括第一数字签名的时间戳；数据完整性验证信息还包括：数据发送端的签约有效期的情况下；
149.数据接收端还可以验证第一确定第一数字签名的时间戳是否在数据发送端的签约有效期内；若是，则确定待验证数据的数据完整性验证成功。若否，则确定待验证数据的数据完整性验证失败。
150.也即是说，数据接收端可以根据第一数字签名和第一数字签名的时间戳，共同验证待验证数据的数据完整性。
151.这样，数据接收端具体可以根据第一数字签名的时间戳是否在签约有效期内判断终端采集数据时是否处于签约有效时间段，并确定数据发送端在签约有效期内采集的数据完整性验证成功，在签约有效期外采集的数据完整性验证失败。
152.一种可能的实现方式中，在数据接收端根据divs as提供的数据完整性验证信息进行验证之前，divs as可以与数据发送端交互，获取数据发送端的数据完整性验证信息，并在区块链中存储数据完整性验证信息。
153.如图5所示，divs as在区块链中存储数据完整性验证信息的方法包括以下步骤：
154.s501、数据发送端生成第一数据。
155.其中，第一数据包括第一公钥，数据发送端支持的签名算法集和数据发送端的第一终端信息。
156.一种具体的实现方式中，数据发送端获取第一公钥，数据发送端支持的签名算法集和数据发送端的第一终端信息。数据发送端将第一公钥，数据发送端支持的签名算法集和第一终端信息作为第一数据。
157.可选的，第一数据中还包括第一签名算法和第二数字签名。此时，该步骤具体可以实现为：数据发送端生成第一密钥对；第一密钥对包括第一公钥和第一私钥。
158.数据发送端获取数据发送端的第一终端信息。
159.数据发送端根据第一私钥和第一签名算法对第一公钥和第一终端信息签名，确定第二数字签名。
160.数据发送端根据第一公钥，第一签名算法和第二数字签名生成第一数据。
161.这样，数据发送端生成第一公钥和第一私钥，数据发送端保存第一私钥，将第一公钥发送给divs as。此外，数据发送端采用第一私钥和第一签名算法对元数据签名，生成第二数字签名，可以使divs as根据第一公钥和第一签名算法对第二数字签名进行验证，保证接收到的第一数据的准确性。
162.s502、数据发送端生成包括第一数据的第二指示信息。
163.具体来说，数据发送端生成第二指示信息，并将第一数据承载在第二指示信息中，向divs as发送第二指示信息。
164.s503、数据发送端向divs as发送第二指示信息。相应的，divs as接收来自数据发送端的第二指示信息。
165.s504、divs as根据第二指示信息中的第一终端信息，获取数据发送端的签约信息。
166.签约信息包括：数据发送端的签约有效性信息。
167.一种具体的实现方式中，如图6所示，divs as获取数据发送端的签约信息的过程具体可以通过以下步骤实现：
168.s601、divs as向nef发送签约信息获取请求。相应的，nef接收来自divs as的签约信息获取请求。
169.其中，签约信息获取请求中包括第一终端信息。
170.一种具体的实现方式中，第一数据中还包括第二数字签名；第二数字签名为根据第一公钥和第一签名算法对第一公钥和第一终端信息签名后生成的数字签名；该步骤具体可以实现为：
171.根据第一公钥和第一签名算法，验证第二数字签名。
172.在第二数字签名验证通过的情况下，获取第一数据中的第一终端信息。
173.根据第一终端信息生成签约信息获取请求。
174.这样，基于此，divs as再次对数据完整性验证信息进行签名，可以使得数据接收端接收到数据完整性验证信息后，根据区块链的签名信息进行验签，保证数据完整性验证信息为来自divs as的信息。
175.s602、nef向udm转发签约信息获取请求。
176.s603、udm向nef发送签约信息。
177.其中，签约信息包括数据发送端的签约信息。
178.一种具体的实现方式中，udm接收到签约信息获取请求之后，根据签约信息获取请求中的第一终端信息，查询与第一终端信息对应的签约信息。udm根据第一终端信息对应的签约信息，生成签约信息，并向nef发送签约信息。
179.s604、nef向divs as发送签约信息。相应的，divs as接收来自nef的签约信息。
180.s605、divs as接收签约信息之后，从签约信息中获取数据发送端的签约信息。
181.根据上述s601-s606.divs as可以通过与nef和udm获取数据发送端的签约信息。
182.s505、divs as根据第一数据和签约信息，确定数据完整性验证信息。
183.一种可能的实现方式中，该步骤具体可以实现为：divs as根据第一数据和签约数据生成第一待签名数据集。divs as根据第二私钥和第二签名算法对第一待签名数据集签名，确定第三数字签名；第二私钥归属于divs as生成的第二密钥对。divs as根据第一待签
名数据集、第二私钥对应的证书、以及第三数字签名，确定数据完整性验证信息。
184.可选的，签约信息中还包括签约有效期，此时，divs as首先验证数据发送端的签约是否在签约有效期。
185.若数据发送端的签约在签约有效期，则divs as根据第一数据和签约信息，确定数据完整性验证信息。
186.若数据发送端的签约不在签约有效期内，则divs as向数据发送端返回注册失败消息。
187.s506、divs as将数据完整性验证信息存储在区块链中。
188.基于此，在进行数据完整性验证之前，数据发送端可以通过与divs as交互，将数据完整性验证信息存储在区块链中。这样，在数据接收端请求数据完整性验证信息时，数据发送端可以从区块链中获取数据完整性验证信息，以避免数据完整性验证信息被篡改。
189.此外，divs as在将数据完整性验证信息存储在区块链之前，从运营商网络中获取数据发送端的签约信息，并对比数据发送端的终端信息和签约信息中的终端信息是否一致，在一致的情况下将数据完整性验证信息存储在区块链中。保证了divs as存储在区块链中的数据为数据发送端的数据完整性验证信息。
190.s507、divs as根据数据完整性验证信息在区块链中的存储信息，生成第一交易标识。
191.第一交易标识用于数据发送端确定第一标识。
192.s508、divs as向数据发送端发送第一交易标识。相应的，数据发送端接收来自divs as的第一交易标识。
193.可选的，divs as还可以向数据发送端发送divs as的地址信息，以便于数据发送端和数据接收端根据地址信息从divs as中获取数据完整性验证信息。具体包括：
194.s509、divs as生成第一地址信息；第一地址信息为存储第一交易标识对应的数据完整性验证信息的divs as的地址信息；
195.s510、divs as向数据发送端发送第一地址信息。相应的，数据发送端接收来自divs as的第一地址信息。
196.可选的，在数据发送端收到第一交易标识之后，数据发送端可以根据第一交易标识生成第一标识。
197.在数据发送端收到第一地址信息之后，数据发送端还可以将第一地址信息添加到目标数据中，以便于数据接收端根据第一地址信息确定存储数据发送端的数据完整性验证信息的divs as。
198.需要指出的是，上述以divs as分别生成和发送第一交易标识和第一地址信息为例进行说明，在实际过程中，divs as可以在分别生成第一交易标识和第一地址信息之后，在同一个消息中向数据发送端发送第一交易标识和第一地址信息。
199.基于此，divs as通过向数据发送端发送交易标识和divs as入口地址，可以使数据发送端根据交易标识生成第一标识，并在数据中携带divs as入口地址，使得数据接收端可以根据divs as入口地址向divs as获取数据完整性验证信息。
200.一种可能的实现方式中，在数据发送端的签约信息更新之后，本技术实施例还提供了一种根据更新后的签约信息，更新数据发送端的数据完整性验证信息的方法。
201.如图7所示，该方法包括：
202.s701、数据发送端esim签约更新触发udm订阅合约变更事件。
203.具体来说，若某个esim的安装终端需要更新签约信息，则会触发esim更新签约信息流程。udm监听到合约变更事件并指示nef该esim更新签约信息。
204.s702、udm向nef发送esim签约更新消息。
205.s703、nef向divs as发送签约信息更新消息。相应的，divs as接收来自nef的签约信息更新消息。
206.其中，签约信息更新消息包括：第二终端信息，以及数据发送端更新后的签约信息。
207.s704、divs as查询区块链中包括第二终端信息的最新目标数据完整性验证信息。
208.需要指出的是，本技术实施例中，最新目标数据完整性验证信息指的是最近一次更新的数据完整性验证信息。例如divs as可以根据数据完整性验证信息的时间标签确定最近一次更新的数据完整性验证信息，并将最近一次更新的数据完整性验证信息作为最新目标数据完整性验证信息。
209.s705、divs as根据更新后的签约信息，更新最新目标数据完整性验证信息。
210.一种具体的实现方式中，对每个目标数据完整性验证信息执行第一操作，确定更新后的每个目标数据完整性验证信息；
211.第一操作包括：根据第一数据和更新后的签约信息，生成第二待验证数据集；
212.根据第二私钥和第二签名算法对第二待签名数据集签名，确定第四数据签名；
213.根据第二待签名数据集，第二私钥对应的证书，以及第四数字签名，确定更新后的目标数据完整性验证信息。
214.s706、divs as将更新后的最新目标数据完整性验证信息存储在区块链中。
215.基于此，在数据发送端的签约信息变更之后，udm能够及时通知divs as进行签约信息的更新。在此之后，divs as将数据发送端更新的签约信息存储在区块链中，可以使得数据接收端根据更新后的签约信息验证待验证数据的数据完整性。
216.可选的，在s706之后，该方法还包括：
217.s707、divs as确定更新后的最新目标数据完整性验证信息。
218.s708、divs as根据更新后的最新目标数据完整性验证信息在区块链中的存储信息，生成更新后的最新目标数据完整性验证信息对应的第二交易标识；第二交易标识用于确定第一标识。
219.s709、divs as向数据发送端发送第二交易标识。
220.s710、divs as生成第二地址信息；第二地址信息为存储第二交易标识对应的更新后的数据完整性验证信息的divs as的地址信息。
221.s711、divs as向数据发送端发送第二地址信息。
222.基于此，divs as通过向数据发送端发送更新后的交易标识(第二交易标识)和divs as入口地址，可以使数据发送端根据更新后的交易标识生成第一标识，并在数据中携带divs as入口地址，使得数据接收端可以根据divs as入口地址向divs as获取更新后的数据完整性验证信息。
223.一种可能的实现方式中，在s707-s711之后，该方法还包括以下步骤：
224.s712、数据发送端根据第一交易标识和第二交易标识中最新的交易标识生成第一标识。
225.可选的，第二交易标识为根据最近一次更新的数据完整性验证信息在区块链中的存储信息生成的交易标识。此时，数据发送端根据第二交易标识生成第一标识。
226.s713、数据发送端根据第一地址信息和第二地址信息中最新的地址信息生成验证访问地址。
227.可选的，第二地址信息为存储第二交易标识对应的最近一次更新的数据完整性验证信息的divs as的地址信息。此时，数据发送端根据第二地址信息生成验证访问地址。
228.基于此，数据发送端可以根据更新后的交易标识生成第一标识，以使得数据接收端根据第一标识获取最新的数据完整性验证信息。同样的，数据发送端根据更新后的交易标识对应的divs as的地址生产验证访问地址，可以使得数据接收端快速准确的确定获取数据完整性验证信息的divs as。
229.如图8所示，本技术实施例提供的方法还包括：数据发送端在开户平台注册，确定签约信息。
230.s801、数据发送端用户向开户平台发送第三指示信息。相应的，开户平台接收来自数据发送端的第三指示信息。
231.其中，第三指示信息用于指示开户平台注册数据发送端的设备信息。
232.s802、开户平台根据第三指示信息生成第一终端信息。
233.s803、开户平台向数据发送端发送第一终端信息。相应的，数据发送端接收来自开户平台的第一终端信息。
234.基于此，数据发送端在运营商网络中完成签约，可以使得udm获得数据发送端的签约信息，以便于udm在数据完整性验证信息上链过程中为divs as提供验证依据。
235.以上对本技术实施例提供的技术方案进行了详细说明。
236.以下，将结合本技术实施例提供的数据完整性验证信息在垂直行业的具体应用，对本技术实施例提供的数据完整性验证方法进行详细说明。
237.在本公开实施例中，在垂直行业中根据本技术提供的数据完整性验证方法进行数据完整性验证的过程具体可以包括如下流程：
238.流程一、机器类型终端在运营商网络中签约的流程；流程二、数据完整性验证信息上链的流程；流程三、数据完整性验证信息更新的流程；流程四、数据完整性验证的流程。以下分别对上述流程进行说明：
239.流程一、机器类型终端在运营商网络中签约的流程。
240.如图9所示，机器类型终端在运营商网络中签约的流程包括以下s901-s904。
241.s901、机器类型终端向开户平台发送设备签约信息。
242.设备签约信息包括以下至少一项：common name、位置(国家、地区)、归属组织名称、邮箱地址。
243.s902、开户平台为机器类型终端开户。
244.具体包括：机器类型终端在开户平台中开户，注册机器类型终端的euicc id、imei、设备序列号sn、设备归属实体名称、部署位置、联系邮箱等信息。
245.开户平台触发esim管理平台生成esim profile及安全applet。esim管理平台生成
esim profile的过程中，为机器类型终端分配iccid。
246.开户平台绑定iccid与imei、euicc id。
247.需要指出的是，上述过程中所需的信息包括以下至少之一：common name、位置(国家、地区)、归属组织名称、邮箱地址。
248.s903、机器类型终端接入运营商网络，获取并安装esim profile及安全applet。
249.一种具体的实现方式中，机器类型终端接入运营商网络后，向esim管理平台请求下载esim profile及安全applet。下载完成之后，机器类型终端在euicc中安装esim profile及安全applet。
250.这样，机器类型终端可以通过esim使用网络服务，通过applet生成密钥对，对需要加密的数据进行加密。
251.s904、开户平台向udm发送签约信息。相应的，udm接收并存储机器类型终端的签约信息。
252.这样，udm中存储机器类型终端的签约信息之后，可以为divs as发送机器类型中的签约信息，以使得divs as根据签约信息验证机器类型终端。
253.需要指出的是，上述s901-s904的具体实现方式可以与上述s801-s803相互参考，本技术对此不在赘述。
254.以上，对机器类型终端在运营商网络中进行签约的过程进行了描述，基于该过程，通过绑定iccid与imei、euicc id，可以通过上述信息完成对机器类型终端的唯一标识。在此之后，divs as和数据消费终端可以基于上述信息对机器类型终端进行验证。
255.流程二、数据完整性验证信息上链的流程。
256.如图10所示，数据完整性验证信息上链的流程可以通过以下s1001-s1012实现。
257.s1001、机器类型终端生成第一密钥对。
258.一种可能的实现方式中，机器类型终端调用euicc中的安全applet，生成第一密钥对(基于ecc或者rsa)。第一密钥对包括第一公钥和第一私钥。
259.需要指出的是，第一私钥将始终存储在安全applet中，不可被机器类型终端或其他设备获取，这样可以避免其他设备窃取到第一私钥之后根据第一私钥向数据消费终端发送数据。
260.s1002、机器类型终端获取元数据，并根据元数据生成第一数据。
261.元数据包括以下至少之一：第一公钥、iemi、iccid、euicc id、设备序列号sn、msisdn。
262.一种可能的实现方式中，机器类型终端应用程序通过adpu指令获取安全applet生成的第一公钥。机器类型终端从操作系统接口和通信模组接口，获取机器类型终端的第一终端信息，包括以下至少之一：iemi、iccid、euicc id、设备序列号sn、msisdn。
263.其中，第一数据包括：元数据、对元数据进行签名的第一签名算法，以及对元数据进行签名后得到的第一数字签名。
264.一种可能的实现方式中，机器类型终端应用程序向安全applet发送元数据。安全applet根据公私密钥对中的第一私钥以及第一签名算法对元数据进行数字签名，得到第一数字签名。
265.机器类型终端根据元数据、第一签名算法和第一数字签名，生成第一数据。
266.s1003、机器类型终端向divs as发送第二指示信息。
267.其中，第二指示信息用于承载第一数据。
268.一种可能的实现方式中，第二指示信息为：ndivs as_devicemetadata_registration。
269.可选的，第二指示信息携带的数据如下述表1所示。
270.表1
271.[0272][0273]
s1004、divs as根据第一公钥和第一数字签名验证第一数据。
[0274]
可选的，divs as根据第一公钥解密第一数字签名，得到解密数据。divs as确定解密数据与元数据或者元数据的哈希是否一致，若一致，则确定验证成功。
[0275]
s1005、divs as向nef发送第一签约请求信息。
[0276]
其中，签约请求信息用于请求获取机器类型终端的签约信息。
[0277]
可选的，divs as通过查询接口(rp-edi)访问nef。访问消息中携带msisdn、iccid及imei，请求获取该msisdn、iccid及imei对应的机器类型终端的签约信息。
[0278]
一种可能的实现方式中，签约请求信息为：nnef_subscribersdata_request。
[0279]
可选的，nnef_subscribersdata_request携带的数据如下述表2所示。
[0280]
表2
[0281][0282]
s1006、nef向udm发送第二签约请求消息。
[0283]
具体来说，nef根据第二签约请求消息中的用户标识，确定机器类型终端归属的udm。nef向归属的udm发送第二签约请求消息。
[0284]
可选的，nef向udm转发msisdn、iccid及imei中的至少一项，请求获取该msisdn、iccid及imei中的至少一项对应的机器类型终端的签约信息。udm通过msisdn、iccid及imei中的至少一项，查询具有该msisdn、iccid及imei中的至少一项信息的签约信息，并将查询到的签约信息返回给nef。
[0285]
一种可能的实现方式中，第二签约请求消息为nusm_subscribersdata_request。
[0286]
可选的，nusm_subscribersdata_request携带的数据如下述表3所示。
[0287]
表3
[0288]
[0289][0290]
s1007、udm向nef发送第一签约响应消息。
[0291]
具体来说，udm接收到第二签约请求消息之后，查询与第二签约请求消息承载的msisdn、iccid及imei中的至少一项对应的签约数据，并根据查询到的签约数据生成第一签约响应消息，udm向nef发送第一签约响应消息。
[0292]
一种可能的实现方式中，第一签约响应消息为nusm_subscribersdata_response。
[0293]
可选的，nusm_subscribersdata_response携带的数据如下述表4所示。
[0294]
表4
[0295]
[0296][0297]
需要指出的是，若udm无法查询到msisdn、iccid及imei中的至少一项对应的签约数据，则向nef返回失败消息。
[0298]
s1008、nef向divs as发送第二签约响应消息。
[0299]
具体来说，nef接收到来自udm的第一签约响应消息之后，根据第一签约响应消息生成第二签约响应消息，并向divs as发送第二签约响应消息。
[0300]
一种可能的实现方式中，第二签约响应消息为nnef_subscribersdata_response。
[0301]
可选的，nnef_subscribersdata_response携带的数据如下述表5所示。
[0302]
表5
[0303]
[0304][0305]
需要指出的是，若nef未接收到来自udm的第一签约响应消息，则向divs as返回失败消息。
[0306]
s1009、divs as确定元数据中的第一终端信息和签约信息中的第二终端信息是否一致，并在一致的情况下生成第一待签名数据集。
[0307]
具体来说，divs as比较元数据中的iemi及msisdn、iccid与签约信息中的iemi及msisdn、iccid比较，确定是否一致。若一致，则将元数据、签约信息和公钥以及第一签名算法信息作为第一待签名数据集。
[0308]
可选的，divs as可以直接将元数据、签约信息和公钥以及第一签名算法信息作为第一待签名数据集，也可以架构元数据、签约信息和公钥以及第一签名算法信息的哈希值作为第一待签名数据集。本技术对此不做限定。
[0309]
s1010、divs as根据第一待签名数据集生成数据完整性验证信息，并将数据完整性验证信息上传到区块链账本中。
[0310]
具体来说，divs as根据区块链账本的第二私钥和第二签名算法对第一待签名数据集签名，生成第二数字签名。divs as将第一待签名数据集、第二数字签名、以及第二私钥的ca证书作为数据完整性验证信息上传到区块链账本中。
[0311]
需要指出的是，区块链账本中包括数据完整性验证信息的前一个交易标识(transation id)。在将数据完整性验证信息上传到区块链账本中之后，divs as将数据完整性验证信息的前一个交易标识的值设置为空，将记录状态设置为可用。
[0312]
s1011、divs as生成数据完整行验证信息的交易标识。
[0313]
s1012、divs as向机器类型终端发送交易标识。
[0314]
可选的，divs as还生成divs as入口的url，同步向机器类型终端发送url和交易标识。
[0315]
一种可能的实现方式中，交易标识和url承载在divs as向机器类型终端发送的ndivs as_devicemetadata_registration_response消息中。
[0316]
可选的，ndivs as_devicemetadata_registration_response携带的数据如下述表6所示。
[0317]
表6
[0318][0319][0320]
需要指出的是，机器类型终端在接收到交易标识和url之后，可以将交易标识和url存储在euicc中的安全applet中。
[0321]
需要指出的是，在上述流程二中，divs as提供的第二私钥对应的证书可以是由区块链系统成员管理基于公私密钥对生成的ca证书，也可以是权威ca结构生成的ca证书，也可以是自签名的ca证书，本技术对此不做限定。
[0322]
可选的，第二签名算法和第一签名算法可以为相同的签名算法。
[0323]
可选的，区块链账本中包含区块链客户端，客户端用于执行区块链账本数据读写及智能合约的执行。
[0324]
可以理解的是，上述信令消息可以通过http get方法传输。
[0325]
需要指出的是，在上述流程二中，机器类型终端和divs as之间可以通过打通专用数据接口实现数据通信。相应的divs as与nef之间也可以通过打通专用数据接口实现数据通信。nef和udm之间可以通过增强现有接口功能实现本公开涉及的nef和udm之间的交互功能。
[0326]
流程三、数据完整性验证信息更新的流程。
[0327]
如图11所示，divs as首先向udm发起签约数据事件订阅/解除订阅。在数据发送端签约数据更新之后udm将通知divs as用户签约信息更新。具体包括以下步骤：
[0328]
s1101、divs as向nef发送第一签约数据事件订阅/解除订阅。
[0329]
第一签约数据事件订阅/解除订阅消息中携带有用户标识数据msisdn等机器类型终端标识数据。
[0330]
一种可能的实现方式中，第一签约数据事件订阅为：nnef_eventexposure_subscriberssigndata_subscriberequest。
[0331]
第一签约数据事件解除订阅为：nnef_eventexposure_subscriberssigndata_unsubscriberequest
[0332]
可选的，nnef_eventexposure_subscriberssigndata_subscriberequest携带的数据如下述表7所示。
[0333]
表7
[0334][0335][0336]
s1102、nef向udm发送第二签约数据事件订阅/解除订阅。
[0337]
具体来说，nef基于第一签约数据事件订阅/解除订阅请求中的用户标识，查询归
属用户数据存储网元udm。nef进行用户标识翻译，将用户标识翻译成imsi或者supi，将nnef_eventexposure_subscriberssigndata_subscriberequest消息转换为：nusm_eventexposure_subscriberssigndata_subscriberequest，转换后的消息中携带nnef_eventexposure_subscriberssigndata_subscriberequest消息所携带的参数。
[0338]
可选的，nusm_eventexposure_subscriberssigndata_subscriberequest携带的数据如下述表8所示。
[0339]
表8
[0340][0341][0342]
需要指出的是，第二签约数据事件解除订阅为：nusm_eventexposure_subscriberssigndata_unsubscriberequest。
[0343]
s1103、udm向nef发送第一签约数据事件订阅/解除订阅响应。
[0344]
具体来说，udm基于用户标识进行用户签约数据事件监测，并向nef发送第一签约数据事件订阅/解除订阅响应。
[0345]
一种可能的实现方式中，第一签约数据事件订阅响应为nusm_eventexposure_subscriberssigndata_subscriberesponse。
[0346]
可选的，nusm_eventexposure_subscriberssigndata_subscriberequest携带的数据如下述表9所示。
[0347]
表9
[0348][0349]
需要指出的是，第一签约数据事件/解除订阅响应为：nusm_eventexposure_subscriberssigndata_unsubscriberequest。
[0350]
s1104、nef向divs as发送第二签约数据事件订阅/解除订阅响应。
[0351]
一种可能的实现方式中，第二签约数据事件订阅响应为：nnef_eventexposure_subscriberssigndata_subscriberesponse。
[0352]
可选的，nnef_eventexposure_subscriberssigndata_subscriberesponse携带的数据如下述表10所示。
[0353]
表10
[0354][0355]
需要说明的是，用户签约事件变化主要包括以下情况：
[0356]
情况1、esim卡注销或者去激活。
[0357]
情况2、用户账户注销。
[0358]
情况3、esim与imei绑定分离。
[0359]
情况4、esim绑定的euicc发生变化。
[0360]
情况5、iccid对应的msisdn变化。
[0361]
情况6、applet去激活。
[0362]
情况7、其他。
[0363]
需要说明的是，上述信令用于是divs as向nef订阅用户签约信息改变通知，nef向udm订阅用户签约信息改变通知(divs as无法直接向udm订阅)。一旦udm中涉及订阅的msisdn的签约注销、机卡绑定变更等信息，udm将被触发主动发送通知。
[0364]
可以理解的是，上述信令消息采用可以http post方法传输。
[0365]
可以理解的是，以上主要以订阅为例进行说明，解除订阅的过程中流程和信令内容类似，本公开不再赘述。
[0366]
以上结合s1001-s1004介绍了divs as向udm进行时间订阅的过程。以下，对udm在签约数据更新后进行事件通知的过程进行说明。
[0367]
s1105、esim签约注销触发udm监控事件。
[0368]
具体来说，若某个esim的安装终端需要注销，则会触发esim签约注销流程。udm指示nef，该esim签约注销。
[0369]
s1106、udm向nef发送第一esim签约注销消息。
[0370]
其中，第一esim签约注销消息包括以下至少之一：iccid、msisdn及绑定imei、esim签约注销时间。
[0371]
一种可能的实现方式中，第一esim签约注销消息为nusm_eventexposure_subscriberssigndata_notify。
[0372]
可选的，nusm_eventexposure_subscriberssigndata_notify携带的数据如下述表11所示。
[0373]
表11
[0374][0375]
s1107、nef向divs as发送第二esim签约注销消息。
[0376]
具体来说，nef触发订阅通知事件，向divs as发送第二esim签约注销消息。
[0377]
一种可能的实现方式中，第二esim签约注销消息为：nnef_eventexposure_
subscriberssigndata_notify。
[0378]
可选的，nusm_eventexposure_subscriberssigndata_notify携带的数据如下述表12所示。
[0379]
表12
[0380][0381]
s1108、divs as根据第二esim签约注销消息，确定对应的交易标识。
[0382]
具体来说，divs as接收到第二esim签约注销消息之后，获取第二esim签约注销消息中的iccid、msisdn和imei。divs as确定iccid、msisdn和imei关联的全部交易标识。
[0383]
s1109、divs as更新交易标识对应的第一待签名数据集，得到第二待签名数据集。
[0384]
具体来说，divs as更新每个交易标识对应的第一待签名数据集中的esim签约注销时间，并将更新后的第一待签名数据集作为第二待签名数据集。
[0385]
divs as根据第二私钥、第二签名算法对第二待签名数据集进行签名，得到第四数字签名。
[0386]
s1110、divs as将第二待签名数据集、第四数字签名、以及第二私钥的ca证书作为更新后的数据完整性验证信息上传到区块链账本中。
[0387]
s1111、divs as生成更新后的数据完整性验证信息的交易标识。
[0388]
s1112、divs as向机器类型终端发送更新后的数据完整性验证信息的交易标识。
[0389]
其中，s1111和s1112的具体实现方式可以参照上述s1010和s1011，此处不再赘述。
[0390]
以上，对签约信息更新的过程进行了说明。
[0391]
流程四、数据完整性验证的流程。
[0392]
如图12所示，数据完整性验证的流程具体可以通过以下s1201-s1207实现。
[0393]
s1201、机器类型终端获取待验证数据。
[0394]
可选的，机器类型终端采集数据之后，将采集到的数据作为待验证数据
[0395]
s1202、机器类型终端根据待验证数据生成目标数据。
[0396]
具体包括：机器类型终端采用第一私钥和第一签名算法对待验证数字签名，得到
第一数字签名。
[0397]
机器类型终端调用adpu指令，将数据发送到安全applet中，使用第一私钥以及第一签名算法对待验证数据进行签名，得到第一数字签名，以及第一数字签名的时间戳。
[0398]
s1203、机器类型终端向数据消费终端发送目标数据。
[0399]
具体来说，机器类型终端根据待验证数据、第一数字签名、第一数字签名的时间戳、以及第一标识生成目标数据。
[0400]
机器类型终端向数据消费终端发送目标数据。
[0401]
需要指出的是，机器类型终端可以通过直接将目标数据发送给数据消费终端，也可以通过其他设备转发后将目标数据发送给数据消费终端，本技术对此不做限定。
[0402]
s1204、数据消费终端向divs as发送数据完整性验证信息请求消息。
[0403]
其中，数据完整性验证信息请求消息中包括第一标识。
[0404]
一种可能的实现方式中，数据完整性验证信息请求消息为：ndivs_intergrityverification_request。
[0405]
可选的，ndivs_intergrityverification_request携带的数据如下述表13所示。
[0406]
表13
[0407][0408][0409]
s1205、divs as查询第一标识关联的数据完整性验证信息。
[0410]
具体来说，divs as接收到请求消息之后，确定第一标识。divs as查询区块链账本中与第一标识关联的数据完整性验证信息。
[0411]
可选的，divs as首先查询查询区块链账本中与第一标识数据完整性验证信息，并确定数据完整性验证信息中的元数据。然后divs as基于元数据中的iemi、msisdn、iccid，确定更新后的数据完整性验证信息。
[0412]
divs as将数据完整性验证信息和更新后的数据完整性验证信息共同发送给数据消费终端
[0413]
s1206、divs as向数据消费终端发送数据完整性验证信息。
[0414]
一种可能的实现方式中，数据完整性验证信息请求消息为：ndivs_intergrityverification_response。
[0415]
可选的，ndivs_intergrityverification_response携带的数据如下述表14所示。
[0416]
表14
[0417]
[0418][0419]
s1207、数据消费终端根据数据完整性验证信息验证待验证数据的数据完整性。
[0420]
具体来说，divs as在接收到数据完整性验证信息之后，根据数据完整性验证信息中的第二公钥和第一私钥的ca整数验证第三数字签名或第四数字签名。验证成功之后，获取数据完整性验证信息中的第一公钥，根据第一公钥和第一签名算法验证第一数字签名。在第一数字签名验证通过之后，确定第一数字签名的时间戳是否在机器类型终端的签约有效期内。若是，则确定待验证数据的数据完整性验证成功。
[0421]
可以理解的是，上述信令消息可以通过http get的方法传输。
[0422]
以上，对本技术实施例涉及到的数据完整性验证系统，以及数据完整性验证系统中各个设备的功能，设备之间的交互进行了详细说明。
[0423]
可以看出，上述主要从方法的角度对本技术实施例提供的技术方案进行了介绍。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，本技术实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术
人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
[0424]
本技术实施例可以根据上述方法示例对数据完整性验证装置(数据完整性验证装置可以是上述涉及到的数据发送端、数据接收端。divs as、nef或者udm中的任一个)进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。可选的，本技术实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
[0425]
如图13所示，为本技术实施例提供的一种数据完整性验证装置的结构示意图，该数据完整性验证装置可以是上述divs as。该数据完整性验证装置包括：通信单元1301和处理单元1302。
[0426]
通信单元1301，用于接收来自数据接收端的第一指示信息；第一指示信息用于指示数据完整性验证服务器divs as查询第一标识对应的数据完整性验证信息，第一标识为数据发送端的数据完整性验证信息在divs as中的存储标识；处理单元1302，用于查询第一标识对应的数据完整性验证信息；处理单元1302，还用于指示通信单元1301向数据接收端发送数据完整性验证信息。
[0427]
在一种可能的实现方式中，第一标识归属于数据发送端向数据接收端发送的目标数据；目标数据包括待验证数据、第一数字签名和第一标识；第一数字签名为根据第一私钥对待验证数据签名后生成的数字签名；第一私钥为数据发送端生成的第一密钥对中的私钥；数据完整性验证信息包括第一公钥，第一公钥为数据发送端生成的第一密钥对中的公钥。
[0428]
在一种可能的实现方式中，该装置还包括：通信单元1301，还用于接收来自数据发送端的第二指示信息；第二指示信息用于承载第一数据；第一数据包括第一公钥，数据发送端支持的签名算法集和数据发送端的第一终端信息；通信单元1301，还用于根据第二指示信息中的第一终端信息，获取数据发送端的签约信息；签约信息包括：数据发送端的签约有效性信息；处理单元1302，还用于根据第一数据和签约信息，确定数据完整性验证信息；处理单元1302，还用于将数据完整性验证信息存储在区块链中。
[0429]
在一种可能的实现方式中，通信单元1301，具体用于：向能力开放平台nef发送签约信息获取请求；签约信息获取请求中包括第一终端信息；接收来自nef的签约信息；签约信息为nef返回的根据第一终端信息在用户数据管理网元udm中获取的数据发送端的签约信息。
[0430]
在一种可能的实现方式中，第一数据中还包括第二数字签名；第二数字签名为根据第一公钥和第一签名算法对第一公钥和第一终端信息签名后生成的数字签名；处理单元1302，还用于：根据第一公钥和第一签名算法，验证第二数字签名；在第二数字签名验证通过的情况下，获取第一数据中的第一终端信息；根据第一终端信息生成签约信息获取请求。
[0431]
在一种可能的实现方式中，处理单元1302，具体用于：根据第一数据和签约数据生成第一待签名数据集；根据第二私钥和第二签名算法对第一待签名数据集签名，确定第三数字签名；第二私钥归属于divs as生成的第二密钥对；根据第一待签名数据集、第二私钥对应的证书、以及第三数字签名，确定数据完整性验证信息。
[0432]
在一种可能的实现方式中，通信单元1301，还用于：向数据发送端发送第一交易标识；其中，第一交易标识用于表征数据完整性验证信息在区块链中的存储信息。
[0433]
在一种可能的实现方式中，通信单元1301，还用于：向数据发送端发送第一地址信息；其中，第一地址信息为存储第一交易标识对应的数据完整性验证信息的divs as的地址信息。
[0434]
在一种可能的实现方式中，通信单元1301，还用于：接收来自nef的签约信息更新消息；签约信息更新消息包括：第二终端信息，以及数据发送端更新后的签约信息；处理单元1302，还用于查询区块链中包括第二终端信息的最新目标数据完整性验证信息；处理单元1302，还用于根据更新后的签约信息，更新最新目标数据完整性验证信息；处理单元1302，还用于将更新后的最新目标数据完整性验证信息存储在区块链中。
[0435]
在一种可能的实现方式中，处理单元1302，还用于：对最新目标数据完整性验证信息执行第一操作，确定更新后的最新目标数据完整性验证信息；第一操作包括：根据第一数据和更新后的签约信息，生成第二待验证数据集；根据第二私钥和第二签名算法对第二待签名数据集签名，确定第四数据签名；根据第二待签名数据集，第二私钥对应的证书，以及第四数字签名，确定更新后的最新目标数据完整性验证信息。
[0436]
在一种可能的实现方式中，通信单元1301，还用于：向数据发送端发送第二交易标识；其中，第二交易标识用于表征更新后的最新目标数据完整性验证信息在区块链中的存储信息。
[0437]
在一种可能的实现方式中，通信单元1301，还用于：向数据发送端发送第二地址信息；其中，第二地址信息为存储更新后的最新目标数据完整性验证信息的divs as的地址信息。
[0438]
其中，处理单元1302可以是处理器或控制器。其可以实现或执行结合本技术公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包括一个或多个微处理器组合，dsp和微处理器的组合等等。通信单元1301可以是收发电路或通信接口等。存储模块可以是存储器。当处理单元1302为处理器，通信单元1301为通信接口，存储模块为存储器时，本技术实施例所涉及的数据完整性验证装置可以为图3-图12所示的divs as。
[0439]
如图14所示，为本技术实施例提供的一种数据完整性验证装置的结构示意图，该数据完整性验证装置可以是上述数据接收端。该数据完整性验证装置包括：通信单元1401和处理单元1402。
[0440]
通信单元1401和处理单元1402；通信单元1401，用于接收来自数据发送端的目标数据；目标数据包括：待验证数据、第一数字签名和第一标识；其中，第一数字签名为根据第一私钥对待验证数据进行签名确定的数字签名；第一标识为数据发送端的数据完整性验证信息在divs as中的存储标识；第一私钥为数据发送端生成的第一密钥对中的私钥；处理单元1402，用于指示通信单元1401向divs as发送第一指示信息；述第一指示信息用于指示divs as查询第一标识对应的数据完整性验证信息；处理单元1402，还用于指示通信单元1401接收来自divs as的数据完整性验证信息。
[0441]
在一种可能的实现方式中，数据完整性验证信息中包括第一公钥；第一公钥为数据发送端生成的第一密钥对中的公钥；处理单元1402，还用于：根据数据完整性验证信息中
的第一公钥，验证第一数字签名；根据第一数字签名的验证结果，确定待验证数据的数据完整性。
[0442]
在一种可能的实现方式中，目标数据还包括第一数字签名的时间戳；数据完整性验证信息还包括：数据发送端的签约有效期；处理单元1402，还用于：确定第一数字签名的时间戳是否在数据发送端的签约有效期内；若是，则确定待验证数据的数据完整性验证成功。
[0443]
在一种可能的实现方式中，数据完整性验证信息具体包括：第一待签名数据集，第二私钥对应的证书，第三数字签名；其中，第一待签名数据集包括第一数据和签约信息；第一数据包括第一公钥，数据发送端支持的签名算法集和数据发送端的第一终端信息；签约信息包括：数据发送端的签约有效性信息和数据发送端的第二终端信息；第二私钥为divs as生成的第二密钥对中的私钥；第三数字签名为根据第二私钥和第二签名算法对第一待签名数据集签名后生成的数字签名；处理单元1402，还用于：根据第二私钥对应的证书和第二签名算法验证第三数字签名；在第三数字签名验证成功的情况下，获取第一待签名数据集中的第一公钥。
[0444]
其中，处理单元1402可以是处理器或控制器。其可以实现或执行结合本技术公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包括一个或多个微处理器组合，dsp和微处理器的组合等等。通信单元1401可以是收发电路或通信接口等。存储模块可以是存储器。当处理单元1402为处理器，通信单元1401为通信接口，存储模块为存储器时，本技术实施例所涉及的数据完整性验证装置可以为图3-图12所示的数据接收端。
[0445]
如图15所示，为本技术实施例提供的一种数据完整性验证装置的结构示意图，该数据完整性验证装置可以是上述数据发送端端。该数据完整性验证装置包括：通信单元1501，和处理单元1502。
[0446]
通信单元1501和处理单元1502；处理单元1502，用于生成目标数据；其中，目标数据包括待验证数据，第一数字签名和第一标识；第一数字签名为根据第一私钥对待验证数据签名后生成的数字签名；第一私钥为数据发送端生成的第一密钥对中的私钥；第一标识为数据发送端的数据完整性验证信息在divs as中的存储标识；通信单元1501，用于向数据接收端发送目标数据，以使得数据接收端根据第一标识和第一数字签名确定待验证数据的数据完整性。
[0447]
在一种可能的实现方式中，处理单元1502，还用于生成第一数据；第一数据包括第一公钥，数据发送端支持的签名算法集和数据发送端的第一终端信息；处理单元1502，还用于生成包括第一数据的第二指示信息；通信单元1501，还用于向divs as发送第二指示信息。
[0448]
在一种可能的实现方式中，处理单元1502，具体用于：生成第一密钥对；第一密钥对包括第一公钥和第一私钥；获取数据发送端的第一终端信息；根据第一私钥和第一签名算法对第一公钥和第一终端信息签名，确定第二数字签名；根据第一公钥，第一终端信息，数据发送端支持的签名算法集，和第二数字签名生成第一数据。
[0449]
在一种可能的实现方式中，通信单元1501，还用于接收来自divs as的第一交易标识和第二交易标识中的至少之一；第一交易标识为根据数据完整性验证信息在区块链中的
存储信息生成的交易标识；第二交易标识为根据更新后的数据完整性验证信息在区块链中的存储信息生成的交易标识；处理单元1502，还用于根据第一交易标识和第二交易标识中的最新的交易标识，生成第一标识。
[0450]
在一种可能的实现方式中，目标数据还包括验证访问地址；验证访问地址用于表征存储数据发送端的数据完整性验证信息的divs as的地址；通信单元1501，还用于接收来自divs as的第一地址信息和第二地址信息中的至少之一；第一地址信息为存储第一交易标识对应的数据完整性验证信息的divs as的地址信息；第二地址信息为存储第二交易标识对应的更新后的数据完整性验证信息的divs as的地址信息；处理单元1502，还用于根据第一地址信息和第二地址信息中的最新的地址生成验证访问地址。
[0451]
在一种可能的实现方式中，第一终端信息包括数据发送端的嵌入式通用集成电路卡标识euicc id/集成电路卡识别码iccid、国际移动设备识别码imei和移动用户号码msisdn的至少之一。
[0452]
其中，处理单元1502可以是处理器或控制器。其可以实现或执行结合本技术公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包括一个或多个微处理器组合，dsp和微处理器的组合等等。通信单元1501可以是收发电路或通信接口等。存储模块可以是存储器。当处理单元1502为处理器，通信单元1501为通信接口，存储模块为存储器时，本技术实施例所涉及的数据完整性验证装置可以为图3-图12所示的数据发送端。
[0453]
本技术实施例提供了一种电子设备，用于执行上述数据完整性确定系统中任一设备所需执行的方法。该电子设备可以是数据发送端、数据接收端、divs as，nef或者udm等，本技术对此不做限定。该电子设备可以为本技术中涉及的电子设备，或者电子设备中的模块；或者是电子设备中的芯片，也可以是其他用于执行网络质量确定方法的装置，本技术对此不做限定。
[0454]
图16为本技术实施例提供的一种电子设备的结构示意图。如图16所示，该电子设备100包括至少一个处理器101，通信线路102，以及至少一个通信接口104，还可以包括存储器103。其中，处理器101，存储器103以及通信接口104三者之间可以通过通信线路102连接。
[0455]
处理器101可以是一个中央处理器(central processing unit，cpu)，也可以是特定集成电路(application specific integrated circuit，asic)，或者是被配置成实施本技术实施例的一个或多个集成电路，例如：一个或多个数字信号处理器(digital signal processor，dsp)，或，一个或者多个现场可编程门阵列(field programmable gate array，fpga)。在具体实现时，处理器101可以执行上述图13中的处理单元1302执行的动作，图14中的处理单元1402执行的动作，或者图15中的处理单元1502执行的动作。
[0456]
通信线路102可以包括一通路，用于在上述组件之间传送信息。
[0457]
通信接口104，用于与其他设备或通信网络通信，可以使用任何收发器一类的装置，如以太网，无线接入网(radio access network，ran)，无线局域网(wireless local area networks，wlan)等。在具体实现时，通信接口104可以执行上述图13中的通信单元1301执行的动作，图14中的通信单元1401执行的动作，或者图15中的通信单元1501执行的动作。
[0458]
存储器103可以是只读存储器(read-only memory，rom)或可存储静态信息和指令
的其他类型的静态存储设备，随机存取存储器(random access memory，ram)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、只读光盘(compact disc read-only memory，cd-rom)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于包括或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。
[0459]
一种可能的设计中，存储器103可以独立于处理器101存在，即存储器103可以为处理器101外部的存储器，此时，存储器103可以通过通信线路102与处理器101相连接，用于存储执行指令或者应用程序代码，并由处理器101来控制执行，实现本技术下述实施例提供的网络质量确定方法。又一种可能的设计中，存储器103也可以和处理器101集成在一起，即存储器103可以为处理器101的内部存储器，例如，该存储器103为高速缓存，可以用于暂存一些数据和指令信息等。
[0460]
作为一种可实现方式，处理器101可以包括一个或多个cpu，例如图16中的cpu0和cpu1。作为另一种可实现方式，电子设备100可以包括多个处理器，例如图16中的处理器101和处理器107。作为再一种可实现方式，电子设备100还可以包括输出设备105和输入设备106。
[0461]
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将网络节点的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，模块和网络节点的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0462]
本技术实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当计算机执行该指令时，该计算机执行上述方法实施例所示的方法流程中的各个步骤。
[0463]
本技术的实施例提供一种包含指令的计算机程序产品，当指令在计算机上运行时，使得计算机执行上述方法实施例中的通信方法。
[0464]
本技术的实施例提供一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行计算机程序或指令，以实现如上述方法实施例中的通信方法。
[0465]
其中，计算机可读存储介质，例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘。随机存取存储器(random access memory，ram)、只读存储器(read-only memory，rom)、可擦式可编程只读存储器(erasable programmable read only memory，eprom)、寄存器、硬盘、光纤、便携式紧凑磁盘只读存储器(compact disc read-on ly memory，cd-rom)、光存储器件、磁存储器件、或者上述的人以合适的组合、或者本领域数值的任何其他形式的计算机可读存储介质。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于特定用途集成电路(application specific integ rated circuit，asic)中。在本发明实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
[0466]
由于本发明的实施例中的装置、设备、计算机可读存储介质、计算机程序产品可以应用于上述方法，因此，其所能获得的技术效果也可参考上述方法实施例，本技术实施例在此不再赘述。
[0467]
以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何在本技术揭露的技术范围内的变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应该以权利要求的保护范围为准。