Communication system, terminal apparatus, communication device, and method

What is AI technical title?
AI technical title is built by Patsnap AI team. It summarizes the technical point description of the patent document.
The described communication system simplifies the issuance and registration of certificates for edge devices, ensuring efficient communication with server devices by integrating a communication device, terminal device, and certificate authority.

JP2025138012APending Publication Date: 2025-09-25KK TOSHIBA

View PDF 2 Cites 0 Cited by

Patent Information

Application Number: JP2024036632
Authority / Receiving Office: JP · JP
Patent Type: Applications
Current Assignee / Owner
Filing Date: 2024-03-11
Publication Date: 2025-09-25

AI Technical Summary

Technical Problem

The process of issuing and registering certificates for edge devices in IoT systems is time-consuming, hindering efficient communication with server devices.

Method used

A communication system comprising a communication device, a terminal device, and a certificate authority, where the communication device requests a certificate from the terminal device, which then forwards the request to the certificate authority for issuance, and the issued certificate is registered in the communication device.

Benefits of technology

Facilitates easy and efficient issuance and registration of certificates for edge devices, enabling seamless communication with server devices.

✦ Generated by Eureka AI based on patent content.

Smart Images

Figure 2025138012000001_ABST

Patent Text Reader

Abstract

To provide a communication system, a terminal apparatus, a communication device, and a method that can easily issue and register certificates used in communication.SOLUTION: According to an embodiment, a communication system is provided that includes a communication device, a terminal apparatus, and a certificate authority. The communication device transmits, to the terminal apparatus, a certificate signing request requesting the issuance of a certificate to be used by the communication device to communicate with a first server device. The terminal apparatus transmits the certificate signing request transmitted from the communication device to the certificate authority. The certificate authority issues a certificate in response to the certificate signing request transmitted from the terminal apparatus. The certificate issued by the certificate authority is transmitted from the certificate authority to the communication device via the terminal apparatus and registered in the communication device.SELECTED DRAWING: Figure 1

Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] FIELD OF THE INVENTION Embodiments of the present invention relate to a communication system, a terminal, a communication device 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 and register 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 terminal apparatus, a communication device, and a method that can easily issue and register certificates used in communication. [Means for solving the problem]

[0006] According to an embodiment, a communication system is provided that 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 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 transmitted from the terminal device. The certificate issued by the certificate authority is transmitted from the certificate authority to the communication device via the terminal device and registered in the communication device. [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. 4 is a diagram showing an example of the data structure of device management 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 a data structure of user information. [Figure 6] FIG. 4 is a diagram showing an example of a data structure 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 a data structure of verification information. [Figure 12] FIG. 10 is a diagram showing another example of the data structure of verification information. [Figure 13] FIG. 10 is a diagram showing yet another example of the data structure of verification information. [Figure 14] FIG. 10 is a diagram showing yet another example of the data structure of verification information. [Figure 15] FIG. 4 is a diagram showing an example of a data structure of issuance history information. [Figure 16] FIG. 10 is a diagram showing an outline of issuing a public key certificate in a comparative example of the present embodiment. [Figure 17] FIG. 2 is a diagram showing an outline of issuing a public key certificate in this embodiment. [Figure 18] FIG. 10 is a diagram showing an example of the system configuration of a communication system according to a second embodiment. [Figure 19] FIG. 2 is a diagram showing an example of the functional configuration of a user terminal. [Figure 20] 1 is a sequence chart showing an example of a processing procedure of a communication system. [Figure 21] FIG. 10 is a diagram showing an example of the system configuration of a communication system according to a third embodiment. 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, URT, and SPI, or parallel communication may be performed between the host controller and the communication device.

[0011] In this embodiment, the edge device 10 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 with the settings necessary for communicating 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, 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.

[0013] The certificate authority 30 issues 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 communications 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] The communication method applied to the communication between the edge device 10 and the user terminal 20 shown in Fig. 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 using a UART (Universal Asynchronous Receiver Transmitter), or a 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.

[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 management information).

[0025] An example of the data structure of device management information is shown in Fig. 3. In the example shown in Fig. 3, the device management 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] In Figure 3, the device management information is described as including the manufacturer, model, serial number, installation location, administrator, and current time, but the device management information may omit some of this information, or may include information other than this information (for example, model number, hardware version, etc.).

[0028] 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.

[0029] Here, the key pair of the edge device 10 may be generated, for example, 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. The key pair of the edge device 10 may also 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. Furthermore, 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.

[0030] 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.

[0031] 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).

[0032] 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).

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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 used by the first communication unit 21 to communicate may be different from or the same as the communication method used by the second communication unit 22 to communicate.

[0037] 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).

[0038] 5 shows an example of the data structure of user information. As shown in Fig. 5, the user information includes, for example, the user's username, the user's affiliation, a user terminal ID for identifying the user terminal 20, and the version of the user terminal 20.

