KR102465466B1 - The DID-based user authentication system that complements the blockchain's oracle problem - Google Patents

Abstract

A DID-based user authentication system that supplements the oracle problem of the blockchain is provided. The DID-based user authentication system is a DID-based user authentication system including an issuing authority node, a trust anchor node, a user node, and a transaction statistics system, and blocks the history of user identity authentication or certificate issuance for public authentication The issuer node that records the transaction as a transaction in the block of the chain, the transaction statistics system that receives and stores transaction statistics from the transaction recorded in the block, and the certificate at the issuer node using the transaction statistics information received from the transaction statistics system A trust anchor node for statistically calculating information on public keys used for issuance, and a user node for performing a certificate issuance request for user identity authentication or public authentication to the issuing authority node, wherein the trust anchor node comprises the The issuing authority node requests authentication of the public keys used to issue the certificate.

Description

{The DID-based user authentication system that complements the blockchain's oracle problem}

The present invention relates to a DID-based user authentication system that supplements the oracle problem of the block chain. of the user authentication system.

Blockchain refers to a data distribution processing technology that distributes and stores all data that is managed by all users participating in the network. It is also called 'Distributed Ledger Technology (DLT)' or 'Public Transaction Ledger' in that the ledger containing transaction information is not owned by the transaction subject or a specific institution, but is a technology shared by all network participants. . Blockchain is a name given to the fact that blocks containing transaction contents are linked like a chain. This block chain is a technology to prevent hacking such as forgery and forgery of transaction contents, and it uses a method to prevent data forgery by sending transaction details to all users participating in the transaction and collating them for each transaction.

The core concept of blockchain is decentralization, which aims for P2P (Peer to Peer) transactions, away from the existing financial system that secures and manages all transactions in financial institutions. P2P refers to a communication network that connects personal computers without a server or client, and each connected computer acts as a server and client and shares information. Through the method of sharing and verifying the same data by multiple nodes, a trust relationship is formed in the digital world. This environment makes it possible to realize smart contracts that can conveniently conclude and modify contracts with P2P without intermediaries.

In the existing financial system, financial companies have kept transaction records in a central server, whereas in a blockchain based on the P2P method, transaction information is stored in blocks, connected in turn, and shared by all participants.

Also, in the blockchain field, an oracle refers to bringing data outside the blockchain into the blockchain. At this time, the data outside the block chain is called off-chain, and the data that enters the block chain is called on-chain. Blockchain is a distributed storage technology that makes it almost impossible to forge or falsify data, but it can only be managed with the block chain when the data enters the block chain. If data does not enter the blockchain, or if forgery occurs in the process of entering the blockchain, it is difficult to trust even if the data is managed by the blockchain.

The process of getting data in the real world into the blockchain is not as easy as you might think. In order for off-chain data to be turned into on-chain data, a person or device that puts data into the blockchain is needed between the real world and the blockchain. The oracle problem is how to trust the person or device acting as this middleman. Blockchain pursues decentralization, so there is no central authority with authority. Therefore, there is a need for a special way to trust the man in the middle of entering data into the blockchain.

Various methods are being introduced to solve the oracle problem in the blockchain, but there is no definitive solution. Blockchain oracle issues, such as how to decide through voting by cryptocurrency owners, how to choose a median of various data, or how to have a middleware that provides reliable data between the real world and the blockchain Various methods have been proposed to solve the problem.

Korean Patent Registration 10-1936758 (Announcement Date January 11, 2019)

The technical problem to be solved by the present invention is that the user node and the trust anchor node are the issuing authority through the process of the trust anchor node periodically or aperiodically or aperiodically proving that the issuing authority node that it guarantees is authenticated using the data recorded in the transaction. It is to provide a DID-based user authentication system that can perform transparent certificate issuance while trusting the node.

However, the technical problems to be solved by the present invention are not limited to the above problems, and may be variously expanded without departing from the technical spirit and scope of the present invention.

A DID-based user authentication system according to an embodiment of the present invention for solving the above problems is a DID-based user authentication system including an issuer node, a trust anchor node, a user node, and a transaction statistics system, the user identity Issuer node that records the history of issuance of certificates for authentication or public certification as a transaction in the block of the block chain, a transaction statistics system that receives and stores transaction statistics from the transactions recorded in the block, and the transaction statistics system A trust anchor node that statistically calculates information on public keys used for certificate issuance in the issuing authority node using transaction statistics information, and a certificate issuance request for user identity authentication or public certification to the issuing authority node and a user node, wherein the trust anchor node requests authentication of the public keys used for issuing a certificate from the issuing authority node.

In some embodiments according to the present invention, in the certificate issuance history recorded by the issuing authority node as a transaction in the block, each corresponding certificate type is recorded for each public key used for issuing the certificate, and is used for each corresponding certificate type It can include both information about the public key used and the public key used previously.

In some embodiments according to the present invention, the trust anchor node may request authentication for all public keys used for issuing certificates from the issuing authority node or may request authentication by setting a threshold value.

A DID-based user authentication system according to another embodiment of the present invention for solving the above problems is a DID-based user authentication system including an issuer node, a first trust anchor node, a second trust anchor node, a user node, and a transaction statistics system As a user authentication system of An issuer node that records issuance history as a transaction in a block of a block chain, a first trust anchor node that issues the identity authentication VC after verifying the DID in response to a request for issuing the identity authentication VC from the issuing institution node, the A transaction statistics system that receives and stores transaction statistics from a transaction recorded in a block, a user node that requests issuance of a certificate for user identity authentication or public proof to the issuing authority node, and transaction statistics received from the transaction statistics system A second trust anchor node that statistically calculates information on public keys used for certificate issuance in the issuing authority node using the information, and requests authentication of the public keys used for certificate issuance to the issuing authority node includes

In some embodiments according to the present invention, the first trust anchor node and the second trust anchor node may be separate nodes.

Other specific details of the invention are included in the detailed description and drawings.

According to the present invention, it is possible to improve a fundamental oracle problem occurring in a DID-based service.

In addition, according to the present invention, the trust anchor node can prove that the issuing authority node it guarantees is authenticated periodically or aperiodically by using the data recorded in the transaction, and by disclosing the authentication information about this, the user node can communicate with The DID document of the issuing authority node can be trusted.

In addition, according to the present invention, in providing a DID-based service, transparent certificate issuance can be made while providing reliability to a user node and a trust anchor node through periodic or aperiodic identity authentication of the issuing authority node.

In addition, according to the present invention, in providing a DID-based service, the trust anchor node, the issuer node, and the user node can trust the DID document registered in the block chain and improve the oracle problem.

However, the effects of the present invention are not limited to the above effects, and may be variously expanded without departing from the spirit and scope of the present invention.

1 is a diagram illustrating a distributed processing system using a block chain to which the technical idea according to the present invention can be applied.
2 and 3 are block diagrams showing the connection of blocks used in the block chain system.
4 is a block diagram illustrating a DID-based user authentication system according to an embodiment of the present invention.
5 is a flowchart illustrating a DID-based user authentication method according to an embodiment of the present invention.
6 is a block diagram illustrating a DID-based user authentication system according to another embodiment of the present invention.
7 is a block diagram of a computing device of a node according to an embodiment of the present invention.

Advantages and features of the present invention and methods of achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but will be embodied in various different forms, and only these embodiments allow the disclosure of the present invention to be complete, and common knowledge in the art to which the present invention pertains It is provided to fully inform those who have the scope of the invention, and the present invention is only defined by the scope of the claims.

The terminology used herein is for the purpose of describing the embodiments, and is not intended to limit the present invention. In this specification, the singular also includes the plural, unless specifically stated otherwise in the phrase. As used herein, “comprises” and/or “comprising” refers to the presence of one or more other components, steps, operations and/or elements mentioned. or addition is not excluded.

Unless otherwise defined, all terms (including technical and scientific terms) used herein may be used with the meaning commonly understood by those of ordinary skill in the art to which the present invention belongs. In addition, terms defined in a commonly used dictionary are not to be interpreted ideally or excessively unless clearly specifically defined.

Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the accompanying drawings. The same reference numerals are used for the same components in the drawings, and repeated descriptions of the same components are omitted.

All blockchain-based services have an oracle problem. Therefore, the reliability of data registered in the blockchain must be guaranteed. Users must trust the data recorded in the block chain, and when data outside the block chain is brought into the block chain, the data can be forged. In particular, the DID document recorded in the block chain must also be trusted.

Data outside the block chain is expressed as off-chain data, and the data recorded within the block chain is expressed as on-chain data, and the node that performs that role is referred to as a trust anchor node. If forgery occurs in the process of off-chain data being recorded in the block chain, it is difficult to trust such data, no matter how block chain it is.

Trust Anchor node is used to solve the oracle problem, but it is dangerous to trust the DID document based on the fact that the trust anchor node is registered. And, when a third party claims that it is a subject with an incorrect DID document, confusion is caused to the user. In other words, since an authentication problem occurs, the Oracle problem in DID-based services must be improved. To this end, a management process that can check whether the data guaranteed by the trust anchor node is valid is required, and the present invention intends to propose a method for improving the oracle problem.

Specifically, when explaining the oracle problem in DID-based services, in the DID framework, the trust anchor node plays the role of an intermediary that records the first off-chain data (DID document) as on-chain data, and in this process, the trust anchor node performs authentication for the DID owner. The subject who registered the DID proves that their DID is "did:lit:thisisAschool" through the identity authentication VC (Verifiable Credential) issued by the trust anchor node.

However, registering a DID document in the blockchain can be performed from any node, such as a trust anchor node or a user node. Accordingly, there is a fundamental Oracle problem. If a third party claims to be a school A using a completely different DID, the user cannot trust the school A guaranteed by the trust anchor node. Therefore, the trust anchor node needs to prove that the DID of school A that it guarantees is a valid DID. To solve this, the trust anchor node needs to authenticate the issuing authority node that it endorsed. The present invention proposes a method of supplementing the Oracle problem according to this necessity.

Hereinafter, first, a distributed processing system using a block chain to which the concept of the present invention can be applied will be described.

1 is a diagram illustrating a distributed processing system using a block chain to which the technical idea according to the present invention can be applied.

Referring to FIG. 1 , a distributed processing system 100 using a block chain is a distributed network system consisting of a plurality of nodes 110-170. The nodes 110 to 170 constituting the distributed network 100 may be electronic devices having computing power, such as computers, mobile terminals, and dedicated electronic devices.

In general, the decentralized network 100 can store and refer to information commonly known to all participating nodes in a connected bundle of blocks called blockchain. The nodes 110-170 can communicate with each other and can be divided into a full node that stores, manages, and propagates the block chain and a light node that can simply participate in transactions. . When referring to a node without a separate description in this specification, it often refers to a full node that participates in a distributed network and performs an operation to create, store, or verify a block chain, but is not limited thereto.

Each block connected to the block chain includes transaction details within a certain period, ie, transactions. The nodes can manage transactions by creating, storing, or verifying the blockchain according to their respective roles.

According to an embodiment, the transaction may represent various types of transactions. In one embodiment, the transaction may correspond to a financial transaction for indicating the ownership status of virtual currency and its change. In another embodiment, the transaction may correspond to a physical transaction for indicating the ownership status of the object and its change. In another embodiment, the transaction may correspond to an information sharing process to represent the recording, storage and transfer of information. Nodes performing a transaction in the distributed network 100 may have a private key and a public key pair each cryptographically related.

2 and 3 are block diagrams showing the connection of blocks used in the block chain system.

Referring to FIG. 2 , the block chain 200 is a kind of distributed database of one or more sequentially connected blocks 210 , 220 , 230 . The block chain 200 is used to store and manage user's transaction details in the block chain system, and each node participating in the network of the block chain system creates a block and connects it to the block chain 200 . Although a limited number of blocks 210, 220, and 230 are shown in FIG. 2, the number of blocks that can be included in the block chain is not limited thereto.

Each block included in the block chain 200 may be configured to include a block header 211 and a block body 213 . The block header 211 may include a hash value of the previous block 220 to indicate a connection relationship between blocks. In the process of verifying whether the block chain 200 is valid, the connection relationship in the block header 211 is used. The block body 213 may include data stored and managed in the block 210 , for example, a transaction list or a transaction chain.

Referring to FIG. 3 , the block header 211 may include a hash 2112 of a previous block, a hash 2113 of a current block, and a nonce 2114 . Also, the block header 211 may include a root 2115 indicating a header of a transaction list in a block.

As described above, the blockchain 200 may include one or more connected blocks. The one or more blocks are connected based on a hash value in the block header 211 . The hash value 2112 of the previous block included in the block header 211 is the same as the current hash 2213 included in the previous block 220 as a hash value of the previous block 220 . The one or more blocks are chained by the hash value of the previous block in each block header. Nodes participating in the distributed network verify the validity of a block based on the hash value of the previous block included in the one or more blocks, so it is impossible for a single malicious node to forge or falsify the contents of an already created block do.

The block body 213 may include a transaction list 2131 . The transaction list 2131 is a list of blockchain-based transactions. For example, the transaction list 2131 may include a record of financial transactions made in the blockchain-based financial system. The transaction list 2131 may be expressed in the form of a tree, for example, the amount of money transmitted by user A to user B is recorded in the form of a list, and the storage length in the block is the value of the transaction included in the current block. It can be increased or decreased based on the number.

In addition, the block 210 may include other information 2116 other than the information included in the block header 211 and the block body 213 .

Nodes participating in a decentralized network have the same blockchain, and the same transactions are stored in blocks. A block containing a list of transactions is shared on the network, so all participants can verify it.

4 is a block diagram illustrating a DID-based user authentication system according to an embodiment of the present invention.

Referring to FIG. 4 , the DID-based user authentication system 300 according to an embodiment of the present invention includes an issuer node 400 , a trust anchor node 500 , a user node 600 , and a transaction statistics system 700 . ) is configured to include

