Blockchain-based authentication and transaction system

Abstract

According to an embodiment of the present invention, a blockchain-based authentication and transaction system is provided, which includes a user's DID (Distributed Identity) wallet, which is an application program installed on a user's mobile terminal. Here, when the user's DID wallet acquires a verifiable presentation (VP) of the other party provided by the other party's system that will be the other party of authentication or transaction, the user's DID wallet verifies the other party's VP and displays the verified other party verification information on a screen to the user, thereby enabling the user to verify the authenticity of the other party.

Description

[Technical field]

[0001] The present invention relates to an online mutual authentication DID (Distributed Identity) technology that allows a user to first check whether a party (or a request for authentication) connected to the user online is a legitimate party and then provide his / her own authentication value in order to provide blockchain-based authentication, transaction, and electronic signature services on a user's mobile terminal, and to an on / offline mutual authentication and transaction technology that allows offline mutual authentication to be performed while maintaining distance without close contact even offline. [Background technology]

[0002] With the abolition of the government-led digital certificate system and the COVID-19-induced contactless environment, new authentication and digital signature technologies that combine greater security and convenience than ever before are attracting attention.

[0003] In terms of security, it is evolving beyond the first-generation centralized identity and second-generation federated identity systems into a decentralized blockchain-based third-generation distributed identity (DID) system that is difficult for attackers to arbitrarily modify or attack.

[0004] This type of DID authentication system is not limited to online transactions, but can also be used offline using QR codes and smartphones.

[0005] However, even though the DID authentication system is a secure system that guarantees the user's public key with a trusted blockchain, if the system the user first accessed or the authentication request value (QR code, return URL, etc.) is fake, the user's authentication information can be stolen by an attacker at any time. Existing DID authentication technology does not allow users to check in advance who they are providing their identity to or what they are signing electronically, and there is a risk that only their own identity proof or electronic signature will be provided to the other party.

[0006] In other words, existing DID authentication technology, like all authentication technologies developed to date (i.e., including OTP, PKI, biometric authentication, behavior-based authentication, blockchain authentication, etc.), has been developed to only verify whether a user accessing a specific service is a legitimate user, and does not verify the authenticity of the service provider providing that specific service.

[0007] For this reason, if a user accesses a malicious attacker's service disguised as a legitimate service provider and requests user authentication or electronic signature, the user's identity and electronic signature will be stolen.

[0008] Malicious attackers can exist not only online but also offline. For example, in the case of QR code authentication, if an attacker distributes a malicious authentication or digital signature QR code that they have generated in advance to the smartphone of an offline service provider, and a legitimate user recognizes and approves it with their smartphone app, the user will approve it without knowing what they have approved, which could result in their identity being stolen or their digital signature being stolen. This type of fraudulent transaction by replacing QR codes (QRishing) is occurring frequently in offline mobile authentication.

[0009] Therefore, no matter how powerful the back-end of the authentication system is, if the system the user first accessed or the authentication request value (QR code, return URL, etc.) is fake, the user's authentication information and electronic signature can be stolen at any time.

[0010] In addition, the recent COVID-19 outbreak has created a situation in which face-to-face transactions must be conducted safely offline while maintaining a distance of more than 2 meters. To improve on the QR and NFC authentication methods that only allow authentication at a close distance of less than 1 meter, an improved method is needed that can safely confirm the other party at a quarantine distance of more than 2 meters and then transmit the user's own authentication value or electronic signature value. Summary of the Invention [Problem to be solved by the invention]

[0011] The present invention has been conceived to solve the above-mentioned problems, and aims to provide a DID-based online mutual authentication and transaction technology that first checks whether a service requesting user authentication is a legitimate service and then transmits a user authentication value to the corresponding service, and an offline mutual authentication and transaction method that first checks whether a transaction partner (or IoT device) is a normal partner even at a safe quarantine distance of 2M or more offline and then transmits a user authentication value. [Means for solving the problem]

