WO2023231782A1

WO2023231782A1 - Data integrity verification system

Info

Publication number: WO2023231782A1
Application number: PCT/CN2023/094845
Authority: WO
Inventors: 薛淼; 王光全; 任梦璇; 任杰; 马少武
Original assignee: 中国联合网络通信集团有限公司
Priority date: 2022-05-30
Filing date: 2023-05-17
Publication date: 2023-12-07
Also published as: CN114826772B; CN114826772A

Abstract

The present application relates to the technical field of communications. Provided is a data integrity verification system, which can verify the data integrity in a data circulation process. The system comprises a data sending end, a data receiving end and a DIVS AS. The data sending end is configured to send target data to the data receiving end, wherein the target data comprises data to be verified, a first digital signature and a first identifier; the data receiving end is configured to receive the target data and send the first identifier to the DIVS AS; the DIVS AS is configured to receive the first identifier and query data integrity verification information associated with the first identifier; and the data receiving end is configured to receive the data integrity verification information, verify the first digital signature according to a first public key in the data integrity verification information, and determine, according to a verification result of the first digital signature, the data integrity of the data to be verified. The embodiments of the present application are used in a data integrity verification process.

Description

Data integrity verification system

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on May 30, 2022, with application number 202210603461.2 and the application name "Data Integrity Verification System", the entire content of which is incorporated into this application by reference.

Technical field

The present application relates to the field of communication technology, and in particular, to a data integrity verification system.

Background technique

In related technologies, after the data sending end collects data, it often needs to send the data to a specific terminal, and the specific terminal forwards or flows the data to the data receiving end. However, the data receiving end cannot verify the data integrity of the received data after receiving the data. As a result, the data receiving end cannot determine whether the received data is the original data sent by the data sending end, and whether the specific terminal has tampered with the data during the forwarding process. Therefore, how the data receiving end verifies the data integrity of the received data has become an urgent problem to be solved.

Contents of the invention

This application provides a data integrity verification system that verifies the data integrity after the data receiving end receives the data.

In order to achieve the above purpose, this application adopts the following technical solutions:

In a first aspect, the present disclosure provides a data integrity verification system, which includes: a data sending end, a data integrity verification server DIVS AS, and a data receiving end.

Wherein, the data sending end is configured to: send target data to the data receiving end; the target data includes: data to be verified, a first digital signature and a first identification; wherein the first digital signature is data to be verified based on the first private key The digital signature for signature confirmation; the first identifier is the storage identifier of the data integrity verification information of the data sender in the DIVS AS; the first private key is the private key in the first key pair generated by the data sender.

The data receiving end is configured to receive the target data and send the first identifier to the DIVS AS.

DIVS AS is configured to: receive the first identification and query the data integrity verification information associated with the first identification; the data integrity verification information includes the first public key; the first public key is the first key generated by the data sending end The public key of the pair.

The data receiving end is configured to: receive data integrity verification information, verify the first digital signature according to the first public key in the data integrity verification information, and determine the data integrity of the data to be verified based on the verification result of the first digital signature. sex.

The above solution at least brings the following beneficial effects: In the embodiment of the present disclosure, after collecting the data, the data sending end uses the first private key to digitally sign the data, and then sends the digital signature and the data to be verified to the data receiving end. After receiving the data, the data receiving end obtains the data integrity verification information of the data sending end from the DIVS AS, and uses the first public key in the data integrity verification information to verify the first digital signature. If the verification is successful, it means that according to the A digital signature is a signature based on a first private key, and the first private key is an internal key of the data sending end and cannot be stolen by the outside. Therefore, if the verification of the first digital signature is successful, it means that the first digital signature is the digital signature obtained by the data sending end after signing the data to be verified, and therefore the data to be verified is the original data sent by the data sending end. Based on this, the data receiving end can determine whether the received data is the original data sent by the data sending end according to this method, thereby effectively verifying the data integrity of the data to be verified.

Combined with the above first aspect, in a possible implementation, the data sending end is also configured to: send the first data to the DIVS AS; the first data includes: a first public key, a set of signature algorithms supported by the data sending end and the first terminal information of the data sending end; the DIVS AS is also configured to: obtain the contract information of the data sending end according to the first terminal information; the contract information includes: the contract validity information of the data sending end; according to the first data and the contract information, determine Data integrity verification information; store data integrity verification information in the blockchain.

Based on this, before performing data integrity verification, the data sending end can store the data integrity verification information in the blockchain by interacting with DIVS AS. In this way, when the data receiving end requests data integrity verification information, the data receiving end can obtain the data integrity verification information from the blockchain to prevent the data integrity verification information from being tampered with.

Combined with the above first aspect, in a possible implementation, the system also includes: capability opening platform NEF and user data management network element UDM; DIVS AS, specifically configured to: send a contract information acquisition request to capability opening platform NEF; The contract information acquisition request includes the first terminal information; NEF is configured to: request the UDM to obtain the contract information of the data sender, and after obtaining the contract information of the data sender, return the contract information of the data sender to DIVS AS; DIVS AS, also Configured to: receive subscription information from NEF; the subscription information is the subscription information of the data sending end obtained from the user data management network element UDM based on the first terminal information returned by NEF.

Based on this, before storing the data integrity verification information in the blockchain, DIVS AS obtains the contract information of the data sender from the operator network, and compares the terminal information of the data sender with the terminal information in the contract information to see if they are consistent. The data integrity verification information is stored in the blockchain. It is guaranteed that the data stored in the blockchain by DIVS AS is the data integrity verification information of the data sender.

In conjunction with the above first aspect, in a possible implementation, the data sending end is specifically configured to: generate a first key pair; the first key pair includes a first public key and a first private key; use a first Private key and first signature The algorithm signs the first public key and the first terminal information to determine the second digital signature; generates the first data according to the first public key, the first terminal information, the signature algorithm set supported by the data sending end, and the second digital signature.

Based on this, the data sending end generates the first public key and the first private key, the data sending end saves the first private key, and sends the first public key to DIVS AS. In this way, the data to be verified can be encrypted using the first private key and decrypted using the first public key. In addition, the data sending end uses the first private key and the first signature algorithm to sign the metadata and generate a second digital signature, which allows DIVS AS to verify the second digital signature based on the first public key and the first signature algorithm to ensure receipt to the accuracy of the first data.

Combined with the first aspect above, in one possible implementation, DIVS AS is specifically configured to: verify the second digital signature based on the first public key and the first signature algorithm; when the second digital signature verification passes , obtain the first terminal information in the first data; and generate a contract information acquisition request according to the first terminal information.

Based on this, DIVS AS can verify the second digital signature to determine whether the first data is the original data sent by the data sender to DIVS AS, ensuring the accuracy of the received first data.

Combined with the above first aspect, in one possible implementation, the DIVS AS is specifically configured to: generate a first data set to be signed based on the first data and contract data; and generate a first data set to be signed based on the second private key and the second signature algorithm. Sign the first data set to be signed to determine the third digital signature; the second private key belongs to the second key pair generated by DIVS AS; according to the first data set to be signed, the certificate corresponding to the second private key, and the third digital signature , determine the data integrity verification information.

Based on this, DIVS AS signs the data integrity verification information again, so that after the data receiving end receives the data integrity verification information, it can verify the signature based on the signature information of the blockchain to ensure that the data integrity verification information comes from DIVS AS Information.

In conjunction with the above first aspect, in a possible implementation, the DIVS AS is further configured to: send the first transaction identifier to the data sending end; wherein the first transaction identifier is used to characterize the Data integrity verification information is stored in the blockchain.

