Method for issuing credential of trusted execution environment using smart contract

Abstract

A method for processing personal information using a smart contract-based trusted execution environment, according to an embodiment of the present invention, comprises the steps of: by a data processing platform server, generating a trusted execution environment including a data processing code, in response to a data processing request received from a data processing request terminal according to a smart contract distributed on a blockchain; by the trusted execution environment, decrypting first data acquired from a data generation terminal; by the trusted execution environment, processing the decrypted first data on the basis of the data processing code so as to generate a data processing result; and by the trusted execution environment, providing the data processing result to the data processing request terminal according to the smart contract.

Description

A method for issuing credentials in a trusted execution environment using smart contracts.

[0001] The present invention relates to a method for issuing credentials in a trusted execution environment using a smart contract.

[0002] Blockchain: A blockchain is a decentralized, distributed system. Decentralization means that there is no central authority to perform its functions, but rather multiple participants work together. Blockchain networks are fundamentally P2P networks, utilizing consensus algorithms to create blocks through a common process. The use of hashes is crucial to blockchains, and the combination of hashes and the ability for multiple participants to process the same data in the same way prevents data tampering.

[0003] A smart contract is a set of programming codes that automates the execution of a contract based on a blockchain, which addresses assets and trust. The code written by the developer resides in a single block on the blockchain, and users can access the smart contract address to execute the code.

[0004] The reason it is called a smart contract is because, like general transaction contents, the code contents of a smart contract are included in the block information, so they cannot be manipulated, and since the program operates according to the coded contents, it is suitable for working on set contents such as a contract.

[0005] Smart contracts written on Ethereum utilize the Solidity language and operate on the EVM. The virtual machine specifically designed to execute Ethereum smart contracts is called the Ethereum Virtual Machine (EVM), and Ethereum smart contracts are written in languages ​​such as Solidity and Viper, and are widely applied and used in the blockchain field. There are several monitoring web applications that provide information about smart contracts on the Ethereum network. The most representative examples include Ethereum's own Etherescan, Alvio, which provides information in a visual format, and Remix, a Solidity IDE.

[0006] Meanwhile, Decentralized Identity (DID) is a scalable, self-sovereign identity verification system that operates autonomously in the market without a central registration authority using a distributed ledger. It is a technology approved as a new web standard by the World Wide Web Consortium (W3C), which sets Internet standards.

[0007] DID gives individuals control over their personal information, enabling them to achieve self-sovereign identity (SSI). It also allows individuals to verify their identity without exposing their personal information. Users can then save a Verifiable Credential (VC) issued by a certification authority on their smartphones, and then select and submit only the information they need when identity verification or certification is required.

[0008] This type of decentralized identity authentication is a method in which the owner of the DID is personally created and recorded, and when an external request is made, the owner of the DID is proven to be the owner using a secret key. However, since the identity of the owner of the DID is never proven, it is highly anonymous and therefore requires a separate certificate issued by a Certificate Authority (CA) to authenticate the owner's identity.

[0009] The technical task of the present invention is to provide a method for issuing credentials in a trusted execution environment using a smart contract that implements distributed identity authentication to realize self-sovereign identity.

[0010] In addition, the technical task to be achieved by the present invention is to provide a method for issuing credentials in a trusted execution environment using a smart contract that can ensure reliable issuance of credentials without the intervention of a separate certification authority.

[0011] A method for issuing a credential of a trusted execution environment using a smart contract according to an embodiment of the present invention includes a step in which a credential platform server generates a trusted execution environment including a credential issuer in response to a request for issuing a credential for a second client terminal received from a first client terminal according to a smart contract distributed on a blockchain, a step in which the trusted execution environment verifies identification information and a first encryption key of the second client terminal, and a step in which the trusted execution environment issues a credential for the second client terminal.

[0012] According to an embodiment, the request for issuing the credential may include a first credential for the second client terminal issued by the first client terminal, the identification information, the first encryption key, and an authentication method of the first credential.

[0013] According to an embodiment, the verifying step may include a step in which the trusted execution environment transmits a verification participation request of the second client terminal to a verification target address corresponding to the identification information included in the credential issuance request, and a step in which the trusted execution environment determines the credential issuance request to be legitimate when a valid verification participation of the second client terminal is received from the verification target address.

[0014] In an embodiment, the step of determining may cause the trusted execution environment to be terminated according to the smart contract if the valid verification participation is not received within a preset expiration date.

[0015] According to an embodiment, the step of determining may determine that the first credential is valid if a valid verification participation of the second client terminal is provided from the verification target address.

[0016] According to an embodiment, the step of determining may determine that the request for issuance of the certificate is valid if the electronic signature information based on the first encryption key provided from the address to be verified is determined to be valid.

[0017] According to an embodiment, the step of issuing the credential may include the step of generating a Decentralized Identity (DID) of the second client terminal corresponding to the first credential, and the step of generating a second credential that certifies that the Decentralized ID corresponding to the first credential has been validly generated by the credential issuer.