[0012] According to one aspect of the present invention, there is provided a blockchain-based authentication and transaction system including a user's Distributed Identity (DID) wallet, which is an application program installed on a user's mobile terminal. Here, when the user's DID wallet acquires a verifiable presentation (VP) of the other party provided by the other party's system to be authenticated or transacted with, the user's DID wallet verifies the other party's VP and displays the verified other party verification information on a screen to the user, thereby enabling the user to verify the authenticity of the other party.

[0013] In one embodiment, the user's DID wallet verifies the other party's VP with a public key corresponding to the other party's VP, verifies the other party's electronic signature included in the re-called VP, obtains the electronic signature of the issuer who issued the other party's VC from the other party's VC (Verifiable Credential) included in the re-called VP, verifies the issuer's electronic signature with the issuer's public key, and then displays the verified other party identification information on a screen to the user.

[0014] In one embodiment, the counterparty's VP is a static VP of a fixed value generated in advance, or a dynamic VP dynamically generated at the time of authentication or transaction by encrypting the counterparty's VC (Verifiable Credential) issued in advance by the counterparty's DID wallet with a private key.

[0015] In one embodiment, the other party's DID wallet, which is an application program installed in the other party's system, is further included. Here, the other party's DID wallet can provide the user with a QR (Quick Response) code after loading the other party's VP into the QR code or loading network access information of a repository that can access the other party's VP into the QR code.

[0016] Here, the user's DID wallet can obtain the other party's VP by recognizing the QR code.

[0017] In one embodiment, the user's DID wallet can submit the user's VP to the other party's system or to a submission destination specified in the other party's VC (Verifiable Credential) only if the user authenticates the other party through the other party identification information displayed on the screen.

[0018] In one embodiment, the user's DID wallet extracts a terminal identification value from a short-range wireless signal sent from the other party's system or an interlocking device interlocked with the other party's system, and transmits the extracted terminal identification value to a Terminal Information Server to obtain the other party's VP corresponding to the terminal identification value from the Terminal Information Server.

[0019] In one embodiment, the user's DID wallet further performs verification as to whether the terminal identification value extracted from the short-range wireless signal matches the terminal identification value of the other party's system included in the retrieved VP, and only if the verification is successful, can the user's VP be submitted to the other party's system or to a submission destination specified in the other party's VC (Verifiable Credential).

[0020] In one embodiment, if the transaction corresponds to a blockchain-based remittance transaction, the user's DID wallet presents a screen in which the remittance amount can be entered only to the deposit address based on the recipient information displayed on the screen as the counterparty identification information, and when the user enters the remittance amount, the transaction can be sent to the corresponding deposit address. Effect of the Invention

[0021] According to an embodiment of the present invention, a DID-based online mutual authentication technology is provided that first checks whether a service requesting user authentication is a legitimate service and then transmits the user's authentication value to the corresponding service, thereby enabling safer identity authentication and transactions. It is also possible to provide an offline mutual authentication and transaction method that enables safe identity authentication and transactions while maintaining a safe quarantine distance even offline. [Brief description of the drawings]