In the present invention, after the issuing agency node 400 records a plurality of public keys to be used for issuing a certificate for user authentication in the DID document, the DID document is stored in the block chain through the issuing agency node 400 or the trust anchor node 500 It is assumed that you have registered in advance.

The operation algorithm of the DID-based user authentication system 300 in the present invention is first, the issuing agency node 400 completes the self-authentication procedure performed in the trust anchor node 500, and after performing the self-authentication procedure, the issuing agency node ( 400) It transmits its DID to the trust anchor node 500 .

The self-authentication procedure performed in the trust anchor node 500 is a step of confirming the identity of the issuing authority node 400, and may be performed by various authentication procedures such as mobile phone self-authentication and digital signature.

Then, the trust anchor node 500 checks the DID transmitted from the issuing authority node 400, and when the DID transmitted from the issuing authority node 400 is verified, the trust anchor node 500 is the corresponding issuing authority node 400 ) to issue an identity authentication VC (Verifiable Credential).

In relation to Verifiable Credential (VC), Claim is a description of one subject and is expressed as a subject-property-information relationship. A credential is a certificate issued by an issuer, and is a set of one or more claims made for one subject. VC (Verifiable Credential) is a set of data that is issued as data including the issuer's digital signature in the credential, and includes metadata such as information on whether the credential has been changed, issuer information, and a digital signature.

