Privacy-protected digital signature system and method for hashing and signing operations in a decentralized, trust-based, 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] The present disclosure generally relates to a method for applying a digital signature to an electronic file (also referred to as file signature) to authenticate the content integrity and source authenticity of the file. In particular, the present disclosure discloses the architecture of a distributed trusted computing system including a virtualized trusted execution environment instantiated on a computer network, and information processing and interexchange methods adopted by these virtualized trusted execution environments to perform digital signature operations on the electronic file while protecting the content privacy of the electronic file.

BACKGROUND ART

[0002] In the ecosystems of the Internet of Things (IoT), Software-Defined Networking (SDN) and edge-cloud computing systems, system and application software modules are generally provided by different software developers, each of which retains ownership of its own software while enabling its software to be integrated with the software of other developers, and intends to jointly deploy through the Continuous Integration and Continuous Deployment (CI / CD) process in the Development, Security and Operations (DevSecOps) lifecycle. In the aforementioned lifecycle, all system and application software modules developed by software developers cannot be deployed and executed on user systems unless authenticated by a trusted Certification Authority (CA). For example, system software needs to be authenticated before being incorporated into the secure boot process, and containerized application software needs to be notarized before being included in the online provisioning process. However, since the software is transmitted to the CA, the content of the software may be leaked.

SUMMARY OF THE INVENTION

[0003] Embodiments of the present disclosure include a customer 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 signer subsystem having a third trusted rich execution environment and a second trusted execution environment, wherein the customer subsystem is configured to provide a file and call a signature request function on the file in the rich execution environment, the customer subsystem is configured to call a hash request function on 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 customer subsystem is configured to generate a first signature of the hash, and the customer subsystem is configured to be atomic and secure together with the signer subsystem in the first trusted rich execution environment A fully configured, atomic, and secure transaction includes: the customer subsystem sending a hash and a first signature to the signer subsystem in a first trusted rich execution environment; the signer subsystem verifying the first signature in a 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 a third trusted rich execution environment, wherein the customer subsystem provides a distributed digital signature system configured to generate a file blob based on the second signature for 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, an atomic and secure transaction further includes performing mutual authentication between a file signing client module and a file signing server module, and exchanging session keys between the file signing client module and the file signing server module.

[0006] In some embodiments, an 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 the private key corresponding to the customer.

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

[0010] In some embodiments, the customer 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, an untrusted general-purpose operating system is executed in a rich execution environment, a trusted general-purpose operating system is executed in a first trusted rich execution environment and a second trusted rich execution environment, and a trusted dedicated operating system is executed in the first trusted execution environment.

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

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

[0014] On the other hand, embodiments of the present disclosure provide a distributed digital signature method comprising the steps of: a customer subsystem providing a file and calling a signature request function for the file in a rich execution environment; a customer subsystem calling 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 in response to a signature request function in a second trusted rich execution environment, wherein the atomic and secure transaction includes the customer subsystem transmitting the hash and the first signature to the signer subsystem; the signer subsystem verifying the first signature in a second trusted execution environment; the signer subsystem generating a second signature of the hash in a second trusted execution environment after successfully verifying the first signature; and the signer subsystem transmitting the second signature to the customer subsystem in a third trusted rich execution environment. [Brief explanation of the drawing]

[0015] This disclosure can be better understood by reading the following detailed description of the embodiments with reference to the following drawings.

[0016] [Figure 1]This figure shows the architecture of the customer subsystem and the signer subsystem according to one embodiment. The solid arrows in the figure indicate secure communication between the REE, T-REE, and TEE. The dashed arrows in the figure indicate the interaction between the TEE and the trusted key and certificate management system, which is used to generate the public-private key pairs that the REE, T-REE, and TEE use for secure communication. [Figure 2] This is a functional block diagram illustrating a distributed digital signature system according to one embodiment. In the diagram, functional blocks contained within rounded rectangles are provided by the customer and are assumed to be untrustworthy, while functional blocks contained 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. All communication between functional blocks (indicated by solid arrows) is protected by cryptographically strong data confidentiality, integrity services, and mutual authentication between communication endpoints. [Figure 3] This is a sequence diagram illustrating the operation between two subsystems according to one embodiment. [Figure 4] This is a flowchart showing a distributed digital signature method according to one embodiment. [Modes for carrying out the invention]

