Cross-DiChain Credit Data Encrypted Storage and Credit Score Privacy Calculation Solution

Abstract

The present invention belongs to the technical field of credit data encryption, and discloses a cross-Di chain credit data encryption storage and credit score privacy calculation scheme, including the following steps: S1: a user through the identity authentication process generates a 256-bit random number as a private key K; S2: the private key K is split into 24 groups of 11 bits, each group corresponds to one of the 2048 Chinese characters, forming a mnemonic phrase of 24 Chinese characters in total; S3: the public key PK is calculated by the private key K; S4: the identity ID and the public key PK are uploaded to the blockchain; S5: the privacy data is encrypted and uploaded to the blockchain. The present invention uses blockchain technology as the underlying infrastructure to design a credit data chain storage scheme, which perfectly solves the protection of the privacy and non-tamperability of credit data. In order to prevent the leakage of credit data and ensure that the privacy data is available but not visible, a credit score card privacy calculation scheme is designed and invented, which combines the credit sensitive data on the blockchain with privacy calculation, and solves the problem that sensitive data is available but not out of the warehouse.

Description

Technical Field

[0001] The present invention belongs to the technical field of credit data encryption, and specifically is a cross-Di chain credit data encryption storage and credit score privacy calculation solution. Background Art

[0002] At present, the data involved in blockchain transactions are open to all chain participants; credit data is personal privacy, owned by relevant individuals or authoritative institutions, and cannot be viewed or modified by other unrelated individuals or institutions; the credit data owner can view his or her credit data at any time and can also authorize others to view it. At the same time, credit data is tamper-proof evidence data, and technical means are needed to ensure that credit data cannot be tampered with.

[0003] Calculating personal credit score cards requires credit information data, which is at risk of being leaked. At the same time, different business companies use different algorithms to calculate credit score cards based on their business needs, and these algorithms are trade secrets. Technical means are needed to protect the leakage of scoring algorithms and credit information data. Summary of the invention

[0004] The purpose of the present invention is to provide a cross-Di chain credit data encryption storage and credit score privacy calculation solution to solve the problems raised in the above background technology.

[0005] In order to achieve the above objectives, the present invention provides the following technical solutions: a cross-Di chain credit data encryption storage and credit score privacy calculation solution, comprising the following steps:

[0006] S1: The user who passes the identity authentication process generates a 256-bit random number as the private key K;

[0007] S2: Split the private key K into 24 groups of 11 bits, each group corresponds to one of the 2048 Chinese characters, forming a mnemonic phrase with a total of 24 Chinese characters;

[0008] S3: Calculate the public key PK through the private key K;

[0009] S4: Upload the identity ID and public key PK to the blockchain;

[0010] S5: Private data is encrypted and uploaded to the blockchain;

[0011] S6: The user uses the private key K to decrypt the private data on the blockchain.

[0012] Preferably, the identity verification process includes the following steps:

[0013] S01: After the user sends a verification request to the identity verification party, the identity verification party generates a random number R, encrypts it with a public key to obtain a ciphertext eR, and sends the ciphertext eR to the user;

[0014] S02: The user decrypts eR with the private key Key to obtain the random number R1, encrypts R1 with the private key to obtain eR1, and sends eR1 to the identity verification party;

[0015] S03: Decrypt eR1 with the public key to obtain R1, compare R and R1, if they are the same, the verification is successful, if they are not the same, the verification fails, and the verification result is sent to the user.

[0016] Preferably, the public key PK=G*K;

[0017] *It is the national secret SM2 elliptic curve algorithm;

[0018] G is the public G point defined by SM2, and its coordinates are G(x, y).

[0019] Preferably, the mnemonic corresponds to the user's private key K, and the mnemonic and the private key K can be derived from each other.

[0020] Preferably, the private key K in S2 is divided into 24 groups, each group of 11 bits constitutes a total of 264 bits, and the remaining 8 bits are used for verification.

[0021] Preferably, the method comprises the following steps:

[0022] S1: Proof of executable environment;

[0023] S2: Deployment of privacy contracts;

[0024] S3: Calling of privacy contract.

[0025] Preferably, the certification of the executable environment comprises the following steps:

[0026] S01: The user generates a random challenge and sends it to the privacy contract environment, which is forwarded to the Enclave by the privacy computing gateway;

[0027] S02: Enclave makes a remote proof of the random challenge received;

[0028] S03: Enclave outputs remote proof through the privacy computing gateway;

[0029] S04: The privacy computing gateway will call the system contract to write the remote proof into the blockchain for storage. The system contract contains the logic to verify the legitimacy of the remote proof. The verified remote proof will be written into the blockchain for storage.

[0030] Preferably, the remote attestation includes a random challenge, a report, an Enclave signature, and an Enclave certificate.

[0031] Preferably, the deployment of the privacy contract includes the following steps:

[0032] S01: The user initiates a request to deploy a contract and sends the contract to the privacy computing gateway in the privacy contract environment;

[0033] S02: After receiving the user's deployment request, the privacy computing gateway sends the contract to the Enclave's EVM for initialization;

[0034] S03: After the Enclave initialization contract is completed, the privacy computing gateway is notified;

[0035] S04: If the Enclave successfully initializes the contract, the privacy computing gateway will store the contract in the blockchain through the on-chain system contract. The on-chain contract can be used as a reference for the reliability verification of the contract logic and for public supervision of the contract.

[0036] S05: The privacy computing gateway notifies the user of the event status of the deployed contract.

[0037] Preferably, the calling of the privacy contract includes the following steps:

[0038] S01: The user initiates a request to call a privacy contract to the privacy contract environment;

[0039] S02: The privacy computing gateway constructs a blockchain request based on the user's request to call the contract. This blockchain request is used to read the corresponding privacy contract and on-chain data from the chain. The privacy computing gateway sends this request to the blockchain;

[0040] S03: After the privacy computing gateway obtains the privacy contract code and the required on-chain data from the blockchain, it forwards it to the Enclave together with the off-chain data from the user;

[0041] S04: Use the on-chain and off-chain data as parameters to execute the privacy contract. If the data is ciphertext, use the encrypted private key to decrypt the data.

[0042] S05: Choose whether to encrypt and package the execution results as needed, including: privacy contract execution results, privacy contracts, on-chain and off-chain parameters;

[0043] S06: Use the signature private key to sign the packaged execution result, and Enclave returns the execution result and signature to the privacy computing gateway;

[0044] S07: The privacy computing gateway calls the system contract to transmit the execution result and signature to the chain. The system contract will obtain the Enclave remote proof from the chain, extract the signature public key from it, and verify the signature of the execution result. It will also extract the privacy contract and on-chain data from the execution result and compare them with the information on the blockchain. If all these verifications are passed, the system contract is executed successfully, and the execution result of the privacy contract will be packaged into the block and wait for consensus to be generated.

[0045] The beneficial effects of the present invention are as follows:

[0046] 1. The present invention uses blockchain technology as the underlying infrastructure to design a credit data chain storage solution, which perfectly solves the problem of protecting the privacy and immutability of credit data. In order to prevent the leakage of credit data and ensure that private data is available but not visible, a credit score card privacy computing solution is designed and invented, which combines credit sensitive data on the blockchain with privacy computing, solving the problem of sensitive data being available but not out of the warehouse.

[0047] 2. The present invention provides blockchain with the ability to process sensitive data in contracts through the cross-Di chain privacy contract function, thereby protecting data privacy while ensuring the reliability of the contract execution process (including contract logic and data integrity). The cross-Di chain privacy contract adopts trusted computing technology to execute privacy contracts in a trusted execution environment. Sensitive data exists in the blockchain ledger in ciphertext form and is decrypted in the trusted execution environment when used by users. The plaintext of sensitive data cannot be obtained outside the trusted execution environment. At the same time, the remote proof of the trusted execution environment ensures that the contract logic is not tampered with. In this way, sensitive data can be available but invisible on the blockchain, while the data processing process can still be publicly verified on the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 It is a schematic diagram of the identity authentication process of the present invention;

[0049] Figure 2 It is a schematic diagram of the process flow of the encryption storage solution of the present invention;

[0050] Figure 3 A schematic diagram of the process of remote certification of the executable environment of the present invention;

[0051] Figure 4 A schematic diagram of the process of deploying the privacy contract of the present invention;