[0018] According to an embodiment, the step of issuing the credential may further include the step of generating a hash value for the distributed ID, generating a transaction including the hash value, and recording the transaction on the blockchain.

[0019] According to an embodiment, the step of issuing the credential may further include the step of generating a hash value for the first credential, generating a transaction including the hash value, and recording the transaction on the blockchain.

[0020] According to an embodiment, the step of issuing the credential may further include the step of generating a hash value for the second credential, generating a transaction including the hash value, and recording the transaction on the blockchain.

[0021] According to an embodiment, the step of creating the trusted execution environment may include a step of creating a primitive trusted execution environment, and a step of creating the trusted execution environment including the credential issuer based on the primitive trusted execution environment in response to the credential issuance request.

[0022] According to an embodiment, the step of creating the raw trusted execution environment may include creating a first hash value of a raw image file that serves as the basis for creating the raw trusted execution environment, comparing whether the first hash value and the second hash value of the raw image file distributed on the blockchain match each other, and if they do, guaranteeing the originality of the raw trusted execution environment.

[0023] According to an embodiment, the step of creating the trusted execution environment may include creating a first image file of the trusted execution environment, creating a hash value for the first image file, and creating a transaction including the hash value and recording the transaction on the blockchain.

[0024] According to an embodiment, the method for issuing credentials of a trusted execution environment using the smart contract may further include a step of destroying the trusted execution environment according to the smart contract when a preset condition is satisfied based on the request for issuing the credentials.

[0025] According to an embodiment, the step of destroying according to the smart contract may include the step of executing a destroy command, and the step of deleting the trusted execution environment including the credential issuance request, the credential issuer, and the second credential.

[0026] According to an embodiment, the step of executing the destroy command may include executing the destroy command, generating a flag indicating execution of the destroy command, and then generating a transaction including the flag and recording the transaction on the blockchain.

[0027] In some embodiments, the trusted execution environment may be a virtual execution environment.

[0028] According to another embodiment of the present invention, a computer-readable recording medium is a computer-readable storage medium storing one or more programs, wherein the one or more programs are configured to be executed by one or more processors of an electronic device, and the one or more programs may include instructions for performing a method for issuing credentials of a trusted execution environment using the smart contract.

[0029] According to another embodiment of the present invention, a credential platform server may include a step of generating a trusted execution environment including a credential issuer in response to a credential issuance request for a second client terminal received from a first client terminal according to a smart contract deployed on a blockchain; a step of transmitting a verification participation request to the second client terminal to verify identification information and a first encryption key of the second client terminal; a step of providing verification participation by the second client terminal in response to the verification participation request; and a step of issuing a credential to the second client terminal by the trusted execution environment.

[0030] According to an embodiment, the step of providing the verification participation may include authenticating the identification of the user of the second client terminal in response to the verification participation request and receiving an electronic signature from the user.

[0031] According to a method for issuing credentials of a trusted execution environment using a smart contract according to an embodiment of the present invention, the trusted execution environment verifies the relationship between an issuer and a holder (VC) of credentials according to a smart contract, and records this on a blockchain to authenticate it, thereby omitting an authentication process by a separate authentication authority.

[0032] In addition, according to the method for issuing credentials of a trusted execution environment using a smart contract according to an embodiment of the present invention, the trusted execution environment only verifies the user's identity information when verifying a request for issuing credentials and does not expose it to the outside, thereby maintaining the anonymity of the distributed ID, thereby allowing one user to own multiple distributed IDs.

[0033] In addition, according to the method for issuing credentials of a trusted execution environment using a smart contract according to an embodiment of the present invention, an external entity can determine forgery, alteration, authenticity, etc. of credentials stored in a client terminal by a simple method of performing verification of a transaction recorded in a blockchain.

[0034] FIG. 1 is a schematic block diagram of a credential issuance system of a trusted execution environment using a smart contract according to an embodiment of the present invention.

[0035] FIGS. 2A to 2C are diagrams for explaining a credential issuance system of a trusted execution environment using a smart contract according to an embodiment of the present invention.

[0036] FIG. 3 is a diagram for explaining a smart contract according to an embodiment of the present invention.

[0037] Figure 4 is a flowchart illustrating a method for issuing credentials in a trusted execution environment using a smart contract according to an embodiment of the present invention.

[0038] The advantages and features of the present invention, and the methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided solely to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the present invention, and the present invention is defined solely by the scope of the claims.

[0039] The terminology used herein is for the purpose of describing embodiments only and is not intended to limit the present invention. In this specification, the singular also includes the plural unless specifically stated otherwise. As used herein, the terms "comprises" and / or "comprising" do not exclude the presence or addition of one or more other components in addition to the mentioned components. Like reference numerals refer to like components throughout the specification, and "and / or" includes each and any combination of one or more of the mentioned components. Although "first", "second", etc. are used to describe various components, these components are not limited by these terms. These terms are only used to distinguish one component from another. Therefore, it should be understood that a first component mentioned below may also be a second component within the technical spirit of the present invention.

