Image formation apparatus, and control method and program therefor

Abstract

To provide a mechanism for verifying data signed at a terminal in an image formation apparatus.SOLUTION: An Image formation apparatus capable of communicating with a terminal having an authentication function includes: transmission means that transmits verification data for performing user authentication of the image formation apparatus to the terminal; reception means that receives, on the basis of the authentication being performed by the authentication function of the terminal, from the terminal, signature data obtained by encrypting the verification data using a private key corresponding to the authentication; and verification means that verifies the received signature data by using the verification data and a public key corresponding to the private key, in which when the verification is successful, a function that is premised on the user authentication is provided.SELECTED DRAWING: Figure 8

Description

[Technical field]

[0001] The present invention relates to a technique for authenticating a user who uses a device. [Background technology]

[0002] In recent years, technologies such as FIDO2.0 defined by the FIDO (Fast Identity Online) Alliance have become known as a means of authenticating users. This technology performs biometric authentication on a terminal held by the user, and verifies data signed with a private key on the terminal on the authentication server side.

[0003] On the other hand, for image forming apparatuses, techniques are known that perform authentication using an IC card or a password input by a user, as disclosed in Japanese Patent Laid-Open No. 2003-233999. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2023-37169 A Summary of the Invention [Problem to be solved by the invention]

[0005] However, with the technology of Patent Document 1, like FIDO, data signed at a terminal cannot be verified at an image forming device.

[0006] An object of the present invention is to provide a mechanism for verifying data signed at a terminal in an image forming apparatus. [Means for solving the problem]

[0007] In order to achieve the above-mentioned object, the image forming apparatus of the present invention is an image forming apparatus capable of communicating with a terminal having an authentication function, and comprises a transmitting means for transmitting to the terminal verification data for performing user authentication of the image forming apparatus, a receiving means for receiving from the terminal signature data obtained by encrypting the verification data using a private key corresponding to the authentication based on the authentication being performed in the authentication function of the terminal, and a verification means for verifying the received signature data using the verification data and a public key corresponding to the private key, and is characterized in that if the verification is successful, a function based on the user authentication is provided. Effect of the Invention

[0008] According to the image forming apparatus of the present invention, it is possible to provide a mechanism for verifying data signed in a terminal in the image forming apparatus. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating a system configuration. [Diagram 2] FIG. 2 is a diagram illustrating a hardware configuration. [Diagram 3] FIG. 2 is a diagram illustrating a software configuration. [Figure 4] FIG. 11 is a diagram showing information stored in a user database. [Diagram 5] FIG. 13 illustrates a user interface displayed on an operation panel of the MFP. [Figure 6] FIG. 13 is a diagram showing a user interface for settings relating to user authentication. [Figure 7] FIG. 11 is a diagram showing a sequence of passkey registration. [Figure 8] FIG. 11 is a diagram showing a sequence of passkey authentication. [Figure 9] FIG. 13 is a diagram illustrating a software configuration of a mobile terminal according to another embodiment. [Figure 10] FIG. 13 is a diagram showing a user interface of a mobile terminal for passkey registration. [Figure 11] FIG. 13 is a diagram showing a user interface of a mobile terminal in passkey authentication. [Figure 12] FIG. 11 is a diagram showing a user interface of a mobile terminal in another embodiment. [Figure 13] FIG. 13 illustrates a user interface displayed on an operation panel of the MFP. [Figure 14] FIG. 13 is a diagram showing a user interface for settings relating to simple login. [Figure 15] 13 is a flowchart showing a process when simple login is enabled. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0011] <First embodiment> An embodiment of the present invention will be described taking an MFP (Multifunction Peripheral) equipped with functions such as copying, printing, and scanning as an example of an image forming apparatus to which the present invention is applied.

[0012] In this embodiment, a digital signature verification technology, such as that used in FIDO (Fast Identity Online), is adopted as an authentication mechanism for a user to use functions and services provided by an image forming apparatus. Specifically, the technology described in this embodiment relates to a mechanism for authenticating a user by performing biometric authentication on a mobile terminal (information processing device) held by the user and verifying the digital signature data output as a result on the image forming apparatus side. As will be described later, one of the features of this embodiment is that a digital function corresponding to a FIDO service in FIDO technology is built into and implemented in the image forming apparatus. Note that, although FIDO is given as an example of such a mechanism, it should be noted in advance that the present invention is not limited to the standard defined by the FIDO Alliance. Also, authentication on a mobile terminal is not limited to biometric authentication. As will be described later, authentication by, for example, a PIN number may also be used.

[0013] <System Configuration> Refer to FIG. 1 to describe the system configuration of this embodiment. The MFP 101 is an MFP to which the present invention is applied. The mobile terminal 102 is a mobile terminal such as a smartphone. The mobile terminal is a terminal equipped with iOS of Apple or a terminal equipped with Android (registered trademark) of Google. The mobile terminal 102 can communicate with the MFP 101 via a wireless LAN (Local Area Network) access point 103, a wired LAN 104, or the like.

[0014] Also, when the MFP 101 has a wireless LAN access point function, the mobile terminal 102 may be configured to connect to the wireless LAN access point function of the MFP 101 and communicate directly.

[0015] <Hardware Configuration of MFP 101> FIG. 2(a) is a schematic diagram showing the hardware configuration of the MFP 101. The CPU 201 is a central processing unit (processor) that controls the operation of the entire MFP 101. The RAM (Random Access Memory) 203 is a volatile memory and a work area, and is used as a temporary storage area for expanding various control programs stored in the ROM 202 and the HDD 204.

[0016] The ROM 202 is a non-volatile memory, and stores the boot program of the MFP 101 and the like. The HDD 204 is a non-volatile hard disk or flash storage with a large capacity compared to the RAM 203. The HDD 204 stores the control program of the MFP. Also, the OS (Operating System) and application programs are stored in the HDD 204.

[0017] When the MFP 101 starts up, the CPU 201 executes a boot program stored in the ROM 202. This boot program is for reading out an OS (Operating System) program stored in the HDD 204 and loading it onto the RAM 203. After executing the boot program, the CPU 201 subsequently executes the OS program loaded onto the RAM 203 and controls the MFP 101. The CPU 201 also stores data used for operations according to the control program onto the RAM 203 and reads and writes it.

