Authentication system, information processing method for authentication system, and program

Abstract

The present disclosure relates to an authentication system, an information processing method for the authentication system, and a program that make it possible to prevent spoofing in personal authentication. A terminal device: supplies, via a chip by means of short-range communication, terminal identification information to a collation server through communication over a first network; and supplies, to the collation server, a certificate including attribute information about an owner of a terminal and the terminal identification information through communication over a second network different from the first network. The collation server: receives the terminal identification information and the certificate; verifies the certificate; and authenticates the terminal device by collating the pieces of terminal identification information respectively acquired in the first network and the second network. The present invention can be applied to an attendance management system.

Description

Authentication system, information processing method for authentication system, and program

[0001] The present disclosure relates to an authentication system, an information processing method for the authentication system, and a program, and in particular to an authentication system, an information processing method for the authentication system, and a program that prevent impersonation in personal authentication processing and ensure that the person being authenticated is in a specific location.

[0002] Identity verification and authentication technologies that use short-range communication such as NFC (Near Field Communication) are becoming increasingly common.

[0003] For example, a technology has been proposed in which certificate information used to authenticate a person is encrypted and stored in a mobile device such as a smartphone, and then presented via an NFC reader / writer to verify the validity of the certificate information, thereby authenticating the person's identity (see Patent Document 1).

[0004] JP 2011-155495 A

[0005] However, with the technology of Patent Document 1, even if the certificate information is highly encrypted, if it is copied and transferred to another person's mobile terminal and shared, it is impossible to distinguish whether the presented certificate information is the certificate information presented from the person's own mobile terminal or the certificate information presented from another person's mobile terminal. This raises the risk that the owner of the certificate information may be authenticated even if he or she is not in front of the NFC reader / writer, which could essentially make it possible to impersonate the person.

[0006] The present disclosure has been made in light of these circumstances, and particularly aims to prevent impersonation in identity confirmation and authentication. When verifying a person's identity, biometric authentication is used to confirm a match with pre-stored data, or the person presents data they hold, and the accuracy of the data is confirmed through authenticity assessment, and the person is then authenticated. There are also cases where these are used in a hybrid manner, where data can be presented as a result of biometric authentication, and identity confirmation and authentication are performed. In this disclosure, the term "identity authentication" includes some and all of the above-mentioned patterns.

[0007] An authentication system according to one aspect of the present disclosure is an authentication system comprising a terminal device, a terminal device, and a matching server, wherein the terminal device acquires connection information relating to communication with the matching server via a first network through short-range communication, and based on the connection information, transmits a certificate including attribute information of its holder to the matching server via communication through the first network, and the matching server receives the certificate transmitted via the first network and verifies the certificate to authenticate the terminal device, thereby confirming that the terminal device is within a range where short-range communication is possible and then authenticating the terminal holder and the terminal.

[0008] An information processing method for an authentication system according to one aspect of the present disclosure is an information processing method for an authentication system including a terminal device and a matching server, the information processing method including an authentication process for authenticating the terminal device, in which the terminal device performs an acquisition process for acquiring connection information related to communication with the matching server via a first network using short-range communication, a transmission process for transmitting a certificate including attribute information of its holder to the matching server via communication via the first network based on the connection information, a reception process for the matching server receiving the certificate transmitted via the first network, and an authentication process for authenticating the terminal device by verifying the certificate.

[0009] In one aspect of the present disclosure, a terminal device acquires connection information related to communication with the matching server via a first network via short-range communication, and based on the connection information, a certificate including attribute information of its holder is sent to the matching server via communication via the first network, and the matching server receives the certificate of the identification information sent via the first network and verifies the certificate, thereby authenticating the terminal device.

[0010] 14 is a diagram illustrating an example of the configuration of an identity authentication system. FIG. 15 is a diagram illustrating an mdoc data format. FIG. 16 is a diagram illustrating the basic configuration of a Verifiable Credential. FIG. 17 is a diagram illustrating authentication processing by the identity authentication system of FIG. 1. FIG. 18 is a diagram illustrating a modified example of authentication processing by the identity authentication system of FIG. 1. FIG. 19 is a diagram illustrating an overview of the identity authentication system of the present disclosure. FIG. 19 is a diagram illustrating an example of the configuration of the identity authentication system of the present disclosure. FIG. 19 is a diagram illustrating identity authentication processing by the identity authentication system of the first embodiment of the present disclosure. FIG. 19 is a flowchart illustrating identity authentication processing by the identity authentication system in a modified example of the first embodiment of the present disclosure. FIG. 19 is a flowchart illustrating identity authentication processing by the identity authentication system in a modified example of the first embodiment of the present disclosure. FIG. 19 is a diagram illustrating an example of a case where the identity authentication system of the present disclosure is applied to an attendance management system. FIG. 19 is a flowchart illustrating processing when multiple user terminals are used in an attendance management system. FIG. 19 is a diagram illustrating a display example of a UI image of the attendance management system. FIG. 19 is a diagram illustrating a display example of a pop image when attending a face-to-face class in the UI image of FIG. 14. FIG. 19 is a diagram illustrating a display example of a pop image when attending a face-to-face class in the UI image of FIG. 14 and a display example of a UI image after operation. 15 is a diagram illustrating a display example of a pop image in the UI image of FIG. 14 when attending a remote class. FIG. 15 is a diagram illustrating a display example of a UI image after an operation in the UI image of FIG. 14 when attending a remote class. FIG. 15 is a diagram illustrating personal authentication processing by the personal authentication system of the second embodiment of the present disclosure. FIG. 15 is a flowchart illustrating personal authentication processing by the personal authentication system of the second embodiment of the present disclosure. FIG. 15 is a diagram illustrating personal authentication processing by the personal authentication system in a modified example of the second embodiment of the present disclosure. FIG. 15 is a flowchart illustrating personal authentication processing by the personal authentication system in a modified example of the second embodiment of the present disclosure. FIG. 15 is a diagram illustrating personal authentication processing by the personal authentication system of the third embodiment of the present disclosure. FIG. 15 is a flowchart illustrating personal authentication processing by the personal authentication system of the third embodiment of the present disclosure. FIG. 15 is a diagram illustrating personal authentication processing by the personal authentication system in a modified example of the third embodiment of the present disclosure.13 is a flowchart illustrating an example of a personal authentication process by a personal authentication system according to a modified example of the third embodiment of the present disclosure.

[0011] Preferred embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. In this specification and drawings, components having substantially the same functional configurations are designated by the same reference numerals, and redundant description will be omitted.

[0012] Hereinafter, embodiments of the present technology will be described in the following order.

[0013] 1. Overview of the present disclosure 2. First embodiment 3. Second embodiment 4. Third embodiment 5. Example of execution by software

[0014] <<1. Overview of the Present Disclosure>> The present disclosure is directed to preventing impersonation in personal authentication in particular. Therefore, first, an overview of the present disclosure will be described.

[0015] Fig. 1 shows an example of the configuration of an authentication system for realizing authentication of an individual. The authentication system 11 in Fig. 1 is composed of a mobile terminal 31, an NFC (Near Field Communication) chip (NFC reader or NFC tag) 32, and a verification server 33.

[0016] The mobile terminal 31 is a communication terminal, such as a smartphone, owned by a user and stores terminal identification information consisting of an IMEI (International Mobile Equipment Identity) that identifies the terminal itself. In this disclosure, the IMEI is used as an identifier to identify the terminal itself. However, instead of the terminal itself, the IMEI may be an identification number of up to 15 digits compliant with the ITU-T E.212 standard that is linked to a telephone number and managed, such as an IMSI (International Mobile Subscription Identity) stored on a SIM (Subscriber Identity Module) card inserted into the terminal or an eSIM (Embedded Subscriber Identity Module) chip built into the terminal. Furthermore, a chip such as an iSIM (Integrated Subscriber Identity Module) may be used, which integrates the functions of a communication module and SIM or eSIM, which previously existed as independent components, into a single chip (SoC: System-on-Chip). Using such information, the uniqueness of the mobile terminal can be expressed and used to identify it from other terminals. The device's Media Access Control (MAC) address when connected via Wi-Fi or Bluetooth Low Energy (BLE) can also be used for identification, utilizing similar uniqueness.

[0017] Although it is written as device identification information, as long as it is an identifier for identifying the device itself, it does not have to be an ID limited to hardware. It is also acceptable for the server to assign a unique ID to the mobile app, or for the mobile app operator to use an ID function provided by the mobile device platform to uniquely identify the device to use a uniquely renumbered identifier.

[0018] Therefore, device identification information can also be expressed as "identification information" that is not limited to the device itself, or as "device / app identification information" that identifies the device itself and / or the device app. However, in this specification, the term "device identification information" will be used consistently to include the meaning of the above-mentioned "identification information" and "device / app identification information," and the following explanation will proceed accordingly.

[0019] The mobile terminal 31 has an NFC communication function for communicating with the NFC chip 32 at a high frequency of 13.56 MHz.

[0020] A terminal application (application program) 41 is installed on the mobile terminal 31. The terminal application may be installed by the user or may be pre-installed by the OS (Operating System) developer. In this case, the user can perform the process without any additional steps when purchasing the device. For example, this function may be implemented by a wallet application provided by the OS developer, such as Google or Apple. Alternatively, the terminal may be pre-installed after negotiations with these companies prior to shipping. The terminal application 41 generates or stores a read command for reading URI (Uniform Resource Identifier) ​​information and a session ID (Identifier), which are connection information with the outside world, through communication with the NFC chip 32. The terminal application 41 also acquires the URI information and session ID, which are fixed information provided by the NFC chip 32, based on the command.

[0021] The mobile terminal 31 has a communication function for transmitting and receiving data to and from the verification server 33 via a network such as the Internet.

[0022] Users can access a database containing their personal information by logging in to a site that manages their IDs, such as a university, company, or public facility (gym, gymnasium, swimming pool, etc.), through a device app. By requesting a certificate from the site that hosts the database containing their personal information, they can download a certificate containing attribute information that identifies them. For example, if you are a student, you will be issued a certificate containing attribute information such as your school name, department, year, date of enrollment, expected date of graduation, date of issue, expected date of expiration (renewal), email address, and student ID number, along with a photo like a student ID card. For example, a company employee would be issued a certificate containing attribute information, such as common information like company name, company address, and main phone number; personal information about the employee, such as department, job title, telephone number, fax number, business mobile phone number, email address, date of employment, expected expiration (renewal) date, skills, and qualifications (date of acquisition, expected expiration date); work-related information, such as number of days worked, overtime hours, expected date of parental leave, date of parental leave taken, number of annual paid vacation days used, and remaining annual paid vacation days; and income-related information, such as last year's annual salary, monthly salary, taxes such as company insurance premiums paid, life insurance premiums, and earthquake insurance premiums. For example, a personal car certificate could be considered for someone who owns a car, combining driver's license information and vehicle attributes. In this case, it is foreseeable that information from the driver's license and vehicle inspection certificate would be combined. This is envisioned as a single certificate that combines a publicly issued driver's license with a privately issued ownership certificate. Additionally, in Japan, there is an ID card such as the My Number Card that every citizen holds, but such a certificate could be stored in a mobile app, and private parties could use it as a basis to add other information and issue certificates. This would allow public institutions to guarantee the four basic pieces of information associated with an individual - name, address, gender, and date of birth - and then private institutions, organizations, and companies could add attributes that they can guarantee to create a single certificate.

[0023] These certificates comply with the mdoc format specified in ISO / IEC 18013 Part 5: Mobile driving license (mDL) application, for example. In this case, the certificate attribute data is assigned an identifier called DocType, and the attribute data is registered together with the identifier in a namespace called NameSpace. The digital student ID, digital employee ID, digital personal car certificate, and digital general-purpose eID certificate are listed in Tables 1 to 4 below, respectively.

[0024]

[0025]

[0026]

[0027]

[0028] A data object called a Mobile Security Object (MSO) associated with a Name Space stores a hash value generated for each item of attribute information described in the Name Space. The MSO, which stores multiple hash values, also contains the public key of an asymmetric encryption algorithm key pair generated by the device application. A signature is generated for the entire data using the issuer's private key and is managed together with the MSO. The structure is shown in Figure 2. In this case, it is expected that a student ID card would be issued by an educational institution such as a university, an employee ID card by the employee's company, a personal car certificate by a dealer or car manufacturer, and an eID by the government or a public institution commissioned by the government.

[0029] To issue an MDoc-format student ID card, a user logs in to a university website using the mobile app mentioned above. The device app generates a key pair for an asymmetric cryptographic algorithm, registers the public key information on the website, and then the issuance process is initiated by the university. An encrypted session using protocols such as SSL (Secure Sockets Layer) or TLS (Transport Layer Security) is established between the university and the device app, and after the university processes the certificate, the MDoc-format certificate is registered in the mobile app. Asymmetric cryptographic algorithms include public key cryptography (RSA), which relies on the difficulty of factoring large composite numbers, and elliptic curve cryptography (ECC), which relies on the difficulty of solving the discrete logarithm problem on an elliptic curve. However, since quantum computers will likely be more susceptible to decryption due to their mathematical complexity, lattice cryptography, which is being considered as post-quantum cryptography (PQC), may also be used. The signature encryption used in certificates is not limited to these cryptographic algorithms; similar technologies can be used without issue as long as the certificate can be verified to have been issued by the correct issuer.

[0030] It is also possible to create similar certificates using the Verifirable Credentials Data Model, which is currently under discussion at the W3C. The Verifirable Credentials Data Model is shown in Figure 3. Credential Metadata is metadata indicating the issuer and the date and time of issue, Claim(s) is the content of the certificate, and Proof(s) is a digital signature by the issuer. Consequently, a verifiable credential may also include identifiers and metadata describing the properties of the credential, such as the issuer, validity period, photo, verification materials, and status information. A verifiable credential is a tamper-proof combination of Claim(s) and Metadata, and uses a signature to verify who issued it. Examples of verifiable credentials include, but are not limited to, digital birth certificates, digital transcripts, learning history certificates, degrees (graduation certificates), and awards. For reference, Table 5 shows an example of a graduation certificate generated using VC.

[0031]

[0032] In this disclosure, certificates are assumed to be in mdoc format or Verifirable Credential format, but it is assumed that the certificates are managed by the user on a medium such as a mobile phone, and there are no limitations on the implementation form.

[0033] Terminal application 41 has a certificate signed using a private key, and supplies it to verification server 33 along with terminal identification information that identifies itself, based on connection information consisting of URI information and a session ID obtained from NFC chip 32, to request personal authentication. Terminal application 41 then obtains and presents the personal authentication result supplied from verification server 33 in response to the personal authentication request.

[0034] The NFC chip 32 is, for example, an NFC tag combined with an antenna, and, based on a command to read the connection information supplied through communication with the mobile terminal 31, supplies the mobile terminal 31 with connection information consisting of URI information consisting of fixed values ​​and a session ID also consisting of fixed values.

