JP2023136248A - Information processing apparatus, information processing method, and information processing program - Google Patents

Abstract

To manage an NFTokenized object in the real world using FIDO authentication and authenticate the owner thereof.SOLUTION: An information processing apparatus includes: an authentication processing unit which performs authentication on a user; and a BC registration unit which registers, on a blockchain, an authentication history to be used for verifying adequacy of authentication. The information processing apparatus further includes a verification request unit which transmits, on receipt of an inquiry for adequacy of authentication from the user, a request to a certified information processing apparatus to verify adequacy of authentication using the authentication history registered on the blockchain and receives a notification about a result of verifying adequacy of authentication from the certified information processing apparatus.SELECTED DRAWING: Figure 1

Description

The present invention relates to an information processing device, an information processing method, and an information processing program.

In recent years, technologies that use NFTs (Non-Fungible Tokens), which are tokens that exist on blockchains, have become popular, such as crypto assets (virtual currency) and NFT art. NFTs allow people to claim ownership of tokens tied to digital treasures. As part of this effort, attempts are being made to turn certificates of real-world artwork into NFTs.

“Between the arts enters new “NFT” business to strengthen asset value of real art”, December 6, 2021 16:15 <URL: https://www.excite.co.jp/news/article/ Prtimes_2021-12-06-61309-32/＞

However, in the field of NFT, including the above-mentioned conventional technology, there are many problems, mainly because the link between tokens and works is ambiguous. For example, guaranteeing the uniqueness of (mainly digital) works of art, and discrepancies with ownership of objects in the real world (there are also tokens that are tied to objects in the real world, but this is different from the ownership of objects). remains a problem. If FIDO (Fast Identity Online) authentication can be used to more strongly authenticate users, owners of objects, appraisers, and authors, it is thought that NFTs could be used effectively.

The present application was made in view of the above, and aims to manage real-world objects converted into NFTs and prove their ownership using FIDO authentication.

The information processing device according to the present application is characterized by comprising an authentication processing unit that authenticates a user, and a BC registration unit that registers an authentication history in a blockchain for use in verifying the appropriateness of authentication. .

According to one aspect of the embodiment, FIDO authentication can be used to manage real-world objects converted into NFTs and prove their ownership.

FIG. 1 is an explanatory diagram showing an overview of an information processing method according to an embodiment. FIG. 2 is an explanatory diagram showing an overview of the object identification method. FIG. 3 is an explanatory diagram showing an overview of an embodiment in which an object management device manages objects. FIG. 4 is an explanatory diagram showing an overview of an embodiment in which the authentication device has an object management function. FIG. 5 is an explanatory diagram showing an overview of an embodiment for generating a key pair that provides both authentication and object ownership proof. FIG. 6 is an explanatory diagram showing an overview of an embodiment in which independent keys are generated for authentication and object ownership proof. FIG. 7 is an explanatory diagram showing an overview of an embodiment in which a distributed ledger device manages an authentication public key. FIG. 8 is an explanatory diagram showing an overview of an embodiment in which a distributed ledger device manages both an authentication public key and an OBJ ownership proof public key. FIG. 9 is an explanatory diagram showing an overview of an embodiment in which a key pair having both authentication and object ownership proof is generated and the public key is managed using a blockchain. FIG. 10 is a sequence diagram showing the first procedure for verifying the validity of FIDO authentication. FIG. 11 is a sequence diagram showing the second procedure for verifying the validity of FIDO authentication. FIG. 12 is a diagram illustrating a configuration example of an information processing system according to an embodiment. FIG. 13 is a diagram illustrating a configuration example of a terminal device according to an embodiment. FIG. 14 is a diagram illustrating a configuration example of a server device according to an embodiment. FIG. 15 is a diagram showing an example of a user information database. FIG. 16 is a diagram showing an example of a history information database. FIG. 17 is a diagram showing an example of the ownership information database. FIG. 18 is a flowchart showing the processing procedure according to the embodiment. FIG. 19 is a diagram showing an example of a hardware configuration.

DESCRIPTION OF THE PREFERRED EMBODIMENTS An information processing apparatus, an information processing method, and an information processing program according to the present application (hereinafter referred to as "embodiments") will be described in detail below with reference to the drawings. Note that the information processing apparatus, information processing method, and information processing program according to the present application are not limited to this embodiment. In addition, in the following embodiments, the same parts are given the same reference numerals, and redundant explanations will be omitted.

[1. Overview of information processing method]
First, with reference to FIG. 1, an overview of an information processing method performed by an information processing apparatus according to an embodiment will be described. FIG. 1 is an explanatory diagram showing an overview of an information processing method according to an embodiment. In FIG. 1, an example will be described in which FIDO authentication is used to manage real-world objects converted into NFTs and to prove their ownership.

As shown in FIG. 1, the information processing system 1 includes a terminal device 10 and a server device 100. The terminal device 10 and the server device 100 are connected to be able to communicate with each other by wire or wirelessly via a network N (see FIG. 12). In this embodiment, the terminal device 10 cooperates with the server device 100.

The terminal device 10 is a smart device such as a smartphone or a tablet terminal used by a user U (user), and is connected to an arbitrary server device via a wireless communication network such as 4G (Generation) or LTE (Long Term Evolution). This is a mobile terminal device that can communicate. Further, the terminal device 10 has a screen such as a liquid crystal display, which has a touch panel function, and allows the user U to perform a tap operation, a slide operation, a scroll operation, etc. using a finger or a stylus, etc. to respond to display data such as content. Accepts various operations. Note that an operation performed on an area of the screen where content is displayed may be an operation on the content. Further, the terminal device 10 may be not only a smart device but also an information processing device such as a desktop PC (Personal Computer) or a notebook PC.

The server device 100 cooperates with the terminal device 10 of each user U, and provides API (Application Programming Interface) services for various applications (hereinafter referred to as apps) and various data to the terminal device 10 of each user U. It is an information processing device that uses computers, cloud systems, etc.

Further, the server device 100 may be an information processing device that provides some kind of web service online to the terminal device 10 of each user U. For example, the server device 100 provides web services such as Internet connection, search service, SNS (Social Networking Service), electronic commerce (EC), electronic payment, online games, online banking, online trading, accommodation/ticket reservation, Services such as video/music distribution, news, maps, route searches, route guidance, route information, operation information, weather forecasts, etc. may be provided. In reality, the server device 100 may cooperate with various servers that provide the above-mentioned Web services, mediate the Web services, or may be in charge of processing the Web services.

Note that the server device 100 can acquire user information regarding the user U. For example, the server device 100 acquires information regarding user U's attributes such as user U's gender, age, and residential area. The server device 100 stores and manages identification information indicating the user U (user ID, etc.) as well as information regarding attributes of the user U.

Further, the server device 100 acquires various types of history information (log data) indicating user U's behavior from the user U's terminal device 10 or from various servers based on the user ID and the like. For example, the server device 100 acquires a location history, which is a history of user U's location, date and time, from the terminal device 10. The server device 100 also acquires a search history, which is a history of search queries input by the user U, from a search server (search engine). Additionally, the server device 100 acquires a viewing history, which is a history of content viewed by the user U, from the content server. Further, the server device 100 acquires a purchase history (payment history) that is a history of user U's product purchases and payment processing from the electronic commerce server and the payment processing server. Further, the server device 100 may acquire the listing history and the sales history, which are the listing history of the user U on the marketplace, from the electronic commerce server or the payment processing server. The server device 100 also acquires a posting history, which is a history of postings by user U, from a posting server or SNS server that provides a word-of-mouth posting service. Note that the various servers described above may be the server device 100 itself. That is, the server device 100 may function as the various servers described above.

[1-1. Object management]
In the present embodiment, the server device 100 uses FIDO (Fast Identity Online) authentication to manage objects that exist in the real world that have been turned into NFTs, and to prove their ownership. FIDO authentication is resistant to phishing because a secret (such as a password) is not shared between the authenticator and the authentication device (FIDO server).

Note that the authenticator may be installed in the same device as the FIDO client (built-in authenticator), or may be installed in a device physically different from the FIDO client (external authenticator).

For example, FIDO authentication uses authentication methods that use memories or possessions such as PIN (Personal Identification Number), USB (Universal Serial Bus) security keys, and smart cards, as well as biometric information such as fingerprints, face, iris, veins, and voice prints. It is possible to implement an authentication method using behavioral information. The authentication method is not limited to these, and any method can be introduced. It is also possible to combine multiple authentication methods to achieve multimodal biometric authentication and multifactor authentication.

Traditionally, in the digital world, software programs manage sets of information (objects) by assigning them unique identifiers. However, since the above method does not exist for objects in the real world, uniqueness cannot be guaranteed.

Therefore, a linking algorithm that generates and assigns a distinguishable identifier to a real-world object, associates a unique identifier for the object with predetermined information (e.g., owner), and a linking algorithm for the object to which the identifier is assigned. A verification algorithm is introduced to verify that predetermined associated information is properly associated.

For example, as shown in FIG. 1, it is assumed that a user U who is an owner of an object OBJ in the real world owns an object OBJ that exists in the real world and has been turned into an NFT. User U may be an appraiser or author of object OBJ, which is a work of art. At least, the user U is a person who has owned or acquired the object OBJ, even temporarily.

Object OBJ, which exists in the real world and has been turned into an NFT, can be transferred and distributed. A new owner who has acquired (purchased) the NFT object OBJ can exercise the right to sell (resell), distribute, and license the object OBJ. Note that the object OBJ is not limited to a work of art, but may be any real-world object manufactured or owned by the user U.

In this embodiment, each of the plurality of server devices 100 is written in an identifiable manner, such as server device 100 (100A) and server device 100 (100B), depending on its role. Note that, in reality, they are not limited to being independent in terms of hardware, but may be independent in terms of software. For example, it may be a plurality of server functions possessed by the same computer.

The server device 100 (100A), which is an object allocation device, has an object identifier generation function and an object allocation function. Further, the server device 100 (100B), which is an object verification device, has an object identification function and an object verification function.

At this time, the server device 100 (100A), which is the object allocation device, uses the object identifier generation function to generate unique identifier information (object identifier ( OID)). Further, the server device 100 (100A) uses the object allocation function to store and manage the object identifier (OID) and the user identifier (UID) indicating the user U who is the owner in association with each other.

Note that when the owner of object OBJ changes, the server device 100 (100A), which is an object allocation device, uses an object allocation function to store an object identifier (OID) and a user identifier (UID) indicating user U when the owner of object OBJ changes. ), and the object identifier (OID) and the user identifier (UID) indicating the new owner are stored and managed in association with each other. That is, the user identifier (UID) indicating the owner of object OBJ is updated. Alternatively, in order to keep the history of the owner of object OBJ, the object identifier (OID) and the user identifier (UID) indicating the latest owner are stored and managed in association with each other, and the object identifier (OID) is stored and managed to indicate the past owner. User identifiers (UIDs) may also be stored and managed in association with each other. For example, the object identifier (OID) may be stored and managed in association with a list or history information (log data) that includes a list of user identifiers (UID) indicating past owners.

Further, the server device 100 (100B), which is an object verification device, uses an object identification function to obtain an object identifier (OID) from the target object OBJ. Further, the server device 100 (100B) uses the object verification function to refer to the relevant information of the object identifier (OID), obtains and verifies the associated user identifier (UID).

[1-2. Object identification]
The object identification method will be described with reference to FIG. 2. FIG. 2 is an explanatory diagram showing an overview of the object identification method.

Sensor D (detector) detects specific characteristic information regarding object OBJ. The sensor D may be the terminal device 10 or other sensor device/detection device. For example, the sensor D extracts an image, a moving image, temperature, acceleration, text information, material information, smell, context information, etc. as specific characteristic information regarding the object OBJ. Furthermore, the sensor D may extract not only the object OBJ itself but also context information (space, environmental sounds, etc.) around the object OBJ.

Note that the specific characteristic information regarding the object OBJ may be obtained as a reaction (response) to some media information. For example, it may be the shape of an object or an image obtained by applying light, infrared rays, or X-rays. Alternatively, it may be the content of a response to a voice question in a natural language (Japanese). It may also be character information that can be distinguished from the outside. For example, in the case of products such as PCs, terminal devices, home appliances, AV equipment, etc., the serial number (serial ID) printed on the surface may be used.

Further, the method and conditions for measuring specific information appropriate for object identification depend on the sensor D. For example, object OBJ may be measured according to the requirements (specifications) of sensor D (device). Furthermore, the object OBJ may be measured by shining light onto the object OBJ from predetermined directions (eg, omnidirectional, front/back, three directions, etc.). Alternatively, the object OBJ may be measured by a sensor D (device) that has passed the certification of a predetermined standard, using a method that guarantees measurement accuracy.

The server device 100 aggregates various characteristic information obtained from the plurality of sensors D that measured the object OBJ, and performs a feature amount analysis. At this time, the server device 100 may cause a model to learn a set of characteristic information and a feature amount, input the characteristic information to this model, and infer the feature amount. Then, the server device 100 generates an object identifier (OID) based on the feature amount. Further, the server device 100 may use the feature amount itself as an object identifier (OID). Furthermore, the server device 100 can identify an object identifier (OID) based on the feature amount, and can identify the object OBJ corresponding to the object identifier (OID).

