Data Owner Rights Protection and Digital Identity Management Enabled by Blockchain

Blockchain is a decentralised network public ledger, from the perspective of data structure, the ledger consists of blocks, nodes collect and validate transactions in the network and organise the transactions into blocks in the form of a Mekle tree, and any change in the transaction will result in a change in the root value of the Mekle tree. The root value of the Mekle tree, together with the hash value of the previous block, the one-time count, and the timestamp make up the block header, and blocks are connected to each other using the hash pointer of the block header to form a chain structure. The blocks are connected to each other using the hash pointer of the block header to form a chain structure.

The consensus algorithm used in this paper is Practical Byzantine Fault Tolerant Consensus (PBFT). In PBFT, up to 1/3 of the malicious nodes in the system can be tolerated [24]. In a PBFT-based blockchain network, the blockchain nodes are divided into master and sub nodes. There is only one master node, while the rest are sub nodes. The master node receives the consensus request message from the client and sends it to the vice node, the vice node receives the message and performs the legitimacy verification and sends the verification result to the other nodes, when the number of passed verifications is greater than 2f+1 (f is the number of malicious nodes), then it confirms the message and replies to the client with the result of execution.

A smart contract is a set of state response rules that are securely stored on the blockchain. Smart contracts enable users to control their digital assets, express business logic, and formulate their rights and obligations. When two or more participants agree on every rule in a smart contract, it is then cryptographically signed and sent to the blockchain network for verification. The smart contract will be executed independently and automatically according to the rules formulated once the predefined conditions are triggered.

The implementation process of digital signature can be expressed as follows: the sender uses the hash function H to generate a digest d for the message M, and uses his own private key SK to sign d; then sends the message M together with the signature s to the receiver B; the receiver B verifies s using A’s public key PK, and if the signature is valid, it means that the message came from the sender A; the receiver B uses the hash function H to generate a digest d’ for the message M, and compares it with d sent by A. If the signatures are the same, the message will not be tampered with or corrupted. And compares it with the one sent by A. The message hasn’t been tampered with or corrupted if the digests are identical.

The representation of a general hash function is in the form of Equation H : →0,1}* → {0,1}ⁿ. where H is the hash function; {0,1}* is the set of inputs; and {0,1}ⁿ is the set of outputs. The hash function is a mapping function, which is centred on mapping an input value to an output value through an input value, and different input values should be mapped to different output values, but of the same length [25].

State secret algorithm (SM algorithm) refers to the standard of cryptographic algorithms independently developed by the Chinese cryptographic community, of which SM2 and SM3 algorithms are mainly applied in this paper [26–27].

The SM2 algorithm uses a fixed elliptic curve parameter set, which is selected as a secure parameter set that satisfies certain mathematical conditions, and is called the “SM2 recommended curve”. The specific parameters include the finite domain p, the elliptic curve equation parameters a and b, the order n of the points on the elliptic curve, and the coordinates of the base point G (Gx, Gy). These parameters are obtained through a series of calculations and verifications to satisfy the security requirements.

In the SM2 signature algorithm, the signature value is calculated as: 1R=(e+x1)modn 2s=((1+d)−1*(k−x1*r))modn where e is the hash of the message, x_I and r are random numbers on the curve, k is a random number, d is the private key and n is the order of the curve. The bilinear pair operation is used to compute the value of I + d. In SM2 encryption algorithm, the ciphertext is computed as: 3C1=[k]G 4C2=M⊕KDF(H,klen) 5C3=Hash(x2▯M▯y2) 6C=C1▯C2▯C3

Where, G is the base point, k is a random number, M is the plaintext message, H is the hash value of the message, k_len is the key length, KDF is the key derivation function, x₂ and y₂ are the coordinates of the public key and Hash is the hash function. The bilinear pair operation is used to compute C_l, where [k]G denotes the base G multiplied by k.

The SM3 algorithm can convert a message of arbitrary length into a 256-bit hash value for security applications such as data integrity checking, digital signatures, identity authentication, etc. The design idea of the SM3 algorithm is mainly borrowed from the SHA-256 algorithm, but it is different in the algorithmic structure, the message extension, the initial value setting, the nonlinear function, and the compression function.

