JP2009100195A - Authentication client device, authentication server device, user authentication system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To achieve a safe user authentication system on a stateless communication protocol without depending on a third party. <P>SOLUTION: A client device creates a set of a public key and a private key, transmits the public key, receives a common key encrypted by the public key, and transmits authentication information using the received common key. A server device has a function of receiving the public key, creating the common key, encrypting it by the public key, and transmitting the encrypted common key, and a function of receiving the authentication information encrypted by the common key, decrypting the authentication information and performing authentication processing. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to an authentication client device, an authentication server device, and a user authentication method that perform user authentication using a stateless communication method.

  Examples of conventional techniques for performing user authentication using a stateless communication method typified by HTTP include basic authentication and digest authentication (see, for example, Non-Patent Document 1). Furthermore, in order to protect the authentication information on the communication system path, an encryption process of a path such as SSL or TLS may be added to the basic authentication (for example, see Non-Patent Document 2).

A method using a dedicated server (for example, see Patent Document 1) has been devised for user authentication using a WEB service. Alternatively, authentication based on PKI is used.
JP 2005-18748 A RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication-HTTP / 1.1) RFC4346 (The TLS Protocol, Version 1.1)

  However, the conventional techniques described above have the following disadvantages.

  When basic authentication is used, confidential information such as a user name and a password flows in plain text on the communication path, so that there is a possibility that the confidential information is intercepted by a third party on the path.

  When using route encryption such as SSL or TLS, it is necessary to introduce a security certificate into the authentication server. Furthermore, it is necessary to request the certificate issuing organization to issue a trustworthy security certificate, which is a barrier to the introduction of SSL and TLS.

  Regarding the authentication technology based on PKI, the authentication server needs to have a certificate, and there is a problem similar to SSL and TLS.

  In the prior art described in Patent Document 1, it is necessary to separately install a server for WEB service authentication, which is a burden on the user. Further, both the server and the client need to be connected to the authentication server in addition to the mutual connection, and there is a problem that the program configuration becomes complicated.

  In order to solve the above-described problem, an authentication client device according to the present invention has a function of creating a key pair of a secret key and a public key, and a common key request function for transmitting the public key to the authentication server and requesting a common key And an authentication information transmission function for encrypting authentication information and a request using the common key received from the authentication server and transmitting the request to the authentication server, and a request reception function for receiving the execution result of the request from the authentication server. . Furthermore, the authentication server device according to the present invention receives a common key request including a public key from an authentication client and retrieves a public key in the request, a common key generation function for generating a common key, A common key transmission function for encrypting the common key with the public key extracted by the common key request reception function and transmitting it to the authentication client, and authentication information for receiving the encrypted authentication information and request from the authentication client A reception function; an authentication information decryption function that decrypts data received by the authentication information reception function and retrieves authentication information and a request; an authentication information verification function that verifies authentication information retrieved by the authentication information decryption function; A request execution function for executing a request fetched by the previous authentication information decryption function when authentication is performed by the authentication information verification function; The results, characterized in that it comprises a request execution result transmitting function of transmitting to the authentication client.

  According to the present invention, user authentication using a stateless communication method can be performed without using a security certificate or an authentication-dedicated server, and user convenience can be improved. Furthermore, authentication information on the communication path can be encrypted, and the confidentiality of the authentication information on the communication path can be increased.

  Next, details of the present invention will be described in accordance with the description of the embodiments.

  FIG. 1 is a diagram showing an arrangement of an authentication server device and an authentication client device that implements a user authentication method according to the first embodiment of the present invention. In the figure, reference numeral 101 denotes a local area network (LAN), and each device is connected to the LAN. Reference numeral 102 denotes an authentication server device, which operates a program that performs user authentication in response to a request from an authentication client and executes a requested process. Reference numerals 103 and 104 denote authentication client apparatuses, which transmit authentication information to the authentication server 102, request execution of processing, and receive the results. Reference numeral 103 denotes a PC, and a program that implements the authentication client process of the present invention operates on the operating system in 103. For example, 104 is a digital multi-function peripheral. In recent years, an increasing number of digital multifunction peripherals are connected to a network and have a function of requesting processing to various servers on the network. Some digital multifunction peripherals are provided with a function capable of adding a dedicated application, and this application may implement an authentication client function.

  FIG. 2 is a block diagram illustrating a hardware configuration of a host computer that operates as the authentication server 102 and the authentication client 103.

  In FIG. 1, a host computer 201 includes a CPU 202, a RAM 203, a ROM 204, and an external storage device 211. The CPU 202 executes software stored in the ROM 204 or the external storage device 211, and comprehensively controls each device connected to the system bus 205. The RAM 203 functions as a main memory or a work area for the CPU 202. The external storage device 211 includes a hard disk (HD), a flexible disk (FD), and the like. The external storage device 211 stores various applications including a boot program, an operating system, an authentication server, an authentication client, database data, font data, user files, and the like.

  In the host computer 201, reference numeral 206 denotes a keyboard controller (KBDC), which sends input information from a keyboard (KBD) 207 or a pointing device (not shown) to the CPU 202. Reference numeral 208 denotes a video controller (VC), which controls display on the display device 209 made up of CRT, LDC, or the like. Reference numeral 210 denotes a disk controller (DKC) that controls access to the external storage device 211. A communication controller (COMM I / F) 212 is connected to the network 101 via this communication controller.

  FIG. 3 is a block diagram illustrating a configuration of the digital multifunction peripheral 103 on which the authentication client operates.

  The CPU 301 executes software for controlling the entire digital multi-function peripheral 103 stored in the ROM 302 or the hard disk (HDD) 305, and comprehensively controls each device connected to the system bus 306. The RAM 303 functions as a work area for the CPU 301. The HDC 304 is a hard disk controller that controls the HDD 305. A reader I / F 307 and a printer I / F 308 are connected to a reader unit 311 and a printer unit 312, respectively, and control these devices. The operation unit I / F 309 is connected to the operation unit 313 and controls display on the operation unit 313 and user input from the operation unit 313. Reference numeral 313 denotes an operation unit, which includes a switch for operation and a display unit. A network interface card (NIC) 314 exchanges data with the host computer via the network 101.

  Here, a portion surrounded by a broken line in the drawing is referred to as an overall control unit 310. The overall control unit 310 is a part that controls various devices and interfaces connected to the digital multifunction peripheral 103 and also controls the operation of the entire digital multifunction peripheral.

  The reader unit 311 reads an image of a document, and outputs image data corresponding to the document image to the printer unit 312 or saves it in a storage device inside the digital multi-function peripheral 103 according to an instruction from the user. Further, image data is transmitted to a host computer connected to the network 101 via the network I / F 314.

  The printer unit 312 prints a document read by the reader unit 311 and image data stored in the storage device 305 in the digital multi-function peripheral body. Further, print data from a host computer connected to the network 101 is received via the network I / F unit 314 and printed.

  The network I / F unit 314 is connected to the network 101, and the overall control unit 310 is used for mutual communication with other information devices on the network 101 such as a host computer and the authentication server 102.

  The operation unit 313 notifies the overall control unit 310 of information display from the overall control unit 310 and user input by using buttons and a display device, a liquid crystal display screen with touch panel input, or a combination thereof.

  FIG. 4 is a block diagram showing a software configuration in the authentication server 102. Although the operating system is omitted in the figure, each block in the figure operates on the operating system.

  In the figure, 401 is a program that implements the function of an authentication server. The program 401 is controlled by the WEB service server control unit. Reference numeral 407 denotes a communication control unit, which performs processing such as transmitting data to the network 101 by the program and passing specific data from the network 101 to the program. For example, a request transmitted from the authentication client 103 or 104 is passed to the WEB service server control unit 402 via the communication processing unit 407 and processed. Conversely, the processing result is returned to the authentication client 103 or 104 via the communication control unit 407 and the network 101.

  A user information management unit 403 performs user authentication processing and the like, and a primary use key management unit 404 manages a common key for primary use. A database 406 stores user authentication information and primary usage keys, and is used by the user information management unit 403 and the primary usage key management unit 404. The user information management unit 403 inquires the database 405 about the validity of the specified authentication information and whether or not the user who is authorized to execute the given request has the authority. The temporary use key management unit 404 is a module that is responsible for managing a common key for primary use. Reference numeral 405 denotes a request execution unit that executes processing requested by the authentication client.

  FIG. 5 is a flowchart showing a processing flow of the authentication client and the authentication server. The figure is divided into three parts in the vertical direction. The left end shows processing in the authentication client 103, and the right end shows processing in the authentication server 102. The central part shows the contents of the packet flowing on the network 101. Since the communication is stateless, the connection is disconnected by a single transmission / reception. In order to show this, each connection is surrounded by a broken line. In the case of the figure, the communication from step S501 to step S502 and the communication from step S503 to step S504 are independent connections.

  Hereinafter, the flow of processing will be described with reference to FIG.

  The user authentication process starts when the authentication client sends a public key to the authentication server and requests a common key for encryption. First, in step S501, the authentication client 103 creates a key pair of a public key and a private key, creates a connection with the authentication server, sends the created public key to the authentication server, and sends a common key for encryption. Request. Reference numeral 521 denotes a common key request packet including the public key created in step S501 transmitted from the authentication client 103 to the authentication server 102.

  In step S511, the authentication server 102 receives the common key request packet 521. In the subsequent step S512, an encryption common key and an identifier for uniquely identifying the common key are created and stored in a temporary key storage table in the database 405. It is conceivable that the key identifier is automatically generated in the database when the common key is stored, but in this case, since it is often a serial number, it is considered to generate the identifier based on a random number. If the created identifier has already been registered at the time of storage in the database 405, an attempt is made to create the identifier and store the key again. Finally, in step S513, the authentication server 102 encrypts the created common key and key identifier with the public key received in step S511, and returns the encrypted key to the authentication client 103. Reference numeral 522 denotes a packet including the common key and the key identifier created in step S513 returned from the authentication server 102 to the authentication client 103. Even when this packet 522 is wiretapped by a third party on the network 101, the secret key created in step S501 is necessary for decryption, and the common key is not leaked to the third party.

  The authentication client receives the packet 522 in step S502, decrypts it with the secret key created in step S501, and takes out the common key and key identifier created by the authentication server 102 in step S512. When the decryption of the packet 522 is started, the pair of the public key and the secret key created in step S501 is unnecessary and is deleted. The processing up to this point is processed by one connection between the authentication client and the authentication server.

  At this point, the authentication client is ready to securely send authentication information and a request to the authentication server. In step S503, the authentication client 103 encrypts the authentication information and the request using the common key received in step S502, and sends it to the authentication server 102 together with the key identifier received in step S502. The authentication client 103 holds authentication information previously input by the user on a storage device such as the RAM 203 or the external storage device 210 and uses it. Reference numeral 523 denotes a packet generated by the authentication client 103 in step S503 in which the authentication information and the request are encrypted with a common key and a key identifier is added thereto. Since the common key included in the packet 522 is concealed from a third party on the network 101, the data in the packet 523 is also concealed from the third party on the network 101.

  In step S514, the authentication server 102 receives the packet 523 from the authentication client 103, extracts the key identifier, and searches for a common key having the key identifier extracted from the temporary key storage table in the database 405. In step S515, the authentication information and request in the packet 523 are decrypted using the common key extracted from the database 405. The authentication information and the request to be executed have been successfully extracted.

  Subsequently, the validity of the authentication information extracted in step S516 is checked. If the authentication information is invalid, the result is returned to the authentication client without processing the request. If the authentication information is valid in step S516, it is further checked in step S517 whether the given user has the authority to execute the given request. If the user does not have the authority to execute the request, the result is returned to the authentication client without processing the request.

  Since the authentication information sent from the authentication client and the validity of the request have been confirmed by the processing so far, the request instructed from the authentication client 103 is processed in step S518, and the processing result is displayed in step S519. It returns to the authentication client 103. Upon returning the processing result, the result is encrypted using the common key generated from the common key created in step S512. The packet 524 is obtained by encrypting the result using a common key generated from the common key. Finally, the authentication server receives the packet 524 in step S504, generates a common key from the common key extracted in step S503, and decrypts the result.

  FIG. 6 is a flowchart showing processing in the primary usage key management unit 404. The processing is divided into primary usage key registration processing 601 and acquisition processing 611. The primary usage key is stored in a relational database as a table having a key identifier and a common key in columns. At this time, since the key identifier is defined as the primary key, a column having a duplicate key identifier cannot be inserted.

  First, the primary usage key registration process 601 will be described. This is the process called at step 512 in FIG. The primary usage key registration process 601 is given a common key, inserts it into the table of the database, and returns a key identifier. First, in step S602, a key identifier is created by using a random number. In step S603, the key identifier created in step S602 and the given common key are inserted into the table. As described above, duplication of key identifiers is not allowed, so if the created key identifier already exists in the table, the insertion fails. In step S604, the result of insertion into the table is acquired. If the insertion fails, the process returns to step S602 to create another key identifier and try again to insert into the table. This series of processing is repeated until the insertion into the table is successful. If the insertion into the table is successful, the key identifier inserted into the table is returned in step S605.

  The primary usage key acquisition process 611 is a process for acquiring the temporary key registered in the temporary usage key registration process 610 from a table in the database. This is a process called in step S514 in FIG. 5, which is given a key identifier, obtains a common key associated with the key identifier from the table, and returns it. In step S612, the process first searches the table for a common key having a given key identifier. In step S613, the search result is acquired. If acquisition fails, the process jumps to step S614 and an error is returned to the caller. If the acquisition is successful, in the subsequent step S615, the row having the given key identifier is deleted from the table. With this process, even if the primary key acquisition process 611 is called again using the same key identifier, an error is returned. Finally, in step S616, the common key acquired in step S612 is returned to the caller.

  The second embodiment of the present invention is an example in which the user authentication method of the present invention is applied to management software for various devices connected on a network. In the case of a large-scale network, it is difficult to manage all devices in the network with a single device management software. For this reason, a plurality of device management software is arranged in each network, and these are interconnected to cope with device management in a large-scale network. For example, a hierarchical relationship is established between the device management software, the lower device management software periodically monitors the status of each device, and the higher device management software collects the results. This makes it possible to reduce processing load distribution and network traffic. In this case, it is necessary to establish a mutual trust relationship between the device management software distributed in each network.

  In this embodiment, each device management software has a set of public key and private key. Each device management software establishes a mutual trust relationship by exchanging each public key. Communication between device management softwares that have established a trust relationship can ensure confidentiality by encrypting data using the other party's public key and signing data using its own private key.

  FIG. 7 is a diagram showing the arrangement of device management software that implements the user authentication method according to the second embodiment of the present invention. In the figure, reference numerals 701 and 711 denote local area networks having separate subnets, and the networks are connected to each other by a router device 710. Device management software 702 and 712 are connected to the networks 701 and 711, respectively, and manage devices connected to the respective subnets. Reference numerals 703 to 706 and 713 to 716 denote devices to be managed by the device management software 702 and 712, such as printers and digital multifunction peripherals, connected to the respective networks. Reference numeral 707 denotes a host computer used by a network administrator, which operates the network management software 702 and 712 via a WEB browser.

  FIG. 8 shows the format of data used for communication between device management software having a trust relationship. In the figure, a state in which data is transmitted from the device management software 702 to the device management software 712 is shown. Assume that the device management software identifiers 702 and 712 are “A” and “B”, respectively.

  In FIG. 8, reference numeral 801 denotes a pair of a private key and a public key of the device management software itself held in the device management software 702. Reference numeral 802 denotes a list of identifiers and public keys of device management software having a trust relationship with the device management software 702. Similarly, reference numeral 803 denotes a pair of a private key and a public key of the device management software itself held in the device management software 712. Reference numeral 804 denotes a list of identifiers and public keys of device management software that has a trust relationship with the device management software 712.

  Reference numeral 810 denotes the contents of a packet transmitted from the device management software 702 to the device management software 712 via the network 101.

  The contents of the packet are as follows. 811 is an identifier of the source device management software, which is “A” in this example. Reference numeral 812 denotes a public key of the transmission destination, that is, a common key for data encryption encrypted with the public key B. Reference numeral 813 denotes an initial vector used when data is encrypted with the public key 812. Reference numeral 814 denotes a data signature with the secret key of the transmission source, that is, the secret key A. Reference numeral 815 denotes data encrypted with the common key 812 and the initial vector 813.

  Upon receiving this packet, the device management software 712 decrypts the common key 812 with its own secret key B, and decrypts the data 815 using the initial vector 813. Based on the identifier of the transmission source device management software 811, the device management software 712 acquires the public key of the transmission source device management software from the list of the device management software 712 having the trust relationship. The device management software 712 uses the public key A of the acquired source device management software to verify the signature of the decrypted data, thereby ensuring that the data is from the device management software A.

  FIG. 9 is a flowchart showing a procedure for establishing a trust relationship between device management software using the user authentication method of the present invention. Here, it is assumed that the device management software 702 and 712 have not yet established a trust relationship, and establish a trust relationship by this procedure.

  In the figure, the process surrounded by a broken line 921 is the same as the flow of the authentication process shown in FIG. 5 of the first embodiment. Here, the authentication client 103 corresponds to the device management software 702, and the authentication server 102 corresponds to the device management software 712. The authentication information transmitted in step S503 in FIG. 5 is the administrator ID and password of the device management software 712, and the request is to send the public key of the device management software 712, that is, the public key B. Since the processing of this portion is the same as that in FIG.

  As a result of the user authentication and execution of the request, the device management software 702 receives the public key B of the device management software 712 in step S903. Further, the received public key B is provisionally registered in a list of identifiers and public keys of device management software having a trust relationship 802 in FIG. After that, in step S904, the device management software 702 sends its public key A to the device management software 712 and requests to register it in the public key list 804 of the device management software 712. At this time, the packet 927 sent from the device management software 702 to the device management software 712 is encrypted and signed in the format 810 of FIG. Therefore, it is very difficult for a third party on the network 101 who eavesdrops on the packet 927 to decrypt the public key A. In step S913, the device management software 712 receives the packet 927, decrypts it, and registers the public key A included in the packet in the public key list 804. When registration is completed, a message to that effect is returned to the device management software 702 (packet 928).

  Finally, in step S905, the device management software 702 permanently registers the public key B temporarily registered in step S903 in the public key list 802.

  Through the above procedure, a trust relationship is established between the device management software 702 and the device management software 712.

  In this example, the operator of the device management software 702 knows the authentication information of the administrator of the device management software 712. However, the operator of the device management software 712 does not know the authentication information of the administrator of the device management software 702. Therefore, the trust relationship is such that the device management software 702 is higher in the hierarchical structure and the device management software 712 is lower.

