Privacy-preserving digital signature system and method using hash and signature operations in a distributed trusted rich execution environment

Abstract

Disclosed is a distributed trusted computing system consisting of a cluster of Trusted Rich Execution Environments (T-REEs) instantiated on a network of computers, information processing methods executed within these T-REEs, and information exchange methods used by these T-REEs to communicate with each other to perform privacy-preserving digital signature operations on electronic files. According to the present disclosure, a trusted party called a certification authority (also called a signer) can authenticate the content integrity and origin authenticity of a file submitted by a file owner (called a customer) by performing a hash operation on a T-REE instantiated on a customer computer and performing a private key signing operation on the hash value on a T-REE instantiated on the signer computer, thereby allowing the certification authority to authenticate the integrity and authenticity of the file without accessing the file's content.

Description

[Technical Field]

[0001] This disclosure generally relates to techniques for applying digital signatures to electronic files (also called file signatures) to authenticate the file's content integrity and origin authenticity. In particular, this disclosure discloses an architecture for a distributed trusted computing system that includes virtualized trusted execution environments instantiated on a network of computers, and information processing and interchange methods employed by these virtualized trusted execution environments to perform digital signature operations on electronic files while protecting the privacy of the electronic file's content. [Background technology]

[0002] In the ecosystems of Internet of Things (IoT), software-defined networks (SDN), and edge and cloud computing systems, system and application software modules are typically provided by different software developers. Each developer retains ownership of its software while ensuring that its software can be integrated with other developers' software and deployed collaboratively through a continuous integration and continuous deployment (CI / CD) process in the development, security, and operations (DevSecOps) lifecycle. In this lifecycle, all system and application software modules developed by software developers must be authenticated by a trusted certificate authority (CA) before they can be deployed and run on user systems. For example, system software must be authenticated before being incorporated into the secure boot process, and containerized application software must be notarized before being included in the online provisioning process. However, the software must be transmitted to the CA, which may expose the software's contents. Summary of the Invention

[0003] An embodiment of the present disclosure includes a client subsystem having a rich execution environment, a first trusted rich execution environment, a second trusted rich execution environment, and the first trusted execution environment; and a signer subsystem having a third trusted rich execution environment and the second trusted execution environment, wherein the client subsystem is configured to provide a file in the rich execution environment and invoke a signature request function on the file, the client subsystem is configured to invoke a hash request function on the file in the first trusted rich execution environment, and in response to the hash request function, calculate a hash of the file in the first trusted execution environment, the client subsystem is configured to generate a first signature of the hash, and the client subsystem executes atomically and securely with the signer subsystem in the first trusted rich execution environment. and the customer subsystem is configured to generate a file blob based on the second signature of the hash and the file in the second trusted rich execution environment in response to a signature request function.

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

[0005] In some embodiments, the atomic and secure transaction further includes performing mutual authentication between the file signing client module and the file signing server module, and exchanging a session key between the file signing client module and the file signing server module.

[0006] In some embodiments, the atomic and secure transaction further includes the file signing server module sending a customer certificate issued to the customer subsystem to the file signing client module.

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

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

[0009] In some embodiments, the file signing client module, the file signing server module, the file blob builder module, the hash function, and the signature function are notarized.

[0010] In some embodiments, the client subsystem includes common hardware, dedicated hardware, and protected hardware, in some embodiments, the common hardware is located in a rich execution environment, the dedicated hardware is located in a first trusted rich execution environment and a second trusted rich execution environment, and the protected hardware is located in the first trusted execution environment.

[0011] In some embodiments, the untrusted general-purpose operating system runs in a rich execution environment, the trusted general-purpose operating system runs in a first trusted rich execution environment and a second trusted rich execution environment, and the trusted-only operating system runs in the first trusted execution environment.

[0012] In some embodiments, communication occurs only between a file signing server module in the signer subsystem and a file signing client module in the customer subsystem.

[0013] In some embodiments, the file is not provided to the signer subsystem.