[0018] In the MFP 101, one CPU 201 executes each process shown in a sequence diagram described later, but other configurations are also possible. For example, a plurality of CPUs or microprocessors (MPUs) may cooperate to execute each process shown in a sequence diagram described later. Some of the processes described later may be executed using hardware circuits such as ASIC (Application SpecifIC Integrated Circuit) and FPGA (Field-Programmable Gate Array).

[0019] The operation panel 205 is a touch-operable display (touch panel). The printer 206 is a printer engine that prints print data received from the outside via a communication unit 208 and digital data acquired from a scanner 207. The scanner 207 is a scanner device that reads paper documents and converts them into digital data. The communication unit 208 is a network interface for connecting to the Internet or an office LAN (Local Area Network).

[0020] <Hardware configuration of the mobile terminal 102> 2(b) is a simplified diagram showing the hardware configuration of the mobile terminal 102. The CPU 211 is a central processing unit (processor) that controls the overall operation of the mobile terminal 102. The RAM (Random Access Memory) 213 is a volatile memory and a work area, and is used as a temporary storage area for expanding various control programs stored in the ROM 212 and the flash storage 214.

[0021] The ROM 212 is a non-volatile memory that stores a boot program and the like for the mobile terminal 102. The flash storage 214 is a non-volatile memory storage with a larger capacity than the RAM 213. The flash storage 214 stores a control program for the mobile terminal. The flash storage 214 also stores an OS (Operating System) and application programs.

[0022] The operation panel 215 is a touch-operable display (touch panel).

[0023] The camera 216 is a camera module that can be used to take pictures, videos, and QR codes (registered trademark). The in-camera 216 is a camera that can be used to take pictures of the user of the mobile terminal and for face authentication. The fingerprint sensor 218 is a sensor that can be used for fingerprint authentication. The communication unit 219 is a network interface for wireless communication.

[0024] <Software configuration> 3 is a simplified diagram showing the software configuration of the MFP 101 and the mobile terminal 102. The MFP 101 has an authentication service 301 for authenticating a user who uses the MFP 101. The authentication service 301 has a local login service 302 and a FIDO service 303. The local login service 302 displays a login screen on the operation panel 205, authenticates a user who uses the operation panel, and allows the user to log in to the operation panel. The FIDO service 303 has a web server function capable of communicating via HTTP (Hypertext Transfer Protocol). It also has an authentication function of WebAuthn (Web Authentication) defined by the FIDO Alliance and the World Wide Web Consortium (W3C).

[0025] The local UI service 304 of the MFP 101 provides a user interface for providing functions to a user who has logged in to the operation panel. The local UI service 304 includes a menu from which the user selects a function, applications, a UI platform that controls screen transitions, and the like. For example, it includes a "copy" application that provides the user with a UI for the copy function, a "print" application that provides a UI for the print function, and a "scan and send" application that provides a UI for sending scanned documents to an external device.

[0026] The printer control unit 305 is a software module that controls the printer 206, and the scanner control unit 306 is a software module that controls the scanner 207. Each software module provides an application with an API (Application Programming Interface) for operating the printer 206 or scanner 207. Although not shown, the software configuration of the MFP 101 includes an operating system and driver software for controlling various hardware.

[0027] The OS 311 of the mobile terminal 102 is an operating system. It is configured as a terminal equipped with Apple's iOS, Google's Android (registered trademark), or the like. The authenticator 312 is software having a FIDO authenticator function defined by the FIDO Alliance. The function of the authenticator 312 may be incorporated into the operating system (OS 311) as one of its functions. The camera application 313 is an application that controls the camera 216 and the in-camera 217 to take photos and videos. It also has a function of taking and decoding QR codes. The web browser 314 is software that operates as a client function for performing HTTP communication. The web browser 314 is configured as Apple's Safari, Google's Chrome, Microsoft's Edge, or the like.

[0028] <user account> 4 is a simplified diagram illustrating a user database stored in the HDD 204 of the MFP 101. The MFP 101 stores and manages user account information in a user database 401 in the HDD 204. Note that a database of another node on the network may be used after encrypting the communication path and storage and providing tamper-proofing. The user database 401 records user IDs, passwords, passkey information (credential ID and public key) used for FIDO authentication, roles, email addresses, and whether password authentication is enabled or disabled.

[0029] "User ID" is an identifier for identifying a user. "Password" is a password used for authentication. "Role" is information indicating the user's usage authority for MFP 101. Examples of roles and usage authority are shown in role information table 402. In addition to the role definitions that MFP 101 has when shipped from the factory, it may be possible for the user to set detailed usage authority and create new roles.

[0030] Registration, editing, and deletion of user account information is performed via a UI for user account management 602 and user account editing 603 in FIG. 6, which will be described later.

[0031] The user database is referenced by the user authentication service 301 to authenticate the user. In addition, passkey information (credential ID and public key) is stored via the FIDO service 303.

[0032] <User authentication function> Next, a user authentication function of the MFP 101 will be described with reference to FIG. 5 and FIG. 6. In this embodiment, two types of user authentication will be described. The first type is authentication using a password input by the user to the operation panel. The second type is a technique using PKI defined by FIDO, in which the MFP login server 103 authenticates the user. That is, authenticating the user using the result of verifying the signature data obtained by encrypting the challenge with a private key using a public key is called user authentication. In this embodiment, apart from these user authentications, authentication for authenticating the owner of the mobile terminal is performed on the mobile terminal. This is authentication in S1019 and S1114, which will be described later. Thus, in this embodiment, there are multiple types of authentication.

[0033] Fig. 5 is a simplified diagram showing a login screen displayed on operation panel 205 and a menu screen displayed after login. Fig. 6 is a schematic diagram showing a setting screen for managing a login method and a user account. The screen shown in Fig. 6 is displayed when a setting menu is selected from management settings 504 shown in Fig. 5.

[0034] On the screen of login method setting 601 of the local UI, a method for performing user authentication and logging in to the operation panel can be selected. In this embodiment, a user operation to select from options including "password authentication" using a password input by the user and "mobile authentication (passkey authentication)" using a passkey including a public key can be accepted and enabled. In addition, when both methods are enabled on the screen of login method setting 601, the local login service 302 may accept the selection of the authentication method on the mobile authentication screen 501 and the password authentication screen 502. In this embodiment, a password authentication button 508 is displayed on the mobile authentication screen 501 to accept the selection of password authentication. In addition, a mobile authentication button 509 is displayed on the password authentication screen 502 to accept the selection of mobile authentication.

