Block chain evidence storage method and system

Abstract

The invention relates to the technical field of block chains, and discloses a block chain evidence storage method and system, and the method comprises the steps: obtaining to-be-stored data, and generating a random password for the to-be-stored data; encrypting the to-be-stored data by using the random password to obtain encrypted stored data; acquiring a public key of the authorized object from a pre-public key database, and encrypting the random password by using the public key to obtain an encrypted password; and uploading the encrypted password and the encrypted evidence storage data to the block chain through an IERC821 standard-based smart contract, promoting the authorized object to obtain the encrypted password and the encrypted evidence storage data in the block chain, decrypting the encrypted password through a private key corresponding to the public key to obtain a random password, and decrypting the encrypted data to be stored through the random password to obtain the encrypted data to be stored. And obtaining evidence storage data. According to the invention, a random password encryption technology and a public and private key encryption technology are mixed to carry out authorized encryption and sharing on the evidence storage information, and privacy protection and controllable sharing of the evidence storage information on the block chain can be realized.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a blockchain evidence storage method and system. Background Art

[0002] Blockchain technology, due to its characteristics of being tamper-proof, decentralized and distributed, is widely used in the evidence storage process of information exchange, value exchange, rights exchange and other behaviors among multiple parties. The relevant application scenarios that have been implemented include medical data exchange evidence storage, big data transaction evidence storage, digital art collection evidence storage, etc. Blockchain technology can ensure that the evidence information cannot be tampered with, the traceability is reliable, and the information is open and transparent. However, the transparency of this distributed ledger also brings serious privacy and security issues.

[0003] In some sensitive areas, the privacy and security issues of blockchain evidence storage are particularly important. For example, in the process of medical data circulation and evidence storage, especially when it involves the exchange of user medical records, these data may be leaked due to the distributed storage characteristics of blockchain. This is an unacceptable risk for both hospitals and patients. Even if only basic evidence information, such as the desensitized user name (nickname), evidence data type, and the hospital to which it belongs, is stored on the chain, it will inevitably expose important information such as the user's health status, number of medical visits, and hospital traffic.

[0004] Therefore, how to provide a privacy-sensitive, secure and controllable blockchain evidence storage method is an urgent problem that needs to be solved. Summary of the invention

[0005] The embodiments of the present invention provide a blockchain evidence storage method and system to solve the above-mentioned technical problems in the prior art.

[0006] In order to have a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended to be a general review, nor is it intended to identify key / important components or to delineate the scope of protection of these embodiments. Its only purpose is to present some concepts in a simple form as a preface to the detailed description that follows.

[0007] According to a first aspect of an embodiment of the present invention, a blockchain evidence storage method is provided.

[0008] In one embodiment, the blockchain evidence storage method includes:

[0009] Acquire the data to be stored as evidence, generate a random password for the data to be stored; and encrypt the data to be stored as evidence using the random password to obtain encrypted stored evidence data;

[0010] Obtaining the public key of the authorized object in a pre-public key database, and encrypting the random password using the public key to obtain an encrypted password;

[0011] The encrypted password and the encrypted evidence data are uploaded to the blockchain through a smart contract based on the IERC821 standard, prompting the authorized object to obtain the encrypted password and the encrypted evidence data in the blockchain, and decrypt the encrypted password through the private key corresponding to the public key to obtain a random password, and decrypt the encrypted data to be stored through the random password to obtain the evidence data.

[0012] In one embodiment, when the random password is used to encrypt the data to be stored, the random password is used to symmetrically encrypt the data to be stored.

[0013] In one embodiment, when the random password is encrypted using the public key, the random password is asymmetrically encrypted using the public key.

[0014] In one embodiment, the public key database is stored on a server of each blockchain node or in a user registration smart contract stored in the blockchain.

[0015] In one embodiment, the smart contract based on the IERC821 standard includes an SSNFT extended smart contract, an SSNFT basic smart contract and an IERC821 smart contract interface standard; the SSNFT extended smart contract inherits from the SSNFT basic smart contract, and the SSNFT basic smart contract inherits and implements the IERC821 smart contract interface standard.

[0016] According to a second aspect of an embodiment of the present invention, a blockchain evidence storage system is provided.

[0017] In one embodiment, the blockchain evidence storage system includes:

[0018] A data encryption module is used to obtain the data to be stored, generate a random password for the data to be stored, and encrypt the data to be stored using the random password to obtain encrypted stored data;

[0019] A password encryption module, used to obtain the public key of the authorized object in a pre-public key database, and encrypt the random password using the public key to obtain an encrypted password;

[0020] The data evidence module is used to upload the encrypted password and the encrypted evidence data to the blockchain through a smart contract based on the IERC821 standard, prompting the authorized object to obtain the encrypted password and the encrypted evidence data in the blockchain, and decrypt the encrypted password through the private key corresponding to the public key to obtain a random password, and decrypt the encrypted data to be stored through the random password to obtain the evidence data.

[0021] In one embodiment, when the random password is used to encrypt the data to be stored, the random password is used to symmetrically encrypt the data to be stored.

[0022] In one embodiment, when the random password is encrypted using the public key, the random password is asymmetrically encrypted using the public key.

[0023] In one embodiment, the public key database is stored on a server of each blockchain node or in a user registration smart contract stored in the blockchain.

[0024] In one embodiment, the smart contract based on the IERC821 standard includes an SSNFT extended smart contract, an SSNFT basic smart contract and an IERC821 smart contract interface standard; the SSNFT extended smart contract inherits from the SSNFT basic smart contract, and the SSNFT basic smart contract inherits and implements the IERC821 smart contract interface standard.

[0025] According to a third aspect of an embodiment of the present invention, a computer device is provided.

[0026] In one embodiment, the computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.

[0027] According to a fourth aspect of embodiments of the present invention, a computer-readable storage medium is provided.

[0028] In one embodiment, the computer-readable storage medium stores a computer program, and the computer program implements the steps of the above method when executed by a processor.

[0029] The technical solution provided by the embodiment of the present invention may have the following beneficial effects:

[0030] The present invention uses a combination of random password encryption technology and public-private key encryption technology to perform authorized encryption and sharing of evidence information, which can achieve privacy protection and controllable sharing of evidence information on the blockchain, and can adapt to privacy-safe and controllable evidence storage processes in a variety of scenarios.

[0031] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0033] Figure 1 It is a flowchart of a blockchain evidence storage method according to an exemplary embodiment;

[0034] Figure 2 It is a structural block diagram of a blockchain evidence storage system according to an exemplary embodiment;

[0035] Figure 3 It is a schematic diagram of the SSNFT evidence storage process according to an exemplary embodiment;

[0036] Figure 4 is a schematic diagram of the module composition of SSNFT according to an exemplary embodiment;

[0037] Figure 5 is an example diagram of a smart contract based on the IERC821 standard according to an exemplary embodiment;

[0038] Figure 6 is a schematic diagram of a mode of separating evidence storage from business according to an exemplary embodiment;

[0039] Figure 7 is a schematic diagram of a storage structure of evidence on a blockchain according to an exemplary embodiment;

[0040] Figure 8 is a schematic diagram of the data structure of a user registration smart contract according to an exemplary embodiment;

[0041] Fig. 9 The figure is a schematic diagram showing the structure of a computer device according to an exemplary embodiment. DETAILED DESCRIPTION

[0042] The following description and accompanying drawings fully illustrate the specific embodiments of this article so that those skilled in the art can practice them. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. The scope of the embodiments of this article includes the entire scope of the claims, as well as all available equivalents of the claims. Herein, the terms "first", "second", etc. are only used to distinguish one element from another, without requiring or implying any actual relationship or order between these elements. In fact, the first element can also be called the second element, and vice versa. Moreover, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that the structure, device or equipment including a series of elements includes not only those elements, but also other elements that are not explicitly listed, or also include elements inherent to such structure, device or equipment. In the absence of more restrictions, the elements defined by the sentence "including one..." do not exclude the existence of other identical elements in the structure, device or equipment including the elements. Each embodiment is described in a progressive manner herein, and each embodiment focuses on the differences from other embodiments, and the same and similar parts between the embodiments can be referred to each other.

[0043] The terms "longitudinal", "lateral", "upper", "lower", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", etc. in this document indicate the orientation or position relationship based on the orientation or position relationship shown in the drawings, and are only for the convenience of describing this document and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operate in a specific orientation, and therefore cannot be understood as a limitation on the present invention. In the description of this document, unless otherwise specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a mechanical connection or an electrical connection, it can also be the internal communication of two elements, it can be a direct connection, or it can be an indirect connection through an intermediate medium. For ordinary technicians in this field, the specific meanings of the above terms can be understood according to specific circumstances.

