Private key distributed management system and program

Abstract

To eliminate, for a user, the hassle of storing a signing key and provide a safe and robust wallet that is resistant to a risk such as loss or theft.SOLUTION: A distributed private key management system includes a user terminal operated by a user, SNS server(s) for authenticating a user from the user terminal, wallet certification authority server(s) for issuing a UUID for the user on the basis of the results of the authentication in the SNS server(s), a smart contract placed on a blockchain network and having a cryptographically non-transferable (non-assignable) function, and distributed storage server(s) (IPFS) placed in a distributed manner on the Internet for storing content referenced by the smart contract, and private keys are managed in a distributed manner among the user terminal, the wallet certification authority server(s), the smart contract, and the distributed storage server(s).SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a private key management technology in public key cryptography, and more specifically to a system for managing private keys in blockchain-related technology. [Background technology]

[0002] In recent years, continuous improvements have been made to blockchain technology to ensure safe and smooth transactions of digital information such as crypto assets, coins, and tokens. One of the elemental technologies of blockchain technology is public key cryptography, which generates a pair of private and public keys and verifies identity by knowing the private key. Furthermore, several efforts have been made to improve blockchain technology regarding private key management technology. Behind these efforts is the risk of private keys being stolen or lost in systems that use private keys to verify identity. However, there are concerns that strict management of private keys by a system could lead to reduced convenience for users.

[0003] Against this background, digital asset management systems for crypto assets and the like have been provided to balance user convenience with the security of private key management (Patent Document 1, Patent Document 2).

[0004] Specifically, Patent Document 1 discloses a digital asset management system for mutually managing a user's digital assets between the user, the service provider, and the management company, which includes a tally generation means for dividing secret information for accessing the digital assets into at least four tally portions using a secret sharing method, and a consent determination means for deeming the user's access legitimate on the condition that a predetermined threshold number of tally portions has been collected, and at least three of the tally portions are distributed to the user, the service provider, and the management company, respectively, as regular tally portions, and the difference between the number of tally portions and the threshold number is stored as redundant tally portions.

[0005] Patent Document 2 also discloses a digital asset management system for mutually managing a user's digital assets between the user, the service provider, and the management company, which includes a tally generation means for dividing secret information for accessing the digital asset into at least four tally portions using a secret sharing method, and a consent determination means for deeming the user's access legitimate on the condition that a predetermined threshold number of tally portions has been collected, and at least three of the tally portions are distributed to the user, the service provider, and the management company, respectively, as regular tally portions, and the difference between the number of tally portions and the threshold number is stored as redundant tally portions.

[0006] Furthermore, hardware wallets that are not connected to an autonomous decentralized network, which have traditionally been used for the safe management of cryptocurrency data, have limitations in terms of convenience. To address this issue, a system has been proposed that enables safe and convenient operations in the finance technology market (Patent Document 3).

[0007] That is, Patent Document 3 describes an electronic tally-type storage system that has a plurality of node computers connected to an autonomous decentralized network and enables cryptocurrency transactions using a decentralized blockchain, in which a user's private key is split and distributed and stored among a plurality of anonymous node computers, the plurality of node computers including node computers of a plurality of users participating in cryptocurrency transactions and a monitoring node computer, the user's node computer having an autonomous decentralized electronic tally wallet, the autonomous decentralized electronic tally wallet being means for splitting the private key, being authenticated by the monitoring node computer using a one-time encryption key, sending each portion of the split private key to the monitoring node computer and issuing a storage request command, the monitoring node computer having an anonymous selection means, the anonymous selection means being means for randomly selecting a plurality of anonymous node computers from the plurality of node computers connected to the autonomous decentralized network based on the storage request command from the user's node computer, registering their addresses, and distributing and storing each portion of the split private key among the selected anonymous node computers. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] Japanese Patent Publication No. 2020-58007 [Patent Document 2] Japanese Patent Publication No. 2020-58008 [Patent Document 3] Japanese Patent Application Publication No. 2020-155911 Summary of the Invention [Problem to be solved by the invention]

[0009] However, even with the above-mentioned conventional technology in mind, further improvements are needed to enhance security for users who store split private keys. Specifically, it is desirable to provide a non-custodial wallet that does not require users to be aware of the hassle of storing signing keys, and that is safe and robust against risks such as loss or theft, and that has functions such as restoration and key rotation for blockchains.

[0010] A non-custodial wallet is a cryptocurrency wallet where the user manages the keys, and includes both hardware and software wallets. On the other hand, a custodial wallet is a wallet where a third party holds or manages the keys. [Means for solving the problem]

[0011] Therefore, a private key distributed management system according to one embodiment of the present invention is a private key distributed management system comprising: a user terminal operated by a user; SNS server(s) for authenticating the user from the user terminal; wallet certificate authority server(s) for issuing a UUID for the user based on the result of the authentication in the SNS server(s); a smart contract (NFT) arranged on a blockchain network and having a cryptographically non-transferable (non-assignable) function; and distributed storage server(s) (IPFS) arranged in a distributed manner on the Internet for storing content referenced by the smart contract (NFT), wherein the user terminal generates a secret vector (S) based on the UUID and a message input by the user and transmits it to the wallet certificate authority server(s), the wallet certificate authority server(s) generate a secret vector (A) based on the secret vector (S) and a random number generated by itself, and the smart contract (NFT) issues a UUID for the user. a distributed storage server (IPFS) generates a secret vector (B) based on the secret vector (A) and a random number generated by the IPFS itself, and the distributed storage server (group) (IPFS) generates a secret vector (C) based on the secret vector (B) and the random number generated by the IPFS itself, and provides the CID stored by the IPFS to the user terminal; the user terminal generates a CID hint vector (A) based on the secret vector (A) and a coordinate vector (D) generated from the random number generated by the IPFS itself, stores the CID hint vector (A) in the wallet certificate authority server (group), derives a quadratic function based on the coordinate vector (D) and the CID, generates a coordinate vector (E) from the random number R generated by the IPFS itself and a Y value derived from the random number R in the quadratic function, generates a CID hint vector (B) based on the coordinate vector (E) and the secret vector (B), and stores the hint vector (B) in the smart contract (NFT), thereby performing distributed management of private keys.

[0012] Furthermore, the personal authentication performed by the SNS server(s) is performed between the user terminal and the wallet authentication authority server(s), making the SNS server(s) unnecessary.

[0013] The secret key is shared based on the Shamir secret sharing scheme.