Note that the server device 100 may use an information management method such as blockchain (BC) for object management and verification. Further, the server device 100 may perform identity authentication (such as FIDO authentication) of the user U at the time of verification.

[1-3. FIDO authentication + object management]
In this embodiment, the following four examples (1) to (4) will be described regarding the implementation of the "FIDO authentication + object management" function. Note that, in reality, the present invention is not limited to these examples.

(1) An object management device manages objects.
In the first embodiment, an independent object management device is prepared separately from the authentication device, and this object management device manages objects. FIG. 3 is an explanatory diagram showing an overview of an embodiment in which an object management device manages objects.

For example, as shown in FIG. 3, the server device 100 (100C), which is an authentication device, assigns a user identifier (UID) to the user U in advance. Further, the server device 100 (100A+100B), which is an object management device, assigns an object identifier (OID) to the object OBJ in advance.

Note that the server device 100 (100A+100B) that is an object management device has the functions of both the server device 100 (100A) that is the object allocation device described above and the server device 100 (100B) that is the object verification device (object management function). ). The server device 100 (100A+100B), which is an object management device, can cooperate with the server device 100 (100C), which is an authentication device.

When the terminal device 10, which is an authenticator, registers that the user U owns the object OBJ, the terminal device 10 uses the user verification function to input user verification information such as biometric information and password of the user U into the user verification model. Validate users. Note that the user verification information may be detected by a sensor specialized for the authenticator, or may be input by the user U.

For example, the terminal device 10 performs user verification based on the biometric information acquired from the user U. The biometric information may be a fingerprint, a vein, a face, an iris, a voiceprint, etc., or a combination thereof. Furthermore, instead of biological information, behavioral information regarding predetermined movements such as gestures may be used. Note that, in reality, the means for confirming identity is not limited to biometric authentication. For example, the terminal device 10 may confirm the identity through authentication using a token that generates a one-time password.

Next, when the terminal device 10, which is an authenticator, confirms the identity of the user as a result of user verification, it generates an authentication key pair at the time of initial (unregistered) user registration. The authentication key pair is a key pair of an authentication private key and an authentication public key. There is a cryptographic link between the authentication private key and the authentication public key. The terminal device 10 then sends the public key for authentication along with attestation (certification of the terminal/authenticator) to the server device 100 (100C), which is an authentication device, and shares the public key for authentication. However, the authenticator and authentication device do not share a "private key." Note that the existing FIDO authentication technology may be used for the authentication key pair generation procedure at the time of user registration.

In addition, when the terminal device 10, which is an authenticator, confirms the identity as a result of user verification, it signs a challenge with the authentication private key when authenticating the registered user, and issues a FIDO assertion (Assertion). The signed challenge is sent as/together with the authentication certificate to the server device 100 (100C) which is the authentication device. The challenge is a random character string that is valid only once and is received from the server device 100 (100C) which is an authentication device at the time of a user authentication request, and is a data string that is different each time determined based on random numbers. Note that the existing FIDO authentication technology may be used for the signature procedure at the time of user authentication.

When the server device 100 (100C), which is an authentication device, receives a signed challenge signed with the private key for authentication from the terminal device 10, which is an authentication device, by using the public key cryptography-based authentication function, the server device 100 (100C), which is an authentication device, uses the public key for authentication Verify the signature. If the signature verification is successful, the server device 100 (100C), which is an authentication device, extracts a user identifier (UID) indicating the user U from among the user identifiers (UIDs) it manages. Note that the existing FIDO authentication technology may be used for the above-mentioned user identifier (UID) extraction procedure. Then, the server device 100 (100C), which is an authentication device, notifies the extracted user identifier (UID) to the server device 100 (100A+100B), which is an object management device.

The server device 100 (100A+100B), which is an object management device, uses the object management function to link the notified user identifier (UID) and object identifier (OID), and manages that the user U owns the object OBJ. do.

Note that the user identifier (UID) managed by the server device 100 (100A+100B), which is an object management device, and the user identifier (UID) managed by the server device 100 (100C), which is an authentication device, are common user identifiers between servers. It may be an identifier (UID), or it may be a user identifier (UID) that is different for each server linked to each other.

(2) The authentication device has an object management function.
In the second embodiment, the authentication device has an object management function, and this authentication device manages objects. FIG. 4 is an explanatory diagram showing an overview of an embodiment in which the authentication device has an object management function.

For example, as shown in FIG. 4, by providing the authentication device with an object management function, the server device 100 (100A+100B) which is the object management device described above and the server device 100 (100C) which is the authentication device explained in FIG. ), which is an authentication device integrated with the server device 100 (100A+100B+100C). The server device 100 (100A+100B+100C), which is this authentication device, performs the processing of both the server device 100 (100A+100B), which is the object management device described above with reference to FIG. 3, and the server device 100 (100C), which is the authentication device. Execute.

Here, the server device 100 (100A+100B+100C), which is the authentication device, allocates a user identifier (UID) to the user U in advance, and also uses the object management function to assign an object identifier (OID) to the object OBJ in advance. assign.

When the terminal device 10, which is an authenticator, registers that the user U owns the object OBJ, the terminal device 10 uses the user verification function to input user verification information such as biometric information and password of the user U into the user verification model. Validate users. Note that the user verification information may be detected by a sensor specialized for the authenticator, or may be input by the user U.

Next, when the terminal device 10, which is an authenticator, confirms the identity of the user as a result of user verification, it generates an authentication key pair at the time of initial (unregistered) user registration. Then, the terminal device 10 sends the attestation and the public key for authentication to the server device 100 (100A+100B+100C), which is an authentication device, and shares the public key for authentication. However, the authenticator and authentication device do not share a "private key."

In addition, when the terminal device 10, which is an authenticator, confirms the identity as a result of user verification, it signs a challenge with the private key for authentication when authenticating a registered user, and sends the signed challenge as/along with the FIDO assertion to the authenticator. The information is sent to the server device 100 (100A+100B+100C).

When the server device 100 (100A+100B+100C), which is an authentication device, receives a signed challenge signed with the private key for authentication from the terminal device 10, which is an authentication device, using the public key cryptography-based authentication function, the server device 100 (100A+100B+100C) uses the public key for authentication. Verify the signature. If the server device 100 (100A+100B+100C), which is an authentication device, succeeds in verifying the signature, it extracts a user identifier (UID) indicating the user U from among the user identifiers (UIDs) it manages.

The server device 100 (100A+100B+100C), which is an authentication device, uses an object management function to link the extracted user identifier (UID) and object identifier (OID), and manages that the user U owns the object OBJ. .

(3) Generate a key pair that provides both authentication and object ownership proof.
In the third embodiment, a terminal device serving as an authenticator generates a key pair used for both authentication and object ownership proof. Authenticating with this key pair also proves ownership of the object. FIG. 5 is an explanatory diagram showing an overview of an embodiment for generating a key pair that provides both authentication and object ownership proof.

The pre-allocation of the user identifier (UID) and object identifier (OID) is the same as that shown in FIG. 4, and a description thereof will be omitted.

For example, as shown in FIG. 5, when registering that the user U owns the object OBJ, the terminal device 10, which is an authenticator, uses the user verification function to verify the user U's biometric information, password, etc. Validate users by inputting information into the user validation model. Note that the user verification information may be detected by a sensor specialized for the authenticator, or may be input by the user U.

Furthermore, the terminal device 10, which is an authenticator, confirms that "object OBJ is owned" through a dialog prompting input, for example. Alternatively, it may be confirmed that the object OBJ actually exists in the hand of the user U via a sensor or the like. If the terminal device 10, which is an authenticator, cannot confirm that "the user U owns the object OBJ", it does not perform the subsequent processing. In other words, the terminal device 10, which is an authenticator, creates the above-mentioned authentication key pair only when it can confirm that "user U owns the object OBJ", thereby preventing subsequent authentication and object ownership. Performs processing to create a key pair that has both proofs.

Next, when the terminal device 10, which is an authenticator, confirms the user's identity as a result of the user verification, it generates an authentication/OBJ ownership proof key pair at the time of initial (unregistered) user registration. The authentication/OBJ ownership proof key pair is a key pair that has both authentication and object ownership proof. Then, the terminal device 10 sends the authentication/OBJ ownership proof public key together with the attestation to the server device 100 (100A+100B+100C), which is an authentication device, and shares the authentication/OBJ ownership proof public key. However, the authenticator and authentication device do not share a "private key."

Note that the terminal device 10, which is an authenticator, may generate an authentication/OBJ ownership proof key pair based on a user identifier (UID) and an object identifier (OID). Alternatively, the terminal device 10, which is an authenticator, may generate an authentication/OBJ ownership proof key pair based on the sensing information of the object OBJ.

In addition, when the terminal device 10, which is an authenticator, confirms the identity as a result of user verification, it signs a challenge with the private key for authentication/OBJ ownership proof at the time of authenticating the registered user, and adds the signature as/along with the FIDO assertion. The challenge is sent to the server device 100 (100A+100B+100C) which is an authentication device.

When the server device 100 (100A+100B+100C), which is an authentication device, receives a signed challenge signed with a private key for proving ownership of the authentication/OBJ from the terminal device 10, which is an authentication device, by the public key encryption based authentication function, the server device 100 (100A+100B+100C) performs the authentication/OBJ ownership. Verify the signature using the public key for proof of ownership. If the server device 100 (100A+100B+100C), which is an authentication device, succeeds in verifying the signature, it extracts a user identifier (UID) indicating the user U from among the user identifiers (UIDs) it manages.

The server device 100 (100A+100B+100C), which is an authentication device, uses an object management function to link the extracted user identifier (UID) and object identifier (OID), and manages that the user U owns the object OBJ. .

Here, as in FIG. 4, the case where the authentication device has an object management function and this authentication device manages objects is explained as an example, but in reality, as in FIG. The management device may be independent.

(4) Generate independent keys for authentication and object ownership proof.
In the fourth embodiment, a terminal device serving as an authenticator separately generates a key pair for authentication and a key pair for object ownership proof. However, both the authentication key pair and the object ownership proof key pair are associated. Access to the object ownership proof private key is based on the premise that the authentication private key can be accessed. At this time, when prompted to prove OBJ ownership, authentication is prompted, and if the authentication is successful, the user can access the OBJ ownership private key. FIG. 6 is an explanatory diagram showing an overview of an embodiment in which independent keys are generated for authentication and object ownership proof.

The pre-allocation of the user identifier (UID) and object identifier (OID) is the same as that shown in FIG. 4, and a description thereof will be omitted.

For example, as shown in FIG. 6, when registering that the user U owns the object OBJ, the terminal device 10, which is an authenticator, uses the user verification function to verify the user U's biometric information, password, etc. Validate users by inputting information into the user validation model. Note that the user verification information may be detected by a sensor specialized for the authenticator, or may be input by the user U.

Furthermore, the terminal device 10, which is an authenticator, confirms that "object OBJ is owned" through a dialog prompting input, for example. Alternatively, it may be confirmed that the object OBJ actually exists in the hand of the user U via a sensor or the like. If the terminal device 10, which is an authenticator, cannot confirm that "the user U owns the object OBJ", it does not perform the subsequent processing.

Next, when the terminal device 10, which is an authenticator, confirms the identity as a result of user verification, at the time of initial (unregistered) user registration, the terminal device 10, which is an authenticator, uses an OBJ ownership certificate, which is used as an object ownership certificate, along with an authentication key pair at the time of initial (unregistered) user registration. Generate a key pair. Then, the terminal device 10 sends the authentication public key and the OBJ ownership proof public key together with the attestation to the server device 100 (100A+100B+100C), which is an authentication device, and sends the authentication public key and the OBJ ownership proof public key. share. However, the authenticator and authentication device do not share a "private key."

In addition, when the terminal device 10, which is an authenticator, confirms the identity as a result of user verification, it signs a challenge with the private key for authentication when authenticating the registered user, and similarly challenges with the private key for proving ownership of OBJ. and sends each signed challenge to the server device 100 (100A+100B+100C), which is an authentication device.

When the server device 100 (100A+100B+100C), which is an authentication device, receives a signed challenge signed with the private key for authentication from the terminal device 10, which is an authentication device, using the public key cryptography-based authentication function, the server device 100 (100A+100B+100C) uses the public key for authentication. Verify the signature. If the server device 100 (100A+100B+100C), which is an authentication device, succeeds in verifying the signature, it extracts a user identifier (UID) indicating the user U from among the user identifiers (UIDs) it manages.

In addition, when the server device 100 (100A+100B+100C) which is an authentication device receives a signed challenge signed with the private key for OBJ ownership proof from the terminal device 10 which is an authentication device by the object management function, the server device 100 (100A+100B+100C) Verify the signature using If the signature verification is successful, the server device 100 (100A+100B+100C), which is an authentication device, extracts an object identifier (OID) indicating the object OBJ owned by the user U from among the object identifiers (OIDs) it manages. .

Then, the server device 100 (100A+100B+100C), which is an authentication device, uses the object management function to link the extracted user identifier (UID) and object identifier (OID), and confirms that the user U owns the object OBJ. to manage.