The identity authentication VC issued by the trust anchor node 500 to the issuing authority node 400 means that the DID provided by the issuing authority node 400 has been verified, and the issuing authority node 400 is in the DID document. It means that identity and ownership have been verified.

Subsequently, through the transaction statistical analysis of the block chain, the trust anchor node 500 checks the public key information used for issuing a certificate for user authentication in the issuing agency node 400 and requests authentication to the issuing agency node 400 and publishes the authentication result by receiving the confirmation of the issuing authority node 400, and users can trust the DID document registered in the block chain through the authentication result. Accordingly, the trust anchor node 500 , the issuing authority node 400 , and the user node 600 can perform a transparent certificate issuance process while providing trust to each other.

Hereinafter, the role and operation process of each component will be described.

The issuing authority node 400 is a node that issues a certificate for user identity authentication, and issues a certificate for user identity authentication in response to a certificate issuance request from the user node 600 and transmits it to the user node 600 , the certificate The issuance history is recorded as a transaction in the block of the blockchain.

Prior to this, the first issuing authority node 400 adds a plurality of public keys to be used for issuing a certificate to the DID document, transmits the DID document to the trust anchor node 500, and requests registration in the block chain. That is, the issuing authority node 400 generates public keys to be registered in the DID document, transmits the public keys to the trust anchor node 500 by including the public keys in the DID document, and requests registration in the block chain.