[0014] The secret key is shared based on a (3,4) threshold secret sharing scheme using the quadratic function. [Effects of the Invention]

[0015] The private key distributed management system according to one embodiment of the present invention has advantageous effects such as making it possible to provide a non-custodial wallet with functions for blockchain that is safe and robust against risks such as loss or theft, without making users aware of the hassle of storing signing keys. [Brief explanation of the drawings]

[0016] [Figure 1] 1 is an explanatory diagram illustrating an example of the overall configuration of a private key distribution management system according to an embodiment of the present invention; [Figure 2A] FIG. 2 is an explanatory diagram illustrating the functional block configuration of various servers in the private key distributed management system according to one embodiment of the present invention. [Figure 2B] 1 is an explanatory diagram illustrating the functional block configuration of a tablet terminal as one form of user terminal in a private key distributed management system according to one embodiment of the present invention; [Figure 3] FIG. 2 is an explanatory diagram illustrating an example of the operation of a private key distribution management system according to one embodiment of the present invention. [Figure 4] 1 is an explanatory diagram illustrating the technical concept of shared private key management in a shared private key management system according to one embodiment of the present invention; [Figure 5]1 is an explanatory diagram illustrating an example of processing for shared private key management in a shared private key management system according to one embodiment of the present invention, from the perspective of data; [Figure 6] 1 is an explanatory diagram illustrating an example of processing for shared private key management in a shared private key management system according to one embodiment of the present invention, from the perspective of data. [Figure 7] 1 is an explanatory diagram illustrating an example of processing for shared private key management in a shared private key management system according to one embodiment of the present invention, from the perspective of data; [Figure 8] 1 is an explanatory diagram illustrating an example of processing for shared private key management in a shared private key management system according to one embodiment of the present invention, from the perspective of data; [Figure 9] 1 is an explanatory diagram illustrating an example of processing for shared private key management in a shared private key management system according to one embodiment of the present invention, from the perspective of data; [Figure 10] FIG. 1 is an explanatory diagram illustrating, from the perspective of data, an example of processing for deriving a private key in a private key distributed management system according to one embodiment of the present invention. [Figure 11] FIG. 1 is an explanatory diagram illustrating, from the perspective of data, an example of processing for deriving a private key in a private key distributed management system according to one embodiment of the present invention. [Figure 12] FIG. 1 is an explanatory diagram illustrating, from the perspective of data, an example of processing for deriving a private key in a private key distributed management system according to one embodiment of the present invention. [Figure 13A] FIG. 1 is an explanatory diagram illustrating, from the perspective of data, an example of processing for deriving a private key in a private key distributed management system according to one embodiment of the present invention. [Figure 13B] 10 is a flowchart illustrating an example of a process for deriving a private key in a private key distributed management system according to one embodiment of the present invention. [Figure 14] FIG. 1 is an explanatory diagram illustrating an example of key rotation processing in a private key distribution management system according to one embodiment of the present invention, from the perspective of data. [Figure 15] FIG. 1 is an explanatory diagram illustrating the technical concept of the present invention. [Figure 16] 1 is an explanatory diagram illustrating an example of a technology that is the premise of a private key distribution management system according to one embodiment of the present invention; DETAILED DESCRIPTION OF THE INVENTION

[0017] Below, we will explain the technical concept of the present invention and an example of the underlying technology in one embodiment of the present invention, and then we will explain in detail the private key distributed management system and other aspects of one embodiment of the present invention with reference to the drawings.

[0018] (Technical idea of the present invention) First, the technical concept of the present invention will be described with reference to Fig. 15. This explains the technical viewpoint underlying the present invention and the future technical outlook that the present invention envisions.

[0019] The core of the present invention is a technical concept of a gateway bridge that bridges Web 2.0 and Web 3.0. As shown in FIG. 15, a gateway bridge 1502 embodying the technical concept of the present invention is equipped with an identity broker with an intermediary function that connects multiple service providers to different identity providers, thereby connecting to numerous conventional Web 2.0 services 1501. Specifically, ID federation, as described below, is adopted. The gateway bridge itself functions as a wallet supported by a cryptographic infrastructure and manages externally owned accounts (EoA), enabling it to connect to future Web 3.0 services supported by blockchain. As shown in FIG. 15, the Web 3.0 services are assumed to be blockchains 1503 consisting of smart contracts that manage and control contract accounts.

[0020] Here, we will explain in more detail the significance of the technical concept of this invention functioning as a gateway bridge between Web 2.0 and Web 3.0. In Web 2.0, web services expanded the scope of web usage and brought about many technological innovations, and one of the technological elements supporting this innovation is ID federation between web services. Meanwhile, in the world of Web 3.0, it is believed that all value can be created, held, and exchanged through tokens. In other words, Web 3.0 advocates the next generation of decentralized internet, and within this, blockchain technology plays an important role in enhancing the security and convenience of services.

[0021] However, Web 3.0 is not intended to completely replace Web 2.0; rather, it is the addition of a token economy to the world of Web 2.0, and it is more appropriate to understand that Web 2.0 and Web 3.0 coexist.

[0022] In this regard, the fundamental technical concept of this invention is that IDs are what connect Web 2.0 and Web 3.0. IDs in Web 2.0 are centrally managed IDs managed by platforms (or web services), while IDs in Web 3.0 are self-sovereign decentralized IDs (DIDs) managed by individuals or groups (communities and other organizations). Here, it is appropriate to think of DIDs as being linked to wallets. The present invention is based on this fundamental technical idea.

[0023] More specifically, a wallet structure could be envisaged that would issue DIDs (for example, NFTs (Non-Fungible Tokens) and SBTs (Soul Bound Tokens)) for Web 3.0 services in a way that integrates authentication by IdPs (ID Providers) provided by Web 2.0 services, i.e., in a way that is not dependent on a specific Web 2.0 service, and use these as entry points for Web 3.0 services; it would not be surprising if services with such a structure were to become commonplace in the future. At this point, concepts such as "membership management" would no longer be necessary for Web 3.0 services, but it is entirely conceivable that services designed in this way would become mainstream.

[0024] Further considering this based on the technical concept of this invention, if we think of an ID as a wallet, who would be the custodian (management institution) of the signing key? Various management forms are conceivable, including (1) platform-managed, (2) community-managed, (3) project-managed, (4) group / team-managed, and (5) individual-managed. However, rather than categorizing these as either institutional or individual, it is more natural to view them as having a loose relationship ranging from institutional management to individual management. In this sense, the difference between custodial and non-custodial, which is often discussed in relation to cryptocurrency wallets, is merely a matter of who is in charge of management.