[0035] When the verification server 33 receives the certificate and terminal identification information supplied from the mobile terminal 31 via the network, it verifies the certificate using the issuer's public key, which is the counterpart of the private key used in the issuer's signature that was attached to the certificate, and supplies the mobile terminal 31 with an identity authentication result based on the verification result. The relationship between the public key and the private key may be a simple pair, or may be structured as a system of a certificate chain consisting of root certificates. In such cases, multiple certificates will be presented, and an intermediate certificate will be attached to guarantee the public key that is the counterpart of the private key attached in the certificate.

[0036] The personal authentication process in the personal authentication system 11 of FIG. 1 is, for example, the process shown in FIG.

[0037] That is, in the first process St1, the terminal application 41 of the mobile terminal 31 communicates with the NFC chip 32 to supply a read command requesting the reading of URI information and a session ID, which are connection information.

[0038] In the second process St2, the NFC chip 32 reads connection information consisting of URI information and a session ID, both of which are fixed values, based on the read command, and supplies the information to the mobile terminal 31. The terminal application 41 of the mobile terminal 31 acquires the connection information consisting of URI information and a session ID, both of which are fixed values, supplied from the NFC chip 32. For example, if the URI information is for a university, it is assumed that the URL is "https: / / www.sample_univ.ac.jp / login.html;jsessionid=". Note that in FIG. 4, "ABCD" is shown as the session ID. In this case, the connection information may be "https: / / www.sample_univ.ac.jp / login.xhtml;jsessionid=ABCD". If the "https: / / " and ";jsessionid=" portions are system-defined messages, they can be omitted, and the terminal application 41 can fill in the information.

[0039] In the third process St3, terminal application 41 accesses verification server 33 based on the acquired connection information consisting of URI information and a session ID, which are fixed values, and provides a certificate signed with a private key along with terminal identification information to request personal authentication. Note that in FIG. 4, "IMEI (350568431468505)" is shown as the terminal identification information. A mobile application ID such as "879.212.071.20.807" can be used. It is more convenient if these IDs are managed in advance by the access control system, and are issued when the mobile application is installed and the user is registered.

[0040] In the fourth process St4, when the verification server 33 acquires the certificate and terminal identification information supplied by the mobile terminal 31, it verifies the certificate using the public key that is the counterpart of the private key used for the signature attached to the certificate, performs identity authentication, and notifies the mobile terminal 31 of the authentication result.

[0041] However, in the case of Figure 4, if the certificate and terminal identification information are transferred to and shared with another mobile terminal 31 owned by another person, the other mobile terminal 31 may be able to impersonate the user using the certificate and terminal identification information.

[0042] Therefore, as shown in second process St2' in Fig. 5, the NFC chip 32 may generate a session ID using random numbers each time it receives a read command, generate connection information together with URI information consisting of a fixed value, and supply the connection information to the terminal application of the mobile terminal 31. In Fig. 5, the session ID is set to "EFGH." In this case, the connection information may be "https: / / www.sample_univ.ac.jp / login.xhtml;jsessionid=EFGH."

[0043] In this case, the session ID included in the connection information acquired by terminal application 41 will be a different value each time, and even if terminal application 41 accesses verification server 33 based on connection information consisting of an old session ID and URI information, the session ID will be determined to be old. In this case, communication cannot be established, and the certificate cannot be sent at all, making identity authentication impossible. Alternatively, if communication can be established even with an old session ID, it will be possible to send a certificate to verification server 33, but since the person who first received the session ID uses it, multiple certificates will be registered for the same session ID. This will also reveal that the person who originally acquired it forwarded it to someone else, which may have the effect of revealing those who facilitated fraud and those who used it.

[0044] 5, if the latest unused session ID and terminal identification information are transferred to and shared with another mobile terminal along with the certificate, the other mobile terminal will also be able to access the verification server 33 using the latest session ID, making it possible for impersonation to occur. Also, even if the information transferred to the other mobile terminal contains only an unused session ID, there is a risk that the person who accessed the verification server 33 may not be the person who sent the read command to the NFC chip 32.

[0045] Therefore, in the present disclosure, a fixed terminal such as a storefront terminal that can communicate with the verification server via a network is provided, and is connected in a state in which it can communicate with the NFC chip.

[0046] With this configuration, the mobile terminal and the matching server exchange terminal identification information stored in the mobile terminal and connection information consisting of a session ID and URI information generated by the matching server via the fixed terminal, and then register them in correspondence with each other.

[0047] Furthermore, the mobile terminal accesses the verification server based on the connection information via a network that does not involve a fixed terminal, and supplies the certificate required for personal authentication together with the terminal identification information, requesting personal authentication.

[0048] Hereinafter, the process by which the mobile terminal and the verification server mutually register and store the connection information and terminal identification information in association with each other will be referred to as the registration process of the terminal identification information and the connection information (or simply the registration process). Note that the mobile terminal does not necessarily need to register and store the connection information and terminal identification information in association with each other, and may immediately perform processing based on the received connection information.

[0049] Furthermore, after the registration process is completed, the mobile terminal accesses the matching server based on the connection information, supplies the certificate and terminal identification information required for personal authentication, and requests personal authentication. This process of verifying the certificate and determining whether the terminal identification information supplied along with the certificate matches the terminal identification information registered in the registration process is also referred to as the certificate verification process (or simply the verification process) using the terminal identification information and connection information.

[0050] More specifically, as shown in Fig. 6, authentication system 51 of the present disclosure is composed of mobile terminal 61, NFC chip 62, fixed terminal 63, and verification server 64. Note that mobile terminal 61, NFC chip 62, and verification server 64 in Fig. 6 correspond to mobile terminal 31, NFC chip 32, and verification server 33 in Figs. 4 and 5. Furthermore, terminal application 71 is installed on mobile terminal 61. Terminal application 71 corresponds to terminal application 41.

[0051] The fixed terminal 63 is a fixed terminal such as a point-of-sale (POS) terminal installed in a store, a tablet terminal, a PC terminal, or a mobile terminal, and is configured to communicate with the verification server 64 via a network. The term "fixed terminal" is used merely to contrast with a user's mobile terminal, since it does not refer to a terminal carried by a specific store employee, but rather to a terminal used by an unspecified number of store employees working at a given time to log in and check in. If the BYOD (Bring Your Own Device) feature is applied to store employees' mobile terminals, and the use of personal PCs or smartphones for work becomes common or a useful service, the mobile terminal may be referred to as a fixed terminal only when performing work, and the employee may use it as a personal mobile phone at other times. Considering the case of professors, full-time lecturers, and adjunct lecturers using their own mobile phones to take attendance at universities, the use of BYOD is expected to become more common, and some universities have already implemented it. In the present disclosure, as long as the fixed terminal is capable of communicating with the verification server 64 via a network in advance, there is no limitation as to whether the terminal is fixed to a store (connected to the store) or associated with a person and managed. The fixed terminal 63 is connected to an NFC chip 62 consisting of an NFC reader or an NFC tag via a USB (Universal Serial Bus) connection, a BLE (Bluetooth Low Energy) connection, or is built into the fixed terminal 63 itself, and is configured to be able to communicate with each other.In this disclosure, BLE and NFC are merely one implementation form, and any proximity, short-distance communication method for indicating presence in a specific space satisfies the requirements of this disclosure, so the same configuration can be achieved by using standards such as already commonly used Wi-Fi (Wireless Fidelity), RFID (Radio Frequency Identification), UWB (Ultra Wide Band), which is an ultra-wideband wireless communication technology, TransferJet, a short-distance wireless communication technology, and its next-generation standard, TransferJet X. If a mobile terminal referred to as fixed terminal 63 has an NFC chip 62 built in, there is no problem in using the two configurations as a single mobile terminal.

[0052] First, fixed terminal 63 sends a session request to matching server 64, requesting the issuance of connection information consisting of a session ID and URI information. In response, matching server 64 issues a session ID and generates URI information, and supplies both as connection information to fixed terminal 63. Fixed terminal 63 holds the connection information consisting of the session ID and URI information supplied by matching server 64.

[0053] Next, when the user holds mobile terminal 61 over NFC chip 62, terminal application 71 of mobile terminal 61 communicates with fixed terminal 63 via NFC chip 62 by communicating with NFC chip 62, and supplies fixed terminal 63 with a read command for reading connection information consisting of a session ID and URI information, and in response, fixed terminal 63 reads the connection information and supplies the connection information to terminal application 71 via NFC chip 62. In response, terminal application 71 acquires the connection information. That is, at this point, terminal application 71 holds the terminal identification information it manages itself in association with the connection information consisting of the session ID and URI information.

[0054] Subsequently, the terminal application 71 of the mobile terminal 61 supplies the fixed terminal 63 via the NFC chip 62 with the terminal identification information and a write command requesting that the terminal identification information be written.

[0055] When the fixed terminal 63 stores the terminal identification information based on the write command for the terminal identification information via the NFC chip 62, it supplies the stored terminal identification information to the verification server 64. That is, at this point, the verification server 64 stores the terminal identification information managed by the terminal application 71 of the mobile terminal 61 in association with connection information consisting of a session ID and URI information. Note that, in response to the write command via the NFC chip 62, the fixed terminal 63 can temporarily store the information by writing it to RAM, or can permanently store the information by writing it to non-volatile memory such as Flash.

[0056] That is, the processing up to this point is the registration processing of the terminal identification information and the connection information.

[0057] Based on the connection information consisting of the acquired session ID and URI information, the terminal application 71 accesses the verification server 64 via a different route that does not go through the fixed terminal 63, requests identity authentication of the user of the mobile terminal 61, and after identity authentication is completed, provides the verification server 64 with a certificate signed with the private key together with the terminal identification information.

[0058] When the verification server 64 receives the certificate and terminal identification information provided together with the request for personal authentication, it verifies whether the certificate is authentic using the public key that is the counterpart of the private key used for the signature attached to the certificate, and compares the terminal identification information registered in association with the session ID and the corresponding connection information with the terminal identification information provided in association with the certificate. The verification server 64 then performs personal authentication based on whether the certificate is authentic and whether the terminal identification information matches the registered information, and notifies the mobile terminal 61 of the authentication result.

[0059] That is, the process from the completion of the registration process up to this point is the process of verifying the certificate using the terminal identification information and connection information.

[0060] As described above, when the user holds the mobile terminal 61 over the NFC chip 62, the mobile terminal 61 and the matching server 64 communicate via the fixed terminal 63 as shown by route R1 in Figure 6, and the connection information and terminal identification information are mutually stored through a registration process.

[0061] After the registration process is completed, the mobile terminal 61 accesses the matching server 64 based on the session ID and URI information in the connection information by communicating via a different network, not via the fixed terminal 63, as shown by route R2 in Figure 6, and provides a certificate signed with the private key required for identity authentication and terminal identification information, and requests identity authentication.

[0062] As a result, the matching server 64 verifies the certificate by using the public key, which is the counterpart of the private key used for signing, and by comparing the terminal identification information supplied with the certificate with the terminal identification information previously registered in the registration process via route R1 via the fixed terminal 63, it achieves identity authentication of the user who owns the mobile terminal 61.

[0063] As a result, even if the connection information and certificate are copied and transferred to another mobile terminal, the terminal identification information of the other mobile terminal will not match the terminal identification information of the mobile terminal 61 held over the NFC chip 62, which was registered in the registration process, and personal authentication will not be recognized, making it possible to prevent impersonation by someone who is not in the same space as the NFC chip 62.

[0064] In addition, the terminal identification information of the mobile terminal 61 held over the NFC chip 62 during the registration process may be a value obtained by hashing the terminal identification information using a cryptographic hash function that is preimage-resistant, and the verification process may be performed by comparing the result of hashing the terminal identification information supplied from the mobile terminal 61 using the hash function.

[0065] <<2. First Embodiment>> Next, a detailed configuration example of an authentication system according to the present disclosure will be described with reference to FIG.

[0066] The personal authentication system 111 of the present disclosure shown in FIG. 7 is composed of a user terminal 131, an NFC chip 132, a fixed terminal 133, and a verification server 134.

[0067] 7 correspond to the mobile terminal 61, NFC chip 62, fixed terminal 63, and verification server 64 in FIG. 6.

[0068] The user terminal 131 includes a terminal application 141 , an RF communication unit 142 , a network communication unit 143 , and a display unit 144 .

[0069] Terminal application (application program) 141 is installed by the user on user terminal 131 and performs identity authentication processing. Terminal application 141 may be an application installed by the user or may be an application pre-installed by the OS developer. In this case, the user can perform similar processing without any additional steps when purchasing the terminal. More specifically, terminal application 141 includes terminal identification information write unit 151, connection information read unit 152, and certificate exchange unit 153.

[0070] The terminal identification information writing unit 151 holds terminal identification information for identifying itself, such as an IMEI (International Mobile Equipment Identity), and controls the RF communication unit 142 to supply a terminal identification information write command to the fixed terminal 133 via the NFC chip 132, causing the fixed terminal 133 to write the terminal identification information.

[0071] The connection information reading unit 152 supplies a read command for connection information consisting of URI (Uniform Resource Identifier) ​​information and a session ID (Identifier) ​​generated by the matching server 134 and held by the fixed terminal 133 to the fixed terminal 133 via the NFC chip 132, and acquires the connection information read from the fixed terminal 133 based on the read command.

[0072] Certificate exchange unit 153 stores a certificate signed with a private key, which is information necessary for authenticating the identity of the user who owns user terminal 131, and controls network communication unit 143 based on the connection information acquired by connection information reading unit 152 to supply the information to verification server 134 via the network, and also acquires the result and displays it on display unit 144, which is made up of a touch panel or the like. At this time, certificate exchange unit 153 supplies terminal identification information together with the certificate to verification server 134.

[0073] The RF communication unit 142 is controlled by the terminal application 141 and communicates with the NFC chip 132 using RF (Radio Frequency) signals in the 13.56 MHz frequency band as carrier waves.

[0074] The network communication unit 143 is controlled by the terminal application 141, and establishes communication with the matching server 134 based on the connection information, sends the certificate and terminal identification information to the matching server 134, requests personal authentication, and obtains the personal authentication result, which is displayed on the display unit 144, which is composed of a touch panel or the like.

[0075] Display unit 144 is configured with a touch panel or the like, and receives operation input to terminal application 141 and displays various processing results.

[0076] The NFC chip 132 consists of, for example, an NFC reader or an NFC tag, and supplies connection information consisting of URI information and a session ID, which are fixed information read from the fixed terminal 133, to the user terminal 131 based on a connection information read command supplied through communication with the user terminal 131.

[0077] The NFC chip 132 communicates with the user terminal 131 and, based on a command to write the terminal identification information supplied, supplies the terminal identification information supplied from the user terminal 131 to the fixed terminal 133, causing it to be written.

[0078] More specifically, the NFC chip 132 includes an emulator processing unit 171 , an RF communication unit 172 , and a fixed terminal communication unit 173 .