[0022] [Figure 1]1 is a diagram showing the flow of logging in to a website using standard DID-based online user authentication according to the conventional method. [Diagram 2] A diagram showing the flow of electronic signature as standard DID-based online user authentication according to the conventional method. [Diagram 3] A diagram showing the flow of authenticating an online user and providing a service using a standard DID including SVC verification of a service provider according to an embodiment of the present invention. [Figure 4] A diagram showing the flow of receiving an online user's electronic signature and providing a service using a standard DID including SVC verification of a service provider according to an embodiment of the present invention. [Diagram 5] 1 is a diagram showing a flow of offline mutual authentication between users via authentication BLE according to an embodiment of the present invention. [Figure 6] 1 is a diagram showing a flow of offline mutual authentication between a user and a device through authentication BLE according to an embodiment of the present invention. [Figure 7] 1 is a diagram showing a flow of allowing login after verifying a service provider with a user wallet and then the service also verifies the user according to an embodiment of the present invention. [Figure 8] A diagram showing the process flow of submitting the user's electronic signature after verifying the contracting party on the blockchain using a QR code when signing an electronic signature in accordance with an embodiment of the present invention. [Figure 9] 1 is a diagram showing a process for confirming information of a service provider offline using a QR code and then transmitting personal information of a user to the service provider according to an embodiment of the present invention. [Figure 10] 1 is a diagram showing the flow of submitting user authentication information after confirming a transacting party using authentication BLE in an offline environment at a distance of 2M or more according to an embodiment of the present invention. [Figure 11] 1 is a diagram showing the service flow of a first embodiment of a method for conducting a remittance transaction after confirming the VP of the remittance recipient according to an embodiment of the present invention. [Figure 12] An example of a service screen for the case in Figure 11. [Figure 13] A diagram showing the service flow of a second embodiment of a method for conducting a remittance transaction after confirming the VP of the remittance recipient according to an embodiment of the present invention. [Figure 14] An example of a service screen for the case in Figure 13. [Figure 15] 1 is a diagram showing a service flow for a method of conducting a withdrawal transaction of virtual currency according to an embodiment of the present invention. [Figure 16] An example of a service screen for the case in Figure 15. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] The present invention can be modified in various ways and can have various embodiments, and a specific embodiment will be described in detail with reference to the drawings. However, this does not limit the present invention to the specific embodiment, and it should be understood that the present invention includes all modifications, equivalents, or alternatives within the spirit and technical scope of the present invention.

[0024] In describing the present invention, if a detailed description of related prior art is deemed to unnecessarily obscure the gist of the present invention, the detailed description will be omitted. In addition, numbers (e.g., 1, 2, etc.) used in the description of this specification are merely identification symbols for distinguishing one component from another.

[0025] In addition, throughout the specification, when a component is referred to as being "connected" to or "accessed" from another component, it should be understood that the component can be directly connected to or accessed from the other component, but can also be connected to or accessed via an intermediate component, unless otherwise specified. In addition, throughout the specification, when a part "includes" a certain component, this does not mean excluding other components, but means that the part can further include other components, unless otherwise specified.

[0026] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[0027] For this purpose, a general conventional DID technique will be clearly explained.

[0028] FIG. 1 is a diagram showing the flow of logging in to a website using online user authentication based on a standard DID according to a conventional method, and FIG. 2 is a diagram showing the flow of electronic signing using online user authentication based on a standard DID according to a conventional method.

[0029] Figure 1 shows the service process flow when a QR code displayed on a PC is scanned with a general DID wallet app and a VP value for user authentication is submitted via the return URL included in the QR code, and Figure 2 shows the service process flow when an electronic signature is performed with content that is too large to be included in the QR code, in which a transaction message is requested and received via the service provider's return URL, and a VP with an electronic signature is submitted for the message. In this general user authentication or electronic signature flow, the service provider provides a QR or link with an address for submitting the user's VP to the user's wallet, and the user submits the VP to the URL address or link to perform user authentication or electronic signature. In other words, the authentication process based on the standard DID according to the conventional method only performs user authentication, and does not verify the authenticity of the service provider providing the corresponding service or the party requesting the electronic signature.

[0030] In contrast, the present invention provides a DID-based online mutual authentication and electronic signature technology that first checks whether a service requesting user authentication is a legitimate service and then transmits a user authentication value to the corresponding service, and also provides an offline mutual authentication and electronic signature technology that first checks whether a transaction partner (or IoT device) is a legitimate partner offline and then transmits a user authentication value. In this regard, the technical scheme of the present invention will be described in detail below with reference to Figures 3 to 10.

[0031] In Figures 3 to 6, Holder (DID Wallet) is an application program installed on a user's mobile terminal and refers to the user's DID wallet, PC (Personal computer) refers to a terminal used by a user to use a specific online service, and Verifier refers to a counterparty system that authenticates or transacts with the user (e.g., in the case of Figures 3 and 4, the system of an online service provider, and in the case of Figures 5 and 6, the counterparty system of an offline transaction).