It is a figure which shows arrangement | positioning of the authentication server apparatus and authentication client apparatus which mounted the user authentication system which concerns on the 1st Embodiment of this invention. 2 is a block diagram illustrating a hardware configuration of a host computer that operates as an authentication server 102 and an authentication client 103. FIG. 2 is a block diagram illustrating a configuration of a digital multifunction peripheral 103 on which an authentication client operates. FIG. 2 is a block diagram illustrating a software configuration in an authentication server 102. FIG. It is a flowchart which shows the flow of a process of an authentication client and an authentication server. It is a flowchart which shows the process in a primary use key management part. It is a figure which shows arrangement | positioning of the device management software which mounted the user authentication system which concerns on the 2nd Embodiment of this invention. It shows the format of data used for communication between device management software that has established a trust relationship. It is the flowchart which showed the procedure which builds the trust relationship between device management software using the user authentication system of this invention.

Explanation of symbols

202, 301 CPU
203, 303 ROM
204, 302 RAM
205, 306 System bus 206 Keyboard controller 207 Keyboard 208 Video controller 209 Display device 210, 304 External storage device controller 211, 305 External storage device 212, 314 Network interface 307 Reader interface 308 Printer interface 309 Operation unit interface 311 Reader unit 312 Printer unit 313 Operation unit