[0079] The emulator processing unit 171 emulates card functions based on read and write commands from the user terminal 131. For NFC readers, the technical specifications provided by the industry group NFC Forum define a state in which an NFC device returns response data when it receives a command in Listen Mode, and it can be in not only Pull Mode, which is the state of a typical reader / writer, but also process external commands and generate response data as if emulating a card. For details about NFC, etc., please refer to NFC Forum / Digital Protocol Technical Specification Version 2.3.

[0080] The RF communication unit 172 is controlled by the emulator processing unit 171 and includes an antenna that realizes communication with the user terminal 131 .

[0081] The fixed terminal communication unit 173 is controlled by the emulator processing unit 171 and realizes communication with the fixed terminal 133 .

[0082] More specifically, when the emulator processing unit 171 controls the RF communication unit 172 to acquire a connection information read command from the user terminal 131, it controls the fixed terminal communication unit 173 to supply the connection information read command to the fixed terminal 133.

[0083] In addition, the emulator processing unit 171 controls the fixed terminal communication unit 173 to acquire connection information consisting of URI information and a session ID read out based on a read command at the fixed terminal 133, and then controls the RF communication unit 172 to supply the acquired connection information to the user terminal 131.

[0084] Furthermore, the emulator processing unit 171 controls the RF communication unit 172 to acquire terminal identification information and the write command from the user terminal 131, and then controls the fixed terminal communication unit 173 to supply the terminal identification information and the write command to the fixed terminal 133.

[0085] In addition, the emulator processing unit 171 controls the fixed terminal communication unit 173 to, when it receives a notification from the fixed terminal 133 indicating that the terminal identification information has been successfully written based on the terminal identification information and the write command, control the RF communication unit 172 to supply the received notification to the user terminal 131.

[0086] The fixed terminal 133 is a terminal installed at a fixed location such as a storefront terminal, a station, or a school, and includes a display unit 191 , a session management unit 192 , a network communication unit 193 , and an NFC chip communication unit 194 .

[0087] The display unit 191 is configured, for example, by a touch panel, and receives various operational inputs and displays various processing results.

[0088] The session management unit 192 controls a network communication unit 193 that communicates via a network such as the Internet, communicates with the matching server 134, and exchanges various types of data. The session management unit 192 controls an NFC chip communication unit 194 that executes communication via a USB connection or a BLE connection, communicates with the user terminal 131 via the NFC chip 132, and exchanges various types of data.

[0089] More specifically, the session management unit 192 controls the network communication unit 193 to supply a session request to the matching server 134 via the network, requesting the generation of a new session ID, and also obtains connection information consisting of the session ID generated based on this session request and corresponding URI information.

[0090] The session management unit 192 temporarily or permanently stores and holds connection information, which is obtained by controlling the network communication unit 193 and includes URI information and a session ID.

[0091] The session management unit 192 controls the NFC chip communication unit 194, and when it acquires a connection information read command supplied from the user terminal 131 via the NFC chip 132, it reads out the corresponding URI information and session ID together as connection information and supplies it to the user terminal 131.

[0092] The session management unit 192 controls the NFC chip communication unit 194 to acquire the terminal identification information and the write command supplied from the user terminal 131 via the NFC chip 132, writes the terminal identification information and connection information in association with each other, and supplies a notification to the user terminal 131 indicating that the write was successful.

[0093] The session management unit 192 controls the network communication unit 193 to supply the written terminal identification information together with the session ID information of the corresponding connection information to the verification server 134 for storage.

[0094] The verification server 134 is composed of a communication unit 211, a connection information generation unit 212, a certificate exchange unit 213, a verification unit 214, and a DB 215. The DB 215 is used for table management of information on the session IDs of the connection information corresponding to the terminal identification information, and there is no problem with table management on a non-volatile memory, so the configuration is not limited.

[0095] The communication unit 211 communicates with the user terminal 131 and the fixed terminal 133 via the network.

[0096] The connection information generation unit 212 controls the communication unit 211, and when a session request is supplied from the fixed terminal 133, supplies the fixed terminal 133 with a session ID consisting of a fixed value and URI information also consisting of a fixed value as connection information.

[0097] The connection information generating unit 212 controls the communication unit 211 to register the connection information and the terminal identification information in the DB 215 in association with each other when the corresponding terminal identification information is transmitted from the fixed terminal 133 .

[0098] The certificate exchange unit 213 controls the communication unit 211, and when a request for identity authentication is received from the user terminal 131 along with the certificate and terminal identification information, it verifies whether the certificate is genuine using the public key that is the counterpart of the private key used for the signature attached to the certificate.

[0099] When the matching unit 214 receives a request for personal authentication from the user terminal 131 along with the certificate and terminal identification information, it searches for the connection information (session ID) and terminal identification information registered in DB 215 based on the connection information (session ID) related to communication with the user terminal 131 and the supplied terminal identification information.

[0100] Then, the matching unit 214 searches for connection information (session ID) related to communication with the user terminal 131 and terminal identification information that matches the supplied information among the connection information (session ID) and terminal identification information registered in DB 215, and performs identity authentication of the user who is the owner of the user terminal 131 based on whether the certificate is legitimate or not.

[0101] The matching unit 214 controls the communication unit 211 to notify the user terminal 131 of the result of the personal authentication.

[0102] <Personal Authentication in the First Embodiment> Next, with reference to FIG. 8, personal authentication in the first embodiment will be described.

[0103] In the following explanation, it is assumed that communication between the user terminal 131 and the NFC chip 132 is realized via the RF communication unit 142 and the RF communication unit 172, and that communication via the RF communication unit 142 and the RF communication unit 172 is data communication using a contactless communication method (Type A, Type B, Type F) defined in ISO / IEC 7816, JIS X6319-4 "IC Card Implementation Specifications - Part 4: Proximity IC Cards for High-Speed ​​Processing" and ISO / IEC 14443 and ISO / IEC 18092, and hexadecimal string commands based on APDU commands or FeliCa (registered trademark) commands and response data; details will be omitted as above. The RF communication unit 142 of the user terminal is the side that transmits commands, and the RF communication unit 172 on the NFC chip side transmits responses on a return carrier wave.

[0104] Additionally, it is assumed that communication between the NFC chip 132 and the fixed terminal 133 is realized via the fixed terminal communication unit 173 and the NFC chip communication unit 194. Communication between the fixed terminal communication unit 173 and the NFC chip communication unit 194 can also be achieved via a wired connection such as USB or via proximity-based contactless communication such as BLE. In a simple configuration, the NFC chip 132 can be configured as a contactless IC card reader, and the fixed terminal can be a general-purpose PC or tablet such as a typical Windows PC, Android tablet or mobile phone, or iOS tablet (iPad®) or iOS mobile phone (iPhone®). In this case, the NFC chip communication unit 194 of the fixed terminal controls the fixed terminal communication unit 173 on the NFC chip side.

[0105] Furthermore, assuming that communication between the user terminal 131 and the fixed terminal 133 is realized via the NFC chip 132, the explanation of the processing via the NFC chip 132 will be omitted and the explanation will be given assuming that communication occurs between the terminal application 141 and the session management unit 192.

[0106] Similarly, it is assumed that communication between the user terminal 131 and the matching server 134 is realized via the network communication unit 143 and the communication unit 211, and the description of the processing via the network communication unit 143 and the communication unit 211 will be omitted, and the description will be replaced by assuming that communication occurs between the terminal application 141, the certificate exchange unit 213, and the matching unit 214.

[0107] Furthermore, it is assumed that communication between the fixed terminal 133 and the matching server 134 is realized via the network communication unit 193 and the communication unit 211, and the description of the processing via the network communication unit 193 and the communication unit 211 will be omitted, and the description will be given assuming that communication occurs between the session management unit 192 and the connection information generation unit 212.

[0108] First, in an eleventh process St11 of FIG. 8, the session management unit 192 of the fixed terminal 133 supplies a session request to the verification server 134, requesting connection information consisting of a session ID and URI information.

[0109] In response to this, in a twelfth process St12, the connection information generation unit 212 of the verification server 134 generates a session ID consisting of a fixed value in response to the session request and registers it in the DB 215. At this time, the terminal identification information corresponding to the session ID remains blank in the DB 215. Note that FIG. 8 shows that "AAAA" has been generated as an example of a session ID. Furthermore, although not shown, connection information including URI information may be registered in the DB 215 in association with the terminal identification information.

[0110] Then, in a thirteenth process St13, the connection information generating unit 212 transmits the session ID to the fixed terminal 133 as a reply to the session request. At this time, the connection information generating unit 212 also supplies the URI information to the fixed terminal 133.

[0111] In the fourteenth process St14, the session management unit 192 receives and stores the session ID and URI information supplied from the matching server 134 as connection information. Note that, although only the session ID is shown as the connection information in Fig. 8, URI information may also be included in the connection information, although this is not shown.

[0112] In a fifteenth process St15 , the connection information reading unit 152 in the terminal application 141 of the user terminal 131 supplies a connection information reading command to the fixed terminal 133 .

[0113] In the sixteenth process St16 , upon receiving the command to read the connection information, the session management unit 192 reads the connection information and supplies it to the user terminal 131 .

[0114] In the seventeenth process St17, the terminal identification information writing unit 151 supplies the terminal identification information held by itself and a command to write the terminal identification information to the fixed terminal 133. Note that in Fig. 8, an example is shown in which the terminal identification information is IMEI (350568431468505).

[0115] In the eighteenth process St18, when the session management unit 192 of the fixed terminal 133 acquires the terminal identification information together with the write command for the terminal identification information, it writes the terminal identification information in response to the write command, stores the information in association with the connection information, and notifies the user terminal 131 that the terminal identification information has been successfully written. In response, the terminal application 141 of the user terminal 131 receives the notification that the terminal identification information has been successfully written.

[0116] In a 19th process St19, the session management unit 192 of the fixed terminal 133 reads out the terminal identification information and notifies the matching server 134. The connection information generation unit 212 of the matching server 134 receives the notification of the terminal identification information of the user terminal 131 supplied from the fixed terminal 133, associates the terminal identification information in the DB 215 with blank connection information (session ID), and registers the received terminal identification information.

[0117] Through the processing up to this point, connection information consisting of a session ID and URI information is generated in the matching server 134, and is supplied to the terminal application 141 of the user terminal 131 via the fixed terminal 133. Furthermore, when the connection information is read from the fixed terminal 133 and the connection information is supplied from the matching server 134 via the fixed terminal 133, the user terminal 131 writes the terminal identification information to the fixed terminal 133. As a result, the fixed terminal 133 notifies the matching server 134 of the written terminal identification information, and the matching server 134 stores the terminal identification information in DB 215 in association with the connection information (session ID).

[0118] In a twentieth process St20, the certificate exchange unit 153 in the terminal application 141 of the user terminal 131 uses the connection information to upload the certificate together with the terminal identification information to the verification server 134, and requests personal authentication. Note that in Fig. 8, the terminal identification information and connection information enclosed by dotted lines are represented as the terminal identification information and connection information uploaded from the user terminal 131.

[0119] In the 21st process St21, the certificate exchange unit 213 of the verification server 134 acquires the certificate and terminal identification information supplied from the user terminal 131, and verifies whether the certificate is authentic by using the public key that is the counterpart of the private key used for the signature attached to the certificate. The verification unit 214 compares the connection information (session ID) related to the communication for which the certificate was notified and the notified terminal identification information together with the information registered in the DB 215, and performs identity authentication of the user of the user terminal 131 based on whether there is a match and whether the certificate is authentic, and notifies the user terminal 131 of the authentication result.

[0120] Through the above series of processes, the matching server 134 stores the terminal identification information of the user terminal 131 in DB 215 in association with the session ID, which is the connection information that it issued in advance via the fixed terminal 133. At this time, the user terminal 131 has acquired the connection information, including the session ID and URI information issued by the matching server 134, via the fixed terminal 133.

[0121] As a result, the user terminal 131 uses the connection information to establish communication with the matching server 134, and supplies the certificate along with its own terminal identification information to the matching server 134, requesting authentication of the user's identity.This allows the matching server 134 to compare the connection information and terminal identification information obtained via the fixed terminal 133 with the connection information and terminal identification information supplied directly from the user terminal 131.

[0122] In other words, the verification server 134 can perform identity authentication based on whether the terminal identification information written by the user terminal 131 to the fixed terminal 133 via the NFC chip 132 matches the terminal identification information supplied together with the certificate sent directly from the user terminal 131 and whether the certificate is genuine.

[0123] As a result, if a certificate is provided using other connection information, the session ID will be different, and the terminal identification information and connection information provided by the user terminal 131 will not match the terminal identification information and connection information registered in DB215, making it possible to prevent impersonation of a user using other connection information.

[0124] <Personal Authentication Processing (Part 1)> Next, the personal authentication processing (part 1) will be described with reference to the flowchart of FIG.

[0125] In step S11, the session management unit 192 of the fixed terminal 133 notifies the verification server 134 of a session request, requesting the generation of a session ID.

[0126] In step S 21 , the connection information generating unit 212 of the matching server 134 receives a session request from the fixed terminal 133 .

[0127] In step S22, the connection information generating unit 212 generates a session ID consisting of a fixed value and URI information consisting of a fixed value.

[0128] In step S23, the connection information generating unit 212 transmits connection information consisting of the session ID and URI information to the fixed terminal 133 as a reply to the session request.

[0129] In step S12, the session management unit 192 of the fixed terminal 133 receives and stores the connection information consisting of the session ID and URI information.

[0130] The process then temporarily enters a standby state, after which the user terminal 131 starts communication with the fixed terminal 133 via the NFC chip 132, and the process proceeds to step S31.

[0131] In step S31, the connection information reading unit 152 in the terminal application 141 of the user terminal 131 transmits a connection information reading command to the fixed terminal 133 via the NFC chip 132, requesting that the connection information be read.

[0132] In step S 13 , the session management unit 192 of the fixed terminal 133 receives a command to read connection information from the user terminal 131 .

[0133] In step S14, the session management unit 192 reads out the connection information based on the connection information read command and transmits it to the user terminal 131.

[0134] In step S32, the connection information reading unit 152 of the user terminal 131 acquires and stores the connection information supplied from the fixed terminal 133.

[0135] In step S33, terminal identification information writing section 151 of terminal application 141 transmits a terminal identification information write command to fixed terminal 133 together with the terminal identification information.

[0136] In step S15, when the session management unit 192 of the fixed terminal 133 receives the terminal identification information and the terminal identification information write command, it writes the terminal identification information to itself in association with the connection information based on the terminal identification information write command.

[0137] In step S16, the session management unit 192 notifies the user terminal 131 that the terminal identification information has been successfully written.

[0138] In step S17, the session management unit 192 notifies the verification server 134 of the terminal identification information.