[0014] Meanwhile, an embodiment of the present disclosure provides a distributed digital signature method, comprising: a customer subsystem providing a file in a rich execution environment and invoking a signature request function for the file; a customer subsystem invoking a hash request function for the file in a first trusted rich execution environment; a customer subsystem calculating a hash of the file in response to the hash request function in the first trusted execution environment; a customer subsystem generating a first signature of the hash in the first trusted execution environment; a customer subsystem and a signer subsystem establishing an atomic and secure transaction; and a customer subsystem generating a file blob based on a second signature of the hash and the file in response to the signature request function in a second trusted rich execution environment, wherein the atomic and secure transaction includes the customer subsystem sending the hash and the first signature to the signer subsystem; the signer subsystem verifying the first signature in the second trusted execution environment; and after the signer subsystem successfully verifies the first signature, generating a second signature of the hash in the second trusted execution environment; and the signer subsystem sending the second signature to the customer subsystem in a third trusted rich execution environment. [Brief explanation of the drawings]

[0015] The present disclosure can be more fully understood from the following detailed description of the embodiments, when read in conjunction with the following drawings, in which:

[0016] [Figure 1]This diagram illustrates the architecture of the Customer Subsystem and Signer Subsystem in one embodiment. The solid arrows in the diagram indicate secure communication between the REE, T-REE, and TEE. The dashed arrows in the diagram indicate interaction between the TEE and a trusted key and certificate management system to generate public-private key pairs used by the REE, T-REE, and TEE for secure communication. [Figure 2] Figure 1 is a functional block diagram illustrating a distributed digital signature system according to one embodiment. Functional blocks within rounded rectangles are provided by customers and are assumed to be untrusted, while those 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 origin authenticity. All communications between functional blocks (denoted by solid arrows) are protected by cryptographically strong data confidentiality and integrity services and mutual authentication between the communicating endpoints. [Figure 3] FIG. 2 is a sequence diagram illustrating operations between two subsystems according to one embodiment. [Figure 4] 1 is a flowchart illustrating a distributed digital signature method according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0017] Specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings, but the described embodiments do not limit the present invention, and the description of the operations does not limit the order of execution. In addition, any device having equivalent functions manufactured from a structure constructed by recombining elements is also intended to be included within the scope of the present invention. Note that the drawings are merely illustrative and are not drawn to actual scale.

[0018] It should be understood that the terms "first," "second," and "third" used in the specification are intended to distinguish between units or data described with the same term, and do not indicate a particular order or hierarchy.

[0019] The content integrity and origin authenticity of an electronic file can be verified by the file's digital signature, which is generated by first calculating a digital hash value of the file's content and then performing a private-key signing operation on the digital hash value using a private key issued by a certification authority to the file owner. Conventionally, 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 proxy. To perform the operation, the file owner must submit the electronic file to the certification authority. Therefore, the content of the electronic file is disclosed to the certification authority or its proxy.

[0020] To protect the information privacy of electronic files, the file's contents and confidentiality metadata must not be disclosed to any third party, including the certification authority. To achieve this goal, the file owner (other than the certification authority) must compute a hash value for the file in a trusted manner and transmit the hash value (but not the file itself) to the certification authority via secure communication. After authenticating the origin of the hash value, the certification authority computes a digital signature for the hash value using a private key assigned to the file owner. The distributed file hash and signature operation separates the computation of the file's hash value, which requires the private file as input, from the computation of the file's digital signature, which requires only the file's hash value as input. By performing these two operations separately in each Trusted-Rich Execution Environment (T-REE) that provides information isolation protection, the content privacy of the private file is protected.

[0021] The distributed file hashing and signing operations can be used to authenticate the content integrity and origin authenticity of any electronic file, including electronic documents, program code, AI models, and datasets. Specifically, digital signatures for program code and AI models have become an essential step in the development, security, and operations (DevSecOps) lifecycle. In this lifecycle, all system and application software modules developed by software developers must be certified by a trusted certification authority before they can be deployed and run on user systems.

[0022] The distributed trusted computing system disclosed in the utility model patent application specifies the system architecture shown in Figure 1. The distributed digital signature system 100 includes a client subsystem 101. The client subsystem 101 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. The REE 130 is an unsecured virtual execution environment instantiated on a hypervisor 140 on a computer, and executes unsecured and untrusted general-purpose applications 135 under the control of an untrusted general-purpose operating system 134. Common hardware (non-dedicated) includes a common processor 131, memory 132, and input / output (I / O) 133, and is located within the REE 130 to execute the untrusted general-purpose operating system 134 and the untrusted general-purpose applications 135.

