Communication system, certificate authority and method

Abstract

To provide a communication system, a certificate authority, and a method capable of easily issuing a certificate used for communication.SOLUTION: A communication system according to an embodiment includes communication devices, an terminal, and a certificate authority. The communication apparatus is configured to transmit a certificate signing request to the terminal. The terminal transmits the certificate signing request transmitted from the communication apparatus to the certificate authority. The certification authority issues a certification in response to the certification signing request transmitted from the terminal, and executes a billing process for billing the cost for the issuance of the certification.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] FIELD OF THE INVENTION Embodiments of the present invention relate to a communication system, a certification authority and a method. [Background technology]

[0002] The technology known as IoT (Internet of Things) makes it possible to realize various IoT services by connecting edge devices (communication devices) to a network.

[0003] Incidentally, in order for the above-mentioned edge device to communicate with a server device that provides an IoT service via a network, a certificate is required to ensure the security of the communication (for example, a certificate for the public key of the edge device in a public key cryptography system). However, it is time-consuming for the user who owns the edge device to issue the certificate. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2021-100227 [Patent Document 2] Japanese Patent Application Publication No. 2023-073479 Summary of the Invention [Problem to be solved by the invention]

[0005] Therefore, an object of the present invention is to provide a communication system, a certification authority, and a method that can easily issue certificates used in communication. [Means for solving the problem]

[0006] A communication system according to an embodiment includes a communication device, a terminal device, and a certificate authority. The communication device transmits a certificate signing request to the terminal device, requesting the issuance of a certificate used by the communication device to communicate with a first server device. The terminal device transmits the certificate signing request transmitted from the communication device to the certificate authority. The certificate authority issues the certificate in response to the certificate signing request transmitted from the terminal device and executes a billing process to bill for the cost of issuing the certificate. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a diagram showing an example of a system configuration of a communication system according to a first embodiment. [Figure 2] FIG. 2 is a diagram showing an example of the functional configuration of an edge device. [Figure 3] FIG. 10 is a diagram showing an example of device information. [Figure 4] FIG. 2 is a diagram showing an example of the functional configuration of a user terminal. [Figure 5] FIG. 4 is a diagram showing an example of user information. [Figure 6] FIG. 10 is a diagram showing an example of server information. [Figure 7] FIG. 2 is a diagram showing an example of the functional configuration of a certificate authority. [Figure 8] FIG. 2 is a diagram illustrating an example of a hardware configuration of an edge device. [Figure 9] 1 is a sequence chart showing an example of a processing procedure of a communication system. [Figure 10] FIG. 10 is a diagram showing an example of a device confirmation screen. [Figure 11] FIG. 10 is a diagram showing an example of verification information. [Figure 12] FIG. 10 is a diagram showing another example of verification information. [Figure 13] FIG. 10 is a diagram showing yet another example of verification information. [Figure 14] FIG. 10 is a diagram showing yet another example of verification information. [Figure 15] FIG. 10 is a diagram showing an example of issuance history information. [Figure 16] FIG. 10 is a diagram showing an example of billing processing information. [Figure 17]10 is a sequence chart showing another example of the processing procedure of the communication system. [Figure 18] FIG. 10 is a diagram showing an outline of issuing a public key certificate in a comparative example of the present embodiment. [Figure 19] FIG. 2 is a diagram showing an outline of issuing a public key certificate in this embodiment. [Figure 20] FIG. 10 is a diagram showing an example of the system configuration of a communication system according to a second embodiment. [Figure 21] FIG. 2 is a diagram showing an example of the functional configuration of a user terminal. [Figure 22] 1 is a sequence chart showing an example of a processing procedure of a communication system. DETAILED DESCRIPTION OF THE INVENTION

[0008] Hereinafter, each embodiment will be described with reference to the drawings. (First embodiment) First, a first embodiment will be described. Fig. 1 shows an example of the system configuration of a communication system according to this embodiment. As shown in Fig. 1, the communication system 1 includes an edge device 10, a user terminal 20 (client terminal), a certificate authority 30, and a server device 40.

[0009] The edge device 10 is a device used in a technology called IoT, and is equipped with a host controller configured to control the operation of the edge device 10 and a communication device configured to provide communication functions to the edge device 10.

[0010] The host controller and the communication device are connected via a connection interface provided on the edge device 10, such as a USB connector or a pin slot connector, but serial communication such as I2C (Inter-Integrated Circuit), UART (Universal Asynchronous Receiver Transmitter) and SPI (Serial Peripheral Interface) or parallel communication may be performed between the host controller and the communication device.

[0011] In this embodiment, the edge device 10 may simply be referred to as a communication device, and includes an IoT device, a personal computer (PC), a gateway, or the like. The edge device 10 communicates with the server device 40 to operate as part of an application system for providing various IoT services. However, it is assumed that the edge device 10 in this embodiment is in a factory default state and therefore has not been configured to communicate with the server device 40. Note that the edge device 10 in a factory default state may be a device that has been used for another purpose in the past and then reset to the factory default state (i.e., initialized) by a predetermined operation.

[0012] The user terminal 20 is assumed to be a handheld terminal such as a smartphone or tablet terminal used by a user who owns the edge device 10 (the owner of the edge device 10), but may also be another type of terminal device such as a PC. The user terminal 20 has a user interface that accepts user input and presents information to the user. Note that, in this embodiment, the user who owns the edge device 10 is described as using the user terminal 20, but the user who uses the user terminal 20 may be different from the user who owns the edge device 10.

[0013] The certificate authority (authentication device) 30 is an information processing device configured to issue a certificate used by the edge device 10 to communicate with the server device 40. Specifically, when a public key cryptosystem is adopted to ensure security in the communication between the edge device 10 and the server device 40, the certificate authority 30 issues a certificate for the public key of the edge device 10 in the public key cryptosystem (a public key certificate of the edge device 10). When the public key certificate issued by the certificate authority 30 is registered in the edge device 10 in this manner, the edge device 10 becomes able to communicate with the server device 40 using the public key certificate.

[0014] The server device 40 operates to provide various IoT services by communicating with the edge device 10. Specifically, the server device 40 may operate to register sensor data collected by the edge device 10 in the server device 40, or may operate to issue a command to the edge device 10 to cause the edge device 10 to execute a predetermined process. Furthermore, the server device 40 may transmit firmware or software running on the edge device 10 to the edge device 10 and instruct the edge device 10 to update the firmware or software.

[0015] The processing of the server device 40 may be executed on a server computer managed on-premise at a base such as a business office, or may be executed on a virtual machine implemented on the server computer. The processing of the server device 40 may also be executed on a cloud platform on the Internet or within a communication network provided by a cloud service provider or the like.

[0016] 1 may be a wireless communication method or a wired communication method. Possible wireless communication methods include, but are not limited to, Bluetooth (registered trademark), Wi-Fi (registered trademark), ZigBee (registered trademark), or infrared communication. Possible wired communication methods include, but are not limited to, Ethernet (registered trademark), serial communication by UART, or CAN (Controller Area Network).

[0017] 1 are connected to each other so as to be able to communicate with each other via a network 51. The edge device 10 and server device 40 are connected to each other so as to be able to communicate with each other via a network 52.

[0018] The communication method applied to the communication between the user terminal 20 and the network 51 and the communication method applied to the communication between the edge device 10 and the network 52 may be a wireless communication method or a wired communication method, similar to the communication method applied to the communication between the edge device 10 and the user terminal 20 described above. The same applies to the communication method applied to the communication between the authentication authority 30 and the network 51 and the communication method applied to the communication between the server device 40 and the network 52.

[0019] Furthermore, the network 51 may be a small-scale, closed network such as a local area network (LAN), a wide-area, closed network such as a wide area network (WAN), or an open network such as the Internet. To connect to the network 51, the user terminal 20 performs communication based on, for example, Wi-Fi or a mobile phone communication method (LTE, 5G, etc.), but may also be configured to perform communication based on other standards. While the network 51 has been described here, the same applies to the network 52. The above-described networks 51 and 52 may be different networks or the same network.

[0020] Fig. 2 shows an example of the functional configuration of the edge device 10 shown in Fig. 1. As shown in Fig. 2, the edge device 10 includes a first communication unit 11, a second communication unit 12, a request generation unit 13, a device information management unit 14, a key management unit 15, a registration unit 16, and an application processing unit 17.