[0032] Also, in Figures 3 to 6, SVC (Service Verifiable Credential) refers to the other party's VC (Verifiable Credential) issued by a specified issuing agency (Issuer), and SVP (Service Verifiable Presentation) refers to the other party's VP (Verifiable Presentation) generated from the SVC.

[0033] [Online mutual authentication based on DID - User authentication information is sent after confirming the service provider through SVP] FIG. 3 is a diagram showing the flow of electronic signing with online user authentication based on standard DID including SVC verification.

[0034] Referring to Figure 3, when a user requests a specific service provided by a certain online service provider on his / her PC (see reference number 1 in Figure 3), the other system of the online service provider returns a QR code so that the QR code can be displayed on the user's PC screen (see reference number 3 in Figure 3). At this time, the QR code contains not only a return URL requesting the user's VP, but also the online service provider's own VP (i.e., SVP).

[0035] Thereafter, when the user recognizes the QR code using the DID wallet installed on his / her mobile device (see reference number 4 in Figure 3), the user's DID wallet uses the SVP acquired through the QR code recognition to verify the authenticity of the other party's online service provider (see reference number 5 in Figure 3).

[0036] At this time, the process of verifying the authenticity of the other party through the user's DID wallet is as follows.

[0037] First, the user's DID wallet refers to the Distributed Identification information (DID) information (which is a type of public key address) included in the SVP acquired through QR code recognition, queries the public key in the corresponding blockchain system, and uses the retrieved public key to decrypt the data included in the SVP.

[0038] At this time, the re-call SVP may include the other party's VC (i.e., SVC) and the other party's digital signature value. In addition, the SVC included in the re-call SVP may include identification information that can identify the other party (hereinafter, this is abbreviated as other party identification information), as well as the digital signature value and public key address of the issuer who issued the SVC.

[0039] Thus, the user's DID wallet verifies the other party's digital signature value using the public key corresponding to the SVP. More specifically, the user's DID wallet can verify the authenticity of the other party's digital signature value (i.e., verify the authenticity of the SVP) by checking whether the digital signature value generated using the public key corresponding to the SVP and a predetermined hash function (this is the hash function used when the other party generated the corresponding digital signature value) matches the other party's digital signature value included in the decoded SVP.

[0040] In addition, the user's DID wallet verifies the issuer's digital signature value. More specifically, the user's DID wallet first obtains the issuer's public key using the issuer's public key address included in the SVC, and then verifies the authenticity of the issuer's digital signature value (i.e., verifies the authenticity of the SVC itself) by checking whether the digital signature value generated using the obtained issuer's public key and a predetermined hash function (this is the hash function used when the issuer generated the digital signature value) matches the issuer's digital signature value included in the SVC.

[0041] As mentioned above, when the authenticity verification of the SVP and SVC is completed, the user's DID wallet displays the counterparty identification information included in the re-call SVP (i.e., the verified counterparty identification information) on the wallet app screen. This allows the user to check the verified counterparty identification information on the wallet app screen, and through this, to check the authenticity of the counterparty.

[0042] Once the authenticity of the other party is confirmed through the above process and the user performs the confirmation process (e.g., clicking the Confirm button) through the wallet app screen, the user's DID wallet generates the user's VP and submits the user's VP to the Verifier (i.e., the other party's system) or to the submission destination (i.e., return URL, etc.) specified by the SVC (see reference numbers 6 and 7 in Figure 3). At this time, the user's VP submission process and the subsequent service processing process based on user authentication (see reference numbers 8 to 10 in Figure 3) are essentially the same processes as those in Figures 1 and 2, so detailed descriptions thereof will be omitted.

[0043] The service provider (the Verifier in Figure 3), which is the counterpart system, can provide a statically generated SVP or a dynamically generated SVP. In this case, to provide a dynamic SVP, the service must have a DID wallet on the service side.