Alternatively, the first issuing authority node 400 adds a plurality of public keys to be used for issuing a certificate to the DID document and directly registers the DID document in the block chain.

Below is an example of a DID document.

(DID Document)

authentication - public key X, public key Y, public key Z, …

assertionMethod - public key A, public key B, public key C, …

capabilityInvocation - … , capabilityDelegation - … , keyAgreement - …

The issuing authority node 400 records the certificate issuance history as a transaction in the block of the block chain, and the following is an example of the recorded transaction.

(Transaction)

("did:lit:thisisAschool", transcript, public key A, 20201201), ("did:lit:thisisAschool", transcript, public key A, 20201130),

("did:lit:thisisAschool", transcript, public key P , 20201130), …

("did:lit:thisisAschool", graduation certificate, public key B, 20201203), ("did:lit:thisisAschool", graduation certificate, public key B, 20201201), …

("did:lit:thisisAschool", academic record, public key C, 20201202), ("did:lit:thisisAschool", academic record, public key C, 20201206), …

In the transaction, each corresponding certificate type is recorded for each public key used for issuing the certificate in the issuing authority node 400, and the type of the public key used for issuing the certificate is different for each corresponding certificate type. In the above example, the public key P means a key used before the public key A in issuing transcripts, and all these histories are recorded in the transaction.