[0035] Password authentication provides a method for logging in by inputting a user ID and a password. Specifically, the local login service 302 displays a password authentication screen 502 as a login screen on the operation panel 205. The user can input the user ID and password using a hard key or a software key (not shown) provided on the MFP 101. The local login service 302 accepts the input of the user ID and password via the hard key or software key. It then verifies whether user account information matching the combination of the accepted user ID and password exists in the user database 401. If it exists, it determines that the user authentication has been successful and displays a post-login menu screen.

[0036] Mobile authentication (passkey authentication) is performed in cooperation with the local login service 302, the FIDO service 303, and the authenticator 312 of the mobile terminal 102. The user is authenticated by a technology called a passkey that uses a PKI (Public Key Infrastructure) defined by FIDO.

[0037] When mobile authentication (passkey authentication) is enabled, a mobile authentication screen 501 is displayed as a login screen on the operation panel 205 to authenticate the user. Details of passkey registration and authentication methods using a passkey will be described later.

[0038] When both password authentication and mobile authentication (passkey authentication) are enabled, a password authentication display button 508 and / or a mobile authentication display button 509 are displayed on the login screen, allowing the user to switch the display of the login screen and use it.

[0039] If the user is successfully authenticated by password authentication or mobile authentication (passkey authentication), the local login service 302 allows the user to log in to the operation panel 205 .

[0040] If the login is successful, the local UI service 304 that has detected the user's login displays a menu screen 503 on the operation panel 205. Then, the local UI service 304 provides functions that are premised on user authentication.

[0041] An example of a function that requires user authentication is a print function with a predetermined print setting by the printer 206. When a user assigned the role of Administrator or GeneralUser is authenticated, printing with color print settings is possible. When a user assigned the role of LimitedUser is authenticated, printing with black and white print settings is permitted only.

[0042] Furthermore, a function that requires user authentication is a function for transmitting image data obtained by scanning with the scanner 207 to an external device. When a user to whom the role of Administrator or GeneralUser is assigned is authenticated, this function is provided.

[0043] Furthermore, as a function premised on user authentication, there is a function that uses an address book when specifying a destination of image data obtained by scanning with Scan 207. The address book is a list in which information on one or more destinations is registered. A user to whom the role of GeneralUser is assigned can select a destination from the address book and specify the destination of image data. Also, a user to whom the role of Administrator is assigned can not only select a destination from the address book, but also register a new destination in the address book and edit the address book.

[0044] Furthermore, a function that assumes user authentication is a function for configuring the MFP 101. The configuration of the MFP 101 includes, as displayed on a management setting screen 504, configuration of a login method for the local UI, configuration related to each user account, device configuration, and network configuration. When a user to whom the role of Administrator is assigned is authenticated, these configuration functions are provided, and the MFP 101 can be configured. The device configuration includes configuration related to print and scan jobs, such as whether or not to display on the operation panel 205 the history recorded when a job is executed. The network configuration includes a configuration such as whether or not to permit the use of each print protocol when printing.

[0045] <Simple login function> The simple login function of the MFP 101 will be described with reference to Figs. 13 and 14. Fig. 13 is a simplified diagram showing a login screen displayed on the operation panel 205 and a menu screen displayed after login. Fig. 14 is a schematic diagram showing a setting for forcing an authentication means after simple login according to the activation of the simple login function and the role shown in Fig. 4. For example, in the setting shown in 1403 in Fig. 14, if the role is Administrator or GeneralUser, a screen for FIDO authentication is displayed after simple login, and login is not possible until authentication is performed by FIDO authentication. This forces FIDO authentication after simple login. If the role is LimitedUser, the screen for FIDO authentication is not displayed after simple login, and the user logs in as is. That is, authentication after simple login is not forced. The screen shown in Fig. 14 is displayed by selecting a setting menu from the management setting 504 shown in Fig. 5.

[0046] When the local login service 302 detects that an enable button 1402 shown on a simple login setting screen 1401 has been pressed, the local login service 302 enables the simple login function. When the simple login function is enabled, the local login service 302 displays buttons and icons of users registered in the user database shown in FIG. 4 on the login screen. The local login service 302 accepts the selection of a button corresponding to the user's user ID from the user via the button or icon. The user is allowed to log in to the MFP 101 by having the user select a button corresponding to the user's avatar. That is, the local login service 302 performs login with the user ID and password of the user corresponding to the selected button among the buttons displayed on the login screen. This allows the user to omit inputting a user ID and password. The simple login can be used in combination with a FIDO service function described later to prevent unauthorized login. In addition, the enforcement of authentication method for each role 1403 makes it possible to set which combination of authentication methods is enforced for each device user.

[0047] An example of the login screen for simple login is shown in 1301 in Fig. 13. When it is detected that a button has been selected by the user on the simple login screen, the local login service 302 proceeds with the login process for the user to the operation panel 205. Note that the simple login function can also be configured so that a PIN or pattern is set for each user, and the user can log in by inputting the correct PIN or pattern. In this case, if authentication using the PIN or pattern is successful, the login process proceeds.

[0048] Here, when a button for a user who has already registered a passkey is selected as shown in the user database 401, a mobile authentication screen 1302 is displayed. After the FIDO authentication process is executed on the mobile authentication screen 1302, the local login service 302 logs the user in to the operation panel 205.

[0049] If the user is logging in for the first time and a passkey is not registered in the user database 402, a screen 1306 is displayed prompting the user to register a passkey. When passkey registration is to be performed, the local login service 302 displays a passkey registration screen 1307, and allows the user to log in to the operation panel 205 after the registration process is completed.

[0050] If it is determined that passkey registration is not required based on the setting in 1403 and whether or not this is the first login, the local login service 302 allows the user to log in to the operations panel 205 .

[0051] Next, the operation when the role-based authentication method enforcement 1403 is enabled will be described. When the role-based authentication method enforcement 1403 is enabled and the user has already registered a passkey, the mobile authentication screen 1302 is displayed. After the FIDO authentication process is executed on the mobile authentication screen 1302, the local login service 302 logs the user in to the operation panel 205.