[0040] Unless otherwise defined, all terms (including technical and scientific terms) used herein may be used in their common sense to those skilled in the art to which the present invention pertains. Furthermore, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless explicitly and specifically defined otherwise.

[0041] FIG. 1 is a schematic block diagram of a credential issuance system of a trusted execution environment using a smart contract according to an embodiment of the present invention.

[0042] Referring to FIG. 1, a credential issuance system (10) of a trusted execution environment using a smart contract includes a credential platform server (100), a first client terminal (200), and a second client terminal (300).

[0043] The credential platform server (100) can host an online network and is a network addressable device, and can verify the relationship between the first client terminal (200), which is the issuer of the first credential, and the owner (Holder) of the first credential according to a smart contract.

[0044] The credential platform server (100) can perform a series of processes such as creation, distribution, execution, and termination of a smart contract on a blockchain through the credential platform, and can create a smart contract for issuing a credential and distribute it on the blockchain. The smart contract for issuing a credential is an electronic contract that is automatically concluded when preset conditions are satisfied on the blockchain, and the credential platform server (100) can create a smart contract that records a series of contractual contents related to credentials, such as issuance, verification, and destruction of credentials, and distribute it on the blockchain. However, the present invention is not limited thereto, and the credential platform server (100) can also perform actions according to the contents of the smart contract as a participant that executes a smart contract distributed by another entity.

[0045] Smart contracts are recorded on blockchain blocks, allowing them to be executed on the blockchain. For example, blockchains are implemented on the Ethereum blockchain, and smart contracts written in Solidity, Viper, etc. can be deployed to the blockchain via the Ethereum Virtual Machine (EVM). Furthermore, all transactions within the blockchain are hashed using SHA-256 and stored as hash values. These hash values ​​can be stored in blockchain blocks to protect individual privacy and prevent overload.

[0046] A smart contract distributed by a credential platform server (100) is automatically concluded when a request for issuing credentials that conforms to preset rules is received from a first client terminal (200), and the contract can be terminated when a credential is returned to a second client terminal (300) in response to the request for issuing credentials.

[0047] Since the trusted execution environment has inbound and outbound rules set, it only receives requests for issuing credentials in a format that corresponds to the smart contract, and the credentials are returned to the outside in a certain format.

[0048] A request for issuing a credential may include a first credential for a second client terminal (300) issued by a first client terminal (200), identification information of the second client terminal (300), a first encryption key of the second client terminal (300), a first credential authentication method, and a deadline for issuing the credential.

[0049] The first credential refers to a credential granted by the first client terminal (200) to the second client terminal (300). For example, the subject of the first client terminal (200) may be the National Police Agency, which issues driver's licenses, and the subject of the second client terminal (300) may be a citizen of the Republic of Korea, who receives a driver's license. The first client terminal (200) may issue a driver's license as the first credential, and may generate a credential issuance request including the issued driver's license and provide it to the credential platform server (100).

[0050] The identification information of the second client terminal (300) relates to the personal identification information of the owner of the second client terminal (300), and may include a resident registration number, mobile phone number, email address, etc.

[0051] The first encryption key is an encryption key of the second client terminal (300), and the first encryption key is an asymmetric key composed of a first public key and a first private key. The request for issuing a credential may include the first public key as the first encryption key. However, this is not limited thereto, and the first encryption key may be any one of a certificate-based encryption key, an ID-based encryption key, an IBD key (Identity-Based Encryption key), and an attribute-based encryption key.

[0052] The first credential authentication method is a method for verifying the identification information of the second client terminal (300) set by the first client terminal (200), and a resident registration number verification method, a mobile phone number verification method, an email verification method, etc. of the second client terminal (300) can be set.

[0053] The deadline for issuing a credential is a period set by the first client terminal (200), and may include a period during which a credential can be issued to the second client terminal (300).

[0054] The credential issuance platform operated by the credential platform server (100) creates a Trusted Execution Environment (TEE) for credential issuance when a smart contract is concluded. That is, when the credential platform server (100) receives a credential issuance request from the first client terminal (200), it creates a Trusted Execution Environment including a credential issuer (Verifier) ​​in response to the credential issuance request.

[0055] Specifically, the credential platform server (100) can create a primitive trusted execution environment that serves as a source for the creation of a trusted execution environment. The primitive trusted execution environment refers to a virtual execution environment in which no arbitrary credential issuer or encryption key has been created.

[0056] A native TEE is a secure execution environment provided by an independent secure area (SEA). It can be created as an image file to implement a virtual execution environment. However, this is not limited to this, and a native TEE can be implemented as either a hardware-based solution or a hardware / software-based solution.

[0057] According to an embodiment, when a raw TEE implemented as a raw image file is created, the credential platform server (100) can generate a hash value for the raw image file, create a transaction including the hash value, and distribute it to the blockchain. Accordingly, the credential platform server (100) can externally disclose that a raw TEE has been created for the creation of a TEE.