[0039] 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).

[0040] 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.

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

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

[0043] The server ID, 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.).

[0044] 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.

[0045] 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).

[0046] Furthermore, the initial setting processing unit 25 receives a certificate signing request transmitted from the edge device 10 via the first communication unit 21. The initial setting processing unit 25 verifies the received certificate signing request.

[0047] 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. In addition, the certificate acquiring unit 26 receives, 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.

[0048] The public key certificate thus received 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.

[0049] 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 communication unit 31, a verification information management unit 32, a request verification unit 33, a certificate issuance unit 34, and an issuance history management unit 35.

[0050] The 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.

[0051] The request verification unit 33 receives a certificate signing request transmitted from the user terminal 20 via the 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 received certificate signing request and the user terminal that is the sender of the certificate signing request and the user that is the user of the user terminal is appropriate.

[0052] 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 sent to the user terminal 20 via the communication unit 31.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

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

[0058] 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.

[0059] Furthermore, some or all of the units 31 to 35 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] When the process of step S1 is executed, the request generator 13 included in the edge device 10 receives, via the first communication unit 11, the initial setting start message transmitted in step S1.

[0069] The request generation unit 13 generates a certificate signing request for issuing a public key certificate in response to the received initial setting 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).

[0070] The certificate signing request 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).

[0071] The certificate signing request 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 managed by the device information management unit 14.

[0072] When the process of step S2 is executed, the initial setting processing unit 25 included in the user terminal 20 receives, via the first communication unit 21, the certificate signing request transmitted in step S2.

[0073] The initial setting processing unit 25 verifies the received 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.

[0074] 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.

[0075] 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.

[0076] 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).

[0077] If the verification of the certificate signature request is successful, the certificate acquisition unit 26 executes user authentication processing with the certification authority 30 (communication unit 31) (step S3). The user authentication processing corresponds to a process in which, for example, a user ID, a password, etc. assigned to a user who uses the user terminal 20 are sent 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.

[0078] 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).

[0079] When the process of step S4 is executed, the request verification unit 33 included in the certificate authority 30 receives, via the communication unit 31, the certificate signing request transmitted in step S4.

[0080] The request verification unit 33 verifies the received 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.

[0081] 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.

[0082] An example of the verification of the certificate signing request performed by the certificate authority 30 as described above will be described below. First, Fig. 11 shows an example of the data structure of the verification information. 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.

[0083] Here, assuming that the certificate signing request received 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).Furthermore, 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).

[0084] 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 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 user request verification unit 33 acquires the user information provided by the communication unit 31 and uses it to verify the certificate signing request.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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).

[0089] 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 communication unit 31.

[0090] 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. Furthermore, the public key certificate for the edge device 10 issued by the certificate issuance unit 34 in this way is transmitted (provided) to the user terminal 20 via the communication unit 31 (step S5).

[0091] 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.

[0092] 15 shows an example of the data structure 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.

[0093] 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.

[0094] If the certificate issuance unit 34 determines that a certificate for the same public key has been issued in the past, it may discard the certificate signing request without issuing a public key certificate in response to the certificate signing request. In this case, the certificate issuance unit 34 may notify the user terminal 20 (or the user using the user terminal 20) that the certificate signing request has been discarded via the communication unit 31, or may send an alert to the administrator of the certification authority 30.

[0095] 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.

[0096] When the processing of step S5 is executed, the certificate acquisition unit 26 included in the user terminal 20 receives (acquires) the public key certificate transmitted in step S5 via the second communication unit 22. The public key certificate received 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 S6).

[0097] When the process of step S6 is executed, the registration unit 16 included in the edge device 10 receives the public key certificate transmitted in step S6 via the first communication unit 11. The public key certificate received by the registration unit 16 is registered (set) in the edge device 10. This completes the initial setting of the edge device 10.

[0098] In step S6, 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.

[0099] 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 S7). Note that in step S7, 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 legitimately issued for the public key of the edge device 10.

[0100] When the edge device 10 is authenticated by executing the process of step S7, 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 S8).

[0101] 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 by 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.

[0102] 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.

[0103] 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.

[0104] 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. Note that the verification of the public key certificate may be performed by, for example, the registration unit 16 included in the edge device 10.

[0105] 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.

[0106] As described above, in this embodiment, the edge device 10 (communications device) transmits a certificate signing request to the user terminal 20, 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. 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. The public key certificate issued by the certificate authority 30 in this manner is transmitted from the certificate authority 30 to the edge device 10 via the user terminal 20, and is registered in the edge device 10.

[0107] In this embodiment, the above-described configuration makes it possible to easily issue and register 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).

[0108] 16 shows an overview of the issuance of a public key certificate in a comparative example of this embodiment. As shown in Fig. 16, in the 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.

[0109] 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.

[0110] In contrast, Fig. 17 shows an overview of the issuance of a public key certificate in this embodiment. As shown in Fig. 17, 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.