In the above explanation, the terminal device 10, which is an authenticator, uses the private key for authentication and the private key for proving ownership of OBJ separately, and signs the challenge individually for each private key. may be used simultaneously to sign the same challenge. For example, the terminal device 10, which is an authenticator, first uses the private key for authentication to sign a challenge, and then uses the secret for proving ownership of OBJ to sign the signed challenge with the private key for authentication. You may. When the server device 100 (100A+100B+100C), which is an authentication device, receives this signed challenge from the terminal device 10, which is an authentication device, it first verifies the signature using the public OBJ ownership certificate, and then sends the public key for authentication. may be used to verify the signature.

Also, similar to FIG. 4, the case where the authentication device has an object management function and this authentication device manages objects is explained as an example, but in reality, similar to FIG. 3, the authentication device and the object management device may be independent.

[1-4. Blockchain application of FIDO authentication]
Furthermore, in this embodiment, it is also possible to apply blockchain technology and turn FIDO authentication into a blockchain. For example, a distributed ledger device manages the FIDO public key. A distributed ledger device is a server device compatible with distributed ledger technology (DLT) that allows each node forming a network to manage/share the same ledger. The distributed ledger device may be one of the nodes configuring this network.

That is, the authentication public key for FIDO authentication is managed by blockchain (BC). Since a hash is included in each block of the blockchain, it can be verified that the public key has not been tampered with. Additionally, authentication can be performed after verifying the suitability of the public key. FIG. 7 is an explanatory diagram showing an overview of an embodiment in which a distributed ledger device manages an authentication public key.

For example, as shown in FIG. 7, apart from the authentication device, a distributed ledger device that constitutes a blockchain-compatible network manages authentication public keys for FIDO authentication. First, the server device 100 (100C), which is an authentication device, assigns a user identifier (UID) to the user U in advance. Then, the server device 100 (100C), which is an authentication device, sends a request message with the intention of storing the public key in the distributed ledger when requesting FIDO registration.

The terminal device 10, which is an authenticator, uses a user verification function to input user verification information such as biometric information and password of the user U into a user verification model to verify the user. Note that the user verification information may be detected by a sensor specialized for the authenticator, or may be input by the user U.

Next, when the terminal device 10, which is an authenticator, confirms the identity of the user as a result of user verification, it generates an authentication key pair at the time of initial (unregistered) user registration. There is a cryptographic link between the authentication private key and the authentication public key. Note that the existing FIDO authentication technology may be used for the authentication key pair generation procedure at the time of user registration.

Then, the terminal device 10 sends an attestation (certification of the terminal/authenticator) and an authentication public key to the server device 100 (100D), which is a distributed ledger device for user management, and the server device, which is an authentication device. 100 (100C), and share the public key for authentication. However, the authenticator and distributed ledger device do not share a "private key." Here, the authentication device identifier (authentication device ID) may be included in the authentication public key, or may be linked to the authentication public key.

Note that there may be a plurality of server devices 100 (100D) that are distributed ledger devices for user management. For example, there may be as many server devices 100 (100D) as distributed ledger devices for user management as there are nodes forming a blockchain-compatible network.

In addition, the terminal device 10 that is an authenticator or the server device 100 (100D) that is a distributed ledger device for user management sends a user identifier (UID) indicating the user U and a message on the blockchain (on a network compatible with the blockchain). The BC public key reference destination (DID), which is information indicating the location (reference position) of the authentication public key, is notified to the server device 100 (100C), which is an authentication device. The server device 100 (100C), which is an authentication device, stores and manages the user identifier (UID) and the BC public key reference (DID) in association with each other.

In addition, when the terminal device 10, which is an authenticator, confirms the identity as a result of user verification, it signs a challenge with the private key for authentication when authenticating the registered user, and issues a signed challenge as/along with the FIDO assertion. is sent to the server device 100 (100C) which is an authentication device. Note that the existing FIDO authentication technology may be used for the signature procedure at the time of user authentication.

When the server device 100 (100C), which is an authentication device, receives a signed challenge signed with the private key for authentication from the terminal device 10, which is an authentication device, by using the public key cryptography-based authentication function, the server device 100 (100C), which is an authentication device, receives a signed challenge signed with the private key for authentication from the terminal device 10, which is an authentication device. Based on the BC public key reference (DID) linked to the user identifier (UID), refer to the authentication public key stored in the server device 100 (100D), which is a distributed ledger device for user management, The signature is verified using this authentication public key. If the signature verification is successful, the server device 100 (100C), which is an authentication device, recognizes that the user U has been properly authenticated (the user U is the authentic user).

[1-5. Blockchainization of FIDO authentication and object management]
In this embodiment, the following two examples (1) and (2) will be described regarding the implementation of the function of "blockchaining FIDO authentication and object management". Note that, in reality, the present invention is not limited to these examples.

(1) The distributed ledger device manages both the authentication public key and the OBJ ownership proof public key.
In this embodiment, the distributed ledger device manages both the authentication public key and the OBJ ownership certification public key (OID). The distributed ledger device separately manages the authentication public key and the OBJ ownership certification public key (OID). FIG. 8 is an explanatory diagram showing an overview of an embodiment in which a distributed ledger device manages both an authentication public key and an OBJ ownership proof public key.

The pre-allocation of the user identifier (UID) and object identifier (OID) is the same as that shown in FIG. 4, and a description thereof will be omitted.

For example, as shown in FIG. 8, a distributed ledger device for user management that manages public keys for authentication for FIDO authentication and a distributed ledger device for object management that manages object identifiers (OIDs) are respectively prepared. These distributed ledger devices can cooperate with each other. Note that, in reality, these distributed ledger devices may be the same server device.

When the terminal device 10, which is an authenticator, registers that the user U owns the object OBJ, the terminal device 10 uses the user verification function to input user verification information such as biometric information and password of the user U into the user verification model. Validate users. Note that the user verification information may be detected by a sensor specialized for the authenticator, or may be input by the user U.

Furthermore, the terminal device 10, which is an authenticator, confirms that "object OBJ is owned" through a dialog prompting input, for example. Alternatively, it may be confirmed that the object OBJ actually exists in the hand of the user U via a sensor or the like. If the terminal device 10, which is an authenticator, cannot confirm that "the user U owns the object OBJ", it does not perform the subsequent processing.

Next, when the terminal device 10, which is an authenticator, confirms the identity as a result of user verification, at the time of initial (unregistered) user registration, the terminal device 10, which is an authenticator, uses an OBJ ownership certificate, which is used as an object ownership certificate, along with an authentication key pair at the time of initial (unregistered) user registration. Generate a key pair. That is, the terminal device 10, which is an authenticator, generates an OBJ ownership proof key pair only after user authentication.

Then, the terminal device 10, which is an authenticator, sends the public key for authentication along with the attestation to the server device 100 (100D), which is a distributed ledger device for user management, and shares the public key for authentication. However, the authenticator and distributed ledger device do not share a "private key." The server device 100 (100D), which is a distributed ledger device for user management, manages public keys for authentication using a blockchain.

At this time, the terminal device 10, which is an authenticator, or the server device 100 (100D), which is a distributed ledger device for user management, stores the user identifier (UID) indicating the user U and the location of the public key for authentication on the blockchain. The BC public key reference destination (DID), which is information indicating the reference position, is notified to the server device 100 (100C), which is an authentication device. The server device 100 (100C), which is an authentication device, stores and manages the user identifier (UID) and the BC public key reference (DID) in association with each other.

In addition, the terminal device 10, which is an authenticator, sends the public key for OBJ ownership proof along with the attestation to the server device 100 (100E), which is a distributed ledger device for object management, and shares the public key for OBJ ownership proof. do. However, the authenticator and distributed ledger device do not share a "private key." The server device 100 (100E), which is a distributed ledger device for object management, manages the public key for OBJ ownership proof using a blockchain.

At this time, the terminal device 10, which is an authenticator, or the server device 100 (100D), which is a distributed ledger device for user management, obtains an object identifier (OID) indicating the user U and the location of the public key for authentication on the blockchain. The server device 100 (100A+100B), which is an object management device, is notified of the BC public key reference destination (DID), which is information indicating the BC public key reference destination (DID). The server device 100 (100A+100B), which is an object management device, stores and manages the object identifier (OID) and the BC public key reference destination (DID) by linking them.

In addition, when the terminal device 10, which is an authenticator, confirms the identity as a result of user verification, when authenticating a registered user, it signs a challenge with the private key for authentication, and authenticates the signed challenge as/together with the FIDO assertion. The information is sent to the server device 100 (100C), which is the device.

Similarly, when the terminal device 10, which is an authenticator, confirms the identity as a result of user verification, when authenticating a registered user, it signs a challenge with the private key for OBJ ownership proof, and adds the signature as/along with the FIDO assertion. The challenge is sent to the server device 100 (100A+100B), which is an object management device.

When the server device 100 (100C), which is an authentication device, receives a signed challenge signed with the private key for authentication from the terminal device 10, which is an authentication device, by using the public key cryptography-based authentication function, the server device 100 (100C), which is an authentication device, receives a signed challenge signed with the private key for authentication from the terminal device 10, which is an authentication device. Based on the BC public key reference (DID) linked to the user identifier (UID), refer to the authentication public key stored in the server device 100 (100D), which is a distributed ledger device for user management, The signature is verified using this authentication public key. If the signature verification is successful, the server device 100 (100C), which is an authentication device, recognizes that the user U has been properly authenticated (the user U is the authentic user). Then, the server device 100 (100C), which is an authentication device, sends a user identifier (UID) indicating the user U who has been duly authenticated (recognized as the user) to the server device 100 (100A+100B), which is an object management device. Notify.

When the server device 100 (100A+100B), which is an object management device, receives a signed challenge signed with the private key for certifying OBJ ownership from the terminal device 10, which is an authenticator, by the object management function, the server device 100 (100A+100B) receives the signed challenge signed with the private key for proving ownership of the object OBJ. Based on the BC public key reference (DID) linked to the object identifier (OID), refer to the authentication public key stored in the server device 100 (100D), which is a distributed ledger device for object management, The signature is verified using this OBJ ownership certification public key. If the signature verification is successful, the server device 100 (100A+100B), which is an object management device, uses the object management function to verify the user identifier (UID) and object identifier (OID) notified from the server device 100 (100C), which is an authentication device. ) to manage that user U owns object OBJ.

(2) Generate a key pair that combines both authentication and object ownership proof, and manage the public key on the blockchain.
In this embodiment, a key pair is generated that provides both authentication and object ownership proof, and the public key is managed on a blockchain. Authentication also proves ownership of the object. FIG. 9 is an explanatory diagram showing an overview of an embodiment in which a key pair having both authentication and object ownership proof is generated and the public key is managed using a blockchain.

The pre-allocation of the user identifier (UID) and object identifier (OID) is the same as that shown in FIG. 4, and a description thereof will be omitted.

For example, as shown in FIG. 9, when registering that the user U owns the object OBJ, the terminal device 10, which is an authenticator, uses the user verification function to verify the user U's biometric information, password, etc. Validate users by inputting information into the user validation model. Note that the user verification information may be detected by a sensor specialized for the authenticator, or may be input by the user U.

Furthermore, the terminal device 10, which is an authenticator, confirms that "object OBJ is owned" through a dialog prompting input, for example. Alternatively, it may be confirmed that the object OBJ actually exists in the hand of the user U via a sensor or the like. If the terminal device 10, which is an authenticator, cannot confirm that "the user U owns the object OBJ", it does not perform the subsequent processing.

Next, as in FIG. 5, the terminal device 10, which is an authenticator, generates an authentication/OBJ ownership proof key pair at the time of initial (unregistered) user registration if the user's identity is confirmed as a result of user verification. . The authentication/OBJ ownership proof key pair is a key pair that has both authentication and object ownership proof. Then, the terminal device 10 sends the authentication/OBJ ownership proof public key together with the attestation to the server device 100 (100D+100E), which is a distributed ledger device, and shares the authentication/OBJ ownership proof public key. However, the authenticator and authentication device do not share a "private key." Note that the server device 100 (100D+100E) is a distributed ledger device that has both the functions of the distributed ledger device for user management and the distributed ledger device for object management shown in FIG.

Note that the terminal device 10, which is an authenticator, may generate an authentication/OBJ ownership proof key pair based on a user identifier (UID) and an object identifier (OID). Alternatively, the terminal device 10, which is an authenticator, may generate an authentication/OBJ ownership proof key pair based on the sensing information of the object OBJ.

In addition, when the terminal device 10, which is an authenticator, confirms the identity as a result of user verification, it signs a challenge with the private key for authentication/OBJ ownership proof at the time of authenticating the registered user, and adds the signature as/along with the FIDO assertion. The challenge is sent to the server device 100 (100A+100B+100C) which is an authentication device.

When the server device 100 (100A+100B+100C), which is an authentication device, receives a signed challenge signed with a private key for proving ownership of the authentication/OBJ from the terminal device 10, which is an authentication device, by the public key encryption based authentication function, the server device 100 (100A+100B+100C) performs the authentication/OBJ ownership. Verify the signature using the public key for proof of ownership. If the signature verification is successful, the server device 100 (100A+100B+100C), which is an authentication device, recognizes that the user U has been properly authenticated (the user U is the authentic user). Then, the user identifier (UID) and the object identifier (OID) are linked, and it is managed that the user U owns the object OBJ.