Based on this, DIVS AS can enable the data sending end to generate a first identification based on the transaction identification by sending a transaction identification to the data sending end, so that the data receiving end can obtain data integrity verification information from DIVS AS based on the first identification.

In conjunction with the above first aspect, in a possible implementation manner, the DIVS AS is further configured to: send the first address information to the data sending end; wherein the first address information is to store the first address information. The address information of the DIVS AS of the data integrity verification information corresponding to a transaction identifier.

Based on this, the DIVS AS can send the DIVS AS entry address to the data sending end. The data sending end adds the DIVS AS entry address to the target data, so that the data receiving end determines the DIVS that can store the data integrity verification information based on the DIVS AS entry address. AS.

Combined with the above first aspect, in a possible implementation, UDM is also configured to: when the subscription information of the data sending end is updated, send a signing information update message to NEF; the signing information update message includes: The second terminal information, as well as the updated contract information of the data sending end; NEF is also configured to: forward the contract information update message to DIVS AS; DIVS AS is also configured to: query the blockchain including the second terminal information The latest target data integrity verification information; update the latest target data integrity verification information based on the updated contract information; store the updated latest target data integrity verification information in the blockchain.

Based on this, after the contract information at the data sender changes, UDM can promptly notify DIVS AS to update the contract information. And DIVS AS can update the data integrity verification information based on the updated contract information to ensure the real-time nature of the data integrity verification information.

Combined with the above first aspect, in one possible implementation, the DIVS AS is specifically configured to: perform a first operation on each target data integrity verification information, and determine the updated each target data integrity verification information. ; The first operation includes: generating a second data set to be verified based on the first data and the updated contract information; signing the second data set to be signed based on the second private key and the second signature algorithm to determine a fourth digital signature; Based on the second data set to be signed, the certificate corresponding to the second private key, and the fourth digital signature, the updated target data integrity verification information is determined.

Based on this, DIVS AS stores the contract information updated by the data sender in the blockchain, which allows the data receiver to verify the data integrity of the data to be verified based on the updated contract information.

Combined with the first aspect above, in a possible implementation, DIVS AS is also configured as:

Send the second transaction identifier to the data sending end; wherein the second transaction identifier is used to characterize the storage information of the updated target data integrity verification information in the blockchain.

Based on this, DIVS AS can enable the data sending end to generate a first identification based on the updated transaction identification by sending the updated transaction identification to the data sending end, thereby enabling the data receiving end to obtain the updated data integrity verification information based on the first identification. .

In conjunction with the above first aspect, in a possible implementation, the DIVS AS is further configured to: send the second address information to the data sending end; wherein the second address information is to store the update Based on the address information of the DIVS AS of the target data integrity verification information, the DIVS AS sends the updated DIVS AS entry address to the data sending end. The data sending end can add the updated DIVS AS entry in the target data. address; thus allowing the data receiving end to obtain updated data integrity verification information from DIVS AS based on the updated DIVS AS entry address.

Combined with the above first aspect, in a possible implementation, the data sending end is further configured to: receive the latest transaction identifier among the first transaction identifier and the second transaction identifier from the DIVS AS; the first transaction identifier The second transaction identification is a transaction identification generated based on the storage information of the data integrity verification information in the blockchain; the second transaction identification is a transaction identification generated based on the storage information of the updated data integrity verification information in the blockchain; At least one of a transaction identifier and a second transaction identifier is used to generate a first identifier.

Based on this, the data sending end can generate the first identification based on the first transaction identification and the second transaction identification.

Combined with the first aspect above, in a possible implementation, the target data also includes a verification access address; the verification access address is used to represent the address of the DIVS AS that stores the data integrity verification information of the data sending end; the data sending end is also Configured to: receive at least one of the first address information and the second address information from the DIVS AS; the first address information is the address information of the DIVS AS that stores the data integrity verification information corresponding to the first transaction identifier; the second address The information is the address information of the DIVS AS that stores the updated data integrity verification information corresponding to the second transaction identifier; the verification access address is generated based on at least one of the first address information and the second address information.

Based on this, the data sending end can generate a verification access address based on the first address information and the second address information.

Combined with the above first aspect, in a possible implementation, the target data also includes the timestamp of the first digital signature; the data integrity verification information also includes: the contract validity period of the data sending end; the data receiving end is also configured to: Determine whether the timestamp of the first digital signature is within the contract validity period of the data sending end; if so, determine whether the data integrity verification of the data to be verified is successful.

Based on this, the data receiving end can specifically determine whether the terminal collects data during the contracting validity period based on whether the timestamp of the first digital signature is within the contracting validity period, and determine that the integrity verification of the data collected by the data sending end during the contracting validity period is successful. The integrity verification of data collected outside the contract validity period failed.

Combined with the above first aspect, in a possible implementation, the data receiving end is further configured to: verify the third digital signature according to the certificate corresponding to the second private key and the second signature algorithm; when the third digital signature verification is successful, In this case, obtain the first public key in the first data set to be signed.

Based on this, the data sending end can determine whether the obtained data is the data sent by DIVS AS to the data sending end by verifying the third digital signature.

Combined with the above first aspect, in a possible implementation, the device information includes: at least one of the embedded universal integrated circuit card identification eUICC ID and the international mobile equipment identification code IMEI; the account opening platform is specifically configured to: obtain The eSIM profile and applet of the data sender determine the integrated circuit card identification code ICCID of the eSIM; bind at least one of the eUICC ID, IMEI and ICCID; determine the contract validity information of the data sender according to the contract validity period of the data sender; according to the second Terminal information and contract validity information determine the contract information of the data sending end.

Based on this, the account opening platform can determine the data transmission based on the device information and contract information of the data sending end. Second terminal information and contract information of the terminal.

Combined with the above first aspect, in a possible implementation, the first terminal information includes at least one of eUICC ID/ICCID, IMEI and MSISDN of the data sending end; the second terminal information includes at least one of eUICC ID/ICCID, IMEI and MSISDNICCID. At least one.

Based on this, the account opening platform binds eUICC ID, IMEI and ICCID as the terminal information of the data sender, ensuring the uniqueness and consistency of the terminal information of the data sender.

In this application, the name of the above-mentioned communication device does not limit the device or functional module itself. In actual implementation, these devices or functional modules may appear under other names. As long as the functions of each device or functional module are similar to those of the present invention, they fall within the scope of the claims of the present invention and its equivalent technologies.

Description of the drawings

Figure 1 is a system architecture diagram of a 5G capability open architecture provided by this application;

Figure 2 is a schematic structural diagram of a blockchain provided by this application;

Figure 3 is a system architecture diagram of a data integrity verification system provided by this application;

Figure 4 is a system architecture diagram of another data integrity verification system provided by this application;

Figure 5 is a system architecture diagram of a data integrity verification system provided by this application in a vertical industry scenario;

Figure 6 is a schematic flow chart of a data sending end signing a contract in an operator network provided by the present disclosure;

Figure 7 is a schematic flow chart of data integrity verification information uploading provided by the present disclosure;

Figure 8 is a schematic flow chart of updating data integrity verification information provided by the present disclosure;

Figure 9 is a schematic flow chart of data integrity verification provided by the present disclosure;

Figure 10 is a schematic structural diagram of an electronic device provided by the present disclosure.

Detailed ways

The data integrity verification system provided by the embodiment of the present application will be described in detail below with reference to the accompanying drawings.

The term "and/or" in this article is just an association relationship that describes related objects, indicating that three relationships can exist. For example, A and/or B can mean: A exists alone, A and B exist simultaneously, and they exist alone. B these three situations.