[0058] The credential platform server (100) can create a trusted execution environment (TEE) that includes a credential issuer that responds to credential issuance requests based on the native TEE. Like the native TEE, the TEE is a secure execution environment provided by an independent secure area, and can be created as a first image file for implementing a virtual execution environment.

[0059] According to an embodiment, the credential platform server (100) may determine the originality of a raw image file that serves as the basis for creating a raw trusted execution environment before creating or executing a trusted execution environment. The credential platform server (100) may generate a hash value of the raw image file and compare it with the hash value of the raw image file distributed on the blockchain to see if they match, and if they do, the originality of the raw image file may be guaranteed. In addition, the credential platform server (100) may create a trusted execution environment including a credential issuer and a second encryption key corresponding to a credential issuance request based on the raw trusted execution environment whose originality is guaranteed.

[0060] The second encryption key of the TEE includes the TEE's account address, and a public-private key pair-based mechanism can be used to generate the second encryption key to ensure the uniqueness of blockchain participants. The second encryption key includes a second public key, which is the account address, and a second private key that controls the second public key. For example, if the TEE operates on the Ethereum blockchain, the public key may be an Eternally Owned Address (EOA).

[0061] The trusted execution environment generates a 256-bit random number when creating an account address and sets it as a second private key. It can then extract a unique second public key by applying it to the second private key through an elliptic cryptography algorithm.

[0062] For example, the TEE can generate random 256-bit data, encode the generated 256-bit data into a 64-digit Hex string to generate a second private key, and generate a second public key using an elliptic curve cryptography algorithm based on the second private key. In addition, the TEE can convert the public key into a Kecak256 hash value to generate 256-bit binary data, remove the first 96 bits of data from the binary data, and encode the remaining 160 bits of binary data into a Hex string value to generate an account address, which is the second public key.

[0063] However, the encryption algorithm that generates the public key based on the private key may be other encryption algorithms such as the RSA (Rivest, Shamir and Adleman) encryption algorithm, the ElGamal encryption algorithm, as well as the elliptic curve cryptography algorithm.

[0064] The second public key of the trusted execution environment generated through this process is disclosed externally through the blockchain, and data encrypted with the second public key can be restored only with the second private key of the trusted execution environment.

[0065] According to an embodiment, when a trusted execution environment implemented as a first image file is created, the credential platform server (100) can generate a hash value for the first image file, create a transaction including the hash value, and record it on the blockchain. Accordingly, the credential platform server (100) can externally disclose that the trusted execution environment corresponding to the smart contract has been safely executed without being tampered with or forged.

[0066] Thereafter, the trusted execution environment can verify the credential issuance request received from the first client terminal (200).

[0067] Specifically, the trusted execution environment can transmit a verification participation request from the second client terminal (300) to the verification target address corresponding to the identification information of the second client terminal (300). In addition, if a valid verification participation is received from the verification target address, the trusted execution environment can determine that the request for issuance of credentials from the first client terminal (200) is legitimate.

[0068] In some embodiments, if a valid verification participation is not received within a preset expiration date, the trusted execution environment may be deemed unfulfilled in the smart contract and may be terminated.

[0069] That is, the TEE can determine the first credential as legitimate if a valid verification request is received from the verification target address. In this case, the verification request and verification process can be performed according to the first credential authentication method included in the credential issuance request.

[0070] For example, if the first credential authentication method uses a mobile phone number verification method, the TEE can set the mobile phone number included in the credential issuance request as the verification target address and send a verification participation request to the corresponding mobile phone number. Furthermore, if the corresponding mobile phone number is determined to correspond to the identification information of the second client terminal (300), the TEE can determine that the identification information of the second client terminal (300) is valid.

[0071] After determining that the identification information of the second client terminal (300) is valid, the trusted execution environment can receive electronic signature information based on the first encryption key from the address to be verified to determine the validity of the first encryption key.

[0072] If the TEE determines that the electronic signature information based on the first encryption key is valid, it can ultimately determine that the credential issuance request is legitimate. In other words, the TEE can verify that the first credential included in the credential issuance request is legitimate.

[0073] If this verification process is determined to be valid, the trusted execution environment can generate a decentralized identity (DID) for the second client terminal (300) corresponding to the first credential. Furthermore, the credential issuer can generate a second credential that verifies that the decentralized ID corresponding to the first credential has been validly generated.

[0074] Thereafter, the TEE can issue credentials including the first credential, the second credential, and the distributed ID to the second client terminal (300). In this case, the TEE can generate hash values ​​for each of the first credential, the second credential, and the distributed ID, and return the generated transaction including the hash values ​​to the blockchain.

[0075] A smart contract between a credential platform server (100) and a first client terminal (200) is automatically concluded when a credential issuance request that meets preset conditions is entered, and the contract can be terminated when the credential corresponding to the credential issuance request is returned to the blockchain. Therefore, when the trusted execution environment records a transaction containing the hash values ​​of the first credential, the second credential, and the distributed ID in a blockchain block, this signifies the completion of the smart contract execution.