The transaction statistics system 700 receives and stores transaction statistics from transactions recorded in blocks of the block chain. In the transaction statistics, the public key used for issuing the certificate in the issuing authority node 400 is matched for each certificate and statistically stored.

The trust anchor node 500 receives transaction statistics information from the transaction statistics system 700, and acquires and issues accumulated data of transactions used in the certificate issuance history in the issuing authority node 400 through the transaction statistics information The authority node 400 statistically calculates information on public keys used for certificate issuance. The following schematically shows the accumulated data of transactions used in the certificate issuance history in the issuing authority node 400 .

School A: Transcript: [Public Key A, Public Key P]

School A: Graduation certificate: [Public key B]

School A: Academic record: [Public key C]

In addition, the trust anchor node 500 provides the public key statistically through the accumulated data of the transaction to the specific issuing institution node 400 in order to guarantee the issuing institution node 400 (eg, school A) that it guarantees. Requests for authentication periodically or aperiodically. That is, to prove that the public key used by the specific issuing agency node 400 (eg, school A) is a value included in the DID document registered in the block chain, it is authenticated with the specific issuing agency node 400 . to request

The following shows an example of a query statement in which the trust anchor node 500 requests authentication of a specific issuing authority node 400 .

requestAuthentication(Public Key A, Public Key B, Public Key C, Public Key P)

The trust anchor node 500 may request authentication for all public keys from a specific issuing authority node 400, or may request authentication by setting a threshold value.