The terms “first” and “second” in the description of this application and the drawings are used to distinguish different objects, or to distinguish different processes on the same object, rather than to describe a specific order of objects.

Furthermore, references to the terms "including" and "having" and any variations thereof in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally also includes other unlisted steps or units, or optionally also Includes other steps or units that are inherent to such processes, methods, products, or devices.

It should be noted that in the embodiments of this application, words such as "exemplary" or "for example" are used to represent examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "such as" in the embodiments of the present application is not to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the words "exemplary" or "such as" is intended to present the concept in a concrete manner.

In the following, for ease of understanding, the terms involved in the embodiments of this application are first explained.

1. Machine type terminal

Machine type terminals are usually used to collect generated data and are widely used in vertical industries. The application of machine-type terminals has effectively promoted the digital transformation of vertical industries such as agriculture, logistics, transportation, medical care, environment, supply chain finance, and smart cities.

With the development of 5G networks, the application of machine-type terminals is becoming more and more widespread. After massive machine-type terminals collect data, the data is sent to service provider terminals, which collect, summarize and analyze the collected data. In addition, the service provider terminal can also forward the data collected by the machine type terminal to the upstream data consumer terminal. Data consumer terminals can obtain valuable data in the industry by analyzing data. For example, in the agricultural industry, data consumption terminals can determine environmental data (such as temperature and wind speed) for agricultural insurance based on data collected by machine-type terminals. In the second-hand car industry, data consumption terminals can determine driving behavior data for second-hand transaction vehicles based on data collected by machine-type terminals. In the transportation industry, data consumption terminals can determine traffic data for AI algorithm training based on data collected by machine-type terminals.

After the current machine type terminal collects data, it directly reports the collected data to the service provider terminal without directly providing the data to the data consumption terminal. Data consumption terminals can only obtain collected data from service provider terminals, but cannot directly obtain data from machine-type terminals. However, after the data consumption terminal receives the collected data, it cannot determine whether the data provided by the service provider terminal has been tampered with, and it is difficult to verify whether the received collected data is the original data collected by the machine type terminal.

In many industries, such as agricultural insurance and distributed artificial intelligence applications, the requirements for data integrity (data authenticity) are very high. If the data consumption terminals in these industries perform data analysis and decision-making based on tampered data, it may cause problems. Causing unnecessary economic losses and suffering security attacks. Therefore, for data consumption terminals, how to verify the data integrity of the acquired data to ensure that the acquired data is the original data collected by the source and that the data has not been tampered with has become an urgent problem to be solved.

In the present disclosure, the machine type terminal may be a data sending end and is used to perform functions related to the data sending end. The data consumption terminal is the data receiving end and is used to perform functions related to the data receiving end.

2. Data integrity

In the embodiment of the present disclosure, data integrity is mainly used by the data receiving end (such as the data consumption terminal described above) to verify whether the received data is sent by the data sending end (such as the machine type terminal described above). The original data sent. Prevent data from being tampered with during intermediate forwarding. Based on the above description in the machine type terminal, it can be known that the current data consumption terminal has a need to verify the data integrity of the data provided by the service provider terminal.

In related technologies, data integrity can be verified by using a symmetric key + one-way Hash function or an asymmetric key hash method. However, these solutions have at least the following problems.

The data integrity verification method using symmetric key + one-way Hash function can only verify the data integrity during the point-to-point transmission process, but cannot verify whether the data is the original data provided by the source. This may cause the service provider terminal to tamper with the data before sending it to the data consuming terminal, and the data consuming terminal cannot verify whether the data has been tampered with.

In the process of data integrity verification using asymmetric key hashing, data integrity is verified by using private key signature + public key signature verification (for example, ITU-T X.509, IETF RFC 4880). However, in this method, it is also impossible to verify whether the data is the original data provided by the source. For example, after the machine type terminal collects data, the service provider terminal forwards the collected data to the data consumption terminal. The data consumption terminal can only use the received data as original data for subsequent processing, or it can constrain the service provider to provide original data through declarations and contracts. However, these methods cannot avoid the fact that the service provider terminal provides original data, making it difficult to ensure data integrity.

3. Embedded subscriber identity module (eSIM) and trusted execution environment (TEE) technology.

eSIM and TEE can store confidential data and perform trusted operations in machine-type terminals. For example, generate a public-private key pair in the eSIM of the machine-type terminal, or send public key endorsement information to eSIM through OTA.

In a machine type terminal, when the machine type terminal needs to send data, the machine type terminal can call a predetermined interface through the OS to sign the collected data using the private key stored in the TEE or eSIM, and then send the signed data to the business Provider terminal.

4. 5G open capability architecture

As shown in Figure 1, it is a system architecture diagram of the 5G capability opening architecture provided by the embodiment of this application. In the 5G capability open architecture shown in Figure 1, it includes: application server (AS), network element function (NEF), unified data management function (UDM), policy control function ( Policy Control Function (PCF), access and mobility management function (AMF), session management function (SMF), network repository function (NRF), Network Entity.

Among them, AS is the operator's application server or a third-party application server, which is used to provide the operator's Network service capabilities or service capabilities of third-party applications. AS accesses the NEF API interface of the operator's 5G network through Nnef, and communicates with NEF through the API interface.

NEF is the operator's ability opening network element, which is used to open the operator's network capabilities to third-party services, open the data in the core network (such as location information) to AS, or open the AS's business requirements (such as QoS policy) Transmitted to network elements in the 5G core network.

NEF is connected to UDM through the Nudm interface, to PCF through the Npcf interface, to AMF through Namf, to SMF through Nsmf, to NRF through Nnrf, and to Network Entity through the 3GPP interface.

It should be pointed out that in the embodiment of the present disclosure, the operator's AS function can be used to provide long-term data integrity verification services for the data collected by the machine type terminal.

5. Blockchain

Blockchain is a data storage technology that is jointly maintained by multiple parties, stores data in a block chain structure, and uses cryptography to ensure transmission and access security. Through blockchain technology, data can be stored consistently, cannot be tampered with, and cannot be repudiated.

The blockchain usually includes multiple blockchain nodes, which store the ledgers in the blockchain respectively, and use P2P technology to synchronize the ledgers to ensure the consistency of the ledgers stored in each node. When the data in the ledger needs to be updated, multiple nodes use a consensus mechanism to confirm the records written to the ledger. In this way, it can be guaranteed that the data written to the ledger is written with the joint confirmation of multiple nodes. Data that has not been jointly confirmed by multiple nodes will not be written, ensuring that the data written in the blockchain ledger cannot be written. Tampered and data is traceable.

Blockchain is divided into three types of blockchain based on the types of users allowed to access: public chain, alliance chain and private chain. Among them, the public chain allows any terminal to access and use the ledger for accounting. The consortium chain only allows specific individual terminals or specific enterprise terminals to access and use the ledger for accounting. Private chains only allow internal nodes within the enterprise to maintain and use the blockchain.

As shown in Figure 2, it is a schematic structural diagram of a blockchain provided by an embodiment of the present disclosure. As shown in Figure 2, the blockchain includes multiple blockchain nodes Peer, and each blockchain node is connected to each other. Smart contracts are set up in the blockchain nodes (only blockchain node 3 is shown in the figure as an example, other nodes are similar to blockchain node 3).

Each blockchain node includes a blockchain ledger (Ledger), which is used to store data, for example, in the form of hash.

It should be pointed out that in the embodiment of the present disclosure, data integrity verification information can be stored through blockchain technology. For example, public key information MSISDN, ICCID, device sequence information, hash algorithm, timestamp and other information, and provide a data integrity verification server for terminals through the open capabilities of the 5G network. This ensures that vertical industries Verification of data integrity during the entire data life cycle when collecting data through machine-type terminals reduces the trust cost generated during data transfer and re-application, and promotes digital transformation and data application in vertical industries.

Above, the technical terms involved in the embodiments of the present application have been described in detail.

According to the above description of machine type terminals and data integrity verification, it can be seen that in the current data transmission process (especially in the process of data forwarding by a third party), the data receiving end has a need to verify the data integrity of the received data.

For example, in vertical industry application scenarios, machine-type terminals send collected data to service provider terminals, which forward the data to data consumption terminals. In this scenario, it is difficult for the data consumption terminal to verify whether the service provider terminal has tampered with the data collected by the machine type terminal. As a result, the data consuming terminal cannot determine the data integrity of the received data.

In order to solve the problems existing in related technologies, embodiments of the present application provide a data integrity verification system. The data integrity verification server DIVS AS stores the data integrity verification information of the data sending end, and receives the data to be verified at the data receiving end. After the first digital signature of the data to be verified, obtain the data integrity verification information of the data sending end from the DIVS AS, verify the first digital signature based on the data integrity verification information, and if the first digital signature is valid, it means that the data It is the original data collected by the data collection terminal, which indicates that the data integrity verification of the data is successful.

Figure 3 is a system architecture diagram of the data integrity verification system provided by the embodiment of this application; as shown in Figure 3, the data integrity verification system includes: data sending end 301, data integrity verification service application server , DIVS AS) 302, and the data receiving end 303.