Claims (11)

An authentication client device that performs user authentication using a stateless communication method,
The ability to create a private / public key pair;
A common key request function for transmitting the public key to the authentication server and requesting a common key;
An authentication information transmitting function for encrypting authentication information and a request using the common key received from the authentication server and transmitting the request to the authentication server; and a request receiving function for receiving the execution result of the request from the authentication server. A featured authentication client device.   The authentication client device according to claim 1, wherein HTTP is used as a stateless communication method.   The execution result from the authentication server is encrypted with a common key or a common key generated from the common key, and has an execution result decryption function for decrypting the encrypted execution result. The authentication client device according to claim 2. An authentication server device that performs user authentication using a stateless communication method,
A common key request receiving function for receiving a common key request including a public key from an authentication client and extracting the public key in the request;
A common key generation function for generating a common key;
A common key transmission function for encrypting the common key with the public key extracted by the common key request reception function and transmitting the encrypted key to the authentication client;
An authentication information receiving function for receiving encrypted authentication information and a request from the authentication client;
An authentication information decryption function for decrypting the data received by the authentication information reception function and retrieving the authentication information and the request;
An authentication information verification function for verifying the authentication information extracted by the authentication information decryption function;
A request execution function for executing the request extracted by the previous authentication information decryption function when authentication is performed by the authentication information verification function;
An authentication server apparatus comprising a request execution result transmission function for transmitting a request execution result to the authentication client.   5. The authentication server device according to claim 4, wherein HTTP is used as a stateless communication method.   The authentication server device according to claim 4 or 5, further comprising an execution result encryption function for encrypting an execution result with a common key or a common key generated from the common key.   6. The authentication server apparatus according to claim 4, wherein the generated common key is used only for a subsequent authentication information decryption function and then discarded.   7. The authentication server device according to claim 6, wherein the generated common key is used only in the subsequent authentication information decryption function and execution result encryption function, and then discarded. It is a user authentication method that performs user authentication using a stateless communication method,
The authentication client
The ability to create a private / public key pair;
A common key request function for transmitting the public key to the authentication server and requesting a common key;
Using a common key received from the authentication server, an authentication information transmission function for encrypting authentication information and a request and transmitting the request to the authentication server;
The authentication server
A common key request receiving function for receiving the common key request and extracting a public key in the request;
A common key generation function for generating a common key;
A common key transmission function for encrypting the common key with the public key extracted by the common key request reception function and transmitting the encrypted key to the authentication client;
An authentication information receiving function for receiving encrypted authentication information and a request transmitted by the authentication client by the authentication information transmitting function;
An authentication information decryption function for decrypting data received by the authentication information reception function and retrieving authentication information and a request;
An authentication information verification function for verifying the authentication information extracted by the authentication information decryption function;
A request execution function for executing the request extracted by the previous authentication information decryption function when authentication is performed by the authentication information verification function;
A user authentication method comprising a request execution result transmission function for transmitting a request execution result to the authentication client.   The user authentication method according to claim 9, wherein HTTP is used as a stateless communication method. The authentication server has an execution result encryption function for encrypting an execution result with a common key or a common key generated from the common key,
The user authentication method according to claim 9 or 10, wherein the authentication client has an execution result decryption function for decrypting the encrypted execution result.

Images