[0021] The first communication unit 11 communicates with the user terminal 20 in accordance with a predetermined communication method. The second communication unit 12 communicates with the server device 40 via the network 52.

[0022] 2, the first and second communication units 11 and 12 are shown as independent functional units, but the first and second communication units 11 and 12 may be realized as a single functional unit. Furthermore, the communication method by which the first communication unit 11 executes communication may be different from or the same as the communication method by which the second communication unit 12 executes communication.

[0023] The request generation unit 13 generates a certificate signing request for requesting the issuance of a public key certificate in accordance with an instruction from the user terminal 20, which will be described later. The certificate signing request generated by the request generation unit 13 is transmitted to the user terminal 20 via the first communication unit 11.

[0024] The device information management unit 14 manages information relating to the edge device 10 (hereinafter referred to as device information).

[0025] An example of device information is shown in Fig. 3. In the example shown in Fig. 3, the device information includes, for example, the manufacturer, model, serial number, installation location, administrator, and current time of the edge device 10.

[0026] The manufacturer, model, and serial number are, for example, information that is embedded in advance when the edge device 10 is manufactured (that is, information that is pre-registered in the edge device 10). The installation location and manager are, for example, information provided by the user terminal 20. The current time is, for example, initialized by information provided by the user terminal 20, and is automatically updated as time passes.

[0027] Furthermore, the device information includes, for example, the owner of the edge device 10 (device owner), the administrator who manages the server device 40 (server administrator), the user who uses the server device 40 (server user), the provider of the IoT service (IoT service provider), and a number (IoT service contract number) assigned to the end user who has entered into a contract with the IoT service provider to use the IoT service.

[0028] At least some of the owner, server administrator, server user, IoT service provider, and IoT service contract number may be information that is pre-embedded when the edge device 10 is manufactured, or may be information that is registered (set) after the edge device 10 is shipped from the factory.

[0029] In Figure 3, the device information is described as including the manufacturer, model, serial number, installation location, administrator, current time, user, server administrator, server user, IoT service provider, and IoT service contract number, but the device information may omit some of this information, or may include information other than this information (for example, model number, hardware version, etc.).

[0030] 3, the server administrator may be, for example, the manufacturer of the server device 40 or a cloud infrastructure provider. The server user may be the same as the IoT service provider that provides IoT services using the server device 40.

[0031] The key management unit 15 manages the public key and private key (key pair) of the edge device 10 in the public key cryptosystem. The certificate signing request generated by the request generation unit 13 includes the public key of the edge device 10 managed by the key management unit 15.

[0032] Here, the key pair of the edge device 10 may be generated in response to an instruction from the request generation unit 13 when the request generation unit 13 generates a certificate signing request. Alternatively, the key pair of the edge device 10 may be generated, for example, when the power of the edge device 10 is turned on in a factory-shipped state. Alternatively, the key pair of the edge device 10 may be generated in response to an instruction from the user terminal 20. Furthermore, the key pair of the edge device 10 may be stored in advance inside the edge device 10. Alternatively, if the key management unit 15 is implemented as a hardware security module such as a secure element, the key pair of the edge device 10 may be generated by the hardware.

[0033] Here, the key management unit 15 has been described as mainly managing the key pair of the edge device 10, but the key management unit 15 may also execute encryption processing and signature processing based on a public key cryptosystem.

[0034] The registration unit 16 executes a process of registering the public key certificate issued by the certificate authority 30 in response to the certificate signing request generated by the request generation unit 13 in the edge device 10 (key management unit 15).

[0035] The application processing unit 17 uses the public key certificate registered in the edge device 10 to perform authentication processing for the edge device 10 with the server device 40 (hereinafter referred to as device authentication processing).

[0036] When the edge device 10 is authenticated (i.e., authentication is successful) by executing the device authentication process, the application processing unit 17 performs communication (application communication) with the server device 40 via the second communication unit 12. The application processing unit 17 also performs processing on the edge device 10 side for providing IoT services (application processing corresponding to application communication). In this case, the application processing unit 17 may perform processing such as acquiring sensor data from a sensor mounted on the edge device 10 and transmitting it to the server device 40. The application processing unit 17 may also perform processing such as executing a command on the edge device 10 or operating an actuator connected to the edge device 10 in accordance with an instruction from the server device 40. The application processing unit 17 may also perform processing such as updating firmware or software of the edge device 10 in accordance with an instruction from the server device 40.

[0037] Fig. 4 shows an example of the functional configuration of the user terminal 20 shown in Fig. 1. As shown in Fig. 4, the user terminal 20 includes a first communication unit 21, a second communication unit 22, a user information management unit 23, a server information management unit 24, an initial setting processing unit 25, and a certificate acquisition unit 26.

[0038] The first communication unit 21 communicates with the edge device 10 in accordance with a predetermined communication method. The second communication unit 22 communicates with the certificate authority 30 via the network 51.

[0039] 4, the first and second communication units 21 and 22 are shown as independent functional units, but the first and second communication units 21 and 22 may be realized as a single functional unit. Furthermore, the communication method by which the first communication unit 21 executes communication may be different from or the same as the communication method by which the second communication unit 22 executes communication.

[0040] The user information management unit 23 manages information (hereinafter referred to as user information) relating to the user who owns the edge device 10 (the user who uses the user terminal 20).

[0041] An example of user information is shown in Fig. 5. As shown in Fig. 5, the user information includes, for example, the user's username (user ID), the user's affiliation, a user terminal ID for identifying the user terminal 20, and the version of the user terminal 20.

[0042] The user name and affiliation are, for example, information set by the user. The user terminal ID and version are, for example, information embedded in advance when the user terminal 20 is manufactured (that is, information registered in advance in the user terminal 20).

[0043] In Figure 5, the user information is described as including the user name, affiliation, user terminal ID, and version, but the user information may omit some of this information, or may include information other than this information.

[0044] The server information management unit 24 manages information relating to the server device 40 (hereinafter referred to as server information).

[0045] An example of the server information is shown in Fig. 6. As shown in Fig. 6, the server information includes, for example, the server name of the server device 40, a uniform resource locator (URL) for accessing the server device 40, and specifications of an application programming interface (API) implemented in the server device 40 (server API specifications).

[0046] The server name, URL, and server API specifications may be information set by the user, or may be information provided from outside the user terminal 20 (for example, the server device 40, etc.).

[0047] In Figure 6, the server information is described as including the server name, URL, and server API specifications, but the server information may omit some of this information, or may include information other than this information.

[0048] The initial setting processing unit 25 executes processing related to the initial setting of the edge device 10. Specifically, when the user terminal 20 is connected to the edge device 10, the initial setting processing unit 25 instructs the edge device 10 to generate a certificate signing request. In addition, during a series of initial settings of the edge device 10, the initial setting processing unit 25 provides the edge device 10 with (a part of) the above-mentioned user information and server information as information to be set in the edge device 10 (hereinafter referred to as setting information).

[0049] Furthermore, the initial setting processing unit 25 acquires a certificate signature request transmitted from the edge device 10 via the first communication unit 21. The initial setting processing unit 25 verifies the acquired certificate signature request.

[0050] If the verification of the certificate signing request by the initial setting processing unit 25 is successful, the certificate acquiring unit 26 transmits the certificate signing request to the certification authority 30 via the second communication unit 22. Furthermore, the certificate acquiring unit 26 acquires, via the second communication unit 22, the public key certificate of the edge device 10 issued by the certification authority 30 in response to the certificate signing request.

[0051] The public key certificate thus acquired by the certificate acquisition unit 26 is passed to the initial setting processing unit 25 and transmitted to the edge device 10 via the first communication unit 21.

[0052] Fig. 7 shows an example of the functional configuration of the certification authority 30 shown in Fig. 1. As shown in Fig. 7, the certification authority 30 includes a first communication unit 31, a verification information management unit 32, a request verification unit 33, a certificate issuance unit 34, an issuance history management unit 35, a claim processing unit 36, and a second communication unit 37.

[0053] The first communication unit 31 communicates with the user terminal 20 via the network 51. The verification information management unit 32 manages information (hereinafter referred to as verification information) used to verify a certificate signing request sent from the user terminal 20. The verification information includes, for example, information about a device owned by the user that can issue a public key certificate.