[1-6. Verification of validity of FIDO authentication]
Anyone can implement a FIDO server by reading the specifications, but it is difficult for each individual to obtain FIDO certification. For example, there is the issue of cost (people, resources, etc.). Additionally, Level 3 with expanded functionality for WebAuthn is currently being prepared, and it will not be easy to keep up with the latest specifications.

Furthermore, it is difficult to verify later that the certification at the time was valid. For example, it is possible to authenticate by installing an uncertified, proprietary FIDO server, but there is a possibility that you will be held responsible for insufficient verification during authentication, and you want to avoid this. Conversely, when investigating a problem, there is a possibility that the certification provider may falsify the logs to suit their own needs.

Therefore, in this embodiment, a service is provided in which authentication result information (FIDO assertion) and authentication public key are stored in a blockchain (BC) and verified using, for example, the functions of a certified FIDO server. The FIDO server currently verifies the authentication assertion addressed to its own domain, but extracts the public key and assertion and verifies it.

That is, in this embodiment, the FIDO server that has performed FIDO authentication registers the history of FIDO authentication in the blockchain. In addition, if this FIDO server receives an inquiry from a user regarding the appropriateness of authentication, it will send a request for determining the appropriateness of authentication using the history registered in the blockchain to a trusted and certified FIDO server. do.

(1) First procedure for verifying the validity of FIDO authentication FIG. 10 is a sequence diagram showing the first procedure for verifying the validity of FIDO authentication.

For example, as shown in FIG. 10, a terminal device 10, which is an authenticator, authenticates to a server device 100 (100C), which is a unique FIDO server, via a network N (see FIG. 12) in response to an operation by a user U. A request is sent (step S1).

Note that the unique FIDO server may be the server device 100 (100A+100B+100C) that integrates the server device 100 (100A+100B), which is the object management device, and the server device 100 (100C), which is the authentication device. Further, the unique FIDO server may be a server device that is not FIDO certified.

The server device 100 (100C), which is a unique FIDO server, challenges the terminal device 10, which is an authenticator, via the network N (see FIG. 12) in order to perform FIDO authentication for the user U in response to an authentication request. (Step S2).

When the terminal device 10, which is an authenticator, receives a challenge from the server device 100 (100C), which is its own FIDO server, it performs user verification, and if the user's identity is confirmed as a result of the user verification, it accepts the challenge with the private key for authentication. The signed challenge is sent to the server device 100 (100C), which is a unique FIDO server, as/as a FIDO assertion (authentication proof of identity) (step S3).

When the server device 100 (100C), which is a unique FIDO server, receives a signed challenge signed with an authentication private key from the terminal device 10, which is an authenticator, via the network N (see FIG. 12), it performs public key cryptography. The base authentication function verifies the signature using the authentication public key (step S4).

If the signature verification is successful, the server device 100 (100C), which is a unique FIDO server, recognizes that the user U is legitimately authenticated (user U is the authentic user) and sends the information via the network N (see FIG. 12). and notifies the terminal device 10, which is the authenticator, that the authentication is OK (step S5).

In addition, if the server device 100 (100C), which is a unique FIDO server, succeeds in verifying the signature, it issues an assertion and publishes it to the server device 100 (100D) such as BC or public storage via the network N (see FIG. 12). The key is linked and registered (step S6A).

Note that the server device 100 (100D) for BC, public storage, etc. is a server device that is a distributed ledger device that has both the functions of a distributed ledger device for user management and a distributed ledger device for object management shown in FIG. It may be 100 (100D+100E).

When an incident occurs in a service that uses a FIDO server, the terminal device 10, which is an authenticator, queries the server device 100 (100C), which is its own FIDO server, regarding the appropriateness of the authentication. (Step S7A).

The server device 100 (100C), which is a unique FIDO server, requests the server device 100 (100F), which is a certified FIDO server, to verify the appropriateness of authentication via the network N (see FIG. 12). , sends an assertion (step S8A).

At this time, the server device 100 (100F), which is a certified FIDO server, receives an authentication appropriateness verification request from the server device 100 (100C), which is its own FIDO server, via the network N (see FIG. 12). , get the assertion. Alternatively, when the server device 100 (100F), which is a certified FIDO server, receives a request to verify the appropriateness of authentication from the server device 100 (100C), which is its own FIDO server, it The assertion at the time of authentication is acquired from among the assertions registered in 100 (100D).

Preferably, the authorized FIDO server is a trusted external authorized FIDO server. For example, a certified FIDO server is a server device that is managed by an external institution or organization such as another reliable (or reliable) business and has received FIDO certification, in addition to the above-mentioned unique FIDO server. be. Note that the authorized FIDO server may be specified by user U or a public institution, including the authentication policy at the time of authentication.

The server device 100 (100F), which is a certified FIDO server, verifies the assertion at the time of authentication in response to a request to verify the appropriateness of authentication from the server device 100 (100C), which is a unique FIDO server (step S9A). .

At this time, instead of just relying on one carrier, multiple carriers may verify the assertion. That is, the number of server devices 100 (100F) that are certified FIDO servers is not limited to one, but may be multiple. For example, multiple operators may decide whether the assertion verification is successful or not by majority vote. At this time, assertion verification results by a plurality of certified FIDO servers may be aggregated, and success or failure of assertion verification may be determined based on the aggregate results.

The server device 100 (100F), which is a certified FIDO server, notifies the server device 100 (100C), which is its own FIDO server, of the verification result of the appropriateness of authentication via the network N (see FIG. 12) (step S10A). At this time, the server device 100 (100C), which is a unique FIDO server, notifies the terminal device 10 of the user U who made the inquiry regarding the appropriateness of the authentication of the verification result of the appropriateness of the authentication. Alternatively, the server device 100 (100F), which is a certified FIDO server, may directly notify the terminal device 10 of the user U, who has made the inquiry regarding the appropriateness of the authentication, of the verification result of the appropriateness of the authentication.

(2) Second procedure for verifying the validity of FIDO authentication FIG. 11 is a sequence diagram showing the second procedure for verifying the validity of FIDO authentication. The steps up to step S5 are the same as in FIG.

For example, as shown in FIG. 11, a terminal device 10, which is an authenticator, authenticates with a server device 100 (100C), which is a unique FIDO server, via a network N (see FIG. 12) in response to an operation by a user U. A request is sent (step S1).

The server device 100 (100C), which is a unique FIDO server, challenges the terminal device 10, which is an authenticator, via the network N (see FIG. 12) in order to perform FIDO authentication for the user U in response to an authentication request. (Step S2).

When the terminal device 10, which is an authenticator, receives a challenge from the server device 100 (100C), which is its own FIDO server, it performs user verification, and if the user's identity is confirmed as a result of the user verification, it accepts the challenge with the private key for authentication. The signed challenge is sent to the server device 100 (100C), which is a unique FIDO server, as/as a FIDO assertion (authentication proof of identity) (step S3).

When the server device 100 (100C), which is a unique FIDO server, receives a signed challenge signed with an authentication private key from the terminal device 10, which is an authenticator, via the network N (see FIG. 12), it performs public key cryptography. The base authentication function verifies the signature using the authentication public key (step S4).

If the signature verification is successful, the server device 100 (100C), which is a unique FIDO server, recognizes that the user U is legitimately authenticated (user U is the authentic user) and sends the information via the network N (see FIG. 12). and notifies the terminal device 10, which is the authenticator, that the authentication is OK (step S5).

In addition, if the signature verification is successful, the server device 100 (100C), which is a unique FIDO server, sends an assertion to the server device 100 (100D) such as BC or public storage via the network N (see FIG. 12). The authentication implementation time indicating the time (date and time) at which the authentication was performed is linked and registered together with the public key (step S6B).

When an incident occurs in a service that uses a FIDO server, the terminal device 10, which is an authenticator, inquires of the server device 100 (100F), which is a certified FIDO server, regarding the appropriateness of the authentication. (Step S7B).

For example, the terminal device 10, which is an authenticator, makes an inquiry to the server device 100 (100F), which is a certified FIDO server, such as "Was there any problem with the authentication of example.com on January 1st?" Send. Note that it is more natural for the authenticator to inquire about the appropriateness of authentication to the certified FIDO server from, for example, a web form of the unique FIDO server.

At this time, the terminal device 10, which is an authenticator, sends assertion specific information such as "user identifier (UID) + date (authentication implementation time)" to the server device 100 (100F), which is a certified FIDO server.

The server device 100 (100F), which is a certified FIDO server, allocates a corresponding assertion from the assertions registered in the server device 100 (100D), such as BC or public storage, via the network N (see FIG. 12). (Step S8B).

For example, the server device 100 (100F), which is a certified FIDO server, connects the server device 100 (100D), such as BC or public storage, based on assertion specific information such as "user identifier (UID) + date (authentication implementation time)". Extract the applicable assertion from the assertions registered in .

The server device 100 (100F), which is a certified FIDO server, verifies the assertion at the time of authentication in response to the inquiry about the appropriateness of authentication from the terminal device 10, which is an authenticator (step S9B).

The server device 100 (100F), which is a certified FIDO server, notifies the server device 100 (100C), which is its own FIDO server, of the verification result of the appropriateness of authentication via the network N (see FIG. 12) (step S10B).

As described above, according to the present embodiment, even a business that does not hold a user's account in advance can authenticate the user and manage ownership of real-world objects converted into NFTs. Additionally, if authentication public keys are distributed and managed on a blockchain, users who do not have an account can access their public keys.

Furthermore, it is possible to guarantee the uniqueness of owners and rights holders of objects in the real world. Furthermore, there is no need to embed something verifiable into the object or transform it.

[2. Configuration example of information processing system]
Next, the configuration of the information processing system 1 including the server device 100 according to the embodiment will be described using FIG. 12. FIG. 12 is a diagram illustrating a configuration example of the information processing system 1 according to the embodiment. As shown in FIG. 12, the information processing system 1 according to the embodiment includes a terminal device 10 and a server device 100. These various devices are connected via a network N so that they can communicate by wire or wirelessly. The network N is, for example, a LAN (Local Area Network) or a WAN (Wide Area Network) such as the Internet.

Moreover, the number of each device included in the information processing system 1 shown in FIG. 12 is not limited to what is illustrated. For example, in FIG. 12, only one terminal device 10 is shown for simplification of illustration, but this is just an example and is not limited, and there may be two or more terminal devices.

The terminal device 10 is an information processing device used by the user U. For example, the terminal device 10 may be a smart device such as a smartphone or a tablet terminal, a feature phone, a PC (Personal Computer), a PDA (Personal Digital Assistant), a game console or AV device with a communication function, a car navigation system, a smart watch, or the like. These include wearable devices such as head-mounted displays, smart glasses, etc.

The terminal device 10 also supports wireless communication networks such as LTE (Long Term Evolution), 4G (4th Generation), and 5G (5th Generation), Bluetooth (registered trademark), and wireless LAN (Local The server device 100 can be connected to the network N via short-range wireless communication such as an area network) and can communicate with the server device 100.

The server device 100 is, for example, a computer such as a PC or a blade server, or a mainframe or a workstation. Note that the server device 100 may be realized by cloud computing.

[3. Configuration example of terminal device]
Next, the configuration of the terminal device 10 will be explained using FIG. 13. FIG. 13 is a diagram showing a configuration example of the terminal device 10. As shown in FIG. As shown in FIG. 13, the terminal device 10 includes a communication section 11, a display section 12, an input section 13, a positioning section 14, a sensor section 20, a control section 30 (controller), and a storage section 40. Be prepared.

(Communication Department 11)
The communication unit 11 is connected to a network N (see FIG. 12) by wire or wirelessly, and transmits and receives information to and from the server device 100 via the network N. For example, the communication unit 11 is realized by a NIC (Network Interface Card), an antenna, or the like.

(Display section 12)
The display unit 12 is a display device that displays various information such as position information. For example, the display unit 12 is a liquid crystal display (LCD) or an organic electro-luminescent display (EL display). Further, the display unit 12 is a touch panel type display, but is not limited to this.

(Input section 13)
The input unit 13 is an input device that receives various operations from the user U. For example, the input unit 13 includes buttons for inputting characters, numbers, and the like. Note that the input unit 13 may be an input/output port (I/O port), a USB (Universal Serial Bus) port, or the like. Further, when the display section 12 is a touch panel display, a part of the display section 12 functions as the input section 13. Further, the input unit 13 may be a microphone or the like that receives voice input from the user U. The microphone may be wireless.

(Positioning unit 14)
The positioning unit 14 receives a signal (radio wave) sent from a GPS (Global Positioning System) satellite, and based on the received signal, determines position information (for example, latitude and longitude). That is, the positioning unit 14 positions the terminal device 10 . Note that GPS is just one example of GNSS (Global Navigation Satellite System).

Further, the positioning unit 14 can measure the position using various methods other than GPS. For example, the positioning unit 14 may use various communication functions of the terminal device 10 to measure the position as an auxiliary positioning means for position correction and the like, as described below.