[0139] In step S24, upon acquiring the terminal identification information, the connection information generating unit 212 stores the acquired terminal identification information in the DB 215 in association with connection information consisting of a session ID and URI information.

[0140] In step S34, the terminal identification information writing unit 151 receives a notification that the terminal identification information has been successfully written. That is, through the processing up to this point, the user terminal 131 and the verification server 134 have mutually completed the registration processing of the connection information and the terminal identification information.

[0141] That is, in step S35, certificate exchanging unit 153 establishes communication with verification server 134 using the connection information, and notifies verification server 134 of the certificate together with the terminal identification information.

[0142] In step S25, the certificate exchange unit 213 acquires the certificate and terminal identification information from the user terminal 131.

[0143] In step S26, the certificate exchange unit 213 verifies whether the certificate is authentic by using the public key. The comparison unit 214 compares the connection information and terminal identification information stored in the DB 215 with the connection information from the user terminal 131 and the terminal identification information acquired from the user terminal 131, and performs personal authentication based on whether matching information exists and whether the certificate is authentic.

[0144] In step S27, the matching unit 214 supplies the user terminal 131 with a result of personal authentication based on whether or not the information held in the DB 215 contains information that matches the connection information from the user terminal 131 and the terminal identification information acquired from the user terminal 131, and whether or not the certificate is legitimate. That is, the matching unit 214 compares the connection information from the user terminal 131 and the terminal identification information acquired from the user terminal 131 with the information registered in the DB 215, and if matching information exists and the certificate is legitimate, it notifies the user terminal 131 that personal authentication has been approved; otherwise, it notifies the user terminal 131 that personal authentication has not been approved.

[0145] In step S36, terminal application 141 acquires the result of the personal authentication and displays it on display unit 144.

[0146] In step S34, if there is no notification of successful writing of the terminal identification information for a predetermined time or longer, the processes of steps S35 and S36 may be skipped so that personal authentication cannot be requested.

[0147] That is, in this case, since the terminal identification information is not written in the fixed terminal 133, the terminal identification information is not notified to the verification server 134 either, and therefore personal authentication cannot be realized.

[0148] As a result, steps S35 and S36 and steps S25 to S27 may be skipped, and the process may be terminated without personal authentication being possible. In this case, steps S15 to S17 cannot be actually performed, so steps S15 to S17 may also be skipped, and the process may be terminated.

[0149] Through the above processing, before the user terminal 131 requests personal authentication, the matching server 134 stores the terminal identification information of the user terminal 131 in DB 215 via the fixed terminal 133 in association with the session ID, which is the connection information issued by the matching server 134 itself.

[0150] Meanwhile, at this time, the user terminal 131 acquires connection information including the session ID and URI information issued by the verification server 134 via the fixed terminal 133 .

[0151] This enables the user terminal 131 to establish communication with the matching server 134 using the connection information, and to supply the certificate along with its own terminal identification information corresponding to the certificate to the matching server 134, thereby requesting authentication of the user's identity.

[0152] In response to this request for personal authentication, the matching server 134 can match the connection information and terminal identification information obtained via the fixed terminal 133 and registered in DB 215 with the connection information and terminal identification information of the communication established on the user terminal 131.

[0153] In other words, the matching server 134 can verify the certificate supplied from the user terminal 131 that wrote the terminal identification information to the fixed terminal 133 via the NFC chip 132, thereby realizing identity authentication of the user who holds the user terminal 131 over the NFC chip 132.

[0154] As a result, if unauthorized communication is established using other connection information, a session ID different from the session ID of the communication established when the certificate is supplied will be assigned, and the connection information (session ID) and terminal identification information related to the established communication will not match the information in DB215, making it possible to prevent impersonation by a user using other connection information.

[0155] In the above process, when a notification is received in step S34 that the terminal identification information has been successfully written to fixed terminal 133, the process proceeds to step S35, and the certificate exchange unit 153 of terminal application 141 establishes communication with matching server 134 based on the connection information, and sends the certificate and the terminal identification information together to request personal authentication.

[0156] Here, as the processing continues, it is considered that the user terminal 131 can control the timing of performing the processing of step S35 depending on the purpose (attendance, etc.) For example, in a class scene, when the processing of step S34 is completed, the user terminal 131 has completed receiving the data that it should acquire from the fixed terminal 133, so there is no problem if the user moves away from the fixed terminal 133 and takes a seat.

[0157] If the class duration is 90 minutes, performing the processing of step S35 during that class time is sufficient for the verification server 134 to determine that the student attended the class. In this case, the time at which the user terminal 131 wrote the terminal identification information in the processing of step S15 is also important. For a class that starts at 10:00, if the processing of step S15 is performed at 9:50 and the processing of step S35 is performed at 11:28, it can be confirmed that the student entered the classroom before the class and that the certificate was stored in the verification server 134 during the class time. In this case, it can also be recognized that the student was in the classroom because the terminal identification information was reliably tapped on the fixed terminal 133.

[0158] However, because there is a possibility that a student may simply tap the NFC function of the fixed terminal 133 and then leave the classroom, teachers should be careful about students leaving the classroom midway. In this case, the teacher may instruct the timing of performing the process of step S35 during class. By doing so, if a student leaves the classroom midway, they may not know the timing and upload the certificate at the wrong time, so it is necessary for the student to stay in the classroom. Instead of such artificial timing, the terminal app 141 may automatically upload the certificate to the verification server 134 in response to specific conditions (e.g., the amount of time elapsed since the start of class, an external inquiry via a beacon, etc.), a user's own recollection or trigger due to external sound quality (high frequency / low frequency), musical scale (melody), or human voice (keyword or song), or program activation or startup. Even when the process is automatically initiated, a user action requesting user consent may be required. Since a user who falls asleep during class may miss the upload timing, fully automatic processing is not necessary. In this regard, even if the system can be operated in a way that allows it to switch behavior based on the prior settings and conditions of teachers, professors, and lecturers, there are no limitations, and it can be considered a setting that can appropriately reflect the way teachers want students to take lessons, thereby improving convenience.

[0159] Furthermore, in the processing of steps S34 and S35, when a notification is obtained in the processing of step S34 that the terminal identification information has been successfully written to fixed terminal 133, terminal application 141 may use display unit 144 to present information to the user asking whether or not the user agrees to establish communication with matching server 134 based on the connection information, send a certificate together with the terminal identification information, and request personal authentication; and proceed to processing of step S35 only when consent is obtained using a password or biometric authentication that only the legitimate user knows.

[0160] This process ensures that the certificate and terminal identification information sent from the user terminal 131 to the verification server 134 are those consented to by the legitimate user. Therefore, even if a third party somehow exploits the user terminal and attempts to use the certificate or terminal identification information, as long as a password or biometric authentication has been set, consent to such use will not be granted and the use itself will be impossible, making it possible to more reliably prevent impersonation.

[0161] Furthermore, in the above, an example has been described in which the session management unit 192 executes the process of only notifying the matching server 134 of the terminal identification information in step S17. However, at this time, it is also possible to send a session request for the next process corresponding to the process in step S11, and repeat the subsequent processes.

[0162] <Regarding identity authentication in a modified example of the first embodiment> In the above, we have explained an example in which the session ID of the connection information generated by the matching server 134 is a fixed value, but the session ID may also be set to a dynamically changing value, for example, by incrementing a random number or a predetermined value each time.

[0163] FIG. 10 is a diagram illustrating personal authentication in a modified example of the first embodiment.

[0164] Note that the 31st process St31 to the 41st process St41 in Figure 10 correspond to the 11th process St11 to the 21st process St21 in Figure 8, and are basically the same processes except for the 32nd process St32.

[0165] That is, in the 32nd process St32, the connection information generation unit 212 of the verification server 134 generates a session ID consisting of a value that changes dynamically each time, for example by incrementing a random number or a predetermined value each time, and registers the session ID in the DB 215. At this time, the corresponding terminal identification information is left blank. Note that in FIG. 10, "AABB" is shown as an example of the session ID that has been generated.

[0166] Then, in the 33rd process St33, the connection information generation unit 212 transmits a session ID consisting of a value that dynamically changes each time to the fixed terminal 133 as a reply to the session request. At this time, the connection information generation unit 212 also supplies URI information to the fixed terminal 133.

[0167] In the thirty-fourth process St34, the session management unit 192 receives and stores the session ID, which is a value that changes dynamically each time and the URI information, which is a fixed value, supplied from the verification server 134 as connection information.

[0168] In a thirty-fifth process St35 , the connection information reading unit 152 in the terminal application 141 of the user terminal 131 supplies a connection information reading command to the fixed terminal 133 .

[0169] In the 36th process St36, when the session management unit 192 receives a command to read connection information, it reads out connection information consisting of a session ID consisting of a value that changes dynamically each time and URI information consisting of a fixed value, and supplies it to the user terminal 131.

[0170] Furthermore, in the 40th process St40, the certificate exchange unit 153 in the terminal application 141 of the user terminal 131 establishes communication with the matching server 134 using connection information consisting of a session ID consisting of a value that changes dynamically each time and URI information consisting of a fixed value, and uploads the certificate and terminal identification information together to the matching server 134 to request personal authentication.

[0171] That is, in the process of FIG. 10, the session ID is dynamically changed and generated each time, and the certificate is supplied through communication established based on connection information consisting of the session ID, which is a value that changes dynamically each time, and URI information, which is a fixed value, thereby making it possible to improve the security level for certificate verification.

[0172] <Personal Authentication Processing (Variation 1)> Next, the personal authentication processing (Variation 1) will be described with reference to the flowchart in Fig. 11. Note that the processes in steps S51 to S57, steps S61, S63 to S67, and steps S71 to S76 in Fig. 11 are similar to the processes in steps S11 to S17, steps S21, S23 to S27, and steps S31 to S36 in Fig. 9, and therefore description thereof will be omitted.

[0173] That is, the flowchart of FIG. 11 differs from the flowchart of FIG. 9 in the process of step S62.

[0174] In step S62, the connection information generating unit 212 generates a session ID consisting of a dynamically changing value, for example, by incrementing a random number or a predetermined value each time, and also generates URI information.

[0175] In the above process, the session ID is dynamically changed and generated each time, and the certificate and terminal identification information are supplied to the verification server 134 through communication established based on the session ID, which is a dynamically changing value, and connection information, which is made up of URI information. This makes it possible to improve the security level related to certificate verification.

[0176] Although the above description has been given of an example in which the session ID changes dynamically, the URI information may change dynamically, or the terminal identification information may change dynamically each time. However, since the terminal identification information is basically a fixed value, for example, a value obtained by adding either the session ID or the URI information, which change dynamically each time, to the fixed terminal identification information may be used as pseudo-terminal identification information that changes dynamically each time.

[0177] That is, by dynamically changing at least one of the session ID, URI information, and terminal identification information each time, it is possible to improve the security level, and the more parameters that are dynamically changed each time, the higher the security level becomes. That is, for example, by dynamically changing all of the session ID, URI information, and terminal identification information each time, the security level becomes the highest. However, the more dynamically changing parameters there are, the more complicated the processing becomes.

[0178] <Processing for Multiple User Terminals> The above has described the processing when there is one user terminal 131. However, when there are multiple user terminals 131, the processing can be divided into a registration processing (processing of steps S11 to S17, steps S21 to S24, and steps S31 to S34 in FIG. 9) in which connection information and terminal identification information are held by both the user terminal 131 and the matching server 134, and a verification processing (processing of steps S25 to S27, and steps S35 and S36 in FIG. 9) in which communication is established based on the connection information and identity authentication is performed by presenting a certificate and terminal identification information. The registration processing and verification processing for each user terminal 131 do not have to be performed consecutively, and the verification processing for multiple user terminals 131 may be performed in an order different from the order in which the registration processing was performed.

[0179] Here, using an example in which the personal authentication system 111 of Figure 7 is applied to an attendance management system that manages students' attendance at classes, as shown in Figure 12, we will explain examples of the timing and order of the registration process and verification process when multiple students use the attendance management system on their own user terminals 131.

[0180] In the attendance management system of Figure 12, first, a student carrying a user terminal 131 holds the user terminal 131 over an NFC chip 132 with an antenna provided in each classroom where the student will be attending class, and connection information is acquired by the user terminal 131. At the same time, the terminal identification information of the user terminal 131 held over the NFC chip 132 is associated with the connection information and registered in DB215 of the matching server 134 via the fixed terminal 133, and the registration process is carried out.

[0181] In addition, in Figure 12, an example is shown in which the NFC chip 132 is installed at the entrance to a classroom, etc., but if the mobile terminal carried by the instructor or teacher is equipped with the function of the NFC chip 132 with an antenna, a registration process may be performed in which the user terminal 131 is held over the mobile terminal equipped with the function of the NFC chip 132, and the connection information is registered in the user terminal 131 via the mobile terminal functioning as the NFC chip 132, and the terminal identification information of the user terminal 131 held over the mobile terminal functioning as the NFC chip 132 is associated with the connection information and registered in DB215 of the matching server 134.

[0182] Next, the student operates user terminal 131 to establish communication with matching server 134 based on the acquired connection information, and presents a certificate consisting of information such as the student ID number on the student ID card and terminal identification information to matching server 134. The presented terminal identification information is then compared with the information registered in DB 215, and if there is matching information, a verification process is executed to verify whether the certificate consisting of information such as the student ID number on the student ID card is genuine.If the verification process recognizes the student's identity, the time of entry into or exit from the classroom where the class is being held is recorded.

[0183] In this disclosure, a certificate containing information such as a student ID number from a student ID card contains the following information: student ID number, given name (including kanji, hiragana, katakana, and romanized characters), date of birth, gender, issuing university name, affiliated faculty, department, and major, university / technical college code expressed in JIS X 0408, issue date, expiration date, academic year, facial photograph, current address, parental address, donor organ information, and donor signature. Authenticity of some of this information may be verified using information stored on the face or IC chip of the My Number Card. The university's signature is added to all or part of this information, ensuring its authenticity and enabling it to be used for authenticity verification. While this information is displayed in the appropriate character code when displayed on the card, it can be stored in a Unicode-defined character code such as UTF-8 to ensure proper display on overseas devices and verification devices.

[0184] These digital certificates can be realized using the Verifiable Credentials standardized by the World Wide Web Consortium (W3C), an international standardization organization, or the mobile document (mdoc) standardized by ISO / IEC 18013-5, also standardized by the International Organization for Standardization (ISO), an international standardization organization. In particular, for student ID cards, formats used for diplomas and transcripts for study abroad programs such as the European Region Action Scheme for the Mobility of University Students Plus (Erasmus+), a grant program for education, training, youth, and sports implemented by the European Union, may be used, and this does not affect the technology applied to the student ID card submitted in the present invention.

[0185] That is, when a student enters a classroom before the start of class, the student holds the user terminal 131 over the NFC chip 132 to perform registration processing, and then operates the user terminal 131 to perform verification processing, thereby recording the time of entry. Furthermore, when the student leaves the classroom, a similar registration processing may be performed, and the time of leaving the classroom may be recorded.