[0044] In this case, the service-side DID wallet can load the SVP into the QR code, or load the network access information of the repository that can access the SVP into the QR code, and then provide the QR code to the user.

[0045] An example of a screen showing a service process for the online mutual authentication case of FIG. 3 is shown in FIG.

[0046] At this time, the online service mutual authentication process of Fig. 3 described above can be similarly applied to the electronic contract process in Fig. 4. Fig. 4 shows a process of transmitting a user's signature for an electronic contract after confirming a service provider in an SVP in the case of a DID-based online electronic signature. An example of a screen of a service processing process related to the online mutual authentication case of Fig. 4 described above is shown in Fig. 8.

[0047] The online service mutual authentication process of Figure 3 can also be similarly applied to the offline mutual authentication cases of Figures 5 and 6. Although a QR code can be used in such offline mutual authentication cases (see the service processing process screen example of Figure 9), Figures 5 and 6 show an example in which a Bluetooth Low Energy beacon (BLE beacon) that transmits short-distance wireless signals is used. By using a BLE beacon in this way, a service can be implemented in which offline mutual authentication can be performed even at a distance of more than 2 meters.

[0048] In order to implement the offline mutual authentication service using the above-mentioned BLE beacon, the other system or the device linked thereto must be equipped with a BLE beacon transmission module. At this time, if the device equipped with the BLE transmission module is a mobile terminal, it can only operate as a client and cannot operate as a server, so it is impossible to include and send an SVP in the message of the BLE beacon signal. Therefore, when implementing the offline mutual authentication service using the BLE beacon, a Terminal Information Server (TIS) can be additionally configured as shown in Figures 5 and 6. In Figures 5 and 6, the TIS is shown as a device independent of the Verifier, which is the other system, but it can be included in the Verifier depending on the implementation method of the system, or it can be implemented to be linked to the blockchain system.

[0049] [Offline mutual authentication - A method to authenticate users after confirming the offline counterpart with SVP using BLE beacon and TIS] FIG. 5 is a diagram showing a flow of offline mutual authentication between a user and a counterpart user through authentication BLE.

[0050] Referring to Figure 5, the user's DID wallet receives a BLE beacon signal from the other party (see reference numeral 1 in Figure 5), and can obtain the UUID (i.e., terminal identification information) included in the BLE beacon signal. Of course, the BLE beacon signal can include terminal authentication information in addition to terminal identification information depending on the implementation method.

[0051] As a result, the user's DID wallet can transmit terminal identification information to the TIS and obtain the other party's SVP corresponding to the terminal identification information (see reference numbers 2 and 3 in Figure 5). Thereafter, the user's DID wallet uses the obtained SVP to perform the other party's authenticity verification process (see reference number 4 in Figure 5). The other party's authenticity verification process at this time is essentially the same as that described in Figure 3 above, so a detailed description thereof will be omitted.

[0052] When the authenticity of the other party is confirmed, the user's DID wallet displays the verified other party confirmation information on the wallet app screen, and when the user completes the other party confirmation, the user's VP can be generated and transmitted to the other party's system (see reference numbers 5 and 6 in Figure 5). At this time, the user's VP submission process and the subsequent service processing process based on user authentication (see reference numbers 7 to 9 in Figure 5) are essentially the same processes as those in Figures 1 and 2, so detailed descriptions thereof will be omitted.

[0053] In the above-mentioned offline mutual authentication process, the user's DID wallet can further add the following process: In other words, the user's DID wallet can determine that the SVP contents are valid only if the unique identification value (UUID) of the other party receiving the BLE beacon matches the unique identification value in the SVP received from the TIS, and display the other party identification information on the wallet app screen.

[0054] In addition, when the user's DID wallet receives the other party's BLE data consisting of the other party's unique identification value and authentication value (a variable value that changes every 60 seconds), it can sign the other party's authentication value with the user's own private key when submitting the user's VP and transmit it to the other party. At this time, the other party's system can further confirm that the user was located near the BLE beacon signal transmission area based on the authentication value included in the user's VP received from the user side in the process of verifying the user's VP in the blockchain system.