That is, the specific issuing authority node 400 may periodically or aperiodically replace the key used for issuing the certificate for security. , the information of keys used before replacement) is calculated statistically. In this case, the trust anchor node 500 may request authentication for all keys used for certificate issuance from the specific issuing authority node 400, or set a threshold value to request authentication for the number of keys corresponding to the threshold value. have.

Specifically, for example, assuming that N keys are registered in the DID document, when N authentication results are requested by requesting authentication for all N keys, it is determined that the issuing authority node 400 owns all the keys. can do. However, if the number of keys increases, it may cause a load to request and verify authentication for all keys. (400) may determine that all keys are owned.

The trust anchor node 500 guarantees the reliability of the specific issuing authority node 400 by publishing the authentication result for the specific issuing authority node 400 . The user nodes 600 may have the reliability of the DID document registered in the block chain through the authentication result for the specific issuer node 400 of the trust anchor node 500 .

According to the present invention, it is possible to improve a fundamental oracle problem occurring in a DID-based service. In DID-based services, there is no central authority that manages identity, so the authentication method is very important. Therefore, there is a limit for the user to completely trust the DID issued by the trust anchor node 500 .

Through the method proposed in the present invention, the trust anchor node 500 can use the accumulated data recorded in the transaction to periodically or aperiodically prove that the issuing authority node 400 that it guarantees is authenticated, and by disclosing this, the user can communicate You can trust the DID document of the publisher node 400 you want to use. The issuing authority node 400 also provides trust to the user node 600 and the trust anchor node 500 through periodic or aperiodic identity authentication, and transparent certificate issuance is made.

Through the method proposed in the present invention, the issuer node 400, trust anchor node 500, and user node 600 can trust the DID document registered in the block chain and improve oracle problems that may occur in DID-based services. have.

5 is a flowchart illustrating a DID-based user authentication method according to an embodiment of the present invention.

Referring to FIG. 5 , a DID-based user authentication method according to an embodiment of the present invention is performed between an issuer node 400 , a trust anchor node 500 , a user node 600 , and a transaction statistics system 700 . operation, and first, the first issuing authority node 400 adds a plurality of public keys to be used for certificate issuance to the DID document, and transmits the DID document to the trust anchor node 500 to request registration in the block chain or , the first issuing agency node 400 directly registers in the block chain (S100). That is, the issuing authority node 400 registers the DID document including the public keys to be used for issuing the certificate in the block chain in some way.

Next, the issuing authority node 400 records the certificate issuance history as a transaction in the block of the block chain (S110).

Then, the transaction statistics system 700 receives and stores the transaction statistics from the transactions recorded in the block of the block chain (S120). In the transaction statistics, the public key used for issuing the certificate in the issuing authority node 400 is matched for each certificate and statistically stored.

Then, the trust anchor node 500 receives transaction statistics information from the transaction statistics system 700, and acquires accumulated data of transactions used in the certificate issuance history in the issuing authority node 400 through the transaction statistics information, , statistically calculates information on public keys used for certificate issuance in the issuing authority node 400 . In addition, the trust anchor node 500 periodically or aperiodically authenticates the public key statistically obtained through the accumulated data of the transaction to the specific issuer node 400 in order to guarantee the issuing authority node 400 that it guarantees. request (S130).

Next, the trust anchor node 500 guarantees the reliability of the specific issuer node 400 by publishing the authentication result for the specific issuer node 400 ( S140 ).

6 is a block diagram illustrating a DID-based user authentication system according to another embodiment of the present invention.

Referring to FIG. 6 , the DID-based user authentication system 310 according to another embodiment of the present invention includes an issuer node 400 , a first trust anchor node 510 , a second trust anchor node 520 , and a user node 600 , a transaction statistics system 700 .

As described above, the issuing authority node 400 is a node that issues a certificate for user identity authentication, and issues a certificate for user identity authentication in response to a certificate issuance request from the user node 600 to the user node 600 . and records the certificate issuance history as a transaction in the block of the blockchain.

