System and method for protecting private digital signatures through hash and signature operations in decentralized trusted open execution environment

Abstract

The present disclosure provides a decentralized trusted computing system consisting of a set of trusted rich execution environments (T-REEs) deployed over a computer network, as well as methods of information processing performed within the T-REEs and methods of information exchange for the T-REEs to communicate with each other, perform privacy protection, and perform digital signature operations on electronic documents. The disclosure enables a trusted party called a certification authority (also a signer) to perform a hash operation of a file through a T-REE on a client computer and perform a private key signature operation on a hash value through the T-REE on a signer computer, thereby proving content integrity and source authenticity of a file submitted by a file submitter (called a client). This enables an authentication authority to prove the integrity and authenticity of the file without accessing the file content.

Description

Technical Field

[0001] This disclosure relates to the practice of attaching digital signatures to electronic documents (also known as file signing) to verify the integrity and authenticity of the document's content. Specifically, this disclosure discloses a distributed trusted computing system architecture, including virtualized trusted execution environments (TEEs) within a computer network, and information processing and exchange methods employed by these TEEs to digitally sign electronic documents while preserving the privacy of the document's content. Background Art

[0002] In the ecosystems of the Internet of Things (IoT), Software Defined Networks (SDN), and edge / cloud computing systems, system and application software modules are often provided by different software developers. Each developer intends to retain proprietary ownership of their software while allowing their software to be integrated with that of other developers and then deployed together within the Secure Development Operations (DevSecOps) lifecycle through a continuous integration and continuous deployment (CI-CD) process. In this lifecycle, all system and application software modules developed by software developers must be certified by a trusted certification authority (CA) before they can be deployed and run on user systems. For example, system software must be certified before it can be included in the secure boot process, and containerized application software must be certified before it can be included in the online provisioning process. However, since the software is submitted to the certification authority, the software's content may be leaked. Summary of the Invention

[0003] The embodiments disclosed herein provide a distributed digital signature system, comprising: a client subsystem having a rich execution environment, a first trusted rich execution environment, a second trusted rich execution environment, and a first trusted execution environment; and a signature terminal system having a third trusted rich execution environment and a second trusted execution environment. The client subsystem is used to provide a file in the rich execution environment and call a request signature function regarding the file. The client subsystem is also used to call a request hash function regarding the file in the first trusted rich execution environment, and calculate a hash value of the file in the first trusted execution environment in response to the request hash function. The client subsystem is also used to generate a first signature of the hash value and establish an atomic secure transaction with the signature terminal system in the first trusted rich execution environment. An atomically secure transaction includes: a client subsystem transmitting a hash value and a first signature to a signing subsystem in a first trusted rich execution environment; the signing subsystem verifying the first signature in a second trusted execution environment; upon successful verification of the first signature, the signing subsystem generating a second signature related to the hash value in the second trusted execution environment; and the signing subsystem transmitting the second signature to the client subsystem in a third trusted rich execution environment. The client subsystem generates a file blob based on the second signature of the hash value and the file in the second trusted rich execution environment in response to a request signature function.

[0004] In some embodiments, the client-side file signing module is installed in a first trusted rich execution environment, the file block construction module is installed in a second trusted rich execution environment, and the server-side file signing module is installed in a third trusted rich execution environment.

[0005] In some embodiments, the aforementioned atomic secure transaction further includes: performing mutual authentication by the client file signing module and the server file signing module; and exchanging session keys by the client file signing module and the server file signing module.

[0006] In some embodiments, the aforementioned atomic secure transaction further includes: the server-side file signing module transmitting the client certificate to the client-side file signing module, wherein the client certificate is issued to the client subsystem.

[0007] In some embodiments, the first signature of the hash value is generated based on a private key issued to the client file signing module.

[0008] In some embodiments, the second signature of the hash value is calculated based on the private key corresponding to the client.