[0052] Figure 5 This is a flow chart of the privacy contract call of the present invention. DETAILED DESCRIPTION

[0053] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0054] like Figures 1 to 5 As shown, in the embodiment of the present invention, the cross-Di chain credit data encryption storage and credit score privacy calculation solution includes the following steps:

[0055] S1: The user who passes the identity authentication process generates a 256-bit random number as the private key K;

[0056] S2: Split the private key K into 24 groups of 11 bits, each group corresponds to one of the 2048 Chinese characters, forming a mnemonic phrase with a total of 24 Chinese characters;

[0057] S3: Calculate the public key PK through the private key K;

[0058] S4: Upload the identity ID and public key PK to the blockchain;

[0059] S5: Private data is encrypted and uploaded to the blockchain;

[0060] S6: The user uses the private key K to decrypt the private data on the blockchain;

[0061] KuaDiChain first confirms the authenticity of personal identity through real-name authentication of ID card. After confirming the real identity, it randomly generates a pair of public and private keys. The private key is kept secretly by the individual user, and the public key and identity ID are bound and stored on the blockchain. The user's public key can be queried through the identity ID.

[0062] The private key K consists of 256 bits, which is difficult to remember and keep. K is decomposed into 24 groups, each with 11 bits, 11*24=264 bits, and the extra 8 bits are used as check bits, 2^11=2048. Each group has 2048 digits. We use 2048 Chinese characters to correspond to them one by one, so we get a mnemonic consisting of a sequence of 24 Chinese characters. The mnemonic corresponds to the personal private key, and the two can be derived from each other.

[0063] The personal private key is used as a personal digital identity on the cross-chain, and is also the key to encrypt and decrypt personal privacy data on the chain. When encrypting private data, a session key is derived from the personal private key and a random number, and the data is encrypted with the session key. At the same time, the ciphertext and the random number are stored in the blockchain. The following is an integration of the encryption algorithm:

[0064] (1) Obtain the data encryption key sharedSecret. The algorithm is as follows:

[0065] sharedSecret=SM3(PrivateKey*PubKey_of_CreditChain,Nonce)

[0066] PrivateKey is the user's personal private key

[0067] PubKey_of_CreditChain is the public key of the CreditChain

[0068] Multiplication is defined as elliptic curve multiplication, and the SM2 elliptic curve algorithm used here is the national secret

[0069] Nonce is a random number

[0070] SM3 is the national secret HASH algorithm

[0071] KuaDiChain uses the SM2 elliptic curve algorithm as an asymmetric algorithm. According to the SM2 algorithm, the user's PrivateKey is a 256-bit random number R, and the public key is the coordinates P(x, y) of a point on the elliptic curve. SM2 defines a public point G with coordinates G(x, y). The public key P can be obtained through the following algorithm:

[0072] P=G*R

[0073] The multiplication rule here is the multiplication rule defined by the elliptic curve algorithm.

[0074] Therefore, the public key P can be derived from the private key (random number R). Since elliptic curve multiplication has no inverse operation, the random number R cannot be derived from the public key P and G.

[0075] The algorithm for encrypting the key sharedSecret is as follows:

[0076] S=PrivateKey*PubKey_of_CreditChain;

[0077] And PubKey_of_CreditChain = G*R1 (R1 is the official private key of CreditChain);

[0078] PrivateKey = R;

[0079] So S=R*G*R1=G*R*R1

[0080] sharedSecret = SM3(S*Nonce)

[0081] The obtained sharedSecret is a 256-bit SM3 HASH value.

[0082] (2) Encrypting private data

[0083] cipherData=Base64_Encode(SM2(Data,sharedSecret));

[0084] sharedSecret is the data encryption key obtained in the first step;

[0085] SM2 is the national secret SM2 algorithm;

[0086] Base64_Encode is the base64 encoding algorithm;

[0087] cipherData is the encrypted ciphertext;

[0088] The process is as follows:

[0089] First, based on the SM2 algorithm, the private data data is encrypted with the data encryption key sharedSecret to obtain the ciphertext binary data. Then the ciphertext binary data is base64 encoded and converted into a string form cipherData for easy blockchain storage.

[0090] (3) Encrypted data on-chain