[0017] Specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings, but the embodiments described are not intended to limit the present invention, and the description of operations does not limit the order of implementation. Furthermore, any device having equivalent functionality manufactured from a structure composed of elements recombined is also included within the scope of the present invention. Note that the drawings are for illustrative purposes only and are not drawn to actual dimensions.

[0018] The terms "First," "Second," and "Third" used in this specification should be understood as being for the purpose of identifying units or data described using the same terminology, and not as indicating a specific order or sequence.

[0019] The integrity of the content and the authenticity of the origin of an electronic file can be authenticated by the digital signature of the file. This digital signature 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 to the file owner by a certification authority. Traditionally, digital hashing and private key signing operations are performed collectively within a secure computing environment called a Trusted Execution Environment (TEE), managed by a certification authority or its proxy. To perform these operations, 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 contents and confidentiality metadata of files must not be disclosed to any third party, including certification authorities. To achieve the above objective, the file owner (other than the certification authority) must calculate the hash value of the file in a trusted manner and send the hash value (not the file itself) to the certification authority via secure communication. 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 distributed file hashing and signing operation separates the calculation of the file hash value, which requires the proprietary file as input, from the calculation of the file digital signature, which requires only the file 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 proprietary files is protected.

[0021] The distributed file hash and signature operations can be used to authenticate the content integrity and origin authenticity of any electronic files, including electronic documents, program code, AI models, and datasets. Specifically, digital signatures for program code and AI models have become an indispensable step in the Development, Security, and Operations (DevSecOps) lifecycle. In the lifecycle, all systems and application software modules developed by software developers cannot be deployed and executed on user systems unless they are authenticated by a trusted certification authority.

[0022] The distributed trusted computing system disclosed in the filed utility model patent identifies 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 (REE) 130, a plurality of Trusted Rich Execution Environments (T-REE) 120, and one or more Trusted Execution Environments (TEE) 110. The REE 130 is an unprotected virtual execution environment instantiated on the hypervisor 140 on the computer, and executes unprotected and untrusted general-purpose applications 135 under the control of the untrusted general-purpose operating system 134. Common hardware (non-dedicated) includes a common processor 131, a memory 132, and input / output I / O 133, which are disposed within the REE 130 to execute the untrusted general-purpose operating system 134 and the untrusted general-purpose applications 135.

[0023] T-REE120 is a protected virtual execution environment instantiated on the hypervisor 140 on the computer, and executes the trusted general-purpose application 125. Before these trusted general-purpose applications 125 are deployed to and executed on T-REE120, their code integrity and source authenticity must be verified by a trusted third party and signed by a certificate authority (CA). Dedicated hardware including a dedicated processor 121, a memory 122, and an I / O 123 is arranged within T-REE120 so as to execute the trusted general-purpose application 125 under the control of a trusted general-purpose operating system 124 dedicated to the service T-REE120. These dedicated processor 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] TEE110 is a physical or virtual protected execution environment established in a protected area of a computer. Protected hardware including a protected processor 111 and a protected memory 112 is arranged within TEE110 so as to be inaccessible or unusable by other execution environments. This protected hardware is used to enforce resource isolation between one TEE110 and other execution environments including other TEEs, T-REE120, and REE130. TEE110 exchanges information with other execution environments via a TEE communication agent 115 that operates at a privileged computing level that isolates TEE communications from other systems and user computing tasks without going through the hypervisor 140. TEE110 executes the protected dedicated application 114 under the control of the trusted dedicated operating system 113, and performs critical operations such as cryptographic operations and a trusted system clock.

[0025] Communication 152 between T-REE120 is protected by end-to-end data confidentiality and integrity services, as well as mutual authentication of the communication endpoints. Communication 151 between REE130 and T-REE120 is protected by end-to-end data confidentiality and integrity services, as well as mutual authentication of the communication endpoints. The security services protecting these communications are performed by a protected dedicated application 114 operating within TEE110. The certificates and cryptographic keys used for protection are stored in protected memory 112 within TEE110 and managed by one of the protected dedicated applications 114 operating within the same TEE110.

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