The data sharing and interest protection system’s architecture is depicted in Figure 2. The auditing blockchain deploys smart contracts for the controlled flow of auditing data to achieve the functions of smart contract execution, uploading of deposited data to the chain, and querying and verification of information on the chain. Uploading audit behavior to the chain for certification is the basic guarantee for security review, and the realization of the blockchain’s certification of data operations, access records, etc. facilitates the tracing of responsibility and auditing after the fact. Internal and external network isolation technology is used by the data source end to ensure data security within each business department and create a secure and trustworthy data transmission channel. The data encryption component ensures that the audit data is transmitted in the form of cipher text to the external world. At the same time, it uses trusted root verification technology to ensure the chained credibility of data and prevent data from being tampered with during transmission. The data middle station summarizes the power data transmitted by each business department and stores the ciphertext of the audit data processed by the encryption component. It provides data upload, download, and storage services for internal personnel. The trusted execution environment is a secure development environment protected by hardware mechanisms with built-in API interfaces for key management, cryptographic algorithms, and so on. Auditors can conduct black-box audits in the trusted execution environment to protect the confidentiality of audit data.

Figure 2

Architecture design of data sharing rights protection system

Relying on the architecture of the data sharing rights protection system, a five-layer system business architecture is designed, including the data source layer, data processing layer, data sharing layer, data analysis and mining layer, and data visualisation layer. The whole application service process adopts smart contract management, encrypts the underlying data source, relies on the data sharing platform for ciphertext delivery management, implants the user requirement model for auditing calculation, and obtains and transmits the auditing result report through the data visualisation layer to ultimately realise the security protection of auditing data that is “available but not visible”. The architecture of the system for protecting shared rights is shown in Figure 3.

Figure 3.

Application architecture design of data sharing rights protection

Experimental environment: Windows system with Intel(R) Core(TM) i7-3687U CPU @2.10GHz 8GB RAM.

This section analyzes the performance test of the data owner’s rights protection system under blockchain mentioned above. The test includes the time consumption of six indicators: trusted preprocessing, audit file encryption, audit ciphertext upload, audit ciphertext download, audit file decryption, and trusted root verification.

Figure 5 demonstrates the results of the performance test of the entitlement protection system. This section records the time consumed results of testing each test element 150 times. As can be seen from the figure, the time consumption of the proposed interest protection system can be maintained in a small time consumption interval for 150 times of testing on trusted preprocessing, audit file encryption, audit ciphertext uploading, audit ciphertext downloading, audit file decryption, and trusted root authentication, e.g., the time consumption on trusted preprocessing is 6-7ms, which indicates that the system in this paper has a better stability of the interest protection. In addition, the average time consumption (ms) of 150 times tested on the six indicators is 6.50, 460.43, 28.99, 37.43, 240.09, and 6.47, respectively, which shows the feasibility of this paper’s interest protection system.

Figure 5.

The protection of rights and interests can test the results

In order to analyse the performance of the consensus algorithm in this paper, the following is a comparative analysis of this algorithm with other algorithms in terms of throughput. In testing the throughput performance, the experimental environment is kept the same, and the number of nodes is set to increase from 10 to 50. The comparison algorithms are PoW, PoS, and DPoS.

The performance and efficiency of a system can be determined by its throughput (TPS). The larger the system transaction throughput, the better the performance and efficiency of the algorithm. The calculation formula is as follows: 7TPS▯t=T_Transactions▯t/▯t where T_Transactions∆t denotes the total transaction volume per unit of time t, and ∆t denotes the time between the initiation of the creation of the transaction and the time interval between the block being confirmed.

The throughput comparison results of the four consensus algorithms are shown in Fig. 6. The throughput of all four consensus algorithms in the figure fluctuates, and the PoW algorithm has the lowest throughput between 150 and 196. Secondly, under different numbers of consensus nodes, the throughput of the proposed algorithm PBFT is always higher than that of the comparison algorithms, and when the number of nodes is 50, it improves by 1188, 362 and 245 compared with PoW, PoS and DPoS, respectively. It can be seen that PBFT is more stable in throughput under the condition of increasing the number of consensus nodes. In addition, the throughput averages of the four consensus algorithms are, in descending order, 169 (PoW), 945 (PoS), 1208 (DPoS), and 1300 (PBFT). To sum up, the throughput of the algorithm presented in this paper is the best performance among these algorithms.

Figure 6.

The throughput comparison results of the four consensus algorithms