[0111] 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.

[0112] 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).

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] 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).

[0119] 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.

[0120] 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.

[0121] 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.

[0122] In addition, this embodiment only requires a configuration that can issue and register 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.

[0123] (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.

[0124] Fig. 18 shows an example of a system configuration of a communication system according to this embodiment. As shown in Fig. 18, 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. 18 will be described as a first server device 40, and the server device 60 will be described as a second server device 60.

[0125] 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).

[0126] The user terminal 20 and the second server device 60 shown in FIG.

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

[0128] 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, separate functional units in Fig. 19, 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.

[0129] 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.

[0130] First, the processes of steps S11 and S12, which correspond to the processes of steps S1 and S2 shown in FIG. 9, are executed.

[0131] 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.

[0132] In this case, the certificate acquisition unit 26 included in the user terminal 20 executes user authentication processing with the second server device 60 (step S13). The user authentication processing is the same as that described in the first embodiment, and therefore a detailed description thereof will be omitted here. Also, between steps S12 and S13, a process of exchanging messages indicating the start of the certificate issuance processing between the user terminal 20 and the certification authority 30 may be inserted, but a detailed description thereof will be omitted.

[0133] After the process of step S13 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 S14).

[0134] If the user is authenticated based on the result of the user authentication process transmitted in step S14, the processes of steps S15 to S19, which correspond to the processes of steps S4 to S8 shown in FIG. 9, are executed.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] (Third embodiment) Next, a third 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.

[0139] Fig. 21 shows an example of the system configuration of a communication system according to this embodiment. As shown in Fig. 21, compared to the first embodiment described above, the communication system 1 includes a device registry 30a instead of the certificate authority 30, and an onboarding server 40a and an application server 40b instead of the server device 40.

[0140] The device registry 30a plays the role of the certificate authority 30 described in the first embodiment. That is, the device registry 30a issues a public key certificate for the edge device 10 through communication with the user terminal 20 communicatively connected via the network 51. The device registry 30a also generates information such as an identifier used by the edge device 10 in communication with the onboarding server 40a (hereinafter referred to as attribute information of the edge device 10). The attribute information of the edge device 10 generated in this manner is managed in the device registry 30a.

[0141] The onboarding server 40a and the application server 40b fulfill the role of the server device 40 described in the first embodiment. The onboarding server 40a is communicably connected to the edge device 10 via a network 52a. The application server 40b is communicably connected to the edge device 10 via a network 52b. The networks 52a and 52b may be the same network as the network 52 described in the first embodiment.

[0142] The edge device 10 acquires the attribute information of the edge device 10 managed in the device registry 30a along with the public key certificate of the edge device 10 via the user terminal 20. The edge device 10 executes communication with the onboarding server 40a using the acquired public key certificate and attribute information of the edge device 10. The onboarding server 40a holds various information (hereinafter referred to as communication execution information) necessary for the edge device 10 to execute communication with the application server 40b, and operates to provide the communication execution information to the edge device 10.

[0143] The application server 40b starts communication (application communication) with the edge device 10 using the communication execution information provided to the edge device 10 by the onboarding server 40a, and operates to provide IoT services.

[0144] The attribute information of the edge device 10 managed in the device registry 30a and the communication execution information held in the onboarding server 40a may be registered, for example, using the user terminal 20, or may be registered in advance by other methods.

[0145] The operation of the communication system 1 in this embodiment is the same as that described in the first embodiment, except that the device registry 30a is arranged in place of the certification authority 30 in the first embodiment described above, and the onboarding server 40a and the application server 40b are arranged in place of the server device 40 in the first embodiment, so a detailed explanation will be omitted here.

[0146] As described above, in this embodiment, even in a communication system 1 configured as shown in FIG. 21, it is possible to easily issue and register a public key certificate for an edge device 10 in a factory-shipped state, as in the first embodiment described above.

[0147] According to at least one of the above-described embodiments, it is possible to provide a communication system, a terminal apparatus, a communication device, and a method that can easily issue and register certificates used in communication.

[0148] 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 within the scope of the invention described in the claims and their equivalents. [Explanation of symbols]

[0149] 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, 23...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...communication unit, 32...verification information management unit, 33...request verification unit, 34...certificate issuance unit, 35...issuance history management unit, 30a...device registry, 40...server device (first server device), 40a...onboarding server, 40b...application server, 51, 52, 52a, 52b...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 a certificate signing request sent from the terminal device; The certificate issued by the certificate authority is transmitted from the certificate authority to the communication device via the terminal device and registered in the communication device. Communication system.

2. 2. The communication system according to claim 1, wherein the certificate includes a certificate for a public key of the communication device in a public key cryptosystem.

3. the terminal device instructs the communication device to generate the certificate signing request when the communication device and the terminal device are communicably connected; The communication device generates the certificate signing request in response to an instruction from the terminal device.