[0091] Upload the following fields to the blockchain: ID; PubKey; cipherData; Nonce.

[0092] ID is the user identity ID;

[0093] PubKey is the user's public key;

[0094] cipherData is the encrypted ciphertext;

[0095] Nonce is the random number used to generate sharedSecret in the first step;

[0096] Store the above data in the blockchain and return the stored block height.

[0097] (4) Data decryption

[0098] The ciphertext data cipherData and random number Nonce are taken from the blockchain, and decryption is divided into the following two cases:

[0099] Individuals have private keys, which can be used to decrypt and view their credit data;

[0100] The official private key of the cross-Di chain is decrypted. In extremely rare cases when it is necessary, the official private key is used to decrypt the original data; individuals can decrypt the corresponding data when they have the private key PrivateKey.

[0101] First calculate sharedSecret sharedSecret = SM3 (PrivateKey * PubKey_of_CreditChain, Nonce)

[0102] Decryption using the national secret algorithm SM2:

[0103] Data=SM2(Base64_Decode(cipherData),sharedSecret);

[0104] Base64_Decode is the base64 decoding algorithm;

[0105] SM2 is the national secret symmetric encryption algorithm;

[0106] The decryption process is as follows:

[0107] 1. First, decode the ciphertext string cipherData into a binary data stream cipherStrearm based on base64; 2. Use the password sharedSecret to decrypt cipherStream based on the SM2 algorithm to obtain the original data. The private key owned by the official KuaDiChain can decrypt the data:

[0108] First calculate the sharedSecret;

[0109] sharedSecret=SM3(PrivateKey_of_CreditChain*PubKey,Nonce)

[0110] The private key of the official Kuaidi Chain, PrivateKey_of_CreditChain, is used here. The private key is owned by the official. PubKey is the public key of the data owner.

[0111] Nonce is a random number stored on the blockchain together with the ciphertext;

[0112] The algorithm for encrypting the key sharedSecret is as follows:

[0113] S=PrivateKey_of_CreditChain*PubKey;