(Wi-Fi positioning)
For example, the positioning unit 14 positions the terminal device 10 using the Wi-Fi (registered trademark) communication function of the terminal device 10 or the communication network provided by each communication company. Specifically, the positioning unit 14 performs Wi-Fi communication, etc., and determines the position of the terminal device 10 by measuring the distance to nearby base stations and access points.

(Beacon positioning)
Further, the positioning unit 14 may use the Bluetooth (registered trademark) function of the terminal device 10 to measure the position. For example, the positioning unit 14 measures the position of the terminal device 10 by connecting to a beacon transmitter connected by a Bluetooth (registered trademark) function.

(geomagnetic positioning)
Furthermore, the positioning unit 14 positions the terminal device 10 based on the geomagnetic pattern of the structure measured in advance and the geomagnetic sensor included in the terminal device 10 .

(RFID positioning)
Further, for example, if the terminal device 10 has an RFID (Radio Frequency Identification) tag function equivalent to a contactless IC card used at station ticket gates, stores, etc., or has a function to read an RFID tag. In this case, the location where the terminal device 10 used the terminal device 10 is recorded together with the information that the payment was made. The positioning unit 14 may measure the position of the terminal device 10 by acquiring such information. Further, the position may be determined by an optical sensor, an infrared sensor, or the like provided in the terminal device 10.

The positioning unit 14 may position the terminal device 10 using one or a combination of the above-mentioned positioning means, if necessary.

(sensor section 20)
The sensor unit 20 includes various sensors mounted on or connected to the terminal device 10. Note that the connection may be a wired connection or a wireless connection. For example, the sensors may be a detection device other than the terminal device 10, such as a wearable device or a wireless device. In the example shown in FIG. 13, the sensor unit 20 includes an acceleration sensor 21, a gyro sensor 22, an atmospheric pressure sensor 23, an air temperature sensor 24, a sound sensor 25, an optical sensor 26, a magnetic sensor 27, and an image sensor ( camera) 28.

Note that each of the sensors 21 to 28 described above is merely an example and is not limited to the above. That is, the sensor section 20 may be configured to include a portion of each of the sensors 21 to 28, or may include other sensors such as a humidity sensor in addition to or instead of each of the sensors 21 to 28. .

The acceleration sensor 21 is, for example, a three-axis acceleration sensor, and detects the physical movement of the terminal device 10, such as the moving direction, speed, and acceleration of the terminal device 10. The gyro sensor 22 detects physical movements of the terminal device 10 such as tilt in three axes directions based on the angular velocity of the terminal device 10 and the like. The atmospheric pressure sensor 23 detects the atmospheric pressure around the terminal device 10, for example.

Since the terminal device 10 is equipped with the above-mentioned acceleration sensor 21, gyro sensor 22, atmospheric pressure sensor 23, etc., it is possible to implement technologies such as pedestrian autonomous navigation (PDR) using these sensors 21 to 23, etc. It becomes possible to measure the position of the terminal device 10 using the . This makes it possible to obtain indoor position information that is difficult to obtain using positioning systems such as GPS.

For example, a pedometer using the acceleration sensor 21 can calculate the number of steps, walking speed, and distance walked. Further, by using the gyro sensor 22, it is possible to know the direction of movement of the user U, the direction of the line of sight, and the inclination of the user's body. Further, from the atmospheric pressure detected by the atmospheric pressure sensor 23, it is also possible to know the altitude and the number of floors where the terminal device 10 of the user U exists.

The temperature sensor 24 detects, for example, the temperature around the terminal device 10. The sound sensor 25 detects, for example, sounds around the terminal device 10. The optical sensor 26 detects the illuminance around the terminal device 10 . The magnetic sensor 27 detects, for example, the earth's magnetism around the terminal device 10. The image sensor 28 captures an image of the surroundings of the terminal device 10.

The above-mentioned atmospheric pressure sensor 23, temperature sensor 24, sound sensor 25, optical sensor 26, and image sensor 28 each detect atmospheric pressure, temperature, sound, and illuminance, and capture images of the surroundings, so that the terminal device 10 It is possible to detect the surrounding environment and situation. Furthermore, it is possible to improve the accuracy of the location information of the terminal device 10 based on the environment and situation around the terminal device 10.

(Control unit 30)
The control unit 30 includes, for example, a microcomputer having a CPU (Central Processing Unit), a ROM (Read Only Memory), a RAM, an input/output port, etc., and various circuits. Further, the control unit 30 may be configured with hardware such as an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array). The control section 30 includes a transmitting section 31 , a receiving section 32 , a processing section 33 , a receiving section 34 , and a verification section 35 . Furthermore, a BC processing section 36 may be included as necessary.

(Transmission unit 31)
The transmitting unit 31 receives, for example, various information input by the user U using the input unit 13, various information detected by the sensors 21 to 28 mounted on or connected to the terminal device 10, and information determined by the positioning unit 14. Location information and the like of the terminal device 10 can be transmitted to the server device 100 via the communication unit 11.

(Receiving unit 32)
The receiving unit 32 can receive various information provided from the server device 100 and requests for various information from the server device 100 via the communication unit 11 .

(Processing unit 33)
The processing unit 33 controls the entire terminal device 10, including the display unit 12 and the like. For example, the processing unit 33 can output various information transmitted by the transmitting unit 31 and various information received from the server device 100 by the receiving unit 32 to the display unit 12 for display.

Note that the reception section 34, verification section 35, and BC processing section 36, which will be described later, may be part of the processing section 33. Further, the processing unit 33 may function as a reception unit 34, a verification unit 35, and a BC processing unit 36 described below by starting an application or executing a program.

(Reception Department 34)
The reception unit 34 receives input of user U's identification information (authentication information) for verification. Further, when prompting the user U to input identification information for verification, the reception unit 34 confirms that the user U owns an object (object OBJ) that exists in the real world and has been turned into an NFT.

(Verification section 35)
The verification unit 35 verifies the user U based on the identification information. Then, when the verification of the user U is successful, the verification unit 35 generates a key pair of a private key and a public key.

For example, the verification unit 35 verifies the user U based on the identity verification information, and if the verification of the user U is successful and it is confirmed that the user U owns the object, the verification unit 35 performs the authentication of the user U. An authentication key pair of an authentication private key and an authentication public key to be used and an ownership proof key pair of an ownership proof private key and an ownership proof public key to be used to prove ownership of the object are respectively generated. Then, the verification unit 35 signs the challenge using the private key for authentication, and signs the challenge using the private key for proving ownership.

At this time, the verification unit 35 sends the authentication public key and the signed challenge signed with the authentication private key to the authentication device that manages the user identifier (UID) indicating the user U. In addition, the verification unit 35 sends the ownership proof public key and the signed challenge signed with the ownership proof private key to the object management device that manages the object identifier (OID) indicating the object.

Alternatively, the verification unit 35 verifies the user U based on the identity verification information, and if the verification of the user U is successful and it is confirmed that the user U owns the object, the verification unit 35 performs the authentication of the user U. Generate an authentication/possession proof key pair of an authentication/possession proof private key and an authentication/possession proof public key, which both serve as proof of ownership of the object. Then, the verification unit 35 signs the challenge using the private key for authentication and ownership proof.

At this time, the verification unit 35 sends the authentication/ownership proof public key and the authentication/ownership proof public key to the authentication device that manages both the user identifier (UID) indicating the user U and the object identifier (OID) indicating the object. Send a signed challenge signed with your private key.

(BC processing unit 36)
The BC processing unit 36 records the public key in a blockchain (BC) and notifies the authentication device using the public key of the reference position of the public key managed in the blockchain.

For example, the BC processing unit 36 records the authentication public key and the ownership proof public key separately on a blockchain, and allows the authentication device that uses the authentication public key to record the authentication public key managed on the blockchain. The reference position is notified, and the reference position of the ownership proof public key managed in the blockchain is notified to the management device that uses the ownership proof public key.

Alternatively, the BC processing unit 36 records the public key for authentication/possession proof on a blockchain, and causes the authentication device that uses the public key for authentication/possession proof to record the public key for authentication/possession proof managed in the blockchain. Notify reference position.

(Storage unit 40)
The storage unit 40 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), or an optical disk. Ru. The storage unit 40 stores various programs, various data, and the like.

[4. Configuration example of server device]
Next, the configuration of the server device 100 according to the embodiment will be described using FIG. 14. FIG. 14 is a diagram showing a configuration example of the server device 100 according to the embodiment. As shown in FIG. 14, the server device 100 includes a communication section 110, a storage section 120, and a control section 130.

(Communication Department 110)
The communication unit 110 is realized by, for example, a NIC (Network Interface Card). Further, the communication unit 110 is connected to the network N (see FIG. 12) by wire or wirelessly.

(Storage unit 120)
The storage unit 120 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as an HDD, an SSD, or an optical disk. As shown in FIG. 14, the storage unit 120 includes a user information database 121, a history information database 122, and an ownership information database 123.

(User information database 121)
The user information database 121 stores user information regarding the user U. For example, the user information database 121 stores various information such as user U's attributes. FIG. 15 is a diagram showing an example of the user information database 121. In the example shown in FIG. 15, the user information database 121 includes items such as "user ID (identifier),""age,""gender,""home,""worklocation," and "interest."

“User ID” indicates identification information for identifying user U. Note that the "user ID" may be user U's contact information (phone number, email address, etc.), or may be identification information for identifying user U's terminal device 10.

Moreover, "age" indicates the age of the user U identified by the user ID. Note that the "age" may be information indicating the specific age of the user U (for example, 35 years old, etc.), or may be information indicating the age of the user U (for example, 30s, etc.). Alternatively, the "age" may be information indicating the date of birth of the user U, or may be information indicating the generation of the user U (for example, born in the 1980s). Moreover, "gender" indicates the gender of the user U identified by the user ID.

Moreover, "home" indicates the location information of the user U's home identified by the user ID. In the example shown in FIG. 15, "home" is illustrated as an abstract code such as "LC11," but it may also be latitude and longitude information. Furthermore, for example, "home" may be a region name or address.

Moreover, "work place" indicates the location information of the work place (school in the case of a student) of the user U identified by the user ID. In the example shown in FIG. 15, the "work location" is illustrated as an abstract code such as "LC12," but it may also be latitude and longitude information. Further, for example, the "work location" may be a region name or address.

Moreover, "interest" indicates the interest of the user U identified by the user ID. That is, "interest" indicates an object in which the user U identified by the user ID has a high interest. For example, "interest" may be a search query (keyword) that the user U inputs into a search engine. In the example shown in FIG. 15, one "interest" is shown for each user U, but there may be a plurality of "interests".

For example, in the example shown in FIG. 15, the age of the user U identified by the user ID "U1" is "20s", and the gender is "male". Further, for example, the user U identified by the user ID "U1" indicates that his home is "LC11". Further, for example, the user U identified by the user ID "U1" indicates that the work location is "LC12". Further, for example, the user U identified by the user ID "U1" indicates that he is interested in "sports."

Here, in the example shown in FIG. 15, abstract values such as "U1", "LC11", and "LC12" are used for illustration, but "U1", "LC11", and "LC12" have specific values. It is assumed that information such as character strings and numerical values is stored. Below, abstract values may be illustrated in diagrams related to other information as well.

Note that the user information database 121 is not limited to the above, and may store various information depending on the purpose. For example, the user information database 121 may store various information regarding the user U's terminal device 10. The user information database 121 also includes user U's demographic (demographic attributes), psychographic (psychological attributes), geographic (geographical attributes), behavioral (behavioral attributes), and other attributes. Information regarding the information may be stored. For example, the user information database 121 includes name, family composition, place of birth (locality), occupation, position, income, qualifications, type of residence (single-family house, condominium, etc.), presence or absence of a car, commuting/commuting time, commuting/commuting, etc. Memorizes information such as routes, commuter pass sections (stations, lines, etc.), frequently used stations (other than the stations closest to your home or work), lessons (location, time zone, etc.), hobbies, interests, lifestyle, etc. It's okay.

(History information database 122)
The history information database 122 stores various information related to history information (log data) indicating user U's actions. FIG. 16 is a diagram showing an example of the history information database 122. In the example shown in FIG. 16, the history information database 122 has items such as "user ID", "location history", "search history", "browsing history", "purchase history", and "posting history".

“User ID” indicates identification information for identifying user U. Further, “position history” indicates a position history that is a history of the user U's position and movement. Further, “search history” indicates a search history that is a history of search queries input by the user U. Moreover, “browsing history” indicates a browsing history that is a history of content that user U has viewed. Further, “purchase history” indicates a purchase history that is a history of purchases by user U. Further, “posting history” indicates a posting history that is a history of postings by user U. Note that the "posting history" may include questions regarding user U's belongings.

For example, in the example shown in FIG. 16, the user U identified by the user ID "U1" moves according to "location history #1", searches according to "search history #1", and searches according to "viewing history #1". This indicates that the content was viewed as per "Purchase History #1", a predetermined product was purchased at a predetermined store, etc. as per "Purchase History #1", and the content was posted as per "Post History".