Among them, the data sending end 301 is configured to: send target data to the data receiving end 303; the target data includes: data to be verified, a first digital signature and a first identification; where the first digital signature is treated according to the first private key The digital signature used to verify the signature of the data; the first identifier is the storage identifier of the data integrity verification information of the data sending end 301 in the DIVS AS 302; the first private key is the private key in the first key pair generated by the data sending end 301. key.

The data receiving end 303 is configured to receive the target data and send the first identifier to the DIVS AS 302.

DIVS AS302 is configured to: receive the first identification and query the data integrity verification information associated with the first identification; the data integrity verification information includes the first public key; the first public key is the first password generated by the data sending end 301 The public key in the key pair.

The data receiving end 303 is configured to: receive data integrity verification information, verify the first digital signature according to the first public key in the data integrity verification information, and determine the data of the data to be verified based on the verification result of the first digital signature. Integrity.

Optionally, the above-mentioned data sending terminal 301 may be the machine type terminal described above. Data receiving end 303 It can be the data consumption terminal described above.

The above solution at least brings the following beneficial effects: In this disclosed embodiment, after collecting the data, the data sending end 301 uses the first private key to digitally sign the data, and then uniformly sends the digital signature and the data to be verified to the data receiving end. 303. After receiving the data, the data receiving end 303 obtains the data integrity verification information of the data sending end 301 from the DIVS AS 302, and uses the first public key in the data integrity verification information to verify the first digital signature. If the verification is successful, then It means that the first digital signature is a signature based on the first private key, and the first private key is an internal key of the data sending end 301 and will not be stolen by the outside. Therefore, if the first digital signature is verified successfully, it means that the first digital signature is the digital signature obtained by signing the data to be verified by the data sending end 301, and therefore the data to be verified is the original data sent by the data sending end 301. Based on this, the data receiving end 303 can determine whether the received data is the original data sent by the data sending end 301 according to this method, thereby effectively verifying the data integrity of the data to be verified.

In conjunction with Figure 3, as shown in Figure 4, in a possible implementation manner, the data integrity verification system provided by the embodiment of the present application also includes: a capability opening platform NEF304 and a user data management network element UDM305.

Among them, the data sending end 301 is also configured to: send the first data to DIVS AS302; the first data includes: the first public key, the signature algorithm set supported by the data sending end and the first terminal information of the data sending end 301; DIVS AS302 is also configured to: obtain the contract information of the data sending end 301 according to the first terminal information; the contract information includes: the contract validity information of the data sending end 301; and determine the data integrity verification information according to the first data and the contract information; Store data integrity verification information in the blockchain.

Based on this, before performing data integrity verification, the data sending end 301 can store the data integrity verification information in the blockchain by interacting with DIVS AS302. In this way, when the data receiving end 303 requests data integrity verification information, the data receiving end 303 can obtain the data integrity verification information from the blockchain to prevent the data integrity verification information from being tampered with.

In a possible implementation, the system also includes: capability open platform NEF and user data management network element UDM; DIVS AS302, specifically configured to: send a contract information acquisition request to the capability open platform NEF; the contract information acquisition request includes The first terminal information; NEF, is configured to: request the UDM to obtain the contract information of the data sending terminal 301, and return the contract information of the data sending terminal 301 to DIVS AS302 after obtaining the contract information of the data sending terminal 301; DIVS AS302, also Configured to: receive subscription information from NEF; the subscription information is the subscription information of the data sending end 301 obtained from the user data management network element UDM based on the first terminal information returned by NEF.

Based on this, before storing the data integrity verification information in the blockchain, DIVS AS302 obtains the contract information of the data sender 301 from the operator network, and compares the terminal information of the data sender 301 with the terminal information in the contract information. Consistent, store data integrity verification information in the blockchain under consistent conditions middle. It is guaranteed that the data stored in the blockchain by DIVS AS302 is the data integrity verification information of the data sending end 301.

In a possible implementation, the data sending end 301 is specifically configured to: generate a first key pair; the first key pair includes a first public key and a first private key; use the first private key and the first private key. The signature algorithm signs the first public key and the first terminal information to determine the second digital signature; generates the first data according to the first public key, the first terminal information, the signature algorithm set supported by the data sending end, and the second digital signature.

Based on this, the data sending end 301 generates the first public key and the first private key, the data sending end 301 saves the first private key, and sends the first public key to DIVS AS302. In this way, the data to be verified can be encrypted using the first private key and decrypted using the first public key. In addition, the data sending end 301 uses the first private key and the first signature algorithm to sign the metadata and generate a second digital signature, which allows the DIVS AS302 to verify the second digital signature based on the first public key and the first signature algorithm to ensure Accuracy of the first data received.

In one possible implementation, DIVS AS302 is specifically configured to: verify the second digital signature based on the first public key and the first signature algorithm; when the second digital signature passes verification, obtain the first data the first terminal information; generating a subscription information acquisition request according to the first terminal information.

Based on this, DIVS AS302 can determine whether the first data is the original data sent by the data sending end 301 to DIVS AS302 by verifying the second digital signature, ensuring the accuracy of the received first data.

In a possible implementation, DIVS AS302 is specifically configured to: generate a first data set to be signed based on the first data and contract data; sign the first data set to be signed based on the second private key and the second signature algorithm , determine the third digital signature; the second private key belongs to the second key pair generated by DIVS AS302; determine the data integrity verification based on the first data set to be signed, the certificate corresponding to the second private key, and the third digital signature information.

Based on this, DIVS AS302 signs the data integrity verification information again, so that after the data receiving end 303 receives the data integrity verification information, it can verify the signature based on the signature information of the blockchain to ensure that the data integrity verification information comes from DIVS AS302 information.

In a possible implementation, DIVS AS302 is also configured to: send the first transaction identifier to the data sending end 301; wherein the first transaction identifier is used to characterize the data integrity verification information Store information in the blockchain.

Based on this, DIVS AS302 can enable the data sending end 301 to generate a first identification based on the transaction identification by sending a transaction identification to the data sending end 301, so that the data receiving end 303 can obtain data integrity verification information from DIVS AS302 based on the first identification. .