[0052] For users with the forced authentication method for each roll enabled and no passkey registration, display a passkey registration screen as shown in 1305. When executing passkey registration, the local login service 302 displays the passkey registration screen 1307 and logs the user in to the operation panel 205 after the registration process is completed. When not executing passkey registration, the local login service 302 displays the simple login screen 1301 again. When the login is successful, the local UI service 304 that detects the user's login displays the menu screen 1303 on the operation panel 205.

[0053] <FIDO service function> The FIDO service 303 has a web server function capable of communicating via HTTP (Hypertext Transfer Protocol). It also has the authentication function of WebAuthn defined by the FIDO Alliance and the W3C.

[0054] The FIDO service 303 is accessed via HTTPS communication from the web browser 314 of the mobile terminal 102 that has photographed the QR code displayed on the mobile authentication screen 501 or the passkey registration screen 506. The FIDO service 303 provides access and functions for URLs 1 to 6 as follows, for example, as a web server.

[0055] <url1> https: / / mfp101.office.local / LocalUI / registration / randomnumber URL1 is a URL that responds with HTML for passkey registration. The random number in URL1 is a character string such as "52f3d66abc7519a209af9de1d96136c9". The random number matches the character string embedded in the QR code on the passkey registration screen 506.

[0056] The HTML for passkey registration returned at URL1 includes JavaScript for accessing the REST (Representational State Transfer) API at the following URL2 and URL3. It also includes the following WebAuthn JavaScript defined in FIDO2.0.

[0057] <WebAuthnのJavaScript> Output JSON data = await navigator.credentials.create(input JSON data); <url2> https: / / mfp101.office.local / LocalUI / registration / challenge URL2 is the URL of a REST API that responds with input JSON data to be input to the above API "navigator.credentials.create()". The input JSON data includes challenge data issued by the FIDO service 303. The challenge is a random number, and is verification data used for verification for registering a passkey.

[0058] <url3> https: / / mfp101.office.local / LocalUI / registration / verification URL3 is the URL of the REST API that receives information for registering a passkey. It receives the output JSON data output by the API "navigator.credentials.create()" above. The output JSON data includes the credential ID, challenge, public key, digital signature, etc. issued by the mobile terminal 102.

[0059] <url4> https: / / mfp101.office.local / LocalUI / authentication / randomnumber URL4 is a URL that responds with HTML for passkey authentication. The random number is a character string such as "b15dee080a1a549be6e3c74e6b59f5c5". The random number matches the character string embedded in the QR code on the mobile authentication screen 501.

[0060] The HTML for passkey authentication returned in URL4 includes JavaScript for accessing the REST API in URL5 and URL6. It also includes the following WebAuthn JavaScript defined in FIDO2.0.

[0061] <WebAuthnのJavaScript> outputJSONData = await navigator.credentials.get(inputJSONData); <url5> https: / / mfp101.office.local / LocalUI / authentication / challenge URL5 is the URL of the REST API that responds with input JSON data to be input to the above "navigator.credentials.get()". The input JSON data includes a challenge issued by the FIDO service 303. The challenge is a random number, and is verification data used for verification for user authentication using a passkey.

[0062] <url6> https: / / mfp101.office.local / LocalUI / authentication / verification URL6 is the URL of the REST API that receives information for passkey authentication. It receives the output JSON data output by the API "navigator.credentials.get()". The output JSON data includes the credential ID of the passkey used for the digital signature, the challenge, the digital signature, etc.

[0063] <Passkey registration sequence> The process flow for registering a passkey will be described with reference to the sequence diagram in Fig. 7. Fig. 10 shows an example of an operation screen of the mobile terminal 102 when registering a passkey. In this embodiment, the flow executed by the MFP 101 is recorded in software programs such as the login service 302 and the FIDO service 303. The software programs are stored in non-volatile storage such as the ROM 202 and the HDD 204, and are loaded into the RAM 203, and the flow is executed by the CPU 201.

[0064] In S701, the local login service 302 detects that the user has pressed the passkey registration button 510 on the mobile authentication screen 501.

[0065] In S702, the local login service 302 displays a screen 505 on the operation panel 205 for authenticating a user with a user ID and password. Then, input of a user ID and password is accepted via the screen 505. The user ID and password input on the screen 505 are acquired to authenticate the user. Specifically, the user database stored in the HDD 204 is referenced, and the password in the user account information that matches the acquired user ID is compared with the acquired password, and if they match, the user authentication is deemed successful. If the user authentication is unsuccessful, an error is displayed.

[0066] If the user authentication is successful, in S703, the local login service 302 generates a random number. The random number is, for example, a character string such as "52f3d66abc7519a209af9de1d96136c9".

[0067] In S704, the local login service 302 transmits the user ID of the user authenticated in S702 and the generated random number to the FIDO service 303 and shares them. The method of transmission may use an API (Application Programming Interface) or may be temporarily stored in the RAM 203 or the HDD 204 and shared, and there are no particular limitations on the means or timing. In addition, the random number may be generated not by the local login service 302 but by the FIDO service 303 or another module and shared with the local login service 302.

[0068] Next, in S705, the local login service 302 generates a QR code and displays the QR code on the passkey registration screen 506. The QR code is embedded with the data of URL1 including the random number. The random number is information known only to the person who photographed the QR code, and is intended to confirm that the user accessing URL1 is in front of the operation panel.

[0069] Next, in S706, the user starts the camera application 313 from the mobile terminal that the user owns, and captures an image of the QR code displayed on the operation panel 205.

[0070] Next, in step S707, the camera application 313 launches the web browser 314.

[0071] In S708, the web browser 314 accesses the address of URL1 obtained from the QR code.

[0072] In S709, the FIDO service 303 of the MFP 101 detects access to URL1. The accessed URL is verified, and if the random number acquired in S704 is not included in the URL, an error such as HTTP 404 Not Found is responded to the web browser 314. If the random number acquired in S704 is included, in S710, the HTML of the HTML screen 1001 for registering a passkey is responded. The HTML for registering the passkey includes JavaScript for accessing the REST (Representational State Transfer) API of URL2 or URL3. In addition, the following JavaScript for WebAuthn defined in FIDO2.0 is included. <WebAuthnのJavaScript> Output JSON data = await navigator.credentials.create(input JSON data);