[0009] In some embodiments, the client-side file signing module, server-side file signing module, file block construction module, hash function, and signing function are authenticated.

[0010] In some embodiments, the client subsystem includes general-purpose hardware, dedicated hardware, and protected hardware. The general-purpose hardware is disposed in a rich execution environment, the dedicated hardware is disposed in a first trusted rich execution environment and a second trusted rich execution environment, and the protected hardware is disposed in the first trusted execution environment.

[0011] In some embodiments, an untrusted general purpose operating system executes in a rich execution environment, a trusted general purpose operating system executes in a first trusted rich execution environment and a second trusted rich execution environment, and a trusted special purpose operating system executes in a first trusted execution environment.

[0012] In some embodiments, in the signing subsystem, only the server-side file signing module communicates with the client-side file signing module in the client subsystem.

[0013] In some embodiments, the aforementioned files are not provided by the signing terminal system.

[0014] The embodiments disclosed herein provide a distributed digital signature method, which is executed by a distributed digital signature system. This distributed digital signature method includes: a client subsystem provides a file in a rich execution environment and calls a request signature function regarding the file; the client subsystem calls a request hash function regarding the file in a first trusted rich execution environment; the client subsystem calculates a hash value of the file in the first trusted execution environment in response to the request hash function; the client subsystem generates a first signature of the hash value in the first trusted execution environment; and the client subsystem establishes an atomic secure transaction with a signature terminal system. The atomic secure transaction includes: the client subsystem transmits the hash value and the first signature to the signature terminal system; the signature terminal system verifies the first signature in a second trusted execution environment; when the first signature is successfully verified, the signature terminal system generates a second signature regarding the hash value in the second trusted execution environment; and the signature terminal system transmits the second signature to the client subsystem in a third trusted rich execution environment. The method further includes generating, by the client subsystem in the second trusted rich execution environment, a file blob based on the second signature of the hash value and the file in response to the request signature function.

[0015] The above design enables the certification body to prove the integrity and authenticity of the file without accessing the file content. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to make the above features and advantages of the present invention more clearly understood, embodiments are given below and described in detail with reference to the accompanying drawings.

[0017] Figure 1 This diagram illustrates the client subsystem and signing subsystem architecture according to one embodiment. The solid arrows in the diagram represent secure communication between the REE, T-REE, and TEE. The dashed arrows in the diagram show the interaction between the TEE and a trusted key and certificate management system to generate private and public key pairs used by the REE, T-REE, and TEE for secure communication.

[0018] Figure 2 This figure illustrates a functional block diagram of a distributed digital signature system, according to one embodiment. In the figure, functional blocks enclosed within rounded rectangles are provided by the client and are assumed to be untrusted, while functional blocks enclosed within sharp rectangles are provided by a certification authority (CA) or other trusted party. The software modules of these functional blocks are certified for integrity and source authenticity. Communications between all functional blocks (shown by solid arrows) are protected by cryptographically strong data confidentiality and integrity services, as well as mutual authentication between communication endpoints.

[0019] Figure 3 is a diagram illustrating a sequence diagram of operations between two subsystems according to an embodiment.

[0020] Figure 4 is a diagram showing a flow chart of a distributed digital signature method according to an embodiment. DETAILED DESCRIPTION

[0021] The following will further describe specific embodiments of the present invention in conjunction with the accompanying drawings. However, these embodiments are not intended to limit the present invention, and the description of the operations is not intended to limit the order of implementation. In addition, any device with equivalent functions generated by recombining the components falls within the scope of protection of the present invention. In addition, the drawings are for schematic illustration only and are not drawn to actual size.

[0022] The terms “first,” “second,” “third,” etc. used herein do not particularly refer to an order or sequence, but are only used to distinguish elements or operations described with the same technical terms.