In one possible implementation, DIVS AS302 is also configured to:

Send the first address information to the data sending end 301; wherein the first address information is a storage The address information of the DIVS AS302 that stores the data integrity verification information corresponding to the first transaction identifier.

Based on this, DIVS AS302 can send the DIVS AS302 entry address to the data sending end 301. The data sending end 301 adds the DIVS AS302 entry address to the target data, so that the data receiving end 303 determines that it can store the data integrity verification based on the DIVS AS302 entry address. Information DIVS AS302.

In a possible implementation, UDM is also configured to: when the subscription information of the data sending end 301 is updated, send a subscription information update message to NEF; the subscription information update message includes: the second data of the data sending end 301 Terminal information, as well as the updated contract information of the data sending end 301; NEF is also configured to: forward the contract information update message to DIVS AS302; DIVS AS302 is also configured to: query the latest update of the second terminal information in the blockchain target data integrity verification information; update the latest target data integrity verification information based on the updated contract information; store the updated latest target data integrity verification information in the blockchain.

Based on this, after the contract information of the data sending end 301 is changed, UDM can promptly notify DIVS AS302 to update the contract information. And DIVS AS302 can update the data integrity verification information based on the updated contract information to ensure the real-time nature of the data integrity verification information.

In a possible implementation, DIVS AS302 is specifically configured to: perform a first operation on each target data integrity verification information, and determine the updated each target data integrity verification information; the first operation includes: Generate a second data set to be verified based on the first data and the updated contract information; sign the second data set to be signed based on the second private key and the second signature algorithm to determine a fourth digital signature; based on the second data to be signed set, the certificate corresponding to the second private key, and the fourth digital signature to determine the updated target data integrity verification information.

Based on this, DIVS AS302 stores the contract information updated by the data sending end 301 in the blockchain, which allows the data receiving end 303 to verify the data integrity of the data to be verified based on the updated contract information.

In a possible implementation, DIVS AS302 is also configured to: send the second transaction identifier to the data sending end 301; wherein the second transaction identifier is used to characterize the updated target data Based on the storage information of the integrity verification information in the blockchain, DIVS AS302 can enable the data sending end 301 to generate a first identification based on the updated transaction identification by sending the updated transaction identification to the data sending end 301, thereby enabling The data receiving end 303 obtains the updated data integrity verification information according to the first identification.

In a possible implementation, the DIVS AS 302 is further configured to: send the second address information to the data sending end 301; wherein the second address information is to store the updated target data integrity verification Information DIVS AS302 address information. It can be understood that DIVS AS can send the transaction ID and URL to the data sending end respectively after generating the transaction ID and URL. DIVS AS can also be merged based on the transaction ID and URL, and the transaction ID and URL are sent to the data sending end through the same message. There are no restrictions on this. In the case where the transaction ID and URL are sent to the data sender in the same message, if DIVS AS updates the transaction ID (for example, DIVS AS will update the transaction ID accordingly after updating the on-chain data corresponding to the transaction ID) but it is not updated. URL, DIVS can update only the transaction identifier in the information, or update the transaction identifier and URL at the same time. This disclosure does not limit this either.

Based on this, DIVS AS302 sends the updated DIVS AS302 entry address to the data sending end 301. The data sending end 301 can add the updated DIVS AS302 entry address in the target data; thus the data receiving end 303 can according to the updated DIVS The AS302 entry address obtains updated data integrity verification information from DIVS AS302.

In a possible implementation, the data sending end 301 is also configured to: receive at least one of the first transaction identification and the second transaction identification from the DIVS AS 302; the first transaction identification is based on data integrity verification information. A transaction identifier generated from the information stored in the blockchain; the second transaction identifier is a transaction identifier generated based on the updated data integrity verification information stored in the blockchain; based on the first transaction identifier and the second transaction identifier The latest transaction identifier in , generates the first identifier.

Based on this, the data sending end 301 can generate the first identification based on the first transaction identification and the second transaction identification.

In a possible implementation, the target data also includes a verification access address; the verification access address is used to represent the address of the DIVS AS302 that stores the data integrity verification information of the data sending end 301; the data sending end 301 is also configured as: Receive at least one of the first address information and the second address information from DIVS AS302; the first address information is the address information of DIVS AS302 that stores the data integrity verification information corresponding to the first transaction identifier; the second address information is the storage The address information of DIVS AS302 of the updated data integrity verification information corresponding to the second transaction identifier; generate a verification access address based on at least one of the first address information and the second address information.

Based on this, the data sending end 301 can generate a verification access address based on the first address information and the second address information.

In a possible implementation, the target data also includes the timestamp of the first digital signature; the data integrity verification information also includes: the contract validity period of the data sending end 301; the data receiving end 303 is also configured to: determine the first Whether the timestamp of the digital signature is within the contract validity period of the data sending end 301; if so, it is determined that the data integrity verification of the data to be verified is successful.

Based on this, the data receiving end 303 can specifically determine whether the terminal collects data during the contracting validity period based on whether the timestamp of the first digital signature is within the contracting validity period, and determine the integrity verification of the data collected by the data sending end 301 within the contracting validity period. Success, the integrity verification of data collected outside the contract validity period failed.

In a possible implementation, the data receiving end 303 is also configured to: correspond to The certificate and the second signature algorithm are used to verify the third digital signature; when the verification of the third digital signature is successful, the first public key in the first data set to be signed is obtained.

Based on this, the data sending end 301 can determine whether the acquired data is the data sent by the DIVS AS302 to the data sending end 301 by verifying the third digital signature.

In a possible implementation, the first terminal information includes the embedded universal integrated circuit card identity (eUICC ID)/integrated circuit card identification code (Integrate circuit card identity, ICCID) of the data sending end 301 ), at least one of International Mobile Equipment Identity (International Mobile Equipment Identity, IMEI) and mobile subscriber number (Mobile Station international ISDN number, MSISDN); the second terminal information includes at least one of eUICC ID/ICCID, IMEI and MSISDN .

Based on this, the account opening platform binds eUICC ID/ICCID, IMEI and MSISDN as the terminal information of the data sending end 301, ensuring the uniqueness and consistency of the terminal information of the data sending end 301.

Above, the devices included in the data integrity verification system involved in the embodiments of the present disclosure, as well as the functions of each device and the interaction between each device have been described in detail.

In one possible implementation manner, combined with Figure 5, there is a system architecture diagram of a data integrity verification system provided by an embodiment of the present application in a vertical industry scenario.

As shown in Figure 5, the data integrity verification system includes a machine type terminal 501, a data integrity verification server 502, a data consumption terminal 503, a capability opening function network element 504, a user data storage network element 505, and other data integrity verification services. Network element 506.

Among them, APP is installed in the machine type terminal 501 for realizing different application functions. Machine type terminals have built-in operating systems OS. The eSIM is installed in the machine type terminal, which allows the machine type terminal to transmit data through the operator network (such as 5G network). An applet can also be installed in the machine type terminal eSIM, and the applet is used to generate a key pair (such as the above-mentioned first public key and first private key). The first private key is always stored in the applet to avoid leakage of the first private key. The first public key can be sent to other terminals, so that other terminals can decrypt data encrypted by the first private key based on the first public key. Optionally, a 5G communication module can also be integrated into the machine type terminal, so that the machine type terminal has 5G communication capabilities.

The data integrity verification server 502 is used to store data integrity verification information of the data sending end and provide data integrity verification information to the data receiving end. Optionally, the data integrity verification server may be a third-party entity deployed in the operator's network. The data integrity verification server 502 may specifically include a signaling processing module 5021, an access control module 5022, a data management module 5023, and a blockchain ledger 5024.