[0054] The request verification unit 33 acquires the certificate signing request transmitted from the user terminal 20 via the first communication unit 31. Using the verification information managed by the verification information management unit 32, the request verification unit 33 verifies whether the correspondence between the acquired certificate signing request and the user terminal 20 that is the sender of the certificate signing request or the user who uses the user terminal 20 is appropriate.

[0055] If the verification of the certificate signing request is successful, the certificate issuing unit 34 issues a public key certificate in response to the certificate signing request. The public key certificate issued by the certificate issuing unit 34 is transmitted to the user terminal 20 via the first communication unit 31.

[0056] The issuance history management unit 35 manages information (hereinafter referred to as issuance history information) related to public key certificates previously issued by the certificate issuance unit 34. Whether or not to issue the above-mentioned public key certificate may be determined based on the issuance history information (i.e., the history of public key certificates previously issued) managed by the issuance history management unit 35.

[0057] In this embodiment, as described above, a public key certificate is issued by the certification authority 30, and the billing processor 36 executes a process (hereinafter referred to as billing process) to bill for the cost of issuing the public key certificate (hereinafter referred to as the certificate issuance cost). Details of the billing process will be described later, but in the billing process, a process is executed in which billing data equivalent to an invoice describing the certificate issuance cost (i.e., billing data including the certificate issuance cost) is sent to the party to bill for the certificate issuance cost.

[0058] The second communication unit 37 communicates with an information processing device (hereinafter referred to as a billing destination device) managed by the billing destination of the certificate issuance fee.

[0059] 7, the first and second communication units 31 and 37 are shown as independent functional units, but the first and second communication units 31 and 37 may be realized as a single functional unit. The communication method used by the first communication unit 31 to execute communication may be different from or the same as the communication method used by the second communication unit 37 to execute communication.

[0060] Fig. 8 shows an example of the hardware configuration of the above-mentioned edge device 10. As shown in Fig. 8, the edge device 10 includes a processor 10a, a nonvolatile memory 10b, a main memory 10c, and a communication interface (I / F) 10d.

[0061] The processor 10a is configured to control the operation of each component in the edge device 10 and may be, for example, a CPU. The processor 10a may be a single processor or may be composed of multiple processors. The processor 10a executes various programs loaded from the non-volatile memory 10b to the main memory 10c. The communication interface 10d is an interface for realizing communication with, for example, the user terminal 20 and the server device 40.

[0062] In this embodiment, some or all of the units 11 to 17 shown in Figure 2 may be realized by having the processor 10a shown in Figure 8 execute a predetermined program (application program) (i.e., software), or may be realized by hardware such as an IC (Integrated Circuit), or may be realized by a configuration that combines software and hardware.

[0063] Although the hardware configuration of the edge device 10 has been described above, it is assumed that the user terminal 20 and the certificate authority 30 also have roughly the same hardware configuration.

[0064] In this case, some or all of the units 21 to 26 shown in Figure 4 may be realized by having a processor (CPU) provided in the user terminal 20 execute a predetermined program (i.e., software), or may be realized by hardware, or may be realized by a configuration that combines software and hardware.

[0065] Furthermore, some or all of the units 31 to 37 shown in Figure 7 may be realized by having a processor (CPU) provided in the certification authority 30 execute a predetermined program (i.e., software), or may be realized by hardware, or may be realized by a configuration that combines software and hardware.

[0066] In this embodiment, the user terminal 20 further includes an input device, a display device, and the like for realizing the above-described user interface.

[0067] An example of a processing procedure of the communication system 1 according to this embodiment will be described below with reference to the sequence chart of FIG.

[0068] In this embodiment, it is assumed that the edge device 10 is in a factory default state, and that at least a public key certificate used by the edge device 10 to communicate with the server device 40 has not been registered in the edge device 10. The communication system 1 according to this embodiment operates to realize issuance and registration of the public key certificate of the edge device 10 using the user terminal 20.

[0069] First, for example, when the power of the edge device 10 in a factory-shipped state is turned on, the edge device 10 enters a state of waiting for initial configuration, and the edge device 10 and the user terminal 20 are connected so as to be able to communicate with each other in response to a user operation on the user terminal 20. When the user terminal 20 is connected to the edge device 10 in this manner, the initial configuration processing unit 25 included in the user terminal 20 transmits a message to the edge device 10 via the first communication unit 21 requesting the start of initial configuration of the edge device 10 (hereinafter referred to as an initial configuration start message) (step S1). Note that by executing the process of step S1, the user terminal 20 instructs the edge device 10 to generate a certificate signing request.

[0070] When the initial setting start message is sent in step S1, setting information (information to be set in the edge device 10) obtained from user information managed by the above-mentioned user information management unit 23 may be provided from the user terminal 20 to the edge device 10.

[0071] Furthermore, if the edge device 10 does not have a real-time clock, the initial setup start message may include information on the current time provided by the user, which allows the edge device 10 to set its internal clock based on the information on the current time included in the initial setup start message.

[0072] The initial setting start message may also include information specified by the user, such as an identifier (user ID) for identifying the user and a random character string for nonce purposes.

[0073] Although it has been described herein that various information may be included in the initial setup start message, such information may also be included in other messages that follow the initial setup start message.

[0074] When the processing of step S1 is executed, the initial setting start message sent in step S1 is received by the first communication unit 11 included in the edge device 10, and the request generation unit 13 obtains the initial setting start message from the first communication unit 11.

[0075] The request generation unit 13 generates a certificate signing request for issuing a public key certificate in response to the acquired initial setup start message (i.e., an instruction to generate a certificate signing request). The certificate signing request generated by the request generation unit 13 is, for example, a Certificate Signing Request (CSR) in accordance with PKCS#10 (RFC2986) of the Public-Key Cryptography Standards (PKCS).

[0076] In this embodiment, the billing process for claiming the certificate issuance fee is executed by the certification authority 30, but the billing process must be executed to the billing destination of the certificate issuance fee. Therefore, the request generation unit 13 generates a certificate signing request including information indicating the billing destination of the certificate issuance fee (hereinafter referred to as billing destination information).

[0077] In this case, for example, the initial setting start message sent from the user terminal 20 in the above-mentioned step S1 includes instructions regarding the billing destination, and the request generation unit 13 generates a certificate signing request including the billing destination information obtained from the device information based on the instructions.

[0078] To explain this in more detail with reference to Figure 3, for example, if it is specified that the billing destination is the device owner (the user who owns the edge device 10), the request generation unit 13 obtains the device owner "F1" from the device information and generates a certificate signing request that includes the device owner "F1" as billing destination information.

[0079] Also, for example, if it is specified that the billing destination is a server user, the request generation unit 13 obtains the server user "H1" from the device information and generates a certificate signing request that includes the server user "H1" as billing destination information.

[0080] Here, the case where the billing destination is the device owner and the server user has been described, but the request generating unit 13 may generate a certificate signing request including billing destination information in accordance with an instruction from the user terminal 20.

[0081] The billing destination may be specified based on, for example, information stored in the user terminal 20. The information stored in the user terminal 20 may be, for example, information managed as part of the user information by the user information management unit 23, or may be information stored in advance in an application program that is started on the user terminal 20 when the above-mentioned initial setting is performed. The billing destination may be specified by the user who uses the user terminal 20.

[0082] Although the billing destination is specified from the user terminal 20 in the above description, the billing destination may be registered (set) in advance in the edge device 10.

[0083] In addition, although it has been described here that information obtained from device information managed in the edge device 10 (device information management unit 14) is used as billing information, for example, if the information used as billing information is not managed in the device information, the edge device 10 may obtain (receive) the billing information directly from the user terminal 20.

[0084] Furthermore, although the certificate signing request has been described as including billing information, the edge device 10 (and the user terminal 20) need only operate to generate a certificate signing request including the specified information, and does not need to recognize that the information is billing information (information related to billing processing).

[0085] The certificate signing request generated by the request generating unit 13 as described above is transmitted to the user terminal 20 via the first communication unit 11 (step S2).

[0086] The certificate signing request sent in step S2 includes the public key of the edge device 10 managed by the key management unit 15, but may also include device information managed by the device information management unit 14 (such as the manufacturer, model number, type, serial number, and hardware version of the edge device 10).