Here, in the example shown in FIG. 16, abstracts such as "U1", "location history #1", "search history #1", "browsing history #1", "purchase history #1" and "posting history #1" are used. Although the figures are illustrated using ``U1'', ``Location history #1'', ``Search history #1'', ``Browsing history #1'', ``Purchase history #1'' and ``Posting history #1'', It is assumed that information such as specific character strings and numerical values is stored.

Note that the history information database 122 is not limited to the above, and may store various information depending on the purpose. For example, the history information database 122 may store user U's usage history of a predetermined service. Further, the history information database 122 may store information regarding the history of authentication, such as an authentication implementation time indicating the time (date and time) when authentication was performed for the user U. Further, the history information database 122 may store information regarding the history of public keys (list of past public keys) sent from the authenticator.

(Ownership information database 123)
The ownership information database 123 stores various information regarding the authentication and object ownership proof of the user U who owns the NFT real world object OBJ. FIG. 17 is a diagram showing an example of the ownership information database 123. In the example shown in FIG. 17, the ownership information database 123 includes "user ID", "public key for authentication", "object ID", "feature amount", "public key for ownership proof", "public key for authentication/ownership It has items such as "public key".

“User ID” indicates a user identifier (UID) that is identification information for identifying user U. Further, the "authentication public key" indicates a public key used for user U's FIDO authentication. It is preferable that the "authentication public key" be associated with each "user ID" on a one-to-one basis. When functioning as an authentication device, the server device 100 verifies the signature using this authentication public key.

Further, "object ID" indicates an object identifier (OID) that is identification information for identifying the real world object OBJ converted into NFT. Moreover, "feature amount" indicates the feature amount of object OBJ obtained by measuring object OBJ. Note that the object identifier (OID) is generated based on the feature amount and specified based on the feature amount. Further, the "ownership proof public key" indicates a public key used to prove that the user U owns the object OBJ. It is preferable that the "ownership proof public key" be associated with each "object ID" on a one-to-one basis. When the server device 100 functions as an object management device, the server device 100 verifies the signature using this ownership proof public key.

Further, the "authentication/ownership proof public key" indicates a public key of a key pair that has both authentication and object ownership proof. That is, the "authentication/ownership proof public key" indicates a public key that has the roles of both "authentication public key" and "ownership proof public key." It is preferable that the "authentication/ownership proof public key" is linked one-to-one for each pair of "user ID" and "object ID."

Note that when using the "public key for authentication/ownership proof", the "public key for authentication" and "public key for ownership proof" may be omitted. On the other hand, when using the "public key for authentication" and the "public key for proving ownership", the "public key for authentication/ownership proof" may not be provided.

Furthermore, the public keys corresponding to the "public key for authentication," "public key for proving ownership," and "public key for authentication/proving ownership" may be managed by a blockchain (BC). In this case, "Public key for authentication", "Public key for ownership proof", and "Public key for authentication/ownership proof" include BC public key which is information indicating the location (reference position) of the public key on the blockchain. Information on a key reference destination (reference identifier) may be stored.

For example, in the example shown in FIG. 17, the user U identified by the user ID "U1" is authenticated using the "authentication public key #U1", and the object ID "O1" is the "feature amount #O1". The object OBJ identified by the object ID "O1" is specified by the "feature #O1", and the user U owns the object OBJ by "publication for ownership proof". This indicates that the user U is authenticated using the "key #U1O1" or that the user U is authenticated and proves ownership of the object OBJ using the "authentication/ownership proof public key #U1O1."

Here, in the example shown in FIG. 17, abstracts such as "U1", "authentication public key #U1", "O1", "ownership proof public key #U1O1", and "authentication/ownership proof public key #U1O1" are used. Although the diagram uses the following values, "U1", "Authentication public key #U1", "O1", "Ownership proof public key #U1O1", and "Authentication/Ownership proof public key #U1O1" It is assumed that information such as specific character strings and numerical values is stored.

Note that the proprietary information database 123 is not limited to the above, and may store various information depending on the purpose. For example, the ownership information database 123 stores an attestation regarding an authenticator (terminal device 10) that has generated an "authentication public key" and "ownership proof public key" or "authentication/ownership proof public key". /certificate of the authenticator) or a FIDO assertion from the authenticator that performed the user verification may be stored.

(Control unit 130)
Returning to FIG. 14, the explanation will be continued. The control unit 130 is a controller, and controls the server device 100 using, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), an ASIC (Application Specific Integrated Circuit), or an FPGA (Field Programmable Gate Array). This is realized by executing various programs (corresponding to an example of an information processing program) stored in an internal storage device using a storage area such as a RAM as a work area.

In the example shown in FIG. 14, the control unit 130 includes an acquisition unit 131. Further, when the server device 100 functions as an authentication device, the control unit 130 includes at least an authentication processing unit 132 and a management unit 133. Furthermore, it may include a BC registration section 134 and a verification request section 135 as necessary. Further, when the server device 100 functions as a certified device (a certified FIDO server), the control unit 130 includes at least a request reception unit 136 and a verification processing unit 137.

Note that the server device 100 may function as an authentication device or a certified FIDO server (certified information processing device) by starting an application or running a program. That is, the control unit 130 activates the acquisition unit 131, the authentication processing unit 132, the management unit 133, the BC registration unit 134, the verification requesting unit 135, the request receiving unit 136, and the verification processing unit by starting an application or executing a program. 137.

(Acquisition unit 131)
The acquisition unit 131 acquires a search query input by the user U. For example, when the user U inputs a search query into a search engine or the like and performs a keyword search, the acquisition unit 131 acquires the search query via the communication unit 110. That is, the acquisition unit 131 acquires, via the communication unit 110, a keyword input by the user U into a search window of a search engine, site, or application.

The acquisition unit 131 also acquires user information regarding the user U via the communication unit 110. For example, the acquisition unit 131 acquires identification information indicating the user U (user ID, etc.), location information of the user U, attribute information of the user U, etc. from the terminal device 10 of the user U. Further, the acquisition unit 131 may acquire identification information indicating the user U, attribute information of the user U, etc. at the time of user U's user registration. The acquisition unit 131 then registers the user information in the user information database 121 of the storage unit 120.

Further, the acquisition unit 131 acquires various types of history information (log data) indicating the behavior of the user U via the communication unit 110. For example, the acquisition unit 131 acquires various types of history information indicating the behavior of the user U from the terminal device 10 of the user U or from various servers based on the user ID and the like. The acquisition unit 131 then registers various types of history information in the history information database 122 of the storage unit 120.

(Authentication processing unit 132)
The authentication processing unit 132 performs FIDO authentication on a user who is the owner of an object existing in the real world that has been converted into an NFT. The authentication processing unit 132 allocates and manages user identifiers to users in advance.

Note that the authentication processing unit 132 generates an authentication/possession proof key that combines both user authentication and object ownership proof, which is generated by the authenticator when the authenticator confirms that the user owns the object. The pair is used to perform FIDO authentication for the user.

Alternatively, the authentication processing unit 132 verifies the user's signature using an authentication key pair generated by the authenticator when the authenticator confirms that the user owns the object. If successful, the user identifier indicating the user is specified and notified to the management unit 133.

Furthermore, the authentication processing unit 132 can also verify the signature of signed information signed with a private key using a public key managed in a blockchain.

For example, during FIDO authentication, the authentication processing unit 132 verifies the signature of signed information signed with an authentication private key using an authentication public key managed in a blockchain. In addition, when performing FIDO authentication for a user, the authentication processing unit 132 uses a public key for ownership proof managed in the blockchain to sign signed information signed with a private key for proof of ownership. Verify.

Alternatively, when performing FIDO authentication for a user, the authentication processing unit 132 uses a public key for authentication and ownership proof managed in a blockchain for signed information signed with a private key for authentication and ownership proof. to verify the signature.

(Management Department 133)
When the FIDO authentication is successful, the management unit 133 manages the user identifier indicating the user and the object identifier indicating the NFT object in association with each other. The management unit 133 assigns an object identifier in advance to an NFT object existing in the real world and manages the object.

The management unit 133 acquires information about an object existing in the real world via a sensor, and generates an object identifier indicating the object from feature amounts based on the object information. Furthermore, the management unit 133 acquires an object identifier indicating an object based on sensing information regarding an object existing in the real world, and identifies a user from a user identifier linked to the acquired object identifier.

Note that when the FIDO authentication is successful using the authentication/ownership proof key pair that combines both user authentication and object ownership proof, the management unit 133 manages the user identifier and the object identifier in a linked manner.

Alternatively, the management unit 133 verifies the user's signature using the ownership proof key pair generated by the authenticator when the authenticator confirms that the user owns the object. If successful, the user identifier and object identifier are linked and managed.

Furthermore, the management unit 133 can also manage the public key of the key pair of the private key and public key generated by the authenticator using a blockchain (BC). Specifically, the management unit 133 manages a user identifier indicating a user to be authenticated using an authenticator in association with a reference identifier indicating a reference position of a public key managed in a blockchain. .

For example, the management unit 133 manages the authentication public key in a blockchain among the authentication key pair of the authentication private key and the authentication public key used for FIDO authentication. Furthermore, the management unit 133 manages the ownership proof public key in a blockchain among the ownership proof key pair of the ownership proof private key and the ownership proof public key used to prove ownership of the object.

Alternatively, the management unit 133 may provide authentication/ownership proof among the authentication/ownership proof key pair of an authentication/ownership proof private key and an authentication/ownership proof public key that combine both user authentication and object ownership proof. Manage public keys on blockchain.

When the FIDO authentication is successful using a public key managed by the blockchain, the management unit 133 manages the user identifier indicating the user and the object identifier indicating the NFT object in association with each other.

(BC registration section 134)
The BC registration unit 134 registers the authentication history for use in verifying the appropriateness of authentication in the blockchain (BC). For example, the BC registration unit 134 registers the authentication history of FIDO authentication in the blockchain.

Furthermore, the BC registration unit 134 registers the assertion received from the authenticator that verified the user and the public key used for authentication in the blockchain. At this time, the BC registration unit 134 may register the authentication implementation time indicating the date and time when the authentication was performed in the blockchain, along with the assertion received from the authenticator that verified the user and the public key used for authentication.

Note that the BC registration unit 134 may realize registration of various information on the blockchain using calculation resources possessed by the server device 100. For example, the BC registration unit 134 may register various information on the blockchain by requesting other information processing devices (so-called miners) to perform various information processing required for registration on the blockchain. good.

(Verification request unit 135)
When the verification request unit 135 receives an inquiry about the appropriateness of authentication from a user, it requests the certified information processing device to verify the appropriateness of authentication using the authentication history registered in the blockchain (BC). and receive a notification of the verification result of the appropriateness of authentication from the certified information processing device.

For example, the verification requesting unit 135 transmits a request to verify the appropriateness of authentication using the authentication history registered in the blockchain to an authorized information processing device designated by a user or a public institution.

In addition, the verification request unit 135 transmits a verification request for verification of the appropriateness of authentication using the authentication history registered in the blockchain to the plurality of certified information processing devices, and Receive notification of the verification results of the suitability of authentication by At this time, the verification requesting unit 135 may receive a notification of the majority vote regarding the verification results of each of the plurality of certified information processing devices.

(Request receiving unit 136)
The request receiving unit 136 receives a request to verify the appropriateness of the authentication performed by the authentication device. For example, the request accepting unit 136 accepts a request to verify the appropriateness of authentication from an authentication device that has received an inquiry about the appropriateness of authentication from a user's terminal device. Alternatively, the request receiving unit 136 directly receives an inquiry about the appropriateness of authentication from the terminal device of the authenticated user as a request to verify the appropriateness of authentication. At this time, the request reception unit 136 may receive a request to verify the appropriateness of the authentication, a user identifier indicating the authenticated user, and information regarding the date and time when the authentication was performed.

(Verification processing unit 137)
In response to a request for verification of the appropriateness of authentication, the verification processing unit 137 verifies the appropriateness of authentication using the authentication history registered in the blockchain (BC), and notifies the requestor of the verification request of the verification result. do.

For example, in response to a request to verify the appropriateness of authentication, the verification processing unit 137 verifies the appropriateness of authentication using the authentication history registered in the blockchain, and notifies the authentication device or the terminal device of the verification result. .

Alternatively, the verification processing unit 137 verifies the appropriateness of authentication using the authentication history registered in the blockchain in response to an inquiry about the appropriateness of authentication as a request for verification of the appropriateness of authentication, and Notify verification results.

At this time, in response to the request for verification of the appropriateness of the authentication, the verification processing unit 137 allocates the corresponding authentication history from among the authentication histories registered in the blockchain based on the information regarding the user identifier and date and time, and the allocated authentication The appropriateness of authentication may be verified using the history, and the verification result may be notified to the requestor of the verification request.

[5. Processing procedure]
Next, a processing procedure by the server device 100 according to the embodiment will be described using FIG. 18. FIG. 18 is a flowchart showing the processing procedure according to the embodiment. Note that the processing procedure shown below is repeatedly executed by the control unit 130 of the server device 100.

For example, as shown in FIG. 18, the authentication processing unit 132 of the server device 100 allocates a user identifier (UID) to the user U in advance, and the management unit 133 of the server device 100 assigns an object identifier (UID) to the object OBJ. (OID) is assigned in advance (step S101).