[0055] An example of a service processing screen relating to the online mutual authentication case of FIG. 5 described above is shown in FIG.

[0056] [Offline mutual authentication - A method in which SVP authenticates the user after checking the offline IoT] Fig. 6 is a diagram showing a flow of offline mutual authentication between a user and a device through authentication BLE. Referring to Fig. 6, the present invention can be embodied as a mutual authentication technology between a user and an unmanned device (such as an entrance and an alcohol vending machine as shown in Fig. 6) in addition to the offline mutual authentication between people as shown in Fig. 5.

[0057] The above-mentioned blockchain-based authentication and transaction system can be similarly applied to transactions such as remittance, deposit and withdrawal on the blockchain. This will be described below with reference to FIGS. 11 to 16.

[0058] Previously, blockchain transactions emphasized anonymity and did not include personal information of the payee or recipient on the blockchain, but as related laws have been revised, senders and recipients are gradually being identified. In line with this trend, the technology of the present invention described above can be used not only for identity authentication but also for the process of verifying the sender and recipient when trading virtual currency (coins / tokens).

[0059] In the past, users had to send coins / tokens to a public key address without being able to confirm who they were sending the coins / tokens to, which led to mistakes such as inputting the wrong public key address, and even if the public key address was correct, problems occurred when sending to the wrong public key address after selecting the wrong blockchain.

[0060] Therefore, if the technology of the present invention is applied to coin / token remittance transactions, a secure transaction can be carried out by first confirming the recipient information based on the DID, then displaying the recipient confirmation information (recipient name, blockchain, public key address, etc.) included in the corresponding DID information in the wallet to the user, and if the user agrees, having the remittance amount entered into the corresponding deposit address, the public key address, and transmitting the transaction via the blockchain. Depending on the implementation method of the system, it is also possible to implement a wallet that includes even the remittance amount in the DID information, allowing users to transmit transactions without having to enter the remittance amount.

[0061] More specifically, it is a mobile-to-mobile transaction between users as shown in Figures 11 and 12. Here, Figure 11 is a diagram showing a service flow of a first embodiment of a method for performing a remittance transaction after verifying the VP of the remittance recipient according to an embodiment of the present invention, and Figure 12 is an example of a service screen in the case of Figure 11.

[0062] Referring to Figures 11 and 12, a person who wishes to receive money via mobile presents VP information containing the recipient's information in a QR code (or network access information that can acquire the recipient's VP information can be presented in a QR code), and a person who wishes to send money acquires the VP information presented by the recipient and verifies it in the blockchain. After confirming the recipient's information on the screen, the sender confirms the recipient's information. After that, the remittance address is fixed with the recipient's blockchain and public key address included in the VP, and the remittance amount is entered in the wallet and the transaction is transmitted.

[0063] Another application example is an example of depositing coins / tokens held in one's mobile wallet to a virtual currency exchange website, which is shown in Figures 13 and 14. Another application example is an example of withdrawing coins / tokens held on a virtual currency exchange website to one's mobile wallet, which is shown in Figures 15 and 16.

[0064] Referring to Figures 13 and 14, when a depositor wishes to deposit coins / tokens held in his / her mobile wallet to a virtual currency exchange website, the depositor scans a QR code for obtaining VP presented by the virtual currency exchange with his / her mobile wallet, verifies the virtual currency exchange's VP on the blockchain, and presents the verified VP information to the user. If the user agrees with the depositor information, the user enters only the amount he / she wishes to enter on the mobile device while fixing the blockchain, recipient address, etc. using part of the information included in the VP in the wallet, and then transmits the transaction on the mobile app.