[0087] The certificate signing request sent in step S2 may also include some of the various information included in the above-mentioned initial setting start message (for example, user information provided by the user terminal 20), the date and time when the certificate signing request was generated, etc. This makes it possible to determine the user who instructed the generation of the certificate signing request and the date and time when the certificate signing request was generated (i.e., the date and time when the initial setting of the edge device 10 started) by referring to the certificate signing request (the information included in the certificate signing request). The certificate signing request may also include device information (for example, a serial number, etc.) managed by the device information management unit 14.

[0088] When the processing of step S2 is executed, the certificate signing request sent in step S2 is received by the first communication unit 21 included in the user terminal 20, and the initial setting processing unit 25 obtains the certificate signing request from the first communication unit 21.

[0089] The initial setting processing unit 25 verifies the acquired certificate signing request. In this case, the verification of the certificate signing request is successful if the certificate signing request includes user information provided by the user terminal 20, and fails if the certificate signing request does not include the user information. Note that the verification of the certificate signing request may also be performed based on other information.

[0090] If the verification of the certificate signature request is successful, the initial setting processing unit 25 passes the certificate signature request to the certificate acquisition unit 26, and if the verification of the certificate signature request is unsuccessful, the initial setting processing unit 25 discards the certificate signature request. Note that if the certificate signature request is discarded, the initial setting processing unit 25 may notify the user of an error.

[0091] The certificate signing request may be verified by the user by checking the contents of the certificate signing request. In this case, the user terminal 20 presents the user with device information included in the certificate signing request on a screen such as that shown in Fig. 10 (hereinafter referred to as a device confirmation screen). This allows the user to check whether the certificate signing request received by the user terminal 20 is the certificate signing request generated by the edge device 10 intended by the user.

[0092] Specifically, for example, if the device information presented on the device confirmation screen matches the device information (such as the serial number) printed on the casing of the edge device 10, the user instructs the user terminal 20 to request the issuance of a public key certificate based on the certificate signing request received (i.e., to execute the processing from step S3 onwards).

[0093] If the verification of the certificate signature request is successful, the certificate acquisition unit 26 executes user authentication processing with the certification authority 30 (first communication unit 31) (step S3). Note that the user authentication processing corresponds to a process in which, for example, a user ID, a password, and the like assigned to a user who uses the user terminal 20 (a user who owns the edge device 10) are transmitted from the user terminal 20 to the certification authority 30, and the certification authority 30 confirms whether the user is a legitimate user who can request the issuance of a public key certificate. Here, the user authentication processing has been described as using a user ID and a password, but the user authentication processing may be any processing for authenticating a user (or the user terminal 20), and other information may be used.

[0094] If the user is authenticated by executing the processing of step S3 (i.e., if the user using the user terminal 20 is confirmed to be a legitimate user in the user authentication processing), the certificate acquisition unit 26 sends a certificate signing request to the certification authority 30 via the second communication unit 22 (step S4).

[0095] When the processing of step S4 is executed, the certificate signing request sent in step S4 is received by the first communication unit 31 included in the certificate authority 30, and the request verification unit 33 obtains the certificate signing request from the first communication unit 31.

[0096] The request verification unit 33 verifies the acquired certificate signing request based on the verification information managed by the verification information management unit 32. If the edge device 10 that is the target of the certificate signing request (i.e., the edge device 10 that can request the issuance of a public key certificate) or attribute information of the certificate is set in advance by, for example, a user, verification of the certificate signing request may include checking whether the edge device 10 or the attribute information is appropriate. In this case, the attribute information includes, for example, the installation location of the edge device 10, information about the administrator, etc.

[0097] The certificate signing request may be verified by checking whether the data structure of the certificate signing request and the information included in the certificate signing request conform to the specifications required by the certification authority 30.

[0098] An example of the verification of the certificate signing request performed by the certificate authority 30 as described above will be described below. First, an example of verification information is shown in Fig. 11. In the example shown in Fig. 11, the verification information includes a user ID for identifying a user, a serial number of the edge device 10 owned by the user, and an expiration date of the verification information, all of which are associated with each other.

[0099] Here, assuming that the certificate signing request acquired by the request verification unit 33 includes user information (e.g., user ID) and device information (e.g., serial number), the verification of the certificate signing request is successful if, as a result of comparing the certificate signing request with the verification information, both the user ID and the serial number match (i.e., verification information exists that includes the user ID and serial number included in the certificate signing request in association).On the other hand, the verification of the certificate signing request fails if, as a result of comparing the certificate signing request with the verification information, at least one of the user ID and the serial number does not match (i.e., verification information does not exist that includes the user ID and serial number included in the certificate signing request in association).

[0100] Although the certificate signing request has been described as including user information, there is a possibility that the certificate signing request does not include user information. Here, the first communication unit 31 executes user authentication processing with the user terminal 20 (certificate acquisition unit 26) in step S3 described above, and holds the user information (user ID, etc.) used in the user authentication processing. Therefore, if the certificate signing request does not include user information as described above, the request verification unit 33 acquires the user information provided by the first communication unit 31 and uses it to verify the certificate signing request.

[0101] As described above, the verification information includes an expiration date. Once the expiration date has passed, the verification information may be discarded or updated with verification information that includes a new expiration date.

[0102] Here, the verification information has been described as information including a user ID and a serial number in association with each other, but the verification information may be, for example, information including a user ID and a manufacturer of the edge device 10 in association with each other as shown in Fig. 12, information including a user ID and an affiliation of the user in association with each other as shown in Fig. 13, or information including a user ID and an installation location of the edge device 10 in association with each other as shown in Fig. 14. Even in the case of the verification information as shown in Figs. 12 to 14, the certificate signing request can be verified by comparing the certificate signing request with the verification information.

[0103] The verification information managed by the verification information management unit 32 may be information having a data structure that combines the above-described data structures shown in FIGS.

[0104] That is, in this embodiment, the above-mentioned verification information limits or designates the edge devices 10 that can issue public key certificates according to the authority set in advance for the user (user terminal 20).

[0105] If the verification of the certificate signing request is successful, the request verification unit 33 passes the certificate signing request to the certificate issuing unit 34, and if the verification of the certificate signing request is unsuccessful, the request verification unit 33 discards the certificate signing request. If the certificate signing request is discarded, the request verification unit 33 may notify the user terminal 20 (or the user using the user terminal 20) of an error via the first communication unit 31.

[0106] If the verification of the certificate signing request is successful as described above, the certificate issuance unit 34 takes over processing from the request verification unit 33 and issues a public key certificate for the edge device 10 in accordance with the certificate signing request passed from the request verification unit 33. When the public key certificate is issued by the certificate issuance unit 34 in this way, issuance history information related to the issued public key certificate is managed by the issuance history management unit 35.

[0107] In the above description, a public key certificate is issued if the verification of the certificate signing request is successful. However, based on the issuance history information (history of public key certificates issued in the past) managed by the issuance history management unit 35, the certificate issuance unit 34 may determine that a request with exactly the same content, including timestamps, as the certificate signing request currently being processed has been processed in the past, and if a certificate was issued at that time, the certificate issuance unit 34 may interrupt the current processing and not issue a new public key certificate.

[0108] 15 shows an example of the issuance history information. As shown in Fig. 15, the issuance history information includes a public key for which a public key certificate has been issued in the past, attribute information of the public key certificate, a user ID for identifying the user who requested the issuance of the public key certificate, and the date and time when the public key certificate was issued (issue date and time), all of which are associated with each other. The attribute information includes, for example, information such as the identifier and installation location of the edge device 10.

[0109] 15, the certificate issuing unit 34 can refer to the issuance history information to check whether a certificate has been issued in the past for the same public key as the public key for which issuance of a public key certificate is being requested by the certificate signing request (that is, whether issuance history information including the same public key and attribute information as the certificate signing request is already managed by the issuance history management unit 35). Specifically, for example, if the certificate signing request includes the date and time when the certificate signing request was generated (hereinafter referred to as the request generation date and time), and the public key and attribute information included in the issuance history information including an issue date and time earlier than the request generation date and time match the public key and attribute information included in the certificate signing request, it can be determined that a certificate has been issued in the past for the same public key.