[0186] This allows the time of entry into (and exit from) the classroom to be determined when the student's identity is authenticated, making it possible to manage the attendance of students who possess user terminals 131 in class.

[0187] The above describes the operation when focusing on one user terminal 131, but since multiple students may each have their own user terminal 131 and may need to perform similar processes consecutively depending on the situation, it may be necessary to devise a timing for when the registration process and verification process are executed.

[0188] For example, an example of processing when four students each carry user terminals 131A to 131D and perform operations to record their entry time will be explained with reference to the flowchart in Figure 13, in association with each process in the flowchart in Figure 9.

[0189] In step S101 by the fixed terminal 133 in FIG. 13, the process of step S11 by the fixed terminal 133 in FIG. 9 is performed, and the fixed terminal 133 supplies a session request to the verification server 134.

[0190] 9 is performed by the matching server 134, a session ID is generated in the matching server 134, and is supplied as connection information together with the URI information to the fixed terminal 133. After this processing, the processing of step S12 in FIG. 9 is performed, and the connection information is stored in the fixed terminal 133, which then goes into a standby state.

[0191] After this state, when the user holds the user terminal 131A over the NFC chip 132, in step S131, a command to read connection information is supplied from the user terminal 131A by the processing of step S31 in FIG.

[0192] In step S102 by the fixed terminal 133, by the processing of steps S13 and S14 in FIG. 9, the fixed terminal 133 reads out the connection information in response to the connection information read command, and supplies it to the user terminal 131A for storage.

[0193] In step S132 by the user terminal 131A, a write command for the terminal identification information of the user terminal 131A is supplied to the fixed terminal 133 by the process of step S33 in FIG.

[0194] In step S103 by the fixed terminal 133, when the fixed terminal 133 acquires the write command for the terminal identification information through the processing of steps S15 and S16 in Fig. 9, the fixed terminal 133 writes the terminal identification information and notifies the user terminal 131A of the success of the write. In response, the user terminal 131A receives a notification of the success of the write through the processing of step S34 in Fig. 9.

[0195] In step S104 by fixed terminal 133, fixed terminal 133 notifies matching server 134 of the terminal identification information of user terminal 131A by the processing of step S17 in Fig. 9, and also supplies the next session request by the processing of step S11 in Fig. 9. In response to this, matching server 134 associates the terminal identification information with the connection information and registers them in DB 215 by the processing of step S24 in Fig. 9.

[0196] That is, through the processing of steps S101 to S104 at fixed terminal 133, the processing of steps S131 and S132 at user terminal 131A, and the processing of step S121 at matching server 134, connection information consisting of a session ID and URI information, and terminal identification information of user terminal 131A are registered in both user terminal 131A and matching server 134, and the registration process is completed.

[0197] Therefore, at any time thereafter, when the user terminal 131A uses the connection information to establish communication with the verification server 134 and provides the certificate and terminal identification information, the verification process becomes ready to start.

[0198] In FIG. 13, the same process is carried out for the user terminals 131B to 131D in that order.

[0199] More specifically, for the user terminal 131B, the registration process is executed by the fixed terminal 133 performing the processes of steps S104 to S107, the user terminal 131B performing the processes of steps S133 and S134, and the verification server 134 performing the process of step S122.

[0200] Similarly, for user terminal 131C, the registration process is executed by the fixed terminal 133 performing steps S107 to S110, the user terminal 131C performing steps S135 and S136, and the verification server 134 performing step S124.

[0201] Furthermore, for the user terminal 131D, the registration process is executed by the fixed terminal 133 performing the processes of steps S110 to S113, the user terminal 131D performing the processes of steps S137 and S138, and the verification server 134 performing the process of step S125.

[0202] Here, in Figure 13, after the processing of step S106 by the fixed terminal 133, in step S141, the user terminal 131A establishes communication with the matching server 134 using the connection information by processing step S35 in Figure 9, notifies the certificate and terminal identification information, and requests personal authentication.

[0203] In response to this, in step S123, the matching server 134 performs the processing of steps S25 to S27 in Figure 9, whereby the matching server 134 verifies the certificate and compares the connection information and terminal identification information with DB215, and if there is a match and the certificate is legitimate, performs identity authentication and notifies the user terminal 131A of the authentication result.

[0204] That is, the registration process for the user terminals 131A and 131B has been completed by the process up to step S106, and therefore the verification process for the user terminal 131A is being executed.

[0205] Also, in Figure 13, after the processing of step S125 by the matching server 134, in step S142 by the user terminal 131B, the user terminal 131B establishes communication with the matching server 134 using the connection information by the processing of step S35 in Figure 9, notifies the matching server 134 of the certificate and terminal identification information, and requests identity authentication.

[0206] In response to this, in step S126, the matching server 134 performs the processing of steps S25 to S27 in Figure 9, whereby the matching server 134 verifies the certificate and compares the connection information and terminal identification information with DB215, and if there is a match and the certificate is legitimate, performs identity authentication and notifies the user terminal 131B of the authentication result.

[0207] In other words, the processing up to step S126 by the matching server 134 has completed the registration processing for user terminals 131A to 131C, and furthermore, the verification processing has been completed for user terminals 131A and 131B, and furthermore, the verification processing is now possible for user terminal 131C.

[0208] In the example of FIG. 13, after the verification server 134 performs the process of step S126, the registration process of the user terminal 131D is executed.

[0209] Furthermore, in Figure 13, after the processing of step S127 by the matching server 134, in step S143 by the user terminal 131D, the user terminal 131D establishes communication with the matching server 134 using the connection information by processing step S35 in Figure 9, and notifies the matching server 134 of both the certificate and the terminal identification information, requesting identity authentication.

[0210] In response to this, in step S128, by processing steps S25 to S27 in Figure 9, the matching server 134 verifies the certificate and compares the connection information and terminal identification information with DB215, and if there is a match and the certificate is legitimate, performs personal authentication and notifies the user terminal 131D of the authentication result.

[0211] In other words, by processing up to step S127, the registration process for user terminals 131A to 131D has been completed, and furthermore, verification process has been completed for user terminals 131A and 131B, and verification process is now possible for either user terminal 131C or 131D.

[0212] Therefore, in the example of Figure 13, after the processing of step S127, verification processing of user terminal 131D is performed in step S143 by user terminal 131D and in step S128 by matching server 134, which are later in the registration processing order.

[0213] Furthermore, in Figure 13, after the timing of processing step S128 by the matching server 134, verification processing for user terminal 131C, which has an order of registration processing before user terminal 131D, is executed in step S144 by user terminal 131C and in step S129 by the matching server 134.

[0214] That is, as shown in FIG. 13, after the registration process has been completed for each of the user terminals 131A to 131D, the verification process can be executed in any order.

[0215] As a result, the registration process is carried out in the order in which the user terminal 131 is held over the NFC chip 132, which has restrictions on its location and number, but the verification process after the registration process can be carried out by individual communication between the user terminal 131 and the matching server 134, so the order does not matter, and the verification process can be carried out at any time without having to wait in line.

[0216] In this registration process, the user terminals are listed in the order of 131A to 131D, but this is merely an example presented to demonstrate that changing the order of the verification process is not a problem. Even if the order of registration of the user terminals 131A to 131D is changed, as long as a user terminal has already completed the registration process, there is no problem with that terminal performing the verification process later. For example, there is no restriction on the order, even if the order is as follows: registration process for user terminal 131D, verification process for 131D, registration process for 131C, verification process for 131C, registration process for user terminal 131B, verification process for 131B, registration process for 131A, verification process for 131A. Furthermore, the user terminals 131A to 131D are not assigned any numerical ranking; one could say that the terminals that performed the registration process at a certain point in time were conveniently numbered A to D.

[0217] <Display Example of UI Image of Attendance Management System> Next, a display example of a UI image in the above-described attendance management system will be described.

[0218] The UI image is managed by terminal application 141 and displayed on display unit 144. For example, when terminal application 141 is launched, UI image P1 as shown in the left part of Fig. 14 is displayed.

[0219] In UI image P1, "Class Attendance Management" is written at the top, expressing that the terminal application 141 is intended for class attendance management.

[0220] Below "Class Attendance Management," there are two buttons on the left labeled "First semester of 2023" and "Second semester," which are used to switch the timetable displayed in the lower section between "First semester of 2023" and "Second semester of 2023."

[0221] The bottom row displays the timetable of classes that the user has registered. More specifically, from the left in the figure, boxes are arranged horizontally for Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, and Sunday, and vertically for the first through fifth periods. When you want to manage attendance for a desired class, you can click (or tap) on the appropriate box to display the corresponding class attendance management screen.

[0222] In Figure 14, when the box C1 labeled "German II-3" for the fourth period on Friday is clicked, a UI image P2 consisting of the class attendance management screen for "German II-3" is displayed, as shown in the center of Figure 14.

[0223] The UI screen P2 has "German II-3" written at the top, indicating that the UI screen P2 is a class attendance management screen for the "German II-3" class.

[0224] Below that, the class attendance management information is displayed in the order of the numbers assigned from top to bottom on the left. In UI image P2, the first entry from the top reads "2023 / 4 / 12 10:28 In-person," and the following entries from the second entry down the image read, in order, "2023 / 4 / 19 10:25 Remote," "2023 / 4 / 26 10:24 In-person," "2023 / 5 / 10 10:29 Online," "Not punched in," "2023 / 5 / 24 10:26 Online," "Course not yet started," and so on.

[0225] For example, the first record indicates that the student entered the classroom at 10:28 AM on April 12, 2023, and attended an in-person class. The second record indicates that the student entered the classroom at 10:25 AM on April 19, 2023, and attended an online class. The third record indicates that the student entered the classroom at 10:24 AM on April 26, 2023, and attended an in-person class. The fourth record indicates that the student entered the classroom at 10:29 AM on May 10, 2023, and attended an online class. The fifth record indicates that the student did not clock in and attendance was not recorded, meaning that the student was absent. The sixth record indicates that the student entered the classroom at 10:26 AM on May 26, 2023, and attended an online class.

[0226] Furthermore, from the seventh item onwards, it is indicated that the class has not yet started and that attendance management information will be registered in the future. For the seventh item, the column indicating whether the class is face-to-face or remote is labeled "Login," indicating that this is the column where attendance management information for the next lecture will be entered.

[0227] When the box labeled "Login" is clicked, a pop-up image P11 such as that shown on the right side of FIG. 14 is displayed.

[0228] In the pop image P11 on the right side of Figure 14, the top line reads "Please hold over the reader / writer in the classroom," indicating that to log in, the user can hold the user terminal 131 over the reader / writer consisting of an NFC chip 132 installed in front of the classroom.

[0229] In addition, at the bottom of the pop image P11, a button B3 is displayed, which is operated when participating in a remote class, with the words "remote attendance" written underneath the word "or."

[0230] For example, as shown in the left part of Figure 15, when pop image P11 is displayed, user STU1, who is a student carrying user terminal 131, approaches a reader / writer consisting of NFC chip 132, as shown by user STU2, second from the left in Figure 14, and then holds user terminal 131 over NFC chip 132, as shown by user STU3, second from the right in Figure 14, and the above-mentioned registration process is executed.

[0231] This registration process completes the reading of connection information from fixed terminal 133 and the writing of terminal identification information to fixed terminal 133, and when the connection information and terminal identification information are registered in both user terminal 131 and matching server 134, terminal application 141 emits a notification sound such as a "ping-pong" from a speaker (not shown) and changes and displays pop image P11 to pop image P12, as shown second from the right in Fig. 15. Depending on the user's settings, terminal application 141 may not emit a sound but may instead vibrate in silent mode, or may light up and flash the terminal's LED lamp.

[0232] In this example, it appears that the "pillow" sound is generated by terminal application 141, but there is no problem if the sound is generated by fixed terminal 133. If the intention is to provide a consistent user experience regardless of the user's settings, it may be easier to understand if the sound, light, and screen display are generated by fixed terminal 133.

[0233] In pop image P12, the top column G1 reads "Entered classroom 112," and the bottom column G2 reads "10:24 on May 31, 2024," indicating that classroom 112 was entered at 10:24 on May 31, 2024.

[0234] Furthermore, after displaying the pop screen P12 for a predetermined period of time, the terminal application 141 switches to displaying a pop image P13 as shown on the right side of FIG.

[0235] In the pop image P13, the top column G11 displays "Entering classroom 112," the middle column G12 displays "09:24 remaining," and the bottom column G13 displays "Upload student ID."

[0236] In other words, it indicates that the student is currently in classroom 112 and the remaining time of the lecture, i.e., the remaining time for uploading the student ID card, is 9 minutes and 24 seconds. The lower column G13 functions as a button that is clicked when uploading the student ID card as terminal identification information to the verification server 134.

[0237] When the lower column G13 in Figure 15 is clicked, the terminal application 141 uses the connection information to establish communication with the matching server 134, and notifies the matching server 134 of the certificate, which is the student ID information (such as student ID number), along with the terminal identification information, requesting identity authentication and executing the verification process.

[0238] If this verification process allows for authentication of the user and confirms attendance at class, terminal application 141 switches the display of pop image P13 to pop image P14 as shown on the left side of FIG.

[0239] In pop image P14, the upper column G21 displays "Attending class" and the lower column G22 displays "Student ID number 023-12345," indicating that the attendance of the user, who is a student and possesses user terminal 131, in class has been confirmed and that the user is currently attending, and that the student ID number on the student ID card corresponding to the information on the presented certificate is "023-12345."

[0240] That is, by displaying the pop image P14, it is expressed that it has been confirmed that the user who is the student and owns the user terminal 131 has attended the class.

[0241] Then, after the class is over, when the student user holds the user terminal 131 over the NFC chip 132, the terminal application 141 switches the display from the pop image P14 to the pop image P15.

[0242] The lower column G13 may not only function as a button to be clicked when uploading the student ID card as the terminal identification information to the verification server 134, but may also function only when information known only to the user who owns the user terminal 131 is entered using a password or biometric authentication. In this way, even if the connection information and terminal identification information are copied by a third party and used on the third party's user terminal 131, the third party cannot operate the button in the lower column G13 or execute the verification process unless they can enter a password or biometric authentication, thereby preventing impersonation.

[0243] In pop image P15, the upper column G31 reads "Attended class," and the lower column G32 reads "May 31, 2024, 11:58," indicating that the student attended class and left the classroom at 11:58 on May 31, 2024.

[0244] The NFC chip 132 is not limited to the type shown in FIG. 12, but may be, for example, an NFC chip 132X that functions as a stationary reader as shown in the middle center of FIG. 16, or a mobile terminal 132Z that is possessed by the teacher and has the function of an NFC chip 132 as shown in the lower center of FIG. 16.

[0245] The middle center of Figure 16 shows a state in which a user terminal 131X is touching (being held over) an NFC chip 132X that functions as a stationary reader, and the bottom center of Figure 16 shows a state in which a user terminal 131Y is touching (being held over) a mobile terminal 132Z held by a teacher.