[0076] Meanwhile, the Trusted Execution Environment (TEE) has a temporary status that remains valid only for the duration of the smart contract. In other words, the TEE is created only when a smart contract deployed on the blockchain is established and a request for issuance of credentials from the first client terminal (200) is received. The TEE may be destroyed when the issuance of the first encryption key corresponding to the smart contract's contents is completed or the smart contract is terminated for other reasons.

[0077] The destruction of a TEE means that the environment that constitutes the TEE is initialized, and a series of data related to the TEE is erased. Therefore, the credential issuer, master key, credential issuance request, and other data may be erased along with the TEE's destruction.

[0078] In this way, when the trusted execution environment is destroyed, the credential platform server (100) stores the data received from the first and second client terminals (200 and 300) only for the period during which the smart contract is maintained, and when the smart contract is terminated, the trusted execution environment is destroyed and the stored data can also be deleted. Accordingly, the credential platform server (100) can prevent not only the encryption key but also information related to the encryption key from being leaked to the outside, and can fundamentally block the operating entity of the credential platform server (100) from viewing the data, thereby protecting the privacy of the entity that provided the data.

[0079] In some embodiments, the TEE may record a flag on the blockchain indicating that a destroy command has been executed. When the destroy command is executed, a flag that cannot be tampered with is generated. When the destroy command is executed, the TEE may create a transaction containing the flag, record it on the blockchain, and then initiate the destruction process.

[0080] In another embodiment, the TEE may be maintained even after issuance of a credential corresponding to a credential issuance request for purposes such as renewing or reissuing an encryption key. The credential issuance request may include the TEE's lifetime, or the TEE's lifetime may be preset by the credential platform server (100).

[0081] The trusted execution environment created for issuing credentials is a virtual execution environment. At least one of these environments is created on the credential platform server (100) for the execution of smart contracts. Depending on the contract's establishment and execution, the environment can be independently created, destroyed, and initialized. In this way, the credential platform server (100) can simultaneously execute multiple smart contracts using a trusted execution environment that independently executes each smart contract.

[0082] The first client terminal (200) is a communication device that can access a credential issuing platform, stores data required for a credential issuing request, and can execute a credential issuing application for accessing the credential issuing platform.

[0083] The first client terminal (200) is an issuer that grants certain authority to the second client terminal (300), that is, issues the first credential, and can generate the first credential at the request of the second client terminal (300). In addition, the first client terminal (200) can generate a credential issuance request including the first credential to certify that the first credential is valid.

[0084] The first client terminal (200) can provide a request for issuing credentials in response to a smart contract deployed on a blockchain, and when the smart contract is executed and a credentials are issued to the second client terminal (300), it can be confirmed that the smart contract has been executed.

[0085] The second client terminal (300) is the holder of the first credential generated by the first client terminal (200) and can realize self-sovereign identity (SSI) using a distributed ID (DID) generated by the trusted execution environment. For example, the second client terminal (300) can use the distributed ID as an electronic driver's license, electronic resident registration card, employee ID, other identification, access certificate, apartment resident registration card, etc.

[0086] The second client terminal (300) runs an application that scans the blockchain, and can verify the issuance of credentials for the trusted execution environment by verifying transactions recorded on the blockchain. For example, the second client terminal (300) can use applications such as Etherescan and Remix to verify the issuance of credentials for the trusted execution environment recorded on the blockchain.

[0087] Each of the first and second client terminals (200 and 300) may be at least one of a personal computer (PC), a smart phone, a tablet PC, a mobile internet device (MID), an internet tablet, an internet of things (IoT) device, an internet of everything (IoE) device, a desktop computer, a laptop computer, a workstation computer, a Wibro (Wireless Broadband Internet) terminal, and a PDA (Personal Digital Assistant).

[0088] FIGS. 2A to 2C are diagrams for explaining a credential issuance system of a trusted execution environment using a smart contract according to an embodiment of the present invention.

[0089] Referring to FIG. 2a, the credential platform server (100) can create a smart contract (SC) for issuing a credential and distribute it to a blockchain (BC), and the smart contract (SC) can be recorded in a block of the blockchain (BC) so that the smart contract (SC) can be executed on the blockchain (BC).

[0090]

[0091] *The smart contract (SC) is automatically executed when a transaction containing a request for issuing credentials (QUE1) that conforms to the preset rules is provided to the blockchain (BC) from the first client terminal (200), and is terminated when a credential (VC) that conforms to the request for issuing credentials (QUE1) is returned.

[0092] The first client terminal (200) can create a transaction including a credential issuance request (QUE1) and record it in the blockchain (BC).

[0093] A request for issuance of a credential (QUE1) includes a first credential issued by a first client terminal (200), and may further include identification information of a second client terminal (300), a first encryption key of the second client terminal (300), a first credential authentication method, a deadline for issuing a credential, a validity period of the credential, etc.

[0094] For example, a request for issuance of a credential (QUE1) may include the validity period of the first encryption key corresponding to the period from the date of creation of the encryption key to the date of loss during which the validity is maintained, the deadline for issuance of a credential in which the issuance period of the encryption key is set, a list of second client terminals (300), identification information of the second client terminal (300) related to mobile phone number, ID, characteristic information, user name, resident registration number, address, birthday, etc.