The data consumption terminal 503 is a third-party terminal used to collect, use, and transfer data collected by machine-type terminals. For example, it can be a personal terminal or a terminal in an enterprise.

The capability opening function network element 504 may be, for example, a capability opening function network element in the 5G core network, such as NEF, which is used to implement communication between third-party applications (such as data integrity verification servers) and the operator's core network.

The user data storage network element 505 is used to store data of user terminals. For example, in the embodiment of the present disclosure, the user data storage network element 505 is used to store subscription information of machine type terminals.

Other data integrity verification service network elements 506 are data integrity verification servers deployed in different core networks of the same operator, or data integrity verification servers of other operators; the blockchain ledger function of the data integrity verification server constitutes a block chain network.

Above, the system architecture diagram of a data integrity verification system in a vertical industry scenario is described in detail.

Below, combined with the above-mentioned data integrity verification system, the process of performing data integrity verification for this application will be explained:

In the embodiment of the present disclosure, the data integrity verification process may specifically include the following processes:

Process 1, the process of the data sending end signing a contract in the operator's network; Process 2, the process of uploading the data integrity verification information to the chain; Process 3, the process of updating the data integrity verification information; Process 4, the process of data integrity verification. The above processes are explained below:

Process 1. The data sending end signs a contract in the operator's network.

As shown in Figure 6, the process for the data sending end to sign a contract in the operator network includes the following S601-S604.

S601. The data sending end user sends equipment contract information to the account opening platform.

The device contract information includes at least one of the following: Common Name, location (country, region), affiliation organization name, and email address.

S602. The account opening platform opens an account for the data sending end.

Specifically, it includes: the data sender opens an account in the account opening platform, and registers the data sender's eUICC ID, IMEI, device serial number SN, device ownership entity name, deployment location, contact email and other information.

The account opening platform triggers the eSIM management platform to generate eSIM profile and security applet. During the process of generating the eSIM profile by the eSIM management platform, the ICCID is assigned to the data sender.

The account opening platform binds ICCID to IMEI and eUICC ID.

It should be pointed out that the information required in the above process includes at least one of the following: Common Name, location (country, region), affiliation organization name, and email address.

S603. The data sending end accesses the operator's network, obtains and installs the eSIM profile and security applet.

In a specific implementation method, after the data sending end is connected to the operator's network, it requests the eSIM management platform to download the eSIM profile and security applet. After the download is completed, the data sender installs the eSIM in the eUICC profile and security applets.

In this way, the data sending end can use network services through eSIM, generate a key pair through an applet, and encrypt the data that needs to be encrypted.

S604. The account opening platform sends contract information to UDM. Correspondingly, UDM receives and stores the contract information of the data sender.

In this way, after the contract information of the data sender is stored in UDM, the contract information in the machine type can be sent to DIVS AS, so that DIVS AS verifies the data sender based on the contract information.

Above, the process of the data sending end signing a contract in the operator network is described. Based on this process, by binding ICCID with IMEI and eUICC ID, the data sending end can be uniquely identified through the above information. After this, DIVS AS and the data receiving end can verify the data sending end based on the above information.

Process 2: The process of uploading data integrity verification information to the chain.

As shown in Figure 7, the process of uploading data integrity verification information to the blockchain can be implemented through the following S701-S711.

S701. The data sending end generates a first key pair.

In one possible implementation, the data sending end calls the security applet in eUICC to generate a first key pair (based on ECC or RSA). The first key pair includes a first public key and a first private key.

It should be pointed out that the first private key will always be stored in the secure applet and cannot be obtained by the data sending end or other devices. This can prevent other devices from stealing the first private key and then sending data to the data receiving end based on the first private key. and signature.

S702. The data sending end obtains metadata and generates data to be uploaded based on the metadata.

Metadata includes at least one of the following: first public key, IEMI, ICCID, eUICC ID, device serial number SN, MSISDN.

In one possible implementation, the data sending end application obtains the first public key generated by the security applet through the ADPU instruction. The data sending end obtains the first terminal information of the data sending end from the operating system interface and the communication module interface, including at least one of the following: IEMI, ICCID, eUICC ID, device serial number SN, MSISDN.

Among them, the data to be uploaded includes: metadata, the first signature algorithm for signing the metadata, and the first digital signature obtained after signing the metadata.

In one possible implementation, the data sending end application sends metadata to the security applet. The security applet digitally signs the metadata based on the first private key in the public-private key pair and the first signature algorithm to obtain the first digital signature.

The data sending end generates data to be uploaded based on the metadata, the first signature algorithm and the first digital signature.

S703. The data sending end sends the data to be uploaded to the DIVS AS.

S704. DIVS AS verifies the data to be uploaded based on the first public key and the first digital signature.

Optionally, DIVS AS decrypts the first digital signature according to the first public key to obtain decrypted data. DIVS AS determines whether the decrypted data is consistent with the metadata or the hash of the metadata. If they are consistent, the verification is successful.

S705, DIVS AS sends contract request information to NEF.

Among them, the contract request information is used to request to obtain the contract information of the data sending end.

Optionally, DIVS AS accesses NEF through the query interface (RP-EDI). The access message carries MSISDN, ICCID and IMEI, and requests to obtain the contract information of the data sender corresponding to the MSISDN, ICCID and IMEI.

S706. NEF obtains the contract information of the sending end from UDM.

Optionally, NEF forwards the MSISDN, ICCID, and IMEI to the UDM, and requests to obtain the contract information of the data sending end corresponding to the MSISDN, ICCID, and IMEI. UDM queries the contract information with the MSISDN, ICCID and IMEI information through MSISDN, ICCID and IMEI, and returns the queried contract information to NEF.

S707. NEF sends the contract information of the data sending end to DIVS AS.

Optionally, NEF forwards the contract information sent by UDM to DIVS AS.

S708, DIVS AS generates the first data set to be signed.

Specifically, DIVS AS uses metadata, signing information, public key, and first signature algorithm information as the first data set to be signed.

Optionally, DIVS AS can directly use the metadata, contracting information, public key, and first signature algorithm information as the first data set to be signed, or it can also use the metadata, contracting information, public key, and first signature algorithm information as the first data set to be signed. The hash value is used as the first data set to be signed. This application does not limit this.

S709, DIVS AS generates data integrity verification information based on the first data set to be signed, and uploads the data integrity verification information to the blockchain ledger.

Specifically, DIVS AS signs the first data set to be signed based on the second private key of the blockchain ledger and the second digital signature algorithm to generate a second digital signature. DIVS AS uploads the first to-be-signed data set, the second digital signature, and the CA certificate of the second private key to the blockchain ledger as data integrity verification information.

It should be pointed out that the blockchain ledger includes the transaction ID (Transation ID) of data integrity verification information. After uploading the data integrity verification information to the blockchain ledger, DIVS AS sets the value of the previous transaction identifier of the data integrity verification information to empty and sets the record status to available.

S710, DIVS AS generates transaction identification of complete data row verification information.

S711. DIVS AS sends the transaction identifier to the data sending end.

Optionally, DIVS AS also generates the URL of the DIVS AS entrance, and synchronously sends the URL and transaction identifier to the data sending end. It is understandable that DIVS AS can send the transaction ID and URL to the data sending end respectively after generating the transaction ID and URL. DIVS AS can also be merged based on the transaction ID and URL, and the transaction ID and URL are sent to the data sending end through the same message. This disclosure does not limit this. In the case where the transaction ID and URL are sent to the data sender in the same message, if DIVS AS updates the transaction ID but does not update the URL, DIVS can only update the transaction ID in the information, or it can update the transaction ID and URL at the same time. This disclosure does not limit this either.