[0246] Furthermore, the terminal application 141 switches the display from UI image P2 to UI image P21 on the right side of Figure 16, updates the seventh attendance management information to information P22, and sets it to "2024 / 5 / 31 10:24 In-person," recording that the student attended the face-to-face class at 10:24 on May 31, 2024.

[0247] On the other hand, as shown in the left part of Figure 17, when button B3, which is operated when participating in a remote class and is labeled "Remote Attendance" at the bottom of pop image P11, is clicked, terminal app 141 switches the display from pop image P11 to that shown in pop image P31.

[0248] In the pop image P31, the upper column G41 displays "Attending class remotely" and the lower column G42 displays "Upload student ID card."

[0249] In other words, it indicates that the student is currently attending a class remotely. The lower field G42 functions as a button that is clicked when uploading the student ID card, which serves as terminal identification information, to the verification server 134.

[0250] When the lower column G42 of the pop image P31 in Figure 17 is clicked, the terminal application 141 issues a certificate using the connection information, notifies the verification server 134 of the certificate along with the information on the student ID card (student ID number, etc.), which is the terminal identification information, requests personal authentication, and executes the verification process.

[0251] However, in this case, since the student is attending the class remotely, the registration process has not been completed and therefore the verification process is not performed.

[0252] Terminal application 141 switches the display from pop image P31 to pop image P32.

[0253] In the pop image P32, the top column G51 displays "Attending class remotely," the middle column G52 displays "Student ID number 023-12345," and the bottom column G53 displays "Left room." In other words, it is displayed that the remote attendance of the user, who is a student and possesses the user terminal 131, in the class has been confirmed and that the user is currently attending, and that the student ID number on the student ID card corresponding to the presented terminal identification information is "023-12345."

[0254] Furthermore, the bottom column G53 labeled "Exit" functions as a button that is operated when exiting a class that has been attended remotely.

[0255] That is, the display of the pop image P32 indicates that it has been confirmed that the user, who is a student and owns the user terminal 131, has attended the class remotely. However, in this case, there is no operation such as holding the device over the NFC chip 132 installed at the entrance of the classroom, as would be the case if the user attended a face-to-face class, and therefore no identity authentication has been performed.

[0256] Then, after the class ends, as shown in the pop image P33, when the user (student) clicks on the lower column G53 labeled "Exit," the terminal application 141 stops displaying the pop image P33.

[0257] Furthermore, the terminal application 141 switches the display from UI image P2 to UI image P31 in FIG. 18, updates the seventh attendance management information to information P41, and sets it to "2024 / 5 / 31 10:20 Online," recording that the student attended a remote class at 10:20 on May 31, 2024.

[0258] Furthermore, it is desirable that the lower column G42 not only functions as a button that is clicked when uploading the student ID card as terminal identification information to the matching server 134, but also functions only when information that only the user who owns the user terminal 131 knows is entered using a password or biometric authentication.

[0259] In other words, when attending a remote class, the user terminal 131 cannot be held over the NFC chip 132 with an antenna to perform the registration process of sharing connection information and terminal identification information with the matching server 134, so the personal authentication process essentially uses only a certificate.

[0260] Therefore, when attending a remote class, if a third party copies the connection information and terminal identification information and uses it on the third party's user terminal 131, impersonation can be realized.

[0261] Therefore, in order to properly prevent impersonation when remote classes are selected, when starting the verification process, the button operation in the lower column G42 must only function when information known only to the user who owns the user terminal 131 is entered using a password or biometric authentication, so that the certificate can only be used by the person requesting identity authentication.

[0262] <<3. Second embodiment>> <Regarding identity authentication in the second embodiment> In the above, an example has been described in which the fixed terminal 133 acquires connection information from the matching server 134, and then the terminal application 141 of the user terminal 131 writes the terminal identification information to the fixed terminal 133 and reads and acquires the connection information, and the fixed terminal 133 supplies the written terminal identification information to the matching server 134, thereby realizing the registration process.

[0263] However, after the registration process is completed, it is sufficient if the user terminal 131 and the matching server 134 are in a state where they hold the connection information and terminal identification information via the fixed terminal 133. Therefore, after the terminal application 141 of the user terminal 131 writes the terminal identification information to the fixed terminal 133, the fixed terminal 133 supplies the terminal identification information to the matching server 134, the matching server 134 generates connection information and supplies it to the fixed terminal 133, and the terminal application 141 reads the connection information from the fixed terminal 133.

[0264] FIG. 19 is a diagram illustrating personal authentication in the second embodiment.

[0265] First, in a fifty-first process St51, the terminal identification information writing unit 151 supplies a terminal identification information write command to the fixed terminal 133 together with the terminal identification information that it holds.

[0266] In the 52nd process St52, when the session management unit 192 of the fixed terminal 133 acquires the terminal identification information together with the write command for the terminal identification information, it writes and stores the terminal identification information in response to the write command, thereby completing the reception of the terminal identification information.

[0267] In a fifty-third process St53, the session management unit 192 notifies the user terminal 131 of the success of writing the terminal identification information. In response to this, the terminal identification information writing unit 151 receives the notification of the success of writing the terminal identification information.

[0268] In a fifty-fourth process St54, the session management unit 192 of the fixed terminal 133 supplies a session request with terminal identification information to the verification server 134, and requests a session ID.

[0269] In response to this, in the 55th process St55, the connection information generation unit 212 of the verification server 134 generates a session ID consisting of a fixed value, associates it with the terminal identification information, and registers it in the DB 215. Note that in Fig. 19, "ABCD" is expressed as an example of the session ID that has been generated.

[0270] Then, in a fifty-sixth process St56, the connection information generating unit 212 supplies the URI information together with the session ID as connection information to the fixed terminal 133 as a reply to the session request.

[0271] In the fifty-seventh process St57, the session management unit 192 receives and stores the session ID and URI information supplied from the verification server 134 as connection information.

[0272] In a fifty-eighth process St58 , the connection information reading unit 152 in the terminal application 141 of the user terminal 131 supplies a connection information reading command to the fixed terminal 133 .

[0273] In the fifty-ninth process St59, upon receiving the connection information read command, the session management unit 192 reads the connection information and supplies it to the user terminal 131. As a result, the connection information reading unit 152 obtains the connection information.

[0274] Through the processing up to this point, the user terminal 131 writes the terminal identification information to the fixed terminal 133 and further notifies the matching server 134, which then stores the terminal identification information in DB 215 in association with the connection information (session ID). Then, the matching server 134 generates connection information consisting of the session ID and URI information, and supplies it to the user terminal 131 via the fixed terminal 133.

[0275] In the 60th process St60, the certificate exchange unit 153 in the terminal application 141 of the user terminal 131 establishes communication with the verification server 134 using the connection information, uploads the certificate together with the terminal identification information to the verification server 134, and requests personal authentication. Note that in Figure 19, the terminal identification information and connection information enclosed by dotted lines are represented as the terminal identification information and connection information uploaded from the user terminal 131.

[0276] In the 61st process St61, the certificate exchange unit 213 of the verification server 134 obtains the certificate and terminal identification information supplied from the user terminal 131 and verifies the certificate using the public key. Then, the verification unit 214 verifies the connection information (session ID) and the terminal identification information together with the information in the DB 215, and performs identity authentication based on whether there is a match and whether the certificate is authentic, and notifies the user terminal 131 of the authentication result.

[0277] Through the above series of processes, the matching server 134 stores the terminal identification information of the user terminal 131 in DB 215 in association with the session ID, which is the connection information that it issued in advance via the fixed terminal 133. At this time, the user terminal 131 has acquired the connection information, including the session ID and URI information issued by the matching server 134, via the fixed terminal 133.

[0278] As a result, the user terminal 131 uses the connection information to establish communication with the matching server 134, and supplies the certificate and its own terminal identification information to the matching server 134 to request authentication of the user, allowing the matching server 134 to compare the connection information and terminal identification information obtained via the fixed terminal 133 with the connection information and terminal identification information supplied directly from the user terminal 131.

[0279] In other words, the verification server 134 can perform identity authentication based on whether the terminal identification information written by the user terminal 131 to the fixed terminal 133 via the NFC chip 132 matches the terminal identification information supplied together with the certificate sent directly from the user terminal 131 and whether the certificate is genuine.

[0280] As a result, if a certificate is provided using other connection information, the session ID will be different, and the terminal identification information and connection information provided by the user terminal 131 will not match the terminal identification information and connection information registered in DB215, making it possible to prevent impersonation of a user using other connection information.

[0281] <Personal Authentication Processing (Part 2)> Next, the personal authentication processing (part 2) will be described with reference to the flowchart of FIG.

[0282] When the user terminal 131 is held over the NFC chip 132, the user terminal 131 starts communication with the fixed terminal 133 via the NFC chip 132, and the process proceeds to step S211. In step S211, the terminal identification information writing unit 151 of the terminal application 141 transmits a terminal identification information write command to the fixed terminal 133 together with the terminal identification information.

[0283] In step S231, when the session management section 192 of the fixed terminal 133 acquires the terminal identification information and the terminal identification information write command, the session management section 192 writes the terminal identification information to itself based on the terminal identification information write command.

[0284] In step S232, the session management unit 192 notifies the user terminal 131 that the terminal identification information has been successfully written.

[0285] In step S233, the session management unit 192 of the fixed terminal 133 generates a session request together with the terminal identification information from the verification server 134, and requests a session ID.

[0286] In step S251, the connection information generating unit 212 of the verification server 134 receives a session request that is a request to generate a session ID together with terminal identification information.

[0287] In step S252, the connection information generating unit 212 reads out a session ID consisting of a fixed value, generates URI information consisting of a fixed value, and generates connection information.

[0288] In step S253, the connection information generating unit 212 stores the terminal identification information in the DB 215 in association with the connection information including the session ID and URI information.

[0289] In step S254, the connection information generating unit 212 transmits the connection information consisting of the session ID and the URI information to the fixed terminal 133 as a reply to the session request.

[0290] In step S234, the session management unit 192 of the fixed terminal 133 receives and stores the connection information consisting of the session ID and URI information.

[0291] In step S212, the terminal identification information writing unit 151 receives a notification that the terminal identification information has been successfully written.

[0292] In step S213, connection information reading section 152 in terminal application 141 transmits a connection information read command to fixed terminal 133 via NFC chip 132, requesting that the connection information be read.

[0293] In step S 235 , the session management unit 192 of the fixed terminal 133 receives the connection information read command from the user terminal 131 .

[0294] In step S 236 , the session management unit 192 reads out the connection information based on the connection information read command and transmits it to the user terminal 131 .

[0295] In step S214, the connection information reading unit 152 of the user terminal 131 acquires and stores the connection information supplied from the fixed terminal 133.

[0296] In step S215, certificate exchanging section 153 uses the connection information to establish communication with verification server 134, notifies verification server 134 of the certificate together with the terminal identification information, and requests personal authentication.

[0297] In step S255, the certificate exchange unit 213 of the verification server 134 receives the certificate and terminal identification information from the user terminal 131 as well as a request for personal authentication.

[0298] In step S256, certificate exchange unit 213 verifies the certificate using the public key. Verification unit 214 compares the connection information and terminal identification information with information in DB 215, and performs identity authentication based on whether matching information exists and whether the certificate is authentic.

[0299] In step S257, the matching unit 214 matches the connection information and the terminal identification information with the information in the DB 215, and supplies the result of personal authentication based on whether or not there is matching information in the matching result and the certificate is authentic to the user terminal 131. That is, the matching unit 214 matches the connection information and the terminal identification information with the information registered in the DB 215, and if there is matching information and the certificate is authentic, notifies the user terminal 131 that personal authentication has been approved, and otherwise notifies the user terminal 131 that personal authentication has not been approved.

[0300] In step S216, terminal application 141 acquires the result of the personal authentication and displays it on display unit 144.

[0301] In step S212, if there is no notification of successful writing of the terminal identification information for a predetermined time or more, the processes of steps S213 to S216 may be skipped so that personal authentication cannot be requested.

[0302] That is, in this case, since the terminal identification information is not written in the fixed terminal 133, the terminal identification information is not notified to the verification server 134 either, and therefore personal authentication cannot be realized.

[0303] As a result, steps S213 to S216 and steps S251 to S257 may be skipped, and the process may end without authenticating the user. In this case, steps S232 to S236 cannot be performed, so steps S232 to S236 may also be skipped, and the process may end.

[0304] In the above processing, before the user terminal 131 requests personal authentication, the matching server 134 stores the terminal identification information of the user terminal 131 in DB 215 via the fixed terminal 133 in association with the session ID, which is the connection information issued by the matching server 134 itself.

[0305] Meanwhile, at this time, the user terminal 131 acquires connection information including the session ID and URI information issued by the verification server 134 via the fixed terminal 133 .

[0306] This enables the user terminal 131 to establish communication with the matching server 134 using the connection information, and to supply the certificate along with its own terminal identification information corresponding to the certificate to the matching server 134 to request authentication of the user's identity.

[0307] As a result, in the second embodiment, as in the first embodiment, it is possible to prevent spoofing by a user using other connection information.

[0308] <Regarding identity authentication in a modified example of the second embodiment> In the above, we have explained an example in which the session ID generated by the matching server 134 is a fixed value, but the session ID may also be set to a dynamically changing value, for example, by incrementing a random number or a predetermined value each time.

[0309] FIG. 21 is a diagram illustrating personal authentication in a modified example of the second embodiment.

[0310] Note that the 71st process St71 to the 81st process St81 in Figure 21 correspond to the 51st process St51 to the 51st process St61 in Figure 19, and are basically the same processes except for the 75th process St75.

[0311] That is, in the 75th process St75, the connection information generation unit 212 of the matching server 134 generates a session ID consisting of a dynamically changing value, for example by incrementing a random number or a predetermined value each time, and registers it in the DB215 in association with the terminal identification information.

[0312] Then, in a 76th process St76, the connection information generation unit 212 transmits the session ID as a reply to the session request to the fixed terminal 133. At this time, the connection information generation unit 212 also supplies the URI information to the fixed terminal 133 as connection information.

[0313] In the 77th process St77, the session management unit 192 receives and stores the session ID and URI information, which are dynamically changing values ​​supplied from the verification server 134, as connection information.

[0314] In the 78th process St78 , the connection information reading unit 152 in the terminal application 141 of the user terminal 131 supplies a connection information reading command to the fixed terminal 133 .

[0315] In the 79th process St79 , upon receiving the connection information read command, the session management unit 192 reads out connection information consisting of a session ID and URI information, which are dynamically changing values, and supplies the connection information to the user terminal 131 .

[0316] Also, in the 80th process St80, the certificate exchange unit 153 in the terminal application 141 of the user terminal 131 establishes communication with the matching server 134 using connection information consisting of a session ID and URI information, which are dynamically changing values, and uploads the connection information together with the certificate and terminal identification information to the matching server 134, requesting personal authentication.

