Distributed key protection method and system for multi-trusted hardware collaboration environment
Through distributed key management and dynamic private key sharding technology, the complexity and security issues of key management in a multi-trusted hardware collaboration environment are solved, homogeneous services and key security of multiple trusted hardware are achieved, and the network's ability to resist single-point leakage is enhanced.
Patent Information
- Application Number
- CN202411218982.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-02
- Publication Date
- 2025-09-23
- Estimated Expiration
- 2044-09-02
AI Technical Summary
In a multi-trusted hardware collaboration environment, existing technologies cannot effectively solve the problem of resource limitations of a single trusted hardware, resulting in complex key management, low security, and an inability to provide consistent and homogeneous service experience, making it susceptible to single point leaks.
A distributed key management method is adopted to share and synchronize keys in a trusted hardware network, generate dynamic private key shards, and collaborate on encryption and decryption between multiple trusted hardware to ensure that all hardware uses the same key, prevent conspiracy attacks, and support dynamic hardware rotation and fault recovery.
It achieves homogeneous services for multiple trusted hardware, enhances the network's resistance to single-point leaks, ensures key security and service continuity, provides a consistent encryption and decryption experience, and prevents collusion attacks from affecting overall security.
Smart Images

Figure CN119210704B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of distributed trusted computing technology, and in particular to a distributed key protection method and system for a multi-trusted hardware collaboration environment. Background Art
[0002] This section is intended to provide a background or context to the embodiments of the invention that are recited in the claims. No statement herein is admitted to be prior art by virtue of its inclusion in this section.
[0003] In a distributed trusted computing environment, resource limitations of a single trusted hardware unit and key management challenges faced by multiple hardware units collaborating together often prevent a single trusted hardware unit from meeting efficiency and performance requirements when processing highly concurrent and large data volumes. To address this shortcoming, current privacy-focused computing approaches employ a collaborative strategy involving multiple trusted hardware units to improve overall computing capabilities. However, this approach introduces new challenges, particularly in key management. In a collaborative environment involving multiple trusted hardware units, if each unit independently uses its own key, it is impossible to provide a unified and consistent service experience for end-user clients. Clients must use different keys to interact with different hardware units, increasing operational complexity and introducing additional security risks. Furthermore, sharing the same key across multiple hardware units to simplify management complicates key negotiation and increases the system's attack surface. A key leak on any one hardware unit in this scenario could potentially trigger a system-wide security breach, rendering the privacy protection features of all related services ineffective.
[0004] Therefore, there is an urgent need to develop an improved key management solution to solve the current problem of resource limitations of single trusted hardware when processing large-scale data or high-concurrency computing tasks, and to provide consistent and homogeneous services in a multi-trusted hardware collaborative environment, while ensuring key security, resisting the widespread impact of single-point leakage, and supporting the dynamics and flexibility of the system. Summary of the Invention
[0005] The embodiments of the present invention provide a distributed key protection method for a multi-trusted hardware collaborative environment. This method can address the resource limitations of a single trusted hardware unit when processing large-scale data or high-concurrency computing tasks. It can achieve homogeneous services for a group of trusted hardware units, enhance the trusted hardware network's resistance to single-point leaks, provide resistance to collusion attacks, and ensure key security and service continuity. The method includes:
[0006] When a trusted hardware in the trusted hardware network receives a trusted service application from a user client, it obtains multiple online trusted hardware randomly assigned by the upper-layer system and acts as assisting trusted hardware. The trusted hardware that receives the trusted service application is the access trusted hardware, and all assisting trusted hardware and access feasible hardware are the execution trusted hardware. The trusted service application includes a ciphertext, the user's public key, and service requirements. The ciphertext is encrypted by using the public key of the trusted hardware network to encrypt user data.
[0007] Each trusted hardware execution generates a dynamic private key shard based on the function and value of each trusted hardware execution;
[0008] The access trusted hardware sends the first part of the ciphertext to all assisting trusted hardware;
[0009] Each trusted hardware executes sharding based on the dynamic private key and calculates the decrypted intermediate value;
[0010] Each assisting trusted hardware sends the decrypted intermediate value to the access trusted hardware;
[0011] The access trusted hardware calculates the plaintext corresponding to the ciphertext based on the second part of the ciphertext and all received decryption intermediate values;
[0012] Access trusted hardware to execute operations according to business requirements and obtain business execution results;
[0013] The trusted hardware is connected to encrypt the business execution result using the user's public key, and the encrypted result is sent to the user client, so that the user client can decrypt the encrypted result using the user's private key.
[0014] The embodiments of the present invention provide a distributed key protection system for a multi-trusted hardware collaborative environment. This system can solve the current problem of resource limitations of a single trusted hardware when processing large-scale data or high-concurrency computing tasks. It can achieve homogeneous services for a group of trusted hardware, enhance the trusted hardware network's resistance to single-point leaks, and support dynamic hardware rotation. Even if some hardware goes offline or colludes, it ensures key security and service continuity. The system includes: a user client, a trusted hardware network, and an upper-layer system. The trusted hardware network includes multiple trusted hardware.
[0015] The user client is used to: encrypt user data using the public key of the trusted hardware network to generate ciphertext, and send a trusted service application to a trusted hardware of the trusted hardware network, wherein the trusted service application includes the ciphertext, the user's public key and the service requirement;
[0016] The upper-layer system is used to randomly assign multiple online trusted hardware as assisting trusted hardware based on trusted service applications. The trusted hardware that receives the trusted service application is the access trusted hardware, and all assisting trusted hardware and access feasible hardware are the execution trusted hardware.
[0017] The trusted hardware is used to: generate dynamic private key shards based on the functions and values executed by the trusted hardware;
[0018] The access trusted hardware is used to: send the first part of the ciphertext to all assisting trusted hardware;
[0019] Execute trusted hardware to: calculate decryption intermediate values based on dynamic private key sharding;
[0020] Assisting the trusted hardware to: send the decrypted intermediate value to the access trusted hardware;
[0021] The access trusted hardware is used to: calculate the plaintext corresponding to the ciphertext based on the second part of the ciphertext and all received decryption intermediate values;
[0022] Access to trusted hardware is used to: execute operations according to business requirements and obtain business execution results;
[0023] The trusted hardware is used to encrypt the service execution result using the user's public key, and send the encrypted result to the user client, so that the user client can decrypt the encrypted result using the user's private key.
[0024] In an embodiment of the present invention, by sharing and synchronizing keys between trusted hardware, it can be ensured that all computing trusted hardware can use the same key in the encryption and decryption process, regardless of which trusted hardware the user is connected to. Therefore, multiple trusted hardware can work synchronously to provide consistent and homogeneous encryption and decryption services to the user client. The embodiment of the present invention adopts distributed key management, which will not affect the overall security of the trusted hardware network even in the event of a leak in any one trusted hardware. The embodiment of the present invention takes into account the need to prevent collusion attacks by implementing multi-party secure computing and key sharding, ensuring that even if some of the trusted hardware that has been rotated offline colludes, it cannot obtain or restore the keys in the current service. The solution of the embodiment of the present invention is applicable to heterogeneous trusted hardware and supports different types of trusted hardware to form a trusted hardware network. Through the above process, the problem of resource limitations of a single trusted hardware when processing large-scale data or high-concurrency computing tasks is solved. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:
[0026] Figure 1Flowchart of a distributed key protection method for a multi-trusted hardware collaboration environment in an embodiment of the present invention;
[0027] Figure 2 A schematic diagram of a business process in a single trusted hardware execution environment in the prior art;
[0028] Figure 3 A schematic diagram of a business process in a multi-trusted hardware collaboration environment according to an embodiment of the present invention;
[0029] Figure 4 This is an overall flow chart of distributed key protection for a multi-trusted hardware collaboration environment in an embodiment of the present invention;
[0030] Figure 5 Schematic diagram of a distributed key protection system for a multi-trusted hardware collaboration environment in an embodiment of the present invention. DETAILED DESCRIPTION
[0031] To make the purpose, technical solutions and advantages of the embodiments of the present invention more clear, the embodiments of the present invention are further described in detail below with reference to the accompanying drawings. Here, the exemplary embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.
[0032] Figure 1 Flowchart of a distributed key protection method for a multi-trusted hardware collaboration environment in an embodiment of the present invention, the method comprising:
[0033] Step 101: When a trusted hardware in a trusted hardware network receives a trusted service application from a user client, it obtains multiple online trusted hardware randomly assigned by an upper-layer system and uses them as assisting trusted hardware. The trusted hardware that receives the trusted service application is the access trusted hardware, and all assisting trusted hardware and access feasible hardware are the execution trusted hardware. The trusted service application includes a ciphertext, a user's public key, and service requirements. The ciphertext is obtained by encrypting user data using the public key of the trusted hardware network.
[0034] Step 102 , each trusted hardware generates a dynamic private key shard based on the function and value of each trusted hardware;
[0035] Step 103: The access trusted hardware sends the first part of the ciphertext to all assisting trusted hardware;
[0036] Step 104: Each trusted hardware executes the sharding operation based on the dynamic private key and calculates the decryption intermediate value.
[0037] Step 105 , each assisting trusted hardware sends the decrypted intermediate value to the accessing trusted hardware;
[0038] Step 106: The access trusted hardware calculates the plaintext corresponding to the ciphertext based on the second part of the ciphertext and all received decryption intermediate values;
[0039] Step 107: Access the trusted hardware to execute the operation according to the business requirements and obtain the business execution results;
[0040] Step 108: Access the trusted hardware to encrypt the service execution result using the user's public key, obtain the encrypted result and send it to the user client, so that the user client decrypts the encrypted result using the user's private key.
[0041] In the solution proposed in the embodiment of the present invention, the participants are: 1. User client: The user client submits personal data to the trusted hardware network (TH, Trusted Hardware Network), and entrusts any trusted hardware to perform trusted services (such as calculation, authentication, etc.) on the personal data. 2. Trusted hardware: The user encrypts the personal data with the public key of the trusted hardware and sends it to the trusted hardware. The trusted hardware decrypts it with its private key, and then performs various operations on the user data according to the user's business requirements, and finally returns the operation results to the user. 3. The upper system of the trusted hardware network (referred to as the upper system): Multiple trusted hardware are interconnected to form a trusted hardware network. The upper system of the trusted hardware network is responsible for managing and coordinating the normal operation of the trusted hardware network, including allowing new trusted hardware to join, eliminating malicious trusted hardware, and other functions. It should be noted that the hardware here can be networked in a heterogeneous form, that is, there can be trusted hardware manufactured by different manufacturers in one network.
[0042] In a single trusted hardware execution environment, each time a user client accesses a different trusted hardware, it needs to obtain the public key of each trusted hardware first, such as Figure 2 The figure shows a business process diagram in a single trusted hardware execution environment in the prior art. There is a risk of single point failure, and the computing performance of a single trusted hardware in processing complex tasks is also limited. In the embodiment of the present invention, a set of unified keys (including private key s and public key P) are jointly generated and maintained by multiple trusted hardware. pub The user client can submit a trusted service application to any trusted hardware (set as trusted hardware TH) in the trusted hardware network and use a unified public key P pub Encrypt personal data, and then multiple trusted hardware THs decrypt it in a collaborative (distributed) manner based on a unified private key s and complete the corresponding business, such as Figure 3 The figure shows a business process diagram in a multi-trusted hardware collaboration environment according to an embodiment of the present invention. Figure 3 In the distributed method, multiple trusted hardware uses a unified private key to decrypt and then perform corresponding business operations on user data. Figure 4 FIG. 1 is an overall flow chart of distributed key protection for a multi-trusted hardware collaboration environment according to an embodiment of the present invention. Figure 4 The overall process mainly consists of four parts: distributed key generation, dynamic private key sharding generation, trusted hardware TH update, and distributed decryption. Among them, distributed key generation and trusted hardware TH update can be started in advance, and dynamic private key sharding generation and distributed decryption need to be performed when the user's trusted business application is received.
[0043] In one embodiment, the method further comprises:
[0044] All trusted hardware in the trusted hardware network generates a private key shard, which is a random positive integer;
[0045] Add up the private key shards of all trusted hardware to get the private key of the trusted hardware network;
[0046] Based on the cryptographic system selected in the current business environment, each trusted hardware calculates the intermediate value based on the private key shards and broadcasts the intermediate value to other trusted hardware;
[0047] Each trusted hardware calculates a public key based on the calculated intermediate value and all received intermediate values, and broadcasts it to the entire trusted hardware network.
[0048] In one embodiment, the method further comprises:
[0049] Each trusted hardware attaches a commitment when broadcasting the intermediate value to other trusted hardware;
[0050] After receiving the intermediate value and commitment broadcast by other trusted hardware, each trusted hardware verifies the received intermediate value. If the verification is successful, it accepts the intermediate value. Otherwise, it reports the error report of the other trusted hardware to the upper system.
[0051] Among them, if the upper-level system receives more than a preset number of error reports for a trusted hardware and determines that the trusted hardware is a malicious node, the malicious node will be removed from the trusted hardware network and the key of the trusted hardware network will be regenerated. If the upper-level system only receives one error report for a trusted hardware, a warning will be issued to the trusted hardware, and the trusted hardware will be required to resend the correct intermediate value to the trusted hardware that reported the error report.
[0052] In one embodiment, after generating the public key of the trusted hardware network, the method further includes:
[0053] Remote assertion of all trusted hardware;
[0054] After the assertion succeeds, the trusted hardware network allows the public key of the trusted hardware network.
[0055] The above process is the key generation process of the trusted hardware network, which is described in detail below.
[0056] Assume that the initial number of trusted hardware TH is n, and the private key s is generated by these n initial trusted hardware TH, and ensure that the private key s is kept confidential during the entire generation process; here the private key s is stored in the trusted hardware and cannot be obtained from the outside; Assume that a certain initial trusted hardware TH is TH j , j∈[1,n]. Each trusted hardware TH has a corresponding trusted hardware identification X value (positive integer), such as TH j The corresponding one is X j The X value can be assigned by the upper system or generated by the trusted hardware TH itself (the X value is public and unique. If the X value generated by the trusted hardware TH is repeated, it needs to be regenerated), and this set of X values is broadcast to all trusted hardware TH.
[0057] (1) Generate private key s: Each initial trusted hardware TH generates a private key shard (a random positive integer) internally. The sum of all the private key shards generated by the initial trusted hardware TH is the private key s (in fact, the addition operation will not be performed because the private key s is always kept secret). Let TH j The generated private key shard is u j , then we have:
[0058]
[0059] (2) Generate public key P pub : Public key P pub The cryptographic system selected according to the specific business environment is generated based on the private key s. Two examples are given here.
[0060] For example:
[0061] 1) If the ElGamal public key cryptosystem is used, then P pub =G s modq, where q is a large prime number, And it is a generator of a cyclic group of order q, where q and G are public values.
[0062] Then each TH j calculate And broadcast to other trusted hardware TH. Due to the characteristics of the cyclic group, knowing P j and G cannot be inferred from u j .
[0063] Each TH j calculate Get the public key P pub , and broadcast it to the entire trusted hardware network.
[0064] 2) If ECC (elliptic curve) public key cryptography is used, then P pub=s·Q, where Q is the generator of the cyclic group and is a public value.
[0065] Then each THj calculates P j =u j Q, and broadcast it to other trusted hardware TH. Due to the characteristics of the cyclic group, knowing P j and Q cannot be inferred from u j .
[0066] Each TH j calculate Get the public key P pub , and broadcast it to the entire trusted hardware network.
[0067] In the above example, the private key s and each private key shard u j All are confidential (each TH j Only know your own u j ), so currently, a complete private key s can only be formed to enable user services when all trusted hardware TH is online. If some trusted hardware TH is offline or damaged, a complete private key s cannot be formed. It is important to note that forming a complete private key s to enable user services does not involve actually calculating the private key s. Instead, it utilizes privacy-preserving computing techniques to allow the private key s to participate in various computations in an indirect manner (e.g., distributed) while maintaining confidentiality.
[0068] (3) To prevent a node from impersonating legitimate trusted hardware, the new trusted hardware must complete a remote attestation before continuing with the next operation. If the trusted hardware's identity is not verified, the subsequent operation will be stopped. This remote attestation guarantees the correctness of the identities of both communicating parties in the trusted hardware, that is, a value indeed comes from a piece of trusted hardware. However, it cannot guarantee that a piece of trusted hardware will maliciously send an incorrect value.
[0069] (4) Further, in order to prevent and check the trusted hardware TH from sending P j Inadvertent or malicious errors (for example, sending malicious private key fragments), each TH j Sending P to other nodes j At the same time, you also need to attach a commitment commit j , used to verify whether the value is real.
[0070] Taking the ElGamal public key cryptosystem as an example, each TH j Need to calculate And send it to other nodes. Let q be a large prime number, And it is a generator of a q-order cyclic group, H(.) represents the SHA256 hash function, and r is TH j Generate a random positive integer, then TH jCommit j for:
[0071] commit j ={A=H(G r ),B=(r+u j ·A)modq}
[0072] Other trusted hardware TH receives TH j P j and commit j When the verification is successful, the P j Otherwise, the error is reported to the upper system. If the upper system receives multiple error reports for a trusted hardware TH, it determines that the trusted hardware TH is a malicious node, removes the trusted hardware TH and reorganizes a round of distributed key generation process; if the upper system receives only one error report for a trusted hardware TH, it issues a warning to the trusted hardware TH and requires it to resend the correct P to the reporting node. j To verify the above example, the verification method is as follows:
[0073] Calculate whether the following equation holds:
[0074]
[0075] If not, verification fails. j Bound to u j , if TH j The promise given is not made through TH j At the same time, due to the characteristics of hash function and discrete logarithm modulus calculation, u cannot be deduced through commitment. j .
[0076] To make it easier to understand, a simple example is given below:
[0077] Because q is a large prime number, the result of the SHA256 hash function is too large, so the specific value is not given, and it is assumed that the value remains unchanged after modulo.
[0078] Let G = 13, r = 7, u j =25, then:
[0079] commit j ={A=H(13 7 ),B=7+25·A}
[0080] TH j Put P j =13 25 and commitj Send to other trusted hardware TH, other trusted hardware TH calculates If the data is true, the formula can be transformed into The equation must hold.
[0081] In this embodiment of the present invention, data sent between trusted hardware THs in most cases requires a commitment to ensure data authenticity and to exclude malicious nodes. The specific commitment methods for each data item will not be detailed here, except for key data, which requires specific explanation to ensure solution integrity.
[0082] In one embodiment, the method further comprises:
[0083] Each trusted hardware in the trusted hardware network randomly generates a first-class t-1 degree polynomial function, where t is the number of trusted hardware and the constant term of the first-class t-1 degree polynomial function is the private key shard of the trusted hardware;
[0084] Each trusted hardware generates n function values based on the first-class t-1 degree polynomial function and distributes each function value to other trusted hardware corresponding to the function value; n is the number of all trusted hardware in the trusted hardware network;
[0085] Each trusted hardware calculates a function and value of each trusted hardware according to the calculated function value and all received function values.
[0086] In one embodiment, the method further comprises:
[0087] Each trusted hardware attaches a commitment when distributing each function value to other trusted nodes corresponding to the function value;
[0088] After receiving the function value and commitment broadcast by other trusted hardware, each trusted hardware verifies the received function value. If the verification passes, it accepts the function value. Otherwise, it reports the error report of the other trusted hardware to the upper system.
[0089] Among them, if the upper-level system receives more than a preset number of error reports for a trusted hardware and determines that the trusted hardware is a malicious node, the malicious node will be removed from the trusted hardware network and the key of the trusted hardware network will be regenerated. If the upper-level system only receives one error report for a trusted hardware, a warning will be issued to the trusted hardware, and the trusted hardware will be required to resend the correct intermediate value to the trusted hardware that reported the error report.
[0090] The above process is the dynamic private key sharding generation process of the trusted hardware network, which is described in detail below.
[0091] n initial trusted hardware THs generate the private key s distributively. When the private key s is required to execute a trusted service, all the trusted hardware THs must participate to form the complete private key s. After some of the trusted hardware THs go offline, are damaged, are attacked, or become malicious nodes, the trusted service cannot be completed. To solve this problem, the embodiment of the present invention uses the (t,n) threshold method to achieve that when there are t or more (t < n) trusted hardware THs online (in practical applications, if there are more than t trusted hardware THs online, the upper-layer system will select t trusted hardware THs to complete the user's trusted service, including the trusted hardware TH for user access and t - 1 randomly selected trusted hardware THs, in order to save computing resources. Therefore, the following will be described by taking t trusted hardware THs online as an example), each trusted hardware TH generates a dynamic private key shard si (i ∈ [1,t]), and the sum of these t private key shards is the private key s, that is:
[0092]
[0093] (1) To implement the (t,n) threshold method, first, n initial trusted hardware THs need to randomly generate their own first-class t - 1 degree polynomial functions. Let the polynomial generated by THj be f j (x). Then, let:
[0094] f j (x) = a t-1 x t-1 + a t-2 x t-2 + … + a2x 2 + a1x + a0
[0095] where the constant term is a0 = u j , and the other polynomial coefficients are randomly generated.
[0096] (2) Then each TH j calculates f j (X1), f j (X2), f j (X3), … f j (X n ) for a total of n function values, and distributes them to the TH corresponding to the X value of this trusted hardware identifier j , for example, TH j sends f j (X1) to TH1, and keeps f j (X j ) itself.
[0097] (3) Since these function values are the core elements for constructing the private key shard s i , it is necessary to ensure their correctness. Therefore, a commitment commit needs to be attached when sendingj Let p be a large prime factor of q-1, And is a generator of a p-order cyclic group, then let TH j Commit j for:
[0098]
[0099] TH j Commit j Contains t elements and is sent to other trusted hardware TH.
[0100] (4) When the trusted hardware TH receives the function value and commitment from other trusted hardware, it needs to verify it. If the verification is successful, the function value is accepted. Otherwise, an error report is reported to the upper system. If the upper system receives multiple error reports for a certain trusted hardware TH, it determines that the trusted hardware TH is a malicious node, removes the trusted hardware TH, and reorganizes a round of distributed key generation process. If the upper system receives only one error report for a certain trusted hardware TH, it issues a warning to the trusted hardware TH and requires it to resend the correct function value to the reporting node. The verification method is as follows:
[0101] TH z (z∈[1,n]) for the received j The function value f j (X z ) and commit j , calculate whether the following equation holds:
[0102]
[0103] If not, verification fails. j The polynomial coefficients are bound, if TH j If the given commitment is not generated by the true coefficients of its polynomial function, the verification will fail. At the same time, due to the characteristics of discrete logarithm modular calculation, the polynomial coefficients cannot be deduced from the commitment.
[0104] To make it easier to understand, a simple example is given below:
[0105] Because p and q are both large prime numbers, and the example number is small, the value remains unchanged after the modulo operation.
[0106] Assume n = 5, t = 3, g = 7, and the polynomial f1(x) of TH1 = 2x 2 +4x+6, then we have:
[0107] commit1={α0=g 6,α1=g 4 ,α2=g 2}
[0108] Assume that the X value of TH2 is X2=2, then f1(X2)=22.
[0109] TH1 sends f1(X2) and commit1 to TH2, and TH2 calculates
[0110] as well as The equation is established and the verification is passed.
[0111] (5) After the commitment verification is passed, each TH j Each TH will get n function values corresponding to its X value, one of which is obtained by itself and the other n-1 are sent by other trusted hardware TH. j Add the obtained n function values and set their sum as the function sum value L j , then we have:
[0112]
[0113] In each TH j After obtaining its own function and value L value, delete its u for safety reasons j The value is no longer needed to complete the user's trusted business and reorganize the private key s.
[0114] (6) When the user client accesses a trusted hardware TH and applies to execute a trusted business, the upper system will randomly assign t-1 online trusted hardware THs, and these t trusted hardware THs will work together to complete the trusted business. The t trusted hardware THs first generate their own dynamic private key shards i , and meet Then each trusted hardware TH uses privacy computing technology to store private key s and node’s own private key shards without exposing them. i In this case, the private key s is reorganized in a distributed manner and the trusted business is completed.
[0115] t trusted hardware TH generates its own dynamic private key shard s i , i∈[1,t], the specific method is as follows:
[0116]
[0117] At this time, the private key shard s of the t trusted hardware TH i The sum is the private key s. The number of online trusted hardware TH may be different at different times, but as long as the number of online trusted hardware TH is greater than or equal to t, the corresponding dynamic private key shard can be generated based on the online trusted hardware TH. i .
[0118] For the dynamic private key shard s of THi at a certain moment i , where L i The value of is relatively fixed, and The value of changes dynamically according to the X value of the collaborative online trusted hardware TH.
[0119] To make it easier to understand, a simple example is given below:
[0120] Because a simple example of the commitment method has been given, this example assumes that the function value is accepted only after each trusted hardware TH has passed the commitment, and the commitment process will not be repeated.
[0121] Assume n=5, t=3, X1=1, X2=2, X3=3, X4=4, X5=5.
[0122] For TH1, let u1 = 8, f1(x) = x 2 -2x+8,
[0123] Then we can calculate f1(1)=7,f1(2)=8,f1(3)=11,f1(4)=16,f1(5)=23;
[0124] For TH2, let u2 = 6, f2(x) = x 2 +2x+6,
[0125] Then we can calculate f2(1)=9, f2(2)=14, f2(3)=21, f2(4)=30, f2(5)=41;
[0126] To calculate TH3, let u3 = 7, f3(x) = 2x 2 +x+7,
[0127] Then we can calculate f3(1)=10, f3(2)=17, f3(3)=28, f3(4)=43, f3(5)=62;
[0128] For TH4, let u4=3, f4(x)=x 2 +3x+3,
[0129] Then we can calculate f4(1)=7,f4(2)=13,f4(3)=21,f4(4)=31,f4(5)=43;
[0130] For TH5, let u5 = 5, f5(x) = 2x 2 -x+5,
[0131] Then we can calculate f5(1)=6, f5(2)=11, f5(3)=20, f5(4)=33, f5(5)=50.
[0132] Private Key 5 trusted hardware TH only knows its own u i , the value of the private key s cannot be known.
[0133] Then the five trusted hardware THs send the calculated polynomial function values to the trusted hardware THs corresponding to the X values. For example, TH1 will obtain f1(1), f2(1), f3(1), f4(1), and f5(1).
[0134] The five trusted hardware THs can each calculate their function and value L:
[0135]
[0136] Assume that a user accesses TH1 and applies for a trusted service, and at this time only TH1, TH2, and TH3 are online.
[0137] Then TH1, TH2, and TH3 can each calculate their dynamic private key shards:
[0138]
[0139] The sum of the dynamic private key shards of TH1, TH2, and TH3 is equal to 29, which is the same as the private key s. In the above calculation process, these three trusted hardware THs also only know their own dynamic private key shards. i , the value of the private key s cannot be known.
[0140] In a multi-trusted hardware collaboration environment, on the one hand, it is necessary to prevent trusted hardware TH from conspiring to steal the private key s, on the other hand, it is necessary to invalidate the node data when removing malicious trusted hardware TH, and on the other hand, it is necessary to allow the addition of new trusted hardware TH or recovery when the trusted hardware TH is damaged. j The value is the key to find the private key s. In order to ensure that this patented system can meet the above security and openness requirements, it is necessary to implement the trusted hardware THL j The updated value of L j The value can still correctly calculate the private key s. When each trusted hardware TH in the trusted hardware network regularly updates L j When the value is set, it is called a regular update; when a trusted hardware TH actively exits or is removed, a round of L is also required. j When a new trusted hardware TH is added or data is damaged, it is necessary to obtain the corresponding L j value.
[0141] The following describes several functions and the process of value update.
[0142] (1) Regular updates
[0143] In one embodiment, the method further comprises:
[0144] At the beginning of each update cycle, each trusted hardware in the trusted hardware network randomly generates a second-order t-1 polynomial function, where t is the number of online trusted hardware and the constant term of the second-order t-1 polynomial function is 0.
[0145] Each trusted hardware generates n function values based on a t-1 degree polynomial function of the second kind, and distributes each function value to other trusted nodes corresponding to the function value; n is the number of all trusted hardware in the trusted hardware network, and each function value corresponds to another trusted node number.
[0146] Each trusted hardware obtains an increment of the function and value of each trusted hardware based on the calculated function value and all received function values;
[0147] The increment of the function and value of each trusted hardware is added to the function and value of the previous cycle to obtain the updated function and value of each trusted hardware.
[0148] Regular updates refer to regular updates of all functions and values of trusted hardware TH. j The value needs to be updated periodically (the periodic time can be set by the upper system). If an attacker obtains the L of part of the trusted hardware TH in the previous period, j value, then in this cycle these L j The value has become invalid. Unless the attacker can obtain L greater than or equal to t trusted hardware TH in one cycle j value, otherwise the private key s cannot be obtained.
[0149] Here’s how to do it:
[0150] 1) At the beginning of a new cycle, all trusted hardware TH randomly generates its own t-1 degree polynomial function. Let the number of trusted hardware TH at this time be n, and a certain trusted hardware TH be TH j , j∈[1,n], TH j The generated polynomial is g j (x), then let:
[0151] g j (x) = a t-1 x t-1 +a t-2 x t-2 +…+a2x 2 +a1x
[0152] g j The polynomial coefficients of (x) are randomly generated, and its constant term is 0.
[0153] 2) Then each TH j Calculate gj (X1),g j (X2),g j (X3),…g j (X n ) a total of n function values (and each with a commitment commit j The commitment and verification methods are the same as above, so we will not repeat them here. The commitment is distributed to the trusted hardware TH corresponding to the X value, such as TH j Put g j (X1) sends to TH1, g j (X j ) are kept for themselves.
[0154] 3) Each TH j Each TH will get n function values corresponding to its X value, one of which is obtained by itself and the other n-1 are sent by other trusted hardware TH. j Add the obtained n function values to get the value added, and then add it to the L of the previous cycle. j Value (set to L j ′) and add them together to get the function and value L of the new period j value:
[0155]
[0156] To make it easier to understand, a simple example is given below:
[0157] Based on the example in the previous dynamic private key shard generation.
[0158] In this example, n=5, t=3, X1=1, X2=2, X3=3, X4=4, X5=5.
[0159] And s=29, L1=39, L2=63, L3=101.
[0160] For TH1, let g1(x)=x 2 -2x,
[0161] Then we can calculate g1(1)=-1, g1(2)=0, g1(3)=3, g1(4)=8, g1(5)=15;
[0162] For TH2, let g2(x)=2x 2 -3x,
[0163] Then we can calculate g2(1)=-1, g2(2)=2, g2(3)=9, g2(4)=20, g2(5)=35;
[0164] To calculate TH3, let g3(x)=x 2 +x,
[0165] Then we can calculate g3(1)=2, g3(2)=6, g3(3)=12, g3(4)=20, g3(5)=30;
[0166] For TH4, let g4(x)=3x 2 +2x,
[0167] Then we can calculate g4(1)=5, g4(2)=16, g4(3)=33, g4(4)=56, g4(5)=85;
[0168] For TH5, let g5(x)=x 2 -x,
[0169] Then we can calculate g5(1)=0, g5(2)=2, g5(3)=6, g5(4)=12, g5(5)=20.
[0170] Then the five trusted hardware THs send the calculated polynomial function values to the trusted hardware THs corresponding to the X values. For example, TH1 will obtain g1(1), g2(1), g3(1), g4(1), and g5(1).
[0171] The last five trusted hardware TH Complete the update of the function and value L.
[0172] For example, for the three trusted hardware THs TH1, TH2, and TH3, the new L1, L2, and L3 can be calculated as follows:
[0173] L1=44, L2=89, L3=164.
[0174] The dynamic private key shards of each trusted hardware TH can be further calculated:
[0175]
[0176] The sum of the dynamic private key shards of TH1, TH2, and TH3 is equal to 29, which is the same as the private key s.
[0177] It can be seen that although L1, L2, and L3 corresponding to these three trusted hardware TH have been updated, the value of the private key s can still be correctly calculated.
[0178] (2) Trusted Hardware Exit
[0179] In one embodiment, the method further comprises:
[0180] When an online trusted hardware in the trusted hardware network exits, the trusted hardware assigned by the upper system is obtained;
[0181] The assigned trusted hardware randomly generates a second-order t-1 polynomial function, where t is the number of online trusted hardware;
[0182] The assigned trusted hardware generates n function values based on the second-order t-1 polynomial function and distributes each function value to other trusted nodes corresponding to the function value; n is the number of all trusted hardware in the trusted hardware network, and each function value corresponds to another trusted node identifier;
[0183] Each trusted hardware adds the received function value to the current function sum value to obtain an updated function sum value of each trusted hardware.
[0184] In the above embodiment, the trusted hardware TH can exit voluntarily or be kicked out by the upper system due to malicious behavior. In this case, L j The value is updated to ensure that the L j The value is no longer valid.
[0185] Here’s how to do it:
[0186] 1) The upper system randomly assigns a trusted hardware TH, which randomly generates its own second-order t-1 polynomial function. Suppose the number of trusted hardware THs at this time is n, and a trusted hardware TH is TH j , the assigned trusted hardware TH is TH w , the exited trusted hardware TH is TH z ,j,w,z∈[1,n],TH w The generated polynomial is g w (x), then let:
[0187] g w (x) = a t-1 x t-1 +a t-2 x t-2 +…+a2x 2 +a1x
[0188] g w The polynomial coefficients of (x) are randomly generated, and its constant term is 0.
[0189] 2) Then TH w Calculate g w (X1),g w (X2),g w (X3),…g w (X n ) a total of n-1 function values (excluding g w (X z ), and still need to attach a commit commit wThe commitment method and verification method are the same as the above method, and the relevant content will not be repeated), and distributed to the trusted hardware TH (excluding THz) corresponding to this X value, such as TH w Put g w (X1) sends to TH1, g w (X w ) are kept for themselves.
[0190] 3) Each TH j (excluding TH z ) will get a function value g corresponding to its X value w (X j ). Each THj (excluding TH z ) Get the g w (X j ) and the current L j Value (set to L j ′) and add them together to get the new function and value L j value:
[0191] L j =g w (X j )+L j '
[0192] Trusted Hardware TH Exit Update L j The value method is actually a simplified version of the regular update, the purpose of which is to improve system operation efficiency, so it will not be explained in detail. The reason why all trusted hardware THs are required to generate polynomials and send function values in the regular update is to be able to detect malicious trusted hardware THs.
[0193] (2) Trusted hardware added
[0194] In one embodiment, the method further comprises:
[0195] When trusted hardware joins the trusted hardware network, the trusted hardware obtains the upper-layer system's consent to join;
[0196] The added trusted hardware generates a trusted node ID and secretly submits it to the upper-layer system. After receiving the approval message from the upper-layer system, the added trusted hardware sends the trusted node ID to other trusted hardware;
[0197] The added trusted hardware randomly selects t online trusted hardware as assisting trusted hardware;
[0198] Each assisting trusted hardware randomly generates a second-order t-1 polynomial function, where the constant term of the second-order t-1 polynomial function is 0;
[0199] Each assisting trusted hardware generates n function values according to the second-type t-1 degree polynomial function, and distributes each function value to other assisting trusted hardware corresponding to the function value;
[0200] Each assisting trusted hardware obtains an increment of the function and value of each assisting trusted hardware according to the calculated function value and all received function values;
[0201] Adding the increment of the function and value of each assisting trusted hardware to the function and value of the previous cycle to obtain a first pseudo function and value of each assisting trusted hardware;
[0202] Each assisting trusted hardware sends the first dummy function and value to the joining trusted hardware;
[0203] The added trusted hardware calculates the function and value of the added trusted hardware according to the received multiple pseudo functions and values.
[0204] In the above embodiment, the new trusted hardware can apply to the upper system, and after the upper system approves it, it becomes the newly added trusted hardware TH. w .
[0205] Here’s how to do it:
[0206] 1)TH w Generate your own trusted hardware identification X value (set to X w ) and secretly submit it to the upper system. The upper system verifies that the X value cannot be the same as the X value of other trusted hardware TH. After the review is passed, TH w X w Send to other trusted hardware TH.
[0207] 2)TH w Randomly select t online trusted hardware TH to assist it in obtaining the function and value L w Value, let the X value of this t online trusted hardware TH be X1, X2, X3, ... X t , where a trusted hardware TH is TH i , i∈[1,t]. This t trusted hardware TH can be used without exposing itself L through the following assistance process i Assist TH under the premise of value w Get its L w value.
[0208] 3) Each TH i Randomly generate your own second kind t-1 degree polynomial function, let the polynomial generated by THi be p i (x), then let:
[0209] p i (x) = a t-1x t-1 +a t-2 x t-2 +…+a2x 2 +a1x+a0
[0210] p i The polynomial coefficients of (x) are randomly generated, but must satisfy p i (X w )=0.
[0211] 4) Then each THi calculates p i (X1),p i (X2),p i (X3),…p i (X t ) a total of t function values (and each with a commitment commit i The commitment and verification methods are the same as those described above, and the relevant content will not be repeated here. The corresponding X value is distributed to the trusted hardware TH, such as TH i Put p i (X1) sends to TH1, to p i (X i ) are kept for themselves.
[0212] 5) Each TH i Each TH will get t function values corresponding to its X value, one of which is obtained by itself and the other t-1 are sent by other trusted hardware TH. i Add the obtained t function values and add them to your own L i Add the values to get the first pseudo function and value L i Value (set to F i ) and send it to TH w :
[0213]
[0214] 6)TH w According to the received F i value, find its L w value, but it is impossible to deduce the L that assists the trusted hardware TH i value.
[0215]
[0216] To make it easier to understand, a simple example is given below:
[0217] Build upon the example in Dynamic Private Key Shard Generation.
[0218] In this example, n=5, t=3, X1=1, X2=2, X3=3, X4=4, X5=5.
[0219] And s=29, L1=39, L2=63, L3=101.
[0220] Assume that the newly added trusted hardware TH is TH6, and TH6 selects its X6=10.
[0221] TH6 selects TH1, TH2, and TH3 to assist it in obtaining the L6 value.
[0222] TH1 generates p1(x)=x 2 +3x-130, satisfying p1(10)=0.
[0223] TH2 generates p2(x)=x 2 -x-90, satisfying p2(10)=0.
[0224] TH3 generates p3(x)=2x 2 +2x-220, satisfying p3(10)=0.
[0225] TH1 calculates p1(1)=-126, p1(2)=-120, p1(3)=-112 and distributes them to TH1, TH2, and TH3.
[0226] TH2 calculates p2(1)=-90, p2(2)=-88, p2(3)=-84 and distributes them to TH1, TH2, and TH3.
[0227] TH3 calculates p3(1)=-216, p3(2)=-208, p3(3)=-196 and distributes them to TH1, TH2, and TH3.
[0228] TH1 calculates F1=39-126-90-216=-393 and sends it to TH6.
[0229] TH2 calculates F2=63-120-88-208=-353 and sends it to TH6.
[0230] TH3 calculates F3=101-112-84-196=-291 and sends it to TH6.
[0231] TH6 calculated
[0232] If we use TH1, TH2, and TH6 as examples to calculate the private key s, we can get:
[0233] The sum of the dynamic private key shards of TH1, TH2, and TH6 is equal to 29, which is the same as the private key s.
[0234] It can be seen that the L6 value generated by TH6 is correct, but TH6 cannot know the L values of TH1, TH2, and TH3.
[0235] (4) Trusted Hardware TH Data Recovery
[0236] There are two ways to implement trusted hardware TH data recovery.
[0237] In the first trusted hardware TH data recovery method, when there is trusted hardware in the trusted hardware network that needs to perform data recovery, the trusted hardware that needs to perform data recovery sends a data recovery application to the upper-level system. After receiving the approval message from the upper-level system, the trusted hardware identifier that needs to perform data recovery is sent to other trusted hardware, and when there is trusted hardware joining the trusted hardware network, the function and value of the trusted hardware that needs to perform data recovery are obtained.
[0238] However, in some cases, a large number of trusted hardware TH may be damaged due to network attacks, causing the service to be temporarily paralyzed. Therefore, the embodiment of the present invention also provides a method for quickly retrieving L j The method of value. Let the trusted hardware TH that needs data recovery be TH w .
[0239] The second trusted hardware TH data recovery method includes:
[0240] When a trusted hardware in the trusted hardware network needs to perform data recovery, the trusted hardware that needs to perform data recovery sends a data recovery request to the upper-layer system. After receiving the approval message from the upper-layer system, the trusted hardware that needs to perform data recovery randomly selects t online trusted hardware as the assisting trusted hardware.
[0241] Each assisting trusted hardware randomly generates t integers and distributes them to other assisting trusted hardware;
[0242] Each assisting trusted hardware obtains a second pseudo function and value of each assisting trusted hardware according to the randomly generated integer and all received integers;
[0243] Each assisting trusted hardware sends the second pseudo function and value to the trusted hardware that needs to perform data recovery;
[0244] The trusted hardware that needs to perform data recovery calculates the function and value of the trusted hardware that needs to perform data recovery based on the received multiple second pseudo functions and values.
[0245] The implementation method of the above embodiment is as follows:
[0246] 1)TH w Randomly select t online trusted hardware TH to assist it in obtaining L w Value, let the X value of this t online trusted hardware TH be X1, X2, X3, ... Xt , where a trusted hardware TH is TH i , i∈[1,t]. This t trusted hardware TH can be used without exposing itself L through the following assistance process i Assist TH under the premise of value w Get its L w value.
[0247] 2) Each TH i Randomly generate t integers r iv , v∈[1,t], and satisfy
[0248] 3) Each TH i Take these t random integers riv Distribute to the corresponding TH v , such as TH3 put r 31 Sent to TH1, 33 Keep it for yourself.
[0249] 4) Each TH i Each TH will get t corresponding r values, 1 of which is obtained by itself, and the other t-1 are sent by other trusted hardware TH. i Calculate D as follows i value and send it to TH w :
[0250]
[0251] 5)TH w According to the received D i value, retrieve its L w value, but it is impossible to deduce the L that assists the trusted hardware TH i value.
[0252]
[0253] To make it easier to understand, a simple example is given below:
[0254] Build upon the example in Dynamic Private Key Shard Generation.
[0255] In this example, n=5, t=3, X1=1, X2=2, X3=3, X4=4, X5=5.
[0256] And L1=39, L2=63, L3=101, L5=219.
[0257] Assume that the trusted hardware TH with data corruption is TH5, and TH5 selects TH1, TH2, and TH3 to assist it in retrieving L5.
[0258] TH1 generation 11 =3, r 12 =1, r 13 =-4, satisfied And distributed to TH1, TH2, TH3.
[0259] TH2 production 21 =2, r 22 =4, r 23 =-6, satisfied And distributed to TH1, TH2, TH3.
[0260] TH3 production 31 =5, r 32 =-3, r 33 =-2, satisfied And distributed to TH1, TH2, TH3.
[0261] TH1 calculated And send it to TH5.
[0262] TH2 calculated And send it to TH5.
[0263] TH3 calculated And send it to TH5.
[0264] TH5 calculates L5 = 127 - 502 + 594 = 219, which is the same as before the damage, indicating that the data is correctly retrieved. However, TH5 cannot obtain the L values of TH1, TH2, and TH3.
[0265] Based on the above solution, a trusted service may be executed, corresponding to steps 101 to 108 , and the detailed process is now given.
[0266] The user uses the public key P pub Encrypt the user data (set as T) (set the encrypted ciphertext as M), then access the trusted hardware TH to apply for various trusted services on the user data T. Before executing the trusted services, the trusted hardware TH must first have the complete private key s to decrypt M. The embodiment of the present invention uses the ElGamal public key cryptography system as an example to introduce how to implement the above process. In the ElGamal public key cryptography system, P pub =G s modq, where q is a large prime number, And it is a generator of a cyclic group of order q, where q and G are public values.
[0267] (1) The user randomly generates an integer k (1<k<q-1) and generates a ciphertext M=(M1,M2).
[0268] Where M1=G kmodq, M2=T·P pub k modq.
[0269] (2) The user accesses a trusted hardware TH (set as TH w ), send the ciphertext M and user public key u pub Give TH w , and apply for relevant trusted businesses.
[0270] (3) The upper system randomly assigns t-1 online trusted hardware TH, which assists TH w Complete the distributed decryption of the ciphertext M (if the trusted business is more complex, the t-1 trusted hardware TH will continue to assist TH w Distributed completion of trusted business).
[0271] (4) t trusted hardware TH(TH w and t-1 assisting trusted hardware TH) to generate their own dynamic private key shards s i , i∈[1,t].
[0272] (5)TH w Send M1 to t-1 assisting trusted hardware TH.
[0273] (6) In the ElGamal public key cryptosystem, the decryption formula is:
[0274] Each TH i calculate t-1 assists trusted hardware TH to put its own C i Send to TH w Due to the characteristics of cyclic groups, we know that C i and M1 cannot infer s i .
[0275] (7)TH w Decrypt the user's personal data according to the following formula. Since the trusted hardware TH assists in sharing most of the exponential calculations in the decryption formula (calculating M1 s ), thus reducing TH w computational burden.
[0276]
[0277] To make it easier to understand, a simple example is given below:
[0278] Assume that a user accesses TH1 to apply for a trusted service, and TH2 and TH3 serve as assisting trusted hardware TH.
[0279] And s1=4,s2=5,s3=6, that is, the private key s=15.
[0280] Assume that the user's personal data T=10, G=7. Since q is a large prime number and the example number is small, the value remains unchanged after the modulo operation.
[0281] Then there is: P pub =7 15 .
[0282] The user generates k=4, then M1=7 4 , M2=10×7 60 .
[0283] TH1 calculates C1=7 16 , TH2 calculates C2=7 20 , TH3 calculates C3=7 24 .
[0284] TH1 finally calculated: The decryption is correct, and the dynamic private key shards of TH2 and TH3 cannot be known during the decryption process.
[0285] (8)TH w According to the user's business requirements, various operations are performed on T (if the business is more complex, the t trusted hardware TH will perform various operations in a distributed manner), and the result E is obtained. Then, the user's public key u is used to calculate the result. pu b Encrypt E to obtain E′, and finally send E′ to the user.
[0286] (9) The user decrypts E' with his private key and obtains the required service execution result E. The user can freely choose the encryption and decryption scheme of his public and private keys, and the present invention does not provide a specific method.
[0287] The embodiment of the present invention further proposes a distributed key protection system for a multi-trusted hardware collaboration environment, the principle of which is similar to the distributed key protection method for a multi-trusted hardware collaboration environment, and will not be repeated here.
[0288] Figure 5 Schematic diagram of a distributed key protection system for a multi-trusted hardware collaboration environment according to an embodiment of the present invention, comprising: a user client 501, a trusted hardware network 502, and an upper-layer system 503; wherein the trusted hardware network includes multiple trusted hardware;
[0289] The user client is used to: encrypt user data using the public key of the trusted hardware network to generate ciphertext, and send a trusted service application to a trusted hardware of the trusted hardware network, wherein the trusted service application includes the ciphertext, the user's public key and the service requirement;
[0290] The upper-layer system is used to randomly assign multiple online trusted hardware as assisting trusted hardware based on trusted service applications. The trusted hardware that receives the trusted service application is the access trusted hardware, and all assisting trusted hardware and access feasible hardware are the execution trusted hardware.
[0291] The trusted hardware is used to: generate dynamic private key shards based on the functions and values executed by the trusted hardware;
[0292] The access trusted hardware is used to: send the first part of the ciphertext to all assisting trusted hardware;
[0293] Execute trusted hardware to: calculate decryption intermediate values based on dynamic private key sharding;
[0294] Assisting the trusted hardware to: send the decrypted intermediate value to the access trusted hardware;
[0295] The access trusted hardware is used to: calculate the plaintext corresponding to the ciphertext based on the second part of the ciphertext and all received decryption intermediate values;
[0296] Access to trusted hardware is used to: execute operations according to business requirements and obtain business execution results;
[0297] The trusted hardware is used to encrypt the service execution result using the user's public key, and send the encrypted result to the user client, so that the user client can decrypt the encrypted result using the user's private key.
[0298] In summary, the method and system proposed in the embodiments of the present invention have the following beneficial effects:
[0299] Providing homogeneous services: By sharing and synchronizing keys between trusted hardware, it can be ensured that all computing trusted hardware can use the same key during the encryption and decryption process, regardless of which trusted hardware the user is connected to. Therefore, multiple trusted hardware can work synchronously and provide consistent and homogeneous encryption and decryption services to user clients.
[0300] Preventing key leakage: The embodiment of the present invention adopts distributed key management, which will not affect the overall security of the trusted hardware network even if any trusted hardware is leaked.
[0301] Support for dynamic hardware rotation: To accommodate the dynamic nature of trusted hardware, such as hardware additions, replacements, or downtime, this invention supports dynamic trusted hardware rotation. Through advanced key synchronization and update mechanisms, homogeneous services and high security are maintained even after hardware composition changes.
[0302] Preventing collusion attacks: The embodiments of the present invention take into account the need to prevent collusion attacks by implementing multi-party secure computing and key sharding, ensuring that even if some trusted hardware that has been rotated offline colluded, the keys in the current service cannot be obtained or restored.
[0303] Support for heterogeneous trusted hardware: Supports different types of trusted hardware to form a trusted hardware network.
[0304] Through the above process, the problem of resource limitations of a single trusted hardware when processing large-scale data or high-concurrency computing tasks is solved.
[0305] The specific embodiments described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.
Claims
1. A distributed key protection method for a multi-trusted hardware collaboration environment, characterized in that: include: When a trusted hardware in the trusted hardware network receives a trusted service application from a user client, it obtains multiple online trusted hardware randomly assigned by the upper-layer system and acts as assisting trusted hardware. The trusted hardware that receives the trusted service application is the access trusted hardware, and all assisting trusted hardware and access feasible hardware are the execution trusted hardware. The trusted service application includes a ciphertext, the user's public key, and service requirements. The ciphertext is encrypted by using the public key of the trusted hardware network to encrypt user data. Each trusted hardware execution generates a dynamic private key shard based on the function and value of each trusted hardware execution; The access trusted hardware sends the first part of the ciphertext to all assisting trusted hardware; Each trusted hardware executes sharding based on the dynamic private key and calculates the decrypted intermediate value; Each assisting trusted hardware sends the decrypted intermediate value to the access trusted hardware; The access trusted hardware calculates the plaintext corresponding to the ciphertext based on the second part of the ciphertext and all received decryption intermediate values; Access trusted hardware to execute operations according to business requirements and obtain business execution results; The trusted hardware is connected to encrypt the business execution result using the user's public key, and the encrypted result is sent to the user client, so that the user client can decrypt the encrypted result using the user's private key.
2. The method according to claim 1, wherein Also includes: All trusted hardware in the trusted hardware network generates a private key shard, which is a random positive integer; Add up the private key shards of all trusted hardware to get the private key of the trusted hardware network; Based on the cryptographic system selected in the current business environment, each trusted hardware calculates the intermediate value based on the private key shards and broadcasts the intermediate value to other trusted hardware; Each trusted hardware calculates a public key based on the calculated intermediate value and all received intermediate values, and broadcasts it to the entire trusted hardware network.
3. The method according to claim 2, wherein Also includes: Each trusted hardware attaches a commitment when broadcasting the intermediate value to other trusted hardware; After receiving the intermediate value and commitment broadcast by other trusted hardware, each trusted hardware verifies the received intermediate value. If the verification is successful, it accepts the intermediate value. Otherwise, it reports the error report of the other trusted hardware to the upper system. Among them, if the upper-level system receives more than a preset number of error reports for a trusted hardware and determines that the trusted hardware is a malicious node, the malicious node will be removed from the trusted hardware network and the key of the trusted hardware network will be regenerated. If the upper-level system only receives one error report for a trusted hardware, a warning will be issued to the trusted hardware, and the trusted hardware will be required to resend the correct intermediate value to the trusted hardware that reported the error report.
4. The method according to claim 1, wherein After generating the public key for the trusted hardware network, also include: Remote assertion of all trusted hardware; After the assertion succeeds, the trusted hardware network allows the public key of the trusted hardware network.
5. The method according to claim 1, wherein Also includes: Each trusted hardware in the trusted hardware network randomly generates a first-class t-1 degree polynomial function, where t is the number of trusted hardware and the constant term of the first-class t-1 degree polynomial function is the private key shard of the trusted hardware; Each trusted hardware generates n function values according to the first-class t-1 degree polynomial function, and distributes each function value to other trusted hardware corresponding to the function value; n is the number of all trusted hardware in the trusted hardware network; Each trusted hardware calculates a function and value of each trusted hardware according to the calculated function value and all received function values.
6. The method according to claim 5, wherein Also includes: Each trusted hardware attaches a commitment when distributing each function value to other trusted nodes corresponding to the function value; After receiving the function value and commitment broadcast by other trusted hardware, each trusted hardware verifies the received function value. If the verification passes, it accepts the function value. Otherwise, it reports the error report of the other trusted hardware to the upper system. Among them, if the upper-level system receives more than a preset number of error reports for a trusted hardware and determines that the trusted hardware is a malicious node, the malicious node will be removed from the trusted hardware network and the key of the trusted hardware network will be regenerated. If the upper-level system only receives one error report for a trusted hardware, a warning will be issued to the trusted hardware, and the trusted hardware will be required to resend the correct intermediate value to the trusted hardware that reported the error report.
7. The method according to claim 1, wherein Also includes: At the beginning of each update cycle, each trusted hardware in the trusted hardware network randomly generates a second-order t-1 polynomial function, where t is the number of online trusted hardware and the constant term of the second-order t-1 polynomial function is 0. Each trusted hardware generates n function values based on the second-order t-1 polynomial function and distributes each function value to other trusted nodes corresponding to the function value; n is the number of all trusted hardware in the trusted hardware network, and each function value corresponds to the number of other trusted nodes; Each trusted hardware obtains an increment of the function and value of each trusted hardware based on the calculated function value and all received function values; The increment of the function and value of each trusted hardware is added to the function and value of the previous cycle to obtain the updated function and value of each trusted hardware.
8. The method according to claim 1, wherein Also includes: When an online trusted hardware in the trusted hardware network exits, the trusted hardware assigned by the upper system is obtained; The assigned trusted hardware randomly generates a second-order t-1 polynomial function, where t is the number of online trusted hardware; The assigned trusted hardware generates n function values according to the second-order t-1 polynomial function and distributes each function value to other trusted nodes corresponding to the function value; n is the number of all trusted hardware in the trusted hardware network, and each function value corresponds to the identity of other trusted nodes; Each trusted hardware adds the received function value to the current function sum value to obtain an updated function sum value of each trusted hardware.
9. The method according to claim 1, wherein Also includes: When trusted hardware joins the trusted hardware network, the trusted hardware obtains the upper-layer system's consent to join; The added trusted hardware generates a trusted node ID and secretly submits it to the upper-layer system. After receiving the approval message from the upper-layer system, the added trusted hardware sends the trusted node ID to other trusted hardware; The added trusted hardware randomly selects t online trusted hardware as assisting trusted hardware; Each assisting trusted hardware randomly generates a second-order t-1 polynomial function, where the constant term of the second-order t-1 polynomial function is 0; Each assisting trusted hardware generates n function values according to the second-type t-1 degree polynomial function, and distributes each function value to other assisting trusted hardware corresponding to the function value; Each assisting trusted hardware obtains an increment of the function and value of each assisting trusted hardware according to the calculated function value and all received function values; Adding the increment of the function and value of each assisting trusted hardware to the function and value of the previous cycle to obtain a first pseudo function and value of each assisting trusted hardware; Each assisting trusted hardware sends the first dummy function and value to the joining trusted hardware; The added trusted hardware calculates the function and value of the added trusted hardware according to the received multiple pseudo functions and values.
10. The method according to claim 1, wherein Also includes: When there is trusted hardware in the trusted hardware network that needs to perform data recovery, the trusted hardware that needs to perform data recovery sends a data recovery application to the upper-level system. After receiving the approval message from the upper-level system, the trusted hardware identifier that needs to perform data recovery is sent to other trusted hardware, and when there is trusted hardware joining the trusted hardware network, the function and value of the trusted hardware that needs to perform data recovery are obtained.
11. The method according to claim 1, wherein Also includes: When a trusted hardware in the trusted hardware network needs to perform data recovery, the trusted hardware that needs to perform data recovery sends a data recovery request to the upper-layer system. After receiving the approval message from the upper-layer system, the trusted hardware that needs to perform data recovery randomly selects t online trusted hardware as the assisting trusted hardware. Each assisting trusted hardware randomly generates t integers and distributes them to other assisting trusted hardware; Each assisting trusted hardware obtains a second pseudo function and value of each assisting trusted hardware according to the randomly generated integer and all received integers; Each assisting trusted hardware sends the second pseudo function and value to the trusted hardware that needs to perform data recovery; The trusted hardware that needs to perform data recovery calculates the function and value of the trusted hardware that needs to perform data recovery based on the received multiple second pseudo functions and values.
12. A distributed key protection system for a multi-trusted hardware collaboration environment, characterized in that: It includes user client, trusted hardware network and upper-layer system; wherein, the trusted hardware network includes multiple trusted hardware; The user client is used to: encrypt user data using the public key of the trusted hardware network to generate ciphertext, and send a trusted service application to a trusted hardware of the trusted hardware network, wherein the trusted service application includes the ciphertext, the user's public key and the service requirement; The upper-layer system is used to randomly assign multiple online trusted hardware as assisting trusted hardware based on trusted service applications. The trusted hardware that receives the trusted service application is the access trusted hardware, and all assisting trusted hardware and access feasible hardware are the execution trusted hardware. The trusted hardware is used to: generate dynamic private key shards based on the functions and values executed by the trusted hardware; The access trusted hardware is used to: send the first part of the ciphertext to all assisting trusted hardware; Execute trusted hardware to: calculate decryption intermediate values based on dynamic private key sharding; Assisting the trusted hardware to: send the decrypted intermediate value to the access trusted hardware; The access trusted hardware is used to: calculate the plaintext corresponding to the ciphertext based on the second part of the ciphertext and all received decryption intermediate values; Access to trusted hardware is used to: execute operations according to business requirements and obtain business execution results; The trusted hardware is used to encrypt the service execution result using the user's public key, and send the encrypted result to the user client, so that the user client can decrypt the encrypted result using the user's private key.
Citation Information
Patent Citations
User private key issuing method based on block chain
CN117040729A
Adaptive attack resistant distributed symmetric encryption
WO2021222272A1
Cited By
Method for digital currency intra-chain and cross-chain off-chain payments based on trusted hardware
US20250299186A1