[0027] Referring to Figure 2, the distributed digital signature system 200 comprises a customer subsystem 201 and a signer subsystem 210. This customer subsystem 201 includes REE220, T-REE221, T-REE222, and TEE223, and its structure is identical to that of Figure 1. For example, REE220 is one of REE130. T-REE221 and T-REE222 are two of T-REE120. TEE223 is one of TEE110. REE220, T-REE221, T-REE222, and TEE223 are established at the facility of the file source (also called the customer). REE220 is also called the developer REE. T-REE221 is also called the customer T-REE. T-REE222 is also called the builder T-REE. TEE223 is also known as the customer cryptography TEE.

[0028] The customer subsystem 201 constructs a file blob for a file by calculating the hash of the file and then combining the file with its file signature. The file may be program code or any digital file, and is not limited to these in this disclosure. Specifically, the signer subsystem 210 executes the file source 206 installed on REE220, the file signature client module 202 installed on T-REE221, the file blob builder module 203 installed on T-REE222, and the signature function 205 and hash function 204 installed on TEE223. The operation of each module is described in detail below.

[0029] The signer subsystem 210 includes T-REE225 and TEE226. T-REE225 is also called the server T-REE. TEE226 is also called the signer cryptograph TEE226. T-REE225 and TEE226 are established within the facilities of a Certificate Authority (CA). The signer subsystem 210 verifies the authenticity of the file signature using the secret key assigned to the file signature client module 202, and then calculates the file signature from the hash. Specifically, the signer subsystem 210 executes the file signature server module 211 installed in T-REE225 and the verification function 212 and signing function 213 installed in TEE226. A secure key storage 214 is also installed in TEE226.

[0030] Regarding the operational and trust relationships between functional modules, the distributed hash and signature system can be broken down into two trust domains (DoTs). The first domain is called the file source and file blob builder domain and consists of the file source 206 in REE220 and the file blob builder module 203 in T-REE222. The operation of modules in the first domain is under the control of the software developer (i.e., the customer) and is separated from the operation of the second domain.

[0031] The second domain is called the file hash and signature domain, and includes the 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 for implementing these modules are verified by a trusted third party and certified by an accredited Certificate Authority before being deployed and used in the domain. In the second domain, the calculation of hashes by the file signature client module 202 based on files and the calculation of file signatures by the file signature server module 211 based on verified file hashes are performed separately. Both the file signature client module 202 and the file signature server module 211 use the cryptographic functions installed in the cryptographic TEE 223 or 226 to which they belong.

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

[0033] In some embodiments, the file source 206 residing within the REE220 is an operating environment for a software developer (i.e., the customer) to provide code images. In other embodiments, the file source 206 may be a suitable software module for providing any digital files used later. All communications with the file source 206 are protected by end-to-end data confidentiality and integrity services and mutual authentication between communication endpoints, so that other modules of the system can trust the content integrity and source authenticity in their interactions with the file source 206. [File Signature Client Module]

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