[0023] The T-REE 120 is a protected virtual execution environment instantiated on a hypervisor 140 on a computer, and executes trusted general-purpose applications 125. Before these trusted general-purpose applications 125 are deployed and executed on the T-REE 120, their code integrity and origin authenticity must be verified by a trusted third party and signed by a Certificate Authority (CA). Dedicated hardware, including dedicated processors 121, memory 122, and I·O 123, is deployed within the T-REE 120 to execute the trusted general-purpose applications 125 under the control of a trusted general-purpose operating system 124 dedicated to the service T-REE 120. These dedicated processors 121, memory 122, and I·O 123 are assigned to a specific T-REE via computer hardware that enforces resource isolation between execution environments.

[0024] The TEE 110 is a physical or virtual protected execution environment established within a protected domain of a computer. Protected hardware, including a protected processor 111 and protected memory 112, is located within the TEE 110 so that it cannot be accessed or used by other execution environments. This protected hardware is used to enforce resource isolation between one TEE 110 and other execution environments, including other TEEs, the T-REE 120, and the REE 130. The TEE 110 communicates with other execution environments via a TEE communication agent 115, which operates at a privileged computing level that isolates TEE communications from other system and user computing tasks, without going through a hypervisor 140. The TEE 110 runs protected-only applications 114 under the control of a trusted-only operating system 113 and performs critical operations such as cryptographic operations and a trusted system clock.

[0025] Communications 152 between T-REEs 120 are protected by end-to-end data confidentiality and integrity services and mutual authentication of the communication endpoints. Communications 151 between the REE 130 and the T-REE 120 are protected by end-to-end data confidentiality and integrity services and mutual authentication of the communication endpoints. The security services protecting these communications are performed by a protected-only application 114 operating within the TEE 110. The certificates and cryptographic keys used for protection are stored in protected memory 112 within the TEE 110 and are managed by one of the protected-only applications 114 operating within the same TEE 110.

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

[0027] Referring to Figure 2, a distributed digital signature system 200 comprises a customer subsystem 201 and a signer subsystem 210. This customer subsystem 201 includes a REE 220, a T-REE 221, a T-REE 222, and a TEE 223, and its structure is identical to that of Figure 1. For example, REE 220 is one of the REEs 130. T-REE 221 and T-REE 222 are two of the T-REEs 120. TEE 223 is one of the TEEs 110. REE 220, T-REE 221, T-REE 222, and TEE 223 are established at the premises of a file source (also called a customer). REE 220 is also called the developer REE. T-REE 221 is also called the customer T-REE. T-REE 222 is also called the builder T-REE. The TEE 223 is also called the Customer Crypto TEE.

[0028] The client subsystem 201 calculates a hash for a file and then combines the file with its file signature to construct a file blob for the file. The file may be program code or any digital file, and is not limited in this disclosure. Specifically, the signer subsystem 210 executes the file source 206 installed in the REE 220, the file signature client module 202 installed in the T-REE 221, the file blob builder module 203 installed in the T-REE 222, and the signature function 205 and hash function 204 installed in the TEE 223. The operation of each module is described in detail below.

[0029] The signer subsystem 210 includes a T-REE 225 and a TEE 226. The T-REE 225 is also referred to as a server T-REE. The TEE 226 is also referred to as a signer cryptographic TEE 226. The T-REE 225 and the TEE 226 are established within the premises of a certification authority (CA). The signer subsystem 210 calculates a file signature from a hash after verifying its authenticity using a private key assigned to the file signature client module 202. Specifically, the signer subsystem 210 executes a file signature server module 211 installed in the T-REE 225 and a verification function 212 and a signing function 213 installed in the TEE 226. A secure key storage 214 is also installed in the TEE 226.

[0030] In terms of operational and trust relationships between functional modules, the distributed hash and signature system can be decomposed into two Domains of Trust (DoT). The first domain is called the File Source and File Blob Builder domain and consists of the File Source 206 in the REE 220 and the File Blob Builder module 203 in the T-REE 222. The operation of the modules in the first domain is under the control of the software developer (i.e., the customer) and is isolated from the operation of the second domain.