[0095] When a smart contract (SC) between a credential platform server (100) and a first client terminal (200) is established, the credential platform server (100) responds to a credential issuance request (QUE1) by creating a trusted execution environment (VM) including a credential issuer. Here, the credential issuer can verify the credential issuance request and issue a credential.

[0096] Referring to FIG. 2b, the credential platform server (100) can transmit a verification participation request (QUE2) to the verification target address corresponding to the identification information of the second client terminal (300).

[0097] And, if a valid verification participation (VE) is received from the verification target address, the credential platform server (100) can determine that the credential issuance request (QUE1) of the first client terminal (200) is legitimate.

[0098] For example, the credential platform server (100) can transmit a verification participation request (QUE2) to the mobile phone number corresponding to the identification information of the second client terminal (300), authenticate the ID of the user of the second client terminal (300), and receive an electronic signature from the user. That is, the credential platform server (100) can receive electronic signature information based on the first encryption key from the verification target address as a verification participant (VE).

[0099] The credential platform server (100) can set a deadline for receiving verification participation, and the process for each verification participation request (QUE2) and verification participation (VE) can be performed according to the first credential authentication method included in the credential issuance request (QUE1).

[0100] Referring to FIG. 2c, the credential platform server (100) can determine that the credential issuance request (QUE1) is valid if the verification participation (VE) of the second client terminal (300) is determined to be valid.

[0101] That is, if the credential platform server (100) determines that the electronic signature information based on the first encryption key is valid, the credential platform server (100) can determine that the first credential issued by the first client terminal (200) is legitimate.

[0102] The credential platform server (100) can generate a distributed ID of a second client terminal (300) in response to a valid first credential. Furthermore, the credential platform server (100) can generate a second credential that verifies that the distributed ID corresponding to the first credential has been validly generated.

[0103] Thereafter, the credential platform server (100) can issue a credential (VC) including the first credential, the second credential, and the distributed ID to the second client terminal (300). The credential platform server (100) can generate hash values ​​for each of the first credential, the second credential, and the distributed ID, and generate a transaction of the credential (VC) including the hash values ​​and return it to the blockchain (BC).

[0104] In this case, the credential platform server (100) may encrypt the credential (VC) using the first encryption key of the second client terminal (300) and return it to the blockchain (BC) to prevent the generated credential (VC) from being exposed to the outside.

[0105] The smart contract between the credential platform server (100) and the first client terminal (200) is terminated when the credential (VC) corresponding to the credential issuance request (QUE1) is returned to the blockchain (BC), and the smart contract (SC) can be terminated as the transaction of the credential (VC) is returned to the blockchain (BC).

[0106] The second client terminal (300) can obtain the encrypted credentials (VC) recorded in the blockchain (BC) and decrypt the encrypted credentials (VC) with a private key to obtain the credentials (VC) required for decentralized identity authentication, and can use the credentials (VC) as an electronic driver's license, electronic resident registration card, employee ID, other identification, access certificate, apartment resident ID, etc.

[0107] When a credential (VC) is returned and the smart contract (SC) is terminated, the trusted execution environment (VM) running on the credential platform server (100) enters either a destruction mode or a maintenance mode for a preset period. Whether the trusted execution environment (VM) is destroyed may be determined based on the terms of the smart contract (SC).

[0108] If the smart contract (SC) is set to destroy the trusted execution environment (VM) upon completion of the execution of the smart contract (SC), the trusted execution environment (VM) may be deleted from the credential platform server (100) along with a series of data including the credential issuer.

[0109] FIG. 3 is a diagram for explaining a smart contract according to an embodiment of the present invention.

[0110] Referring to FIG. 3, the credential platform server (100) can create a smart contract for issuing credentials and distribute it to a blockchain, and when the smart contract is concluded with the first client terminal (200), a trusted execution environment for issuing credentials can be created.

[0111] The credential platform server (100) can create multiple smart contracts and distribute them to the blockchain. If multiple different credential issuance requests are made to one smart contract, multiple different trusted execution environments may be created.

[0112] The trusted execution environment created for issuing credentials is a virtual execution environment, and at least one can be created on the credential platform server (100) for the execution of smart contracts. That is, even if 10 smart contracts are deployed on the blockchain, if only two smart contracts are executed, the credential platform server (100) can execute two trusted execution environments to execute the contracts.

[0113] Additionally, since each smart contract can have different settings for whether execution is completed normally, the execution period, and the execution method, each smart contract is created and destroyed independently according to the contract's establishment and execution status.

[0114] For example, the credential platform server (100) can conclude a first smart contract (SC1) with a first A client terminal (200A) and a second smart contract (SC2) with a first B client terminal (200B). The credential platform server (100) can create a first trusted execution environment (VM1) corresponding to the conclusion of the first smart contract (SC1) and create a second trusted execution environment (VM2) corresponding to the conclusion of the second smart contract (SC2). Even if there are smart contracts distributed on the blockchain (BC) other than the first and second smart contracts (SC1 and SC2), the credential platform server (100) executes the trusted execution environment only for the concluded smart contract.