It should be pointed out that after receiving the transaction ID and URL, the data sender can store the transaction ID and URL in the secure applet in the eUICC.

It should be pointed out that in the above process two, the certificate corresponding to the second private key provided by DIVS AS can be a CA certificate generated based on the public and private key pairs managed by the members of the blockchain system, or it can be a CA generated by an authoritative CA structure. The certificate can also be a self-signed CA certificate, which is not limited in this application.

Optionally, the second digital signature algorithm and the first digital signature algorithm may be the same digital signature algorithm.

Optionally, the blockchain ledger includes a blockchain client, which is used to read and write blockchain ledger data and execute smart contracts.

Process 3. Data integrity verification information update process.

As shown in Figure 8, the process of updating the data integrity verification information is the contract cancellation process as an example to explain the process of updating the data integrity verification information. The contract cancellation process can be implemented through the following S801-S808.

S801, UDM triggers eSIM contract cancellation.

Specifically, the data sending end user's contract data stored in UDM. Once the user's service is logged out, the contract cancellation process will be triggered, and a UDM event notification will be triggered to NEF.

S802. UDM sends an eSIM subscription cancellation message to NEF.

The eSIM subscription cancellation message includes at least one of the following: ICCID, MSISDN, bound IMEI, and eSIM subscription cancellation time.

S803. NEF sends an eSIM subscription cancellation message to DIVS AS.

Specifically, NEF triggers a subscription notification event and sends an eSIM subscription cancellation message to DIVS AS.

S804, DIVS AS determines the corresponding transaction identifier based on the eSIM contract cancellation message.

Specifically, after receiving the eSIM subscription and cancellation message, DIVS AS obtains the ICCID, MSISDN and IMEI in the eSIM subscription and cancellation message. DIVS AS determines all transaction identifiers associated with ICCID, MSISDN and IMEI.

S805. DIVS AS updates the first data set to be signed corresponding to the transaction identifier and obtains the second data set to be signed.

Specifically, DIVS AS updates the eSIM signing and cancellation time in the first data set to be signed corresponding to each transaction identification, and uses the updated first data set to be signed as the second data set to be signed.

DIVS AS signs the second data set to be signed based on the second private key and the second signature algorithm to obtain the fourth digital signature.

S806, DIVS AS uploads the second data set to be signed, the fourth digital signature, and the CA certificate of the second private key to the blockchain ledger as updated data integrity verification information.

S807, DIVS AS generates the transaction identifier of the updated data integrity verification information.

S808, DIVS AS sends the transaction identifier of the updated data integrity verification information to the data sending end.

Among them, the specific implementation of S807 and S808 can refer to the above-mentioned S710 and S711, and will not be described again here.

The above describes the process of updating contract information.

Process 4. Data integrity verification process.

As shown in Figure 9, the data integrity verification process can be implemented through the following S901-S907.

S901. The data sending end obtains the data to be verified.

Optionally, after the data sending end collects the data, the collected data will be used as data to be verified.

S902. The data sending end generates target data based on the data to be verified.

Specifically, the data sending end uses the first private key and the first signature algorithm to obtain the digital signature to be verified, and obtains the first digital signature.

The data sending end calls the ADPU instruction to send the data to the secure applet, uses the first private key and the first signature algorithm to sign the data to be verified, and obtains the first digital signature and the timestamp of the first digital signature.

S903. The data sending end sends the target data to the data receiving end.

Specifically, the data sending end generates target data based on the data to be verified, the first digital signature, the timestamp of the first digital signature, and the first identification.

The data sending end sends target data to the data receiving end.

It should be pointed out that the data sending end can directly send the target data to the data receiving end, or can also send the target data to the data receiving end after being forwarded by other devices. This application does not limit this.

S904. The data receiving end sends a data integrity verification information request message to the DIVS AS.

The request data includes a first identification.

S905, DIVS AS queries the data integrity verification information associated with the first identifier.

Specifically, after receiving the request message, the DIVS AS determines the first identifier. DIVS AS queries the data integrity verification information associated with the first identifier in the blockchain ledger.

Optionally, DIVS AS first queries the data integrity verification information related to the first identification in the blockchain ledger, and determines the metadata in the data integrity verification information. Then DIVS AS determines the updated data integrity verification information based on the IEMI, MSISDN, and ICCID in the metadata.

DIVS AS sends the data integrity verification information and the updated data integrity verification information to the data receiving end.

S906, DIVS AS sends data integrity verification information to the data receiving end.

S907. The data receiving end verifies the data integrity of the data to be verified based on the data integrity verification information.

Specifically, after receiving the data integrity verification information, DIVS AS verifies the third digital signature or the fourth digital signature based on the CA integer of the second public key and the first private key in the data integrity verification information. After the verification is successful, the first public key in the data integrity verification information is obtained, and the first digital signature is verified based on the first public key and the first signature algorithm. After the first digital signature passes the verification, it is determined whether the timestamp of the first digital signature is within the contract validity period of the data sending end. If yes, it is determined that the data integrity verification of the data to be verified is successful.

Above, the data integrity verification system involved in the embodiment of the present application, the functions of each device in the data integrity verification system, and the interaction between the devices have been described in detail.

An embodiment of the present application provides an electronic device for performing the method required by any device in the above data integrity determination system. The electronic device can be a data sending end, a data receiving end, a DIVS AS, NEF or UDM, etc. This application does not limit this. The electronic device may be the electronic device involved in this application, or a module in the electronic device; or it may be a chip in the electronic device, or other device for performing the network quality determination method, which is not limited by this application.

FIG. 10 is a schematic structural diagram of an electronic device provided by an embodiment of the present application. As shown in FIG. 10 , the electronic device 100 includes at least one processor 101 , a communication line 102 , and at least one communication interface 104 , and may also include a memory 103 . Among them, the processor 101, the memory 103 and the communication interface 104 can be connected through a communication line 102.

The processor 101 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present application. For example: one or more digital signal processors (DSP), or one or more field programmable gate arrays (FPGA).

Communication line 102 may include a path for communicating information between the components described above.

The communication interface 104 is used to communicate with other devices or communication networks, and can use any transceiver-like device, such as Ethernet, wireless access network (radio access network, RAN), wireless local area networks (WLAN) wait.

The memory 103 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (random access memory (RAM)) or other type that can store information and instructions. A dynamic storage device can also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disk storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), disk storage media or other magnetic storage devices, or can be used to include or store desired program code in the form of instructions or data structures and can be used by a computer Any other medium for access, but not limited to this.

In one possible design, the memory 103 can exist independently of the processor 101, that is, the memory 103 can be a memory external to the processor 101. In this case, the memory 103 can be connected to the processor 101 through the communication line 102 for storing execution data. Instructions or application program codes are controlled and executed by the processor 101 to implement the network quality determination method provided by the following embodiments of the present application. In another possible design, the memory 103 can also be integrated with the processor 101, that is, the memory 103 can be an internal memory of the processor 101. For example, the memory 103 can be a cache, which can be used to temporarily store some data and instructions. Information etc.

As an implementation manner, the processor 101 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 10 . As another implementation manner, the electronic device 100 may include multiple processors, such as the processor 101 and the processor 107 in FIG. 10 . As yet another implementation manner, the electronic device 100 may also include an output device 105 and an input device 106.

Embodiments of the present application provide a computer program product containing instructions. When the computer program product is run on a computer, it causes the computer to execute the method executed by each device in the above system embodiment.