[0031] The second domain is called the file hash and signature domain, which includes file signature client module 202, hash function 204, signature function 205, file signature server module 211, verification function 212, and signature function 213. The operation of the modules in the second domain is under the control of a certificate authority (CA) and is separate from the operation of the first domain. The second domain is a trusted domain. All programs implementing these modules are verified by a trusted third party and authenticated by an accredited certificate authority before being deployed and used in the domain. In the second domain, the file signature client module 202 calculates a hash based on a file and the file signature server module 211 calculates a file signature based on the verified file hash, independently. Both file signature client module 202 and file signature server module 211 use cryptographic functions installed in their respective cryptographic TEEs 223 or 226.

[0032] The following paragraphs identify the functions of the components shown in Figure 2 and their interactions. [File Source]

[0033] In some embodiments, the file source 206 residing in the REE 220 is a software developer's (i.e., customer's) operating environment for providing code images. In other embodiments, the file source 206 may be any suitable software module for providing any digital file used below. To ensure that other modules in the system can trust the content integrity and origin authenticity in their interactions with the file source 206, all communications with said component are protected by end-to-end data confidentiality and integrity services and mutual authentication between communication endpoints. [File Signature Client Module]

[0034] In some embodiments, file signing client module 202 is the only module in the second trust domain with which file source 206 and file blob builder module 203 interact. The file signing client module receives the file from file source 206 and performs a file hash calculation operation by invoking hash function 204 in TEE 223 to generate a file hash. The file signing client module further generates a client-signed file hash from the file hash by invoking signature function 205 in TEE 223 using a private key assigned to file signing client module 202 by a CA.

[0035] The file signing client module 202 is also the only module in the signer subsystem 210 that can interact with the file signing server module 211. This interaction occurs via atomic and secure transactions. Through these transactions, the file signing client module 202 receives from the file signing server module 211 a file signature for the file and a customer certificate that can be used to verify the file signature. The file signing client module 202 then forwards these entities to the file blob builder module 203 for combining with the file to create a file blob. [File Signature Server Module]

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

[0037] After successful verification, the file signing server module 211 performs the file signature calculation operation by calling the signing function 213 in the TEE 226. The signing function 213 then retrieves the customer-assigned private key (known as the signing key) from the secure key storage 214 and signs the verified file hash using the signing key.

[0038] After completing the file signature calculation operation, the file signature server module 211 sends the file signature and the public key certificate corresponding to the private key assigned to the customer (known as the customer certificate) to the file signature client module 202 via an atomic and secure transaction. [File Blob Builder Module]

[0039] The file blob builder module 203 is a component within the client subsystem 201 that combines a file, its signature, and a client certificate to build different types of file blobs, enabling them to be deployed, verified, and used by various user systems. The file blob builder module 203 is a component verified and certified by a trusted third party because it must be trusted by various user systems to generate unaltered and accurate file blobs. Communication between the file blob builder module 203 and the file signature client module 202 is protected by end-to-end data confidentiality and integrity services and mutual authentication of the communication endpoints. [Service workflow for privacy-preserving distributed signatures]

[0040] The workflow of the distributed digital signature method is shown in the form of a sequence diagram in Figure 2. Below we show the four operations incorporated in this sequence diagram. [File Signature Operations]

[0041] Operation 311a begins with a file-with-signature function call from file source 206 to file signing client module 202, with the file as an argument: client subsystem 201 provides the file and invokes the file-with-signature function for this file in REE 220. The function call initiates the distributed file hashing and file signing process, which ends with the return of a signed file blob from file blob builder module 203. [File hash calculation operation]

[0042] In response to the signature request function, the file signature client module 202 performs two operations 321a and 324a. In operation 321a, the file signature client module invokes a hash request function for the file in the T-REE 221. In operation 331, a hash of the file is calculated by the hash function 204 in the TEE 223 in response to the hash request function. In operation 321b, the hash request function returns the hash of the file (also called the file hash) to the file signature client module 202.

[0043] In operation 324a, the file signing client module 202 initiates a signature hash function call to the signing function 205 in the TEE 223 with the file hash as an argument. In operation 351, a first signature is generated for the file hash using a private key assigned to the file signing client module 202 by the signer subsystem 210. In operation 324b, the signature hash function call returns the first signature to the file signing client module 202. [Atomic and secure transactions]