[0114] And PubKey = G*R (R is the user's private key);

[0115] PrivateKey_of_CreditChain=R1;

[0116] So S = R1*G*R = G*R*R1;

[0117] sharedSecret=SM3(S*Nonce);

[0118] The obtained sharedSecret is a 256-bit HASH value;

[0119] Any other third party cannot decrypt the data

[0120] Other third parties cannot calculate the sharedSecret key because they do not have the user's private key PrivateKey or the official private key PrivateKey_of_Creditchain of the Creditchain, and therefore cannot decrypt cipherData. Personal privacy data is effectively protected.

[0121] The identity verification process includes the following steps:

[0122] S01: After the user sends a verification request to the identity verification party, the identity verification party generates a random number R, encrypts it with a public key to obtain a ciphertext eR, and sends the ciphertext eR to the user;

[0123] S02: The user decrypts eR with the private key Key to obtain the random number R1, encrypts R1 with the private key to obtain eR1, and sends eR1 to the identity verification party;

[0124] S03: Decrypt eR1 with the public key to obtain R1, compare R and R1, if they are the same, the verification is successful, if they are not the same, the verification fails, and the verification result is sent to the user;

[0125] Credit data is personal privacy data. Privacy data must have an owner. First of all, the problem of personal identity on the chain must be solved. KuaDi Chain uses a public-private key mechanism and a digital signature algorithm to authenticate personal identity. The public-private key mechanism is an asymmetric encryption technology. KuaDi Chain uses the national secret SM2 asymmetric encryption technology and the SM2-SM3 signature algorithm suite. In the SM2 technical solution, the private key is a randomly generated 256-bit large number. In computer cryptography, a 256-bit large number is large enough. At present, it is technically impossible to obtain other people's private keys through collisions or inverse operations. The SM2-SM3 signature algorithm is based on the SM2 asymmetric encryption technology, which consists of a public key. Data encrypted by a private key can only be decrypted by a private key, and data encrypted by a private key can only be decrypted by a public key. Therefore, the identity authentication party only needs to use a certain person's public key PubKey to encrypt a random number R to obtain the encrypted data eR. The verified party uses its private key to decrypt the ciphertext eR to obtain R1, and then uses its private key PrivateKey to encrypt data R1 to obtain ciphertext eR1. The verifier uses PubKey to decrypt eR1 to obtain R1. By comparing R1 with the original data R, it is possible to verify whether the encryptor has the private key, thereby determining the authenticity of the personal identity.

[0126] The private key K in S2 is divided into 24 groups, each group of 11 bits constitutes a total of 264 bits, and the remaining 8 bits are used for verification.

[0127] The privacy contract function is provided by a privacy contract environment based on a trusted execution environment. This privacy contract environment consists of a trusted execution environment Enclave and a privacy computing gateway. Enclave is the logic running in the trusted execution environment, responsible for verifying, compiling, and executing the contract. Sensitive data ciphertext can only be decrypted in the Enclave. A set of EVM logic is implemented in the Enclave, which can compile and run any data processing logic. The privacy computing gateway is responsible for packaging the information sent by the user and the Enclave into the transaction payload of the blockchain and forwarding it to the blockchain for evidence storage.

[0128] The Trusted Execution Environment is a security-hardened area of ​​the CPU that ensures that the software logic and data therein are protected in terms of confidentiality and integrity. The software and hardware environment of this area can be regarded as an anti-sandbox environment isolated from the outside world. For programs running in this environment, external entities, including the operating system, cannot read or write their memory, nor can they interfere with their code running logic.

[0129] S1: Proof of executable environment;

[0130] S2: Deployment of privacy contracts;

[0131] S3: Calling of privacy contract.

[0132] The remote attestation action can be a one-time one. In this stage, the user initiates the remote attestation of the Enclave in the privacy contract environment to verify whether the Enclave is running in a trusted execution environment and whether the logic in the Enclave has been tampered with after deployment.

[0133] The deployment of the privacy contract occurs after remote attestation, and each different privacy contract needs to be deployed separately. During this stage, any data processing logic accepted by the blockchain consensus can be deployed as a privacy contract. The privacy contract will be stored on the blockchain and its logic will be subject to public supervision. Unlike ordinary contract deployment methods where users directly upload contract codes to blockchain nodes, privacy contracts require users to upload contracts to the privacy computing environment for initialization, and then the privacy computing environment uploads the processed contracts to the blockchain ledger through the gateway.

[0134] The call of the privacy contract occurs after deployment. After a privacy contract is deployed, users can call it multiple times with the same or different data as input parameters.

[0135] Remote attestation allows the verifier to identify whether the software logic on the trusted execution environment being verified has been changed. Usually, the verified party of remote attestation generates a certificate through trusted hardware. This certificate contains a report information that describes the software (code measurement) currently running in the trusted execution environment. The verifier verifies the legitimacy of this certificate to verify whether the software process on the trusted hardware has been modified.

[0136] In the Intel DCAP (Datacenter Attestation Primitives) remote attestation mode based on Intel SGX trusted hardware, Intel will provide authentication for SGX hardware as the root CA.

[0137] The remote attestation of the custom trust root across DiChain makes some changes to Intel SGX DCAP, transferring the trust in Intel to the trust in any selected CA organization.

[0138] During the initialization phase of the trusted execution environment, the trusted hardware generates a pair of signature public-private key pairs and a pair of encryption public-private key pairs based on the hardware inherent key, and applies for a certificate from a selected CA organization. The certificate contains the signature public key and the encryption public key. This process is similar to registering information with Intel when the hardware leaves the factory.

[0139] The certification of the executable environment comprises the following steps:

[0140] S01: The user generates a random challenge (any random string), sends it to the privacy contract environment, and is forwarded to the Enclave by the privacy computing gateway;

[0141] S02: Enclave makes a remote proof of the random challenge received;

[0142] S03: Enclave outputs remote proof through the privacy computing gateway;

[0143] S04: The privacy computing gateway will call the system contract to write the remote proof into the blockchain for storage. The system contract contains the logic to verify the legitimacy of the remote proof. The verified remote proof will be written into the blockchain for storage.

[0144] The remote attestation includes random challenge, report, Enclave signature and Enclave certificate.

[0145] The deployment of the privacy contract includes the following steps:

[0146] S01: The user initiates a request to deploy a contract and sends the contract to the privacy computing gateway in the privacy contract environment;

[0147] S02: After receiving the user's deployment request, the privacy computing gateway sends the contract to the Enclave's EVM for initialization;

[0148] S03: After the Enclave initialization contract is completed, the privacy computing gateway is notified;

[0149] S04: If the Enclave successfully initializes the contract, the privacy computing gateway will store the contract in the blockchain through the on-chain system contract. The on-chain contract can be used as a reference for the reliability verification of the contract logic and for public supervision of the contract.

[0150] S05: The privacy computing gateway notifies the user of the event status of the deployed contract.

[0151] The calling of the privacy contract includes the following steps:

[0152] S01: The user initiates a request to call a privacy contract to the privacy contract environment;

[0153] S02: The privacy computing gateway constructs a blockchain request based on the user's request to call the contract. This blockchain request is used to read the corresponding privacy contract and on-chain data from the chain. The privacy computing gateway sends this request to the blockchain;

[0154] S03: After the privacy computing gateway obtains the privacy contract code and the required on-chain data from the blockchain, it forwards it to the Enclave together with the off-chain data from the user;

[0155] S04: Use the on-chain and off-chain data as parameters to execute the privacy contract. If the data is ciphertext, use the encrypted private key to decrypt the data.

[0156] S05: Choose whether to encrypt and package the execution results as needed, including: privacy contract execution results, privacy contracts, on-chain and off-chain parameters;

[0157] S06: Use the signature private key to sign the packaged execution result, and Enclave returns the execution result and signature to the privacy computing gateway;

[0158] S07: The privacy computing gateway calls the system contract to transmit the execution result and signature to the chain. The system contract will obtain the Enclave remote proof from the chain, extract the signature public key from it, and verify the signature of the execution result. It will also extract the privacy contract and on-chain data from the execution result and compare them with the information on the blockchain. If all these verifications are passed, the system contract is executed successfully, and the execution result of the privacy contract will be packaged into the block and wait for consensus to be generated.

[0159] In steps 1 and 4 of the contract call phase, it was mentioned that the data used by the privacy contract may be encrypted.

[0160] Off-chain encrypted data

[0161] The user can randomly generate a symmetric key as the session key to encrypt the data, and then obtain the Enclave's encryption public key from the blockchain to encrypt the session key. The off-chain data passed in when the user calls the privacy contract is the symmetric encryption ciphertext of the data itself and the asymmetric encryption ciphertext of the session key. When the Enclave is used, the encrypted private key is used to decrypt the session key, and then the session key is used to decrypt the data.

[0162] Encrypted data on blockchain

[0163] There may be a small amount of ciphertext of sensitive data on the blockchain. These ciphertexts are first put on the chain in the same way as off-chain encrypted data. The Enclave uses the on-chain ciphertext in the same way as it uses off-chain ciphertext.

[0164] In step 5 of the contract call phase, it is mentioned that the execution result of the privacy contract can be encrypted as needed. There are two options:

[0165] Encryption using the Enclave's encrypted public key

[0166] Enclave randomly generates a symmetric key as the session key to encrypt the result, and then uses the encryption public key of Enclave to encrypt the session key; the ciphertext of the execution result contains two parts: the session key ciphertext and the data ciphertext. In this case, the execution result of the privacy contract can only be used in the Enclave in subsequent privacy contract calls, and the result cannot be decrypted externally.

[0167] Encrypt using a public key passed in the contract parameters

[0168] The public key in the input parameter can be data from the blockchain, or it can be the user's public key outside the chain brought in when the user sends a request to call the privacy contract. Enclave randomly generates a symmetric key as the session key to encrypt the result, and then encrypts the session key with the encrypted public key in the input parameter; the ciphertext of the execution result contains two parts: the session key ciphertext and the data ciphertext. In this case, the execution result of the privacy contract can be decrypted and used by the corresponding encrypted private key holder.

[0169] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0170] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. The encrypted storage method of credit investigation data across DiChain is characterized by: The following steps are involved: S1: The user who passes the identity authentication process generates a 256-bit random number as the private key K; S2: Split the private key K into 24 groups of 11 bits, each group corresponds to one of the 2048 Chinese characters, forming a mnemonic phrase with a total of 24 Chinese characters; S3: Calculate the public key PK through the private key K; S4: Upload the identity ID and public key PK to the blockchain; S5: Encrypted credit data across DiChain is uploaded to the blockchain; S6: The user uses the private key K to decrypt the cross-chain credit data on the blockchain; The following steps are involved: S01: Proof of executable environment; S02: Deployment of privacy contracts; S03: Calling of privacy contract; The certification of the executable environment comprises the following steps: S001: The user generates a random challenge and sends it to the privacy contract environment, which is forwarded to the encrypted memory enclave by the privacy computing gateway; S002: The encrypted memory enclave makes a remote proof of the random challenge received; S003: Encrypted memory enclave outputs remote proof through privacy computing gateway; S004: The privacy computing gateway calls the system contract to write the remote proof into the blockchain for storage. The system contract contains the logic to verify the legitimacy of the remote proof. The verified remote proof is written into the blockchain for storage. The deployment of the privacy contract includes the following steps: S0001: The user initiates a request to deploy a contract and sends the contract to the privacy computing gateway in the privacy contract environment; S0002: After receiving the user's deployment request, the privacy computing gateway sends the contract to the virtual machine EVM of the encrypted memory Enclave for initialization; S0003: After the encrypted memory Enclave initialization contract is completed, the privacy computing gateway is notified; S0004: If the encrypted memory Enclave successfully initializes the contract, the privacy computing gateway will store the contract in the blockchain through the on-chain system contract. The on-chain contract is used as a reference for the reliability verification of the contract logic and for public supervision of the contract. S0005: The privacy computing gateway notifies the user of the event status of the deployed contract; The calling of the privacy contract includes the following steps: S00001: The user initiates a request to call a privacy contract to the privacy contract environment; S00002: The privacy computing gateway constructs a blockchain request based on the user's request to call the contract. This blockchain request is used to read the corresponding privacy contract and on-chain data from the chain. The privacy computing gateway sends this request to the blockchain; S00003: After the privacy computing gateway obtains the privacy contract code and the required on-chain data from the blockchain, it forwards it to the encrypted memory Enclave together with the off-chain data from the user; S00004: Use on-chain and off-chain data as parameters to execute the privacy contract. If the data is ciphertext, use the encrypted private key to decrypt the data. S00005: Choose whether to encrypt and package the execution results as needed, including: privacy contract execution results, privacy contracts, on-chain and off-chain parameters; S00006: Use the signature private key to sign the packaged execution result, and the encrypted memory Enclave returns the execution result and signature to the privacy computing gateway; S00007: The privacy computing gateway calls the system contract to transmit the execution result and signature to the chain. The system contract obtains the encrypted memory Enclave remote proof from the chain, extracts the signature public key from it, verifies the signature of the execution result, and extracts the privacy contract and on-chain data from the execution result, and compares them with the information on the blockchain. If these verifications are passed, the system contract is executed successfully, and the execution result of the privacy contract is packaged into the block and waits for consensus to be generated.