[0025] In other words, the question of where to place the gateway connecting Web 2.0 and Web 3.0 in terms of service type becomes a question of where to set up the custodian.

[0026] (Example of prerequisite technology in one embodiment of the present invention) In the present invention, although not limited to this, the Shamir secret sharing scheme is adopted as a method for dividing secret information into multiple tally tokens and restoring the original secret information by bringing together a certain number of the tally tokens. The Shamir secret sharing scheme is said to be suitable for secret sharing of small information. Here, for the purpose of understanding the present invention, the Shamir secret sharing scheme will be described with reference to FIG.

[0027] The basic principle of Shamir's secret sharing scheme is based on the mathematical property that, when considering the graph of a k-1-degree function, once k coordinates have been determined, a polynomial that passes through all of those coordinate points can be determined. For example, two coordinate points are required for a linear function, three coordinate points for a quadratic function, and four coordinate points for a cubic function; once the number of coordinate points corresponding to the degree is known, the polynomial can be identified.

[0028] Although there are an infinite number of candidate coordinates on the graph of a particular polynomial, one method involves selecting several fixed values of x, dividing the tally into n pieces and distributing them based on a (k,n) threshold secret sharing scheme, and then collecting k of the tally pieces to restore the secret information. As mentioned above, the number k of tally pieces that needs to be collected depends on the degree of the function used to advance the secret sharing scheme. In many cases, quadratic functions are used, and one embodiment of the present invention can also be designed to employ a (3,4) threshold secret sharing scheme using a quadratic function.

[0029] In this case, the secret information is divided into four tally pieces and distributed, and if three of the tally pieces can be collected, the original secret information can be identified.

[0030] The robustness of secret information based on this method can be explained as follows with reference to FIG. 16. That is, for each of the quadratic functions shown in FIGS. 16(A) to 16(C), let us assume that the coordinates of two points, point A (x=-1) and point B (x=1), are known (for example, let us assume that this information is leaked). However, the coordinates of these two points alone do not allow us to identify the polynomial of the quadratic function (each parabola in FIGS. 16(A) to 16(C)). For example, it is impossible to know the intercept (S)=(x=0) (secret information) with the y-axis of each quadratic function in FIGS. 16(A) to 16(C) or the coordinates of the vertex (P) and point C (x=2). In this figure, for ease of understanding, the x-coordinate is fixed as (-1, +1, +2) and vertical auxiliary lines are drawn, but in reality, the x-coordinate can be determined randomly as shown in the examples described below.

[0031] FIG. 1 shows an example of the overall configuration of a distributed private key management system according to one embodiment of the present invention.

[0032] As shown in FIG. 1, in one embodiment, the private key distributed management system 10 is configured with various information processing devices used by users, etc. (The figure exemplarily shows a PC 11a, mobile information terminals 11b to 11d including a smartphone and a tablet terminal. Hereinafter, these may be collectively referred to as "various terminals," "user terminals," or simply "terminals"), an Idp server(s) 12, a wallet certification authority server(s) 13, an object distributed storage server(s) 14, and a blockchain network 15 (hereinafter referred to as blockchain 15). In one embodiment, the blockchain network 15 is configured such that each of its constituent terminals (151 to 158) is connected peer-to-peer to form a network.

[0033] Also, in Figure 1, for the sake of convenience, the blockchain 15 is depicted as if it were a network independent of the Internet 19, but in reality, the blockchain 15 may also be configured in a form that is incorporated into the Internet.

[0034] Each of the various servers 12 to 14 can form a group consisting of a plurality of servers. Also, each of the various server(s) 12 to 14 can be configured as a plurality of types of server(s), for example, Idp server(s) 12a, Idp server(s) 12b, etc.

[0035] The various terminals are connected to each other so that they can communicate with each other via dedicated lines or public lines such as the Internet (wired lines: 16a to 16d, 17, and 19) as shown in Figure 1. The lines may be wired or wireless, and in the wireless case, mobile information terminals 11b to 11d access the Internet 19 wirelessly via base stations or access points (not shown), and are further connected to various servers (groups) 12 to 14 and a blockchain 15 so that they can communicate with each other via lines 16b to 16d and 17.

[0036] Here, an access point is a wireless device that connects wireless terminals such as PCs and mobile information terminals to each other or to other networks. Typically, it is a device that operates using communication protocols in Layer 1 (physical layer) and Layer 2 (data link layer) of the OSI reference model.

[0037] At the time of filing this application, many of the mobile information terminals or tablets have processing capabilities (communication processing speed, image processing capabilities, etc.) equivalent to those of personal computers (PCs), and can be considered small computers.

[0038] In addition, the program or software necessary for implementing the present invention is typically installed or stored on an HDD, SSD, etc. in the storage unit of a PC or mobile information terminal, and when the program or software is executed, all or part of it is read out as a software module into the memory in the storage unit as needed, and is calculated and executed by the CPU.

[0039] Alternatively, a browser-based computer or mobile information terminal can be used, in which case programs are distributed to the terminal from other servers or computers as needed, and executed in the browser on the terminal.

[0040] Furthermore, the hardware configuration of the various server(s) 12 to 14 can basically be PCs (for clarity, this will be described later with reference to FIG. 2A). Although the present invention is not limited to this, the various server(s) 12 to 14 can also be configured to be suitable for processing large amounts of data by operating multiple PCs (for example, tens to tens of thousands) in parallel to increase the hardware specifications as needed.

[0041] On the other hand, depending on the system configuration, some of the information processing terminals (for example, the PC 11a and the portable information terminals 11b to 11d) may be made to take on some or all of the functions of the various servers (groups) 12 to .

[0042] Although not shown in Figure 1, one embodiment of the present invention is also envisioned in which IoT devices, AI, robot terminals, etc. each have their own administrator (human) wallet. Even in this case, an external IdP server will be responsible for authentication via the administrator's operation. In this sense, the SNS server group provided when a user communicates over a network via a user terminal is one form of the external IdP server 12. In addition to the SNS server group, the external IdP server group also includes directory services such as LDAP that are individually managed by companies.

[0043] 2A shows a functional block diagram of various servers (IdP server, wallet certification authority server, etc.; hereinafter, referred to as "servers" in the description of this figure) in a private key distributed management system according to one embodiment of the present invention. Illustratively, the operation of the various servers is realized by the individual operations of the hardware described below, and the cooperative operation of the software and this hardware.