[0044] Next, atomic and secure transaction 330 is established by file signing client module 202 and file signing server module 211. Atomic and secure transaction 330 guarantees (a) confidentiality of the contents of messages exchanged in the transaction, (b) integrity of the contents of messages exchanged in the transaction, and (c) that the transaction can only end in a successful completion state; otherwise, the transaction is rolled back to its initial state before it began. In other words, the entire transaction is executed as an indivisible atomic transaction, ensuring that either all actions are completely successful or no actions occur at all.

[0045] In operation 322, mutual authentication is performed between file signing client module 202 and file signing server module 211. In operation 323, a session key is exchanged between file signing client module 202 and file signing server module 211. Transport Layer Security (TLS) or Secure Sockets Layer (SSL) protocols may be employed, although the details of the protocols will not be detailed herein.

[0046] In operation 325a, the file signing client module 202 sends the file hash and the first signature to the file signing server module 211. In operation 371, the file signing server module 211 initiates a verification function call with the file hash and the first signature as arguments. The verification function 212 verifies the first signature on the file hash using a public key corresponding to the private key assigned to the file signing client module 202. After the verification is successful, in operation 372a, the file signing server module 211 initiates a file signing function call with the verified file hash as an argument. In operation 381, the signing function 213 calculates a second signature (also referred to as a file signature) on the file hash using a private key assigned to the customer by the signer subsystem 210. In operation 372b, the file signing function call returns the second signature to the file signing server module 211. In operation 325b, the second signature and a public key certificate (referred to as a customer certificate) corresponding to the customer private key are returned to the file signing client module 202. [File Blob Construction Operation]

[0047] After receiving the file signature and customer certificate, in operation 311b, file signature client module 202 forwards them to file blob builder module 203. File blob builder module 203 then sends a return variable indicating success to file source 206. File source 206 then initiates a file blob establishment function call to file blob builder module 203 with the file as an argument. In operation 312a, file blob builder module 203 then combines the file with the file signature and customer certificate to generate file blobs of different forms according to the requirements of different user systems. In operation 312b, file blob builder module 203 returns the file blob to file source 206 in response to the signature request function initiated in operation 311a.

[0048] Similar to communication between the file signing client module 203 and the file blob builder module 203, communication between the file source 206 and the file blob builder module 203 is protected by end-to-end data confidentiality and integrity services and mutual authentication of the communication endpoints.

[0049] FIG. 4 illustrates a distributed digital signature method according to one embodiment. Referring to FIG. 4, in step 401, a client subsystem provides a file in a rich execution environment and invokes a signature request function for the file. In step 402, the client subsystem invokes a hash request function for the file in a first trusted execution environment. In step 403, the client subsystem calculates a hash of the file in the first trusted execution environment in response to the hash request function. In step 404, the client subsystem generates a first signature of the hash in the first trusted execution environment. The client subsystem and the signer subsystem then establish an atomic and secure transaction 405, which includes steps 406-409. In step 406, the client subsystem sends the hash and the first signature to the signer subsystem. In step 407, the signer subsystem verifies the first signature in a second trusted execution environment. In step 408, after successfully verifying the first signature, the signer subsystem generates a second signature of the hash in the second trusted execution environment. In step 409, the signer subsystem sends the second signature to the client subsystem in the third trusted rich execution environment. In step 410, the client subsystem generates a file blob based on the second signature of the hash and the file in response to the signature request function in the second trusted rich execution environment.

[0050] In the above-described system and process, the customer's file is not provided to the signer subsystem 210. Instead, the hash value of the file is provided to the signer subsystem 210. The customer can still obtain a digital signature, thereby protecting the privacy of the customer's file.

[0051] In some embodiments, the distributed digital signature system 100 is realized as a distributed cloud-native computing system implemented according to guidelines established by the Cloud Native Computing Foundation (CNCF), a subsidiary of the Linux Foundation. The distributed cloud-native computing system is established to run containerized software modules, known as applications, within isolated REEs 130 or T-REEs 120 as container runtime environments under the control of a Kubernetes distributed container orchestration system. In some embodiments, applications running within the REEs do not need to be authenticated for authenticity and integrity by a trusted third party, such as a Certificate Authority (CA). As such, these applications are considered untrusted applications 135.