[0073] In addition, the header of the communication packet in S710 includes a session ID to be saved in a cookie of the web browser 314. The session ID is used to confirm that the access to URL1 for which the random number verification in S709 was performed and the subsequent access to URL2 and URL3 are performed in the same session. If URL2 or URL3 is accessed directly without the session ID in the cookie, the FIDO service 303 can return an error without processing the request.

[0074] Web browser 314, which has received the HTML in S710, executes JavaScript in S711 and accesses URL2. At this time, it is preferable to automatically execute JavaScript and access URL2 without the user operating the web browser. JavaScript can be executed automatically by utilizing the onload event of JavaScript, which is called when the HTML of HTML screen 1001 has been fully loaded into web browser 314. Alternatively, a "register passkey" button may be displayed as in HTML screen 1002, and when it is detected that the user has pressed the "register passkey" button, JavaScript may be executed and URL2 may be accessed.

[0075] Upon receiving the access to URL2, the FIDO service 303 generates a challenge in S712. The challenge is a random number.

[0076] Next, in step S713, the input JSON data including the generated challenge is returned as a response. The input JSON data also includes information about the server of the MFP 101 (for example, a host name or domain name such as mfp101.office.local), a user ID, and the like.

[0077] Next, in S714, the web browser 314 executes the following JavaScript of WebAuthn using the received input JSON data and launches the authenticator 312. <WebAuthnのJavaScript> Output JSON data = await navigator.credentials.create(input JSON data);

[0078] Next, in S715, the authenticator 312 authenticates the owner of the mobile terminal 102 by any of a number of means, such as authentication using biometric information such as face authentication or fingerprint authentication, authentication using a PIN number, or pattern authentication.

[0079] Next, in S716, the authenticator 312 generates a key pair (PKI private key and public key) called a passkey and a credential ID for identifying the passkey, and stores it in a tamper-resistant storage area in association with information about the server of the MFP 101 (e.g., mfp101.office.local) and the user ID.

[0080] Next, in S717, the authenticator 312 uses the generated private key to digitally sign the data including the challenge data received in S713. The authenticator 312 returns output JSON data to the web browser. The output JSON data includes the generated public key, credential ID, digital signature, etc.

[0081] Next, in S718, the web browser 314 accesses URL3 and sends output JSON data including the public key, credential ID, and digital signature to the FIDO service 303.

[0082] Next, in S719, the FIDO service 303 verifies the digital signature using the challenge issued by itself in S712 and the public key received. Specifically, the FIDO service 303 verifies whether the digital signature is the same as the challenge issued by itself by decrypting the digital signature using the received public key. If they are the same, it is determined that the digital signature verification has been successful, and if they are not the same, it is determined that the verification has failed. If the digital signature verification is successful, in S720, the FIDO service 303 associates the passkey information (public key and credential ID) with the user ID and stores them in the user database of the HDD 204.

[0083] Next, in step S721, the FIDO service 303 responds to the web browser 314 with information such as whether the passkey registration was successful or not.

[0084] Next, in step S722, the FIDO service 303 notifies the local login service 302 that the passkey registration has been completed.

[0085] Next, in step S723, the local login service 302 displays a screen 507 on the operation panel 205 for selecting whether or not to disable password authentication. If it is detected that the user has selected "Yes," the service stores the disabled password authentication in the user database in the HDD 204 in association with the user ID. The user who has disabled password authentication is then unable to log in using their user ID and password, and is controlled so that they can only log in to the operation panel using mobile authentication (passkey authentication).

[0086] Finally, in S724, the passkey registration screen is closed, and the passkey registration process is terminated.

[0087] In the above configuration, an example is shown in which a user who wishes to register a passkey is authenticated on an operation panel. However, the user may be authenticated on the web browser 314 of the mobile terminal 102. In this case, in S710, the HTML screen 1003 returned by the FIDO service 303 includes a text field for inputting a user ID and password, and requests the user to input a user ID and password. Furthermore, the FIDO service 303 receives the user ID and password entered by the user in the packet of S711, and authenticates the user by referring to the user database in the HDD 204.

[0088] The password authentication of each user can be enabled / disabled, and the registration status of the passkey can be confirmed and the registration can be deleted on a user account edit screen 603. The user account edit screen is a screen that can be viewed and edited by an administrator user to whom the role of Administrator, who has the authority to change the management settings of the MFP 101, is assigned. When the authentication service 301 authenticates an administrator user to whom the role of Administrator is assigned, the local UI service 304 displays the menu screen 503. When the local UI service 304 accepts the selection of management settings on the menu screen 503, it displays the management settings screen 504. Then, when the management settings screen 504 accepts the selection of user account management, it displays a user account management screen 602. On the user account management screen 602, the administrator selects a user to be edited and presses an edit button. When the local UI service 304 detects the pressing of the edit button, it displays a user account edit screen 603 for the selected user. When the authentication service 301 authenticates a general user to whom the role of GeneralUser is assigned, the local UI service 304 displays the menu screen 503 but controls so as not to accept the selection of management settings. Therefore, the general user cannot view the user account management screen 602. The general user can press the "Personal Settings" button displayed on the menu 503 screen. When the local UI service 304 detects that the personal settings button has been pressed, it displays the user account edit screen 603 for the account of the logged-in general user.

[0089] On the user account editing screen 603, the disabled password authentication can be re-enabled by pressing an enable button 604. When a "passkey has been registered" and "password authentication is enabled", a disable button is displayed instead of the enable button 604, allowing the password authentication to be disabled. When a "passkey has not been registered", disabling "password authentication" leaves the user with no means of logging in, so the configuration may be such that "passkey authentication" cannot be disabled when a "passkey has not been registered". When a passkey has been registered, the passkey registration can be deleted by pressing a delete registration button 605. When the passkey registration is deleted, the user will no longer be able to log in with the passkey, so it is advisable to configure the configuration so that the disabled password authentication is automatically enabled.

[0090] If the passkey is not registered, the passkey registration status displays “Not registered.” If the passkey is not registered, the registration deletion button 605 is configured to be grayed out or not displayed.

[0091] <Passkey authentication sequence> The process flow for logging in using a passkey will be described with reference to the sequence diagram of FIG.

[0092] FIG. 11 shows an example of an operation screen of the mobile terminal 102 during passkey authentication.

[0093] In S801, if a user is not logged in, the local login service 302 starts displaying the mobile authentication screen 501. For example, when a logged-in user logs out, the mobile authentication screen 501 is displayed. Also, the mobile authentication screen 501 may be configured to be displayed when the MFP 101 is powered on.

