Information processing device, information processing method, and information processing program

Abstract

This provides a means to verify the authentication results contained in the certificate. [Solution] The information processing device according to the present invention is characterized by comprising: an authentication processing unit that, upon receiving a request from a user for the issuance of a verifiable certificate, performs FIDO authentication on the user, receives an authentication result signed using the user's authentication private key from the user's authenticator, and verifies the signature using the user's authentication public key; a key management unit that changes the purpose of use of the user's authentication public key used for FIDO authentication and publishes it externally as a public key for verification within the certificate, and requests the user's authenticator to generate a new authentication key pair; and a certificate issuing unit that issues a verifiable certificate to the user that includes the signed authentication result.

Description

Technical Field

[0001] The present invention relates to an information processing apparatus, an information processing method, and an information processing program.

Background Art

[0002] A technique related to FIDO (Fast Identity Online) and using an authenticator is disclosed (see Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the above prior art, when a signed authentication result (authentication assertion) is included in a certificate issued after user authentication, although a mechanism for verifying the entire certificate (the certificate itself) by signing the certificate can be realized, the authentication key for verifying the signed authentication result cannot be made public to anyone other than the authenticator. Therefore, there is no means for a verifier to verify the authentication result (the content of the certificate) included in the certificate.

[0005] The present application has been made in view of the above, and an object thereof is to provide a means for verifying an authentication result included in a certificate.

Means for Solving the Problems

[0006] The information processing device according to the present application is characterized by comprising: an authentication processing unit that, upon receiving a request from a user for the issuance of a verifiable certificate, performs FIDO authentication on the user, receives an authentication result signed using the user's authentication private key from the user's authenticator, and verifies the signature using the user's authentication public key; a key management unit that changes the purpose of use of the user's authentication public key used for FIDO authentication and publishes it externally as a public key for verification within the certificate, and requests the user's authenticator to generate a new authentication key pair; and a certificate issuing unit that issues a verifiable certificate including the signed authentication result to the user. [Effects of the Invention]

[0007] According to one embodiment, a means for verifying the authentication result contained in a certificate can be provided. [Brief explanation of the drawing]

[0008] [Figure 1] Figure 1 is an explanatory diagram illustrating the overview of the FIDO authentication system. [Figure 2] Figure 2 is an explanatory diagram showing an overview of the information processing system according to the embodiment. [Figure 3] Figure 3 is an explanatory diagram illustrating the overview of the processing related to VC issuance requests. [Figure 4] Figure 4 is an explanatory diagram illustrating the overview of the process related to changing the scope and making keys public. [Figure 5] Figure 5 is an explanatory diagram illustrating the overview of the processes related to VC issuance and key reissuance. [Figure 6] Figure 6 is an explanatory diagram illustrating the overview of the VC verification process. [Figure 7] Figure 7 shows an example of the configuration of a terminal device according to this embodiment. [Figure 8] Figure 8 shows an example of the configuration of a server device according to the embodiment. [Figure 9] Figure 9 is a flowchart showing the processing procedure according to the embodiment. [Figure 10]Figure 10 shows an example of a hardware configuration. [Modes for carrying out the invention]

[0009] The following describes in detail, with reference to the drawings, embodiments for implementing the information processing device, information processing method, and information processing program according to the present application (hereinafter referred to as "embodiments"). Note that these embodiments do not limit the information processing device, information processing method, and information processing program according to the present application. Furthermore, the same parts are denoted by the same reference numerals in the following embodiments, and redundant descriptions are omitted.

[0010] [1. Overview of the Information Processing System] First, let's refer to Figure 1 to explain the overview of the FIDO authentication system. Figure 1 is an explanatory diagram showing the overview of the FIDO authentication system. Figure 1 also explains the basic mechanism of FIDO authentication.

[0011] As shown in Figure 1, the FIDO authentication system includes a terminal device 10 and a server device 100. The terminal device 10 and the server device 100 are connected to each other via a network N, either by wired or wireless means, enabling communication between them. This allows the terminal device 10 to cooperate with the server device 100. The network N can be, for example, a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet.

[0012] Terminal device 10 is a smart device such as a smartphone or tablet used by user U, and is a mobile terminal device that can communicate with any server device via wireless communication networks such as LTE (Long Term Evolution), 4G (4th Generation), 5G (5th Generation), Bluetooth (registered trademark), or wireless LAN. Terminal device 10 also has a screen such as a liquid crystal display with touch panel functionality, and accepts various operations on displayed data such as content from user U using a finger or stylus, such as tapping, sliding, and scrolling. Operations performed on the area of ​​the screen where content is displayed may also be considered as operations on the content.

[0013] Furthermore, the terminal device 10 is not limited to smart devices, but also includes PCs (Personal Computers) such as desktop and notebook (laptop) types, mobile phones such as feature phones (ガラケー / ガラケー / ガラホ), PDAs (Personal Digital Assistants), game consoles and AV equipment with communication functions, information appliances and digital appliances, car navigation systems, wearable devices such as smartwatches, head-mounted displays, and smart glasses. In addition, the terminal device 10 may be a house or building compatible with the Internet of Things (IoT), a car, home appliances, electronic devices, etc.

[0014] In this embodiment, terminal device 10 functions as a FIDO client in FIDO authentication (Fast Identity Online). The FIDO client works in cooperation with an authenticator to authenticate user U. The authenticator may be implemented on the same device as the FIDO client (built-in authenticator), or it may be implemented on a physically different device from the FIDO client (external authenticator).

[0015] For example, in FIDO authentication, authentication methods using memories and possessions such as PIN (Personal Identification Number), USB (Universal Serial Bus) security keys, smart cards, etc., or authentication methods using biometric information and behavioral information such as fingerprints, faces, irises, veins, voiceprints, etc. can be implemented. The authentication method is not limited to these, and any method can be introduced. Also, multiple authentication methods can be combined to achieve multimodal biometric authentication or multi-factor authentication.

[0016] Hereinafter, for the sake of simplicity of explanation, the FIDO client and the authenticator are not distinguished, and the terminal device 10 will be described as both the FIDO client and the authenticator. That is, the case where the authenticator is an internal authenticator will be described as an example. In actuality, the authenticator may be an external authenticator that is physically independent from the terminal device 10 and can cooperate with the terminal device 10.

[0017] Also, a Web Authentication API (Application Programming Interface) that enables FIDO authentication through calling the authenticator from web content displayed on the Web browser of the FIDO client and communicating with the authentication server (FIDO server) can be implemented, but the description thereof will be omitted in this embodiment.

[0018] The server device 100 is an information processing device capable of communicating with the terminal device 10, and is, for example, a computer such as a PC or a blade server, or a mainframe or a workstation, etc. Note that the server device 100 may be realized by cloud computing.

[0019] In this embodiment, the server device 100 functions as an authentication server (FIDO server) in FIDO authentication. The authentication server corresponds to an RP (Relying Party) / IdP (Identity Provider). An RP (Relying Party) refers to an entity or organization that implements the FIDO server. In FIDO authentication, since "secrets" such as passwords and biometric information are not shared between the authenticator and the authentication server, it is resistant to phishing.

[0020] As shown in Figure 1, in FIDO authentication, when the authentication server receives an authentication request from a user, it sends a challenge to the user's authenticator. The challenge is a random string that is valid only once and is a different data sequence each time, determined based on a random number. The user performs user verification using the authenticator and verifies their identity locally. The authenticator then signs the verification result with its private key and sends it to the authentication server as a signed response. When the authentication server receives the signed response, it verifies the signature with its public key. The pair of private and public keys is called a key pair.

[0021] Thus, in FIDO authentication, the authentication server uses a public key to verify that the user's authenticator possesses the appropriate private key, thereby achieving authentication. The authenticator and the authentication server do not share the "private key".

[0022] Furthermore, the server device 100 also functions as a federated RP / SP (Service Provider) that provides identity services through identity federation with an RP / IdP that supports FIDO authentication. When FIDO authentication and identity federation are combined, the authentication context is propagated from the authenticator to the federated RP / SP via the RP / IdP.

[0023] For the sake of simplicity, the following explanation will not distinguish between RP / IdP and collaborative RP / SP, and will describe server device 100 as both RP / IdP and collaborative RP / SP. In practice, however, the server device acting as RP / IdP and the server device acting as collaborative RP / SP may be physically separate and independent server devices.

[0024] For example, the server device 100 may cooperate with the user U's terminal device 10 and provide the user U's terminal device 10 with API (Application Programming Interface) services for various applications (hereinafter referred to as "apps"), as well as various data.

[0025] Furthermore, the server device 100 may be an information processing device that provides some kind of online service to the user U's terminal device 10. For example, the server device 100 may provide services such as internet access, search services, SNS (Social Networking Service), e-commerce (EC), electronic payment, online games, online banking, online trading, accommodation / ticket reservations, video / music distribution, news, maps, route search, route guidance, route information, service information, and weather forecasts as online services. In practice, the server device 100 may cooperate with various servers that provide the above-mentioned online services and act as an intermediary for online services, or it may be responsible for processing online services.

[0026] The server device 100 can acquire user information about user U. For example, the server device 100 can acquire information about user U's attributes (attribute information), such as user U's gender, age, and residential area. The server device 100 can also acquire information about user U's demographics, psychographics, geographics, behavioral attributes, etc. The server device 100 may also acquire information about the segment or persona to which user U belongs in the field of marketing, as user information. The server device 100 stores and manages information about user U's attributes (attribute information) along with identification information (user ID, etc.) that identifies user U.

[0027] Furthermore, the server device 100 acquires various historical information (log data) indicating user U's actions from user U's terminal device 10, or from various servers based on the user ID, etc. For example, the server device 100 acquires location history, which is the history of user U's location and date and time, from the terminal device 10. The server device 100 also acquires search history, which is the history of search queries entered by user U, from the search server (search engine). The server device 100 also acquires browsing history, which is the history of content viewed by user U, from the content server. The server device 100 also acquires purchase history (payment history), which is the history of user U's product purchases and payment processing, from the e-commerce server or payment processing server. The server device 100 may also acquire listing history and sales history, which are the history of user U's listings on the marketplace, from the e-commerce server or payment processing server. The server device 100 also acquires posting history, which is the history of user U's posts, from posting servers that provide word-of-mouth posting services or SNS servers. The various servers mentioned above may also be the server device 100 itself. In other words, the server device 100 may function as the various servers mentioned above.

[0028] Furthermore, the number of devices included in the FIDO authentication system shown in Figure 1 is not limited to those illustrated. For example, in Figure 1, only one terminal device 10 is shown for the sake of illustration, but this is merely an example and not limiting; there may be two or more.

[0029] [2. Change of purpose of public key] In the information processing system 1 according to this embodiment, the FIDO authentication system issues verifiable certificates (VCs) containing user U's authentication information in a privacy-protected format.

[0030] In the current FIDO authentication system configuration, it is technically impossible to verify the authentication assertion, which is the authentication result, regarding the user U's identification information described in the verifiable certificate (VC). Therefore, while the certificate (VC) verifier can verify the validity of the entire issued certificate (VC), it has no choice but to trust the certificate (VC) issuer regarding the authentication result contained within the certificate (VC). For example, in the case of identity federation, as a privacy consideration, a pseudonym valid only between the IdP and SP is used for the username, and the SP, as the verifier, has no choice but to trust the content of the authentication assertion contained in the certificate (VC) from the IdP, based on trust in the IdP as the issuer, and cannot verify it.

[0031] The FIDO authentication public key (authentication key) held by the authentication server that issues the certificate (VC) cannot be directly exposed, provided, and shared with an external information processing device that verifies the certificate (VC), even though it is a "public key," because the authentication server uses it for user authentication.

[0032] Furthermore, to prove that user U is the subject, it is conceivable that user U could sign a certificate (VC) with a private key for subject verification (a private key different from the FIDO private key), and that a verifier who obtains the certificate (VC) could then obtain a public key for subject verification (a public key different from the FIDO public key) (which is made public to the verifier) ​​and verify the certificate (VC). However, generating and managing a separate key pair for subject verification for each of multiple users, in addition to the authentication key pair, in order to issue a verifiable certificate (VC) is cumbersome and inefficient.

[0033] Therefore, in this embodiment, the issuer adopts a public-key cryptography-based authentication method and changes the public key (authentication key) used for user U's authentication from authentication purpose to verification purpose after the certificate (VC) is issued. At this time, the issuer deletes the original public key (authentication key) whose purpose has been changed and requests user U to generate a new authentication key pair. The issuer then makes the public key (verification key) that has been changed from authentication purpose to verification purpose public to the person who received the certificate (VC), and makes it possible to verify the certificate (VC) using this public key (verification key). In other words, user U always has only one key pair, and only the old public key (the public key of the key pair used when user U was authenticated) is made public.

[0034] Figure 2 is an explanatory diagram showing an overview of the information processing system according to the embodiment. As shown in Figure 2, the server device 100, which acts as both an authenticator (IdP) and issuer, performs FIDO authentication on user U, which acts as the subject, using the terminal device 10, which acts as the authenticator. The server device 100 stores the authentication assertion, which was signed using the authentication secret key (FIDO secret key) during FIDO authentication, in a verifiable certificate (VC). The certificate (VC) contains the authentication assertion.

[0035] Furthermore, the server device 100 issues a certificate (VC) to user U's terminal device 10. The server device 100 then stores and publishes the authentication public key (FIDO public key) as an in-VC authentication assertion verification public key (in-VC verification public key) on the public key site 200. At this time, the in-VC verification public key is the same as the FIDO public key itself, but it is published with a different scope of use.

[0036] Furthermore, the server device 100 publishes the public key for verification within the virtual machine (VC), and requests the authenticator terminal device 10 to render the original FIDO private key unusable and create a new FIDO authentication key pair. This is because the scope of key usage changes, resulting in the absence of a corresponding FIDO public key to the FIDO private key.

[0037] User U's terminal device 10 presents a certificate (VC) to the verification device 300 of company A, which acts as the verifier. The verification device 300 may be a computer such as a PC or server, or it may be a smartphone or tablet device. The verification device 300 verifies the certificate (VC) using the publicly available verification key within the VC.

[0038] [2-1. Scope of Key Use] The scope of a key includes its purpose of use, available entities, and target users. For example, server device 100 sets the scope of the key to be: purpose of use: for FIDO authentication (for verifying authentication assertions), available entities: limited to the authenticator (or its origin), and target users: users corresponding to the public key.

[0039] FIDO authentication maintains practical security by setting the scope of key usage as described above. For example, in FIDO authentication, the public key is stored by the Relying Party (RP: authentication server) for the purpose of authenticating user U, so even though it is a "public key," the RP will not distribute or disclose that public key to anyone other than the RP (origin).

[0040] In this embodiment, the original FIDO public key for authentication (authentication key) is used with a changed scope. By doing so, the regulations of the above FIDO authentication can be complied with.

[0041] Specifically, at the time of issuing a verifiable credential (VC), for the existing public key for authentication, the verifier is changed to the "verifier of the authentication assertion included in the VC". For example, the scope of the public key for authentication <purpose of use, available entity, target user> is changed from <for FIDO authentication, FIDO authenticator, user U> to <for VC verification, VC verifier, user U>.

[0042] Also, the existing private key for authentication is made unusable. For example, the existing private key for authentication may be deleted (requested to be deleted). Since the corresponding public key for authentication no longer exists, the existing private key for authentication becomes unnecessary. Note that whether to make the existing private key for authentication unusable is optional. That is, it is not essential.

[0043] Then, a new private key for authentication is generated (requested to be generated). That is, a new key pair for authentication (a pair of a new private key for authentication and a public key for authentication) is generated.

[0044] 〔2-2. Example〕 Next, referring to FIGS. 3 to 6, an example of the information processing system according to the embodiment will be described. FIG. 3 is an explanatory diagram showing an overview of the process related to the VC issuance request. FIG. 4 is an explanatory diagram showing an overview of the process related to the scope change and publication of keys. FIG. 5 is an explanatory diagram showing an overview of the process related to VC issuance and key reissuance. FIG. 6 is an explanatory diagram showing an overview of the process related to VC verification.

[0045] For example, as shown in FIG. 3, assume an academic transcript as a verifiable credential (VC), and assume that the authentication assertion created by the authenticator is included in the verifiable credential (VC).

[0046] First, assuming that a FIDO key pair is configured, user U uses terminal device 10 to request server device 100, which will act as the authenticator / issuer, to issue a verifiable certificate (VC) to be presented to company A, which will act as the verifier (step S1).

[0047] Next, the server device 100, which acts as the authenticator / issuer, performs FIDO authentication on user U (step S2). At this time, user U performs identity verification (user verification) using the terminal device 10, which acts as the authenticator. If the authenticator terminal device 10 succeeds in identity verification, it creates an authentication assertion as the authentication result, signs it with the FIDO private key (authentication private key), and sends it to the server device 100. The server device 100 verifies the signature using the FIDO public key (authentication public key).

[0048] Next, as shown in Figure 4, the server device 100, which acts as the authenticator / issuer, changes the purpose of use of the FIDO public key of user U used for FIDO authentication and stores this FIDO public key in the public key site 200 as a public key for verification within the certificate (VC) to verify the authentication assertion contained within the certificate (VC) (step S3). At this time, as an option, access control may be implemented so that only company A can access the certificate (VC) (other entities cannot access it), for example by issuing an OAuth access token, with user U acting as the verifier. Similarly, access control may be implemented so that only company A can access the public key for verification within the VC stored in the public key site 200.

[0049] Furthermore, the server device 100, which acts as the authenticator / issuer, deletes the FIDO public key of user U used for FIDO authentication from the management database (step S4). Note that this process (deletion of the FIDO public key) may be performed before the process in step S3. For example, the server device 100 may delete the FIDO public key of user U used for FIDO authentication from the management database and store the deleted FIDO public key in the public key site 200 as a public key for verification within the VC. In other words, the server device 100 may move the FIDO public key from the management database to the public key site 200.

[0050] Next, as shown in Figure 5, the server device 100, which acts as the authenticator / issuer, issues a verifiable certificate (VC) containing the authentication assertion created by the authenticator to user U (step S5). Note that this process (issuance of the certificate (VC)) may be performed before the processes in steps S3 and S4. The authentication assertion is created by signing with a FIDO private key. At this time, optionally, the server device 100, which acts as the authenticator / issuer, may generate a signature for the entire certificate (VC) using its own private key for signing the VC (not shown). In this case, the server device 100, which acts as the authenticator / issuer, generates a key pair of a private key for signing the VC (not shown) and a public key for verifying the VC signature (not shown).

[0051] Next, the server device 100, which will act as the authenticator / issuer, performs FIDO authentication on user U in order to register a new key (generate a new authentication key pair) (step S6). This process (FIDO authentication for new key registration) may be performed before or after the process in step S5. At this time, the server device 100, which will act as the authenticator, may request the terminal device 10, which will act as the authenticator, to disable the original FIDO private key and create a new FIDO authentication key pair.

[0052] After the certificate (VC) is issued, user U uses terminal device 10 to present the verifiable certificate (VC) to the verification device 300 of company A, which will act as the verifier (step S7).

[0053] Next, the verification device 300 of company A, which will act as the verifier, requests and obtains the public key for verification within the VC from the public key site 200 in order to verify the presented verifiable certificate (VC) (step S8).

[0054] Next, the verification device 300 of company A, which acts as the verifier, verifies the authentication assertion embedded in the certificate (VC) using the public key for verification within the VC (Step S9). Signature verification of the certificate (VC) as a whole may also be performed by obtaining the public key for VC signature verification of the certifier / issuer (not shown).

[0055] Next, the verification device 300 of company A, which is the verifier, provides the service to user U based on the verification results of the certificate (VC) (step S10). In practice, the verification device 300 may provide the service to user U directly or in cooperation with other server devices, etc., or it may grant user U permission or authority to use the service.

[0056] [2-3. Characteristics] In this embodiment, the number of keys to manage does not increase, thus reducing management costs. This is because the FIDO public key is reused.

[0057] Furthermore, privacy can be protected in this embodiment. The authentication assertion does not originally contain user U's identification information. The key ID, which corresponds to user U, was originally information meaningful only to the authentication server for the purpose of extracting the user ID. However, after the issuance of the certificate (VC), the original FIDO authentication key pair is no longer usable for FIDO authentication purposes. Therefore, even if it is made public (to verifiers), it is no longer information that can track user U.

[0058] Furthermore, this embodiment can be implemented in a format that conforms to the standard FIDO authentication technique, because the FIDO key is controlled to be used only within the scope of FIDO authentication.

[0059] [2-4. Others] In this embodiment, when the server device 100 receives the purpose of use of the FIDO public key corresponding to the FIDO private key of the person being verified (from the user or the verifier), it changes the purpose of use of the FIDO public key and provides the FIDO public key with the changed purpose of use to a distribution device that distributes FIDO public keys.

[0060] The server device 100 may provide the FIDO public key, whose purpose of use has been changed, to multiple verifiers. Furthermore, the server device 100 may delete the provided FIDO public key from the database after providing it.

[0061] The FIDO public key (the authentication public key used during user U's authentication) is only exposed to external parties (other than the authenticator) when a request is made for the issuance of a certificate (VC) containing an authentication assertion verifiable with that public key. Note that if user U is already authenticated and remains logged in, this exposure may be considered the first time a request for the same certificate (VC) is made. Until a request for a certificate (VC) is made, the FIDO public key can continue to be used as the authentication public key without being exposed to external parties.

[0062] This embodiment has been implemented if, instead of examining the entire certificate (VC), the contents of the certificate (VC) are examined and verified, and authentication can be successfully performed using the public key obtained from the public server.

[0063] [3. Example of terminal device configuration] Next, the configuration of the terminal device 10 will be described using Figure 7. Figure 7 is a diagram showing an example of the configuration of the terminal device 10 according to the embodiment. As shown in Figure 7, the terminal device 10 comprises a communication unit 11, a display unit 12, an input unit 13, a positioning unit 14, a sensor unit 20, a control unit 30 (controller), and a storage unit 40.

[0064] (Communications Section 11) The communication unit 11 is connected to the network N by wire or wireless connection and transmits and receives information to and from the server device 100 via the network N. For example, the communication unit 11 is implemented by a NIC (Network Interface Card), an antenna, and a communication circuit according to the communication method.

[0065] (Display section 12) The display unit 12 is a display device that displays various information such as location information. For example, the display unit 12 may be a liquid crystal display (LCD) or an organic electro-luminescent display (OLED). The display unit 12 may also be a touch panel display, but is not limited to this.

[0066] (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 has buttons for inputting characters, numbers, etc. The input unit 13 may also be an input / output port (I / O port) or a USB (Universal Serial Bus) port. If the display unit 12 is a touch panel display, a part of the display unit 12 functions as the input unit 13. The input unit 13 may also be a microphone that receives voice input from the user U. The microphone may be wireless.

[0067] (Positioning unit 14) The positioning unit 14 receives signals (radio waves) transmitted from GPS (Global Positioning System) satellites and, based on the received signals, acquires position information (e.g., latitude and longitude) indicating the current position of the terminal device 10. In other words, the positioning unit 14 determines the position of the terminal device 10. Note that GPS is just one example of a GNSS (Global Navigation Satellite System).

[0068] Furthermore, the positioning unit 14 can determine its position using various methods other than GPS. For example, the positioning unit 14 may use various communication functions of the terminal device 10 to determine its position as an auxiliary positioning means for position correction, etc., as described below.

[0069] (Wi-Fi positioning) For example, the positioning unit 14 determines the location of the terminal device 10 by utilizing the Wi-Fi® communication function of the terminal device 10 and the communication network provided by each telecommunications company. Specifically, the positioning unit 14 determines the location of the terminal device 10 by performing Wi-Fi communication, etc., and determining the distance to nearby base stations and access points.

[0070] (Beacon positioning) Furthermore, the positioning unit 14 may determine the location using the Bluetooth® function of the terminal device 10. For example, the positioning unit 14 determines the location of the terminal device 10 by connecting to a beacon transmitter connected via the Bluetooth® function.

[0071] (Geomagnetic positioning) Furthermore, the positioning unit 14 determines the position of the terminal device 10 based on the geomagnetic pattern of the structure, which has been measured in advance, and the geomagnetic sensor provided by the terminal device 10.

[0072] (RFID positioning) Furthermore, if, for example, the terminal device 10 is equipped with an RFID (Radio Frequency Identification) tag function equivalent to that of a contactless IC card used at a train station ticket gate or in a store, or if it is equipped with a function to read RFID tags, the location where it was used will be recorded along with the information on the payment or other transactions made by the terminal device 10. The positioning unit 14 may determine the location of the terminal device 10 by acquiring such information. Alternatively, the location may be determined by an optical sensor or infrared sensor equipped in the terminal device 10.

[0073] The positioning unit 14 may, if necessary, determine the position of the terminal device 10 using one or a combination of the positioning means described above.

[0074] (Sensor unit 20) The sensor unit 20 includes various sensors mounted on or connected to the terminal device 10. The connection can be wired or wireless. For example, the sensors may be detection devices other than the terminal device 10, such as wearable devices or wireless devices. In the example shown in Figure 7, the sensor unit 20 includes an acceleration sensor 21, a gyro sensor 22, a barometric pressure sensor 23, a temperature sensor 24, a sound sensor 25, a light sensor 26, a magnetic sensor 27, and an image sensor (camera) 28.

[0075] The sensors 21-28 described above are merely examples and not limiting. In other words, the sensor unit 20 may be configured to include some of the sensors 21-28, or it may include other sensors such as humidity sensors in addition to or instead of the sensors 21-28.

[0076] The acceleration sensor 21 is, for example, a 3-axis acceleration sensor and detects the physical movement of the terminal device 10, such as its direction of movement, velocity, and acceleration. The gyro sensor 22 detects the physical movement of the terminal device 10, such as its tilt in the three axes, based on its angular velocity. The barometric pressure sensor 23 detects the atmospheric pressure around the terminal device 10, for example.

[0077] Since the terminal device 10 is equipped with the acceleration sensor 21, gyroscope 22, barometric pressure sensor 23, etc., it becomes possible to determine the position of the terminal device 10 using technologies such as pedestrian dead-reckoning (PDR) that utilize these sensors 21 to 23. This makes it possible to obtain indoor location information that is difficult to obtain with positioning systems such as GPS.

[0078] For example, a pedometer using an accelerometer 21 can calculate the number of steps, walking speed, and distance walked. Additionally, a gyroscope 22 can be used to determine the user U's direction of movement, gaze direction, and body tilt. Furthermore, the barometric pressure sensor 23 can detect atmospheric pressure, allowing the system to determine the altitude and floor level of the user U's terminal device 10.

[0079] The temperature sensor 24 detects, for example, the ambient temperature around the terminal device 10. The sound sensor 25 detects, for example, the ambient sound around the terminal device 10. The light sensor 26 detects the ambient illumination around the terminal device 10. The magnetic sensor 27 detects, for example, the Earth's magnetic field around the terminal device 10. The image sensor 28 captures an image of the area around the terminal device 10.

[0080] The aforementioned pressure sensor 23, temperature sensor 24, sound sensor 25, light sensor 26, and image sensor 28 can detect the surrounding environment and conditions of the terminal device 10 by detecting atmospheric pressure, temperature, sound, and illuminance, respectively, and by capturing images of the surroundings. Furthermore, it becomes possible to improve the accuracy of the location information of the terminal device 10 based on the surrounding environment and conditions.

[0081] (Control Unit 30) The control unit 30 includes, for example, a microcomputer having a CPU (Central Processing Unit), ROM (Read Only Memory), RAM, input / output ports, and various circuits. Alternatively, the control unit 30 may be composed of hardware such as an integrated circuit (ASIC) or FPGA (Field Programmable Gate Array). The control unit 30 includes a transmission unit 31, a reception unit 32, and a processing unit 33.

[0082] (Transmitter 31) The transmission unit 31 can transmit various information, such as information input by user U using the input unit 13, various information detected by sensors 21-28 mounted on or connected to the terminal device 10, and location information of the terminal device 10 determined by the positioning unit 14, to the server device 100 via the communication unit 11. The transmission unit 31 also transmits a request for the issuance of a verifiable certificate (VC) to the server device 100, which will act as the certifier / issuer.

[0083] (Receiving unit 32) The receiving unit 32 can receive various information provided by the server device 100 and requests for various information from the server device 100 via the communication unit 11. The receiving unit 32 also receives verifiable certificates (VCs) from the server device 100, which acts as the authenticator / issuer. The receiving unit 32 may receive not the verifiable certificates (VCs) themselves, but rather location information (access destination) and access rights of separately stored verifiable certificates (VCs).

[0084] (Processing 33) The processing unit 33 controls the entire terminal device 10, including the display unit 12. For example, the processing unit 33 can output and display various information transmitted by the transmission unit 31 and various information received from the server device 100 by the reception unit 32 to the display unit 12. The processing unit 33 also generates an authentication key pair used for FIDO authentication and sends the authentication public key to the server device 100, which will act as the authenticator / issuer, via the transmission unit 31. The processing unit 33 also performs user authentication in FIDO authentication. If user authentication is successful, it issues an authentication assertion signed using the authentication private key and sends the signed authentication assertion to the server device 100, which will act as the authenticator / issuer, via the transmission unit 31. The processing unit 33 may also access verifiable certificates (VCs) stored by the server device 100, which will act as the authenticator / issuer, via an API.

[0085] (Storage unit 40) The storage unit 40 is implemented by, for example, semiconductor memory elements such as RAM (Random Access Memory) and flash memory, or by storage devices such as HDD (Hard Disk Drive), SSD (Solid State Drive), and optical discs. Various programs and various data are stored in this storage unit 40.

[0086] [4. Example of Server Device Configuration] Next, the configuration of the server device 100 according to the embodiment will be described using Figure 8. Figure 8 is a diagram showing an example of the configuration of the server device 100 according to the embodiment. As shown in Figure 8, the server device 100 includes a communication unit 110, a storage unit 120, and a control unit 130.

[0087] (Communications Department 110) The communication unit 110 is implemented, for example, by a NIC (Network Interface Card). The communication unit 110 is also connected to the network N by wired or wireless connection.

[0088] (Storage unit 120) The storage unit 120 is implemented by, for example, a semiconductor memory element such as RAM (Random Access Memory) or flash memory, or a storage device such as an HDD, SSD, or optical disc. The storage unit 120 stores a management database that stores the FIDO public key of user U used for FIDO authentication. The storage unit 120 may also store user U's attribute information and history information (log data) along with identification information (user ID, etc.) that identifies user U.

[0089] (Control unit 130) The control unit 130 is a controller, and is realized by executing various programs (corresponding to an example of an information processing program) stored in the internal memory of the server device 100 using a memory area such as RAM as a working area, for example, by a CPU (Central Processing Unit), MPU (Micro Processing Unit), ASIC (Application Specific Integrated Circuit), or FPGA (Field Programmable Gate Array). In the example shown in Figure 8, the control unit 130 has an acquisition unit 131, an authentication processing unit 132, a key management unit 133, and a certificate issuance unit 134.

[0090] (Acquisition part 131) The acquisition unit 131 acquires the authentication public key (FIDO public key) from the authentication key pair generated by the user U's terminal device 10 via the communication unit 110. For example, when user U registers a key for FIDO authentication, the acquisition unit 131 acquires user U's authentication public key generated by user U's authenticator and stores it in the management database stored in the storage unit 120.

[0091] Furthermore, the acquisition unit 131 may acquire user information relating to user U via the communication unit 110. For example, the acquisition unit 131 may acquire identification information (such as user ID), location information, and attribute information of user U from user U's terminal device 10. The acquisition unit 131 may also acquire identification information and attribute information of user U when user U is registered. The acquisition unit 131 then stores the user information in the storage unit 120.

[0092] Furthermore, the acquisition unit 131 may acquire various historical information (log data) indicating the user U's actions via the communication unit 110. For example, the acquisition unit 131 acquires various historical information indicating the user U's actions from the user U's terminal device 10, or from various servers based on the user ID, etc. The acquisition unit 131 then stores the various historical information in the storage unit 120.

[0093] (Authentication processing unit 132) The authentication processing unit 132 receives a request for the issuance of a verifiable certificate (VC) from the user U's terminal device 10 via the communication unit 110. Furthermore, during FIDO authentication, the authentication processing unit 132 obtains the authentication assertion (authentication result) created by the authenticator terminal device 10 via the communication unit 110. The authentication assertion is signed by the authenticator terminal device 10 using the user U's authentication private key. The authentication processing unit 132 may also include an acquisition unit 131.

[0094] For example, when the authentication processing unit 132 receives a request from user U to issue a verifiable certificate (VC), it performs FIDO authentication on user U, receives an authentication assertion signed using user U's authentication private key from the terminal device 10 which acts as user U's authenticator, and verifies the signature using user U's authentication public key.

[0095] (Key management section 133) The key management unit 133 changes the purpose of use of the authentication public key of user U used for FIDO authentication and makes it publicly available to external parties (other than the authenticator) as a public key for verification within the certificate (VC). The key management unit 133 also requests the terminal device 10, which acts as the authenticator for user U, to generate a new authentication key pair.

[0096] For example, the key management unit 133 deletes the authentication public key of user U used for FIDO authentication from the management database and stores and makes public user U's authentication public key as a public key for verification within the certificate (VC) at the public key site 200. In other words, the key management unit 133 moves user U's authentication public key from the management database to the public key site 200.

[0097] At this time, the key management unit 133 deletes the authentication public key of user U used for FIDO authentication from the management database and requests the terminal device 10, which acts as the authenticator for user U, to generate a new authentication key pair.

[0098] Alternatively, the key management unit 133 requests the terminal device 10, which acts as the authenticator for user U, to disable the authentication private key for user U that corresponds to the authentication public key for user U used for FIDO authentication and to regenerate the authentication key pair.

[0099] Furthermore, the key management unit 133 may request the terminal device 10, which acts as the authenticator for user U, to delete the user U's authentication private key that corresponds to the user U's authentication public key used for FIDO authentication.

[0100] Furthermore, the key management unit 133 provides user U's authentication public key to a specific verifier as a public key for verification within the certificate (VC).

[0101] Furthermore, the key management unit 133 may generate a key pair consisting of a private key for signing the verifiable certificate (VC) and a public key for verifying the signature of the verifiable certificate (VC), and may also expose the public key for verifying the signature of the verifiable certificate (VC) to the outside.

[0102] (Certificate Issuance Section 134) The certificate issuing unit 134 issues a verifiable certificate (VC) containing a signed authentication assertion to user U.

[0103] In this case, when the certificate issuing unit 134 receives a request from user U to issue a verifiable certificate (VC) for a specific verifier, it may issue to user U a verifiable certificate (VC) that includes a signed authentication assertion and has access control that allows access only to the specific verifier.

[0104] Furthermore, the certificate issuing unit 134 may sign a verifiable certificate (VC) containing a signed authentication assertion using the private key for signing the verifiable certificate (VC) and issue it to user U.

[0105] [5. Processing Procedure] Next, the processing procedure by the server device 100 according to the embodiment will be described using Figure 9. Figure 9 is a flowchart of 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.

[0106] For example, as shown in Figure 9, the authentication processing unit 132 of the server device 100 receives a request to issue a verifiable certificate (VC) from the user U's terminal device 10 via the communication unit 110 (step S101).

[0107] Next, when the authentication processing unit 132 of the server device 100 receives a request from user U to issue a verifiable certificate (VC), it performs FIDO authentication on user U, receives an authentication assertion (authentication result) signed using user U's authentication private key from the terminal device 10 which acts as user U's authenticator, and verifies the signature using user U's authentication public key (step S102).

[0108] Next, the key management unit 133 of the server device 100 changes the purpose of use of the authentication public key of user U used for FIDO authentication and makes it publicly available as a public key for verification within the certificate (VC) (step S103). For example, the key management unit 133 deletes the authentication public key of user U used for FIDO authentication from the management database and stores and makes public user U's authentication public key as a public key for verification within the certificate (VC) at the public key site 200.

[0109] Next, the key management unit 133 of the server device 100 requests the terminal device 10, which will act as the authenticator for user U, to generate a new authentication key pair (step S104).

[0110] Next, the certificate issuing unit 134 of the server device 100 issues a verifiable certificate (VC) containing a signed authentication assertion to user U, signing it using the private key for signing the verifiable certificate (VC) (step S105). At this time, the key management unit 133 exposes the public key for verifying the signature of the verifiable certificate (VC) to the outside.

[0111] Next, user U presents a verifiable certificate (VC) to the verification device 300, which will act as the verifier, using terminal device 10 (step S106). At this time, the certificate issuing unit 134 of server device 100 may provide the verifiable certificate (VC) to user U's terminal device 10 and the verification device 300, which will act as the verifier, via API.

[0112] Next, the verification device 300, which acts as the verifier, obtains the public key for signature verification of the published verifiable certificate (VC), and uses the public key for signature verification of the verifiable certificate (VC) to verify the signature of the presented verifiable certificate (VC) (step S107).

[0113] Next, the verification device 300, which acts as the verifier, obtains the verification public key within the published certificate (VC) and uses the verification public key within the certificate (VC) to verify the signature of the signed authentication assertion contained in the verifiable certificate (VC) (step S108).

[0114] [6. Variant Example] The terminal device 10 and server device 100 described above may be implemented in various different forms other than those of the embodiment described above. Therefore, the following describes modifications of the embodiment.

[0115] In the above embodiment, some or all of the processing performed by the server device 100 may actually be performed by the terminal device 10 (or an application running on the terminal device 10). For example, the processing may be completed in a standalone manner (by the terminal device 10 alone). In this case, the terminal device 10 is assumed to have the functions of the server device 100 in the above embodiment. Furthermore, in the above embodiment, since the terminal device 10 is in cooperation with the server device 100, from the perspective of user U, it appears as if the processing of the server device 100 is also being performed by the terminal device 10. In other words, from another perspective, it can be said that the terminal device 10 is equipped with the server device 100.

[0116] Furthermore, in the above embodiment, the terminal device 10 of user U may communicate with the server device 100, which acts as the authenticator / issuer, via an API, and the terminal device 10 may issue a verifiable certificate (VC) as the issuer. Also, the verification device 300, which acts as the verifier, may be another terminal device 10 or another server device 100. For example, the verifier may be another user or another authentication server.

[0117] Furthermore, in the above embodiment, if the verifier is a trustworthy party, such as another verifier / issuer belonging to the same organization as the verifier / issuer, the server device 100 acting as the verifier may not store the authentication public key in the public key site but provide it directly to the verifier (or implement access control on the public key site so that only the verifier can access it), and may continue to use the authentication public key as a public key for FIDO authentication without deleting it from the management database. In other words, the authentication public key may be shared between the verifier / issuer and the verifier. In this case, the authentication public key is also used as the certificate (VC) verification public key between the verifier / issuer and the verifier.

[0118] Furthermore, in the above embodiment, the server device 100 acting as the authenticator / issuer may manage blockchain-verifiable certificates (VCs) using distributed ledger technology (DLT). Also, the public key site 200 may manage verification data such as public keys on the blockchain using distributed ledger technology (DLT).

[0119] Furthermore, in the above embodiment, the same verifiable certificate (VC) may contain the authentication assertions of multiple different users. For example, the server device 100 acting as the authenticator / issuer may perform FIDO authentication on each of multiple users who are members of the same group, obtain a signed authentication assertion for each user, and issue a common verifiable certificate (VC) containing the signed authentication assertions of each user. In this case, the server device 100 acting as the authenticator / issuer stores and publishes each user's authentication public key as a public key for verification within the certificate (VC) at the public key site 200. At this time, the server device 100 acting as the authenticator / issuer may implement access control so that each user's public key for verification within the certificate (VC) is made available to different verifiers.

[0120] Furthermore, in the above embodiment, the server device 100 that acts as the authenticator / issuer may be a smartphone or a tablet terminal. For example, in some embodiments, the terminal device 10 that acts as the authenticator, the server device 100 that acts as the authenticator / issuer, and the verification device 300 that acts as the verifier may all be smartphones. Also, the server device 100 that acts as the authenticator / issuer may be a smartphone on which a container has been built that performs FIDO authentication in cooperation with a container engine that provides FIDO authentication functionality via an API.

[0121] [7. Effects] As described above, the information processing device (server device 100) according to the present invention is characterized by comprising: an authentication processing unit 132 that, upon receiving a request from user U to issue a verifiable certificate (VC), performs FIDO authentication on user U, receives an authentication result (authentication assertion) signed using user U's authentication private key from user U's authenticator (terminal device 10), and verifies the signature using user U's authentication public key; a key management unit 133 that changes the purpose of use of user U's authentication public key used for FIDO authentication and publishes it externally as a public key for verification within the certificate (VC), and requests user U's authenticator (terminal device 10) to generate a new authentication key pair; and a certificate issuing unit 134 that issues a verifiable certificate (VC) including the signed authentication result to user U.

[0122] This provides a means to verify the authentication results contained in the certificate. In conventional FIDO, if a certificate issued after user authentication includes a signed authentication result, it is common practice that the public key for verifying the signed authentication result is not disclosed to anyone other than the authenticator. Therefore, there was no way for the verifier to verify the authentication result contained in the certificate. As a new technical concept that differs from conventional practices, when a certificate containing a signed authentication result is requested, the original authentication public key used for FIDO authentication is made public as the public key for verifying the signed authentication result contained in the certificate, and a new authentication key pair is generated.

[0123] The key management unit 133 deletes the authentication public key of user U used for FIDO authentication from the management database, and stores and makes public user U's authentication public key as a public key for verification within the certificate (VC) at the public key site 200.

[0124] This allows the original public authentication key, which has been made publicly available, to be discarded as it is no longer needed. Additionally, the user's authentication public key used for FIDO authentication can be moved from the management database to the public key site.

[0125] The key management unit 133 deletes the authentication public key of user U used for FIDO authentication from the management database and requests the authenticator (terminal device 10) of user U to generate a new authentication key pair.

[0126] This allows for the simultaneous destruction of the original public authentication key that has been exposed externally and the generation of a new public authentication key.

[0127] The key management unit 133 requests the authenticator (terminal device 10) of user U to disable the authentication private key of user U that corresponds to the authentication public key of user U used for FIDO authentication and to regenerate the authentication key pair.

[0128] This prevents the authenticator from using the original authentication private key corresponding to the original authentication public key that has been exposed externally, and allows the authenticator to be required to recreate the authentication key pair.

[0129] The key management unit 133 requests user U's authenticator (terminal device 10) to delete user U's authentication private key, which corresponds to user U's authentication public key used for FIDO authentication.

[0130] This allows the authenticator to destroy the original authentication private key that corresponds to the original authentication public key that has been exposed externally.

[0131] When the certificate issuing unit 134 receives a request from user U to issue a verifiable certificate (VC) for a specific verifier, it issues to user U a verifiable certificate (VC) that includes a signed authentication result and has access control so that it can only be accessed by the specific verifier.

[0132] This makes it possible to issue certificates (VCs) that are accessible only to specific verifiers, such as company A.

[0133] The key management unit 133 provides user U's authentication public key to a specific verifier as a public key for verification within the certificate (VC).

[0134] This allows the public key for certificate (VC) verification to be provided only to specific verifiers, such as company A. In this case, the public key site can also store the public key with access control enabled, allowing only specific verifiers to access it.

[0135] The key management unit 133 generates a key pair consisting of a private key for signing the verifiable certificate (VC) and a public key for verifying the signature of the verifiable certificate (VC), and publishes the public key for verifying the signature of the verifiable certificate (VC) to the outside. The certificate issuing unit 134 signs the verifiable certificate (VC), which includes the signed authentication result, using the private key for signing the verifiable certificate (VC), and issues it to user U.

[0136] This allows the entire certificate (VC), including the signed authentication result, to be signed separately and validated as a whole.

[0137] Through any or a combination of the above-described processes, the information processing device according to the present application can provide a means for verifying the authentication result contained in a certificate. Furthermore, the authentication key pair can be automatically updated each time a verifiable certificate (VC) is issued. In addition, a verifier can verify the signed authentication result contained in a verifiable certificate (VC) in the same way as an authenticator.

[0138] [8. Hardware Configuration] Furthermore, the terminal device 10 and server device 100 according to the above-described embodiment are realized by a computer 1000 having a configuration such as that shown in Figure 10. The following explanation will use the server device 100 as an example. Figure 10 shows an example of the hardware configuration. The computer 1000 is connected to an output device 1010 and an input device 1020, and has a configuration in which an arithmetic unit 1030, a primary storage device 1040, a secondary storage device 1050, an output interface 1060, an input interface 1070, and a network interface 1080 are connected by a bus 1090.

[0139] The arithmetic unit 1030 operates based on programs stored in the primary storage device 1040 and the secondary storage device 1050, as well as programs read from the input device 1020, and executes various processes. The arithmetic unit 1030 can be implemented 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).

[0140] The primary storage device 1040 is a memory device, such as RAM (Random Access Memory), that temporarily stores data used by the arithmetic unit 1030 for various calculations. The secondary storage device 1050 is a storage device where data used by the arithmetic unit 1030 for various calculations and various databases are registered, and can be implemented using ROM (Read Only Memory), HDD (Hard Disk Drive), SSD (Solid State Drive), flash memory, etc. The secondary storage device 1050 may be internal storage or external storage. The secondary storage device 1050 may also be a removable storage medium such as USB (Universal Serial Bus) memory or SD (Secure Digital) memory card. The secondary storage device 1050 may also be cloud storage (online storage), NAS (Network Attached Storage), file server, etc.

[0141] The output I / F 1060 is an interface for transmitting information to be output to output devices 1010, such as displays, projectors, and printers, and is implemented using connectors of standards such as USB (Universal Serial Bus), DVI (Digital Visual Interface), and HDMI (High Definition Multimedia Interface). The input I / F 1070 is an interface for receiving information from various input devices 1020, such as mice, keyboards, keypads, buttons, and scanners, and is implemented using, for example, USB.

[0142] Furthermore, the output interface 1060 and input interface 1070 may be wirelessly connected to the output device 1010 and input device 1020, respectively. In other words, the output device 1010 and input device 1020 may be wireless devices.

[0143] Furthermore, the output device 1010 and the input device 1020 may be integrated as 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.

[0144] The input device 1020 may also be a device that reads information from, for example, an optical recording medium such as a CD (Compact Disc), DVD (Digital Versatile Disc), or PD (Phase Change Rewritable Disk), a magneto-optical recording medium such as an MO (Magneto-Optical disk), a tape medium, a magnetic recording medium, or a semiconductor memory.

[0145] The network interface 1080 receives data from other devices via network N and sends it to the computing unit 1030, and also transmits data generated by the computing unit 1030 to other devices via network N.

[0146] The arithmetic unit 1030 controls the output device 1010 and the input device 1020 via the output interface 1060 and the input interface 1070. For example, the arithmetic unit 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.

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

[0148] [9. Other] Although embodiments of the present invention have been described above, the present invention is not limited by the content of these embodiments. Furthermore, the aforementioned components include those that can be easily conceived by those skilled in the art, those that are substantially the same, and those that fall within the so-called equivalent range. Moreover, the aforementioned components can be combined as appropriate. Furthermore, various omissions, substitutions, or modifications of the components can be made without departing from the gist of the embodiments described above.

[0149] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by known methods. In addition, the processing procedures, specific names, and information including various data and parameters shown in the above document and drawings can be arbitrarily changed unless otherwise specified. For example, the various information shown in each figure is not limited to the information shown.

[0150] Furthermore, the components of each illustrated device are functionally conceptual and do not necessarily need to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.

[0151] For example, the server device 100 described above may be implemented using multiple server computers, and the configuration can be flexibly changed, such as by calling external platforms via APIs (Application Programming Interfaces) or network computing depending on the function.

[0152] Furthermore, the embodiments and modifications described above can be combined as appropriate, provided that the processing content is not inconsistent.

[0153] Furthermore, the terms "section, module, unit" mentioned above can be replaced with "means" or "circuit," etc. For example, the acquisition unit can be replaced with acquisition means or acquisition circuit. [Explanation of Symbols]

[0154] 1. Information Processing System 10 Terminal devices 100 Server Devices 110 Communications Department 120 Storage section 130 Control Unit 131 Acquisition Department 132 Authentication Processing Unit 133 Key Management Department 134 Certificate Issuance Department 200 public key sites 300 Verification devices

Claims

1. An authentication processing unit, upon receiving a request from a user for the issuance of a verifiable certificate, performs FIDO authentication on the user, receives an authentication result signed using the user's authentication private key from the user's authenticator, and verifies the signature using the user's authentication public key. A key management unit that changes the purpose of use of the user's authentication public key used for FIDO authentication and makes it publicly available as a certificate verification public key, and requests the user's authenticator to generate a new authentication key pair, A certificate issuing unit that issues a verifiable certificate containing the signed authentication result to the user, An information processing device characterized by comprising:

2. The aforementioned key management unit deletes the user's authentication public key used for FIDO authentication from the management database, and stores the user's authentication public key as a certificate verification public key on the public key site and makes it public. The information processing apparatus according to feature 1.

3. The key management unit deletes the user's authentication public key used for FIDO authentication from the management database and requests the user's authenticator to generate a new authentication key pair. The information processing apparatus according to feature 1.

4. The key management unit requests the user's authenticator to disable the user's authentication private key corresponding to the user's authentication public key used for FIDO authentication and to regenerate the authentication key pair. The information processing apparatus according to feature 1.

5. The key management unit requests the user's authenticator to delete the user's authentication private key corresponding to the user's authentication public key used for FIDO authentication. The information processing apparatus according to feature 1.

6. When the certificate issuing unit receives a request from the user for the issuance of a verifiable certificate for a specific verifier, it issues to the user a verifiable certificate that includes the signed authentication result and has access control that allows only the specific verifier to access it. The information processing apparatus according to feature 1.

7. The key management unit provides the user's authentication public key to the specified verifier as a public key for certificate verification. The information processing apparatus according to feature 6.

8. The key management unit generates a key pair consisting of a private key for signing the verifiable certificate and a public key for verifying the signature of the verifiable certificate, and publishes the public key for verifying the signature of the verifiable certificate. The certificate issuing unit signs the verifiable certificate containing the signed authentication result using the private key for signing the verifiable certificate and issues it to the user. The information processing apparatus according to feature 1.

9. An information processing method performed by an information processing device, The authentication process includes receiving a request from a user for the issuance of a verifiable certificate, performing FIDO authentication on the user, receiving an authentication result signed using the user's authentication private key from the user's authenticator, and verifying the signature using the user's authentication public key, A key management process that involves changing the purpose of use of the user's authentication public key used for FIDO authentication and exposing it externally as a public key for certificate verification, and requesting the user's authenticator to generate a new authentication key pair, A certificate issuance step of issuing a verifiable certificate containing the signed authentication result to the user, An information processing method characterized by including

10. An authentication process procedure in which, upon receiving a request from a user for the issuance of a verifiable certificate, FIDO authentication is performed on the user, an authentication result signed using the user's authentication private key is received from the user's authenticator, and the signature is verified using the user's authentication public key, A key management procedure that changes the purpose of use of the user's authentication public key used for FIDO authentication and exposes it externally as a public key for certificate verification, and requests the user's authenticator to generate a new authentication key pair, A certificate issuance procedure for issuing a verifiable certificate containing the signed authentication result to the user, An information processing program characterized by causing a computer to execute it.

Images