[0110] If it is confirmed that a certificate for the same public key has been issued in the past, the certificate issuance unit 34 may not issue a public key certificate in response to the certificate signing request and may discard the certificate signing request. In this case, the certificate issuance unit 34 may notify the user terminal 20 (or the user who uses the user terminal 20) that the certificate signing request has been discarded via the first communication unit 31, or may notify the administrator of the certification authority 30 of an alert.

[0111] Here, we have explained that a public key certificate will not be issued if a certificate for the same public key has already been issued, but by embedding the serial number or random number of the public key certificate in the attribute information (i.e., making the attribute information different depending on the serial number or random number), it may be possible to reissue a public key certificate even for the same public key, for example.

[0112] When a public key certificate is issued by the certificate issuing unit 34 as described above, the billing processing unit 36 ​​receives a certificate signing request from the certificate issuing unit 34, for example, and executes billing processing to bill for the invoice issuance fee.

[0113] The billing process executed by the billing processor 36 will now be described. First, the billing processor 36 identifies the billing recipient for the invoice issuance fee based on the billing recipient information included in the certificate signing request. In the example shown in FIG. 3 above, the billing recipient for the invoice issuance fee is one of the device owner, server administrator, server user, IoT service provider, and IoT service contract number (or end user assigned the number), but it may also be, for example, the manufacturer of the edge device 10.

[0114] Next, the billing processing unit 36 ​​generates billing data including the certificate issuance fee. The billing data generated by the billing processing unit 36 ​​may be data in PDF format, for example, but may also be data in other formats. The billing data generated in this manner is transmitted from the second communication unit 37 to the billing destination device based on the billing destination for the certificate issuance fee identified as described above (step S5).

[0115] Note that if the certificate issuance fee is billed to, for example, a device owner (a user who owns the edge device 10) and the device owner has used the user terminal 20 to issue the certificate (i.e., the user who uses the user terminal 20), the billing destination device is the user terminal 20. Also, if the certificate issuance fee is billed to, for example, a server administrator, a server user, or an IoT service provider, the billing destination device is, for example, the server device 40 or another server device. Furthermore, if the certificate issuance fee is billed to, for example, an end user of an IoT service, the billing destination device is, for example, a terminal device used by the end user.

[0116] Here, we have explained that the invoice data is sent directly to the billing destination (billing destination device) for the certificate issuance fee, but if the certificate issuance fee is billed through a billing agent that provides services to bill and collect various fees, the billing destination device may be a server device or the like managed by the billing agent.

[0117] During the billing process, invoice data including the certificate issuance fee is sent to the billing recipient, but the unit price (the cost for issuing one public key certificate) used to calculate the certificate issuance fee may be common to multiple billing recipients, or may be different for each billing recipient.

[0118] Furthermore, the timing at which invoice data is sent to the billing destination (i.e., billing timing) may be each time a public key certificate is issued, or each time a predetermined number (fixed number) of public key certificates are issued. Furthermore, the billing timing may be each time a predetermined period (e.g., one month) has elapsed. Note that FIG. 9 assumes that invoice data is sent to the billing destination each time a public key certificate is issued.

[0119] Furthermore, the method of payment for the certificate issuance fee may be postpaid, in which the fee is paid after the public key certificate is issued, or prepaid, in which the fee is paid in advance before the public key certificate is issued.

[0120] Here, it is assumed that the billing processing unit 36 ​​previously stores billing processing information for managing the unit price, billing timing, and payment method for each billing destination.

[0121] An example of the billing processing information will be described below with reference to Fig. 16. As shown in Fig. 16, the billing processing information includes a unit price, billing timing, payment method, and the number of certificates that can be issued, all of which are associated with a billing destination.

[0122] In the example shown in FIG. 16, the billing processing information includes a unit price of "fff," a billing timing of "N / A," a payment method of "prepayment," and a maximum number of issuable certificates of "100" associated with the billing destination "F1." This indicates that the billing destination "F1" will pay in advance the cost calculated by multiplying the unit price of "fff" by the maximum number of issuable certificates of "100." In this case, the billing destination "F1" can issue 100 public key certificates with the prepaid cost. The certificate issuing unit 34 issues a public key certificate if the difference between the maximum number of issuable certificates and the number of public key certificates already issued (the number of public key certificates issued for the billing destination "F1") is equal to or greater than 1. In other words, the certificate issuing unit 34 does not issue a public key certificate if the difference between the maximum number of issuable certificates and the number of public key certificates already issued is 0 or an invalid value. If the certificate issuing unit 34 does not issue a public key certificate, the certificate issuing unit 34 notifies the user terminal 20 of an error. That is, the certificate issuing unit 34 may determine (decide) whether or not to issue a public key certificate based on the request processing information.

[0123] The number of public key certificates that have already been issued can be ascertained by referring to the issuance history information described above. The number of public key certificates that have already been issued may also be managed in the billing processing information by subtracting the number of available certificates associated with billing destination "F1" from the number of certificates that can be issued each time a public key certificate with billing destination "F1" is issued.

[0124] The billing processing information also includes, in association with billing recipient "G1," a unit price "ggg," billing timing "end of month," payment method "postpaid," and the number of certificates that can be issued "N / A." This indicates that billing recipient "G1" will pay the cost calculated by multiplying the unit price "ggg" by the number of public key certificates issued by the end of the month, in a deferred payment. The number of public key certificates issued by the end of the month can be determined by referring to the issuance history information described above, but it may also be managed in the billing processing information.

[0125] The billing processing information also includes, in association with billing recipient "H1," a unit price "hhh," a billing timing "billing each time," a payment method "postpaid," and the number of certificates that can be issued "N / A." This indicates that billing recipient "H1" will pay a fee equivalent to the unit price "hhh" on a postpaid basis each time a public key certificate is issued.

[0126] The billing processing information also includes, in association with billing recipient "I1," unit price "iii," billing timing "N / A," payment method "prepayment," and number of certificates that can be issued "80." This indicates that billing recipient "I1" will pay in advance the cost calculated by multiplying unit price "fff" by number of certificates that can be issued "80."

[0127] The billing processing information also includes, in association with billing recipient "J1," unit price "jjj," billing timing "end of month closing," payment method "prepayment / postpayment," and maximum number of certificates that can be issued "100 / month." This indicates that billing recipient "I1" will pay in advance the cost calculated by multiplying unit price "jjj" by the maximum number of certificates that can be issued "100," and if public key certificates are issued in excess of the maximum number of certificates that can be issued, will pay in arrears the cost calculated by multiplying unit price "jjj" by the number of public key certificates that have been issued by the end of the month in excess of the maximum number of certificates that can be issued.

[0128] By referencing the above-mentioned billing processing information, billing processing unit 36 ​​can execute appropriate billing processing according to the billing destination. In other words, in this embodiment, the unit price for calculating the certificate issuance fee (calculation method of the certificate issuance fee), the billing timing of the certificate issuance fee (timing of calculation of the certificate issuance fee or timing of sending invoice data), and the payment method of the certificate issuance fee can be made different depending on the billing destination.

[0129] Although not shown in the example of Fig. 16, the number of certificates that can be issued may be managed in the billing processing information even when the payment method is "postpaid." By doing so, for example, by setting the number of certificates that can be issued according to the billing recipient's budget, it is possible to prevent the issuance of a number of public key certificates that exceeds the billing recipient's budget (i.e., prevent the billing recipient from being billed for costs that exceed the budget).

[0130] Furthermore, in this embodiment, the certificate issuance fee is billed to a billing destination identified based on the billing destination information included in the certificate signing request. However, if the billing destination is not included in the billing processing information (i.e., if the certification authority 30 receives a certificate signing request associated with a billing destination that is not included in the billing processing information), the certificate issuing unit 34 may notify the user terminal 20 of an error.

[0131] Here, in order to perform the billing process (the process of billing the certificate issuance fee), billing information indicating the party to bill the certificate issuance fee is required. However, if, for example, the certificate signing request does not include billing information, it is not possible to identify the party to bill the certificate issuance fee, and therefore the billing processing unit 36 ​​may notify the user terminal 20 (or the user using the user) of an error via the first communication unit 31.