[0094] In S802, the local login service 302 generates a random number. The random number is, for example, a character string such as "b15dee080a1a549be6e3c74e6b59f5c5".

[0095] Next, in S803, the generated random number is transmitted to the FIDO service 303 and shared. The method of transmission may be by using an API, or by temporarily storing the random number in the RAM 203 or the HDD 204 and sharing it, and there are no particular limitations on the means or timing. In addition, the random number may be generated not by the local login service 302 but by the FIDO service 303 or another module, and shared with the local login service 302.

[0096] Next, in S804, the local login service 302 generates a QR code and controls display so that the QR code is displayed on the mobile authentication screen 501. The QR code contains the data of URL4 including the random number. The random number is information known only to the person who photographed the QR code, and is intended to confirm that the user accessing URL4 is in front of the operation panel.

[0097] Next, in S805, the user starts the camera application 313 from the mobile terminal that the user owns, and captures an image of the QR code displayed on the operation panel 205.

[0098] Next, in S806, the camera application 313 launches the web browser 314.

[0099] Next, in S807, the web browser 314 accesses the address of URL4 obtained from the QR code.

[0100] In S806, the FIDO service 303 of the MFP 101 detects access to URL4. The accessed URL is verified, and if the random number acquired in S803 is not included in the URL, an error such as HTTP 404 Not Found is responded to the web browser 314. If the random number acquired in S803 is included, the HTML of an HTML screen 1011 for passkey authentication is responded to in S809. The HTML for passkey authentication includes JavaScript for accessing the REST (Representational State Transfer) API of URL5 or URL6. In addition, the following WebAuthn JavaScript defined in FIDO2.0 is included. <WebAuthnのJavaScript> outputJSONData = await navigator.credentials.get(inputJSONData);

[0101] Furthermore, the header of the communication packet in S809 includes a session ID to be saved in a cookie of the web browser 314. The session ID is used to confirm that the access to URL4 for which the random number verification in S808 was performed and the subsequent access to URL5 and URL6 are performed in the same session. If URL5 or URL6 is accessed directly without the session ID in the cookie, the FIDO service 303 can return an error without processing the request.

[0102] In this case, it is preferable to automatically execute JavaScript to access URL 5 without the user operating the web browser. JavaScript can be executed automatically by using the onload event of JavaScript, which is called when the HTML of HTML screen 1011 is completely loaded into web browser 314.

[0103] Alternatively, a "passkey authentication" button may be displayed as in HTML screen 1012, and when it is detected that the user has pressed the "passkey authentication" button, JavaScript may be executed and URL 5 may be accessed.

[0104] The FIDO service 303 that has received the access to URL 5 generates a challenge in S811. The challenge is a random number.

[0105] Next, in step S811, the input JSON data including the generated challenge is returned as a response. The input JSON data also includes information about the server of the MFP 101 (for example, a host name or domain name such as mfp101.office.local).

[0106] Next, in step S813, the web browser 314 executes the following JavaScript of WebAuthn using the received input JSON data, and starts the authenticator 312. If the authenticator 312 manages multiple passkeys in association with information on the server of the MFP 101, there are cases in which a screen for selecting one passkey from the multiple passkeys is displayed. <WebAuthnのJavaScript> Output JSON data = await navigator.credentials.create(input JSON data);

[0107] Next, in S814, the authenticator 312 authenticates the owner of the mobile terminal 102 by any of the following means: face authentication, fingerprint authentication, PIN number, pattern authentication, or the like.

[0108] Next, in S815, the authenticator 312 acquires a passkey (PKI private key) stored in association with information about the server of the MFP 101 (for example, mfp101.office.local). Then, the authenticator 312 generates a digital signature for the data including the challenge received in S812 using the private key. The authenticator 312 returns output JSON data to the web browser. The output JSON data includes the digital signature, the credential ID of the passkey used for the digital signature, and the like.

[0109] Next, in S816, the web browser 314 accesses URL 6 and sends output JSON data including the public key, credential ID, and digital signature to the FIDO service 303.

[0110] Next, in step S817, the FIDO service 303 refers to the user database in the HDD 204 and obtains the user ID and public key of the account associated with the received credential ID.

[0111] Next, in S818, the "digital signature received in S816" is verified using the "challenge issued by the FIDO service in S811" and the "public key obtained from the user database in S817." Specifically, the FIDO service 303 verifies whether the digital signature is the same as the challenge issued by the FIDO service 303 by decrypting the digital signature using the public key. If they are the same and the digital signature verification is successful, it is determined that the authentication is successful, and if the verification is unsuccessful, it is determined that the authentication is unsuccessful.

[0112] Next, in S819, a response is made as to whether the authentication was successful or not.

[0113] If the authentication is successful, in step S820, a request to log in to the operations panel is made to the local login service 302. The login request includes the user ID.

[0114] Next, in S821, the local login service 302 performs login processing to allow the user with the user ID specified in S820 to log in to the operation panel. Specifically, the local login service 302 refers to the user database in the HDD 204 and acquires user information such as the user ID, role, and email address of the account to be logged in. Furthermore, the local login service 302 notifies the local UI service 304 of a login occurrence event. The login event includes information about the user to be logged in.

[0115] Finally, in S822, the mobile authentication screen 501 is closed, and the local UI service 304 displays the menu screen 503, thereby completing the login process. If the verification is successful in S818, the local UI service 304 provides the user with a function that is premised on user authentication. The function that is premised on user authentication and is provided when the verification is successful is as described above in the description of the user authentication function.

[0116] If the verification is not successful in S817, a failure is notified in S819. For example, there are cases where "the specified user ID is not registered in the user DB", "the public key of the passkey is not registered in association with the user ID", and "verification of the digital signature failed" in S818. The local login service 302 may also be notified of the error, and a message of authentication failure may be displayed on the mobile authentication screen 501. Note that, if "the specified user ID is not registered in the user DB", or "the public key of the passkey is not registered in association with the user ID", the FIDO service 303 cannot identify the public key to be used for verification in S818. Therefore, a failure notification in S819 may be sent without performing S818.

[0117] In addition, the random number stored in the QR code on the mobile authentication screen 501 should be updated to a new random number when a notification of authentication success or failure is received. Even when there is no notification of authentication success or failure, it is safer to update the random number periodically and shorten the lifetime of the random number.