Next, the authentication processing unit 132 of the server device 100 performs FIDO authentication on the user U who owns the NFT object OBJ that exists in the real world. , requests user verification and sends a challenge (step S102).

At this time, the reception unit 34 of the terminal device 10 of the user U, which is the authenticator, receives the input of user U's identification information (authentication information) for verification. Further, when prompting the user U to input identification information for verification, the reception unit 34 confirms that the user U owns an object (object OBJ) that exists in the real world and has been turned into an NFT.

Then, the verification unit 35 of the terminal device 10 of the user U, which is an authenticator, verifies the user U based on the identity verification information, successfully verifies the user U, and confirms that the user U owns the object. If confirmed, a signed challenge signed with the private key corresponding to the user U is sent to the server device 100.

Subsequently, the authentication processing unit 132 of the server device 100 receives a signed challenge from the authenticator when it is confirmed by the authenticator that the user U owns the object OBJ (step S103).

Next, if the public key generated by the authenticator is managed by a blockchain (BC), the authentication processing unit 132 of the server device 100 uses a reference identifier indicating the reference position of the public key on the blockchain. Based on this, the public key managed in the blockchain is referred to (step S104).

Note that if the public key is managed within the server device 100 instead of the blockchain, the process of referring to the public key managed by the blockchain (the process of step S104 above) is unnecessary.

Subsequently, the authentication processing unit 132 of the server device 100 verifies the signature using the public key generated by the authenticator (step S105).

For example, when it is confirmed by the authenticator that the user U owns the object OBJ, the authentication processing unit 132 of the server device 100 receives a signature signed with the private key for authentication/OBJ ownership proof from the authenticator. The signature is verified using the public key for authentication and OBJ ownership proof.

Alternatively, when the authentication device confirms that the user U owns the object OBJ, the authentication processing unit 132 of the server device 100, which is an authentication device, receives a signature signed with the authentication private key from the authentication device. Verify the signature using the authentication public key.

Subsequently, if the signature is successfully verified by the authentication processing unit 132 and the FIDO authentication is successful, the management unit 133 of the server device 100 sends the user identifier (UID) indicating the user U and the owned object OBJ. The object identifier (OID) shown is linked and managed (step S106).

For example, if the management unit 133 of the server device 100 succeeds in verifying the signature using the public key for authentication/OBJ ownership proof and succeeds in FIDO authentication, the management unit 133 of the server device 100 uses the object management function to use the user identifier ( UID) and object identifiers (OID) are linked and managed.

Alternatively, if the authentication processing unit 132 of the server device 100, which is an authentication device, succeeds in verifying the signature using the authentication public key and succeeds in the FIDO authentication, the authentication processing unit 132 of the server device 100, which is an authentication device, uses the public key cryptography-based authentication function to generate a user identifier ( UID) to the object management device.

Using the object management function, the management unit 133 of the server device 100, which is an object management device, receives a signed challenge signed with the private key for proving ownership of the object OBJ from the authenticator, and uses the public key for proving possession of the object OBJ. If the signature is successfully verified, the object identifier (OID) of the object OBJ is identified, and the user identifier (UID) notified from the authentication device and the identified object identifier (OID) are verified. Manage by linking.

Subsequently, the BC registration unit 134 of the server device 100 registers the authentication history for use in verifying the appropriateness of authentication in the blockchain (BC) (step S107).

For example, the BC registration unit 134 of the server device 100 registers the assertion received from the authenticator that verified the user U and the public key used for authentication in the blockchain. At this time, the BC registration unit 134 may register the authentication implementation time indicating the date and time when the authentication was performed in the blockchain, along with the assertion received from the authenticator that verified the user U and the public key used for authentication.

Next, when the verification requesting unit 135 of the server device 100 receives an inquiry about the appropriateness of authentication from the user U, the verification requesting unit 135 registers the certified information processing device (the certified FIDO server) in the blockchain (BC). A request to verify the appropriateness of authentication using the authentication history obtained is transmitted (step S108).

At this time, the request reception unit 136 of the server device 100, which is a certified information processing device (certified FIDO server), receives a request to verify the appropriateness of the authentication performed by the authentication device, and the verification processing unit 137, In response to a request to verify the appropriateness of authentication, the appropriateness of the authentication is verified using the authentication history registered in the blockchain (BC), and the verification result is notified to the requester of the verification request.

Subsequently, the verification requesting unit 135 of the server device 100 receives a notification of the verification result of the appropriateness of authentication from the certified information processing device, and notifies the user U (step S109).

Note that the processes in steps S108 and S109 described above may be performed directly between the authenticator and the certified information processing device.

[6. Modified example]
The terminal device 10 and server device 100 described above may be implemented in various different forms other than the above embodiments. Therefore, a modification of the embodiment will be described below.

In the above embodiment, part or all of the processing executed by the server device 100 may actually be executed by the terminal device 10. For example, the process may be completed stand-alone (by the terminal device 10 alone). In this case, it is assumed that the terminal device 10 has the functions of the server device 100 in the above embodiment. Furthermore, in the embodiment described above, since the terminal device 10 cooperates with the server device 100, it appears to the user U that the terminal device 10 is also executing the processing of the server device 100. That is, from another point of view, it can be said that the terminal device 10 includes the server device 100.

Furthermore, in the embodiments described above, the object OBJ in the real world may be a living thing or a non-living object. For example, the real world object OBJ converted into NFT may be an image of the user U himself (an image of his face, hands, whole body, etc.), a personal property (personal property) of the user U himself, or the like. It is more valuable if the user U is a famous person or a popular person. It may also be a car, a house (room), a clock, a decorative item, a branded item, etc., or it may be an antique, vintage item, or other limited or rare item. You can. Furthermore, the object OBJ may be a creature such as a pet animal or an industrial animal (economic animal) that the user U keeps, or a plant such as a foliage plant or a flower that the user U cares for. Alternatively, it may be a natural object such as a tree or rock that exists within the user U's premises (private land).

Further, in the above embodiment, the server device 100 is configured such that the target real-world object OBJ was previously owned by an expert or critic of the object OBJ, or even temporarily by a person with authority or social influence. Alternatively, if the object OBJ has been acquired, it may be proved that the object OBJ has passed through the hands of the above-mentioned person in the past. Furthermore, the server device 100 may certify that the object OBJ has been “certified” by the above-mentioned person. Note that the information is not limited to a person, and may be an organization or an institution.

Furthermore, in the embodiment described above, the server device 100 may recreate the key pair linked to the user U or the object OBJ each time the ownership of the object OBJ is transferred and the owner U is replaced. At this time, the server device 100 may recreate the key pair using the object identifier (OID) or the sensing information of the object OBJ.