Prior to this, the first issuing agency node 400 adds a plurality of public keys to be used for issuing a certificate to the DID document, transmits the DID document to the first trust anchor node 510 with public trust, and requests registration on the block chain do. That is, the issuing authority node 400 generates public keys to be registered in the DID document, transmits the public keys to the first trust anchor node 510 by including the public keys in the DID document, and requests registration in the block chain.

Alternatively, the first issuing authority node 400 adds a plurality of public keys to be used for issuing a certificate to the DID document and directly registers the DID document in the block chain.

The issuing authority node 400 records the certificate issuance history as a transaction in the block of the block chain. In the transaction, each corresponding certificate type is recorded for each public key used for issuing the certificate in the issuing authority node 400, and the type of the public key used for issuing the certificate is different for each corresponding certificate type. In particular, in the transaction, a history of the change details of the public key used for issuing the certificate is all recorded.

The transaction statistics system 700 receives and stores transaction statistics from transactions recorded in blocks of the block chain. In the transaction statistics, the public key used for issuing the certificate in the issuing authority node 400 is matched for each certificate and statistically stored.

The second trust anchor node 520 receives transaction statistics information from the transaction statistics system 700, and acquires accumulated data of transactions used in the certificate issuance history in the issuing authority node 400 through the transaction statistics information, , statistically calculates information on public keys used for certificate issuance in the issuing authority node 400 .

In addition, the second trust anchor node 520 periodically or non-certifies the public key statistically through the accumulated data of the transaction to the specific issuer node 400 in order to guarantee the issuing authority node 400 that it guarantees. request periodically. That is, in order to prove that the public key used by the specific issuing agency node 400 for issuing the certificate is a value included in the DID document registered in the block chain, authentication is requested from the specific issuing agency node 400 .

The second trust anchor node 520 may request authentication for all public keys from the specific issuing authority node 400 or may request authentication by setting a threshold value.

That is, the specific issuing authority node 400 may periodically or aperiodically replace the key used for issuing the certificate for security. , the information of keys used before replacement) is calculated statistically. In this case, the second trust anchor node 520 may request authentication for all keys used for certificate issuance from the specific issuing authority node 400 or may request by setting a threshold value.

The second trust anchor node 520 guarantees the reliability of the specific issuer node 400 by periodically or non-periodically publishing the authentication result for the specific issuer node 400 . The user nodes 600 may have the reliability of the DID document registered in the block chain through the authentication result for the specific issuer node 400 of the second trust anchor node 520 .

The second trust anchor node 520, for example, whenever BP nodes (Block Producers, block generating nodes) of the block chain that provide DID-based services generate blocks, the transaction statistics system 700 provides It periodically or aperiodically requests the specific issuing authority node 400 to authenticate the public key statistically based on the accumulated data.

Here, the first trust anchor node 510 may be a node whose public trust is recognized by receiving the DID document from the issuing authority node 400 and requesting registration in the block chain, and the second trust anchor node 520 provides transaction statistics It may be a node that receives the accumulated data of the transaction from the system 700 and periodically or aperiodically performs validation of the DID document and the public key for the specific issuer node 400 . The first trust anchor node 510 and the second trust anchor node 520 may be physically separated from each other or may be the same node.

7 is a block diagram of a computing device of a node according to an embodiment of the present invention.

Referring to FIG. 7 , the computing device 1000 of a node according to an embodiment of the present invention includes a processor 1100 and a memory 1200 , and the processor 1100 includes one or more cores and a graphic processing unit and/or Alternatively, it may include a connection path (eg, a bus, etc.) for transmitting and receiving signals with other components.

The processor 1100 according to an embodiment executes the operation of the DID-based user authentication system described with reference to FIGS. 4 to 6 by executing one or more instructions stored in the memory 1200 .

For example, the processor 1100 collects information about data upload/download that occurs in one or more nodes by executing one or more instructions stored in the memory, writes the collected information to a block, and writes the collected information to the block. Based on the information, related information is provided for at least one node.