[0044] As used herein, the term "plurality" means two or more than two, unless otherwise specified.

[0045] In this document, the character " / " indicates that the preceding and following objects are in an "or" relationship. For example, A / B means: A or B.

[0046] In this article, the term "and / or" is a description of the association relationship between objects, indicating that three relationships may exist. For example, A and / or B means: A or B, or, A and B.

[0047] It should be understood that, although the various steps in the flow chart are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the figure may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0048] Each module in the device or system of the present application can be implemented in whole or in part by software, hardware, or a combination thereof. The above modules can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to the above modules.

[0049] In the absence of conflict, the embodiments of the present invention and the features of the embodiments may be combined with each other.

[0050] Figure 1 An embodiment of a blockchain evidence storage method of the present invention is shown.

[0051] In this optional embodiment, the blockchain evidence storage method includes:

[0052] Step S101, obtaining data to be stored as evidence, generating a random password for the data to be stored; and encrypting the data to be stored as evidence using the random password to obtain encrypted stored data;

[0053] Step S103, obtaining the public key of the authorized object in the pre-public key database, and encrypting the random password using the public key to obtain an encrypted password;

[0054] Step S105, uploading the encrypted password and the encrypted evidence data to the blockchain through a smart contract based on the IERC821 standard, prompting the authorized object to obtain the encrypted password and the encrypted evidence data in the blockchain, and decrypting the encrypted password through the private key corresponding to the public key to obtain a random password, and decrypting the encrypted data to be stored through the random password to obtain the evidence data.

[0055] In this optional embodiment, when acquiring the data to be stored, the original system acquires data from an external interface or generates data generated by internal information processing, and generates the data content to be stored after packaging. When the random password is used to encrypt the data to be stored, the random password is used to symmetrically encrypt the data to be stored; when the public key is used to encrypt the random password, the public key is used to asymmetrically encrypt the random password. Among them, the symmetric encryption algorithm includes but is not limited to the use of mainstream symmetric encryption algorithms such as DES, AES, RC, and symmetric encryption algorithms such as SM1, SM4, SM7, and Zu Chongzhi of the National Security. Asymmetric encryption algorithms include but are not limited to the use of mainstream asymmetric encryption algorithms such as RSA, DSA, ECC, or asymmetric encryption algorithms such as SM2 and SM9 of the National Security.

[0056] In this optional embodiment, the public key database is stored on the server of each blockchain node or in the user registration smart contract stored in the blockchain. For the user registration smart contract, the user registration smart contract includes a Key structure that stores the user's public key and other related information. The structure at least includes the user's blockchain address and public key, a publicKeys field of a mapping data type, one or more keyIndex fields of a mapping type, a register method, a revoke method, and a getPublicKey method. The user registration smart contract requires that the administrator deploy it to the blockchain in advance before use. Among them, the publicKeys field is used to store the mapping relationship between the user address and its corresponding Key structure instance; the keyIndex field is used to store the index of the Key structure instance related to the user's public key; the register method is used to provide the function of registering a new user, passing in the user's public key, the data type is bytes (bytes) or string (string); the revoke method is used to provide the function of user cancellation of user information; the getPublicKey method is used to provide the query function of public information, mainly public key query.

[0057] In this optional embodiment, the smart contract based on the IERC821 standard includes an SSNFT extended smart contract, an SSNFT basic smart contract and an IERC821 smart contract interface standard; the SSNFT extended smart contract inherits from the SSNFT basic smart contract, and the SSNFT basic smart contract inherits and implements the IERC821 smart contract interface standard.

[0058] Specifically, the SSNFT extended smart contract inherits from the SSNFT basic smart contract, and contains a constructor that requires the name of the evidence and the type of evidence to be passed in; it contains a field tokenIds for the evidence list, which is a mapping data type that maps the relationship between the primary key of the evidence and the evidence instance; it contains one or more fields tokenIndex for the evidence index, which is a mapping data type that maps the relationship between the indexes of multiple evidences and the evidence instance, or the relationship between the evidence index and the primary key of the evidence; it contains a method getTokenByIndex for searching evidence by index, which queries the instance of the evidence according to the index or primary key; it contains a mint method for initiating a new evidence, passing in the encrypted evidence content and password; it contains a share method for authorizing the sharing of evidence to a third-party object.