[0317] In other words, in the process of Figure 21, the session ID is dynamically changed and generated each time, so that the user terminal 131 establishes communication with the matching server 134 based on connection information consisting of a dynamically changing session ID and fixed terminal identification information, thereby making it possible to improve the security level.

[0318] <Personal Authentication Processing (Variation 2)> Next, the personal authentication processing (Variation 1) will be described with reference to the flowchart in Fig. 22. Note that the processes in steps S311 to S316, steps S331 to S336, and steps S351, S353 to S357 in Fig. 22 are similar to the processes in steps S211 to S216, steps S231 to S236, and steps S251, S253 to S257 in Fig. 20, and therefore description thereof will be omitted.

[0319] That is, the flowchart in FIG. 22 differs from the flowchart in FIG. 20 in the process of step S352.

[0320] In step S352, the connection information generating unit 212 generates a session ID consisting of a dynamically changing value, for example, by incrementing a random number or a predetermined value each time, and also generates URI information and connection information.

[0321] In the above process, the session ID is dynamically changed and generated each time, and the certificate and terminal identification information are supplied to the verification server 134 through communication established based on the session ID, which is a dynamically changing value, and connection information, which is made up of URI information. This makes it possible to improve the security level related to certificate verification.

[0322] Although the above description has been given of an example in which the session ID changes dynamically, the URI information may also change dynamically, or the terminal identification information may also change dynamically each time. In other words, by dynamically changing at least one of the session ID, URI information, and terminal identification information each time, the security level can be improved, and the greater the number of parameters that change dynamically each time, the higher the security level. For example, the highest security level can be achieved by dynamically changing all of the session ID, URI information, and terminal identification information each time. However, the more dynamically changing parameters there are, the more complex the processing becomes.

[0323] <<4. Third embodiment>> <Personal authentication in the third embodiment> In the above, an example has been described in which user terminal 131 writes terminal identification information to fixed terminal 133, fixed terminal 133 supplies the written terminal identification information to matching server 134, matching server 134 supplies connection information to fixed terminal 133, and user terminal 131 acquires the connection information read from fixed terminal 133, whereby user terminal 131 and matching server 134 perform a registration process in which they mutually register terminal identification information and connection information, and then user terminal 131 uses the connection information to establish communication with matching server 134, and supplies the certificate and terminal identification information together to matching server 134, thereby performing personal authentication.

[0324] That is, when the user terminal 131 writes terminal identification information to the fixed terminal 133 via the NFC chip 132 with an antenna, the terminal identification information of the user terminal 131, which has been proven to have communicated with the NFC chip 132, is registered in the matching server 134, thereby realizing personal authentication.

[0325] Therefore, when the terminal application 141 of the user terminal 131 supplies a write command for the terminal identification information to the NFC chip 132 together with the terminal identification information and writes the terminal identification information, the terminal application 141 does not supply the terminal identification information and the certificate together to the verification server 134 until it is confirmed that a notification of successful writing has been supplied from the NFC chip 132.

[0326] That is, terminal application 141 is configured to authenticate the user only when it is confirmed that terminal identification information has been reliably written in NFC chip 132, making it possible to prevent impersonation.

[0327] In this case, however, the terminal application 141 of the user terminal 131 holds a message authentication code (MAC) key used as a shared key between the terminal application 141 and the verification server 134, generates MAC authentication using the terminal identification information, and writes the terminal identification information with MAC authentication to the NFC chip 132. The terminal application 141 also supplies the terminal identification information with MAC authentication to the verification server 134 together with the certificate.

[0328] The verification server 134 verifies the terminal identification information with MAC authentication and the certificate from the user terminal 131, whose communication with the NFC chip 132 is guaranteed. More specifically, the verification server 134 generates MAC authentication from the terminal identification information using a MAC key, which is a common key, and verifies the terminal identification information based on whether it matches the assigned MAC authentication. The verification server 134 also verifies the certificate using a public key, and achieves personal authentication based on the results of both verifications.

[0329] FIG. 23 is a diagram illustrating personal authentication in the third embodiment.

[0330] First, in the 91st process St91, the terminal identification information writing unit 151 generates and assigns MAC authentication to the terminal identification information it holds using a MAC key, and supplies a write command for the terminal identification information with MAC authentication to the NFC chip 132 along with the terminal identification information with MAC authentication.

[0331] In the 92nd process St92, the emulator processing unit 171 of the NFC chip 132 functions as a tag, writes the terminal identification information with MAC authentication based on the write command for the terminal identification information with MAC authentication, and notifies the user terminal 131 of the success of writing the terminal identification information with MAC authentication. In response to this, the terminal application 141 of the user terminal 131 receives the notification of the success of writing the terminal identification information with MAC authentication.

[0332] In the 93rd process St93 , upon confirming the notification that the writing of the MAC-authentication-added terminal identification information was successful, the connection information reading unit 152 in the terminal application 141 of the user terminal 131 supplies a connection information reading command to the NFC chip 132 .

[0333] In the 94th process St94, when the emulator processing unit 171 of the NFC chip 132 acquires the connection information read command, it reads out connection information consisting of fixed-value URI information and fixed-value session ID, and supplies the connection information to the user terminal 131. As a result, the connection information reading unit 152 acquires the connection information.

[0334] Through the processing up to this point, the user terminal 131 writes the terminal identification information with MAC authentication to the fixed terminal 133, and connection information consisting of a session ID and URI information made up of fixed values ​​is supplied to the user terminal 131.

[0335] In the 95th process St95, the certificate exchange unit 153 in the terminal application 141 of the user terminal 131 establishes communication with the verification server 134 using the connection information, uploads the certificate together with the terminal identification information with MAC authentication to the verification server 134, and requests personal authentication. Note that in Figure 23, the terminal identification information and connection information surrounded by dotted lines are represented as the terminal identification information with MAC authentication and connection information uploaded from the user terminal 131.

[0336] In the 96th process St96, the certificate exchange unit 213 of the verification server 134 obtains the certificate and the terminal identification information with MAC authentication supplied from the user terminal 131 and verifies the certificate using the public key. The verification unit 214 generates a MAC authentication for the terminal identification information using the MAC key and verifies the terminal identification information based on whether it matches the MAC authentication assigned to the terminal identification information. The verification unit 214 then performs user authentication based on the verification results of both the certificate and the terminal identification information with MAC authentication, and notifies the user terminal 131 of the authentication result.

[0337] Through the above series of processes, the terminal application 141 of the user terminal 131 supplies the NFC chip 132 with terminal identification information with MAC authentication and the write command, and upon receiving notification of successful writing, obtains connection information including the session ID and URI information issued by the NFC chip 132.

[0338] As a result, terminal application 141 uses the connection information to establish communication with verification server 134, and supplies the certificate and terminal identification information with MAC authentication to verification server 134, requesting authentication of the user.

[0339] In response to this, when the matching server 134 acquires the connection information and terminal identification information with MAC authentication supplied directly from the user terminal 131, it generates MAC authentication from the terminal identification information using the MAC key, verifies the MAC authentication attached to the terminal identification information, and can also verify the certificate using the public key.

[0340] In other words, by using the MAC key to verify the MAC authentication assigned to the terminal identification information, the matching server 134 can verify both that the terminal identification information, which is guaranteed to be written to the NFC chip 132, has not been tampered with and the certificate.

[0341] As a result, if another user terminal 131 copies and uses another terminal identification information, the fraud can be confirmed in MAC authentication verification, making it possible to prevent impersonation of a user using another terminal identification information.

[0342] <Personal Authentication Processing (Part 3)> Next, the personal authentication processing (Part 3) will be described with reference to the flowchart of FIG.

[0343] In step S311, terminal identification information writing section 151 of terminal application 141 generates MAC authentication from the terminal identification information using the MAC key and assigns it to the terminal identification information, thereby generating terminal identification information with MAC authentication.

[0344] In step S312 , the terminal identification information writing unit 151 transmits the terminal identification information with MAC authentication and a command to write the terminal identification information with MAC authentication to the NFC chip 132 .

[0345] In step S331, when the emulator processing unit 171 of the NFC chip 132 acquires the terminal identification information with MAC authentication and the write command for the terminal identification information with MAC authentication, it writes the terminal identification information with MAC authentication to itself based on the write command for the terminal identification information with MAC authentication.

[0346] In step S332, the session management unit 192 notifies the user terminal 131 that the writing of the terminal identification information with MAC authentication has been successful.

[0347] In step S313, the terminal identification information writing unit 151 receives a notification that the terminal identification information with MAC authentication has been successfully written.

[0348] In step S314, connection information reading section 152 in terminal application 141 transmits a connection information reading command to NFC chip 132, requesting that the connection information be read.

[0349] In step S533 , the emulator processing unit 171 of the NFC chip 132 acquires a command to read connection information from the user terminal 131 .

[0350] In step S 534 , the emulator processing unit 171 reads out connection information consisting of fixed-value URI information and fixed-value session ID based on the connection information read command, and transmits it to the user terminal 131 .

[0351] In step S515, the connection information reading unit 152 of the user terminal 131 acquires and stores the connection information supplied from the NFC chip 132.

[0352] In step S516, certificate exchanging section 153 uses the connection information to establish communication with verification server 134, notifies verification server 134 of the certificate together with the MAC authentication-included terminal identification information, and requests personal authentication.

[0353] In step S551, the certificate exchange unit 213 of the verification server 134 receives from the user terminal 131 a request for personal authentication along with the certificate and terminal identification information with MAC authentication.

[0354] In step S552, certificate exchange unit 213 verifies the certificate using a public key that is the counterpart of the private key used for the signature attached to the certificate. Based on the terminal identification information with MAC authentication sent together with the certificate, comparison unit 214 generates a MAC authentication from the terminal identification information based on the MAC key, which is a common key, and determines whether the MAC authentication matches the MAC authentication attached to the terminal identification information.

[0355] In step S553, the collation unit 214 supplies the user terminal 131 with a result of personal authentication based on the verification results of both the terminal identification information with MAC authentication and the certificate. That is, the collation unit 214 generates MAC authentication from the terminal identification information based on the MAC key, and if it matches the MAC authentication assigned to the terminal identification information and the certificate is determined to be authentic, it notifies the user terminal 131 that personal authentication has been approved; otherwise, it notifies the user terminal 131 that personal authentication has not been approved.

[0356] In step S517, terminal application 141 acquires the result of the personal authentication and displays it on display unit 144.

[0357] In step S513, if there is no notification of successful writing of the terminal identification information for a predetermined time or more, the processes of steps S514 to S517 are skipped so that personal authentication cannot be requested.

[0358] That is, in this case, since the terminal identification information with MAC authentication is not written in the NFC chip 132, the connection information is not notified, and therefore personal authentication cannot be realized.

[0359] As a result, steps S513 to S216 and steps S551 to S553 may be skipped, and the process may end without authenticating the user. In this case, steps S531 to S534 may also not be realized, and so steps S531 to S534 may also be skipped, and the process may end.

[0360] In the above process, when the user terminal 131 writes the terminal identification information with MAC authentication into the NFC chip 132, the user terminal 131 acquires connection information including a fixed session ID and fixed URI information.

[0361] As a result, only when the terminal identification information with MAC authentication has been reliably written to the NFC chip 132 can the terminal application 141 of the user terminal 131 use the connection information to establish communication with the matching server 134, and supply the certificate and the terminal identification information with MAC authentication together to the matching server 134 to request authentication of the user.

[0362] In other words, when the terminal identification information with MAC authentication is not written to the NFC chip 132, the terminal application 141 cannot supply the certificate and the terminal recognition information with MAC authentication together to the verification server 134. Therefore, when the certificate and the terminal recognition information with MAC authentication are acquired by the verification server 134 and can be verified, spoofing becomes impossible.

[0363] As a result, in the third embodiment, as in the first and second embodiments, it is possible to prevent spoofing by a user using other connection information.

[0364] In the above, an example has been described in which the emulator processing unit 171 of the NFC chip 132 unconditionally writes terminal identification information with MAC authentication based on a write command for terminal identification information with MAC authentication supplied from the user terminal 131.

[0365] However, when receiving a write command from the user terminal 131, the emulator processing unit 171 may generate MAC authentication from the terminal identification information using a MAC key, which is a common key, based on the received terminal identification information with MAC authentication, and write the terminal identification information with MAC authentication only when it matches the assigned MAC authentication.

[0366] As a result, MAC authentication is verified when the terminal identification information with MAC authentication is written to the NFC chip 132, and furthermore, MAC authentication is also verified by the verification server 134, thereby achieving double verification and improving the effectiveness of preventing impersonation.

[0367] Conversely, if MAC authentication verification is performed at the stage when the terminal identification information with MAC authentication is written to the NFC chip 132, at least one MAC authentication verification will be performed in the NFC chip 132, so the MAC authentication verification in the matching server 134 may be omitted.

[0368] That is, verification of MAC authentication may be performed by both or either of the NFC chip 132 and the verification server 134. In this case, a configuration may be adopted depending on the required level of spoofing prevention effect and the processing capabilities and costs of the NFC chip 132 and the verification server 134. For example, by using the methods described in sections 5.4.3 "Read with MAC" and 5.4.4 "Write with MAC" in the technical specifications "FeliCa Lite-S User Manual" published by Sony (https: / / www.sony.co.jp / Products / felica / business / tech-support / data / fls_usmnl_1.4j.pdf), it is possible to perform a verification sequence that confirms authenticity using MAC authentication using an NFC chip with an antenna.

[0369] <Regarding identity authentication in a modified example of the third embodiment> In the above, we have explained an example in which the session ID generated by the matching server 134 is a fixed value, but the session ID may also be set to a dynamically changing value, for example, by incrementing a random number or a predetermined value each time.

[0370] FIG. 25 is a diagram illustrating personal authentication in a modified example of the third embodiment.

[0371] Note that the 111th process St111 to the 116th process St116 in Figure 25 correspond to the 91st process St91 to the 96th process St96 in Figure 23, and are basically the same processes except for the 114th process St114.

[0372] That is, in the 114th process St114, the emulator processing unit 171 of the NFC chip 132 generates connection information based on a session ID consisting of a dynamically changing value and URI information consisting of a fixed value, for example by incrementing a predetermined value each time, and supplies the connection information to the user terminal 131.

[0373] Then, in the 115th process St115, the certificate exchange unit 153 in the terminal application 141 of the user terminal 131 connects to the matching server 134 using connection information consisting of a session ID consisting of a dynamically changing value and URI information consisting of a fixed value, and uploads the certificate and terminal identification information to the matching server 134, requesting personal authentication.

[0374] That is, in the process of FIG. 25, the session ID is dynamically changed and generated each time, and therefore the certificate generated based on the connection information consisting of the session ID consisting of dynamically changing values ​​and the terminal identification information with MAC authentication also changes each time, which makes it possible to improve the security level for certificate verification.