[0115] The first Trusted Execution Environment (VM1) and the second Trusted Execution Environment (VM2) are virtual machines created based on different contractual terms and execute independently, making it impossible for one Trusted Execution Environment to influence the other. Therefore, even if the first Trusted Execution Environment (VM1) is terminated upon contract execution, the second Trusted Execution Environment (VM2) remains unaffected and can continue to issue credentials according to the second smart contract (SC2).

[0116] In this way, the credential platform server (100) can execute multiple smart contracts simultaneously by using a trusted execution environment that is independently executed for each smart contract, and can prevent the risk of data being leaked or mixed by using an independent data processing space that cannot be intruded upon.

[0117] Figure 4 is a flowchart illustrating a method for issuing credentials in a trusted execution environment using a smart contract according to an embodiment of the present invention.

[0118] Referring to FIG. 4, a trusted execution environment (VM) running on a credential platform server (100) may be created in response to a credential issuance request (QUE1) received from a first client terminal (200) according to a smart contract (SC) deployed on a blockchain (BC), and may include a credential issuer (S100).

[0119] In addition, the trusted execution environment (VM) can verify the identification information and the first encryption key of the second client terminal (300) to determine the legitimacy of the credential issuance request (QUE1) received from the second client terminal (300) (S110). At this time, the trusted execution environment (VM) can transmit a verification participation request (QUE2) to the verification target address based on the credential issuance request (QUE1) of the first client terminal (200) and determine the validity of the verification participation (VE).

[0120] In addition, the trusted execution environment (VM) can issue a credential (VC) to a second client terminal (300) in response to a credential issuance request (QUE1) determined to be valid (S120). At this time, the credential (VC) may include a first credential issued by the first client terminal (200), a distributed ID generated by the trusted execution environment, and a second credential that certifies that the distributed ID corresponding to the first credential has been generated as valid.

[0121] Depending on the purpose of issuance, a certificate of qualification (VC) can be used as an electronic driver's license, electronic resident registration card, employee ID card, other identification, access certificate, apartment resident ID card, etc.