[7. effect〕
As described above, the information processing device (server device 100) functioning as the authentication device according to the present application performs FIDO authentication on the user U who is the owner of an object (object OBJ) that exists in the real world and has been turned into an NFT. and a management unit 133 that links and manages the user identifier (UID) indicating the user U and the object identifier (OID) indicating the NFT object when the FIDO authentication is successful.

The authentication processing unit 132 allocates and manages a user identifier (UID) to the user U in advance. The management unit 133 assigns an object identifier (OID) in advance to an NFT object existing in the real world and manages the object.

The management unit 133 acquires information about an object existing in the real world via a sensor, and generates an object identifier (OID) indicating the object from feature amounts based on the object information.

The management unit 133 acquires an object identifier (OID) indicating the object based on sensing information regarding the object existing in the real world, and identifies the user U from the user identifier (UID) linked to the acquired object identifier (OID). Identify.

The authentication processing unit 132 generates an authentication/possession proof key that combines both user U authentication and object ownership proof, which is generated by the authenticator when the authenticator confirms that the user U owns the object. FIDO authentication is performed for user U using the pair. When the FIDO authentication is successful, the management unit 133 manages the user identifier (UID) and object identifier (OID) in association with each other.

The authentication processing unit 132 verifies the signature of the user U using the authentication key pair generated by the authenticator when the authenticator confirms that the user U owns the object, and performs verification of the signature. If successful, the user identifier (UID) indicating the user U is identified and notified to the management unit 133. The management unit 133 verifies the signature of the user U using the ownership proof key pair generated by the authenticator when the authenticator confirms that the user U owns the object, and performs verification of the signature. If successful, the user identifier (UID) and object identifier (OID) are linked and managed.

In addition, the information processing device (terminal device 10) functioning as an authenticator according to the present application, when prompting user U to input identification information for verification, possesses an object that exists in the real world that has been turned into an NFT. The reception unit 34 verifies the user U based on the identity verification information, and if the verification of the user U is successful and it is confirmed that the user U owns the object, the private key and A verification unit 35 that generates a key pair with a public key is provided.

For example, the verification unit 35 verifies the user U based on the identity verification information, and if the verification of the user U is successful and it is confirmed that the user U owns the object, the verification unit 35 performs the authentication of the user U. Generate an authentication key pair of an authentication private key and an authentication public key to be used, and an ownership proof key pair of an ownership proof private key and an ownership proof public key to be used to prove ownership of the object, Sign the challenge using the private key for authentication, and sign the challenge using the private key for proving possession.

At this time, the verification unit 35 sends the authentication public key and the signed challenge signed with the authentication private key to the authentication device that manages the user identifier (UID) indicating the user U, and sends the authentication public key and the signed challenge signed with the authentication private key to the authentication device that manages the user identifier (UID) indicating the user U. The ownership proof public key and the signed challenge signed with the ownership proof private key are sent to the object management device that manages the (OID).

Further, the verification unit 35 verifies the user U based on the identity verification information, and if the verification of the user U is successful and it is confirmed that the user U owns the object, the verification unit 35 performs the authentication of the user U. Generate an authentication/possession proof key pair between a private key for authentication/possession proof and a public key for authentication/possession proof, which also serves as proof of ownership of the object, and sign a challenge using the private key for authentication/possession proof. .

Alternatively, the verification unit 35 sends the public key for authentication/ownership proof and the private key for authentication/ownership proof to the authentication device that manages both the user identifier (UID) indicating the user U and the object identifier (OID) indicating the object. Send a signed challenge signed with the key.

Further, the information processing device (server device 100) functioning as the authentication device according to the present application includes a management unit 133 that manages the public key of the key pair of the private key and public key generated by the authentication device using a blockchain; It includes an authentication processing unit 132 that verifies the signature of signed information signed with a private key using a public key managed in a blockchain.

The management unit 133 manages a user identifier (UID) indicating a user U who is a target of authentication using an authenticator, and a reference identifier indicating a reference position of a public key managed in a blockchain in a linked manner.

The authentication processing unit 132 performs FIDO authentication on the user U who is the owner of the NFT object that exists in the real world. When the FIDO authentication is successful, the management unit 133 manages the user identifier (UID) indicating the user U and the object identifier (OID) indicating the NFT object in association with each other.

The authentication processing unit 132 allocates and manages a user identifier (UID) to the user U in advance. The management unit 133 assigns an object identifier (OID) in advance to an NFT object existing in the real world and manages the object.

The management unit 133 manages the authentication public key in a blockchain among the authentication key pair of the authentication private key and the authentication public key used for FIDO authentication. At the time of FIDO authentication, the authentication processing unit 132 verifies the signature of the signed information signed with the authentication private key using the authentication public key managed by the blockchain.

The management unit 133 uses a blockchain to manage the ownership proof public key of the ownership proof key pair of the ownership proof private key and the ownership proof public key used to prove ownership of the object. At the time of FIDO authentication for user U, the authentication processing unit 132 verifies the signature of the signed information signed with the ownership proof private key using the ownership proof public key managed in the blockchain. do.

The management unit 133 selects an authentication/possession proof key pair of an authentication/possession proof private key and an authentication/possession proof public key that serve both the authentication of the user U and the ownership proof of the object. Manage public keys on blockchain. At the time of FIDO authentication for user U, the authentication processing unit 132 uses the public key for authentication/possession proof managed in the blockchain for signed information signed with the private key for authentication/possession proof. Verify the signature.

Further, the information processing device (terminal device 10) functioning as an authenticator according to the present application includes a reception unit 34 that receives input of user U's identification information for verification, and verifies the user U based on the user U's identification information. If the verification of user U is successful, the verification unit 35 generates a key pair of a private key and a public key, and the public key is recorded on a blockchain and is managed by the authentication device that uses the public key on the blockchain. The BC processing unit 36 notifies the reference position of the public key.

For example, when prompting the user U to input identification information for verification, the reception unit 34 confirms that the user U owns an object that exists in the real world and has been turned into an NFT. The verification unit 35 verifies the user U based on the identity verification information, and when the verification of the user U is successful and it is confirmed that the user U owns the object, the verification unit 35 provides an authentication information used for FIDO authentication. An authentication key pair of a private key and an authentication public key, and an ownership proof key pair of an ownership proof private key and an ownership proof public key used to prove ownership of an object are generated. The BC processing unit 36 records the public key for authentication and the public key for ownership proof separately on the blockchain, and provides the reference position of the public key for authentication managed in the blockchain to the authentication device using the public key for authentication. The management device that uses the public key for proving ownership is notified of the reference position of the public key for proving ownership that is managed on the blockchain.

Alternatively, when prompting the user U to input identification information for verification, the reception unit 34 confirms that the user U owns an object that exists in the real world and has been turned into an NFT. The verification unit 35 verifies the user U based on the identity verification information, and if the verification of the user U is successful and it is confirmed that the user U owns the object, the verification unit 35 authenticates the user U and authenticates the object. Generate an authentication/possession proof key pair of an authentication/possession proof private key and an authentication/possession proof public key that serve as both ownership proof. The BC processing unit 36 records the public key for authentication/possession proof on the blockchain, and provides the reference position of the public key for authentication/possession proof managed in the blockchain to the authentication device that uses the public key for authentication/possession proof. Notify.

The information processing device (server device 100) according to the present application includes an authentication processing unit 132 that authenticates the user U, and a BC registration unit 134 that registers the authentication history in the blockchain for use in verifying the appropriateness of authentication. , is provided.

In addition, when the information processing device (server device 100) according to the present application receives an inquiry from user U regarding the appropriateness of authentication, the information processing device (server device 100) performs authentication using the authentication history registered in the blockchain for the certified information processing device. The authentication requesting unit 135 further includes a verification requesting unit 135 that transmits a verification request for the suitability of the authentication and receives a notification of the verification result of the suitability of the authentication from the certified information processing device.

The verification request unit 135 transmits a request to verify the appropriateness of the authentication using the authentication history registered in the blockchain to the certified information processing device designated by the user U or the public institution.

In addition, the verification request unit 135 transmits a verification request for verification of the appropriateness of authentication using the authentication history registered in the blockchain to the plurality of certified information processing devices, and Receive notification of the verification results of the suitability of authentication by

At this time, the verification requesting unit 135 receives notification of the result of the majority vote regarding the verification results of each of the plurality of certified information processing devices.

The BC registration unit 134 registers the assertion received from the authenticator that verified the user U and the public key used for authentication in the blockchain.

The BC registration unit 134 registers in the blockchain the assertion received from the authenticator that verified the user U and the public key used for authentication, as well as the authentication implementation time indicating the date and time when the authentication was performed.

In addition, the certified information processing device (server device 100) according to the present application includes a request reception unit 13634 that receives a request for verification of the appropriateness of authentication performed by the authentication device, and a It includes a verification processing unit 137 that verifies the appropriateness of authentication using the authentication history registered in the blockchain and notifies the requestor of the verification request of the verification result.

For example, the request accepting unit 13634 accepts a request to verify the appropriateness of authentication from an authentication device that has received an inquiry about the appropriateness of authentication from the terminal device 10 of the user U. In response to the request for verification of the appropriateness of authentication, the verification processing unit 137 verifies the appropriateness of the authentication using the authentication history registered in the blockchain, and notifies the authentication device or the terminal device 10 of the verification result.

Alternatively, the request receiving unit 13634 directly receives an inquiry about the appropriateness of authentication from the terminal device 10 of the authenticated user U as a request to verify the appropriateness of the authentication. In response to the inquiry regarding the appropriateness of the authentication, the verification processing unit 137 verifies the appropriateness of the authentication using the authentication history registered in the blockchain, and notifies the terminal device 10 of the verification result.

At this time, the request receiving unit 13634 receives a request to verify the appropriateness of the authentication, a user identifier (UID) indicating the authenticated user U, and information regarding the date and time when the authentication was performed. In response to the inquiry regarding the appropriateness of the authentication, the verification processing unit 137 allocates the corresponding authentication history from among the authentication histories registered in the blockchain based on the information regarding the user identifier (UID) and date and time, and uses the allocated authentication history. Verify the appropriateness of the authentication using , and notify the verification result to the requestor of the verification request.

Through any one or a combination of the above-described processes, the information processing device according to the present application can manage real-world objects converted into NFTs and prove their ownership using FIDO authentication.

[8. Hardware configuration]
Further, the terminal device 10 and the server device 100 according to the embodiments described above are realized by, for example, a computer 1000 having a configuration as shown in FIG. 19. The following will explain the server device 100 as an example. FIG. 19 is a diagram showing an example of a hardware configuration. The computer 1000 is connected to an output device 1010 and an input device 1020, and a calculation device 1030, a primary storage device 1040, a secondary storage device 1050, an output I/F (Interface) 1060, an input I/F 1070, and a network I/F 1080 are connected to a bus. 1090.

The arithmetic device 1030 operates based on programs stored in the primary storage device 1040 and the secondary storage device 1050, programs read from the input device 1020, and performs various processes. The arithmetic device 1030 is realized by, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or the like.

The primary storage device 1040 is a memory device such as a RAM (Random Access Memory) that temporarily stores data used by the calculation device 1030 for various calculations. Further, the secondary storage device 1050 is a storage device in which data used by the calculation device 1030 for various calculations and various databases are registered, and includes a ROM (Read Only Memory), an HDD (Hard Disk Drive), and an SSD (Solid Disk Drive). This is realized using flash memory, etc. The secondary storage device 1050 may be a built-in storage or an external storage. Further, the secondary storage device 1050 may be a removable storage medium such as a USB (Universal Serial Bus) memory or an SD (Secure Digital) memory card. Further, the secondary storage device 1050 may be a cloud storage (online storage), a NAS (Network Attached Storage), a file server, or the like.

The output I/F 1060 is an interface for transmitting information to be output to the output device 1010 that outputs various information such as a display, a projector, and a printer. (Digital Visual Interface) and HDMI (registered trademark) (High Definition Multimedia Interface). Further, the input I/F 1070 is an interface for receiving information from various input devices 1020 such as a mouse, keyboard, keypad, button, scanner, etc., and is realized by, for example, a USB or the like.

Further, the output I/F 1060 and the input I/F 1070 may be wirelessly connected to the output device 1010 and the input device 1020, respectively. That is, output device 1010 and input device 1020 may be wireless devices.

Moreover, the output device 1010 and the input device 1020 may be integrated like a touch panel. In this case, the output I/F 1060 and the input I/F 1070 may also be integrated as an input/output I/F.

Note that the input device 1020 is, for example, an optical recording medium such as a CD (Compact Disc), a DVD (Digital Versatile Disc), or a PD (Phase change rewritable disk), a magneto-optical recording medium such as an MO (Magneto-Optical disk), or a tape. It may be a device that reads information from a medium, a magnetic recording medium, a semiconductor memory, or the like.

Network I/F 1080 receives data from other devices via network N and sends it to computing device 1030, and also sends data generated by computing device 1030 to other devices via network N.

Arithmetic device 1030 controls output device 1010 and input device 1020 via output I/F 1060 and input I/F 1070. For example, the arithmetic device 1030 loads a program from the input device 1020 or the secondary storage device 1050 onto the primary storage device 1040, and executes the loaded program.

For example, when the computer 1000 functions as the server device 100, the arithmetic unit 1030 of the computer 1000 realizes the functions of the control unit 130 by executing a program loaded onto the primary storage device 1040. Further, the arithmetic device 1030 of the computer 1000 may load a program obtained from another device via the network I/F 1080 onto the primary storage device 1040, and execute the loaded program. Furthermore, the arithmetic unit 1030 of the computer 1000 may cooperate with other devices via the network I/F 1080, and may call and use program functions, data, etc. from other programs of other devices.

[9. others〕
Although the embodiments of the present application have been described above, the present invention is not limited to the contents of these embodiments. Furthermore, the above-mentioned components include those that can be easily assumed by those skilled in the art, those that are substantially the same, and those that are in a so-called equivalent range. Furthermore, the aforementioned components can be combined as appropriate. Furthermore, various omissions, substitutions, or modifications of the constituent elements can be made without departing from the gist of the embodiments described above.

Further, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or the processes described as being performed manually can be performed manually. All or part of this can also be performed automatically using known methods. In addition, information including the processing procedures, specific names, and various data and parameters shown in the above documents and drawings may be changed arbitrarily, unless otherwise specified. For example, the various information shown in each figure is not limited to the illustrated information.

Furthermore, each component of each device shown in the drawings is functionally conceptual, and does not necessarily need to be physically configured as shown in the drawings. In other words, the specific form of distributing and integrating each device is not limited to what is shown in the diagram, and all or part of the devices can be functionally or physically distributed or integrated in arbitrary units depending on various loads and usage conditions. Can be integrated and configured.

For example, the server device 100 described above may be realized by a plurality of server computers, and depending on the function, it may be realized by calling an external platform etc. using an API (Application Programming Interface), network computing, etc. Can be changed flexibly.

Furthermore, the above-described embodiments and modifications can be combined as appropriate within a range that does not conflict with the processing contents.

Further, the above-mentioned "section, module, unit" can be read as "means", "circuit", etc. For example, the acquisition unit can be read as an acquisition means or an acquisition circuit.

1 Information processing system 10 Terminal device 34 Reception section 35 Verification section 36 BC processing section 100 Server device 110 Communication section 120 Storage section 121 User information database 122 History information database 123 Ownership information database 130 Control section 131 Acquisition section 132 Authentication processing section 133 Management Department 134 BC Registration Department 135 Verification Request Department 136 Request Acceptance Department 137 Verification Processing Department

Claims (15)

an authentication processing unit that authenticates users;
A BC registration department that registers the authentication history on the blockchain for use in verifying the appropriateness of authentication;
An information processing device comprising: When an inquiry about the appropriateness of authentication is received from the user, a request to verify the appropriateness of authentication using the authentication history registered in the blockchain is sent to the certified information processing device, and a verification request unit that receives a notification of verification results of authentication appropriateness from the information processing device;
The information processing device according to claim 1, further comprising: The verification request unit is characterized in that the verification request unit transmits a verification request for the appropriateness of authentication using the authentication history registered in a blockchain to a certified information processing device designated by the user or a public institution. The information processing device according to claim 2. The verification request unit transmits a verification request for verification of the appropriateness of authentication using the authentication history registered in a blockchain to the plurality of certified information processing devices, and The information processing device according to claim 2 or 3, wherein the information processing device receives a notification of the verification result of the appropriateness of authentication by. The information processing device according to claim 4, wherein the verification requesting unit receives a notification of a majority vote regarding the verification results of each of the plurality of certified information processing devices. The information according to any one of claims 1 to 5, wherein the BC registration unit registers an assertion received from an authenticator that verified the user and a public key used for authentication in a blockchain. Processing equipment. Claim 6, wherein the BC registration unit registers, in a blockchain, an assertion received from an authenticator that verified the user, a public key used for authentication, and an authentication implementation time indicating a date and time when authentication was performed. The information processing device described in . A certified information processing device,
a request reception unit that receives a request for verification of the appropriateness of the authentication performed by the authentication device;
a verification processing unit that, in response to the verification request for the appropriateness of the authentication, verifies the appropriateness of the authentication using the authentication history registered in the blockchain, and notifies the requester of the verification request of the verification result;
An information processing device comprising: The request receiving unit receives a verification request for authentication appropriateness from the authentication device that has received an inquiry about the appropriateness of authentication from a user's terminal device,
In response to the request for verification of the appropriateness of the authentication, the verification processing unit verifies the appropriateness of the authentication using the authentication history registered in the blockchain, and notifies the authentication device or the terminal device of the verification result. The information processing device according to claim 8, characterized in that: The request receiving unit receives an inquiry regarding the appropriateness of authentication directly from a terminal device of an authenticated user as a request for verifying the appropriateness of authentication;
The verification processing unit is characterized in that, in response to an inquiry regarding the appropriateness of authentication, the verification processing unit verifies the appropriateness of authentication using an authentication history registered in a blockchain, and notifies the terminal device of the verification result. The information processing device according to claim 8. The request reception unit receives a request to verify the appropriateness of authentication, a user identifier indicating the authenticated user, and information regarding the date and time when the authentication was performed,
In response to a request for verification of the appropriateness of authentication, the verification processing unit allocates the corresponding authentication history from among the authentication histories registered in the blockchain based on the user identifier and the information regarding the date and time, and extracts the allocated authentication history. The information processing apparatus according to any one of claims 8 to 10, wherein the information processing apparatus verifies the appropriateness of authentication using an authentication method, and notifies the requester of the verification request of the verification result. An information processing method executed by an information processing device, the method comprising:
an authentication processing step of authenticating the user;
a BC registration process that registers the authentication history on the blockchain for use in verifying the appropriateness of the authentication;
An information processing method characterized by comprising: An information processing method executed by a certified information processing device,
a request reception step for receiving a request for verification of the appropriateness of the authentication performed by the authentication device;
In response to the request for verification of the appropriateness of the authentication, the appropriateness of the authentication is verified using the authentication history registered in the blockchain, and a verification processing step of notifying the requester of the verification request of the verification result;
An information processing method characterized by comprising: an authentication processing procedure for authenticating a user;
A BC registration procedure for registering the authentication history on the blockchain for use in verifying the appropriateness of authentication;
An information processing program that allows a computer to execute. a request reception procedure for receiving a request for verification of the appropriateness of the authentication performed by the authentication device;
In response to the request for verification of the appropriateness of the authentication, the appropriateness of the authentication is verified using the authentication history registered in the blockchain, and the verification result is notified to the requester of the verification request;
An information processing program that allows a certified computer to execute

Images