2. The encrypted storage method for credit investigation data across DiChain according to claim 1 is characterized in that: The identity verification process includes the following steps: After the user sends a verification request to the identity verification party, the identity verification party generates a random number R, encrypts it with the public key to obtain the ciphertext eR, and sends the ciphertext eR to the user; The user decrypts eR with the private key to obtain the random number R1, encrypts R1 with the private key to obtain eR1 and sends eR1 to the identity verification party; The authentication party decrypts eR1 with the public key to obtain R1, compares R and R1, and if they are the same, the authentication passes; if they are not the same, the authentication fails, and the authentication result is sent to the user.

3. The encrypted storage method for credit investigation data across DiChain according to claim 1 is characterized in that: The public key PK=G*K; *It is the national secret SM2 elliptic curve algorithm; G is the public G point defined by SM2, and its coordinates are G(x, y).

4. The encrypted storage method for credit investigation data across DiChain according to claim 1 is characterized in that: The mnemonic corresponds to the user's private key K, and the mnemonic and the private key K can be derived from each other.

5. The encrypted storage method for credit investigation data across DiChain according to claim 1 is characterized in that: The private key K in S2 is divided into 24 groups, each group of 11 bits constitutes a total of 264 bits, and the remaining 8 bits of the 256-bit private key K are used for verification.

Images