[0122] The steps of the method or algorithm for issuing credentials for a trusted execution environment using a smart contract described in connection with an embodiment of the present invention may be implemented directly in hardware, implemented as a software module executed by hardware, or implemented by a combination thereof. The software module may reside in a random access memory (RAM), a read only memory (ROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a flash memory, a hard disk, a removable disk, a CD-ROM, or any other form of computer-readable recording medium well known in the art to which the present invention pertains.

[0123] Although the embodiments of the present invention have been described above, it is understood that those skilled in the art will be able to make various modifications and implementations without departing from the scope of the claims of the present invention.

[0124] According to the present invention, a trusted execution environment verifies the relationship between an issuer and a holder through a smart contract and authenticates it by recording it on a blockchain, thereby omitting the authentication process by a separate authentication authority.

[0125] In addition, according to the present invention, the trusted execution environment only verifies the user's identity information when verifying a request for issuance of a credential and does not expose it to the outside, thereby maintaining the anonymity of the distributed ID, thereby allowing one user to possess multiple distributed IDs.

[0126] In addition, according to the present invention, an external entity can determine the forgery, alteration, authenticity, etc. of credentials stored in a client terminal by a simple method of performing verification of transactions recorded in a blockchain.

Claims

1. A step in which a data processing platform server creates a trusted execution environment including data processing code in response to a data processing request received from a data processing request terminal according to a smart contract deployed on a blockchain; A step in which the above trusted execution environment decrypts first data obtained from a data generation terminal; A step in which the above trusted execution environment processes the first data decrypted based on the data processing code to generate a data processing result; and A method for processing personal information using a smart contract-based trusted execution environment, including a step of providing the data processing result to the data processing request terminal according to the smart contract.

2. In paragraph 1, A method for processing personal information using a smart contract-based trusted execution environment, wherein the first data includes at least one of video data and audio data that have been anonymized, metadata, and first encryption key information.

3. In paragraph 2, A method for processing personal information using a smart contract-based trusted execution environment, wherein the metadata includes first terminal information of the data generation terminal that generated the first data, the generation time of at least one of the video data and the audio data before the personal information is anonymized, and the location of the data generation terminal.

4. In paragraph 2, A method for processing personal information using a smart contract-based trusted execution environment, wherein the first encryption key information includes second terminal information of the encryption key supply terminal that generated the first encryption key, and a first public key used to de-identify the personal information.

5. In the fourth paragraph, the step of decrypting the first data is: A personal information processing method using a smart contract-based trusted execution environment, characterized in that the data area corresponding to the personal information is identified and processed using a first private key obtained from the encryption key supply terminal.

6. In paragraph 2, The first encryption key is an asymmetric key consisting of a pair of a first private key and a first public key generated by an encryption key supply terminal, the first public key is generated based on the first private key, and the first encryption key is updated by the encryption key supply terminal according to a preset schedule. A method for processing personal information using a smart contract-based trusted execution environment.

7. In the first paragraph, the step of generating the data processing result is, A step of analyzing the decrypted first data to determine a data processing target corresponding to the data processing request; A step of selecting target image data including the data processing target from among the decrypted first data; A step of extracting metadata corresponding to the selected target image data; and A method for processing personal information using a smart contract-based trusted execution environment, including a step of processing extracted metadata according to the data processing code to generate the data processing result.

8. In paragraph 7, the step of determining the data processing target is: A step of recognizing an object in image data within the decrypted first data using an object recognition model included in the data processing code; and A personal information processing method using a smart contract-based trusted execution environment, comprising a step of determining a matching rate between object characteristic information included in the above data processing request and a recognized object, and specifying an object having a matching rate higher than a standard matching rate as a target of the data processing.

9. In the first paragraph, the step of generating the data processing result is, A step of analyzing the decrypted first data to determine a data processing target corresponding to the data processing request; A step of selecting target audio data including the data processing target from among the decrypted first data; A step of extracting metadata corresponding to the selected target target acoustic data; and A method for processing personal information using a smart contract-based trusted execution environment, including a step of processing extracted metadata according to the data processing code to generate the data processing result.

10. In paragraph 9, the step of determining the data processing target is: A step of classifying the acoustic data in the decoded first data using the acoustic signal analysis model included in the data processing code; and A personal information processing method using a smart contract-based trusted execution environment, comprising a step of determining a matching rate between object characteristic information included in the above data processing request and classified sound data, and specifying sound data having a matching rate higher than a standard matching rate as a target of the data processing.

11. In paragraph 1, after the step of providing the data processing request terminal, A method for processing personal information using a smart contract-based trusted execution environment, further comprising a step of destroying the trusted execution environment according to the smart contract.

12. A computer-readable storage medium storing one or more programs, wherein the one or more programs are configured to be executed by one or more processors of an electronic device, and the one or more programs are a computer-readable recording medium including instructions for performing any one of the methods of claims 1 to 11.

13. Multiple data generation terminals that generate temporary data by shooting or collecting sound in different areas, recognize personal information in the temporary data, and generate first data by de-identifying the personal information based on the first encryption key; and A personal information processing system using a smart contract-based trusted execution environment, including a data processing platform server that generates a trusted execution environment that provides a data processing result generated based on the first data to the data processing request terminal in response to a data processing request received from the data processing request terminal according to a smart contract deployed on a blockchain.

14. In paragraph 13, A personal information processing system using a smart contract-based trusted execution environment, wherein the first data includes at least one of video data and audio data that have been anonymized, metadata, and first encryption key information.

15. In paragraph 14, the trusted execution environment is: A personal information processing system using a smart contract-based trusted execution environment that decrypts first data obtained through the blockchain from each of the above data generation terminals, processes the decrypted first data according to a data processing code, and generates a data processing result.

16. In paragraph 14, the trusted execution environment is: A personal information processing system using a smart contract-based trusted execution environment, characterized in that the first public key used for anonymization processing is determined based on the first encryption key information, the personal information is identified using the first private key corresponding to the first public key, and the first data is decrypted.

17. In paragraph 14, the trusted execution environment is: A personal information processing system using a smart contract-based trusted execution environment that analyzes the decrypted first data to determine a data processing target corresponding to the data processing request, selects target image data including the data processing target from among the decrypted first data, and processes metadata corresponding to the selected target image data according to a data processing code to generate the data processing result.

18. In paragraph 17, the trusted execution environment is: A personal information processing system using a smart contract-based trusted execution environment that recognizes an object in image data within the decrypted first data using an object recognition model included in the data processing code, determines a matching rate between the object characteristic information included in the data processing request and the recognized object, and specifies an object having a matching rate higher than a standard matching rate as a target of the data processing.

19. In paragraph 14, the trusted execution environment is: A personal information processing system using a smart contract-based trusted execution environment that analyzes the decrypted first data to determine a data processing target corresponding to the data processing request, selects target audio data including the data processing target from among the decrypted first data, and processes metadata corresponding to the selected target audio data according to a data processing code to generate the data processing result.

20. In paragraph 19, the trusted execution environment is: A personal information processing system using a smart contract-based trusted execution environment that classifies audio data in the decrypted first data using an audio signal analysis model included in the data processing code, determines the matching rate between the object characteristic information included in the data processing request and the classified audio data, and specifies audio data having a value higher than a standard matching rate as the data processing target.

21. In paragraph 13, A personal information processing system using a smart contract-based trusted execution environment, further comprising an encryption key supply terminal that generates the first encryption key according to a preset schedule and provides it to each of the data generation terminals.

22. In paragraph 21, A personal information processing system using a smart contract-based trusted execution environment, characterized in that each of the above data generating terminals receives a second encryption key having a different value.

Images