[0118] In the above configuration, an example has been shown in which the web browser 314, which has completed receiving the HTML of the HTML screen 1011, receives an onload event of the JavaScript and automatically executes the JavaScript in S809. In S809, a form for a passkey authentication button may also be included, as in the HTML screen 1012, and the user may be prompted to press the button.

[0119] In S809, a text field for inputting the user ID may be included as in HTML screen 1013, and the user may be prompted to input the user ID. In this case, the user ID is included in the URL 5 access in S810. The FIDO service 303 that receives this can obtain the credential ID associated with the user ID from the user database and include the credential ID in the response in S812. This makes it possible to narrow down the passkey to be used from the credential ID to one, even if multiple passkeys are managed on the authenticator 312 side.

[0120] <Passkey registration and authentication sequence when simple login is enabled> The process flow from passkey registration to authentication when simple login is enabled will be described with reference to the flowchart in Fig. 15. The flowchart in Fig. 15 starts, for example, when a logged-in user logs out. It also starts when the MFP 101 is powered on.

[0121] In S1501, the local login service 302 checks whether the "enable simple login" setting 1402 is enabled on the simple login setting screen 1401. If simple login is enabled, the display process of the simple login authentication screen 1301 is started.

[0122] In step S 1502 , the local login service 302 refers to the user database in the HDD 204 and checks the account information to be displayed on the simple login authentication screen 1301 .

[0123] After executing the process of displaying the simple login authentication screen 1301, the local login service 302 detects in step S1504 that the user avatar has been pressed.

[0124] Next, in S1505, account information such as a user ID and a role associated with the user avatar is temporarily stored. The method of temporary storage may be to use an API or to store in the RAM 203 area, and there are no particular limitations on the means or timing.

[0125] Next, in S1506, the local login service 302 checks the forced setting 1403 of the authentication method for each role on the simple login setting screen 1401. As shown in Fig. 14, when the role of the user who executed the simple login is "Administrator" or "GeneralUser", it is possible to set it so that FIDO authentication is forced. When the role is "LimitedUser", it is possible to set it so that the authentication process after the simple login is not forced. In addition, the administrator who executes the simple login setting may force FIDO authentication for all roles, or may set it so that there is no authentication after the simple login.

[0126] Next, in step S1507, the local login service 302 determines the process to be performed after the simple login authentication based on the temporarily stored role information and the forced setting 1403 of the authentication method for each role.

[0127] For example, when authentication is performed for "Dave" shown in the user database 401, the FIDO authentication enforcement setting is not implemented, so in S1508 the local login service 302 checks the passkey registration status of the authenticated user "Dave". Since the passkey of the authenticated user "Dave" is not registered, in S1509 the local login service 302 checks whether the authenticated user "Dave" is a user who has logged in for the first time. If the authenticated user is not a user who has logged in for the first time, the local login service 302 performs only simple login authentication and ends the login process (S1521). If the authenticated user is a user who has logged in for the first time, in S1510 the local login service 302 performs a process of displaying the registration screen 1306 that prompts the user to register a passkey before performing the authentication process. If the login user performs passkey registration in S1511, the local login service 302 performs the passkey registration process from S703 to S724 described above in S1512, and performs the login process (S1521). If the login user does not register a passkey, the local login service 302 executes only simple login authentication and ends the login process (S1521).

[0128] Furthermore, when authentication is performed using "Carol" shown in the user database 401, FIDO authentication is set to be forced, but passkey registration has not been performed. Therefore, in S1513, the local login service 302 executes processing to display the passkey registration screen 1305 before executing authentication processing. Next, if the login user executes passkey registration in S1514, the local login service 302 executes the passkey registration processing from S703 to S724 described above in S1516. After executing the passkey registration processing, the local login service 302 executes the login processing shown in S1521 and ends the processing. If the login user does not execute the passkey registration processing, the local login service 302 cancels the simple login authentication processing and executes processing to display a passkey non-registration error screen in S1515.

[0129] Furthermore, when authentication is performed using "Alice" shown in the user database 401, FIDO authentication is mandatory and passkey registration has already been performed, so in S1517 the local login service 302 executes the mobile authentication screen 1302 display process. After the mobile authentication screen 1302 display process, in S1518 the local login service 302 executes the passkey authentication process from S802 to S818 described above.

[0130] Here, in S818 of FIG. 15, the FIDO service 303 verifies the digital signature using a public key corresponding to the user who executed the simple login authentication. In S817, if "the public key of the passkey is not registered in association with the user ID" or "the public key is registered but is different from the user ID who executed the simple login authentication", S818 is not performed and failure is notified in S1519. In addition, if the verification is not successful in S818 due to reasons such as "verification of the digital signature failed", failure is notified in S1519. The local login service 302 may also be notified of the error and a message of authentication failure may be displayed on the mobile authentication screen 501. In the case of authentication failure, the local login service 302 cancels the simple login authentication process and executes display processing of a public key mismatch error screen in S1520. In the case of successful verification, the local login service 302 executes login processing shown in S1521 and ends the process.

[0131] <Effects> Since users can log in to the operation panel using the biometric authentication function of their mobile device, passwordless login can be provided without additional costs such as IC card reading devices. In addition, it is secure because it uses digital signature verification technology using a passkey, which is also used in FIDO. Furthermore, this invention does not require an external FIDO server and can perform verification only on the image forming device.

[0132] We have provided a means to disable password authentication for users who have registered a passkey. Disabling password authentication is safe and eliminates security concerns such as brute force password attacks and password leaks.

[0133] The mobile device has a function that allows users to photograph the QR code with the mobile camera and launch a standard browser to access the URL embedded in the QR code. This means that there is no need for a dedicated mobile app, and users can use this function with just the standard camera and browser on their mobile device.

[0134] <Second embodiment> In the first embodiment, an example in which a standard camera and browser provided in a mobile terminal are used has been described.

[0135] As another embodiment, as shown in Fig. 9, a vendor may provide an MFP application 901 that can be installed in the mobile terminal 102. Fig. 12 shows an example of an operation screen of the mobile terminal 102 when the MFP application 901 is used.