[0059] The SSNFT basic contract inherits from the IERC821 smart contract interface standard and needs to implement all interfaces in IERC821. It contains a name field, which is of string or bytes type, to store the name of the certificate; it contains a typeId field, which is of integer (uint) data type, to store the category of the certificate; it contains a Token structure, which contains at least the certificate content field content and the certificate password mapping relationship field keys, content stores the encrypted certificate content, which is of bytes or string type, and keys stores the mapping from the certificate authorization address to the certificate password, and the data type is mapping; it contains a share method to implement the certificate authorization sharing required by IERC821; it contains a mint interface to implement the certificate creation interface required by IERC821. In addition, the IERC821 smart contract interfaces must be implemented in the SSNFT basic smart contract.

[0060] IERC821 is a standard interface contract that the upper-level SSNFT smart contract needs to implement, including: name interface, typeId interface, balanceOf interface, creatorOf interface, shareListOf interface, key interface and content interface.

[0061] When in use, the authorized object needs to call the deployed smart contract based on the IERC821 standard. If the SSNFT extended smart contract needs to be called, the calling process first needs to specify the contract deployment address of the above contract in the blockchain, and then call the index search evidence method getTokenByIndex, or other similar evidence search methods that have undergone equivalent transformations, enter the index (including the primary key) and object address, and finally obtain the encrypted evidence password and encrypted evidence content corresponding to the authorized object address.

[0062] Figure 2 An embodiment of a blockchain evidence storage system of the present invention is shown.

[0063] In this optional embodiment, the blockchain evidence storage system includes:

[0064] The data encryption module 201 is used to obtain the data to be stored, generate a random password for the data to be stored, and encrypt the data to be stored using the random password to obtain encrypted stored data;

[0065] The password encryption module 203 is used to obtain the public key of the authorized object in the pre-public key database, and use the public key to encrypt the random password to obtain an encrypted password;

[0066] The data evidence module 205 is used to upload the encrypted password and the encrypted evidence data to the blockchain, prompting the authorized object to obtain the encrypted password and the encrypted evidence data in the blockchain, and decrypt the encrypted password through the private key corresponding to the public key to obtain a random password, and decrypt the encrypted data to be stored through the random password to obtain the evidence data.

[0067] In this optional embodiment, when acquiring the data to be stored, the original system acquires data from an external interface or generates data generated by internal information processing, and generates the data content to be stored after packaging. When the random password is used to encrypt the data to be stored, the random password is used to symmetrically encrypt the data to be stored; when the public key is used to encrypt the random password, the public key is used to asymmetrically encrypt the random password. Among them, the symmetric encryption algorithm includes but is not limited to the use of mainstream symmetric encryption algorithms such as DES, AES, RC, and symmetric encryption algorithms such as SM1, SM4, SM7, and Zu Chongzhi of the National Security. Asymmetric encryption algorithms include but are not limited to the use of mainstream asymmetric encryption algorithms such as RSA, DSA, ECC, or asymmetric encryption algorithms such as SM2 and SM9 of the National Security.

[0068] In this optional embodiment, the public key database is stored on the server of each blockchain node or in the user registration smart contract stored in the blockchain. For the user registration smart contract, the user registration smart contract includes a Key structure that stores the user's public key and other related information. The structure at least includes the user's blockchain address and public key, a publicKeys field of a mapping data type, one or more keyIndex fields of a mapping type, a register method, a revoke method, and a getPublicKey method. The user registration smart contract requires that the administrator deploy it to the blockchain in advance before use. Among them, the publicKeys field is used to store the mapping relationship between the user address and its corresponding Key structure instance; the keyIndex field is used to store the index of the Key structure instance related to the user's public key; the register method is used to provide the function of registering a new user, passing in the user's public key, the data type is bytes (bytes) or string (string); the revoke method is used to provide the function of user cancellation of user information; the getPublicKey method is used to provide the query function of public information, mainly public key query.

[0069] In this optional embodiment, the smart contract based on the IERC821 standard includes an SSNFT extended smart contract, an SSNFT basic smart contract and an IERC821 smart contract interface standard; the SSNFT extended smart contract inherits from the SSNFT basic smart contract, and the SSNFT basic smart contract inherits and implements the IERC821 smart contract interface standard.