Embodiments of the present application also provide a computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When the instructions are run on a computer, they cause the computer to execute the method performed by each device in the above system embodiment.

The computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: electrical connections having one or more conductors, portable computer disks, hard drives, random access memory (RAM), read-only memory (Read-Only Memory, ROM), Erasable Programmable Read Only Memory (EPROM), register, hard disk, optical fiber, portable compact disk read-only memory (Compact Disc Read-Only Memory, CD-ROM ), an optical storage device, a magnetic storage device, or any suitable combination of the above, or any other form of computer-readable storage medium well known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from the storage medium and transfer information to the storage medium. Write information. Of course, the storage medium can also be an integral part of the processor. The processor and storage medium may be located in an Application Specific Integrated Circuit (ASIC). In the embodiments of the present application, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, apparatus or device.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application can be integrated into one processing unit, each unit can exist physically alone, or two or more units can be integrated into one unit.

The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be covered by the protection scope of the present application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims

A data integrity verification system, characterized by including: a data sending end, a data receiving end and a data integrity verification server DIVS AS;

The data sending end is configured to: send target data to the data receiving end; the target data includes: data to be verified, a first digital signature and a first identification; wherein the first digital signature is based on the first digital signature. A private key is used to sign the digital signature of the data to be verified; the first identification is the storage identification of the data integrity verification information of the data sending end in the DIVS AS; the first private key is the The private key in the first key pair generated by the data sending end;

The data receiving end is configured to: receive the target data and send the first identifier to the DIVS AS;

The DIVS AS is configured to: receive the first identification and query the data integrity verification information associated with the first identification; the data integrity verification information includes a first public key; the first public key The public key in the first key pair generated by the data sending end;

The data receiving end is configured to: receive the data integrity verification information, verify the first digital signature according to the first public key in the data integrity verification information, and verify the first digital signature based on the verification of the first digital signature. The result determines the data integrity of the data to be verified.
The system according to claim 1, characterized in that the data sending end is also configured to: send first data to the DIVS AS; the first data includes: the first public key, the The set of signature algorithms supported by the data sending end and the first terminal information of the data sending end;

The DIVS AS is further configured to: obtain the contract information of the data sending end according to the first terminal information; the contract information includes: the contract validity information of the data sending end; according to the first data and the Determine the contract information, determine the data integrity verification information, and store the data integrity verification information in the blockchain.
The system according to claim 2, characterized in that the system further includes: capability opening platform NEF and user data management network element UDM;

The DIVS AS is specifically configured to: send a contract information acquisition request to the capability opening platform NEF; the contract information acquisition request includes the first terminal information;

The NEF is configured to: request the UDM to obtain the contract information of the data sender, and return the contract information of the data sender to the DIVS AS after obtaining the contract information of the data sender;

The DIVS AS is also configured to: receive subscription information from the NEF; the subscription information is the data returned by the NEF and obtained in the user data management network element UDM based on the first terminal information. The contract information of the sender.
The system according to claim 3, characterized in that the data sending end is specifically configured to:

Generate a first key pair; the first key pair includes the first public key and the first private key;

Sign the first public key and the first terminal information using the first private key and the first signature algorithm to determine a second digital signature;

The first data is generated based on the first public key, the first terminal information, a set of signature algorithms supported by the data sending end, and a second digital signature.
The system according to claim 4, characterized in that the DIVS AS is specifically configured as:

Verify the second digital signature according to the first public key and the first signature algorithm;

If the second digital signature verification passes, obtain the first terminal information in the first data;

The subscription information acquisition request is generated according to the first terminal information.
The system according to claim 5, characterized in that the DIVS AS is specifically configured as:

Generate a first data set to be signed based on the first data and contract data;

Sign the first data set to be signed according to the second private key and the second signature algorithm to determine the third digital signature; the second private key belongs to the second key pair generated by the DIVS AS;

The data integrity verification information is determined based on the first data set to be signed, the certificate corresponding to the second private key, and the third digital signature.
The system according to claim 6, characterized in that the DIVS AS is also configured to:

Send a first transaction identifier to the data sending end; wherein the first transaction identifier is used to characterize the storage information of the data integrity verification information in the blockchain.
The system according to claim 7, characterized in that the DIVS AS is also configured to:

The DIVS AS sends the first address information to the data sending end; wherein the first address information is the address information of the DIVS AS that stores the data integrity verification information corresponding to the first transaction identifier.
The system according to claim 8, wherein the UDM is further configured to: when the subscription information of the data sending end is updated, send a subscription information update message to the NEF; the subscription information update The message includes: the second terminal information of the data sending end, and the updated contract information of the data sending end;

The NEF is also configured to: forward the subscription information update message to the DIVS AS;

The DIVS AS is further configured to: query the latest target data integrity verification information including the second terminal information in the blockchain; and update the latest target data according to the updated contract information. Integrity verification information; store the updated latest target data integrity verification information in the blockchain.
The system according to claim 9, characterized in that:

The DIVS AS is specifically configured to: perform a first operation on each target data integrity verification information, and determine the updated each target data integrity verification information;

The first operation includes: generating a second data set to be verified based on the first data and the updated contract information;

Sign the second data set to be signed according to the second private key and the second signature algorithm to determine a fourth digital signature;

Based on the second data set to be signed, the certificate corresponding to the second private key, and the fourth digital signature, the updated target data integrity verification information is determined.
The system according to claim 10, characterized in that the DIVS AS is also configured to:

Send a second transaction identifier to the data sending end; wherein the second transaction identifier is used to characterize the storage information of the updated target data integrity verification information in the blockchain.
The system according to claim 11, characterized in that the DIVS AS is also configured to:

Send the second address information to the data sending end; wherein the second address information is the address information of the DIVS AS that stores the updated target data integrity verification information.
The system according to claim 12, characterized in that the data sending end is further configured to: receive at least one of the first transaction identification and the second transaction identification from the DIVS AS; the first The transaction identifier is a transaction identifier generated based on the storage information of the data integrity verification information in the blockchain; the second transaction identifier is the storage information in the blockchain based on the updated data integrity verification information. Generated transaction ID;

The first identifier is generated according to the latest transaction identifier among the first transaction identifier and the second transaction identifier.
The system according to claim 13, wherein the target data further includes a verification access address; the verification access address is used to characterize the address of the DIVS AS that stores the data integrity verification information of the data sending end; The data sending end is also configured to: receive at least one of the first address information and the second address information from the DIVS AS; the first address information is to store the data integrity corresponding to the first transaction identifier. The address information of the DIVS AS of the verification information; the second address information is the address information of the DIVS AS that stores the updated data integrity verification information corresponding to the second transaction identifier;

The verification access address is generated according to at least one of the first address information and the second address information.
The system according to any one of claims 1-14, characterized in that the target data also includes the timestamp of the first digital signature; the data integrity verification information also includes: the contract of the data sending end Validity period; the data receiving end is also configured to: determine whether the timestamp of the first digital signature Within the validity period of the contract at the data sending end;

If yes, it is determined that the data integrity verification of the data to be verified is successful.
The system according to claim 15, characterized in that the data receiving end is further configured to:

Verify the third digital signature according to the certificate corresponding to the second private key and the second signature algorithm;

If the verification of the third digital signature is successful, the first public key in the first data set to be signed is obtained.
The system according to any one of claims 1 to 14, characterized in that the first terminal information includes the embedded universal integrated circuit card identification eUICC ID/integrated circuit card identification code ICCID, international mobile equipment of the data sending end. At least one of the identification code IMEI and the mobile subscriber number MSISDN;

The second terminal information includes at least one of the eUICC ID/ICCID, IMEI and MSISDN.