[0065] Also, referring to Figures 15 and 16, when a user wishes to withdraw coins / tokens held on the website of a virtual currency exchange to his / her mobile wallet, he / she first scans the QR code for VP submission provided by the exchange with the mobile wallet, and submits his / her (i.e., the withdrawer) VP stored in the wallet at the address included in the QR code with the mobile wallet. The website of the virtual currency exchange then verifies the submitted VP of the user on the blockchain, and if the user agrees to the withdrawal information on the web screen, it fixes the blockchain, the recipient address, etc. using part of the information included in the VP, and then the user enters the withdrawal amount, and the exchange transmits the transaction on the blockchain.

[0066] The above-mentioned blockchain-based authentication and transaction system according to the present invention can be embodied as computer-readable code in a computer-readable recording medium. The computer-readable recording medium includes all types of recording media in which data readable by a computer system is stored. For example, there are read only memories (ROMs), random access memories (RAMs), magnetic tapes, magnetic disks, flash memories, optical data storage devices, etc. In addition, the computer-readable recording media can be distributed among computer systems connected by a computer communication network and stored and executed as readable code in a distributed manner.

[0067] Although the present invention has been described above with reference to an embodiment thereof, it will be readily understood by those skilled in the art that the present invention can be modified and changed in various ways without departing from the spirit and scope of the present invention as set forth in the claims below.

Claims

1. In a blockchain-based authentication and transaction system including a user's Distributed Identity (DID) wallet, which is an application program installed on a user's mobile device, The user's DID wallet is When the verifiable presentation (VP) of the other party provided by the system of the other party to be authenticated or transacted is acquired, the VP of the other party is verified, and the verified information of the other party is displayed on the screen to the user. A terminal identification value is extracted from a short-range wireless signal transmitted from the other party's system or an interlocking device interlocked with the other party's system, and the extracted terminal identification value is transmitted to a terminal information system (Terminal Information Server) to obtain the other party's VP corresponding to the terminal identification value from the terminal information system. A blockchain-based authentication and transaction system.

2. The user's DID wallet is Recalling the VP of the other party using a public key corresponding to the VP of the other party, and verifying the electronic signature of the other party included in the re-call VP; The digital signature of the issuer who issued the VC of the other party is obtained from the VC (Verifiable Credential) of the other party included in the re-called VP, and the digital signature of the issuer is verified with the public key of the issuer.

2. The blockchain-based authentication and transaction system according to claim 1, wherein verified counterparty identification information is displayed on a screen to a user.

3. The other party's DID wallet is an application program installed in the other party's system; The counterparty VP is a static VP of a fixed value generated in advance, or a dynamic VP dynamically generated at the time of authentication or transaction by encrypting the counterparty's verifiable credential (VC) issued in advance by the counterparty's DID wallet with a private key, The other party's DID wallet loads the other party's VP into a QR (Quick Response) code, or loads the network access information of a storage facility that can access the other party's VP into the QR code, and then provides the QR code to the user. The blockchain-based authentication and transaction system according to claim 1, wherein the user's DID wallet acquires the other party's VP by recognizing the QR code.

4. The user's DID wallet is The blockchain-based authentication and transaction system according to claim 1, characterized in that the VP of the user is submitted to the other party's system or a submission destination designated in the other party's VC (Verifiable Credential) only if the user authenticates the other party through the other party identification information displayed on a screen.

5. The user's DID wallet is Recalling the VP of the other party using a public key corresponding to the VP of the other party, and verifying the electronic signature of the other party included in the re-call VP; The blockchain-based authentication and transaction system of claim 1, further comprising: a verification as to whether a terminal identification value extracted from the short-range wireless signal matches a terminal identification value of the other system included in the called VP; and only if the verification is successful, the VP of the user is submitted to the other system or a submission destination designated in the other party's VC (Verifiable Credential).

6. If the transaction is a blockchain-based remittance transaction, The user's DID wallet is 2. The blockchain-based authentication and transaction system of claim 1, further comprising: a screen for inputting a remittance amount to a deposit address according to the recipient information displayed on the screen as the counterparty identification information; and when a user inputs a remittance amount, the transaction is transmitted to the corresponding deposit address.

Images