[0052] In some embodiments, applications running within a T-REE are certified for authenticity and integrity by a trusted third party, such as a Certificate Authority (CA), and are therefore considered trusted applications 125.

[0053] In some embodiments, a container runtime environment can be executed within a virtual machine (VM) established on a hypervisor 140 deployed on each computer in the distributed cloud-native computing system. In this case, the general-purpose operating system (OS) running within the REE does not need to be authenticated for its authenticity and integrity by a trusted third-party certificate. As such, the general-purpose operating system is considered an untrusted general-purpose OS 134.

[0054] When a VM is used, the general-purpose operating system (OS) running within the T-REE has its authenticity and integrity certified by a trusted third party, and is therefore considered a trusted general-purpose OS 124. Both the trusted and untrusted general-purpose OS can be developed based on the Linux operating system on which the Kubernetes and container runtime environments are established.

[0055] In some embodiments, the allocation of dedicated processors 121, dedicated memory 122, and dedicated I·O 123 is performed by hardware-assisted functions provided by integrated circuit (IC) manufacturers. Examples of these functions include ARM TrustZone TM (TZ) and Confidential Computing Architecture TM (CCA); Intel's Software Guard Extension TM (SGX) and Trusted Domain Extension TM (TDX), AMD's Secure Encrypted Virtualization TM (SEV) is included.

[0056] In some embodiments, the TEE 110 is established as a protected computing environment implemented in a protected processor 111 and a protected memory 112. Examples of protected processors include the Trusted Platform Module (TPM) defined by the Trusted Computing Group (TCG) and the TrustZone developed by ARM®. TM This includes CPU secure mode in (TZ). Protected memory is a segment of a computer's physical memory that is accessible only to the protected processor and its associated coprocessors.

[0057] In a TEE, a trusted-only OS 113 is used by the protected processor 111 and its associated coprocessors to run protected applications 114 on the protected memory 112. An example of a trusted-only OS is the OP·TEE trusted OS. A trusted-only OS only supports the execution of a single task at a time and does not allow concurrent execution. The purpose of this restriction is to eliminate the possibility of information leakage due to concurrent execution.

[0058] In some embodiments, only protected applications 114 that perform security functions run within the TEE. Examples of these applications include symmetric and asymmetric encryption and decryption, random number generation, and a trusted system clock.

[0059] Although the present invention has been described in detail with reference to specific embodiments, other embodiments are possible. Therefore, the spirit and scope of the appended claims should not be limited to the description of the embodiments set forth herein. It will be apparent to those skilled in the art that various modifications and variations can be made to the structure of the present invention without departing from the scope or spirit of the invention. In view of the foregoing, it is intended that the present invention cover modifications and variations of the present invention provided they fall within the scope of the following claims. [Explanation of symbols]

[0060] 111: Protected processor 112: Protected memory 113: Trusted dedicated OS 114: Protected Applications 115: TEE communication agent 121: Dedicated processor 122: Dedicated memory 123: Dedicated I / O 125: Trusted general-purpose applications 131: Common Processor 132: Memory 133: Input / Output I / O 134: Untrusted General-Purpose Operating System 135: Untrusted general-purpose applications 150: Trusted Key and Certificate Management System 151:Communication 152:Communication 153:Communication 140: Hypervisor 200: Distributed Digital Signature System 201: Customer Subsystem 202: File signing client 203: File Blob Builder 204: Hash function 205: Signature Function 206: File Source 210: Signer Subsystem 211: File signature server module 212: Validation functions 213: Signature Function 214: Secure Key Storage 220:REE 221:T-REE 222:T-REE 223:TEE 225:T-REE 226:TEE 401~410: Process

Claims

1. 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; a signer subsystem having a third trusted rich execution environment and a second trusted execution environment; Equipped with the client subsystem is configured to provide a file in the rich execution environment and to invoke a signature request function for the file; the client subsystem is configured to invoke a hash request function for the file in the first trusted rich execution environment, and to calculate a hash of the file in the first trusted execution environment in response to the hash request function; the client subsystem is configured to generate a first signature of the hash; the customer subsystem is arranged to establish atomic and secure transactions with the signer subsystem in the first trusted rich execution environment; and the atomic and secure transaction includes the customer subsystem sending the hash and the first signature to the signer subsystem in the first trusted-rich execution environment, the signer subsystem verifying the first signature in the second trusted execution environment, the signer subsystem generating a second signature for the hash in the second trusted execution environment after successfully verifying the first signature, and the signer subsystem sending the second signature to the customer subsystem in the third trusted-rich execution environment; The customer subsystem is configured to generate a file blob based on the second signature of the hash and the file in the second trusted rich execution environment in response to the signature request function.