[0070] Specifically, the SSNFT extended smart contract inherits from the SSNFT basic smart contract, and contains a constructor that requires the name of the evidence and the type of evidence to be passed in; it contains a field tokenIds for the evidence list, which is a mapping data type that maps the relationship between the primary key of the evidence and the evidence instance; it contains one or more fields tokenIndex for the evidence index, which is a mapping data type that maps the relationship between the indexes of multiple evidences and the evidence instance, or the relationship between the evidence index and the primary key of the evidence; it contains a method getTokenByIndex for searching evidence by index, which queries the instance of the evidence according to the index or primary key; it contains a mint method for initiating a new evidence, passing in the encrypted evidence content and password; it contains a share method for authorizing the sharing of evidence to a third-party object.

[0071] The SSNFT basic contract inherits from the IERC821 smart contract interface standard and needs to implement all interfaces in IERC821. It contains a name field, which is of string or bytes type, to store the name of the certificate; it contains a typeId field, which is of integer (uint) data type, to store the category of the certificate; it contains a Token structure, which contains at least the certificate content field content and the certificate password mapping relationship field keys, content stores the encrypted certificate content, which is of bytes or string type, and keys stores the mapping from the certificate authorization address to the certificate password, and the data type is mapping; it contains a share method to implement the certificate authorization sharing required by IERC821; it contains a mint interface to implement the certificate creation interface required by IERC821. In addition, the IERC821 smart contract interfaces must be implemented in the SSNFT basic smart contract.

[0072] IERC821 is a standard interface contract that the upper-level SSNFT smart contract needs to implement, including: name interface, typeId interface, balanceOf interface, creatorOf interface, shareListOf interface, key interface and content interface.

[0073] When in use, the authorized object needs to call the deployed smart contract based on the IERC821 standard. If the SSNFT extended smart contract needs to be called, the calling process first needs to specify the contract deployment address of the above contract in the blockchain, and then call the index search evidence method getTokenByIndex, or other similar evidence search methods that have undergone equivalent transformations, enter the index (including the primary key) and object address, and finally obtain the encrypted evidence password and encrypted evidence content corresponding to the authorized object address.

[0074] In specific applications, Figure 3 The basic process of the SSNFT evidence storage method is introduced: first, the business logic layer generates a random password, then uses the random password to symmetrically encrypt the evidence data, and then uses the authorized object's public key to asymmetrically encrypt the random password, and finally uploads the encrypted evidence and the encrypted password to the chain. The authorized object obtains the evidence on the chain and finds the encryption password corresponding to its wallet address, uses the private key to asymmetrically decrypt the password, and uses the password to symmetrically decrypt the ciphertext of the evidence, and finally obtains the original text of the evidence.

[0075] Figure 4The module composition and specific process of implementing SSNFT are introduced. The whole process consists of two parts: off-chain and on-chain. The off-chain (business logic layer) server generates the original text of the evidence and generates a random password. The random password is used to symmetric encrypt the data to be stored to obtain the encrypted evidence. Then, the server queries the public key list of the authorized target from the public key library, asymmetrically encrypts the random password, and obtains the encrypted password. In the on-chain part, the server requests the evidence business smart contract deployed on the chain to perform the evidence transaction. The blockchain verifies the transaction, packages the transaction, and generates a block. At this point, the evidence process is completed.

[0076] The SSNFT (Safe Shareable Non-Fungible Token) method also requires the completion of the evidence decryption and verification logic off-chain. The authorized party reads the encrypted evidence content and password from the on-chain smart contract, and returns to the off-chain part. The business logic layer server first uses the private key to asymmetrically decrypt the random password, and then uses the password to symmetrically decrypt the evidence content. In the whole process, an important feature is that the blockchain and smart contracts on the chain only provide "evidence + password" storage and packaging services, and do not perform business logic processing, encryption and decryption processing.

[0077] In order to better understand the SSNFT method, the characteristics of each component of the SSNFT method are described in detail below from various angles.

[0078] 1. For evidence encryption, let the plaintext to be stored be s, the plaintext of the random password be k, and use a symmetric encryption algorithm Encrypt s:

[0079]

[0080] The encrypted evidence is S. Then k is asymmetric encrypted with the specified authorized object θ:

[0081] K[n]=[θ(k,p1),θ(k,p2),θ(k,p3),θ(k,p4),...]

[0082] Get the encrypted password sequence: K[n], map the address of the specified authorized object and the encrypted password α, and trade it on the chain together with the encrypted evidence content S:

[0083] T(S,α n (K)

[0084] Among them, [p1, p2, p3, p4] are the public keys of authorized objects 1, 2, 3, and 4 respectively. T represents an on-chain transaction, which is usually executed on a smart contract. α represents the on-chain address mapping of the object, and the address is generated using the public key.

[0085] 2. For evidence storage and decryption, assuming that the ciphertext content of the evidence on the chain is S, the random password corresponding to the authorized object is stored on the chain as:

[0086] K n =[α1(K),α2(K),α3(K),α4(K),...]

[0087] The symmetric decryption process is:

[0088] k=[O(K1,P1),O(K2,P2),O(K3,P3),O(K4,P4),...]

[0089] Get the plaintext password k and use the password k to decrypt the ciphertext evidence content:

[0090] Φ(S,k)→s

[0091] The authorized object obtains the proof of existence document s.

[0092] Among them, [P1, P2, P3, P4] are the private keys of authorized objects 1, 2, 3, and 4 respectively, Φ represents symmetric decryption, and O is the asymmetric decryption method.

[0093] 3. For smart contracts and interface standards, Figure 5 This paper introduces the inheritance relationship, main data structure, method functions and other aspects of smart contracts in SSNFT. The smart contracts involved in the SSNFT method should include: IERC821 contract interface standard, SSNFT basic smart contract and SSNFT extended smart contract. The relationship between the above smart contracts is: SSNFT extended contract inherits from SSNFT basic contract, and SSNFT basic contract implements the interface standard specified by IERC821. Usually, a customized extended contract is implemented for specific business needs. The extended contract can flexibly save more index fields and methods for tokens, but it should be noted that this means that more plain text of token-related fields will be exposed at the smart contract level.

[0094] The IERC821 smart contract interface standard requires the inheritor to implement the following method interfaces: the name method for obtaining the name of the evidence business; the typeId method for obtaining the evidence type; the balanceOf method for evidence count, inputting the address of the evidence creator; the creatorOf method for querying the evidence creator, inputting the evidence primary key (tokenId); the shareListOf method for querying the evidence authorization list, inputting the evidence primary key (tokenId); the key method for obtaining the evidence encryption password, inputting the evidence primary key (tokenId) and the authorized party address; the content method for obtaining the encrypted content of the evidence, inputting the evidence primary key tokenId.

[0095] The SSNFT basic smart contract must inherit and implement the IERC821 interface standard contract. The contract contains a name field that stores the name of the evidence business, which is a string data type; it also needs to store an id of the evidence category, the typeId field, which is a uint data type; the Token in the basic contract is a structure that represents the evidence data structure, which contains at least two fields: content and keys, where content is the content of the evidence, which is a string type, and here should be the encrypted evidence content, and keys stores the mapping of the authorized object chain address to its encryption password, which is a mapping type. The evidence list tokens is a mapping field from the primary key of the evidence to the token instance of the evidence, which is a mapping type. The methods of the SSNFT basic contract include share, which is a method of authorizing an object to share the evidence, and requires the input of the primary key of the evidence, the address of the authorized sharing object, and the encryption password; mint is a method of adding a new evidence, and the encrypted content and encryption password of the evidence are input. In addition, since the SSNFT basic contract inherits from IERC821, it is necessary to implement all the interfaces required by IERC821 in the previous section.

[0096] The SSNFT extended smart contract inherits from the SSNFT basic contract and needs to implement the constructor method of the basic contract to enter the specific evidence business name (name) and evidence type (typeId). The extended contract contains a tokenIds field, which is a self-incrementing primary key for evidence, which can be simply implemented as a self-incrementing number or other specified numbering format. The tokenIndex in the extended contract refers to various indexes of evidence, generally of mapping type, and should be customized in the extended contract according to business needs. This field can be implemented as multiple indexes of evidence, or it can be not implemented.

[0097] 4. For the separation mode of evidence storage and business, in the actual application of the SSNFT method, the evidence storage and business logic are designed and operated in a separate mode. The evidence storage only saves the encrypted password and encrypted evidence storage content, and the user address list or mapping authorized for sharing. The specific business logic-related algorithms and data structures are designed to be implemented off-chain, because the methods of the business logic layer often change greatly and the amount of data operated is large and complex, which is not suitable for the logic and storage mode of the blockchain. The database is used to assist the blockchain in the addition, deletion, modification and query of business data (including data structure), and the general programming language is used to assist the blockchain in data analysis and various operations. These include: (1) encryption and decryption of evidence storage; (2) storage of complex data structures of various businesses, such as tree structure, graph structure, chain structure, etc. (3) The business logic layer queries and uses the evidence storage on the chain by operating the index of the evidence storage, such as tokenIds.

[0098] Figure 6 A special case of a solution for storing user behavior evidence in a medical data flow scenario is introduced to facilitate the understanding of the present invention. This service requires the traceability of the evidence link of medical data flow, and also requires the privacy protection of the evidence content. Suppose that a storage service called "transmitting medical data" is implemented, which aims to store on-chain evidence of users sending personal medical information to third parties. Suppose that the evidence is sent to three parties: hospitals, insurance companies, and the National Health Commission. In this scenario, the algorithms that need to be implemented in the business logic layer (off-chain) include encryption of the evidence content, that is, asymmetric encryption of the passwords of the three parties: hospitals, insurance companies, and the National Health Commission. The off-chain storage structure includes a tree-like storage structure ( Figure 6 The right half of the diagram shows the nodes in the tree diagram, which represent objects (authorized objects or unauthorized objects), and the edges between the nodes represent the evidence. The edges of this tree diagram only store the index of the evidence, such as the tokenId in the above contract, and the actual evidence content has been encrypted on the chain. When a user needs to trace the source, the corresponding tree diagram is queried from the off-chain, and the evidence ciphertext is read from the chain according to the index of the nodes and edges on the tree diagram, and then output to the visual graphical interface after decryption.

[0099] 5. For the evidence storage structure on the blockchain, Figure 7 The hierarchical relationship of the storage structure of the evidence data after it is put on the chain is revealed. The first layer is the block, which contains various transactions. Transactions are not necessarily just evidence transactions, but also regular blockchain contract transactions, and the actual evidence content is stored under the evidence transaction.

[0100] 6. For the user registration smart contract, in order to facilitate the implementation of the SSNFT scheme, especially considering the requirement for users to asymmetric encrypt the password to specify the authorized address before initiating or sharing the certificate, it is possible to add a user registration smart contract to retrieve the address, public key and other information of the user on the chain. It should be noted that the user registration contract is not a necessary functional module of the SSNFT scheme itself, but an additional enhancement module to assist SSNFT users in quickly finding the address, public key and other information of the authorized sharing object on the chain.

[0101] The data structure and method functions of the user registration smart contract are as follows Figure 8 As shown, a list of user public key registration information (publicKeys) must be disclosed on the smart contract. In addition, it should also include an index field for publicKeys, using the mapping data type index. The index can be set to 0 or more, the purpose is to quickly find the public key of the shared object. In addition, the smart contract also includes a user registration method, a user cancellation method, and various index methods, such as the getPublicKey method for obtaining the public key of the target address.

[0102] Since the disclosure of public keys does not pose a risk to information security, traditional methods can be used to replace user registration contracts to store user public key information, such as manually recording and registering user public keys, or using centralized libraries to access user public key lists.

[0103] In the specific verification, Solidity was used to write and implement smart contracts, Node.js was used to simulate the business logic layer, and experiments were conducted on the business scenario of medical data sharing and evidence storage. In the experiment, a total of 10 medical evidence data for testing, 1 symmetric encryption algorithm and 3 asymmetric encryption algorithms were prepared. In order to increase the pressure and real effect of the test, the 10 data were cloned into 10,000 data, and 100 batches of chain operations were performed with 100 evidences uploaded to the chain each time. After the evidence is uploaded to the chain, the 10,000 evidence data are shared again. Each time a request is made to share 20 evidences, each evidence is shared to 5 random addresses, that is, 100 sharing transactions are requested at a time, and 500 batches of sharing requests are made. The data obtained from the experiment are shown in the following table:

[0104] Table 1: Experimental results of implementing SSNFT using various encryption and storage methods

[0105]

[0106]

[0107] Table 1 is the data obtained from the experiment, which mainly includes the results of on-chain data expansion (space consumption) and running time (time consumption) after mint testing and share testing of SSNFT.

[0108] The experimental group is divided into two SSNFT solutions based on two different evidence data types: string storage and bytes storage, which respectively refers to the use of Solidity's string type and bytes type to store the evidence content on the chain. The experimental results show that the bytes type can greatly save storage space. Therefore, we ultimately recommend using the bytes type data type to store evidence and passwords in a production environment. In this experiment, one transaction corresponds to only one evidence. "ETH" refers to the asymmetric encryption algorithm ECDSA secp256k1 used by Ethereum.

[0109] Fig. 9 An embodiment of a computer device of the present invention is shown. The computer device may be a server, and the computer device includes a processor, a memory, and a network interface connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store static information and dynamic information data. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, the steps in the above method embodiment are implemented.

[0110] Those skilled in the art will understand that Fig. 9 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present invention, and does not constitute a limitation on the computer device to which the solution of the present invention is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0111] In addition, the present invention also provides a computer device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiment when executing the computer program.

[0112] In addition, the present invention further provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps in the above method embodiment are implemented.

[0113] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided by the present invention can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0114] The present invention is not limited to the structures which have been described above and shown in the drawings, and various modifications and changes may be made without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A blockchain evidence storage method, characterized in that: include: Acquire the data to be stored as evidence, generate a random password for the data to be stored; and encrypt the data to be stored as evidence using the random password to obtain encrypted stored evidence data; Obtaining the public key of the authorized object in a pre-public key database, and encrypting the random password using the public key to obtain an encrypted password; The encrypted password and the encrypted evidence data are uploaded to the blockchain through a smart contract based on the IERC821 standard, prompting the authorized object to obtain the encrypted password and the encrypted evidence data in the blockchain, and decrypt the encrypted password through the private key corresponding to the public key to obtain a random password, and decrypt the encrypted data to be stored through the random password to obtain the evidence data.