[0132] On the other hand, even if billing information is not included in the certificate signing request, if the certification authority 30 (billing processing unit 36) manages billing information indicating the billing address for the certificate issuance fee corresponding to the user who owns the edge device 10, the billing address may be identified based on the billing information.

[0133] Specifically, the first communication unit 31 executes the user authentication process with the user terminal 20 (certificate acquisition unit 26) in step S3 described above, and holds the user ID used in the user authentication process. In this case, the billing processing unit 36 ​​can acquire the user ID from the first communication unit 31 via, for example, the certificate issuance unit 34, and identify the billing destination indicated by the billing destination information corresponding to the user ID. In other words, in this embodiment, the billing process may be executed based on the billing destination information managed in the certificate authority 30 to bill the billing destination for the invoice issuance fee corresponding to the user (the user who owns the edge device 10) authenticated by the execution of the user authentication process.

[0134] In addition, if the certificate signing request does not include billing information and the billing information indicating the billing address corresponding to the user who owns the edge device 10 is not managed by the certification authority 30, an error will be notified to the user terminal 20 from the certificate issuing unit 34 even if the user is authenticated by executing the user authentication process.

[0135] Returning to FIG. 9 again, the public key certificate of the edge device 10 issued by the certificate issuing unit 34 as described above is transmitted (provided) to the user terminal 20 via the first communication unit 31 (step S6).

[0136] When the processing of step S6 is executed, the public key certificate transmitted in step S6 is received by the second communication unit 22 included in the user terminal 20, and the certificate acquisition unit 26 acquires the public key certificate from the second communication unit 22. The public key certificate acquired by the certificate acquisition unit 26 is passed to the initial setting processing unit 25 and transmitted to the edge device 10 via the first communication unit 21 (step S7).

[0137] When the processing of step S7 is executed, the public key certificate transmitted in step S7 is received by the first communication unit 11 included in the edge device 10, and the registration unit 16 acquires the public key certificate from the first communication unit 11. The public key certificate acquired by the registration unit 16 is registered (set) in the edge device 10. This completes the initial setting of the edge device 10.

[0138] In step S7, configuration information (e.g., server information managed by the server information management unit 24) for the edge device 10 to communicate with the server device 40 may be sent along with the public key certificate, and the configuration information may be set in the edge device 10.

[0139] When a public key certificate is registered in the edge device 10 as described above, device authentication processing using the public key certificate is executed between the edge device 10 and the server apparatus 40 (step S8). Note that in step S8, device authentication processing may be executed to confirm, for example, whether the public key certificate presented by the edge device 10 is a public key certificate that has been validly issued for the public key of the edge device 10.

[0140] When the edge device 10 is authenticated by executing the process of step S8, the application processing unit 17 included in the edge device 10 starts executing application communication with the server device 40. Through such application communication, the edge device 10 and the server device 40 operate in cooperation as an application system, thereby realizing the provision of IoT services (step S9).

[0141] 9, it has been explained that the billing destination for the certificate issuance fee is identified based on the billing destination information included in the certificate signing request or the billing destination information managed by the certification authority 30. However, it is assumed that the certificate signing request includes billing destination information (hereinafter referred to as the first billing destination information) and that the certification authority 30 manages billing destination information (hereinafter referred to as the second billing destination information). In this case, if the billing destination indicated by the first billing destination information and the billing destination indicated by the second billing destination information are the same, billing processing for that billing destination is executed. On the other hand, if the billing destination indicated by the first billing destination information and the billing destination indicated by the second billing destination information are different, it is necessary to identify the billing destination for the certificate issuance fee based on either the first or second billing destination information.

[0142] Specifically, if priority information indicating that one of the first and second billing information is to be given priority is set (stored) in advance in the certification authority 30, one of the first and second billing information can be selected based on the priority information, and the billing address for the certificate issuance fee can be identified based on the selected billing information.

[0143] 17, the user terminal 20 (or the user using the user terminal 20) may be inquired about the billing destination for the certificate issuance fee between the processes of steps S4 and S5 shown in Fig. 9. This makes it possible to execute billing processing for the billing destination identified based on the response (result of the inquiry) to the inquiry in step S11.

[0144] 9, the billing process (i.e., the transmission of billing data) is described as being executed after the public key certificate is issued and before the public key certificate is transmitted from the certification authority 30 to the user terminal 20, but the billing process may be executed at a different timing. Specifically, the billing process may be executed when the verification of the certificate signing request is successful (after it is confirmed that the public key certificate can be issued and before the public key certificate is issued), or may be executed after the public key certificate is transmitted from the certification authority 30 to the user terminal 20.

[0145] Furthermore, a public key certificate issued by the certification authority 30 (certificate issuing unit 34) is set with an expiration date, and the expiration date is managed by the certification authority 30. When the expiration date of the public key certificate thus set expires, the edge device 10 will no longer be able to communicate with the server device 40. Therefore, the certification authority 30 may notify the billing party responsible for the cost of issuing the public key certificate that the expiry date of the public key certificate (issued certificate) will be updated. This notification to the billing party may include, for example, sending a message (email) such as, "The public key certificate of device Y provided to user X will expire in three months. We recommend that you update it soon." Note that updating a public key certificate is equivalent to issuing a new public key certificate. Therefore, when updating a public key certificate, the same process as that shown in FIG. 9 is executed, and the current public key certificate is discarded.

[0146] 9, for example, the key management unit 15 included in the edge device 10 may generate a digital signature to be attached to the certificate signing request using the private key of the edge device 10 managed by the key management unit 15. The digital signature is generated by, for example, performing cryptographic processing using the private key of the edge device 10 on the hash value of the certificate signing request.

[0147] In this case, a certificate signing request with an electronic signature attached is transmitted from the edge device 10 to the user terminal 20, and the initial setting processing unit 25 included in the user terminal 20 can verify the certificate signing request using the electronic signature. In verifying such a certificate signing request, a hash value of the certificate signing request is calculated, and the calculated hash value is compared with the result (hash value) of encrypting the electronic signature attached to the certificate signing request with a public key (the public key of the edge device 10) that is paired with the private key of the edge device 10. In this case, if the hash value of the certificate signing request matches the hash value obtained from the electronic signature, it can be confirmed that the verification of the certificate signing request has been successful.

[0148] Here, it has been described that a digital signature generated in the edge device 10 is attached to a certificate signing request transmitted from the edge device 10 to the user terminal 20, but a digital signature generated using the private key of the user terminal 20 may be attached to a certificate signing request transmitted from the user terminal 20 to the certification authority 30. In this case, the request verification unit 33 included in the certification authority 30 can verify the certificate signing request transmitted from the user terminal 20 using the digital signature attached to the certificate signing request and the public key of the user terminal 20. This makes it possible to confirm that the edge device 10 generated the certificate signing request in response to an instruction from the user terminal 20.

[0149] Furthermore, a digital signature generated using the private key of the certification authority 30 may be attached to the public key certificate transmitted from the certification authority 30 to the user terminal 20. In this case, the certificate acquisition unit 26 included in the user terminal 20 can verify the public key certificate transmitted from the certification authority 30 using the digital signature attached to the public key certificate and the public key of the certification authority 30. The verification of the public key certificate may be performed by the registration unit 16 included in the edge device 10, for example.

[0150] The processing shown in Figure 9 above is an example, and in this embodiment, processing that is partially different from the processing described in Figure 9 may be executed, or processing in which part of the processing described in Figure 9 is omitted may be executed.

[0151] As described above, in this embodiment, the edge device 10 (communications device) transmits a certificate signing request to the user terminal 20 (terminal device) requesting the issuance of a public key certificate (a certificate for the public key of the edge device 10 in a public key cryptosystem) to be used by the edge device 10 to communicate with the server device 40 (first server device). Also, in this embodiment, the user terminal 20 transmits the certificate signing request transmitted from the edge device 10 to the certificate authority 30. Furthermore, in this embodiment, the certificate authority 30 issues a public key certificate in response to the certificate signing request transmitted from the user terminal 20, and executes a billing process to bill for the certificate issuance fee (the fee for issuing the certificate).

[0152] In this embodiment, the above-described configuration makes it possible to easily issue a public key certificate for the edge device 10 in a factory-shipped state (a public key certificate used by the edge device 10 for communication).