[0023] The content integrity and source authenticity of an electronic file can be proven by the file's digital signature. The generation of this digital signature includes the following operations: first, calculating the digital hash value of the file content, and then using the private key issued by the certification authority to the file owner to perform a private key signing operation on the digital hash value. In the prior art, the digital hashing and private key signing operations are performed together in a secure computing environment called a Trusted Execution Environment (TEE), which is managed by the certification authority or its agent. To perform this operation, the file owner needs to submit the electronic file to the certification authority. As a result, the content of the electronic file is disclosed to the certification authority or its agent.

[0024] To protect the information privacy of electronic files, the file's content and sensitive metadata must not be disclosed to any other party, not even to the certification authority. To achieve this goal, the file owner (rather than the certification authority) should calculate the file's hash value in a trustworthy manner and then transmit the hash value (rather than the file itself) to the certification authority via a secure communication channel. After authenticating the source of the hash value, the certification authority calculates a digital signature of the hash value using the private key assigned to the file owner. This decentralized file hashing and file signing operation thus separates the calculation of the file's hash value (which requires the proprietary file as input) from the calculation of the file's digital signature (which only requires the file's hash value as input). By performing these two operations in separate trusted rich execution environments, each environment provides information isolation protection, thereby preserving the content privacy of proprietary files.

[0025] This decentralized file hashing and signing operation can be used to prove the content integrity and source authenticity of any electronic document, including electronic documents, program code, AI models, and datasets. Specifically, digital signing of program code and AI models has become a necessary step in the secure development and operations (DevSecOps) lifecycle. All system and application software modules developed by software developers in this lifecycle must be authenticated by a trusted certification authority before they can be deployed and run on user systems.

[0026] The distributed trusted computing system disclosed herein provides a system architecture, such as Figure 1As shown. The distributed digital signature system includes a client subsystem 101, which has one or more Rich Execution Environments (REEs) 130, multiple Trusted Rich Execution Environments (T-REEs) 120, and one or more Trusted Execution Environments (TEEs) 110. For simplicity, the following description uses the abbreviations REE, T-REE, and TEE. REE 130 is an unprotected virtual execution environment running on a computer. It is instantiated by a virtual machine monitor (hypervisor) 140 and is used to run under the control of an untrusted general-purpose operating system 134, thereby executing unprotected and untrusted applications 135. General-purpose hardware (non-dedicated) includes a general-purpose processor 131 , a general-purpose memory 132 , and a general-purpose input / output (I / O) 133 . These hardware are provided in the REE 130 to execute an untrusted general-purpose operating system 134 and an untrusted general-purpose application program 135 .

[0027] T-REE 120 is a protected virtual execution environment instantiated on a computer by a virtual machine monitor 140, used to run trusted general-purpose applications 125. These trusted general-purpose applications 125 must have their code integrity and source authenticity verified by a trusted third party and signed by a certification authority (CA) before being deployed and executed on T-REE 120. Dedicated hardware, including a dedicated processor 121, dedicated memory 122, and dedicated input / output 123, is provided within T-REE 120 to execute trusted applications 125 under the control of a trusted general-purpose operating system 124 designed specifically for servicing T-REE 120. These dedicated processors 121, dedicated memory 122, and dedicated input / output 123 are assigned to specific T-REEs through computer hardware, which enforces resource separation between execution environments.

[0028] TEE 110 is a protected entity or virtual execution environment established in the protected part of the computer. Protected hardware includes a protected processor 111 and protected memory 112, which are set in TEE 110. These protected hardware cannot be accessed or used by other execution environments. Protected hardware is used to enforce resource separation to distinguish resources between TEE 110 and other execution environments including TEE, T-REE 120 and REE 130. TEE 110 exchanges information through a TEE communication agent 115 (rather than a virtual machine monitor 140) running at a privileged computing level. This communication agent separates TEE communication from other system and user computing tasks. TEE 110 runs protected applications 114 under the control of a trusted special purpose operating system 113. These applications have special purposes to perform critical operations, such as cryptographic operations and trusting the system clock.

[0029] Communications 152 between multiple T-REEs 120 are protected by end-to-end data confidentiality and integrity services, with mutual authentication of the communication endpoints. Communications 151 between REEs 130 and T-REEs 120 are also protected by end-to-end data confidentiality and integrity services, with mutual authentication of the communication endpoints. The security services protecting these communications are performed by a protected special-purpose application 114 running in the TEE 110. The credentials and keys used for protection are stored in protected memory 112 within the TEE 110 and managed by the protected special-purpose application 114 running in the same TEE 110.

[0030] The keys and certificates used to protect all of the aforementioned communications are issued and managed by a trusted key and certificate management system 150. These keys and certificates are stored in protected memory 112 via communication 153.

[0031] refer to Figure 2 The distributed digital signature system 200 includes a client subsystem 201 and a signature terminal system 210. The client subsystem 201 includes REE 220, T-REE 221, T-REE 222 and TEE 223. Figure 1 REE 220 is identical to REE 110; T-REE 221 and T-REE 222 are identical to T-REE 120; and TEE 223 is identical to TEE 110. REE 220, T-REE 221, T-REE 222, and TEE 223 are created for the file source (also known as the client). REE 220 is also known as the developer REE. T-REE 221 is also known as the client T-REE. T-REE 222 is also known as the builder T-REE. TEE 223 is also known as the client crypto TEE.

[0032] The client subsystem 201 calculates the hash value of a file and then constructs a file blob by combining the file and the corresponding file signature. The above file may be program code or any digital file, which is not limited in this disclosure. Specifically, the signature subsystem 210 executes the file source 206 installed on the REE 220, the client file signature module 202 installed on the T-REE 221, the file blob construction module 203 installed on the T-REE 222, and the signature function 205 and hash function 204 installed on the TEE 223. The operation of each module will be described in detail below.

[0033] The signature terminal system 210 has a T-REE 225 and a TEE 226. The T-REE 225 is also called a server T-REE. The TEE 226 is also called a signer encryption TEE 226. The T-REE 225 and the TEE 226 are established for a certification authority (CA). The signature terminal system 210 calculates a file signature based on the hash value after verifying the authenticity of the hash value using the private key assigned to the client file signing module 202. Specifically, the signature terminal system 210 executes the server file signing module 211 installed on the T-REE 225, as well as the verification function 212 and the signature function 213 installed on the TEE 226. A secure key storage 214 is also installed in the TEE 226.

[0034] In terms of the operations and trust relationships between functional modules, the distributed hashing and signing system can be broken down into two domains of trust (DoT). The first domain is called the file source and file block construction domain, which includes the file source 206 in the REE 220 and the file block construction module 203 in the T-REE 222. The operations of the modules in the first domain are controlled by the software developer (i.e., the customer) and are separate from the operations in the second domain.

[0035] The second domain is called the file hash and signature domain, which includes the client file signature module 202, the hash function 204, the signature function 205, the server file signature module 211, the verification function 212 and the signature function 213. The operation of the modules in the second domain is controlled by the certification authority (CA) and is separated from the operation of the first domain. The second domain is a trusted domain. All programs that implement these modules must be verified by a trusted third party and certified by an approved certification authority before they can be deployed and used in this domain. In the second domain, the client file signature module 202 calculates the hash value based on the file, while the server file signature module 211 calculates the file signature separately based on the verified file hash value. Both the client file signature module 202 and the server file signature module 211 use the encryption function installed in the TEE 223 or 226 to which they belong.

[0036] The following paragraphs will explain in detail Figure 2 The functions and interactions between the components depicted in .

[0037] [File Source]

[0038] In some embodiments, file source 206, located in REE 220, is an operating environment in which a software developer (i.e., a client) provides code images. In other embodiments, file source 206 may be any suitable software module that provides any digital file used below. To ensure that other modules in the system trust the integrity and authenticity of the content interacting with file source 206, all communications with this module are protected by end-to-end data confidentiality and integrity services, with mutual authentication of the communication endpoints.

[0039] [Client file signature module]

[0040] In certain embodiments, the client-side file signing module 202 is the only module in the second trusted domain that can interact with the file source 206 and the file block construction module 203. It receives a file from the file source 206 and performs a file hash calculation operation by calling the hash function 204 in the TEE 223 to generate a file hash value. It also uses the private key assigned to the client-side file signing module 202 by the CA to generate a client signature based on the file hash value by calling the signature function 205 in the TEE 223.

[0041] The client-side file signing module 202 is also the only module that can interact with the server-side file signing module 211 in the signing subsystem 210. This interaction occurs through an atomic, secure transaction. Through this transaction, the client-side file signing module 202 receives a file signature from the server-side file signing module 211 and a client credential that can be used to verify the signature. The client-side file signing module 202 then forwards this data to the file block construction module 203 so that it can be combined with the file to generate a file block.

[0042] [Server-side file signature module]

[0043] In some embodiments, the server-side file signing module 211 is the only module that can interact with the client-side file signing module 202 in the client subsystem 201. It receives the file hash from the client-side file signing module 202 and verifies the integrity and authenticity of the file hash by calling the verification function 212 in the TEE 226 using the public key certificate issued to the client-side file signing module 202.

[0044] After successful verification, the server-side file signing module 211 performs the file signature calculation operation by calling the signature function 213 in the TEE 226. The signature function 213 then obtains the private key assigned to the client (called the signing key) from the secure key storage 214 and uses the signing key to sign the verified file hash.

[0045] After completing the file signature calculation operation, the server-side file signature module 211 then sends the file signature and the public key certificate corresponding to the private key assigned to the client (called the client credential) to the client-side file signature module 202 through an atomic secure transaction.

[0046] [File block construction module]

[0047] The file chunk construction module 203 is a component within the client subsystem 201 that combines a file with its signature and client credentials to create file chunks in various formats, enabling them to be deployed, verified, and used by various user systems. The file chunk construction module 203 is a component that undergoes trusted third-party verification and authentication, as it must be trusted by various user systems to generate unaltered and correct file chunks. Communication between the file chunk construction module 203 and the client file signing module 202 is protected by end-to-end data confidentiality and integrity services, with mutual authentication of the communication endpoints.

[0048] [Privacy-protected decentralized signature service process]

[0049] The workflow of the decentralized digital signature method is Figure 3The following are four operations embedded in the sequence diagram.

[0050] [Document signature operation]

[0051] In operation 311a, the request-sign function is called from file source 206 to client file signing module 202 with a file as a parameter. In other words, client subsystem 201 provides the file and calls the request-sign function for the file in REE 220. This function call initiates the distributed file hashing and file signing process, which concludes with the signed file block being returned by file block construction module 203.

[0052] [File hash calculation operation]

[0053] In response to the request signature function, the client file signing module 202 performs two operations 321a and 324a. In operation 321a, it calls a request hash function for the file in T-REE 221. In operation 331, after responding to the request hash function, the hash function 204 in TEE 223 calculates the hash value of the file. In operation 321b, the request hash function returns the hash value of the file (also called the file hash value) to the client file signing module 202.

[0054] In operation 324a, the client file signing module 202 initiates a signature hash function call with the file hash value as a parameter, thereby using the signature function 205 in the TEE 223. In operation 351, the signature function 205 is called to generate a signature of the file hash value (referred to as the first signature) using the private key assigned to the client file signing module 202 by the signing subsystem 210. In operation 324b, the signature hash function call returns the first signature to the client file signing module 202.

[0055] [Atomic Secure Transactions]

[0056] Next, the client-side file signing module 202 and the server-side file signing module 211 establish an atomic and secure transaction 330. Atomic and secure transaction 330 ensures: (a) the confidentiality of the information exchanged in the transaction; (b) the integrity of the information exchanged in the transaction; and (c) that the transaction can only conclude successfully; otherwise, the transaction will be rolled back to its initial state. In other words, the entire transaction is executed as an indivisible atomic transaction, ensuring that all actions are either completed completely successfully or not at all.

[0057] In operation 322, the client-side file signing module 202 and the server-side file signing module 211 perform mutual authentication. In operation 323, a session key is exchanged between the client-side file signing module 202 and the server-side file signing module 211. Transport Layer Security (TLS) or Secure Sockets Layer (SSL) protocols may be used, but the details of these protocols are not described in detail here.

[0058] In operation 325a, the client-side file signing module 202 transmits the file hash value and the first signature to the server-side file signing module 211. In operation 371, the server-side file signing module 211 initiates a verification function call with the file hash value and the first signature as parameters. Next, the verification function 212 verifies the first signature of the file hash using the public key corresponding to the private key assigned to the client-side file signing module 202. After successful verification, in operation 372a, the server-side file signing module 211 initiates a file signing function call with the verified file hash value as a parameter. In operation 381, the signing function 213 calculates a second signature (also called a file signature) of the file hash using the private key assigned to the client by the signing subsystem 210. In operation 372b, a file signing function call returns the second signature to the server-side file signing module 211. In operation 325 b , the second signature and the public key certificate corresponding to the client's private key (referred to as the client certificate) are then sent back to the client file signing module 202 .

[0059] [File block creation operation]

[0060] After receiving the file signature and client credentials, the client file signing module 202 forwards them to the file block construction module 203 in operation 311b. The file block construction module 203 then sends a success return value to the file source 206. The file source 206 then calls the create file block function with the file as a parameter to the file block construction module 203. In operation 312a, the file block construction module 203 then combines the file, file signature, and client credentials to generate file blocks in different formats to meet the requirements of different user systems. In operation 312b, in response to the request signature function initiated in operation 311a, the file block construction module 203 returns the file block to the file source 206.

[0061] Similar to the communication between the client file signing module 202 and the file block construction module 203, the communication between the file source 206 and the file block construction module 203 is also protected by end-to-end data confidentiality and integrity services, and also has mutual authentication of communication endpoints.

[0062] Figure 4 FIG is a flow chart of a distributed digital signature method according to an embodiment. Figure 4 In step 401, the client subsystem provides a file and calls a request signature function for the file in a rich execution environment. In step 402, the client subsystem calls a request hash function for the file in a first trusted rich execution environment. In step 403, the client subsystem responds to the request hash function by calculating a hash value for the file in the first trusted execution environment. In step 404, the client subsystem generates a first signature of the hash value in the first trusted execution environment. Next, the client subsystem establishes an atomic secure transaction 405 with a signing subsystem, which includes steps 406-409. In step 406, the client subsystem transmits the hash value and the first signature to the signing subsystem. In step 407, the signing subsystem verifies the first signature in a second trusted execution environment. In step 408, the signing subsystem generates a second signature of the hash value in the second trusted execution environment after successfully verifying the first signature. In step 409, the signing subsystem transmits the second signature to the client subsystem in a third trusted rich execution environment. In step 410 , the client subsystem responds to the request signature function and generates a file block according to the second signature of the hash value and the file in a second trusted rich execution environment.

[0063] In the aforementioned system and process, the client's file is not provided to the signature subsystem 210. Instead, the hash value of the file is given to the signature subsystem 210. The client can still obtain a digital signature, thereby protecting the privacy of the client's file.

[0064] In certain embodiments, the decentralized digital signature system 200 is implemented as a decentralized cloud-native computing system, based on guidelines established by the Cloud Native Computing Foundation (CNCF), a subsidiary of the Linux Foundation. This decentralized cloud-native computing system is designed to run containerized software modules, called applications, in isolated REEs 130 or T-REEs 120, known as container runtime environments (CREs), controlled by the Kubernetes decentralized container orchestration system. In certain embodiments, applications running in REEs do not require authentication of their authenticity and integrity by a trusted third party, such as a certification authority (CA), and are therefore considered untrusted applications 135.

[0065] In some embodiments, applications running in T-REE are certified for authenticity and integrity by a trusted third party, such as a certification authority (CA), and are therefore considered trusted general-purpose applications 125 .

[0066] In some embodiments, the container runtime environment can run on virtual machines (VMs) built on hypervisors 140 deployed on individual computers in a distributed cloud-native computing system. In this case, the general-purpose operating system running in the REE does not need to have its authenticity and integrity verified by a trusted third party. Therefore, it is considered an untrusted general-purpose operating system 134.

[0067] In the case of virtual machines, the general-purpose operating system running in T-REE has its authenticity and integrity verified by a trusted third party. Therefore, it is considered a trusted general-purpose operating system.124 Both trusted and untrusted general-purpose operating systems can be developed based on the Linux operating system, which is the foundation of Kubernetes and container runtime environments.

[0068] In some embodiments, the allocation of dedicated processors 121, dedicated memory 122, and dedicated input / output 123 is performed by hardware assist functions provided by the integrated circuit manufacturer. Examples of such functions include ARM's TrustZone TM (TZ) and Confidential Computing Architecture TM (CCA); Intel Software GuardExtension TM (SGX) and Trusted Domain Extension TM (TDX); AMD's Secure EncryptedVirtualization TM (SEV).

[0069] In some embodiments, TEE 110 is established as a protected computing environment implemented on a protected processor 111 and protected memory 112. Examples of protected processors include Trusted Platform Modules (TPMs) specified by the Trusted Computing Group (TCG) and TrustZone developed by TM Protected memory refers to a segment of the computer's physical memory that can only be accessed by the protected processor and its associated coprocessors.

[0070] In a TEE, a trusted special-purpose operating system 113 runs protected special-purpose applications 114 on a protected processor 111 and its associated coprocessors. These components reside in protected memory 112. An example of a trusted special-purpose operating system is OP-TEE Trusted OS. A trusted special-purpose operating system only supports the execution of one task at a time; multiple tasks cannot be executed simultaneously. This restriction is intended to eliminate the possibility of information leakage caused by simultaneous execution.

[0071] In some embodiments, only protected special purpose applications 114 that perform security functions are executed in the TEE. Examples of these applications include symmetric and asymmetric encryption and decryption, random number generation, and a trusted system clock.

[0072] Although the present invention has been disclosed above with reference to the embodiments, they are not intended to limit the present invention. Those skilled in the art may make slight changes and modifications without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

Claims

1. A distributed digital signature system, characterized in that: include: A client subsystem having a rich execution environment, a first trusted rich execution environment, a second trusted rich execution environment, and a first trusted execution environment; as well as The signature terminal system has a third trusted rich execution environment and a second trusted execution environment. The client subsystem is used to provide a file in the rich execution environment and call a request signature function on the file, The client subsystem is configured to call a request hash function for the file in the first trusted rich execution environment, and calculate a hash value of the file in the first trusted rich execution environment in response to the request hash function. The client subsystem is used to generate a first signature of the hash value, The client subsystem is used to establish an atomic secure transaction with the signing subsystem in the first trusted rich execution environment, and the atomic secure transaction includes: The client subsystem transmits the hash value and the first signature to the signing subsystem in the first trusted rich execution environment; verifying, by the signing subsystem, the first signature in the second trusted execution environment; When the first signature is successfully verified, the signing subsystem generates a second signature for the hash value in the second trusted execution environment; and The signing subsystem transmits the second signature to the client subsystem in the third trusted rich execution environment, The client subsystem is configured to generate a file block in the second trusted rich execution environment according to the second signature of the hash value and the file to respond to the request signature function.

2. The distributed digital signature system according to claim 1, characterized in that: The client file signing module is installed in the first trusted rich execution environment, the file block construction module is installed in the second trusted rich execution environment, and the server file signing module is installed in the third trusted rich execution environment.

3. The distributed digital signature system according to claim 2, characterized in that: The atomically secure transaction also includes: The client-side file signing module and the server-side file signing module perform mutual authentication; and The client-side file signing module and the server-side file signing module exchange session keys.

4. The distributed digital signature system according to claim 3, characterized in that: The atomically secure transaction also includes: The server-side file signing module transmits a client certificate to the client-side file signing module, wherein the client certificate is issued to the client subsystem.

5. The distributed digital signature system according to claim 4, characterized in that: The first signature of the hash value is generated according to the private key issued to the client file signing module.

6. The distributed digital signature system according to claim 5, characterized in that: The second signature of the hash value is calculated based on the private key corresponding to the client.

7. The distributed digital signature system according to claim 6, characterized in that: The client file signature module, the server file signature module, the file block construction module, the hash function and the signature function are authenticated.

8. The distributed digital signature system according to claim 1, characterized in that: The client subsystem includes general hardware, dedicated hardware and protected hardware. The general hardware is set in the rich execution environment, the dedicated hardware is set in the first trusted rich execution environment and the second trusted rich execution environment, and the protected hardware is set in the first trusted execution environment.

9. The distributed digital signature system according to claim 8, characterized in that: An untrusted general purpose operating system executes in the rich execution environment, a trusted general purpose operating system executes in the first trusted rich execution environment and the second trusted rich execution environment, and a trusted special purpose operating system executes in the first trusted execution environment.

10. The distributed digital signature system according to claim 2, characterized in that: In the signature subsystem, only the server-side file signature module communicates with the client-side file signature module in the client subsystem.

11. The distributed digital signature system according to claim 1, characterized in that: The document was not provided by this signing subsystem.

12. A distributed digital signature method, executed by a distributed digital signature system, characterized in that: The distributed digital signature method includes: The client subsystem provides the file in the rich execution environment and calls the request signature function on the file; calling, by the client subsystem, a request hash function regarding the file in the first trusted rich execution environment; calculating, by the client subsystem, a hash value of the file in the first trusted execution environment in response to the request hash function; generating, by the client subsystem, a first signature of the hash value in the first trusted execution environment; The client subsystem and the signing subsystem establish an atomic secure transaction, which includes: The client subsystem transmits the hash value and the first signature to the signing subsystem; verifying, by the signing subsystem, the first signature in a second trusted execution environment; When the first signature is successfully verified, the signing subsystem generates a second signature for the hash value in the second trusted execution environment; and transmitting, by the signing subsystem, the second signature to the client subsystem in a third trusted rich execution environment; and The client subsystem generates a file block in a second trusted rich execution environment according to the second signature of the hash value and the file to respond to the request signature function.

13. The distributed digital signature method according to claim 12, characterized in that: The client file signing module is installed in the first trusted rich execution environment, the file block construction module is installed in the second trusted rich execution environment, and the server file signing module is installed in the third trusted rich execution environment, wherein the atomic secure transaction further includes: The client-side file signing module and the server-side file signing module perform mutual authentication; and The client-side file signing module and the server-side file signing module exchange session keys.

14. The distributed digital signature method according to claim 13, wherein: The atomically secure transaction also includes: The server-side file signing module transmits the client certificate to the client-side file signing module, wherein the client certificate is issued to the client subsystem.

15. The distributed digital signature method according to claim 14, characterized in that: The first signature of the hash value is generated according to the private key issued to the client file signing module.

16. The distributed digital signature method according to claim 15, characterized in that: The second signature of the hash value is calculated based on the private key corresponding to the client.

17. The distributed digital signature method according to claim 16, characterized in that: The client file signature module, the server file signature module, the file block construction module, the hash function and the signature function are authenticated.

18. The distributed digital signature method according to claim 12, wherein: The document was not provided by this signing subsystem.

Images