[0044] In FIG. 2A, server 200 as an entire hardware block is broadly composed of CPU 201 for performing various comparison and calculation processes, memory unit 202 such as RAM, ROM, flash memory, etc., input unit 203 such as a keyboard or pointing device, output unit 204 such as a display or speaker, control unit 205 for controlling various signals, communication (interface) unit 206 (whether wireless or wired), clock unit 207 for measuring the time, etc., and power supply unit 208.

[0045] These modules are connected as needed by appropriate communication buses and power supply lines (collectively shown as connection 249 in FIG. 2A for convenience).

[0046] In addition, the programs or software executed on the management server 200 necessary for implementing the present invention are typically installed or stored on a hard disk disk, SSD (Solid State Drive), flash memory, etc. that constitutes the memory unit 202, and when the programs or software are executed, all or part of them are read out as software modules into the memory in the memory unit 202 as needed, and are calculated and executed by the CPU 201.

[0047] The calculations do not necessarily have to be performed by a central processing unit such as the CPU 201, but can also be performed by an auxiliary calculation device such as a digital signal processor (DSP) (not shown).

[0048] 2B shows an example of a functional block diagram of hardware constituting mobile information terminals 11b to 11d as user terminals according to one embodiment of the present invention. The operations of mobile information terminals 11b to 11d are realized by the individual operations of the hardware, which will be described below, and the cooperative operations between software and these hardware.

[0049] In FIG. 2B, the mobile information terminal 250 as an entire hardware block is broadly composed of an input unit 251 consisting of hardware buttons, a multi-touch input panel provided on a display, a microphone, etc.; a memory unit 252 consisting of a hard disk for storing programs, data, etc., RAM and / or ROM, etc.; a central processing unit 253 consisting of a CPU that performs various numerical calculations and logical operations using programs; a display unit 254 consisting of a display, etc.; a control unit 255 for controlling chips and electrical systems, etc.; a communication interface unit 256 consisting of a slot for accessing the Internet, a port for optical communication, and a communication interface; an output unit 257 including a speaker, vibration, an infrared projector, etc.; a timing unit 258 for timing the time, etc.; a sensor unit 259 consisting of an image sensor such as a CMOS, an infrared sensor, an inertial sensor, etc.; and a power supply unit 260 for supplying power to each module within the device, and these modules are connected as necessary by communication buses and power supply lines (collectively shown as connection 299 in FIG. 2B for convenience).

[0050] The sensor unit 259 may include a GPS sensor module for identifying the position of the portable information terminal 250 (11a to 11d). Signals detected by an image sensor such as a CMOS or an infrared sensor constituting the sensor unit 259 can be processed as input information in the input unit 251.

[0051] In addition, the programs or software executed on the mobile information terminal 250 necessary for implementing the present invention are usually installed or stored in a hard disk disk, SSD (Solid State Drive), flash memory, etc. that constitutes the memory unit 252, and when the programs or software are executed, all or part of them are read out as software modules into the memory in the memory unit 252 as needed, and are calculated and executed by the CPU 253.

[0052] The calculations do not necessarily have to be performed by a central processing unit 253 such as a CPU, but an auxiliary calculation device such as a digital signal processor (DSP) (not shown) can also be used.

[0053] 3 shows an example of the operation of a private key distributed management system and the like according to one embodiment of the present invention. From the upper left, the figure shows a "user," a "client application (terminal device)," an "external IdP (SNS, etc.)," a "wallet certification authority server," a "blockchain," and an "object distributed storage (IPFS)" (IPFS stands for InterPlanetary File System). Although the "user" is not shown in FIG. 1, the "client application (terminal device)" corresponds to (a client application installed on) the PC 11a or the mobile information terminals 11b to 11d in the figure, the "external IdP (SNS, etc.)" corresponds to (the ID provision function provided by) the IdP server(s) 12 in the figure, the "wallet certification authority server" corresponds to the wallet certification authority server(s) 13 in the figure, the "blockchain" corresponds to the blockchain 15 in the figure, and the "object distributed storage (IPFS)" corresponds to the object distributed storage server(s) 14 in the figure. The operation example in Figure 3 shows the series of operations that occur when a wallet app installed on a mobile information terminal is launched for the first time by a user, and then SNS authentication, login authentication, and email address authentication are performed, leading up to the user obtaining the authenticated UUID.

[0054] 3, when an application on the user terminal is launched by a user operation, in step S302, it is determined whether a UUID (Universally Unique IDentifier) is held in the application on the user terminal. If a UUID is already held here, a new UUID is not acquired (S303, details omitted). However, if a UUID is not held, the process proceeds to step S304, where an entrance IdP selection display is displayed (at this time, in one embodiment of the present invention, a list of various selectable SNSs, not shown, is displayed). The user selects an IdP for a specific SNS while viewing the list of various selectable SNSs displayed on the application screen of the user terminal (step S305).

[0055] Then, a login request for the selected SNS is sent to the external IdP, and the external IdP sends a login screen to the user terminal (step S305). The login screen of the external IdP is displayed on the user terminal, and the user attempts to log in to the external IdP (step S307). The external IdP performs login authentication (step S308), and if the authentication is successful, the external IdP sends a notification of successful authentication to the wallet certificate authority server (at this time, a request for issuance of a JWS (UUID) may also be made, although this is not shown). In step S308, the wallet certificate authority server issues a JWS (UUID) and sends it to the user terminal.

[0056] In step S310, the JWS (UUID) sent from the wallet certificate authority server is verified in the user terminal, and if it is invalid, the series of processes is terminated (step S311), but if it is determined to be valid, this UUID is acquired in the user terminal as a valid ID issued by the JWS (step S312). The acquired UUID is stored and managed in a memory in the user terminal (not shown).

[0057] (ID federation) Next, an example of ID federation processing performed in a private key distributed management system according to one embodiment of the present invention will be described below. The processing examples (<Process 1-1> to <Process 1-16>) here provide a more detailed and complementary explanation of the processing described with reference to FIG.

[0058] <Process 1-1> The user launches the wallet application installed on the user's user terminal.

[0059] <Process 1-2> The wallet application checks whether the UUID information assigned to the user is stored in the internal storage. If it is retained: It will be considered as the second or subsequent launch. If not retained: It is determined to be the first startup and proceeds to <Process 1-3>.

[0060] <Process 1-3> The wallet application presents a selection list for delegating authentication to an external IdP (such as an SNS) on the screen of the user's terminal as an entrance screen for the service.