[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 takes place via an atomic and secure transaction. Through this transaction, the file signing client module 202 receives a customer certificate from the file signing server module 211 that can be used to file sign and verify the file signature. The file signing client module 202 then transfers these entities to the file blob builder module 203 to combine them with the file and generate a file blob. [File Signature Server Module]

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

[0037] After successful verification, the file signature server module 211 performs a file signature calculation operation by calling the signature function 213 in the TEE226. The signature function 213 then retrieves the private key (known as the signing key) assigned to the customer 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 signed file and the public key certificate (known as the customer 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 Customer Subsystem 201 that combines files, their signatures, and customer certificates to construct file blobs of different forms, enabling deployment, verification, and use by various user systems. Because this File Blob Builder Module 203 needs to generate file blobs that are trusted by different user systems, are unaltered, and accurate, it is a component verified and authenticated by a trusted third party. 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, as well as mutual authentication of the communication endpoints. [Service workflow for privacy-protected distributed signatures]

[0040] The workflow of the distributed digital signature method is shown in the form of a sequence diagram in Figure 2. The four operations incorporated into this sequence diagram are shown below. [File signing operation]

[0041] Operation 311a is initiated by a signature request function call from file source 206 to file signing client module 202, with the file as an argument. In other words, customer subsystem 201 provides a file and calls a signature request function for this file within REE220. 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 calls the hash request function for the file in T-REE221. In operation 331, the hash of the file is computed by the hash function 204 in TEE223 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 TEE223, taking the file hash as an argument. In operation 351, the signer subsystem 210 uses the secret key assigned to the file signing client module 202 to generate a first signature on the file hash. 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, an atomic and secure transaction 330 is established by the file signing client module 202 and the file signing server module 211. The atomic and secure transaction 330 guarantees (a) the confidentiality of the content of the messages exchanged in the transaction, (b) the integrity of the content of the messages exchanged in the transaction, and (c) that the transaction can only be terminated in a successful completion state, otherwise the transaction will be rolled back to its initial state before it started. In other words, the entire transaction is executed as an indivisible atomic transaction, guaranteeing that all actions will either be completely successful or no actions will occur at all.

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

[0046] In operation 325a, the file signature client module 202 sends the file hash and the first signature to the file signature server module 211. In operation 371, the file signature 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 of the file hash using the public key corresponding to the private key assigned to the file signature client module 202. After successful verification, in operation 372a, the file signature server module 211 initiates a file signature function call with the verified file hash as an argument. In operation 381, the signature function 213 calculates the second signature (also called the file signature) of the file hash using the private key assigned to the customer by the signer subsystem 210. In operation 372b, the file signature function call returns the second signature to the file signature server module 211. In operation 325b, the second signature and the public key certificate (called the customer certificate) corresponding to the customer private key are returned to the file signature client module 202. [File blob construction operation]

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

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

[0049] Figure 4 shows a distributed digital signature method according to one embodiment. Referring to Figure 4, in step 401, the customer subsystem provides a file in the rich execution environment and calls a signature request function for the file. In step 402, the customer subsystem calls a hash request function for the file in the first trusted rich execution environment. In step 403, the customer subsystem calculates the hash of the file in the first trusted execution environment in response to the hash request function. In step 404, the customer subsystem generates a first signature of the hash in the first trusted execution environment. Next, the customer subsystem and the signer subsystem establish an atomic and secure transaction 405 including steps 406-409. In step 406, the customer subsystem sends the hash and the first signature to the signer subsystem. In step 407, the signer subsystem verifies the first signature in the 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 customer subsystem in the third trusted rich execution environment. In step 410, the customer subsystem generates a file blob in the second trusted rich execution environment in response to the signature request function, based on the second signature hash and the file.

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

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

[0052] In some embodiments, applications running within the T-REE are authenticated for their authenticity and integrity by a trusted third party, such as a certification authority (CA). Therefore, these applications are considered trusted applications 125.

[0053] In some embodiments, the container runtime environment can run 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 trusted third-party authentication. Therefore, 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 is authenticated for its authenticity and integrity by a trusted third party. Therefore, the said general-purpose operating system is considered a trusted general-purpose OS124. Both trusted and untrusted general-purpose OSs 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 a dedicated processor 121, dedicated memory 122, and dedicated I / O 123 is performed by hardware-assisted functions provided by the integrated circuit (IC) manufacturer. An example of these functions is ARM's TrustZone. TM (TZ) and Confidential Computing Architecture TM (CCA); Intel Software Guard Extension TM (SGX) and Trusted Domain Extension TM (TDX), AMD's Secure Encrypted Virtualization TM Includes (SEV).

[0056] In some embodiments, TEE110 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 TrustZone developed by ARM®. TM This includes CPU secure mode in (TZ). Protected memory is a segment of a computer's physical memory that can only be accessed by a protected processor and its associated coprocessors.

[0057] In TEE, the trusted dedicated OS 113 is used to execute a protected application 114 on the protected memory 112 in the protected processor 111 and its associated coprocessor. An example of a trusted dedicated OS is the OP·TEE trusted OS. The trusted dedicated OS supports the execution of only one task at a time and does not allow parallel execution. The purpose of this restriction is to eliminate the possibility of information leakage due to parallel execution.

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

[0059] The present invention is described in detail with reference to specific embodiments, but other embodiments are also possible. Therefore, the spirit and scope of the appended claims should not be limited to the descriptions of the embodiments provided herein. It will be apparent to those skilled in the art that various changes and modifications may be made to the structure of the present invention without departing from the scope or spirit of the invention. In view of the foregoing, the present invention is intended to include changes and variations of the present invention, as long as 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 Communications 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: Unreliable General-Purpose Operating Systems 135: Unreliable General Purpose Applications 150: Trusted Key and Certificate Management Systems 151: Communications 152: Communications 153: Communications 140: Hypervisor 200: Decentralized 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: Verification function 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 customer 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 customer subsystem is configured in the rich execution environment to provide a file and to call a signature request function on the file. The customer subsystem is configured to call a hash request function for the file in the first trusted rich execution environment, and to calculate the hash of the file in response to the hash request function in the first trusted execution environment. The customer subsystem is configured to generate the first signature of the hash, The customer subsystem is configured in the first trusted rich execution environment to establish atomic and secure transactions together with the signer subsystem. Furthermore, the atomic and secure transaction includes the customer subsystem transmitting 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 transmitting the second signature to the customer subsystem in the third trusted rich execution environment. The customer subsystem is a distributed digital signature system configured to generate a file blob in the second trusted rich execution environment based on the second signature of the hash and the file, in response to the signature request function.

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

3. The aforementioned atomic and secure transaction is The process involves performing mutual authentication between the aforementioned file signature client module and the aforementioned file signature server module, The exchange of session keys between the aforementioned file signature client module and the aforementioned file signature server module, The distributed digital signature system according to claim 2, further comprising:

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

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

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

7. The distributed digital signature system according to claim 6, wherein the file signature client module, the file signature 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. The distributed digital signature system according to 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 protective hardware is located in the first trusted execution environment.

9. The distributed digital signature system according to claim 8, wherein the untrusted general-purpose operating system is executed in the rich execution environment, the trusted general-purpose operating system is executed in the first trusted rich execution environment and the second trusted rich execution environment, and the trusted dedicated operating system is executed in the first trusted execution environment.

10. The distributed digital signature system according to claim 2, wherein communication is performed only between the file signature server module in the signer subsystem and the file signature client module in the customer subsystem.

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

12. The customer subsystem provides a file in a rich execution environment and calls a signature request function for the file, The customer subsystem, in the first trusted rich execution environment, performs the steps of calling a hash request function for the file, The customer subsystem, in a first trusted execution environment, performs the steps of calculating the hash of the file in response to the hash request function, The customer subsystem performs the steps of generating the first signature of the hash in the first trusted execution environment, The customer subsystem and the signer subsystem establish an atomic and secure transaction. The customer subsystem, in a second trust-based rich execution environment, in response to the signature request function, generates a file blob based on the second signature of the hash and the file; Equipped with, A distributed digital signature method comprising: the atomic and secure transaction being: the customer subsystem transmitting the hash and the first signature to the signer subsystem; the signer subsystem verifying the first signature in a second trusted execution environment; the signer subsystem generating a second signature of the hash in the second trusted execution environment after successfully verifying the first signature; and the signer subsystem transmitting the second signature to the customer subsystem in a third trusted rich execution environment.

13. The file signing client module is installed in the first trusted rich execution environment, the file blob builder module is installed in the second trusted rich execution environment, and the file signing server module is installed in the third trusted rich execution environment. The aforementioned atomic and secure transaction is The process involves performing mutual authentication between the aforementioned file signature client module and the aforementioned file signature server module, The exchange of session keys between the aforementioned file signature client module and the aforementioned file signature server module, A distributed digital signature method according to claim 12, further comprising:

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

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

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

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

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

Images