[0136] The MFP application 901 includes a WebView 902. The WebView 902 is a component that includes a function equivalent to that of a web browser. The MFP application 901 can store the address and user ID of the MFP 101 in a storage area of ​​the MFP application 901 in advance.

[0137] The MFP application 901 starts the camera and displays a QR code capture button on a screen 1201. It detects that the QR code capture button has been pressed and captures the QR code. Next, the MFP application 901 acquires the address obtained from the QR code and starts the WebView 902 (screen 1202). The WebView 902 accesses the address obtained from the QR code. At this time, it transmits a user ID that has been registered in advance in the MFP application 901. The WebView 902 performs the role of the web browser 314 in the flow from S806 to S819 in the first embodiment. Finally, it is preferable that the MFP application 901 detects that it has received the response of S819 and closes the WebView 902.

[0138] Also, the MFP may be selected from a screen 1203 of the MFP application 901, and the URL of the address stored in association with the selected MFP may be accessed from the WebView 902.

[0139] Alternatively, a configuration may be adopted in which a PIN code is used to confirm that the user is in front of the MFP 101. The PIN code is a random number. In this case, in S804, a random PIN code is displayed on the mobile authentication screen 501. In S809, an HTML screen 1204 having a text field for entering a PIN code is returned, and the user is prompted to enter the PIN code that he or she visually confirmed on the mobile authentication screen 501 into the HTML screen 1202.

[0140] Also, the MFP may be selected from screen 1205 of the MFP application 901, and passkey authentication may be performed without requiring QR code photography or PIN code input. In this case, since it is not possible to confirm whether the user performing the mobile operation is in front of the MFP, the configuration allows the user to log in to the operation panel of the MFP from a remote location.

[0141] <Other embodiments> The present invention can also be realized by supplying a program that realizes one or more functions of each of the above-mentioned embodiments to a system or device via a network or a storage medium, and having one or more processors in a computer of the system or device read and execute the program. It can also be realized by a circuit (e.g., ASIC or FPGA) that realizes one or more functions. [Explanation of symbols]

[0142] 101 MFP 102 Mobile devices 205 Operation Panel 302 Local Login Service 303 FIDO Services 312 Authenticator 314 Web Browser 501 Mobile authentication screen 1301 Simple login authentication screen

Claims

1. An image forming apparatus capable of communicating with a terminal having an authentication function, a transmitting means for transmitting verification data for performing user authentication of the image forming apparatus to the terminal; a receiving means for receiving, from the terminal, signature data obtained by encrypting the verification data using a private key corresponding to the authentication based on the authentication being performed by the authentication function of the terminal; a verification means for verifying the received signature data by using the verification data and a public key corresponding to the private key; having If the verification is successful, a function that is premised on the user authentication is provided.

1. An image forming apparatus comprising:

2. The image forming apparatus is an image forming apparatus including a printer, If the verification is successful, a printing function with a predetermined print setting is provided by the printer as a function premised on the user authentication.

2. The image forming apparatus according to claim 1,

3. The image forming apparatus is an image forming apparatus including a scanner, If the verification is successful, a function of transmitting image data obtained by scanning with the scanner to an external device is provided as a function premised on the user authentication.

2. The image forming apparatus according to claim 1,

4. If the verification is successful, a function is provided that, as a prerequisite for the user authentication, allows a user to select a destination from an address book when specifying a destination of image data obtained by scanning with the scanner.

4. The image forming apparatus according to claim 3.

5. The image forming apparatus is an image forming apparatus including a printer and a scanner, If the verification is successful, a function for setting up printing using the printer and scanning using the scanner is provided as a function premised on the user authentication.

2. The image forming apparatus according to claim 1,

6. a registration unit for registering the public key corresponding to the private key in the image forming apparatus; The verification means performs the verification using the registered public key.

2. The image forming apparatus according to claim 1,

7. The registration means includes: Transmitting verification data for registering the public key to the terminal; receiving, from the terminal, the public key corresponding to the private key generated based on authentication by the authentication function of the terminal, and signature data for registration obtained by encrypting verification data for the registration using the private key; When the signature data for the registration is successfully verified using the verification data for the registration and the received public key, the received public key is registered in the image forming apparatus.

7. The image forming apparatus according to claim 6,

8. 7. The image forming apparatus according to claim 6, wherein the public key is registered in association with user information of a user who uses the image forming apparatus.

9. a display control unit for displaying a QR code including information of a URL for accessing the image forming apparatus on an operation panel of the image forming apparatus; The transmission means transmits the verification data to the terminal when it detects an access to the URL from the terminal.

2. The image forming apparatus according to claim 1,

10. A user operation is accepted to select a method for performing the user authentication from options including a method using the public key and a method using a password input by the user.

2. The image forming apparatus according to claim 1,

11. 2. The image forming apparatus according to claim 1, wherein the authentication function of the terminal is a function for authenticating biometric information.

12. The device further includes a receiving means for receiving a selection of an icon corresponding to a user, The verification means performs the verification by using a public key that is managed in association with the user corresponding to the selected icon as the public key corresponding to the verification data and the private key.

2. The image forming apparatus according to claim 1,

13. a management means for managing information indicating whether or not the verification is to be performed in association with a user; a display control means for displaying a screen for transmitting the verification data to the terminal when an icon corresponding to a user associated with the information to be verified is selected by the reception means; The image forming apparatus according to claim 12 , further comprising:

14. A method for controlling an image forming apparatus capable of communicating with a terminal having an authentication function, comprising the steps of: a transmitting step of transmitting verification data for performing user authentication of the image forming apparatus to the terminal; a receiving step of receiving, from the terminal, signature data obtained by encrypting the verification data using a private key corresponding to the authentication based on the authentication being performed by the authentication function of the terminal; a verification step of verifying the received signature data by using the verification data and a public key corresponding to the private key; having If the verification is successful, a function that is premised on the user authentication is provided. A control method comprising:

15. An image forming apparatus capable of communicating with a terminal having an authentication function, a transmitting means for transmitting verification data for performing user authentication of the image forming apparatus to the terminal; a receiving means for receiving, from the terminal, signature data obtained by encrypting the verification data using a private key corresponding to the authentication based on the authentication being performed by the authentication function of the terminal; a verification means for verifying the received signature data by using the verification data and a public key corresponding to the private key; A program for causing the device to function as a If the verification is successful, a function that is premised on the user authentication is provided. A program characterized by:

Images