2. 2. The distributed digital signature system of claim 1, wherein a file signature client module is installed in the first trusted rich execution environment, a file blob builder module is installed in the second trusted rich execution environment, and a file signature server module is installed in the third trusted rich execution environment.

3. The atomic and secure transaction is performing mutual authentication between the file signing client module and the file signing server module; exchanging a session key between the file signing client module and the file signing server module; The distributed digital signature system of claim 2 further comprising:

4. The atomic and secure transaction is The distributed digital signature system of claim 3 , further comprising the file signing server module sending a customer certificate issued to the customer subsystem to the file signing client module.

5. The distributed digital signature system of claim 4 , wherein the first signature of the hash is generated based on a private key issued to the file signing client module.

6. 6. The distributed digital signature system of claim 5, wherein the second signature of the hash is calculated based on a private key corresponding to a customer.

7. 7. The distributed digital signature system of claim 6, wherein the file signing client module, the file signing server module, the file blob builder module, the hash function, and the signature function are notarized.

8. the customer subsystem includes common hardware, dedicated hardware, and protected hardware; 2. The distributed digital signature system of claim 1, wherein the common hardware is located in the rich execution environment, the dedicated hardware is located in the first trusted rich execution environment and the second trusted rich execution environment, and the protected hardware is located in the first trusted execution environment.

9. 9. The distributed digital signature system of claim 8, wherein a non-trusted general-purpose operating system runs in the rich execution environment, a trusted general-purpose operating system runs in the first trusted rich execution environment and the second trusted rich execution environment, and a trusted-only operating system runs in the first trusted execution environment.

10. 3. The distributed digital signature system of claim 2, wherein communication occurs only between the file signing server module in the signer subsystem and the file signing client module in the customer subsystem.

11. The distributed digital signature system of claim 1 , wherein the file is not provided to the signer subsystem.

12. a client subsystem providing a file in a rich execution environment and invoking a signature request function for the file; the client subsystem invoking a hash request function for the file in a first trusted rich execution environment; the client subsystem calculating a hash of the file in a first trusted execution environment in response to the hash request function; generating a first signature of the hash by the client subsystem in the first trusted execution environment; said customer subsystem and signer subsystem establishing an atomic and secure transaction; generating, in the client subsystem's second trusted rich execution environment, a file blob based on a second signature of the hash and the file in response to the signature request function; Equipped with 10. The distributed digital signature method of claim 1, wherein the atomic and secure transaction includes the customer subsystem sending the hash and the first signature to the signer subsystem; the signer subsystem verifying the first signature in a second trusted execution environment; after the signer subsystem successfully verifies the first signature, generating a second signature of the hash in the second trusted execution environment; and the signer subsystem sending the second signature to the customer subsystem in a third trusted rich execution environment.

13. a file signing client module installed in the first trusted rich execution environment, a file blob builder module installed in the second trusted rich execution environment, and a file signing server module installed in the third trusted rich execution environment; The atomic and secure transaction is performing mutual authentication between the file signing client module and the file signing server module; exchanging a session key between the file signing client module and the file signing server module; The distributed digital signature method of claim 12, further comprising:

14. The atomic and secure transaction is 14. The distributed digital signature method of claim 13, further comprising the file signing server module sending a customer certificate issued to the customer subsystem to the file signing client module.

15. 15. The distributed digital signature method of claim 14, wherein the first signature of the hash is generated based on a private key issued to the file signing client module.

16. 16. The distributed digital signature method of claim 15, wherein the second signature of the hash is calculated based on a private key corresponding to a customer.

17. 17. The distributed digital signature method of claim 16, wherein the file signing client module, the file signing server module, the file blob builder module, the hash function, and the signature function are notarized.

18. 13. The distributed digital signature method of claim 12, wherein the file is not provided to the signer subsystem.

Images