[0153] 18 shows an overview of the issuance of a public key certificate in a comparative example of this embodiment. As shown in Fig. 18, in this comparative example of this embodiment, user settings such as registration of a public key certificate issued by a certificate authority 30 are completed at the manufacturing site of the edge device 10, and the user can communicate with the server device 40 (secure communication using the certificate) using the edge device 10 in which the public key certificate has already been registered.

[0154] However, in the comparative example of this embodiment described above, the public key certificate is registered in advance in the edge device 10 before it is shipped from the factory, so it is not possible to issue the public key certificate at the certificate authority 30 designated by the user, for example. Furthermore, if the public key certificate is issued and registered in advance, it takes time before the edge device 10 is shipped.

[0155] In contrast, Fig. 19 shows an overview of the issuance of a public key certificate in this embodiment. As shown in Fig. 19, in this embodiment, after an edge device 10 for which a public key certificate has not been issued or registered in advance is shipped from a factory, a user terminal 20 is used to issue and register a public key certificate for the edge device 10 in its factory-shipped state.

[0156] According to this configuration, unlike the comparative example of this embodiment described above, a certification authority 30 designated by the user who owns the edge device 10 (the user who uses the user terminal 20) can be used to issue and register a public key certificate.

[0157] Furthermore, in this embodiment, there is no need for settings such as connecting the edge device 10 to the certificate authority 30 for issuing a public key certificate, and it is possible to automate the issuance and registration (i.e., initial setting) of a public key certificate for the edge device 10 in a factory-shipped state. That is, in this embodiment, there is no need for specialized knowledge or complicated work related to the issuance and registration of a public key certificate, and therefore the user's workload can be reduced (i.e., initial setting including the issuance and registration of a public key certificate can be easily performed).

[0158] Furthermore, in this embodiment, it is not necessary to complete user settings such as issuing and registering a public key certificate before shipping from the factory, which can contribute to prompt shipping of the edge device 10.

[0159] 18, the edge device 10 has not yet been delivered at the time the public key certificate is issued, and therefore the certificate issuance fee is billed to, for example, the manufacturer of the edge device 10. In contrast, in the present embodiment shown in FIG. 19, the certificate issuance fee can be billed to, for example, a server administrator.

[0160] That is, in this embodiment, it is possible to execute billing processes for various billing destinations according to the users and implementers of the communication system 1, compared to the comparative example of this embodiment.

[0161] In this embodiment, the certificate signing request includes billing information indicating the billing destination for the certificate issuance fee, and the certificate authority 30 executes billing processing to the billing destination for the certificate issuance fee indicated by the billing information included in the certificate signing request. In this case, the edge device 10 generates a certificate signing request including billing information managed in the edge device 10, for example, and the billing destination may be specified based on information held in the user terminal 20, or may be specified by the user who owns the edge device 10 (i.e., information input by the user to the user terminal 20).

[0162] In addition, if billing information is not included in the certificate signing request, the certificate authority 30 may perform billing processing to the billing destination for the certificate issuance fee corresponding to the user who owns the edge device 10 (the user authenticated by executing the user authentication processing).

[0163] Furthermore, if the billing address indicated by the billing address information included in the certificate signing request is different from the billing address corresponding to the user who owns the edge device 10, the certificate authority 30 may inquire of the user as to the billing address for the certificate issuance fee, and perform billing processing based on the results of the inquiry.

[0164] In this embodiment, the certificate issuance fee, the timing of billing for the certificate issuance fee, and the payment method for the certificate issuance fee may differ depending on the billing destination for the certificate issuance fee.

[0165] In this embodiment, with the above-described configuration, it is possible to execute appropriate billing processing when issuing a public key certificate for the edge device 10 after shipping from the factory.

[0166] Here, a specific application example of the communication system 1 according to this embodiment will be briefly described. Here, we consider a case where the edge device 10 is an MFP (Multi Function Peripheral) installed in an office or the like. Also, for example, it is assumed that an MFP maintenance technician uses an edge terminal equivalent to the user terminal 20 to perform initial settings of the MFP in the office or the like where the MFP is installed. In this case, a public key certificate of the MFP can be issued using the communication system 1 according to this embodiment.

[0167] When a public key certificate is issued as described above, the certificate issuance fee may be charged, for example, to the company that manufactured the MFP, or to the provider of the cloud service (IoT service) that the MFP connects to, or to the end user of the MFP (the company that actually uses the MFP in an office, etc.).

[0168] According to this embodiment, the billing destination for the certificate issuance fee is identified based on the billing destination information. However, if there are multiple billing destinations (i.e., the billing destination information is included in the certificate signing request and the billing destination information is managed by the certification authority 30), a message such as "To whom would you like to bill the fee?" will be displayed as a pop-up on the edge terminal held by the maintenance worker, and the maintenance worker using the edge terminal can select one of the company that manufactured the MFP, the cloud service provider, and the end user.

[0169] Although an MFP has been described here as an example of the edge device 10, the communication system 1 according to this embodiment can be applied to cases where IoT services are provided using various edge devices 10.

[0170] In this embodiment, when the edge device 10 and the user terminal 20 are connected so that they can communicate with each other, the user terminal 20 instructs the edge device 10 to generate a certificate signing request, and the edge device 10 generates the certificate signing request in response to the instruction from the user terminal 20, thereby enabling the issuance of a public key certificate from the certification authority 30 using the user terminal 20.

[0171] Furthermore, in this embodiment, the user terminal 20 transmits user information about the user who owns the edge device 10 (the user who uses the user terminal 20) and server information about the server apparatus 40 to the edge device 10, and the user information and server information transmitted from the user terminal 20 are set in the edge device 10, thereby enabling the edge device 10 to be automatically configured based on the information provided from the user terminal 20. Note that in this embodiment, in addition to the above-mentioned certificate authority 30, the user may also specify the server apparatus 40 (cloud system) with which the edge device 10 will cooperate.

[0172] In this embodiment, the certificate authority 30 verifies the certificate signing request based on, for example, device information included in the certificate signing request, and issues a public key certificate if the verification of the certificate signing request is successful. This configuration makes it possible to issue a public key certificate for a legitimate edge device 10.

[0173] The certificate signing request may be verified using the digital signature attached to the certificate signing request. This configuration can prevent a situation in which a public key certificate is issued in response to a certificate signing request that has been tampered with, and can reduce security risks in IoT services.

[0174] Here, we have explained the verification of the certificate signature request, but the verification of the public key certificate issued by the certification authority 30 may also be performed using, for example, the electronic signature attached to the public key certificate (electronic signature generated by the certification authority 30).

[0175] In addition, in this embodiment, by performing user authentication processing for the user who owns the edge device 10 between the user terminal 20 and the certification authority 30, it becomes possible to issue a public key certificate in response to a request from a legitimate user.

[0176] Furthermore, in this embodiment, the decision as to whether to issue a public key certificate may be made based on issuance history information about public key certificates issued in the past. This configuration makes it possible to prevent situations in which the communication system 1 does not operate normally due to, for example, multiple certificates being issued for the same public key. Furthermore, by utilizing the issuance history information, it is possible to prevent erroneous issuance of public key certificates and replay attacks in which the same certificate signing request is sent multiple times to the certification authority 30.

[0177] Furthermore, in this embodiment, as described above, a device authentication process is performed on the edge device 10 using the public key certificate registered in the edge device 10, and when the edge device 10 is authenticated, communication with the server device 40 is performed, making it possible to provide IoT services with reduced security risks.

[0178] In addition, this embodiment only requires a configuration that can issue a public key certificate for an edge device 10 in a factory-shipped state using a user terminal 20, and the communication system 1, edge device 10, user terminal 20, and certification authority 30 described in this embodiment may, for example, have some of their configurations omitted or other configurations added.

[0179] (Second embodiment) Next, a second embodiment will be described. In this embodiment, detailed descriptions of the same parts as those in the first embodiment will be omitted, and the description will focus mainly on the parts that are different from the first embodiment.

[0180] Fig. 20 shows an example of a system configuration of a communication system according to this embodiment. As shown in Fig. 20, the communication system 1 further includes a server device 60 different from the server device 40 in the first embodiment described above. For ease of explanation, the server device 40 shown in Fig. 20 will be described as a first server device 40, and the server device 60 will be described as a second server device 60.