The data user enters an account number, selects a login role, and clicks the Register button. The frontend sends the account name and role type to the back-end, which verifies that the digital user has been registered, and the system calls the Register interface function in the registration smart contract to store the DID document, didDocument, that records the data user’s public key, PK, with the distributed identifier, DID, to complete the identity registration.

The Identity Center is accessed by the identity owner to add certificate information and complete the identity data form. The identity owner chooses the data provider as the authentication organization for their identity credentials and then inputs the original identity data into the text box to apply for the identity credentials.

The data provider logs into the “Pending Credentials Center” of the system to view the list of identity credential applications of the data owner. The provider looks up the corresponding identity data cipher text, decrypts the original identity data information using the private key, verifies the authenticity of the original identity data, and issues the identity credentials to the data owner after the verification is successful.

The service provider requests identity credentials from the data owner, who encrypts the identity credentials VC and returns them. The service provider calls queryDIDDocument interface function to find the DID document according to the data provider identifier dpDID in the VC, and obtains its public key value to verify the signature value of the identity credential. If the verification passes, it proves that the identity credential is genuine and legitimate. If the verification passes, the service provider calls the queryUserIdentityClaim interface function in the smart contract to query the hash value of the identity credential declaration VCHash, calculate the hash value of the identity credential credential’s credentialSubject, and then compare the VCHash of the identity credential declaration with the HASH of the identity credential, and then, if it is the same, prove that the identity credential provided by the data owner is real and legitimate. If the identity credential provided by the data owner is credible, authentication will pass; otherwise, authentication will fail.

In order to further assess the feasibility of the identity management system, this section conducts a performance test on the proposed system simulation implementation by measuring the performance overhead of the key interaction operations during the authentication process in order to assess the overall performance of the system, the selected interaction operation is credential issuance.

The issuer node issues 100, 500, 700, 1000, and 1500 credentials to the holder node, respectively, and network system 1 (Hyrax) and network system 2 (Bulletproofs) are chosen as the comparison systems to observe their completion time. The comparison results of the total time (s) for issuing credentials with different throughputs are shown in Fig. 8. Table 1 shows the average time consumed (ms) for individual credentials with different throughputs.

Figure 8

The total time of issuing certificates under different throughput

As can be seen from the chart, the total time consumed for issuing credentials of this system is lower than that of the comparison system under different credential issuing volume, e.g., when the credential issuing volume is 1500, the time consumed (s) of this system is lower than that of the network systems 1 and 2 by 46.88 and 24.56, respectively. In addition, the average time consumed for issuing single credentials of the present system, the network system 1, and the network system 2 is found to be 64.474, 94.596, and 86.764, it can be seen that in the operation of approaching credentials from the issuer node to the holder node, when the number of credentials reaches the order of hundreds, the average time consuming of issuing a single credential does not show a significant increase in time consuming with the rise in the amount of credentials. Meanwhile, the average time consumed for issuing a single credential in this paper can meet the system’s requirements for the performance overhead of the key operations of identity management.

In order to evaluate and test the time overhead performance of this system, this section compares the system in this paper with the two reference systems in the previous section, in an experimental setting consistent with the above. Fig. 9 depicts the variation of time cost with the number of signatures for the aggregation phase and the aggregation verification phase.

Figure 9.

Time cost varies with the number of signatures

As can be seen from the figure, when the number of nodes increases linearly, the sum of time costs for both the aggregation and aggregation verification phases of the three groups of systems shows an upward trend, but with the increase in the number of nodes, the sum of time costs of this paper’s system is always lower than that of the control system, and when the number of nodes is 150, the system of this paper reduces its time consumption (ms) by 141.80 and 103.76 compared to the network systems 1 and 2, respectively.

In order to further test the performance of the identity management systems proposed in this paper, this section also compares the computational overheads on the user side and server side. Table 2 shows the time (ms) overhead of the three sets of systems on the user and server sides during the cross-domain authentication phase. From the table, it is clear that the time overhead of this paper’s system is slightly higher than the other two systems at the user side and server side and it requires more overhead at the server side which is 13.65 ms. This is because the system used in this paper uses multi-signature, which is more costly. But the system in this paper completes the authentication of bulk users instead of one-to-one authentication in the comparative system, the user side does not need to add too many operations and the multi-signature is calculated by the server.