[0061] <Process 1-4> The user selects the external IdP of their choice from the external IdPs (SNS, etc.) presented on the screen of the user terminal. At this time, as background processing, when the external IdP (SNS, etc.) is selected, the destination to be notified of the authentication success or failure can be set, and the wallet certification authority can be specified here as the destination to be notified of the authentication success or failure.

[0062] <Process 1-5> The external IdP (SNS, etc.) selected by the user prompts the user to log in (for example, by displaying a login screen on the screen of the user's terminal).

[0063] <Process 1-6> The user attempts to log in as prompted by the external IdP (SNS).

[0064] <Process 1-7> The external IdP (SNS) performs user login authentication. If authentication is successful: Proceed to <Process 1-8>. If authentication fails: Return to <Process 1-5>.

[0065] <Process 1-8> The external IdP (SNS) sends a notification of successful authentication to the wallet authentication authority designated in advance in <Process 1-4>.

[0066] <Process 1-9> Upon receiving notification of successful authentication, the wallet certification authority issues a randomly generated administrative ID (UUID), generates a signed token (JWS) containing this information, signs it, and then sends the signed token (JWS) to the wallet application.

[0067] <Process 1-10> The wallet application verifies the received signed token (JWS). If it is valid: Proceed to <Process 1-11>. If invalid: The user is notified that the digitally signed token (JWS) is invalid, and the process ends.

[0068] <Process 1-11> The wallet application extracts the enclosed management ID (UUID) from the received signed token (JWS).

[0069] <Process 1-12> The wallet application prompts the user to enter their email address, and once the user enters it, the wallet application sends the entered email address to the wallet certification authority.

[0070] <Process 1-13> When the wallet certification authority receives the user's email address, it issues a one-time URL for email address verification to that email address and sends it along with the URL.

[0071] <Process 1-14> The user who receives the one-time URL clicks on the link of the one-time URL for email address verification described in <Process 1-13>.

[0072] <Process 1-15> When the wallet certification authority detects that a one-time URL has been clicked, it checks the validity of the URL. If valid: Proceed to <Process 1-16>. If the email address is invalid: The user is notified that the email address is invalid, and the process ends.

[0073] <Process 1-16> The wallet certificate authority uses the management ID (UUID) as an index to register and manage the user's email address in a storage (such as a database) within the wallet certificate authority.

[0074] (account abstraction) Next, with reference to Figure 4, we will explain the account abstraction assumed in a private key distributed management system or the like according to one embodiment of the present invention. In one embodiment of the present invention, this account abstraction is positioned as a prerequisite technology for issuing instructions to a smart contract from an externally owned account. The difference between an externally owned account and an abstracted account is whether or not it has a private key for electronically signing a transaction issued to a smart contract. In one embodiment of the present invention, only the externally owned account has a private key.

[0075] The purpose of account abstraction is to establish a relay point (i.e., an abstracted NFT (smart contract) of the account) to ensure that instructions (transactions) continue to be issued from the possession of the same ID, even if the key of the externally owned account of a person with a certain ID is changed.

[0076] In Figure 4, EoA41 is an entity of an Externally Owned Account, which is an account address and wallet address owned by a user on a blockchain platform for building decentralized applications and smart contracts.

[0077] An NFT is a digital token that, once issued, cannot be transferred by anyone other than the owner, and the implementation of an NFT 42 is a smart contract. In one embodiment of the present invention, the NFT 42 can register the EoA address of a user authorized to issue instructions 452, and can define the authorization of the user in the EoA 41 (453).

[0078] Furthermore, other smart contracts (or wallets) 43 are smart contracts separate from NFT 42, and can be viewed as tasks (functions) from the perspective of EoA 41. Furthermore, multiple tasks exist in smart contract 43, and it can also be viewed as a collection of individual tasks.

[0079] In one embodiment of the present invention, an NFT42 is used as a decentralized identity (DID) for accessing a blockchain network and as a base for sending instructions (transactions). Because smart contracts do not hold signing keys, issuing instructions (transactions) to the blockchain network requires that the instructions be issued from a wallet address that holds the signing key, known as an External Address (EoA).

[0080] Based on this, in a private key distributed management system according to one embodiment of the present invention, instructions are not issued directly to a blockchain network 43 from a wallet address 41 having a signing key called an external address (EoA), but are always issued indirectly via a smart contract 42, i.e., an NFT (instruction 452, instruction 454, instructions 455a to 455c). Here, instruction 452 represents an indirect instruction from the EoA to the smart contract 43. Furthermore, instruction 454 represents an instruction for a certain task (A), and instructions 455a to 455c represent a series of instructions for a task (B) different from task (A). All of these are shown as examples to help understand the concept of this diagram.

[0081] By configuring it in this way, it becomes easy to create a situation where no one other than the owner of the NFT can access the smart contract 43 (other smart contracts or wallets separate from the NFT 42), enabling convenient and flexible system operation.

[0082] This operation is called account abstraction. NFTs that achieve account abstraction have the advantage that they can freely design functions such as control rights and history records according to the smart contract that constitutes the NFT (such as limiting the EoA that can be specified).

[0083] (Private key distribution processing) Next, with reference to FIGS. 5 to 9, it will be described how the private key sharing process is carried out using the UUID obtained by authentication by the wallet authentication authority as a key and the passphrase entered by the user as a message.

[0084] FIG. 5 illustrates the secret vector (S) derivation process performed on the user terminal from a data perspective.

[0085] Figure 6 explains the hint allocation process of secret sharing fragments (A) and (C) executed by the wallet certificate authority from the data perspective. Note that the "hint" here refers to the Shamir secret sharing fragment used to synthesize a CID (Content ID). The CID is an ID set when a file is placed in the IPFS (InterPlanetary File System).

[0086] Figure 7 explains the hint placement process of secret sharing pieces (B) and secret sharing pieces (C) executed in the blockchain (smart contract) from a data perspective.

[0087] Figure 8 explains the secret sharing piece (C) allocation process executed on the distributed storage server (IPFS) from the data perspective.

[0088] FIG. 9 explains the process of generating hints for secret sharing pieces (C) executed at a user terminal from the viewpoint of data.

[0089] 5, an identifier code (UUID) 51 authenticated by a wallet authentication authority is used as a 128-bit key 53, a passphrase 52 entered by a user is used as a free-length message 54, and the key 53 and message 54 are converted into a Hash-based Message Authentication Code (HMAC). This HMAC-converted 512-bit value 55 is divided into 256-bit upper bits 56 and 256-bit lower bits 57. Furthermore, the upper bits 56 and the lower bits 57 are applied to an XOR gate circuit, and the output value is used as a 256-bit secret vector (S) 58. The derived secret vector (S) 58 is stored in the user terminal. It should be noted that the bit lengths of the codes and data shown in the following figures are merely examples, and the individual bit lengths do not limit the present invention.

[0090] 6, two random numbers 601 and 602 are generated by a random number generator (not shown), the random number 601 is set as 128-bit R1, the random number 602 is set as 128-bit R2, and the concatenation of R1 and R2 is made into a 256-bit coordinate vector (A) 603. This coordinate vector (A) 603 and the 256-bit secret vector (S) 604 derived in Fig. 5 are multiplied by an XOR gate, and the output value (256 bits) is made into secret sharing piece (A) 605, which is stored in storage (A) 607 of the wallet certification authority by introduction processing 606.

[0091] Next, the 256-bit secret vector (S) 604 is used as key 610, and the 256-bit secret sharing piece (A) 605 is used as message 611, and the key 610 and message 611 are HMAC'd to obtain a 512-bit output value 612. Next, the output value 612 is divided into 256-bit upper bits 613 and 256-bit lower bits 614, and the upper bits 613 and lower bits 614 are then applied to an XOR gate, and the output value (256 bits) is used as secret vector (A) 615.

[0092] Furthermore, the process results described below <6> The value generated in is stored as a CID hint vector (A) 609 (256 bits) in the storage (A) 607 of the wallet certificate authority after an introduction process 608 .

[0093] In Fig. 7, two random numbers 701 and 702 are generated by a random number generator (not shown), random number 701 is set to 128-bit R3, random number 702 is set to 128-bit R4, and the concatenation of R3 and R4 forms a 256-bit coordinate vector (B) 703. This coordinate vector (B) 703 and the 256-bit secret vector (A) 704 derived in Fig. 6 are multiplied by an XOR gate, and the output value (256 bits) is set to secret sharing piece (B) 705, which is placed on the blockchain (B) 707 as an NFT by introduction process 706.

[0094] Next, the 256-bit secret vector (A) 704 is used as key 710, and the 256-bit secret sharing piece (B) 705 is used as message 711, and the key 710 and message 711 are HMAC'd to obtain a 512-bit output value 712. Next, the output value 712 is divided into 256-bit upper bits 713 and 256-bit lower bits 714, and the upper bits 713 and lower bits 714 are then applied to an XOR gate, and the output value (256 bits) is used as secret vector (B) 715.

[0095] Furthermore, the process results described below <7> The value generated in is placed as a CID hint vector (B) 709 (256 bits) on the blockchain (B) 707 as an NFT after an introduction process 708.

[0096] 8, two random numbers 801 and 802 are generated by a random number generator (not shown), random number 801 is set to 128-bit R5, random number 802 is set to 128-bit R6, and the concatenation of R5 and R6 forms a 256-bit coordinate vector (C) 803. This coordinate vector (C) 803 and the 256-bit secret vector (B) 804 derived in FIG. 7 are multiplied by an XOR gate, and the output value (256 bits) is set to secret sharing piece (C) 805, which is stored in distributed storage (C) 807 by introduction processing 806.

[0097] Next, the 256-bit secret vector (B) 804 is used as key 810, and the 256-bit secret sharing piece (C) 805 is used as message 811, and key 810 and message 811 are HMAC'd to obtain a 512-bit output value 812. Next, output value 812 is divided into 256-bit upper bits 813 and 256-bit lower bits 814, and the upper bits 813 and lower bits 814 are further applied to an XOR gate, and the output value (256 bits) is used as secret vector (C) 815. At this time, the CID of the secret sharing piece (C) is obtained, and this value is passed on to subsequent processing.

[0098] In Figure 9, two random numbers 901 and 902 are generated by a random number generator (not shown), and the random number 901 is set to 128-bit R7 and the random number 902 is set to 128-bit R8. The concatenation of R7 and R8 results in a 256-bit coordinate vector (D) 903. This coordinate vector (D) 903 and the 256-bit secret vector (A) 904 derived in the previous step are multiplied by an XOR gate, and the output value (256 bits) is set as a CID hint vector (A) 905. This is then used as the result of this step in the previous step. <6> is used for the process of introducing

[0099] Next, we determine a quadratic function 906 by setting this coordinate vector (D) as the vertex and the CID of the secret sharing piece (C) obtained in the previous step as the y-intercept. If we can find this intercept, we can obtain the value of the CID. Furthermore, by using this CID, we can retrieve the vector (C) of coordinate B in the previous step from the distributed storage (IPFS).

[0100] Next, a random number generator (not shown) is used to generate a random number 907, which is set as 128-bit R9. In the quadratic function 906 determined earlier, the value of y is found when x = random number 907, and this is set as Y10.

[0101] Then, the concatenation of R9 and Y10 is set as a coordinate vector (E) 908 (256 bits), and the coordinate vector (E) 908 and the secret vector (B) 909 (256 bits) generated in the previous step are multiplied by an XOR gate to obtain a value as a CID hint vector (B) 910 (256 bits), and the result of this step is used in the previous step. <7> is used for the process of introducing

[0102] 10 to 13B explain the process of deriving a private key executed in a user terminal from a data perspective (FIGS. 10 to 13A). Ultimately, a wallet address is derived from the private key (FIG. 13B).

[0103] 10, the secret vector (S) 1001 generated in the previous step is used as key 1003, and the secret sharing pieces (A) stored in the wallet certificate authority (A) 1006 are used as message 1004. The key 1003 and message 1004 are HMAC'd to obtain an output value 1005. This value 1005 is divided into upper bits 1007 and lower bits 1008, and the upper bits 1007 and lower bits 1008 are multiplied by an XOR gate to obtain an output value that is used as secret vector (A) 1009.

[0104] Furthermore, by applying an XOR gate to this secret vector (A) 1009 and the CID hint vector (A) 1010 stored in the wallet authentication authority (A) 1006, a coordinate vector (D) 1011 recording the vertex coordinate values (R7, R8) can be obtained.

[0105] Furthermore, by applying an XOR gate to the secret vector (S) 1001 (256-bit key 1003) and the message 1004, a coordinate vector (A) 1002 recording the arbitrary coordinate values (R1, R2) can be obtained.

[0106] 11, the secret vector (A) 1101 generated in the previous step is used as key 1103, and the secret sharing piece (B) stored in the blockchain (B) 1106 is used as message 1104. The key 1103 and message 1104 are HMACed to obtain an output value 1105. This value 1105 is divided into upper bits 1007 and lower bits 1008, and the upper bits 1107 and lower bits 1108 are multiplied by an XOR gate to obtain an output value that is used as secret vector (B) 1109.

[0107] Furthermore, by applying an XOR gate to this secret vector (B) 1109 and the CID hint vector (B) 1110 stored in the blockchain (B) 1106, a coordinate vector (E) 1111 recording an arbitrary coordinate value (R9, Y10) can be obtained.

[0108] Furthermore, by applying an XOR gate to the secret vector (A) 1101 (256-bit key 1103) and the message 1104, a coordinate vector (B) 1102 recording the arbitrary coordinate values (R3, R4) can be obtained.

[0109] In FIG. 12, a coordinate vector (D) 1201 including the vertex coordinate values (R7, R8) acquired in the previous step and a coordinate vector (E) 1202 including arbitrary coordinate values (R9, Y10) are respectively y=a(xp) 2 +q and solve the simultaneous equations (1203). This arithmetic processing 1203 gives the general formula for the quadratic function, y=ax 2 +bx+c Next, the value at the y-intercept (x=0) of this function is taken as the CID value (C) 1205, and this CID value (C) 1205 is used to obtain the secret sharing fragment (C) 1208 from the distributed storage (C) (IPFS) 1206.

[0110] Then, by applying an XOR gate to the secret sharing fragment (C) 1208 and the secret vector (B) 1209 obtained in the previous step, a coordinate vector (C) 1210 recording the arbitrary coordinate values (R5, R6) can be obtained.

[0111] In FIG. 13A, the coordinate information of a coordinate vector (A) 1301 including the arbitrary coordinate values (R1, R2) acquired in the previous step, a coordinate vector (B) 1302 including the arbitrary coordinate values (R3, R2), and a coordinate vector (C) 1303 including the arbitrary coordinate values (R5, R2) is expressed as a general formula of a quadratic function. (y=ax 2 +bx+c) and solving this simultaneous linear equation with three unknowns (1304), we obtain the quadratic function y=ax 2 +bx+c is derived (1305).

[0112] Next, the value of the secret vector (C) obtained in the previous step is used as key 1306, and the value of the y-intercept (Y) (x=0) is used as message 1307. Key 1306 and message 1307 are HMAC'd to obtain output value 1308. This value 1305 is divided into upper bits 1309 and lower bits 1310, and the value obtained by multiplying upper bits 1309 and lower bits 1310 by an XOR gate is used as secret key (K) 1311. Once the private key (K) is obtained, the wallet address is derived using the procedure shown in Figure 13B.

[0113] 13B, once a private key (K) is obtained (step S1391) as described with reference to the previous figure, elliptic curve cryptography (ECDSA) (secp256k1) is applied based on this private key (K) (step S1392) to derive a public key (step S1393). Furthermore, a hash function (keccak256: equivalent to SHA-3) is applied to the public key obtained in the previous step (step S1304).

[0114] In step S1305, a 160-bit (20-byte) value ranging from the 96th bit to the 255th bit is extracted from the output value obtained in the previous step, and in step S1306, the value extracted in the previous step is converted to hexadecimal notation.Furthermore, in step S1307, "0x" is added to the beginning of the value converted in the previous step, and this is used as the wallet address.

[0115] In step S1308, the wallet address obtained in the previous step is compared with the value derived by the hash function, and if the value is greater than 0x8, the alphabetic parts are converted to uppercase. The value obtained by the above process is used as the checksum of the wallet address.

[0116] By performing such processing, it is possible to derive a valid wallet address that is compatible with the Ethereum (registered trademark) blockchain. Of course, it is also possible to derive a valid wallet address for other blockchains by performing appropriate processing. Appropriate processing according to these blockchains does not affect the essence and scope of the present invention.

[0117] (Key rotation processing) FIG. 14 shows an example of key rotation processing in a distributed private key management system according to one embodiment of the present invention.

[0118] In Figure 14, two random numbers 1401 and 1402 are generated by a random number generator (not shown), and random number 1401 is set to 128-bit R5 and random number 1402 is set to 128-bit R6. R5 and R6 are concatenated to form coordinate vector (C) 1403 containing arbitrary coordinate values (R5, R6).

[0119] Next, the coordinate vector (C) 1403 and the secret vector (B) 1404 obtained in the previous step are multiplied by an XOR gate to obtain the secret sharing fragment (C) 1405, which is placed in the distributed storage (IPFS) 1407 by the introduction process 1406, and a CID (C) 1408 is obtained.

[0120] Next, to keep the value of CID (C) 1408 secret, this value is placed at the y-intercept (x=0), and similarly, using random numbers 1409 and 1410, a coordinate vector (D) 1411 containing vertex coordinate values (R7, R8) is generated. y=a(xp) 2 +p By substituting p=R7 and q=R8 in the equation and solving these simultaneous equations, we derive a quadratic function (1416).

[0121] Next, a random number 1417 is used to generate the value of R9, and the y coordinate corresponding to x = R9 is obtained from the quadratic function derived in 1416, which is set as (Y10), and a coordinate vector (E) 1418 including (R9, Y10) is generated.

[0122] Next, the coordinate vector (D) 1411 containing the vertex coordinate values (R7, R8) is XORed with the secret vector (A) 1412 obtained in the previous step, and this value is set as the CID hint vector (A) 1413, which is stored in the wallet certification authority's storage (A) 1415 by the introduction process 1414.

[0123] Next, the coordinate vector (E) 1418 containing the arbitrary coordinate value (R9, Y10) is XORed with the secret vector (B) 1419 obtained in the previous step, and the output value is set as the CID hint vector (B) 1420, which is placed as an NFT on the blockchain (B) by the introduction process 1421.

[0124] By executing the above processing, key rotation in a private key distributed management system according to one embodiment of the present invention is completed.

[0125] (Problem solved by one embodiment of the present invention) The embodiments of the present invention have been described from various angles, but from the perspective of problem-solving, the problems solved by the present invention can be summarized as follows.

[0126] (1) We have created a blockchain wallet that works with an external IdP.

[0127] (2) It is now possible to restore the recovery phrase even if the user does not remember it. This is because the system uses a flow in which the key is restored and used each time it is used. This means that the situation in which a user "loses their signing key" does not occur in the first place.

[0128] (3) Even if a third party accidentally finds a part of the secret sharing fragment, it is now impossible for them to recover the key based on this. Even if a third party were to find a user's device and obtain the secret sharing fragment contained within, it is now impossible for anyone other than the user to recover the key.

[0129] (4) Even if an external IdP is hacked and authentication information is spoofed, it is now impossible for anyone other than the user to restore the key.

[0130] (5) Even if a third party were somehow able to collect all the secret sharing fragments, it would be impossible for anyone other than the user to restore the key.

[0131] (6) Furthermore, the implementation of key rotation further improves the robustness of the wallet.

[0132] The above describes a private key distribution management system according to one embodiment of the present invention based on specific examples, but embodiments of the present invention can also be embodied as a method or program for implementing a system or device, as well as a storage medium on which a program is recorded (for example, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a CD-RW, a magnetic tape, a hard disk, or a memory card).

[0133] Furthermore, the implementation form of the program is not limited to application programs such as object code compiled by a compiler or program code executed by an interpreter, but may also be in the form of a program module incorporated into an operating system.

[0134] Furthermore, it is not necessary for all processing of the program to be performed solely by the CPU on the control board, but it can also be configured so that some or all of the program is performed by another processing unit (such as a DSP) implemented on an expansion board or expansion unit added to the board as needed.

[0135] All of the features described in this specification (including the claims, abstract, and drawings) and / or all steps of any disclosed method or process may be combined in any combination, except combinations in which these features are mutually exclusive.

[0136] Furthermore, each feature described in this specification (including the claims, abstract, and drawings) may be replaced by alternative features serving the same, equivalent, or similar purpose, unless expressly denied. Thus, unless expressly denied, each disclosed feature is only one example of a generic series of identical or equivalent features.

[0137] Furthermore, the present invention is not limited to the specific configuration of any of the above-described embodiments, but extends to any novel feature or combination thereof described in this specification (including the claims, abstract, and drawings), or any novel method or process step or combination thereof described. [Explanation of symbols]

[0138] 10. Distributed Private Key Management System 11a PC (a type of user terminal) 11b-11d Mobile information terminals, smartphones, tablets (a type of user terminal) 12 IdP server(s) 13 Wallet Certificate Authority Server(s) 14 Object Distributed Storage(s) 15 Blockchain 16a~16d, 17 Communication lines 19 Public lines (dedicated lines, internet, etc.)

Claims

1. a user terminal operated by a user; an SNS server (or servers) for authenticating the user from the user terminal; a wallet certification authority server(s) that issues a UUID for the user in response to the result of the identity authentication in the SNS server(s); A smart contract (NFT) placed on a blockchain network and equipped with cryptographic non-transferability (NFT) features; Distributed storage servers (IPFS) distributed across the Internet to store content referenced by the smart contract (NFT); A private key distributed management system comprising: the user terminal generates a secret vector (S) based on the UUID and a message input by the user, and transmits the secret vector (S) to the wallet certificate authority server(s); The wallet certificate authority server(s) generates a secret vector (A) based on the secret vector (S) and a random number generated by the wallet certificate authority server(s), The smart contract (NFT) generates a secret vector (B) based on the secret vector (A) and a random number generated by itself, The distributed storage server(s) (IPFS) generates a secret vector (C) based on the secret vector (B) and a random number generated by itself, and provides the CID stored by itself to the user terminal, The user terminal generating a CID hint vector (A) based on a coordinate vector (D) generated from a random number generated by itself and the secret vector (A), and storing the CID hint vector (A) in the wallet certificate authority server(s); Deriving a quadratic function based on the coordinate vector (D) and the CID; Generate a coordinate vector (E) from a random number R generated by itself and a Y value derived from the random number R in the quadratic function; Generate a CID hint vector (B) based on the coordinate vector (E) and the secret vector (B), and store the hint vector (B) in the smart contract (NFT); A distributed private key management system characterized by performing distributed management of private keys by:

2. 2. The private key distributed management system according to claim 1, wherein the identity authentication performed by the SNS server(s) is performed between the user terminal and the wallet certification authority server(s), making the SNS server(s) unnecessary.

3. 3. The private key distribution management system according to claim 1, wherein the private key is distributed based on Shamir's secret sharing scheme.

4. 4. The private key sharing management system according to claim 3, wherein the private key is shared based on a (3, 4) threshold secret sharing scheme using the quadratic function.

5. A program executed on a private key distributed management system consisting of a user terminal operated by a user, SNS server(s) for authenticating the user from the user terminal, wallet certification authority server(s) for issuing a UUID for the user based on the results of the authentication on the SNS server(s), a smart contract (NFT) placed on a blockchain network and having a cryptographically non-transferable (non-assignable) function, and distributed storage server(s) (IPFS) placed on the Internet for storing content referenced by the smart contract (NFT), wherein when executed on the system: causing the user terminal to generate a secret vector (S) based on the UUID and a message input by the user, and to transmit the secret vector (S) to the wallet certificate authority server(s); causing the wallet certificate authority server(s) to generate a secret vector (A) based on the secret vector (S) and a random number generated by the wallet certificate authority server(s); A step of causing the smart contract (NFT) to generate a secret vector (B) based on the secret vector (A) and a random number generated by the smart contract (NFT); The method executes a step of having a distributed storage server(s) (IPFS) generate a secret vector (C) based on the secret vector (B) and a random number generated by itself, and providing a CID stored by itself to the user terminal, The user terminal, generating a CID hint vector (A) based on a coordinate vector (D) generated from a random number generated by itself and the secret vector (A), and storing the CID hint vector (A) in the wallet certificate authority server(s); Deriving a quadratic function based on the coordinate vector (D) and the CID; Generate a coordinate vector (E) from a random number R generated by itself and a Y value derived from the random number R in the quadratic function; Generate a CID hint vector (B) based on the coordinate vector (E) and the secret vector (B), and store the hint vector (B) in the smart contract (NFT); A program for performing distributed management of private keys by executing steps.

6. 6. The program according to claim 5, wherein the personal authentication performed by the SNS server(s) is performed between the user terminal and the wallet certification authority server(s), making the SNS server(s) unnecessary.

7. 7. The program according to claim 5, wherein the secret key is shared based on Shamir's secret sharing scheme.

8. 8. The program according to claim 7, wherein the secret key is shared based on a (3, 4) threshold secret sharing scheme using the quadratic function.

Images