Meanwhile, the processor 1100 may further include a random access memory (RAM) and a read-only memory (ROM) for temporarily and/or permanently storing signals (or data) processed therein. . In addition, the processor 1100 may be implemented in the form of a system on chip (SoC) including at least one of a graphic processing unit, a RAM, and a ROM.

The memory 1200 may store programs (one or more instructions) for processing and controlling the processor 1100 . Programs stored in the memory 1200 may be divided into a plurality of modules according to functions.

The operations of the system described in relation to the embodiments of the present invention may be implemented directly in hardware, as a software module executed by hardware, or by a combination thereof. A software module may include random access memory (RAM), read only memory (ROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, hard disk, removable disk, CD-ROM, or It may reside in any type of computer-readable recording medium well known in the art to which the present invention pertains.

The components of the present invention may be implemented as a program (or application) to be executed in combination with a computer, which is hardware, and stored in a medium. Components of the present invention may be implemented as software programming or software components, and similarly, embodiments may include various algorithms implemented as data structures, processes, routines, or combinations of other programming constructs, including C, C++ , Java, assembler, etc. may be implemented in a programming or scripting language. Functional aspects may be implemented in an algorithm running on one or more processors.

It is to be understood that the above-described embodiments are illustrative in all respects and not restrictive, the scope of the present invention being indicated by the following claims rather than by the foregoing detailed description. And it should be construed that all changes and modifications derived from the meaning and scope of the claims as well as equivalent concepts are included in the scope of the present invention.

100: decentralized network
110-170: nodes
200: Blockchain
210, 220, 230: block
300, 310: user authentication system
400: Issuer node
500: trust anchor node
510: first trust anchor node
520: second trust anchor node
600: user node
700: transaction statistics system

Claims (5)

A DID-based user authentication system comprising an issuer node, a trust anchor node, a user node, and a transaction statistics system,
an issuer node that records the history of issuing a certificate for user identity authentication or public authentication as a transaction in a block of the block chain;
a transaction statistics system for receiving and storing transaction statistics from the transactions recorded in the block;
a trust anchor node for statistically calculating information on public keys used for certificate issuance in the issuing authority node using the transaction statistics information received from the transaction statistics system; and
A user node that performs a certificate issuance request for user identity authentication or public authentication to the issuing authority node;
The trust anchor node requests the issuing authority node to authenticate the public keys used to issue the certificate, a DID-based user authentication system. The method of claim 1,
The certificate issuance history recorded by the issuing authority node as a transaction in the block is,
A DID-based user authentication system in which each corresponding certificate type is recorded for each public key used for issuing a certificate, and information on the public key used for each corresponding certificate type and the previously used public key are all included. The method of claim 1,
The trust anchor node, a DID-based user authentication system for requesting authentication for all public keys used for issuing certificates from the issuing authority node or by setting a threshold value to request authentication. A DID-based user authentication system comprising an issuer node, a first trust anchor node, a second trust anchor node, a user node, and a transaction statistics system,
After completing the identity authentication procedure performed in the trust anchor node, the user transfers his/her DID to the trust anchor node to request the issuance of an identity authentication VC (Verifiable Credential), and blocks the history of user identity authentication or certificate issuance for public authentication issuer nodes that record transactions in blocks of the chain;
a first trust anchor node for issuing the identity authentication VC after verifying the DID for the identity authentication VC issuance request from the issuing authority node;
a transaction statistics system for receiving and storing transaction statistics from the transactions recorded in the block;
a user node for performing a certificate issuance request for user identity authentication or public authentication to the issuing authority node; and
By using the transaction statistics information received from the transaction statistics system, information on public keys used for certificate issuance in the issuing authority node is statistically calculated, and for the public keys used for certificate issuance to the issuing authority node A DID-based user authentication system, including; a second trust anchor node that requests authentication. 5. The method of claim 4,
The DID-based user authentication system, wherein the first trust anchor node and the second trust anchor node are different and separate nodes.

Images