[0375] <Personal Authentication Processing (Variation 3)> Next, the personal authentication processing (Variation 3) will be described with reference to the flowchart in Fig. 26. Note that the processes in steps S611 to S617, steps S631 to S633, and steps S651 to S653 in Fig. 26 are similar to the processes in steps S511 to S517, steps S531 to S533, and steps S551 to S553 in Fig. 24, and therefore description thereof will be omitted.

[0376] That is, the flowchart in FIG. 26 differs from the flowchart in FIG. 24 in the process of step S634.

[0377] In step S634, the emulator processing unit 171 of the NFC chip 132 generates a session ID consisting of a dynamically changing value, for example by incrementing a predetermined value each time, and also generates URI information with a fixed value, combines the two to form connection information, and supplies it to the user terminal 131.

[0378] In the above process, the session ID is dynamically changed and generated each time, and therefore the certificate generated based on the connection information consisting of the dynamically changing session ID and URI information also changes each time, thereby improving the security level related to certificate verification.

[0379] Although the above description has been given of an example in which the session ID changes dynamically, the URI information may also change dynamically, or the terminal identification information may also change dynamically each time. In other words, by dynamically changing at least one of the session ID, URI information, and terminal identification information each time, the security level can be improved, and the greater the number of parameters that change dynamically each time, the higher the security level. For example, the highest security level can be achieved by dynamically changing all of the session ID, URI information, and terminal identification information each time. However, the more dynamically changing parameters there are, the more complex the processing becomes.

[0380] <<5. Example of Execution by Software>> The above-described series of processes can be executed by hardware, but can also be executed by software. When the series of processes is executed by software, the program constituting the software is installed from a recording medium into a computer incorporated in dedicated hardware, or into, for example, a general-purpose computer that can execute various functions by installing various programs.

[0381] 27 shows an example of the configuration of a general-purpose computer. This computer has a built-in CPU (Central Processing Unit) 1001. An input / output interface 1005 is connected to the CPU 1001 via a bus 1004. A ROM (Read Only Memory) 1002 and a RAM (Random Access Memory) 1003 are connected to the bus 1004.

[0382] The input / output interface 1005 is connected to an input unit 1006 including input devices such as a keyboard and a mouse through which a user inputs operation commands, an output unit 1007 that outputs a processing operation screen and images of processing results to a display device, a storage unit 1008 including a hard disk drive or the like that stores programs and various data, and a communication unit 1009 including a LAN (Local Area Network) adapter or the like that executes communication processing via a network typified by the Internet. Also connected is a drive 1010 that reads and writes data from / to a removable storage medium 1011 such as a magnetic disk (including a flexible disk), an optical disk (including a CD-ROM (Compact Disc-Read Only Memory) and a DVD (Digital Versatile Disc)), a magneto-optical disk (including an MD (Mini Disc)), or a semiconductor memory.

[0383] The CPU 1001 executes various processes in accordance with a program stored in a ROM 1002 or a program read from a removable storage medium 1011 such as a magnetic disk, optical disk, magneto-optical disk, or semiconductor memory, installed in a storage unit 1008, and loaded from the storage unit 1008 into a RAM 1003. The RAM 1003 also stores data necessary for the CPU 1001 to execute various processes as appropriate.

[0384] In a computer configured as described above, the CPU 1001 performs the above-described series of processes by, for example, loading a program stored in the memory unit 1008 into the RAM 1003 via the input / output interface 1005 and the bus 1004 and executing it.

[0385] The program executed by the computer (CPU 1001) can be provided by being recorded on a removable storage medium 1011 such as a package medium, for example. The program can also be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.

[0386] In a computer, a program can be installed in the storage unit 1008 via the input / output interface 1005 by inserting a removable storage medium 1011 into the drive 1010. The program can also be received by the communication unit 1009 via a wired or wireless transmission medium and installed in the storage unit 1008. Alternatively, the program can be installed in advance in the ROM 1002 or the storage unit 1008.

[0387] The program executed by the computer may be a program that processes in chronological order according to the order described in this specification, or may be a program that processes in parallel or at the required timing, such as when called.

[0388] In addition, the CPU 1001 of the general-purpose computer in Figure 27 realizes the functions of the terminal application 141 of the user terminal 131, the emulator processing unit 171 of the NFC chip 132, the session management unit 192 of the fixed terminal 133, and the connection information generation unit 212, certificate exchange unit 213, and matching unit 214 of the matching server 134, respectively, in Figure 7.

[0389] In this specification, a system refers to a collection of multiple components (devices, modules (components), etc.), regardless of whether all of the components are housed in the same housing. Therefore, multiple devices housed in separate housings and connected via a network, and a single device housed in a single housing with multiple modules, are both systems.

[0390] Furthermore, the embodiments of the present disclosure are not limited to the above-described embodiments, and various modifications are possible within the scope of the gist of the present disclosure.

[0391] For example, the present disclosure can be configured as a cloud computing system in which a single function is shared and processed collaboratively by multiple devices via a network.

[0392] Furthermore, each step described in the above flowchart can be executed by one device, or can be shared and executed by a plurality of devices.

[0393] Furthermore, when one step includes multiple processes, the multiple processes included in that one step can be executed by one device or can be shared and executed by multiple devices.

[0394] Furthermore, since NFC chips with antennas have exactly the same functions as NFC chips installed in mobile phones, we have used NFC chips as an example in the sense that they are permanently installed in schools and facilities, but if teachers and facility staff install devices such as mobile phones and tablets on a regular basis, then they are not limited to NFC chips with antennas, and there is no problem in using mobile phones or tablet devices instead.

[0395] The present disclosure may also have the following configuration: <1> An authentication system including a terminal device and a matching server, wherein the terminal device acquires connection information related to communication with the matching server via a first network by short-range communication, and transmits a certificate including attribute information of its holder to the matching server based on the connection information by communication via the first network, and the matching server receives the certificate transmitted via the first network and verifies the certificate, thereby authenticating the terminal device. <2> The authentication system described in <1>, wherein the terminal device writes identification information that identifies itself through the short-range communication, and the verification server acquires the identification information written from the terminal device through the short-range communication by communication via a second network different from the first network, and generates the connection information, the terminal device acquires the connection information through communication via the second network and the short-range communication, and transmits the certificate and the identification information to the verification server via the first network based on the connection information, and the verification server receives the certificate and the identification information transmitted from the terminal device via the first network, and authenticates the terminal device by verifying the certificate and comparing the identification information received via the first network with the identification information received via the second network. <3> The authentication system described in <2>, wherein the verification server generates the connection information, and the terminal device writes the identification information after acquiring the connection information through communication via the second network and the short-range communication, and the verification server acquires the identification information.<4> The system further includes a short-range communication chip that communicates with the terminal device through short-range communication when the terminal device is held over the first network; and a fixed terminal connected to the short-range communication chip and communicating with the verification server via the second network, wherein the verification server generates the connection information, the fixed terminal acquires the connection information from the verification server through communication via the second network, and reads the connection information to the terminal device via the short-range communication chip, the terminal device acquires the connection information read from the fixed terminal via the short-range communication chip, and writes the identification information to the fixed terminal via the short-range communication chip, and the verification server acquires the identification information written to the fixed terminal through communication via the second network, the terminal device transmits the certificate and the identification information via the first network based on the connection information, and the verification server receives the certificate and the identification information transmitted from the terminal device via the first network, The authentication system according to <3>, wherein the terminal device is authenticated by verifying the certificate and comparing the identification information received via the first network with the identification information received via the second network. <5> The authentication system according to <2>, wherein the terminal device writes the identification information, the comparison server acquires the identification information and then generates the connection information, and the terminal device acquires the connection information through communication via the second network and the short-range communication.<6> The authentication system according to <5>, further including: a short-range communication chip that communicates with the terminal device through the short-range communication when the terminal device is held over it; and a fixed terminal connected to the short-range communication chip and communicating with the verification server via the second network, wherein the terminal device writes the identification information to the fixed terminal via the short-range communication chip; the verification server acquires the identification information written to the fixed terminal by communication via the second network and generates the connection information; the fixed terminal acquires the connection information from the verification server by communication via the second network and reads the connection information to the terminal device via the short-range communication chip; the terminal device transmits the certificate and the identification information via the first network based on the connection information; and the verification server receives the certificate and the identification information transmitted from the terminal device via the first network and authenticates the terminal device by verifying the certificate and comparing the identification information received via the first network with the identification information received via the second network. <7> The authentication system according to <2>, wherein the connection information includes URI information and a session ID. <8> The authentication system according to <7>, wherein the URI information and the session ID are both fixed values. <9> The authentication system according to <7>, wherein at least one of the URI information and the session ID is a dynamically changing value. <10> The authentication system according to <9>, wherein a value obtained by adding at least one of the URI information and the session ID, which are the dynamically changing values, to the original identification information, which is a fixed value, is used as the pseudo identification information. <11> The authentication system according to <10>, wherein at least one of the URI information, the session ID, and the identification information is the dynamically changing value. <12> The authentication system according to <1>, wherein the verification server authenticates the terminal device by verifying the certificate, and authenticates the holder by authenticating the terminal device.<13> An information processing method for an authentication system comprising a terminal device and a matching server, comprising: the terminal device performing an acquisition process to acquire connection information related to communication with the matching server via a first network by short-range communication, a transmission process to transmit a certificate including attribute information of its holder to the matching server via communication via the first network based on the connection information, the matching server performing a reception process to receive the certificate transmitted via the first network, and an authentication process to authenticate the terminal device by verifying the certificate. <14> A computer constituting an authentication system comprising a terminal device and a matching server, comprising: the terminal device performing a program to cause the computer to: acquire connection information related to communication with the matching server via the first network by short-range communication, transmit a certificate including attribute information of its holder to the matching server via communication via the first network based on the connection information, the matching server receiving the certificate transmitted via the first network, and authenticate the terminal device by verifying the certificate.

[0396] DESCRIPTION OF SYMBOLS 111 Authentication system, 131 User terminal, 132 NFC chip, 133 Fixed terminal, 134 Verification server, 141 Terminal application, 142 RF communication unit, 143 Network communication unit, 151 Terminal identification information write unit, 152 Connection information read unit, 153 Certificate exchange unit, 171 Emulator processing unit, 172 RF communication unit, 173 Fixed terminal communication unit, 191 Display unit, 192 Session management unit, 193 Network communication unit, 194 NFC chip communication unit, 211 Communication unit, 212 Connection information generation unit, 213 Certificate exchange unit, 214 Verification unit, 215 DB

Claims

1. An authentication system comprising a terminal device and a matching server, wherein the terminal device acquires connection information relating to communication with the matching server via a first network through short-range communication, and based on the connection information, transmits a certificate including attribute information of its holder to the matching server via communication through the first network, and the matching server receives the certificate transmitted via the first network and verifies the certificate, thereby authenticating the terminal device.

2. The authentication system described in claim 1, wherein the terminal device writes identification information that identifies itself through the short-range communication, the matching server acquires the identification information written from the terminal device through the short-range communication by communication via a second network different from the first network, and generates the connection information, the terminal device acquires the connection information through communication via the second network and the short-range communication, and transmits the certificate and the identification information to the matching server via the first network based on the connection information, and the matching server receives the certificate and the identification information transmitted from the terminal device via the first network, verifies the certificate, and authenticates the terminal device by comparing the identification information received via the first network with the identification information received via the second network.

3. The authentication system of claim 2, wherein the matching server generates the connection information, the terminal device acquires the connection information through communication via the second network and the short-range communication, and then writes the identification information, and the matching server acquires the identification information.

4. The system further includes a short-range communication chip that communicates with the terminal device through short-range communication when the terminal device is held over the first network, and a fixed terminal connected to the short-range communication chip and communicating with the matching server via the second network, wherein the matching server generates the connection information, the fixed terminal acquires the connection information from the matching server through communication via the second network, and reads the connection information to the terminal device via the short-range communication chip, the terminal device acquires the connection information read from the fixed terminal via the short-range communication chip, and writes the identification information to the fixed terminal via the short-range communication chip, and the matching server acquires the identification information written to the fixed terminal through communication via the second network, the terminal device transmits the certificate and the identification information via the first network based on the connection information, and the matching server receives the certificate and the identification information transmitted from the terminal device via the first network, 4. The authentication system according to claim 3, wherein the terminal device is authenticated by verifying the certificate and comparing the identification information received via the first network with the identification information received via the second network.

5. The authentication system of claim 2, wherein the terminal device writes the identification information, the matching server acquires the identification information and then generates the connection information, and the terminal device acquires the connection information through communication via the second network and the short-range communication.

6. An authentication system as described in claim 5, further comprising: a short-range communication chip that communicates with the terminal device via short-range communication when the terminal device is held over the authentication server; and a fixed terminal connected to the short-range communication chip and communicating with the verification server via the second network, wherein the terminal device writes the identification information to the fixed terminal via the short-range communication chip; the verification server acquires the identification information written to the fixed terminal by communication via the second network and generates the connection information; the fixed terminal acquires the connection information from the verification server by communication via the second network and reads the connection information to the terminal device via the short-range communication chip; the terminal device transmits the certificate and the identification information via the first network based on the connection information; and the verification server receives the certificate and the identification information transmitted from the terminal device via the first network and authenticates the terminal device by verifying the certificate and comparing the identification information received via the first network with the identification information received via the second network.

7. The authentication system according to claim 2, wherein the connection information includes URI information and a session ID.

8. The authentication system according to claim 7, wherein the URI information and the session ID are both fixed values.

9. The authentication system according to claim 7, wherein at least one of the URI information and the session ID is a dynamically changing value.

10. An authentication system as described in claim 9, wherein a value obtained by adding at least one of the URI information and the session ID, which are dynamically changing values, to the original identification information, which is a fixed value, is used as the pseudo identification information.

11. The authentication system according to claim 10, wherein at least one of the URI information, the session ID, and the identification information is the dynamically changing value.

12. The authentication system according to claim 1, wherein the verification server authenticates the terminal device by verifying the certificate, and authenticates the identity of the holder by authenticating the terminal device.

13. An information processing method for an authentication system comprising a terminal device and a matching server, the information processing method including the steps of: the terminal device performing an acquisition process to acquire connection information relating to communication with the matching server via a first network by short-range communication; a transmission process to transmit a certificate including attribute information of its holder to the matching server via communication via the first network based on the connection information; the matching server performing a reception process to receive the certificate transmitted via the first network; and an authentication process to authenticate the terminal device by verifying the certificate.

14. A computer that constitutes an authentication system consisting of a terminal device and a matching server, wherein the terminal device obtains connection information related to communication with the matching server via a first network using short-range communication, and based on the connection information, transmits a certificate containing attribute information of its holder to the matching server via communication via the first network, and the matching server receives the certificate transmitted via the first network and verifies the certificate, thereby authenticating the terminal device.

Images