WO2024095755A1 - Serveur de gestion, système de traitement d'informations et procédé de traitement d'informations - Google Patents

Serveur de gestion, système de traitement d'informations et procédé de traitement d'informations Download PDF

Info

Publication number
WO2024095755A1
WO2024095755A1 PCT/JP2023/037472 JP2023037472W WO2024095755A1 WO 2024095755 A1 WO2024095755 A1 WO 2024095755A1 JP 2023037472 W JP2023037472 W JP 2023037472W WO 2024095755 A1 WO2024095755 A1 WO 2024095755A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
card
user
personal authentication
personal
Prior art date
Application number
PCT/JP2023/037472
Other languages
English (en)
Japanese (ja)
Inventor
康雄 竹内
Original Assignee
ソニーグループ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソニーグループ株式会社 filed Critical ソニーグループ株式会社
Publication of WO2024095755A1 publication Critical patent/WO2024095755A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication

Definitions

  • This technology relates to a management server, an information processing system, and an information processing device, and in particular to a management server, an information processing system, and an information processing device that enable information on a contactless IC card to be registered only on the card user's own information processing device, based on authenticity according to the security policy desired by the card issuer, etc. of the contactless IC card.
  • IC cards such as FeliCa (registered trademark), a contactless IC card technology
  • FeliCa registered trademark
  • a contactless IC card technology can also be used as cards for personal authentication based on the information written on them, and are being used in a variety of businesses.
  • it can be used to charge and subtract closed money managed online, and if shared within related companies, it can be used for identity verification at printers and payment for a wide range of services.
  • Patent Document 1 the following user authentication method is disclosed.
  • a service providing device transmits a service identifier that identifies the service and service authentication information that authenticates the service to the authentication card upon presentation of the authentication card.
  • the authentication card searches for a user identifier that is uniquely assigned to each service and each authentication card from a service management table that records multiple service information, and authenticates the service authentication device. If the authentication is successful, information including a card identifier, which is information unique to the authentication card, is encrypted with a card key to generate card authentication information, and then the searched user identifier and the generated card authentication information are transmitted to the service providing device.
  • the service providing device transmits the transmitted card authentication information to an authentication authority device.
  • the authentication authority device decrypts the transmitted card authentication information with a card key to obtain a card identifier, determines the validity of the obtained card identifier, and transmits the result of the determination to the service providing device.
  • the user of the authentication card is identified by sequentially going through the above series of processes.
  • Patent Document 1 only limits the method to a uniform one in which a user is registered and recognized using a reassigned service identifier, and is not capable of handling the diverse identity verification methods desired by issuers using IC cards issued under complex conditions.
  • This technology was developed in light of these circumstances, and allows contactless IC card information to be registered only on the card user's own information processing device, based on authenticity according to the security policy desired by the card issuer, etc.
  • this example is not limited to contactless cards, and even IC cards with a contact interface can communicate with a mobile phone via BLE by inserting them into a reader/writer with BLE functionality, so there is no limitation to the interface the card has.
  • the management server or information processing system of the first aspect of this technology is a management server or information processing system having a processing unit that performs identity verification that a user of an information processing device in which personal authentication information held by a personal authentication card, which is a contactless IC card, is registered is the card user authenticated by the personal authentication card, in a manner that conforms to the policy of the organization that issued the personal authentication card.
  • identity verification that a user of an information processing device in which personal authentication information held by a personal authentication card, which is a contactless IC card, is registered is the card user authenticated by the personal authentication card is performed in a manner that conforms to the policy of the organization that issued the personal authentication card.
  • the information processing device has an SE chip (also called a secure element) in which at least a portion of the personal authentication information held by a personal authentication card, which is a contactless IC card, is registered at the request of the user, and identity verification is performed in a manner that conforms to the policy of the organization that issued the personal authentication card, with the information being registered in the SE chip only when it has been confirmed that the user is the card user authenticated by the personal authentication card.
  • SE chip also called a secure element
  • an SE chip (also called a secure element) is provided in which at least a portion of the personal authentication information held by a personal authentication card, which is a contactless IC card, is registered at the request of the user, and identity verification is performed in a manner that conforms to the policy of the organization that issued the personal authentication card, and the information is registered in the SE chip only when it has been confirmed that the user is the card user authenticated by the personal authentication card.
  • FIG. 1 is a diagram illustrating an example of the configuration of an information processing system to which the present technology is applied.
  • FIG. 13 is a diagram illustrating a flow of issuing a card to a mobile terminal.
  • 10 is a diagram illustrating an example of a selection screen for a service to be emulated on a mobile terminal as an IC card using NFC.
  • FIG. 11 is a diagram illustrating an outline of a posture data generation process. 13 is a diagram showing an example of a digital effect on a face image of a card.
  • 1 is a diagram for explaining registration information (personal authentication information) of a card user of a personal authentication card.
  • FIG. 11 is a diagram showing an example of a face image of a personal authentication card emulated on a mobile terminal;
  • FIG. 11 is a diagram showing an example of a face image of a personal authentication card emulated on a mobile terminal;
  • FIG. 13 is a diagram showing an example of the registration information (personal authentication information) of each card user managed by the SP server.
  • FIG. 13 is a diagram showing an example of the registration information (personal authentication information) of each card user managed by the SP server.
  • FIG. 13 is a diagram showing an example of the registration information (personal authentication information) of each card user managed by the SP server.
  • FIG. 13 is a diagram showing an example of the registration information (personal authentication information) of each card user managed by the SP server.
  • FIG. 13 is a diagram showing an example of the registration information (personal authentication information) of each card user managed by the SP server.
  • FIG. 1 is a diagram illustrating an example of authentication information for personal authentication stored in an SE chip of a mobile terminal. 1 is a sequence diagram illustrating a basic flow of issuing a card to a mobile terminal.
  • FIG. 13 is a diagram showing a specific example of an authenticity evaluation method according to a customer policy for card issuance.
  • FIG. 13 is a diagram illustrating an expression of an authenticity evaluation method implemented according to a customer policy.
  • FIG. 11 is a diagram illustrating an example of a policy storage DB.
  • 11 is a sequence diagram illustrating an example of a process flow for evaluating the authenticity of a user when issuing a card to a mobile terminal.
  • FIG. 2 is a functional block diagram showing a configuration example of an SP server and a mobile terminal.
  • 11 is a sequence diagram illustrating a detailed flow of issuing a card to a mobile terminal.
  • FIG. 11 is a sequence diagram illustrating a detailed flow of issuing a card to a mobile terminal.
  • FIG. 11 is a sequence diagram illustrating a detailed flow of issuing a card to a mobile terminal.
  • FIG. 11 is a sequence diagram illustrating a detailed flow of issuing a card to a mobile terminal.
  • FIG. 11 is a sequence diagram illustrating a detailed flow of issuing a card to a mobile terminal.
  • FIG. FIG. 1 is a configuration diagram showing a seating presence system using an authentication system.
  • FIG. 1 is a diagram illustrating a seating system.
  • FIG. 1 is a diagram showing an example of the configuration of an information processing system to which the present technology is applied.
  • the information processing system 1 has an SP server 11, a mobile terminal (Device) 51, a personal information DB (Cloud) 101, etc.
  • the SP server 11 is, for example, a server (server device) operated by a service provider (SP), and includes a management server that manages the SE chip 61 possessed by the mobile terminal 51.
  • the SP server 11 may be composed of one or more servers, and one server may have one or more functions.
  • the SP server 11 has the function of a management server that manages the SE chip 61 possessed by the mobile terminal 51.
  • the mobile terminal 51 represents one of many terminal devices such as smartphones and tablets owned by many users.
  • the mobile terminal 51 operates under management or control of an operating system (OS) such as Android (registered trademark) or iOS (registered trademark), but the OS of the mobile terminal 51 is not limited to a specific type.
  • the mobile terminal 51 has an SE chip 61 (also called an embedded chip 61).
  • the SE chip 61 is an IC chip that realizes a Secure Element (or SE chip), which is a secure area that is designed to withstand external (e.g., malicious) analysis attacks and includes a memory for securely storing data and a cryptographic processing circuit.
  • the SE chip 61 is a tamper-resistant IC chip that includes a processor composed of an arithmetic circuit such as an MPU (Micro Processing Unit) and a memory for storing various data.
  • the SE chip 61 may be either removable or non-removable from the mobile terminal 51, and may be incorporated as part of an IC chip used for any purpose, such as a SIM (Subscriber Identity Module) card.
  • SIM Subscriber Identity Module
  • the mobile terminal 51 has a terminal application 62 including a program executed on the OS.
  • the terminal application 62 is an application that performs processes such as issuing a card to the mobile terminal 51.
  • the process of issuing a card to the mobile terminal 51 is a process of registering information (also called registration information or personal authentication information) equivalent to the information held by the personal authentication card (ID card) CA, which is a contactless IC card issued by E University 141 in FIG. 1, in the mobile terminal 51 in order to emulate the function of the personal authentication card CA.
  • the registration information (personal authentication information) registered in the mobile terminal 51 includes part or all of the authentication information and the card face information.
  • the recognition information is information for personal authentication stored in the IC chip (SE chip) built into the personal authentication card CA or information equivalent thereto.
  • the card face information is information written on the face of the personal authentication card CA. Note that the authentication information and the face information may overlap in part or in whole, and the registered information (personal authentication information) may not necessarily be classified as either authentication information or face information.
  • the registered information (personal authentication information) is stored in the SE chip 61 of the mobile terminal 51 and in a storage unit (also commonly referred to as memory) other than the SE chip 61, but at least the authentication information is stored in the SE chip 61 of the mobile terminal 51. However, some or all of the personal authentication information other than the authentication information such as face information may be stored in the SE chip 61, or some or all of the authentication information may be stored only in the SE chip 61.
  • the personal information DB 101 is a database that stores (stores) the personal information of each user of the personal authentication card CA (card users such as employees and students).
  • Personal information is information that identifies or identifies an individual (information about an individual).
  • the personal information DB 101 is stored, for example, in a storage unit of a cloud (cloud server).
  • the cloud server is provided as one of the cloud computing services such as Amazon Web Service (registered trademark), Google Cloud Platform (registered trademark), and Microsoft Azure (registered trademark), and the personal information DB 101 stored in the storage unit of the cloud, which is a database provided as one of the services, can be referenced by an external device such as the SP server 11 connected (communication connected) to the Internet through a Web API (Application Programming Interface).
  • the personal information DB 101 is treated as data stored in the cloud.
  • the personal information DB 101 is not limited to being stored in a cloud, but may be stored in a database server, a file server, or any storage device that can be read by the SP server 11.
  • the personal information DB 101 is managed for each group (group or organization) to which the card user of the personal authentication card belongs.
  • companies A to C which operate cloud services, each operate a personal information DB 101.
  • the personal information DB 101 operated by company A manages personal information of company D 121 and university E 141.
  • the number of personal information DBs 101 that can be referenced by the SP server 11 is not limited to three and may be any number, and the type of group may be any group or organization such as a company (enterprise), school, or local government.
  • the personal information DBs 101 of companies A to C are each managed by a different cloud service, but the personal information DBs 101 of multiple groups may be managed by the same cloud service.
  • the personal information DBs 101 of companies A to C may be represented as personal information DBs 101A to 101C, respectively.
  • the group is called an organization.
  • the personal information of card users managed in each organization's personal information DB 101 is provided via a personal information DB in which the organization to which the card user belongs participates.
  • personal information in personal information DB 101A which manages information about D company 121, is provided by D company 121 to the SP server 11.
  • University E 141 uses an issuing printer it owns to issue a personal authentication card CA corresponding to each individual using the information in the organization's personal information DB 101.
  • the issued personal authentication cards CA for each card user are distributed to the card user.
  • the issuing printer is owned by the university, but it is also possible to request issuance from company A, which has access to the personal information DB 101, so there is no particular issue as to who owns the issuing printer, and it is sufficient for it to be held by a company that has access to the personal information DB for operational purposes.
  • the personal authentication card CA has a storage area for writing the name and ID number of the card user (employee, student, etc.).
  • FeliCa registered trademark
  • the file system is composed of system, area, service, and block data.
  • An example of the file system configuration is shown in Figure 11, which will be referred to in the explanation below.
  • a service defines the access method and access authority for block data, and holds an authentication key for confirming the access authority.
  • a block is a memory area divided into 16 bytes for writing and reading from memory, and all user data is stored in the block. Therefore, the name information and ID number mentioned earlier are written in this block. Details of this structure will be omitted in the following explanation, and it will be expressed as writing to memory.
  • a FeliCa (registered trademark) system is a concept higher than the above-mentioned area, and after the relevant system is selected by wireless or wired access, the relevant area node and service node are accessed.
  • the first one is system 0, and multiple systems are created as many times as there is memory. If a wildcard is specified when selecting a system, the first system 0 is selected.
  • a key may be set to access a service specified by FeliCa (registered trademark). If a key is set, mutual authentication with the relevant key in a challenge-response format is required, and a session key is generated from the information shared between them during the mutual authentication. The session key is used to decrypt data encrypted inside the card when reading data from the card, and is used to encrypt data when writing data to the card. If a key is not set, no encryption process is performed and data can be read and written freely. The presence or absence of this key can be set for each access method assigned to the service, so for example, even when accessing the same service, a key can be required to write data but not to read data.
  • the personal authentication card CA personal information (authentication information) such as the name and ID number of the card user (employee, student, etc.) is recorded in the memory area of the chip, and can be freely read depending on the access method settings. Therefore, the ID number of the card user recorded in the personal authentication card CA can be used directly in various systems. For example, in a typical authentication system, the card user holds his/her personal authentication card CA over a reader device, and the card user's ID number and other information are read from the personal authentication card CA (IC chip) using NFC (Near Field Communication), authenticating the card user.
  • NFC Near Field Communication
  • the entrance/exit management system performs authentication using a personal authentication card CA when entering or exiting a room. Based on the authentication result at the time of entry, control is performed to unlock the door and permit entry only to specific card users. Based on the authentication result at the time of exit, management of exit time and presence management, etc. are performed.
  • the work management system for example, performs authentication using a personal authentication card CA at the start and end of work hours. Based on these authentication results, management of the working hours of card users is performed.
  • the attendance management system performs authentication using a personal authentication card CA, for example, when a lecture or the like is attended and left. Based on these authentication results, the attendance status of the card user is managed.
  • the seat usage status is managed by detecting the seating position of the attending card user along with the authentication.
  • the seating position can be detected, for example, by providing a reader device for each seat, or by attaching a tag indicating the position information to each seat, and inputting the seating position information into the attendance management system during authentication.
  • the PC login system operates Windows (registered trademark) automatic logon and single sign-on on the PC based on the user authentication results.
  • the key management system performs authentication using a personal authentication card CA when a key is taken out and returned. Based on the authentication results, the key usage status is managed.
  • the medicine management system manages access to the medicine cabinet, which requires strict management, and can appropriately manage the usage status of medicines by managing the opening and closing of the door by the card user, or by managing the weight difference between before and after use.
  • a closed money management system money information linked to a personal authentication card is managed online, and by holding the card over a reader device along with the amount, the card user is authenticated and an amount is added or subtracted from the ID held by the card, allowing the card to be used like money to purchase items within a specific area such as on campus or within a company, or to use services such as printing on a printer.
  • the process of issuing a card to the mobile terminal 51 is a process of registering registration information (personal authentication information) equivalent to the personal authentication card CA in the mobile terminal 51 in order to emulate the functions of the personal authentication card CA in the mobile terminal 51 as described above.
  • FIG. 2 is a diagram for explaining the flow of issuing a card to the mobile terminal 51.
  • a user U is a card user and owns a personal authentication card CA issued by the E University 141 in FIG. 1.
  • the user U uses the mobile terminal 51 to download a terminal application 62 from an application providing server (marketplace) 181 so that the personal authentication card CA can be emulated on the user's mobile terminal 51.
  • the terminal application 62 is an application for performing a process of issuing a card to the mobile terminal 51 and displaying issued card information.
  • user U starts terminal application 62 and performs input operations and the like according to the instructions of terminal application 62.
  • User U's input operations include enabling NFC on mobile terminal 51 and setting NFC to R (reader)/W (writer) mode.
  • R/W mode is a mode that allows mobile terminal 51 to be used as an NFC-compatible R/W terminal (reader device and writer device).
  • User U holds his/her personal authentication card CA over mobile terminal 51 to have mobile terminal 51 read the memory data and authentication information stored in the IC chip of personal authentication card CA by NFC.
  • User U also inputs information (authenticity information) into mobile terminal 51 that evaluates the authenticity (authenticity of user U) that the person authenticated by personal authentication card CA (authenticated person of personal authentication card CA) and user U themselves are the same person.
  • the authenticity information is, for example, a facial photograph (photographic information) of the user U, and a personal identification password known only to the person authenticated by the personal authentication card CA.
  • the authenticity information is information for so-called identity verification, and will be described in detail later.
  • the terminal application 62 receives as input information the name, company name, and university name, which are also written on the face of the card.
  • the terminal application 62 transmits the recognition information acquired by the input operation by the user U and the authenticity information to the matching server 21 in the SP server 11.
  • the SP server 11 is composed of the matching server 21 and the issuing server 22, which are connected to each other for communication.
  • the matching server 21 compares the data and authentication information in the memory of the personal authentication card CA from the terminal application 62 with the personal information of each card user in the personal information DB 101 to identify the person (person's personal information) authenticated by the data and authentication information in the memory of the personal authentication card CA.
  • the matching server 21 also evaluates the authenticity of the user U (identity verification) based on the personal information of the identified person and the authenticity information from the terminal application 62. In evaluating the authenticity of the user U, it is determined whether the user U and the person identified by the authentication information of the personal authentication card CA (person authenticated by the authentication information) are the same person.
  • the evaluation of the authenticity of the user U may be performed using eKYC (electronic Know Your Customer) technology, and the matching server 21 may perform eKYC processing (identity verification processing), or may use an eKYC business operator server 161 that provides eKYC services as shown in FIG. 2B.
  • the eKYC processing may be performed by the mobile terminal 51 (terminal app 62).
  • the matching server 21 determines that the person identified by the memory data and authentication information of the personal authentication card CA is user U, and writes the registration information (personal authentication information) of user U to the terminal application 62.
  • the registration information (personal authentication information) of user U is some or all of the personal information of the person identified by the authentication information of the personal authentication card CA who is determined to be user U, and is obtained from the personal information DB 101.
  • Writing the registration information (personal authentication information) to the terminal application 62 means that the terminal application 62 writes (stores) the registration information (personal authentication information) from the matching server 21 to a memory unit (normal memory) other than the SE chip 61 of the mobile terminal 51.
  • the registration information (personal authentication information) written to the mobile terminal 51 can be displayed by the user U on the display unit of the mobile terminal 51 using the terminal application 62.
  • the registration information from the matching server 21 may be temporarily written to the memory unit of the mobile terminal 51, and may be updated as appropriate by the user's will or the will of the card issuer, E University 141, with consideration for the user's privacy and the intention of always checking the latest data in the personal information DB 101.
  • the memory unit uses a temporary storage area such as RAM (Read Access Memory) rather than flash memory, and uses a function that erases the data stored in the memory when the terminal is turned off.
  • the data may not be deleted in conjunction with turning off the mobile phone, but may also be registered as data with a time limit. For example, there may be cases where a user is temporarily allowed to enter a building or room, or where authority has been revoked by the issuer, so it is possible to manage the time within the app and erase the data when the time limit has passed, or for the app to erase the data based on a deletion request from the server.
  • the issuing server 22 when the authenticity of user U is confirmed by the verification server 21, the issuing server 22 writes the authentication information of user U to the SE chip 61 of the mobile terminal 51.
  • the issuing server 22 is a management (use) server that manages the SE chip 61.
  • the issuing server 22 is a server that can supply the mobile terminal 51 with a command for writing information to a memory area in the SE chip 61.
  • the authentication information of the user U written in the SE chip 61 is part of the registration information (personal authentication information) of the user U written in the terminal application 62 by the verification server 21, and is authentication information of a person specified by the authentication information of the personal authentication card CA. However, part or all of the authentication information of the user U written in the SE chip 61 may not be included in the registration information (personal authentication information) of the user U written in the terminal application 62 by the verification server 21.
  • the authentication information is written in the SE chip 61 via the terminal application 62. When the authentication information is written in the SE chip 61 of the mobile terminal 51, the card issuance process for the mobile terminal 51 is completed.
  • the user U can emulate the function of the personal authentication card CA on the mobile terminal 51 by enabling the NFC of the mobile terminal 51 and setting it to a card emulation mode.
  • the user U holds the mobile terminal 51 set in the card emulation mode over a reader device of an arbitrary authentication system, and authentication is performed in the same way as when the personal authentication card CA is held over the reader device.
  • Setting the R/W mode and card emulation mode is an explicit operation, and in many cases, both modes can be used automatically from the factory if the NFC function is on. In other words, if you hold a contactless card over a mobile terminal 51 with an NFC function on, the card can be read, and if you hold the mobile terminal 51 over a reader/writer, it can be used as a card.
  • FIG. 3 shows an example of a selection screen on the display of the mobile terminal 51 for emulating a service as an IC card using NFC on the mobile terminal 51.
  • the selection screen 201 in FIG. 3 shows a list of services that can be emulated.
  • the list displays thumbnail images of the card faces corresponding to the services and the service names.
  • the names of the actual services are displayed in the areas marked "Transportation Card (1)", “Identification Card”, "Payment Service (1)” and “Payment Service (2)”, “Point Service (1)” and “Point Service (2)”, and "Coupon Service (1)".
  • the name of an actual transportation card service such as Suica (registered trademark) is displayed in the area marked "Transportation Card (1)".
  • an image (thumbnail image) of the card face of an actual Suica (registered trademark) card is displayed in the thumbnail image of the card face.
  • the names of actual payment services such as nanaco (registered trademark) and Google Pay (registered trademark) are displayed in the notation parts of "Payment Service (1)” and “Payment Service (2)”
  • the names of actual point services such as Mobile d Point Card (registered trademark) are displayed in the notation parts of "Point Service (1)” and “Point Service (2)”.
  • a service named "identification card” that functions as a personal authentication card is displayed as a service that can be emulated.
  • an image of the actual face of the personal authentication card is displayed.
  • the personal authentication card registered as the "identification card” by the card issuance process is set as a service to be emulated by the mobile terminal 51.
  • a detailed information screen 202 for the personal authentication card is displayed.
  • a detailed image of the face of the personal authentication card is displayed on the detailed information screen 202.
  • the detailed information screen 202 can switch between displaying the front and back of the card.
  • the image to be displayed it is desirable to always display the latest information, and as described above, the image may be temporarily stored. In that case, when the user turns off the terminal and then starts it again, the detailed card information including the photo information will be lost.
  • the image is not temporarily stored but is stored in a memory area that is stored even when the terminal is turned off, such as a flash, a digital effect is applied to the card image to make it look deteriorated in order to let the person who is verifying know how new the photo information is and how much time has passed since the card was issued.
  • FIG. 4 shows an example of a digital effect applied to the card image 221 displayed on the mobile terminal 51. For example, FIG.
  • FIG. 4A shows an example in which the card image 221 has been subjected to color adjustment (such as emphasizing the red component) to make it look sepia.
  • color adjustment such as emphasizing the red component
  • FIG. 4B shows an example where the face image 221 is blurred
  • FIG. 4C shows an example where the face image 221 is blurred.
  • the terminal application can determine from the current time that the information is to be displayed and stop the display, or overwrite an "invalid" stamp indicating that the expiration date has passed on the card face image 221 as shown in (E) of FIG. 4, to convey a message that is easy to understand to the person verifying the information. Conversely, if the information is within the expiration date, a clear message may be displayed to the person verifying the information by explicitly displaying "valid.”
  • the personal authentication card is set as a service to be emulated on the mobile terminal 51 and the NFC of the mobile terminal 51 is set to card emulation mode (this includes the case where card emulation is enabled by default), by holding the mobile terminal 51 over a reader device of the authentication system, authentication in the authentication system is performed in the same way as when an actual personal authentication card CA is held over the reader device.
  • the SP server 11 (verification server 21) manages the registration information (personal authentication information) of the card user of the personal authentication card CA as shown in the template image 211 on the right side of FIG. 5.
  • the template image is a diagram showing various information included in the registration information (personal authentication information) arranged two-dimensionally, and does not necessarily match the arrangement of various information written on the actual card.
  • the intention of managing with a template is that the SP server 11 or the terminal application 62 already has data that is used uniformly by the majority, eliminating the need for unnecessary data updates. Therefore, the contents described in this template are merely an example, and depending on the template decided by the issuer, information other than information that is individualized by personal information may already be included as fixed information in the template.
  • the SP server 11 acquires from the personal information DB 101 and manages the registration information (personal authentication information) of the card user required for issuing the personal authentication card emulated by the mobile terminal 51.
  • the registration information personal authentication information
  • the registration information may be generated in advance and stored in a storage unit of the SP server 11, regardless of the card issuing process for the mobile terminal 51, or may be generated by acquiring personal information from the personal information DB 101 as necessary.
  • FIG. 5 shows an example of registration information (personal authentication information) when an identification card (personal authentication card) that proves that the card user belongs to a specific university, i.e., a student ID card, is emulated on a mobile terminal 51.
  • the registration information (personal authentication information) of the card user includes information (data) required to personalize the card face, information (data) included in the template, and information (data) that is automatically entered.
  • the information required to personalize the card face is information that differs depending on the card user, and is information required to identify the card user.
  • the information required to personalize the card face is information that is placed in the rectangular area with no background in the template image 211 in FIG. 5.
  • the information required to personalize the card face includes information related to the card user's student number, year of enrollment, name (hiragana, alphabet), date of birth, department name, and photograph.
  • the information included in the template is information that is commonly used as registration information (personal authentication information) for card users who belong to the same organization.
  • the information included in the template is information in which the background pattern is placed in the rectangular portion of the horizontal line in template image 211 in Figure 5.
  • the information included in the template includes information on the name, school emblem, and location of the university to which the card user belongs, as well as information on the background image of the card face. Note that the information on the background image of the card face is placed as information on the overall background image within template image 211.
  • Automatically entered information is information that is automatically set by the SP server 11, etc., when issuing a personal authentication card emulated by a mobile terminal.
  • Automatically entered information is information in which the background pattern is placed in the rectangular portion of the vertical lines in the template image 211 in FIG. 5.
  • Automatically entered information includes the issue date and expiration date of the emulated personal authentication card.
  • the SP server 11 manages this registration information (personal authentication information) by writing it in, for example, JSON (JavaScript (registered trademark) Object Notification) format.
  • JSON JavaScript (registered trademark) Object Notification
  • FIG. 5 mainly shows card face information among the registration information (personal authentication information)
  • authentication information such as an ID number that differs for each card user is also managed by the SP server 11.
  • FIG. 6 is a diagram illustrating an example of a face image on the mobile terminal 51 of a personal authentication card emulated by the mobile terminal 51.
  • a face image 221 is a face image on the mobile terminal 51 when a student ID card (identification card) is emulated as a personal authentication card by the mobile terminal 51 as illustrated in FIG. 5.
  • the face image on the mobile terminal 51 is an image representing the face of a personal authentication card emulated by the mobile terminal 51 when displayed on the display unit of the mobile terminal 51.
  • the example of the face image 221 in FIG. 6 shows a case where face information is displayed in a layout almost similar to that of the template image 211 in FIG. 5.
  • the original data may be data received from the SP server or data read by a terminal application from the SE chip 61 of the mobile terminal 51. Since it is not appropriate for the data read from the SE chip 61 via a non-contact method to be inconsistent with the data of the face image displayed on the screen, one method is to link them. On the other hand, it is also conceivable that the terminal application 62 could check for such mismatches and prompt the user to re-obtain the card image if there is a lack of consistency with the original data.
  • FIG. 7 to 10 are diagrams showing examples of the description of the registration information (personal authentication information) of each card user managed by the SP server 11.
  • the SP server 11 describes and manages the registration information (personal authentication information) of each card user, for example, in JSON format.
  • FIG. 7 is an example of the "information included in the template" described in FIG. 4 described in JSON format.
  • FIG. 7(A) is an example of the description in JSON format, and
  • FIG. 7(B) is a diagram showing a schematic representation of the description example in JSON format of FIG. 7(A). According to this, the name of the university to which the card user belongs, the school emblem (image file name), and the location information are described in JSON format as the "information included in the template".
  • FIG. 7 is an example of the "information included in the template”.
  • FIG. 8 is an example of the "information necessary for individualizing the card face" and the "information to be automatically entered” described in FIG. 5 described in JSON format.
  • FIG. 8(A) is an example of the description in JSON format
  • FIG. 8(B) is a diagram showing a schematic representation of the description example in JSON format of FIG. 8(A).
  • the "information necessary to personalize the card” and “information to be entered automatically” include the card user's student number, year of enrollment, name, date of birth, gender, department name, and photo (image file name), as well as information regarding the issue date and expiration date of the emulated personal authentication card, all written in JSON format.
  • FIGs 7 and 8 shows a case where the SP server 11 manages the face information of the card user's registration information (personal authentication information) by dividing it into information for each organization to which the card user belongs and information for each card user.
  • Figure 9 shows an example of the face information of the registration information (personal authentication information) that the SP server 11 sends to the mobile terminal 51 when issuing a card to the mobile terminal 51, written in JSON format.
  • Figure 9 (A) is an example of the description in JSON format
  • Figure 9 (B) is a diagrammatic representation of the description example in JSON format of Figure 9 (A). According to this, in Figure 9, information (face information, etc.) including both the information in Figure 7 and the information in Figure 8 is written in JSON format.
  • FIG. 10 shows an example of authentication information in JSON format, which is part of the registration information (personal authentication information) that the SP server 11 transmits to the mobile terminal 51 when issuing a card to the mobile terminal 51.
  • FIG. 10A shows an example of the description in JSON format
  • FIG. 10B shows a diagram of the description example in JSON format of FIG. 10A.
  • block data which is authentication information stored in the SE chip 61 of the mobile terminal 51, is described in JSON format.
  • the file system defined by FeliCa is composed of a system, an area, a service, and block data.
  • the system, the area, the service, and the block data are each managed in a specific data size, and the unit of the data size is called a block, and the data size of one block is 16 bytes.
  • the service defines the access method and access authority for the block data, and holds an authentication key for confirming the access authority.
  • the area is used to manage block data hierarchically, and a hierarchical structure is possible.
  • the area one level below an area is called a child area, and the area one level above is called a parent area.
  • An area has the right to create a child area, and the right to register a service and change a key for a service at the next lower level.
  • a single physical card (chip) can hold multiple logical cards, and this logical card is called a system.
  • FIG. 11 is a diagram illustrating authentication information for personal authentication stored in the SE chip 61 of the mobile terminal 51.
  • area 0 is created at the next lower level of system 0
  • area X is created as a child area at the next lower level of area 0.
  • Service Y is created at the next lower level of area X, and block data consisting of three blocks is written as authentication information at the next lower level of service Y.
  • System 0, area 0, area X, and service Y each hold an authentication key for confirming the access authority to each of them.
  • a system, area, or service may hold, as keys, one or both of the following: a key for AES (Advanced Encryption Standard), which is a common key cryptography method (AES key), and a key for DES (Data Encryption Standard), which is a common key cryptography method (DES key).
  • AES Advanced Encryption Standard
  • DES Data Encryption Standard
  • the block data in FIG. 11 is authentication information written in the JSON format in FIG. 10.
  • the authentication information in FIG. 10 is three blocks of block data with a dataID of 00010203.
  • the SP server 11 transmits the information in FIG. 10 to the mobile terminal 51, and writes the block data, which is the authentication information, to the system in the SE chip 61, thereby issuing a card to the mobile terminal 51.
  • step S1 information (authentication information) read from the personal authentication card CA owned by the user (card user) is provided to the terminal application 62 of the mobile terminal 51.
  • the user sets the NFC of the mobile terminal 51 to the R/W mode and holds the personal authentication card CA over the mobile terminal 51.
  • step S2 terminal application 62 requests SE chip 61 of mobile terminal 51 to obtain information stored in SE chip 61, and the information from SE chip 61 is obtained by terminal application 62.
  • the user uses terminal application 62 to fill in the application form displayed by terminal application 62.
  • the format included in the application form includes applicant information such as name, date of birth, age at the time, and address, and if the personal authentication card CA in question is a student ID card, information on the issuer issuing application permission such as university name, department name, and year, and information indicating the relationship with the issuer, thereby entering information to determine whether the applicant is a valid applicant. If it is an employee ID card, it is expected that the applicant will apply for the company name, department name, etc. in addition to the name.
  • users when applying, users may be required to enter information related to authentication, such as IDs and passwords that have been distributed in advance, IDs distributed to individuals, two-dimensional codes (QR Code (registered trademark), etc.), or IDs that can only be obtained by students who have attended a specific orientation each year or a specific year, two-dimensional codes, and information distributed by mail on the premise of identity verification, in order to identify themselves or their groups, clubs, laboratories, seminars, and other organizations.
  • identity verification is performed by using a FIDO (Fast Identity Online) authenticator or authenticator in conjunction with a mobile device to which the user has registered biometric authentication or ID in advance.
  • FIDO Fast Identity Online
  • Communication between the device and the authenticator is performed by physical contact or contactless connection, such as BLE (Bluetooth (registered trademark) Low Energy), WiFi (Wireless Fidelity), USB communication, or NFC.
  • BLE Bluetooth (registered trademark) Low Energy
  • WiFi Wireless Fidelity
  • NFC NFC
  • the authenticator can be connected to another laptop, a browser can be opened, and identity verification can be performed for a specific site using the authenticator, and the results of identity verification can be shared from the laptop to the mobile phone by capturing the two-dimensional code displayed on the browser opened on the laptop with the mobile phone camera.
  • This method uses caBLE (cloud assisted Bluetooth (registered trademark) Low Energy), a technical method disclosed by the FIDO Alliance, as an example, and is not limited to this as a method of linking authentication with other devices using an authenticator.
  • a private key contained in the authenticator is used to sign a unique string of information that is temporarily displayed on the application form or presented to the authenticator, and the signature on that string is verified using a public key held in advance in personal information DB 101. If this verification is successful, identity verification has been performed.
  • biometric authentication methods implemented by the authenticator, including fingerprints, faces, irises, palm veins, ear shapes, and signatures, but the ones listed in this specification are merely typical examples of biometric authentication and are not intended to limit the methods in any way.
  • step S3 based on the information acquired in steps S1 and S2, the terminal application 62 sends to the matching server 21 a request to acquire data necessary for card issuance (acquisition of registration information (personal authentication information) from the personal information DB 101), and application data (information identifying the organization to which the user belongs, information identifying the user, etc.) for the matching server 21 to request acquisition of the user's registration information (personal authentication information) from the personal information DB 101.
  • acquisition of registration information personal authentication information
  • application data information identifying the organization to which the user belongs, information identifying the user, etc.
  • step S4 the verification server 21 requests the issuing server 22 to start the card issuance process. As a result, the issuing server 22 starts the card issuance process.
  • step S5 the issuing server 22 notifies the verification server 21 that the card issuance process has started.
  • step S6 the verification server 21 requests the terminal application 62 to start the card issuance process.
  • step S7 the terminal application 62 issues an issuance request to the MFC (Mobile FeliCa (registered trademark) Client) 63, which is a client for controlling the SE chip 61.
  • MFC Mobile FeliCa (registered trademark) Client
  • This client (MFC 63) for controlling the SE chip 61 may be built into the OS of the mobile terminal 51 at the time of shipment, or, with the user's consent, it is an application that can be downloaded from a marketplace and built into the terminal later. If it is built into the OS at the time of shipment, it may be positioned as middleware and may be given some strong authority in advance as a system application, and in this case, access authority to the SE chip 61 is granted. In the implementation form, some SDKs may be stored as functions in the middleware, and the applications may call them to access the SE chip 61. Alternatively, the access control function to the SE chip 61 of the mobile terminal may be enabled in advance at the time of shipment from the factory so that the corresponding middleware or application can access the SE chip 61.
  • this function (this client) is called MFC.
  • the MFC 63 is middleware for exchanging various data with the SE chip 61, and is part of the functions that the terminal application 62 calls via the API. Since the MFC 63 can be commonly called and used by other applications via the API, it can be considered as a general-purpose library or utility.
  • the MFC 63 starts the card issuance process (the process of registering card face information).
  • step S8 an issuance request is sent from the MFC 63 to the issuing server 22.
  • step S9 the issuing server 22 sends an issuance request to the matching server 21.
  • steps S10 and S11 are carried out in parallel with steps S7 to S9.
  • step S10 application data is sent from the matching server 21 to the personal information DB 101 to request acquisition of the user's registered information (personal authentication information).
  • FIG. 12 illustrates an example in which application data is sent from the matching server 21 to the personal information DB 101C of Company C, but the application data is sent to the personal information DB 101 of the organization to which the user (card user of the personal authentication card CA) belongs. If the user is a student, the application data may be, for example, the university code and student number of the user.
  • the personal information DB 101 transmits the registration information (personal authentication information) of the user (card user of the personal authentication card CA) to the matching server 21 based on the application data in step S10.
  • the registration information (personal authentication information) includes face information (individual face information) and authentication information (block data) as described above.
  • the face information (individual face information) is information described in JSON format, for example, divided into "information included in the template" in FIG. 7 and "information required for individualizing the face” and "information entered automatically” in FIG. 8.
  • the face information (individual face information) is information described in JSON format, including face information in both FIG. 7 and face information in FIG. 8, as in FIG. 9.
  • the authentication information (block data) is information described in JSON format, for example, as in FIG.
  • block data which is authentication information
  • the JSON format used is merely an example, and is adopted because it is an excellent format for sharing textual information that conveys a specific meaning. If the opposing personal information DB 101 responds in CSV (Comma Separated Values) format and the receiving matching server 21 can properly recognize the order of the data, this format is acceptable. Any format that can be understood by the receiving side in advance, such as XML format or text format, or information that can be identified by an extension or an identifier included at the beginning of the file, and other mutually understandable formats, can be supported.
  • CSV Common Separated Values
  • the data is not textual information but an image displayed as a card face, such as a JPEG image, on the DB, it is also possible to send the image to the matching server 21. If it is displayed as is, or the text portion of the image data can be recognized and converted into text data using an OCR (Optical Character Reader) function.
  • OCR Optical Character Reader
  • step S12 is performed, and in step S12, the face information (individual face information) acquired in step S11 is provided from the matching server 21 to the issuing server 22 in JSON format.
  • the issuing server 22 stores the face information within the server.
  • step S13 the face information (individual face information) from the issuing server 22 is provided from the matching server 21 to the MFC 63 in JSON format.
  • step S14 the issuing server 22 requests block data from the matching server 21.
  • step S15 the matching server 21 sends a card issuance request together with the block data to the issuing server 22.
  • step S16 the issuing server 22 sends the block data from the matching server 21 to the MFC 63.
  • step S17 an exchange is carried out between the issuing server 22 and the SE chip 61 to register the block data in the SE chip 61, and the block data is registered in the SE chip 61.
  • step S18 the SE chip 61 notifies the MFC 63 that the card has been issued.
  • step S19 the MFC 63 notifies the issuing server 22 that the card has been issued.
  • step S20 the issuing server 22 notifies the matching server 21 that the card has been issued.
  • step S21 the matching server 21 notifies the issuing server 22 that the card issuance process has been completed.
  • step S22 the issuing server 22 notifies the MFC 63 that the card issuance process has been completed.
  • the MFC 63 registers (stores in a storage unit other than the SE chip 61 of the mobile terminal 51) the card face information (individual card face information) acquired in step S13, and ends the card face information registration process.
  • step S23 the MFC 63 notifies the terminal application 62 that registration of the card face information has been completed. This completes the card issuance process.
  • ⁇ Customer policy when issuing a card to the mobile terminal 51> Although omitted in the flow of card issuance in FIG. 12, when a card is issued to a portable terminal 51, a process is performed to evaluate the authenticity of the user U who is the owner of the portable terminal 51 (portable terminal 51 where a card is issued) in which a personal authentication card is emulated.
  • the user U is also an applicant who applies for a card to be issued to the portable terminal 51.
  • the evaluation of the authenticity of the user U (applicant) is an evaluation of the authenticity of whether the user U (applicant) of the portable terminal 51 is the same person as the card user authenticated by the personal authentication card (original personal authentication card CA) emulated by the portable terminal 51.
  • the evaluation of the authenticity of the user U (applicant) is an identity confirmation of whether the user U (applicant) who is the owner of the portable terminal 51 is the card user authenticated by the personal authentication card (original personal authentication card CA) emulated by the portable terminal 51.
  • the method of evaluating the authenticity of a user U can be set according to the policy of each customer (organization) that issues the personal authentication card CA.
  • the methods of evaluating authenticity can be classified into possession authentication, knowledge authentication, biometric authentication, binding between the applicant and the card in possession, and binding between the applicant and the photo in the personal information DB.
  • Possession authentication is a process of confirming whether the personal authentication card in the applicant's possession and the item given to the applicant are legitimate.
  • Knowledge authentication is a process of confirming whether the applicant can correctly enter authenticated information stored in the personal information DB, etc. in the application field (present as application data).
  • Binding between the applicant and the card in possession is a process of confirming whether the applicant's own face matches the face printed on the card when a face photo or the like is printed on the face of the personal authentication card in the applicant's possession.
  • Binding between the applicant and the photo in the personal information DB is a process of verifying whether the applicant's own face matches the face photo of the applicant stored in the personal information DB and confirming whether they match.
  • biometric authentication a device of some kind is required in the user's hand, and a well-known example is the authenticator defined by the FIDO Alliance.
  • UAF Universal authentication Framework
  • U2F Universal 2nd Factor
  • UAFs have a function as a platform authenticator built into the mobile phone. This technology is applied when a site can be viewed using fingerprint or face recognition on an iPhone (registered trademark) or Android (registered trademark) mobile phone.
  • an authenticator the public key side of the key pair held in the authenticator must be shared with the application destination in advance.
  • items used for possession authentication include driver's licenses, My Number cards, and passports issued by public institutions such as the government. By applying these and comparing them with the information on the card or with information that has already been authenticated, identity verification can be realized.
  • the authenticity of user U can be evaluated using any one of these evaluation methods or a combination of multiple methods.
  • the type 1 authenticity evaluation method is a method based on authenticity confirmation of a possessed card.
  • authenticity confirmation of a possessed card authenticity determination is performed using key information attached to the personal authentication card possessed by the applicant and data stored on that personal authentication card.
  • a session key is created using a common key (DES key, AES key, etc.) shared in advance by a challenge-response method using a mutual authentication command, and it is confirmed whether the data encrypted and output by the personal authentication card can be correctly decrypted by the SP server.
  • the possessed card can include a personal authentication card issued by a public institution, such as a driver's license or a My Number card.
  • a personal authentication card issued by a public institution such as a driver's license or a My Number card.
  • the password check in this case is performed locally by the user, it is possible to forge whether it was really successful. Therefore, in the case of My Number cards, it is necessary to use a method that can check the authenticity on the server side by reading out the user authentication electronic certificate that can be used after password check.
  • Type 2 authenticity evaluation method is a method by matching ID and PW (password).
  • ID and PW ID or PW
  • ID and PW are assumed to be properly issued to the individual through identity verification such as mailing with identity verification, verification by other public institutions, or face-to-face verification or online authentication such as distribution of public identification such as My Number Card.
  • ID and PW for accessing My Portal Site in the company or on campus may be reused for this application.
  • Type 2 authenticity evaluation method corresponds to knowledge authentication. Generally, when ID and password are adopted, the same password may be used on other sites, and it is considered that it is vulnerable to "password list attack" that applies a list of passwords leaked in the past to an attack.
  • ID in the case of universities and companies, a unique number is often given, and the number is assigned collectively from the year of admission or the year of joining the company in alphabetical order, alma mater, or by region, so the situation may be different from that of general sites that use email addresses as ID.
  • ID in recent years, there is a high possibility that individual IDs are forgotten, and in many cases, email addresses are used. In such cases, a password list attack is considered to be an effective means of attack.
  • the authenticity evaluation method of Type 3 is a method by matching two-dimensional code information.
  • a two-dimensional code is a code that has information in two dimensions, such as a QR code (registered trademark).
  • the two-dimensional code in this method is assumed to be a two-dimensional code that has been properly issued to the individual through face-to-face or online verification, such as mailing with identity verification, verification by other public institutions, or distribution of public identification such as My Number cards, as a prerequisite for identity verification.
  • the two-dimensional code in this method is not a two-dimensional code used by unspecified people that is printed on magazines or flyers.
  • the authenticity evaluation method of Type 3 corresponds to knowledge authentication of whether or not the code is known, but since the applicant cannot remember the two-dimensional code, it corresponds to whether or not the applicant possesses an item to which the code is assigned, so it is an authenticity evaluation method that is closer to possession authentication.
  • the authenticity evaluation method of Type 4 is a method based on matching the application contents.
  • the authenticity evaluation method of Type 4 corresponds to knowledge authentication.
  • Knowledge authentication is a process to confirm whether the applicant can correctly apply the authenticated information stored in the personal information DB as described above.
  • additional information such as the name of the organization to which the applicant belongs (university name or company name) can be used as information to search the DB when deriving the application contents for card issuance. Therefore, if the matching contents are not registered in the personal information DB 101, or if there is a partial mismatch between the search results and the application contents, it may not be possible to authenticate the person as the person. In particular, a more reliable matching can be achieved by matching information that is not written on the face of the personal authentication card as the application contents.
  • the authenticity evaluation method of Type 5 is a method for implementing eKYC. If the applicant possesses a personal authentication card with a face photo or the like printed on the face of the card, eKYC confirms whether the applicant's own face matches the face printed on the face of the card. In this case, this corresponds to an authenticity evaluation method by binding between the applicant and the card possessed. Since the binding between the possessed item used for possession authentication and the applicant can be confirmed, higher security can be realized.
  • the face of the applicant is compared with the face photo managed in the personal information DB 101, and eKYC confirms whether they match. Note that this method can be adopted even if the applicant possesses a personal authentication card with a face photo printed on it. In this case, this corresponds to an authenticity evaluation method by binding between the applicant and the photo in the personal information DB 101. Since the authenticity of the applicant can be confirmed, higher security can be realized.
  • a face photo or the like for example, an ID, a two-dimensional code, or a personal authentication card without a face photo
  • Type 6 authenticity assessment methods use an authenticator, for example, an authenticator defined by the FIDO Alliance is used to verify identity.
  • the FIDO Alliance defines devices that support the Universal authentication Framework (UAF) and devices called Universal 2nd Factor (U2F), and some UAFs are equipped with a function as a platform authenticator in a mobile phone.
  • UAF Universal authentication Framework
  • U2F Universal 2nd Factor
  • identity verification linked to biometric authentication can be realized.
  • the applicant must register biometric information on the mobile phone that he or she possesses.
  • the type of biometric information varies depending on the biometric authentication method supported by the mobile phone, and includes fingerprint authentication, face authentication, and iris authentication. In this case, the public key of the key pair held in the mobile phone must be shared with the site to be accessed.
  • the authenticity evaluation methods of types 1 to 6 as shown in Figure 13 are independent of each other, so by assigning bits as shown in Figure 14, each bit can be given a meaning and the authenticity evaluation method to be performed according to the customer policy can be expressed as a numerical value (assigned value). For example, when the assigned value is 0x01, the authenticity check of the card in possession of type 1 is performed. When the assigned value is 0x03, the authenticity check of the card in possession of type 1 (0x01) and the ID/PW check of type 2 (0x02) are performed.
  • the assigned value represents the sum of the assigned values of the authenticity check of the card in possession of type 1 (0x01), the ID/PW check of type 2 (0x02), the check of the application contents and personal information DB of type 4 (0x08), and the eKYC implementation of type 5 (0x10), and the authenticity evaluation methods of types 1, 2, 4, and 5 are performed.
  • the assigned value represents the sum of the assigned values of the authenticity check of the card in possession of type 1 (0x01), the ID/PW check of type 2 (0x02), the check of the application contents and personal information DB of type 4 (0x08), and the eKYC implementation of type 5 (0x10), and the authenticity evaluation methods of types 1, 2, 4, and 5 are performed.
  • the order of assignment and the method of authenticity evaluation of the user (identity verification) as shown in Figures 13 and 14 are merely examples, and the present technology is not limited to the examples of Figures 13 and 14.
  • the policy storage DB may be included in the SP server 11, or may be included in a device that can communicate with the SP server 11.
  • the policy storage DB is set with an identification code, and a customer name (organization name), customer policy, and cloud service (name) are recorded in association with each identification code.
  • the customer name represents the organization to which the user U of the mobile terminal 51 for which the card is issued belongs, and represents the organization that issued the personal authentication card CA owned by the user U (the organization that requested the issuance).
  • the customer policy represents a policy regarding matching that the customer (organization) desires as a security policy when issuing a card to the mobile terminal 51.
  • the allocation value of FIG. 14 that indicates the method of evaluating the authenticity of the user U to be performed correspondingly is recorded as the customer policy.
  • the cloud service represents the service name of the cloud server in which the personal information DB 101 of the card user belonging to the customer (organization) is stored.
  • the customer policy for that identification code is applied when issuing a card for that customer name, and an authenticity evaluation (identity verification) of user U corresponding to the customer policy is performed.
  • the security policy for card issuance (issuance security policy) is entrusted to the cloud service in which the customer's personal information DB is stored.
  • the customer policy for that identification code is applied to perform an authenticity evaluation (identity verification) of user U corresponding to the customer policy. If both the customer policy and the cloud service policy are left blank, the default policy held by the matching server 21 is applied. This does not mean that there is no policy, but rather that the matching server guarantees a minimum policy.
  • Online seat management is an example of the usage form of an authentication system using NFC. Online seat management is a system that checks whether a user is seated using a personal authentication card emulated by a mobile terminal 51 or an actual personal authentication card CA after a card is issued, and can be used both offline and online.
  • card authentication is performed when the mobile terminal 51 reads the NFC tag attached to an actual desk, or when the personal authentication card CA is held up to a reader/writer set up in a classroom or the like, or when the personal authentication card CA is held up to a mobile phone reader/writer, or when the personal authentication card emulated by the mobile terminal 51 is connected to an online verification server, and the time when the user's authenticity evaluation (the authenticity judgment of the card held and the implementation of eKYC) was performed is recorded as log information in the verification server.
  • the log information on the verification server is shared. The method for evaluating the authenticity of users in this type of online seat management will also be recorded as a customer policy.
  • Fig. 16 is a sequence diagram illustrating the process flow of evaluating the authenticity of a user when issuing a card to a mobile terminal 51.
  • the terminal application 62 of the mobile terminal 51 requests the personal authentication card CA owned by the user (card user) to read information (authentication information, etc.) of the personal authentication card CA.
  • the user sets the NFC of the mobile terminal 51 to R/W mode and holds the personal authentication card CA over the mobile terminal 51.
  • the information of the personal authentication card CA is transmitted from the personal authentication card CA to the terminal application 62.
  • organization information (university code, company code, etc.) identifying the organization to which the card user of the personal authentication card CA belongs is transmitted from the terminal application 62 to the verification server 21 of the SP server 11.
  • the matching server 21 inquires of the policy storage DB 232 to obtain the customer policy of the organization to which the card user belongs.
  • the policy storage DB 232 is a device that stores data of a policy storage DB such as that shown in FIG. 15, and may be a memory unit possessed by the matching server 21, or an external device such as a cloud server that is communicatively connected to the matching server 21.
  • the data in the policy storage DB 232 may be updated as appropriate according to the security policy obtained from the personal information DB 101 or the security policy inquired of the customer (organization).
  • the matching server 21 determines the method of evaluating the authenticity of the user to be implemented based on the customer policy.
  • step S55 the verification server 21 requests the terminal application 62 to execute a secure read.
  • Execution of a secure read refers to encryption processing including mutual authentication with the key assigned to the card, and the subsequent reading of data by an encryption command.
  • step S56 the requested secure read is executed by exchanging information between the terminal application 62, the personal authentication card CA, the issuing server 22, etc., in accordance with the request from the verification server 21. (A detailed flow is described in FIG. 20.)
  • step S57 the verification server 21 causes the terminal application 62 to execute eKYC. However, if the customer policy selected in step S54 does not request the execution of the authenticity evaluation method of type 5 in FIG. 13, eKYC is not executed.
  • the eKYC process obtains information from the user using the terminal application 62.
  • the card to be held up and the subject to be photographed change depending on the content of the eKYC.
  • photos or videos of multiple cards taken at different angles may be requested, or facial photos may include photos of the person looking to the side, with the corners of the mouth turned up, or with the right ear in view to check whether the person has depth.
  • the eKYC matching process itself may be performed by a device other than the terminal app 62, or may be performed by the matching server 21, the issuing server 22, etc.
  • step S58 the matching server 21 requests the personal information DB 101 for registration information (personal authentication information).
  • the user's registration information includes card face information (individual card face information) and authentication information (block data).
  • step S59 the personal information DB 101 provides the user's registration information (personal authentication information) to the matching server 21.
  • step S60 the matching server 21 provides the user's registration information (personal authentication information) to the terminal application 62.
  • step S61 the terminal application 62 provides the MFC 63 with a card issuance request and block data.
  • step S62 commands and the like for card issuance are exchanged between the MFC 63 and the SP server 11, and between the MFC 63 and the SE chip 61 and the issuing server 22.
  • the block data is stored in the SE chip 61, and the card is issued.
  • step S63 the MFC 63 notifies the terminal application 62 that the card has been issued.
  • step S64 the terminal application 62 expands the card face information to generate and save image data of the face of the personal authentication card.
  • FIG. 17 is a functional block diagram showing a configuration example of the SP server 11 and the mobile terminal 51.
  • FIG. 17 shows the SP server 11, the mobile terminal 51, and the personal information DB 101 shown in FIG. 1 and FIG. 2.
  • the SP server 11 includes the matching server 21 and the issuing server 22 shown in FIG. 2.
  • the SP server 11 may be composed of a single server (computer) or two or more servers (computers).
  • the SP server 11 has a matching processing unit 231, a policy storage DB 232, a communication unit 233, an issuing processing unit 234, and the like.
  • the matching processing unit 231, the policy storage DB 232, the communication unit 233, and the issuing processing unit 234 are arranged in.
  • the matching processing unit 231 When issuing a card to the mobile terminal 51, the matching processing unit 231 identifies (identifies) the card user based on the authentication information acquired from the actual personal authentication card CA, and acquires the registration information (personal authentication information) of the card user from the personal information DB 101.
  • the matching processing unit 231 also performs processing such as evaluating the authenticity of the user U who owns the mobile terminal 51, that is, the user U who is the applicant who applies for the issuance of a card to the mobile terminal 51.
  • the matching processing unit 231 refers to the policy storage DB 232 and determines the method of evaluating the authenticity of the user U according to the customer policy as described above.
  • the evaluation of the authenticity of the user U may be performed by the mobile terminal 51 or by an external device other than the SP server 11 and the mobile terminal 51.
  • the matching processing unit 231 acquires the result of the evaluation of the authenticity of the user U performed by the external device such as the mobile terminal 51.
  • the verification processing unit 231 continues the card issuance process only if the authenticity of the user U is confirmed, and stops the card issuance process if the authenticity is denied.
  • the policy storage DB 232 stores information on a customer policy (authenticity evaluation method to be implemented) that is predetermined for each customer (organization) that has issued a personal authentication card CA as described above, or for each cloud service used in the personal information DB 101, as shown in FIG. 15.
  • the policy storage DB 232 may be included in a device different from the SP server 11.
  • the communication unit 233 controls communication between the SP server 11 and an external device such as the mobile terminal 51.
  • the communication may be either wireless or wired, and the communication method is not limited to a specific method.
  • the issuance processing unit 234 When issuing a card to the mobile terminal 51, the issuance processing unit 234 obtains the registration information (personal authentication information) of the user U (card user) from the matching processing unit 231 to be stored in the memory unit or SE chip 61 of the mobile terminal 51, and transmits it to the mobile terminal 51 via the communication unit 233.
  • the mobile terminal 51 has an SE chip 61, a DH 241, an antenna 242, and a CLF 243.
  • the SE chip 61 has been described above, so a detailed description will be omitted.
  • the DH 241 is a device host, and includes one or more processors, such as an MPU or other arithmetic circuit.
  • the processor in the DH 241 executes middleware and applications (terminal application 62, etc.) to perform various processes.
  • the DH 241 also includes a communication unit (communication device), and controls communication with external devices such as the SP server 11.
  • the antenna 242 is an antenna for NFC.
  • the CLF 243 is a Contactless Front End, and controls communication via the antenna 242 by NFC.
  • the CLF 243 controls, for example, data transmission and reception with an IC card (such as a personal authentication card CA) held over the antenna 242, and data transmission and reception between the SE chip 61 and an external reader/writer device.
  • the mobile terminal 51 may also be equipped with a ROM (Read Only Memory), a RAM (Random Access Memory), a storage unit, an operation unit, a display unit for displaying various screens on a display screen, etc.
  • step S101 the user U requests the mobile terminal 51 to start the mobile terminal 51 and to connect to the Internet (communication connection).
  • step S102 the user U requests the marketplace 181 to download the terminal application 62.
  • step S103 the marketplace 181 downloads the terminal application 62 to the mobile terminal 51.
  • step S104 the mobile terminal 51 installs the terminal application 62.
  • step S105 the user U operates the mobile terminal 51 to start the terminal application 62.
  • step S106 the mobile terminal 51 starts the terminal application 62.
  • step S107 the user U registers user information to the terminal application 62.
  • step S108 the user U touches the mobile terminal 51 with the contactless IC card (holds it over the mobile terminal 51) to the personal authentication card CA.
  • step S109 a read command is sent from the terminal application 62 to the personal authentication card CA.
  • step S110 response data is returned from the personal authentication card CA to the terminal application 62.
  • step S111 information (response data) is sent from the terminal application 62 to the matching server 21 of the SP server 11.
  • step S112 the matching server 21 confirms the information and extracts the identification information.
  • step S113 the matching server 21 checks the customer policy against the policy storage DB 232.
  • step S114 the policy storage DB 232 returns the customer policy to the matching server 21.
  • step S115 the matching server 21 notifies the terminal application 62 of the customer policy.
  • step S116 the terminal application 62 checks the customer policy.
  • step S121 the terminal app 62 requests user U to "take a photograph" as a case where eKYC is required.
  • step S122 the user U issues an operation to the terminal app 62 to press a photo-taking button.
  • step S123 the terminal app 62 displays photo data to user U and requests "movements such as turning one's head or smiling.”
  • step S124 a photo of expected quality is provided by user U to the terminal app 62.
  • step S131 the terminal app 62 requests user U to input "ID/PW" as a case where ID/PW input is required.
  • step S132 the user U inputs the ID/PW to the terminal app 62 using an operation unit such as a keypad.
  • step S133 the terminal application 62 displays the ID/PW (marked with *) to the user U, and asks for confirmation of "send.”
  • step S134 the user U instructs the terminal application 62 to press the send button.
  • step S141 the terminal application 62 requests the user U to "wave the card” again, since mutual card authentication is required.
  • step S142 the user U touches (waves) the contactless IC card (personal authentication card CA) to the mobile terminal 51.
  • step S143 the terminal application 62 requests the matching server 21 to send an access URL.
  • step S144 the matching server 21 requests the issuing server 22 to send an access URL for secure reading.
  • step S145 the issuing server 22 returns the access URL to the matching server 21.
  • step S146 the matching server 21 returns the access URL to the terminal application 62.
  • step S147 the terminal application 62 sends the access URL for cure reading to the MFC 63.
  • step S148 the MFC 63 connects to the issuing server 22 using the access URL.
  • step S149 the issuing server 22 generates a command for reading based on the access content.
  • step S150 the issuing server 22 transmits a command for reading to the MFC 63.
  • step S151 the MFC 63 transmits a command for reading to the personal authentication card CA.
  • step S152 response data is transmitted from the personal authentication card CA to the MFC 63.
  • step S153 the response data is transmitted from the MFC 63 to the issuing server 22.
  • step S154 the issuing server 22 decrypts the response data.
  • step S155 the issuing server 22 transmits the decrypted response data (plain data) to the verification server 21.
  • step S156 the verification server 21 confirms that the plain data is in a specified format.
  • step S157 the verification server 21 notifies the terminal application 62 of normal termination.
  • step S161 terminal application 62 requests user U to input a "two-dimensional code" if a two-dimensional code needs to be input.
  • step S162 user U instructs terminal application 62 to hold the two-dimensional code over the camera.
  • step S163 terminal application 62 analyzes the read two-dimensional code.
  • step S164 terminal application 62 notifies user U that the two-dimensional code has been read and displays the text of the analysis results.
  • step S165 user U inputs a press of the send button to terminal application 62.
  • step S181 terminal application 62 checks whether all information necessary to implement the requested authenticity evaluation method based on the customer policy has been input. In step S182, if all steps in step S181 are complete, the terminal application 62 proceeds to the next step, and if not, the conditional processing from step S121 above is repeated. In step S183, the terminal application 62 sends information (photo data, ID/PW, two-dimensional code, etc.) to the matching server 21 and requests the issuance of a card.
  • information photo data, ID/PW, two-dimensional code, etc.
  • step S184 the matching server 21 confirms the customer policy and executes the necessary processing using the data. If eKYC is to be implemented as a method for evaluating the authenticity of user U based on the customer policy, the process proceeds to step S191.
  • step S191 the matching server 21 requests the eKYC business server 161 to match the photo data.
  • step S192 the eKYC business server 161 returns an OK/NG result to the matching server 21.
  • step S201 the matching server 21 compares the ID and PW with the personal information DB 101.
  • step S202 the personal information DB 101 returns an OK/NG result to the matching server 21.
  • step S211 the matching server 21 confirms that the command processing was successful.
  • step S221 the matching server 21 compares the text content of the two-dimensional code with the personal information DB 101.
  • step S222 the personal information DB 101 returns an OK/NG result to the matching server 21.
  • step S231 the matching server 21 checks whether all of the requested authenticity evaluation methods have been completed based on the customer policy.
  • the matching server 21 requests the personal information DB 101 for face information and data (block data) to be written to the SE chip 61.
  • the personal information DB 101 returns the face information and data (block data) to be written to the chip to the matching server 21.
  • the terminal application 62 requests the MFC 63 to create face information (face creation) and issue a card.
  • step S235 the MFC 63 requests the issuing server 22 to create a face and issue a card.
  • the issuing server 22 requests the matching server 21 for format information and write data.
  • step S237 the matching server 21 sends the format information and write data to the issuing server 22.
  • step S238, the issuing server 22 creates a write command from the format information and write data.
  • step S239 the issuing server 22 stores the face information.
  • step S240 the issuing server 22 sends a write command to the MFC 63.
  • step S241 the MFC 63 sends a write data command to the SE chip 61.
  • step S242 passes the write data command to the command processing unit inside the chip.
  • step S243 the command processing unit inside the SE chip 61 generates a response after command processing.
  • step S244 the SE chip 61 returns response data to the MFC 63.
  • step S245 the MFC 63 returns response data to the issuing server 22.
  • step S246, the issuing server 22 returns response data to the matching server 21.
  • step S247 the matching server 21 notifies the issuing server 22 of normal completion.
  • step S248 the issuing server 22 notifies the MFC 63 of normal completion.
  • step S249 the MFC 63 returns normal completion to the terminal application 62.
  • step S250 the terminal application 62 confirms the card face information and registers the card face information within the application.
  • step S251 the terminal application 62 notifies the user U of the completion of the registration process (card issuance process).
  • this technology confirms the authenticity of the card based on the data read from the card, verifies the verification details required by the organization to which the card belongs, and after successfully carrying out the identity verification method required by the organization, writes the issuance details based on the card and application details into the chip in the terminal used when applying.
  • authenticity from the card it is also possible to obtain the same level of authenticity as the card by entering a one-time two-dimensional code or ID/PW, and permit writing to the chip. Note that if it is determined that the level of authenticity is lower than that obtained using a card, a temporary expiration date is set for the card information issued to the chip. By permitting issuance in units of one week or one month, temporary operation can be handled when the card is not in hand.
  • the DB that manages the card data is required to have strict security measures in order to manage personal information.
  • the issued cards using that data are linked to user information and are generally distributed correctly to the user.
  • there are various methods to use the card to check whether it is trustworthy. Whether the necessary information is available on the face of the card may differ depending on the issuer's design, and depending on the purpose of the card, the security regarding issuance may be low ( strict checks are not required). Two-factor check using ID/PW provided separately is also possible. Therefore, it is difficult to apply a uniform security policy.
  • the security policy required by the issuer can be checked in advance by reading the data written on the card, and the check contents required for issuing the card to the mobile terminal 51 can be checked, thereby realizing an appropriate pre-check. Even if the aforementioned card is not available, it may be possible to perform a similar identity verification by mailing or handing over the ID/PW or 2D code to the user. Therefore, in addition to card-based identity authentication, this technology also makes it possible to satisfy the security policies required by the organization (university, company) to which the target user belongs, using the ID/PW.
  • FIG. 22 is a configuration diagram showing a presence system 251 using an authentication system.
  • the presence system 251 of FIG. 22 after the issuance of the personal authentication card CA and after the issuance of the card to the mobile terminal 51, the time information of the execution of the identity verification is recorded and saved as a log in the SP server 11. This makes it possible to check the past presence status.
  • the presence system 251 is configured similarly to the information processing system 1 shown in FIG. 1 and FIG. 2. In the figure, the same reference numerals are given to the components corresponding to the information processing system 1, and the description thereof is omitted.
  • the SP server 261 is, for example, a server that manages attendance to a university class.
  • the SP server 261 acquires information of the personal authentication card read by a reader device. For example, it is assumed that the user U1 possesses the personal authentication card CA1, and the card is also issued to the mobile terminal 51. When the user U1 attends an online class, the user U1 sets the NFC of the mobile terminal 51 to the R/W mode and holds up the personal authentication card CA1. As a result, information on the personal authentication card CA1 is transmitted from the terminal application 62 to the SP server 261. In addition, by emulating a personal authentication card on the mobile terminal 51, the user U1 can also cause the terminal application 62 to transmit information on the emulated personal authentication card to the SP server 261 when attending an online class or the like.
  • the SP server 261 acquires the information of the personal authentication card from the user who attended the online class, it transmits the information to the SP server 11 and requests the processing of identity verification.
  • the SP server 11 performs the processing of identity verification in the same manner as the processing of the authenticity evaluation of the user described above.
  • the SP server 11 acquires a face image of user U1 or user U2 who is watching the online class, and compares it with the face image of user U1 or user U2 registered in the personal information DB 101 to verify the identity.
  • the identity verification is performed continuously while the online transmission and reception is being performed.
  • the SP server 11 records and saves, as an attendance log, for example, the information of the personal authentication card and the time information when the identity verification was performed correctly.
  • the information on the personal authentication card to be recorded and saved as an attendance log can be, for example, a manufacturing ID (IDm), which is unique information assigned to the IC chip of the personal authentication card CA or the SE chip 61 of the mobile terminal 51.
  • IDm manufacturing ID
  • the SP server 261 can determine who attended or was absent from an online class and when.
  • the SP server 261 acquires this information, and as shown in FIG. 23C, it is possible to acquire not only the attendance status but also the seat position information of the attendees.
  • NDFE NFC Data Exchange Format
  • FIG. 23B a user who participates in an online class from home or the like holds (tap) the personal authentication card CA over the NFC-enabled mobile terminal 51 as described above, and reads the information on the personal authentication card CA.
  • FIG. 23C by the SP server 261 acquiring this information and utilizing the identity verification process in the SP server 11, the SP server 261 can acquire information on attendees in the online class (attendees from home).
  • the present technology can also be configured as follows.
  • a management server having a processing unit that performs identity verification that a user of an information processing device in which personal authentication information held by a personal authentication card, which is a contactless IC card, is the card user authenticated by the personal authentication card, in a manner conforming to the policy of an organization that issued the personal authentication card.
  • the processing unit prevents the personal authentication information from being registered in the information processing device if the identity verification cannot be performed.
  • the information processing device is a device that emulates a function of the personal authentication card.
  • the personal authentication information registered in the information processing device is obtained from a personal information database in which personal information of the card user authenticated based on the information of the personal authentication card read by a reader of the information processing device is pre-stored.
  • the personal information database is provided using a cloud service,
  • the management server according to (5), wherein the policy of the organization is determined according to the cloud service used by the personal information database of the organization.
  • the management server according to any one of (1) to (12), wherein the processing unit performs a process of registering the personal authentication information in the information processing device.
  • the information processing device includes a secure element, The management server according to any one of (1) to (13), wherein a part of the personal authentication information registered in the information processing device is registered in a secure element.
  • the management server according to (14), wherein the personal authentication information registered in the information processing device includes authentication information registered in the secure element and face information written on the face of the personal authentication card.
  • An information processing system having a processing unit that performs identity verification that a user of an information processing device in which personal authentication information held by a personal authentication card, which is a contactless IC card, is the card user authenticated by the personal authentication card, in a method conforming to the policy of an organization that issued the personal authentication card.
  • the processing unit performs a process of registering the personal authentication information in the information processing device.
  • a personal information database in which personal information of the card user is stored in advance;
  • the information processing system according to (17), wherein the processing unit acquires the personal authentication information to be registered in the information processing device from the personal information database.
  • the personal authentication card is a contactless IC card having a secure element in which at least a part of personal authentication information is registered at the request of a user; An information processing device in which identity verification is performed in a manner consistent with the policy of the organization that issued the personal authentication card, and the information is registered in the secure element only if it is confirmed that the user is the card user authenticated by the personal authentication card.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Credit Cards Or The Like (AREA)

Abstract

La présente technologie se rapporte à un serveur de gestion, à un système de traitement d'informations et à un dispositif de traitement d'informations qui permettent d'enregistrer des informations d'une carte à circuit intégré sans contact uniquement sur un dispositif de traitement d'informations du véritable utilisateur de la carte sur la base d'une authenticité selon une politique de sécurité qu'un émetteur de carte ou un système similaire de carte à circuit intégré sans contact souhaite. Dans la présente invention, à l'aide d'un procédé selon une politique d'un groupe qui a émis une carte d'authentification personnelle qui est une carte à IC sans contact, une vérification d'identité est effectuée pour s'assurer qu'un utilisateur du dispositif de traitement d'informations, sur lequel des informations d'authentification personnelle conservées par la carte d'authentification personnelle doivent être enregistrées, est le véritable utilisateur de la carte authentifiée par la carte d'authentification personnelle.
PCT/JP2023/037472 2022-11-02 2023-10-17 Serveur de gestion, système de traitement d'informations et procédé de traitement d'informations WO2024095755A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022176416 2022-11-02
JP2022-176416 2022-11-02

Publications (1)

Publication Number Publication Date
WO2024095755A1 true WO2024095755A1 (fr) 2024-05-10

Family

ID=90930298

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/037472 WO2024095755A1 (fr) 2022-11-02 2023-10-17 Serveur de gestion, système de traitement d'informations et procédé de traitement d'informations

Country Status (1)

Country Link
WO (1) WO2024095755A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018133739A (ja) * 2017-02-16 2018-08-23 日本電信電話株式会社 秘密鍵複製システム、端末および秘密鍵複製方法
WO2022097523A1 (fr) * 2020-11-05 2022-05-12 フェリカネットワークス株式会社 Dispositif de traitement d'informations, procédé de traitement d'informations, programme, terminal portable, et système de traitement d'informations
JP2022096855A (ja) * 2020-12-18 2022-06-30 株式会社東芝 管理サーバ、ｉｄ登録システム、ｉｄ登録方法およびプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018133739A (ja) * 2017-02-16 2018-08-23 日本電信電話株式会社 秘密鍵複製システム、端末および秘密鍵複製方法
WO2022097523A1 (fr) * 2020-11-05 2022-05-12 フェリカネットワークス株式会社 Dispositif de traitement d'informations, procédé de traitement d'informations, programme, terminal portable, et système de traitement d'informations
JP2022096855A (ja) * 2020-12-18 2022-06-30 株式会社東芝 管理サーバ、ｉｄ登録システム、ｉｄ登録方法およびプログラム

Similar Documents

Publication Publication Date Title
US11777726B2 (en) Methods and systems for recovering data using dynamic passwords
US11790118B2 (en) Cloud-based system for protecting sensitive information in shared content
US20220239499A1 (en) System and method for high trust cloud digital signing
EP3662634B1 (fr) Systèmes et procédés de gestion d'identités numériques associées à des dispositifs mobiles
KR102400395B1 (ko) 법률 서면을 전자적으로 제공하는 시스템 및 방법
CN110462658A (zh) 用于提供数字身份记录以核实用户的身份的系统和方法
US11282071B2 (en) Digital identity management device
KR102131206B1 (ko) 법인 관련 서비스 제공 방법, 이를 지원하는 방법, 이를 수행하는 서비스 서버 및 인증 서버
US20210271744A1 (en) Presentation of a verifiable credential having usage data
TW201640409A (zh) 用以傳送憑證之系統及方法
US20120066349A1 (en) Method and system using two or more storage devices for authenticating multiple users for a single transaction
US11610196B1 (en) Officially authorized virtual identification cards
KR20240015642A (ko) 검증 가능 클레임을 위한 신뢰성 있는 관리 연속성
van den Broek et al. Securely derived identity credentials on smart phones via self-enrolment
WO2024095755A1 (fr) Serveur de gestion, système de traitement d'informations et procédé de traitement d'informations
Ferraiolo et al. Personal Identity Verification (PIV) Credentials
EP4111345B1 (fr) Justificatif d'identité vérifiable avec attribut dynamique
KR102403375B1 (ko) 전자증명서 지갑을 이용한 qr 코드 연계 전자증명서 출력 서비스 방법 및 그 장치와 시스템
US20180294970A1 (en) Methods of affiliation, emancipation and verification between a tutor and tutee
US12013924B1 (en) Non-repudiable proof of digital identity verification
US12107957B2 (en) Point-of-service digital identity verification device
US20240020355A1 (en) Non-fungible token authentication
US20240289718A1 (en) Service workflow integration platform
Fiebig Identity in the age of social networks and digitalisation
Souppaya et al. Derived Personal Identity Verification (PIV) Credentials

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23885517

Country of ref document: EP

Kind code of ref document: A1