[0181] The second server device 60 is configured to perform a user authentication process for a user who owns the edge device 10 (a user who uses the user terminal 20).

[0182] The user terminal 20 and the second server device 60 shown in FIG. 20 are connected via a network 51 so as to be able to communicate with each other.

[0183] Fig. 21 shows an example of the functional configuration of the user terminal 20 in this embodiment. As shown in Fig. 21, the user terminal 20 further includes a third communication unit 27, compared to the first embodiment described above.

[0184] The third communication unit 27 communicates with the second server device 60 via the network 51. Although the first communication unit 21, the second communication unit 22, and the third communication unit 27 are shown as independent and separate functional units in Fig. 21, the first communication unit 21, the second communication unit 22, and the third communication unit 27 may be realized as a single functional unit. Furthermore, the communication method used by the first communication unit 21 to communicate, the communication method used by the second communication unit 22 to communicate, and the communication method used by the third communication unit 27 to communicate may be different from each other or may be the same.

[0185] An example of a processing procedure of the communication system 1 according to this embodiment will be described below with reference to the sequence chart of FIG.

[0186] First, the processes of steps S21 and S22, which correspond to the processes of steps S1 and S2 shown in FIG. 9, are executed.

[0187] Here, in the first embodiment described above, the user authentication process is explained as being executed between the user terminal 20 (certificate acquisition unit 26) and the certification authority 30, but in this embodiment, it is assumed that the user authentication process is performed by the second server device 60.

[0188] In this case, the certificate acquisition unit 26 included in the user terminal 20 executes user authentication processing between the user terminal 20 and the second server device 60 (step S23).

[0189] The user authentication process is the same as that described in the first embodiment, so a detailed explanation will be omitted here. However, in this embodiment, it is assumed that the user authentication process is performed in the second server device 60 for providing another service using a user ID and password associated with an account for the other service that is different from the IoT service described above.

[0190] Note that a process for exchanging a message indicating the start of the certificate issuance process between the user terminal 20 and the certificate authority 30 may be inserted between steps S22 and S23, but a detailed description thereof will be omitted.

[0191] After the process of step S23 is executed, the certificate acquisition unit 26 transmits the result of the user authentication process to the certificate authority 30 via the second communication unit 22 (step S24).

[0192] If the user is authenticated based on the result of the user authentication process transmitted in step S24, the processes of steps S25 to S30, which correspond to the processes of steps S4 to S9 shown in FIG. 9, are executed.

[0193] In the first embodiment described above, for example, if billing information is not included in the certificate signing request, billing processing is performed on the billing destination for the certificate issuance fee corresponding to the user authenticated by the user authentication processing executed by the certification authority 30. However, in this embodiment, billing processing can be performed on the billing destination for the certificate issuance fee corresponding to the user authenticated by the user authentication processing executed by the second server device 60.

[0194] In this embodiment, the second server device 60 acts on behalf of the authentication authority 30 in performing user authentication processing, which makes it possible to reduce the processing load of the authentication authority 30, and eliminates the need for the authentication authority 30 to manage user authentication information.

[0195] In the present embodiment, the user authentication process has been described as being executed between the user terminal 20 and the second server device 60. However, the user authentication process may be executed, for example, by the authentication authority 30 transferring a user authentication request from the user terminal 20 to the second server device 60 (i.e., the authentication authority 30 requesting the second server device 60 to execute the user authentication process). Furthermore, the user authentication process may be executed by using, for example, the authentication and authorization of OAuth2 or the mechanism of OpenID Connect.

[0196] Furthermore, in this embodiment, for example, a part of the configuration of the certification authority 30 described in the first embodiment may be arranged in the second server device 60. Specifically, for example, the verification information management unit 32 included in the certification authority 30 may be arranged in the second server device 60. With this configuration, for example, when a user is authenticated by executing a user authentication process between the user terminal 20 and the second server device 60, verification information is provided from the second server device 60 to the certification authority 30, and the certification authority 30 can verify the certificate signing request based on the verification information provided from the second server device 60.

[0197] According to at least one of the above-described embodiments, it is possible to provide a communication system, a certification authority, and a method that can easily issue certificates used in communication.

[0198] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included within the scope and spirit of the invention, as well as the inventions described in the claims and their equivalents. [Explanation of symbols]

[0199] 1...communication system, 10...edge device (communication device), 10a...processor, 10b...non-volatile memory, 10c...main memory, 10d...communication interface, 11...first communication unit, 12...second communication unit, 13...request generation unit, 14...device information management unit, 15...key management unit, 16...registration unit, 17...application processing unit, 20...user terminal (terminal device), 21...first communication unit, 22...second communication unit, 2 3...user information management unit, 24...server information management unit, 25...initial setting processing unit, 26...certificate acquisition unit, 27...third communication unit, 30...certificate authority, 31...first communication unit, 32...verification information management unit, 33...request verification unit, 34...certificate issuance unit, 35...issuance history management unit, 36...billing processing unit, 37...second communication unit, 40...server device (first server device), 51, 52...network, 60...server device (second server device).

Claims

1. A communication system including a communication device, a terminal device, and a certificate authority, the communication device transmits to the terminal device a certificate signing request requesting issuance of a certificate to be used by the communication device to communicate with a first server device; The terminal device transmits the certificate signing request transmitted from the communication device to the certificate authority; The certificate authority issues the certificate in response to the certificate signing request sent from the terminal device, and executes a billing process to bill for the cost of issuing the certificate. Communication system.

2. the certificate signing request includes billing information indicating to whom the fee should be billed; The certificate authority executes the billing process to the billing destination indicated by the billing destination information included in the certificate signing request. The communication system of claim 1.

3. The communication system of claim 2 , wherein the communication device generates a certificate signing request that includes billing information managed in the communication device.

4. 4. A communication system according to claim 3, wherein the destination to which the fee is to be charged is designated based on information held in the terminal device.

5. 4. The communication system according to claim 3, wherein the destination to which the fee is to be charged is designated by a user who owns the communication device.

6. The certificate authority executes the billing process to the billing destination corresponding to the user who owns the communication device. The communication system of claim 1.

7. the certificate signing request includes billing information indicating to whom the fee should be billed; If the billing address indicated by the billing address information included in the certificate signing request is different from the billing address corresponding to the user who owns the communication device, the certificate authority inquires about the billing address of the user and performs the billing process based on the result of the inquiry. The communication system of claim 1.

8. 8. The communication system according to claim 6, wherein the certificate authority executes an authentication process for a user who owns the communication device between the certificate authority and the terminal device.

9. the terminal device is communicably connected to a second server device; 8. The communication system according to claim 6, wherein the second server executes an authentication process for a user who owns the communication device between the second server and the terminal device.

10. 7. The communication system according to claim 2, wherein the cost varies depending on the billing party.

11. 7. The communication system according to claim 2 or 6, wherein the timing of billing the fee varies depending on the billing destination of the fee.

12. 7. A communication system according to claim 2 or 6, wherein the payment method for the fee differs depending on the billing party for the fee.

13. In a certification authority communicably connected to a terminal device, a receiving means for receiving a certificate signing request from the terminal device when the certificate signing request is transmitted from the communication device to the terminal device, the certificate signing request requesting the issuance of a certificate used by the communication device to communicate with a first server device; issuing means for issuing the certificate in response to the received certificate signing request; a billing processing means for executing a billing process for billing for the issuance of the certificate; A certification authority that has:

14. A method performed by a communication system comprising a communication device, a terminal device, and an authentication authority, the method comprising: transmitting a certificate signing request from the communication device to the terminal device, the certificate signing request requesting issuance of a certificate used by the communication device to communicate with a first server device; sending a certificate signing request sent from the communication device to the certificate authority from the terminal device; issuing the certificate in response to a certificate signing request sent from the terminal device; performing a billing process to bill for the issuance of said certificate; A method comprising:

15. A method performed by a certification authority communicatively connected to a terminal device, comprising: receiving a certificate signing request from the terminal device when the certificate signing request is transmitted from the communication device to the terminal device, the certificate signing request requesting issuance of a certificate used by the communication device to communicate with a first server device; issuing the certificate in response to the received certificate signing request; performing a billing process to bill for the issuance of said certificate; A method comprising:

Images