2. The blockchain evidence storage method according to claim 1 is characterized in that: When the random password is used to encrypt the data to be stored, the random password is used to symmetrically encrypt the data to be stored.

3. The blockchain evidence storage method according to claim 1 is characterized in that: When the random password is encrypted by using the public key, the random password is asymmetrically encrypted by using the public key.

4. The blockchain evidence storage method according to claim 1, characterized in that: The public key database is stored on the server of each blockchain node or in the user registration smart contract of the blockchain.

5. The blockchain evidence storage method according to claim 1 is characterized in that: The smart contract based on the IERC821 standard includes an SSNFT extended smart contract, an SSNFT basic smart contract and an IERC821 smart contract interface standard; the SSNFT extended smart contract inherits from the SSNFT basic smart contract, and the SSNFT basic smart contract inherits and implements the IERC821 smart contract interface standard.

6. A blockchain evidence storage system, characterized in that: include: A data encryption module is used to obtain the data to be stored, generate a random password for the data to be stored, and encrypt the data to be stored using the random password to obtain encrypted stored data; A password encryption module, used to obtain the public key of the authorized object in a pre-public key database, and encrypt the random password using the public key to obtain an encrypted password; The data evidence module is used to upload the encrypted password and the encrypted evidence data to the blockchain through a smart contract based on the IERC821 standard, prompting the authorized object to obtain the encrypted password and the encrypted evidence data in the blockchain, and decrypt the encrypted password through the private key corresponding to the public key to obtain a random password, and decrypt the encrypted data to be stored through the random password to obtain the evidence data.

7. The blockchain evidence storage system according to claim 6, characterized in that: When the random password is used to encrypt the data to be stored, the random password is used to symmetrically encrypt the data to be stored.

8. The blockchain evidence storage system according to claim 6, characterized in that: When the random password is encrypted by using the public key, the random password is asymmetrically encrypted by using the public key.

9. The blockchain evidence storage system according to claim 6, characterized in that: The public key database is stored on the server of each blockchain node or in the user registration smart contract of the blockchain.

10. The blockchain evidence storage system according to claim 1, characterized in that: The smart contract based on the IERC821 standard includes an SSNFT extended smart contract, an SSNFT basic smart contract and an IERC821 smart contract interface standard; the SSNFT extended smart contract inherits from the SSNFT basic smart contract, and the SSNFT basic smart contract inherits and implements the IERC821 smart contract interface standard.

Images