Communication system, terminal equipment, communication device, authentication station, and method

Abstract

To provide a communication system, terminal equipment, communication device, authentication station, and method capable of easily issuing a certificate to be used for communication.SOLUTION: A communication system comprising a communication device, terminal equipment, and an authentication station is provided. The communication device transmits a certificate signature request for requesting issuance of a certificate to be used for the communication device executing communication with a server device to the terminal equipment, the certificate signature request including device information, a configuration certification nonce, and an electronic signature generated for the device information and the configuration certification nonce using a secret key that is for the configuration certification and is held previously in the communication device. The terminal equipment transmits the certificate signature request transmitted from the communication device to the authentication station. Verification of the electronic signature included in the certificate signature request is performed using a public key for the configuration certification, a pair to the secret key for the configuration certification. The authentication station issues the certificate depending on a verification result.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0006] According to an embodiment, a communication system including a communication device, a terminal device, and a certificate authority is provided. The communication device transmits to the terminal device a certificate signing request for issuance of a certificate to be used by the communication device to communicate with a server device, the certificate signing request including device information about the communication device, an attestation nonce, and a digital signature generated for the device information and the attestation nonce using an attestation private key previously stored in the communication device. The terminal device transmits the certificate signing request transmitted from the communication device to the certificate authority. The digital signature included in the certificate signing request is verified using an attestation public key that is a pair with the attestation private key. The certificate authority issues the certificate according to the verification result. [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. 10 is a diagram showing an example of information managed by an attestation nonce management unit. [Figure 9] FIG. 10 is a diagram showing an example of information managed by an attestation key management unit. [Figure 10] FIG. 2 is a diagram illustrating an example of a hardware configuration of an edge device. [Figure 11] 1 is a sequence chart showing an example of a processing procedure of a communication system. [Figure 12] FIG. 10 is a diagram showing an example of a device confirmation screen. [Figure 13]FIG. 10 is a diagram showing an example of verification information. [Figure 14] FIG. 10 is a diagram showing another example of verification information. [Figure 15] FIG. 10 is a diagram showing yet another example of verification information. [Figure 16] FIG. 10 is a diagram showing yet another example of verification information. [Figure 17] FIG. 10 is a diagram showing an example of issuance history information. [Figure 18] FIG. 10 is a diagram showing an outline of issuing a public key certificate in a first 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 for explaining security threats in a second comparative example of the present embodiment. [Figure 21] FIG. 10 is a diagram for explaining the security effect of the present embodiment. [Figure 22] FIG. 10 is a diagram showing an example of the system configuration of a communication system according to a second embodiment. [Figure 23] FIG. 2 is a diagram showing an example of the functional configuration of a user terminal. [Figure 24] FIG. 2 is a diagram showing an example of the functional configuration of a certificate authority. [Figure 25] FIG. 2 is a diagram illustrating an example of the functional configuration of a server device. [Figure 26] 1 is a sequence chart showing an example of a processing procedure of a communication system. [Figure 27] FIG. 11 is a diagram showing an example of the functional configuration of a user terminal according to the third embodiment. [Figure 28] FIG. 2 is a diagram showing an example of the functional configuration of a certificate authority. [Figure 29] FIG. 10 is a diagram showing an example of information managed by an attestation secret management unit. [Figure 30] 1 is a sequence chart showing an example of a processing procedure of a communication system. [Figure 31] FIG. 13 is a diagram showing an example of the functional configuration of a certificate authority according to the fourth embodiment. [Figure 32] FIG. 10 is a diagram showing an example of agent information. [Figure 33] FIG. 1 is a diagram for explaining a specific mode of use 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, UART, and SPI, 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 operates as part of an application system for providing various IoT services by communicating with the server device 40. 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, 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 (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, for example, sensor data collected (measured) by the edge device 10 inside 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 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. 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 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 10a, a second communication unit 10b, a request generation unit 10c, a device information management unit 10d, a first key management unit 10e, a registration unit 10f, a second key management unit 10g, a signature generation unit 10h, and an application processing unit 10i.

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

[0022] 2, the first and second communication units 10a and 10b are shown as independent functional units, but the first and second communication units 10a and 10b may be realized as a single functional unit. Furthermore, the communication method used by the first communication unit 10a to execute communication may be different from or the same as the communication method used by the second communication unit 10b to execute communication.

[0023] The request generation unit 10c 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 10c is transmitted from the first communication unit 10a to the user terminal 20.

[0024] The device information management unit 10d 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] In Figure 3, the device information is described as including the manufacturer, model, serial number, installation location, administrator, and current time, 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.).

[0028] Furthermore, the device information management unit 10d may be located in hardware in which device information cannot be rewritten from the outside.

[0029] The first key management unit 10e 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 10c includes the public key of the edge device 10 managed by the first key management unit 10e.

[0030] Here, the key pair of the edge device 10 may be generated in response to an instruction from the request generation unit 10c when the request generation unit 10c generates a certificate signing request, for example. Alternatively, the key pair of the edge device 10 may be generated 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 first key management unit 10e 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.

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

[0032] The registration unit 10f executes a process of registering, in the edge device 10 (first key management unit 10e), a public key certificate issued by the certificate authority 30 in response to the certificate signing request generated by the request generation unit 10c.

[0033] In this embodiment, the second key management unit 10g manages a public key and a private key (a public key and a private key for attestation) for proving that the edge device 10 is an authentic or trustworthy device. This pair of a public key and a private key for attestation (an asymmetric cryptographic key pair) is referred to as an attestation key. The attestation key is generated by the manufacturer of the edge device 10 and written to the second key management unit 10g when the edge device 10 is manufactured (i.e., it is stored in advance in the edge device 10). The second key management unit 10g also manages a key ID (hereinafter referred to as an attestation key ID) for identifying the attestation key (a pair of a public key and a private key for attestation).

[0034] The signature generation unit 10h generates a digital signature using an attestation key (a private key for attestation) for the device information (information such as manufacturer, model, and serial number) and the attestation nonce (data including the nonce) managed by the device information management unit 10d. In the following description, this digital signature will be referred to as the attestation signature. The attestation nonce is a random number (for example, a disposable random character string) that is used only once, and is provided by the user terminal 20.

[0035] The above-mentioned device information, attestation nonce, attestation signature, and attestation key ID are passed to the request generator 10c and included in a certificate signing request generated by the request generator 10c.

[0036] In principle, the second key management unit 10g is located in hardware that cannot read or write data from outside (except from the signature generation unit 10h). In other words, in this embodiment, the attestation key is managed so that it can only be used by the signature generation unit 10h (i.e., only the signature generation unit 10h can generate an attestation signature).

[0037] The application processing unit 10i 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).

[0038] When the edge device 10 is authenticated (i.e., authentication is successful) by executing the device authentication process, the application processing unit 10i executes communication (application communication) with the server device 40 via the second communication unit 10b. The application processing unit 10i also executes processing on the edge device 10 side for providing IoT services (application processing corresponding to application communication). In this case, the application processing unit 10i may execute processing such as acquiring sensor data from a sensor mounted on the edge device 10 and transmitting the data to the server device 40. The application processing unit 10i may also execute 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. Furthermore, the application processing unit 10i may also execute processing such as updating firmware or software of the edge device 10 in accordance with an instruction from the server device 40.

[0039] 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 20a, a second communication unit 20b, a user information management unit 20c, a server information management unit 20d, an attestation nonce acquisition unit 20e, an initial setting processing unit 20f, and a certificate acquisition unit 20g.

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

[0041] 4, the first and second communication units 20a and 20b are shown as independent functional units, but the first and second communication units 20a and 20b may be realized as a single functional unit. Furthermore, the communication method used by the first communication unit 20a to communicate may be different from or the same as the communication method used by the second communication unit 20b to communicate.

[0042] The user information management unit 20c 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).

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

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

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

[0046] The server information management unit 20d manages information relating to the server device 40 (hereinafter referred to as server information).

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

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

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

[0050] The attestation nonce acquisition unit 20e requests the certificate authority 30 to issue an attestation nonce via the second communication unit 20b, and acquires (receives) the attestation nonce transmitted in response to the request from the certificate authority 30. The attestation nonce acquired by the attestation nonce acquisition unit 20e is passed from the attestation nonce acquisition unit 20e to the initial setting processing unit 20f.

[0051] The initial setting processing unit 20f 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 20f instructs the edge device 10 to generate a certificate signing request. In this case, the initial setting processing unit 20f provides (transmits) the attestation nonce passed from the attestation nonce acquisition unit 20e to the edge device 10 via the first communication unit 20a. In addition, during a series of initial settings of the edge device 10, the initial setting processing unit 20f provides (part of) the above-mentioned user information and server information to the edge device 10 as information to be set in the edge device 10 (hereinafter referred to as setting information).

[0052] Furthermore, the initial setting processing unit 20f acquires (receives) via the first communication unit 20a a certificate signature request transmitted from the edge device 10. The initial setting processing unit 20f verifies the acquired certificate signature request.

[0053] When the verification of the certificate signing request by the initial setting processing unit 20f is successful, the certificate acquiring unit 20g transfers (transmits) the certificate signing request to the certificate authority 30 via the second communication unit 20b. In addition, the certificate acquiring unit 20g acquires (receives) via the second communication unit 20b the public key certificate of the edge device 10 issued by the certificate authority 30 in response to the certificate signing request.

[0054] The public key certificate thus acquired by the certificate acquisition unit 20g is passed to the initial setting processing unit 20f and transferred (transmitted) to the edge device 10 via the first communication unit 20a.

[0055] 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 30a, an attestation nonce issuing unit 30b, an attestation nonce management unit 30c, a verification information management unit 30d, a first verification unit 30e, an attestation key management unit 30f, a second verification unit 30g, a certificate issuing unit 30h, and an issuance history management unit 30i.

[0056] The communication unit 30a communicates with the user terminal 20 via the network 51. The attestation nonce issuing unit 30b accepts a request (attestation nonce issuance request) from the user terminal 20 via the communication unit 30a and issues (generates) an attestation nonce. The attestation nonce issuing unit 30b issues an attestation nonce with a different value for each user terminal 20 (user using the user terminal 20) that is the requestor of the attestation nonce issuance request.

[0057] The attestation nonce issued by the attestation nonce issuing unit 30b is provided (transmitted) to the user terminal 20 via the communication unit 30a, and is also passed to the attestation nonce management unit 30c.

[0058] The attestation nonce management unit 30c manages the attestation nonce passed from the attestation nonce issuing unit 30b. As shown in Fig. 8, in addition to the attestation nonce (its value), the attestation nonce management unit 30c also manages the user ID for identifying the user to whom the attestation nonce is issued (the requestor) and the expiration date of the attestation nonce (the date during which the attestation nonce is valid in the verification process described below). An entry that has expired may be discarded at a predetermined timing, or may be updated with an entry that includes a new expiration date.

[0059] The verification information management unit 30d manages information (hereinafter referred to as verification information) used to verify a certificate signing request transmitted 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.

[0060] The first verification unit 30e acquires (receives) a certificate signing request transmitted from the user terminal 20 via the communication unit 30a, and verifies the certificate signing request using the verification information managed by the verification information management unit 30d. The first verification unit 30e also passes the acquired certificate signing request to the second verification unit 30g.

[0061] The attestation key management unit 30f manages the above-mentioned attestation keys (especially the public keys for attestation). As shown in FIG. 9, in addition to the attestation keys, the attestation key management unit 30f also manages a key ID (attestation key ID) for identifying the attestation keys and an expected device information value. The expected device information value corresponds to a range of values ​​or a conditional expression expected as device information for the edge device 10 that manages (holds) the attestation keys. The attestation key management unit 30f may also manage the source of the information managed by the attestation key management unit 30f (i.e., an ID indicating the entity that provided the attestation keys and the expected device information value).

[0062] The information managed by the attestation key management unit 30f is provided by the manufacturer of the edge device 10 prior to shipping of the edge device 10. Note that the certification authority 30 may employ a mechanism to charge the manufacturer of the edge device 10 when accepting the information managed by the attestation key management unit 30f from the manufacturer (i.e., when registering the information in the attestation key management unit 30f).

[0063] The second verification unit 30g verifies the attestation signature and device information included in the certificate signing request passed from the first verification unit 30e. In this case, the second verification unit 30g refers to information managed by the attestation nonce management unit 30c and the attestation key management unit 30f.

[0064] The certificate issuing unit 30h issues a public key certificate in accordance with the results of the verifications performed by the first and second verification units 30e and 30g. The public key certificate issued by the certificate issuing unit 30h is transmitted to the user terminal 20 from the communication unit 30a.

[0065] The issuance history management unit 30i manages information (hereinafter referred to as issuance history information) related to public key certificates previously issued by the certificate issuance unit 30h. 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 30i.

[0066] Fig. 10 shows an example of the hardware configuration of the above-mentioned edge device 10. As shown in Fig. 10, the edge device 10 includes a processor 101, a nonvolatile memory 102, a main memory 103, a communication interface (I / F) 104, and the like.

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

[0068] In this embodiment, some or all of the units 10a to 10i shown in FIG. 2 may be realized by causing the processor 101 shown in FIG. 10 to 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.

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

[0070] In this case, some or all of the units 20a to 20g 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.

[0071] Furthermore, some or all of the units 30a to 30i shown in FIG. 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.

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

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

[0074] 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 the issuance and registration of the public key certificate of the edge device 10 using the user terminal 20.

[0075] First, the user terminal 20 (for example, the attestation nonce acquisition unit 20e) executes user authentication processing with the certification authority 30 (step S1). The user authentication processing corresponds to a process in which, for example, a user ID and a password for identifying 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.

[0076] When the user is authenticated by executing the processing of step S1 (that is, when the user authentication processing confirms that the user using the user terminal 20 is a valid user), the attestation nonce acquisition unit 20e included in the user terminal 20 requests the certificate authority 30 to issue an attestation nonce via the second communication unit 20b. In this case, the second communication unit 20b transmits an attestation nonce issuance request to the certificate authority 30 (step S2). Note that the attestation nonce issuance request includes, for example, a user ID or the like for identifying the user who has requested the attestation nonce issuance request (that is, the user using the user terminal 20 that transmitted the attestation nonce issuance request).

[0077] The attestation nonce issuing unit 30b included in the certificate authority 30 receives the attestation nonce issuance request transmitted in step S2 via the communication unit 30a. The attestation nonce issuing unit 30b issues an attestation nonce in response to the received attestation nonce issuance request. The attestation nonce issued by the attestation nonce issuing unit 30b is transmitted from the communication unit 30a to the user terminal 20 (step S3). The attestation nonce management unit 30c manages the attestation nonce issued by the attestation nonce issuing unit 30b together with the user ID included in the attestation nonce issuance request and the expiration date set for the attestation nonce. In this case, the expiration date may be set to, for example, a time after a predetermined time (e.g., one minute) has elapsed since the time the attestation nonce was issued.

[0078] Next, 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 setting, 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, a message requesting the start of initial setting of the edge device 10 (hereinafter referred to as an initial setting start message) is transmitted from the first communication unit 20a to the edge device 10 in accordance with an instruction from the initial setting processing unit 20f included in the user terminal 20 (step S4). Note that by executing the processing of step S4, the user terminal 20 instructs the edge device 10 to generate a certificate signing request.

[0079] Here, the attestation nonce transmitted in the above-mentioned step S3 is acquired by the attestation nonce acquisition unit 20e via the second communication unit 20b. The attestation nonce acquired by the attestation nonce acquisition unit 20e is passed from the attestation nonce acquisition unit 20e to the initial setup processing unit 20f. In this case, in the above-mentioned step S4, an initial setup start message including the attestation nonce passed from the attestation nonce acquisition unit 20e to the initial setup processing unit 20f is transmitted to the edge device 10.

[0080] In addition, when the initial setting start message is sent in step S4, setting information (information to be set in the edge device 10) obtained from user information managed by the above-mentioned user information management unit 20c may be provided from the user terminal 20 to the edge device 10.

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

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

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

[0084] When the process of step S4 is executed, the request generator 10c included in the edge device 10 acquires the initial setting start message transmitted in step S4 via the first communicator 10a.

[0085] The request generation unit 10c 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 10c is, for example, a Certificate Signing Request (CSR) conforming to PKCS#10 (RFC2986) of the Public-Key Cryptography Standards (PKCS).

[0086] The certificate signing request includes the public key of the edge device 10 managed by the first key management unit 10e. The certificate signing request also includes, for example, device information managed by the device information management unit 10d and an attestation nonce included in the initial setting start message.

[0087] The signature generation unit 10h also obtains an attestation key from the second key management unit 10g and generates an attestation signature for the device information and attestation nonce. The attestation signature corresponds to a digital signature for the device information and attestation nonce using the attestation key. The attestation signature is generated, for example, by performing cryptographic processing using the attestation key (a private key for attestation) on the hash value of the device information and attestation nonce.

[0088] The attestation signature generated by the signature generation unit 10h as described above is used to verify the authenticity of the device information included in the certificate signing request, and is passed from the signature generation unit 10h to the request generation unit 10c. The signature generation unit 10h passes the attestation key ID obtained from the second key management unit 10g, along with the attestation signature, to the request generation unit 10c.

[0089] According to this, the request generating unit 10c generates a certificate signing request including the attestation signature and the attestation key ID, as well as the above-mentioned public key, device information, and attestation nonce.

[0090] The certificate signing request thus generated by the request generating unit 10c is transmitted from the first communication unit 10a to the user terminal 20 (step S5).

[0091] The certificate signing request may 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. By referring to the certificate signing request (the information included in the certificate signing request), it becomes 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).

[0092] When the process of step S5 is executed, the initial setting processing unit 20f included in the user terminal 20 acquires the certificate signing request transmitted in step S5 via the first communication unit 20a.

[0093] The initial setting processing unit 20f 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.

[0094] If the verification of the certificate signature request is successful, the initial setting processing unit 20f passes the certificate signature request to the certificate acquisition unit 20g, and if the verification of the certificate signature request is unsuccessful, the initial setting processing unit 20f discards the certificate signature request. If the certificate signature request is discarded, the initial setting processing unit 20f may notify the user of an error.

[0095] 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 (hereinafter referred to as a device confirmation screen) such as that shown in FIG. 12. This allows the user to check whether the certificate signing request acquired (received) by the user terminal 20 is the certificate signing request generated by the edge device 10 intended by the user.

[0096] 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 obtained (i.e., to execute the processing from step S6 onwards).

[0097] If the verification of the certificate signature request is successful, the certificate acquisition unit 20g executes user authentication processing with the certificate authority 30 (step S6). The processing in step S6 is the same as the processing in step S1, and therefore a detailed description thereof will be omitted here.

[0098] As described above, the user authentication process is executed in step S1. Therefore, if the user authentication process is executed in step S1 and authentication session information (information indicating that the user has already been authenticated) is held in the user terminal 20 or the authentication authority 30, the process of step S6 may be omitted.

[0099] Next, the certificate acquisition unit 20g transfers the certificate signing request acquired by the initial setting processing unit 20f to the certificate authority 30 via the second communication unit 20b (step 7).

[0100] When the process of step S7 is executed, the first verification unit 30e included in the certificate authority 30 acquires the certificate signing request transferred from the user terminal 20 in step S7 via the communication unit 30a.

[0101] The first verification unit 30e verifies the acquired certificate signing request based on the verification information managed by the verification information management unit 30d. If attribute information of 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 the certificate is set in advance by, for example, a user, verification of the certificate signing request may include confirmation of whether the edge device 10 or the attribute information is appropriate. In this case, the attribute information may include, for example, the installation location of the edge device 10, information about the administrator, etc.

[0102] In addition, the verification of the certificate signing request may be performed by checking whether the data structure of the certificate signing request and the information contained in the certificate signing request conform to the specifications required by the certification authority 30.

[0103] An example of the process relating to the verification of the certificate signature request (hereinafter referred to as the first verification process) performed by the first verification unit 30e as described above will be described below.

[0104] First, Fig. 13 shows an example of verification information. In the example shown in Fig. 13, 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 associated with each other. Verification information (entry) whose expiration date has expired may be discarded at a predetermined timing, or may be updated with an entry including a new expiration date.

[0105] Here, assuming that the certificate signing request acquired by the first verification unit 30e 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).

[0106] 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. 14, information including a user ID and an affiliation of the user in association with each other as shown in Fig. 15, or information including a user ID and an installation location of the edge device 10 in association with each other as shown in Fig. 16. Even in the case of the verification information as shown in Figs. 14 to 16, the first verification process can be executed by comparing the certificate signing request with the verification information.

[0107] The verification information managed by the verification information management unit 30d may be information having a structure that combines the above-described information shown in FIGS.

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

[0109] In the first verification process described above, the certificate signing request is verified by comparing the certificate signing request with verification information. However, if the authenticity of the device information (e.g., serial number, etc.) included in the certificate signing request cannot be confirmed (i.e., if the certificate signing request contains false device information), there is a possibility that a public key certificate will be issued to a device to which a public key certificate should not be issued.

[0110] For this reason, in this embodiment, the second verification unit 30g executes the second verification process separately from the first verification process described above. Note that the second verification process may be executed before or after the first verification process, or may be executed in parallel with the first verification process.

[0111] An example of the second verification process will be described below. In the second verification process, the attestation signature, device information, and attestation nonce are verified.

[0112] When the second verification process is executed, the certificate signing request and the user ID (user ID for identifying the user using the user terminal 20 that transferred the certificate signing request to the certification authority 30) are passed from the first verification unit 30e to the second verification unit 30g.

[0113] First, the verification of the attestation signature will be described. Assuming that the information shown in FIG. 9 is managed by the attestation key management unit 30f, the second verification unit 30g uses the attestation key ID included in the certificate signing request passed from the first verification unit 30e to obtain from the attestation key management unit 30f the attestation key (public key for attestation) associated with the attestation key ID. The second verification unit 30g uses the obtained attestation key to verify the attestation signature included in the certificate signing request. Specifically, the second verification unit 30g calculates a hash value of the device information and attestation nonce included in the certificate signing request, and compares the calculated hash value with the result (hash value) of encrypting the attestation signature included in the certificate signing request with the public key for attestation. In this case, if the hash values ​​of the device information and attestation nonce match the hash value obtained from the attestation signature, it can be confirmed that the verification of the attestation signature has been successful.

[0114] Next, verification of device information will be described. Assuming that the information shown in FIG. 9 is managed by the attestation key management unit 30f as described above, the second verification unit 30g uses the attestation key ID included in the certificate signing request passed from the first verification unit 30e to obtain from the attestation key management unit 30f the expected device information value associated with the attestation key ID. The second verification unit 30g compares the device information included in the certificate signing request with the expected device information value obtained from the attestation key management unit 30f and verifies whether the device information satisfies the expected device information value. Specifically, assuming that the attestation key ID is "xxxx" as shown in FIG. 9, if the device information included in the certificate signing request indicates that the manufacturer is "A1," the model is "B1," and the firmware version is "1.1.9 or higher," it can be confirmed that the verification of the device information has been successful. Also, assuming that the attestation key ID is "yyyy" as shown in Figure 9, if the manufacturer of the device information included in the certificate signing request is "A2", the model is "B2", and the serial number is "C101", "C102", or "C103", it can be confirmed that the verification of the device information was successful.

[0115] Next, verification of the attestation nonce will be described. Assuming that the information shown in FIG. 8 is managed by the attestation nonce management unit 30c, the second verification unit 30g uses the attestation nonce included in the certificate signing request passed from the first verification unit 30e to obtain the expiration date associated with the attestation nonce (its value) from the attestation nonce management unit 30c. In this manner, the second verification unit 30g can confirm that the verification of the attestation nonce has been successful if the expiration date obtained from the attestation nonce management unit 30c has not expired (i.e., the attestation nonce is within the expiration date). Note that in verifying the attestation nonce, the second verification unit 30g may obtain from the attestation nonce management unit 30c the user ID associated with the attestation nonce (its value) included in the certificate signing request passed from the first verification unit 30e, and verify whether the obtained user ID matches the user ID passed from the first verification unit 30e.

[0116] If at least one of the verifications of the attestation signature, device information, and attestation nonce performed in the second verification process as described above fails (i.e., if an error occurs during the verification), the second verification unit 30g notifies the first verification unit 30e of the error.

[0117] The first verification unit 30e passes the certificate signing request to the certificate issuing unit 30h if the verification in the first and second verification processes described above is successful, and discards the certificate signing request if the verification in the first or second verification process is unsuccessful. Note that if the certificate signing request is discarded, the first verification unit 30e may notify the user terminal 20 (or the user using the user terminal 20) of an error via the communication unit 30a.

[0118] If the verifications in the first and second verification processes are successful, the certificate issuance unit 30h takes over the process from the first verification unit 30e and issues a public key certificate for the edge device 10 in response to the certificate signing request passed from the first verification unit 30e. Once the public key certificate is issued by the certificate issuance unit 30h in this manner, issuance history information related to the issued public key certificate is managed by the issuance history management unit 30i. The public key certificate for the edge device 10 issued by the certificate issuance unit 30h in this manner is transmitted from the communication unit 30a to the user terminal 20 (step S8).

[0119] Here, it has been explained that a public key certificate is issued if the verification in the first and second verification processes is successful, but the certificate issuing unit 30h may also issue a public key certificate based on issuance history information (history of public key certificates issued in the past) managed by the issuance history management unit 30i.

[0120] 17 shows an example of the issuance history information. As shown in Fig. 17, 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.

[0121] 17, the certificate issuing unit 30h 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 30i). 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.

[0122] If the certificate issuance unit 30h determines that a certificate for the same public key has been issued in the past, it 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 30h 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 30a, or may notify the administrator of the certification authority 30 of an alert.

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

[0124] When the process of step S8 is executed, the certificate acquisition unit 20g included in the user terminal 20 acquires the public key certificate transmitted in step S8 via the second communication unit 20b. The public key certificate acquired by the certificate acquisition unit 20g is passed to the initial setting processing unit 20f and transmitted from the first communication unit 20a to the edge device 10 (step S9).

[0125] When the process of step S9 is executed, the registration unit 10f included in the edge device 10 acquires the public key certificate transmitted in step S9 via the first communication unit 10a. The public key certificate acquired by the registration unit 10f is registered (set) in the edge device 10. This completes the initial setting of the edge device 10.

[0126] In step S9, configuration information (e.g., server information managed by the server information management unit 20d) 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 registered in the edge device 10.

[0127] 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 S10). Note that in step S10, 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.

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

[0129] 11, for example, the first key management unit 10e 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 first key management unit 10e. 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.

[0130] In this case, the edge device 10 transmits a certificate signing request with an electronic signature attached to it to the user terminal 20, and the initial setting processing unit 20f 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. The verification of the certificate signing request is successful when the hash value of the certificate signing request matches the hash value obtained from the electronic signature.

[0131] 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. However, 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 first verification unit 30e 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.

[0132] 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 20g 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 10f included in the edge device 10.

[0133] 11 is an example, and in this embodiment, a process that is partially different from the process described in Fig. 11 may be executed, or a process that omits part of the process described in Fig. 11 may be executed. Specifically, in this embodiment, for example, first and second verification processes are executed, but part of the first and second verification processes may be changed or omitted, or a verification process different from the first and second verification processes may be further executed.

[0134] As described above, in this embodiment, the edge device 10 (communications device) transmits to the user terminal 20 (terminal device) a certificate signing request requesting the issuance of a certificate to be used by the edge device 10 to communicate with the server device 40. The certificate signing request includes device information about the edge device 10, an attestation nonce, and an attestation signature (digital signature) generated for the device information and the attestation nonce using an attestation key (private key for attestation) previously stored in the edge device 10. Also, in this embodiment, the user terminal 20 transmits (transfers) the certificate signing request transmitted from the edge device 10 to the certificate authority 30. In this case, the certificate authority 30 uses the public key for attestation to verify the attestation signature included in the certificate signing request transmitted from the user terminal 20, and issues a public key certificate according to the verification result.

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

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

[0137] However, in the first 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.

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

[0139] According to this configuration, unlike the first comparative example of this embodiment described above, if the certification authority 30 has information such as that shown in FIG. 9 pre-registered, the 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.

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

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

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

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

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

[0145] Furthermore, according to this embodiment, a configuration is adopted in which the authenticity of device information is verified using an attestation signature in the second verification process. The security effects of adopting such a configuration will be described below.

[0146] First, with reference to FIG. 20, a description will be given of security threats (security risks) in the case where the configuration for verifying the authenticity of the device information described above is not adopted (hereinafter referred to as a second comparative example of this embodiment).

[0147] 20, it is assumed that a large number of sensor devices installed in a power plant, for example, operate as edge devices 10, and that the sensor devices connect to a power plant remote monitoring service built on a cloud service (that is, communicate with a server device 40 that provides the power plant remote monitoring service). The sensor devices are manufactured, sold, and delivered by device manufacturers, and are configured to measure data (sensor data) related to the operating status of various pieces of equipment installed in the power plant.

[0148] In the second comparative example of this embodiment, an inspector at the power plant can use the user terminal 20 to issue a public key certificate at the certification authority 30 and register the public key certificate in each sensor device. The public key certificate is issued when the verification of the certificate signing request using the verification information managed by the verification information management unit 30d included in the certification authority 30 is successful.

[0149] Each sensor device uploads (transmits) sensor data (measurement data) to the power plant remote monitoring service using the public key certificate registered on that sensor device. This makes it possible to realize a power plant remote monitoring service that analyzes the sensor data uploaded from the sensor devices and constantly monitors the equipment installed within the power plant for abnormalities. If an abnormality is discovered, the power plant remote monitoring service issues an alert to the monitor and prompts them to take action regarding the alert (i.e., the abnormality).

[0150] Incidentally, the verification information managed by the verification information management unit 30d as shown in Fig. 20 is registered in the verification information management unit 30d (certification authority 30) when the sensor devices purchased by the monitor from the device manufacturer are delivered. The verification information (entry) shown in Fig. 20 indicates that the owner of the sensor devices (four sensor devices with serial numbers "01" to "04") delivered by the device manufacturer is the monitor. According to such verification information, only the monitor can issue public key certificates to the sensor devices using the user terminal 20 and use the power plant remote monitoring service.

[0151] Here, assume that during the distribution process of sensor devices from device manufacturers to monitors as described above, a malicious third party (e.g., a terrorist) has an opportunity to get hold of the sensor device. In this case, the malicious third party may prepare sophisticated counterfeit sensor devices, replace some or all of the multiple sensor devices manufactured by the device manufacturer with the counterfeit devices (hereinafter referred to as counterfeit devices), and deliver the counterfeit devices to the monitors. Note that FIG. 20 shows a case where, for example, a sensor device with serial number "04" (hereinafter referred to as a genuine device) out of four sensor devices with serial numbers "01" to "04" has been replaced with a counterfeit device (i.e., a counterfeit device has been mixed in).

[0152] It is assumed that a malicious third party reads device information from a genuine device and copies the device information to the fake device before delivering the fake device to the monitor. In such a case, the fake device holds the same device information as the genuine device. Therefore, in the second comparative example of this embodiment, when the initial setting process is executed, the certificate authority 30 recognizes that the fake device has been registered in the verification information management unit 30d, and a public key certificate is issued for the fake device.

[0153] In this case, for example, a fake device may operate in the same way as a legitimate device for a while, uploading measured sensor data (data on the operating status of equipment) to a power plant remote monitoring service, but then operate the fake device to upload false data upon receiving a remote command from a malicious third party or upon reaching a specified time. If this false data indicates an abnormality in equipment installed in the power plant, the power plant remote monitoring service will frequently issue alarms to monitors based on the false data, forcing the monitors to respond to the alarms. This could cause confusion at the power plant and ultimately lead to a shutdown of the power plant.

[0154] On the other hand, as shown in FIG. 21, when adopting a configuration for verifying the authenticity of device information as described in this embodiment, the device manufacturer generates an attestation key 100 when manufacturing each sensor device and registers the generated attestation key 100 in the second key management unit 10g included in the sensor device. Note that the second key management unit 10g is located in hardware known as a secure element, for example, and is configured to prevent external reading and writing of data after shipment. Furthermore, in this embodiment, the device manufacturer registers the attestation key (public key for attestation) in the certification authority 30 (attestation key management unit 30f) before selling and delivering the sensor device to a monitor.

[0155] As explained in the second comparative example of this embodiment, it is assumed that a malicious third party obtains a sensor device (a genuine device) during the distribution process of sensor devices and delivers a fake device to a monitor by copying the appearance, basic functions, device information, etc. of the genuine device. However, as explained above, the attestation key in the genuine device is kept secret within the secure element, so the malicious third party cannot copy the attestation key, and the fake device does not hold the attestation key.

[0156] According to this, in this embodiment, the above-mentioned attestation signature verification is performed when processing related to initial setup is executed, thereby making it possible to issue a public key certificate in response to a certificate signing request from a genuine device, but discard a certificate signing request from a fake device (i.e., since there is no valid attestation signature, a public key certificate is not issued to the fake device).

[0157] As described above, the configuration of this embodiment for verifying the authenticity of device information (i.e., verifying the attestation signature) makes it possible to prevent counterfeit devices prepared by malicious third parties such as terrorists from connecting to the power plant remote monitoring service (i.e., to avoid security threats).

[0158] Although the verification of the attestation signature performed in the second verification process has been described above, the second verification process also includes verification of device information and verification of the attestation nonce. This configuration can further reduce security risks in IoT services.

[0159] In addition, in order to reduce security risks, the verification of the certificate signature request performed in the first verification process may be performed using the electronic signature attached to the certificate signature request, or the verification of the public key certificate issued by the certification authority 30 may be performed using the electronic signature attached to the public key certificate (electronic signature generated by the certification authority 30).

[0160] Furthermore, in this embodiment, it becomes possible to issue a public key certificate in response to a request from a legitimate user by executing a user authentication process for the user who owns the edge device 10 between the user terminal 20 and the certificate authority 30. Note that, although the user authentication process has been described as being executed by the certificate authority 30 in this embodiment, it is also possible to configure the user authentication process to be executed by a device different from the certificate authority 30 (for example, the server device 40 or another server device different from the server device 40, etc.).

[0161] In addition, in this embodiment, a configuration may be adopted in which a decision is made as to whether to issue a public key certificate based on issuance history information about public key certificates issued in the past. This configuration makes it possible to avoid 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.

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

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

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

[0165] Fig. 22 shows an example of the system configuration of a communication system according to this embodiment. In Fig. 22, the same parts as those in Fig. 1 are given the same reference numerals, and detailed description thereof will be omitted.

[0166] As shown in FIG. 22, the communication system 1 according to this embodiment further includes a server device 60 different from the server device 40 in the first embodiment described above.

[0167] The server device 60 is communicatively connected to the user terminal 20 via the network 51, and is configured to perform a process (i.e., a second verification process) to verify the authenticity of the device information described in the first embodiment above.

[0168] In other words, this embodiment differs from the first embodiment in that the server device 60 performs the second verification process instead of the certificate authority 30. The server device 60 in this embodiment corresponds to an independent server device (verification server device) for performing verification in the second verification process.

[0169] In this embodiment, the user terminal 20 communicates with the edge device 10 , the certificate authority 30 , and the server device 60 to perform processing related to the initial setting of the edge device 10 .

[0170] Although the server device 60 has been described here as being communicatively connected to the user terminal 20 via the network 51, the server device 60 may also be communicatively connected to the user terminal 20 via a network different from the network 51.

[0171] The server device 60 may be operated by the same entity as or a different entity from the certificate authority 30. Specifically, the server device 60 may be operated by, for example, a device manufacturer.

[0172] Fig. 23 shows an example of the functional configuration of the user terminal 20 in this embodiment. In Fig. 23, the same parts as those in Fig. 4 are given the same reference numerals, and detailed description thereof will be omitted.

[0173] As shown in FIG. 23, the user terminal 20 further includes a third communication unit 20h and a verification request unit 20i, as compared with the first embodiment described above.

[0174] The third communication unit 20h communicates with the server device 60 via the network 51. Although the third communication unit 20h is shown as a functional unit separate from the first communication unit 20a and the second communication unit 20b in Fig. 23, the third communication unit 20h may be realized as the same functional unit as at least one of the first communication unit 20a and the second communication unit 20b. The communication method used by the third communication unit 20h to communicate may be different from or the same as the communication method used by the first communication unit 20a and the communication method used by the second communication unit 20b to communicate.

[0175] The verification request unit 20i requests the server device 60 to perform verification in the second verification process (for example, verification of the attestation signature, etc.) via the third communication unit 20h.

[0176] Fig. 24 shows an example of the functional configuration of the certificate authority 30 in this embodiment. In Fig. 24, the same parts as those in Fig. 7 are given the same reference numerals, and detailed description thereof will be omitted.

[0177] As shown in FIG. 24, the certificate authority 30 further includes a third verification unit 30j, as compared with the first embodiment described above.

[0178] In this embodiment, the server device 60 performs the verification in the second verification process, but the third verification unit 30j acquires the verification result from the server device 60 via the communication unit 30a and verifies the verification result.

[0179] As shown in Figure 24, the attestation nonce issuing unit 30b, attestation nonce management unit 30c, attestation key management unit 30f, and second verification unit 30g described in the first embodiment above do not have to be included in the certification authority 30 (i.e., they may be omitted from the certification authority 30).

[0180] Fig. 25 shows an example of the functional configuration of the server device 60 in this embodiment. As shown in Fig. 25, the server device 60 includes a communication unit 60a, an attestation nonce issuing unit 60b, an attestation nonce management unit 60c, an attestation key management unit 60d, a verification unit 60e, and a verification server key management unit 60f.

[0181] The communication unit 60a communicates with the user terminal 20 via the network 51. In this embodiment, the server device 60 performs verification in the second verification process instead of the certification authority 30, and the attestation nonce issuing unit 60b, the attestation nonce management unit 60c, the attestation key management unit 60d, and the verification unit 60e shown in Fig. 25 are functional units corresponding to the attestation nonce issuing unit 30b, the attestation nonce management unit 30c, the attestation key management unit 30f, and the second verification unit 30g included in the certification authority 30 described in the first embodiment.

[0182] The verification server key management unit 60f manages the private key and public key (key pair) of the server device 60 in the public key cryptosystem. The private key of the server device 60 managed by the verification server key management unit 60f is used to generate a digital signature to be attached to the verification result of the verification unit 60e.

[0183] Here, the functional configurations of the user terminal 20, the certificate authority 30, and the server device 60 have been described, but the functional configuration of the edge device 10 in this embodiment is the same as that described in FIG. 2, and therefore a detailed description thereof will be omitted.

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

[0185] First, the attestation nonce acquisition unit 20e included in the user terminal 20 requests the server device 60 to issue an attestation nonce via the second communication unit 20b. In this case, an attestation nonce issuance request is sent from the second communication unit 20b to the server device 60 (step S21). Note that the attestation nonce issuance request sent in step S21 is the same as the attestation nonce issuance request sent in step S2 shown in Fig. 11, and therefore a detailed description thereof will be omitted here.

[0186] 11, the user authentication process is executed before the attestation nonce issuance request is sent. However, the user authentication process between the user terminal 20 and the server device 60 may be omitted. The user terminal 20 is assumed to have authentication information for connecting to the server device 60 pre-installed. The authentication information includes, for example, a pair of a user terminal ID and a shared key (a key shared between the user terminal 20 and the server device 60 for communication), a public key certificate, etc. Even when multiple users use the user terminal 20 (for example, when multiple employees use a business user terminal 20), the user terminal 20 is assumed to be able to connect to the server device 60 by presenting the same authentication information.

[0187] The attestation nonce issuing unit 60b included in the server device 60 receives the attestation nonce issuance request transmitted in step S21 via the communication unit 60a. The attestation nonce issuing unit 60b issues an attestation nonce in response to the received attestation nonce issuance request. The attestation nonce issued by the attestation nonce issuing unit 60b is transmitted from the communication unit 60a to the user terminal 20 (step S22). Note that the attestation nonce transmitted in step S22 is the same as the attestation nonce transmitted in step S3 shown in FIG. 11, and therefore a detailed description thereof will be omitted here.

[0188] Next, the processes of steps S23 and S24, which correspond to the processes of steps S4 and S5 shown in FIG. 11, are executed.

[0189] Here, the initial setting processing unit 20f included in the user terminal 20 acquires the certificate signature request transmitted in step S24 via the first communication unit 20a. As described in the first embodiment, the initial setting processing unit 20f verifies the acquired certificate signature request. If the verification of the certificate signature request is successful, the initial setting processing unit 20f passes the certificate signature request to the verification request unit 20i.

[0190] The verification request unit 20i acquires the device information, attestation nonce, attestation signature, and attestation key ID included in the certificate signing request passed from the initial setting processing unit 20f from the certificate signing request. The verification request unit 20i transmits the device information, attestation nonce, attestation signature, and attestation key ID acquired from the certificate signing request in this way from the third communication unit 20h to the server device 60, thereby requesting the server device 60 to perform verification in the second verification process described in the first embodiment (step S25).

[0191] When the process of step S25 is executed, the verification unit 60e included in the server device 60 acquires, via the communication unit 60a, the device information, the attestation nonce, the attestation signature, and the attestation key ID transmitted in step S25.

[0192] The verification unit 60e executes the second verification process described in the first embodiment. Upon completion of the second verification process, the verification unit 60e generates a digital signature for the result of the second verification process (whether the verification performed in the second verification process was successful or failed) and the device information (data including the result) using the private key of the server device 60 managed by the verification server key management unit 60f. Hereinafter, the data to which the digital signature generated by the verification unit 60e for the result of the second verification process and the device information is attached will be referred to as verification result data. The verification result data is transmitted from the communication unit 60a to the user terminal 20 (step S26).

[0193] When the process of step S26 is executed, the verification request unit 20i included in the user terminal 20 acquires, via the third communication unit 20h, the verification result data transmitted from the server device 60 in step S26. The verification request unit 20i executes a verification process (hereinafter referred to as a third verification process) based on the acquired verification result data.

[0194] In this case, the verification request unit 20i verifies the result of the second verification process and the digital signature attached to the device information in the verification result data, for example, by using the public key of the server device 60. Note that the verification of the digital signature is as described in the first embodiment, and therefore a detailed description thereof will be omitted here.

[0195] Furthermore, the verification request unit 20i verifies the verification result performed in the second verification process in the verification result data. In this case, the verification request unit 20i checks whether the verification performed in the second verification process is successful.

[0196] If all the verifications performed in the third verification process are successful (passed), the process proceeds to step S27, which corresponds to step S6 shown in Fig. 11. If the user is authenticated by the process of step S27, the certificate signing request and verification result data are transmitted from the second communication unit 20b to the certificate authority 30 (step S28).

[0197] When the process of step S28 is executed, the first verification unit 30e included in the certificate authority 30 acquires, via the communication unit 30a, the certificate signature request and verification result data transmitted from the user terminal 20 in step S28.

[0198] In this case, the first verification unit 30e executes the first verification process (i.e., verification of the certificate signature request) described in the first embodiment. The first verification unit 30e also passes the verification result data to the third verification unit 30j, which then executes the third verification process based on the verification result data. Since the third verification process is similar to the process executed in the user terminal 20 described above, a detailed description thereof will be omitted here.

[0199] If the verifications in the first and third verification processes are successful, the certificate issuance unit 30h issues a public key certificate for the edge device 10 in response to the certificate signing request passed from the first verification unit 30e, as described in the first embodiment. Once the public key certificate is issued by the certificate issuance unit 30h in this manner, the issued public key certificate is transmitted from the communication unit 30a to the user terminal 20 (step S29).

[0200] After the process of step S29 is executed, the processes of steps S30 to S32, which correspond to the processes of steps S9 to S11 shown in FIG. 11, are executed.

[0201] As described above, in this embodiment, even if the communication system 1 is configured such that the server device 60 (verification server) performs the second verification process (such as verifying the attestation signature) instead of the certification authority 30, it is possible to easily issue a public key certificate (a public key certificate used by the edge device 10 for communication) to the edge device 10 in its factory-shipped state.

[0202] (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. Note that the system configuration of the communication system according to this embodiment is the same as that in FIG. 1, so detailed descriptions thereof will be omitted and the description will be made using FIG. 1.

[0203] In the first embodiment described above, the certificate authority 30 issues the attestation nonce, but this embodiment differs from the first embodiment in that the user terminal 20 issues the attestation nonce.

[0204] Fig. 27 shows an example of the functional configuration of the user terminal 20 in this embodiment. In Fig. 27, the same parts as those in Fig. 4 are given the same reference numerals, and detailed description thereof will be omitted.

[0205] As shown in FIG. 27, the user terminal 20 further includes an attestation secret management unit 20j and an attestation nonce issuing unit 20k, as compared with the first embodiment described above.

[0206] In this embodiment, the user terminal 20 issues an attestation nonce, and in this embodiment, as in the first embodiment, it is necessary to verify the attestation signature using the attestation nonce. For this reason, in this embodiment, secret data (hereinafter referred to as an attestation secret) is shared in advance between the user terminal 20 and the certification authority 30. The attestation secret management unit 20j manages the attestation secret shared with the certification authority 30 in this manner. The attestation nonce issuing unit 20k issues an attestation nonce generated from the attestation secret managed by the attestation secret management unit 20j.

[0207] Fig. 28 shows an example of the functional configuration of the certificate authority 30 in this embodiment. In Fig. 27, the same parts as those in Fig. 7 are given the same reference numerals, and detailed description thereof will be omitted.

[0208] As shown in FIG. 28, the certificate authority 30 further includes an attestation secret management unit 30k, as compared with the first embodiment described above.

[0209] As described above, the attestation secret management unit 30k manages the attestation secret shared with the user terminal 20. The attestation secret managed by the attestation secret management unit 30k is used when the second verification unit 30g executes the second verification process.

[0210] 29, the attestation secret management units 20j and 30k further manage a user ID for identifying a user who uses the user terminal 20 and the expiration date of the attestation secret in addition to the attestation secret (its value). An entry whose expiration date has expired may be discarded at a predetermined timing, or may be updated to an entry including a new expiration date.

[0211] The attestation secret management units 20j and 30k manage different attestation secrets for each user. In this case, for example, when a user performs initial setup of the user terminal 20, an attestation secret for that user is generated, and the generated attestation secret is shared between the user terminal 20 and the certificate authority 30.

[0212] Here, the functional configurations of the user terminal 20 and the certificate authority 30 have been described, but the functional configuration of the edge device 10 in this embodiment is the same as that described in FIG. 2, and therefore a detailed description thereof will be omitted.

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

[0214] First, when the power of the edge device 10 is turned on, for example, in a factory-shipped state, the edge device 10 enters a state of waiting for initialization, 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 attestation nonce issuing unit 20k included in the user terminal 20 issues an attestation nonce using an attestation secret managed by the attestation secret management unit 20j. The attestation nonce is generated by applying a predetermined algorithm to, for example, an attestation secret associated with a user ID for identifying the user operating the user terminal 20 and the current time. The predetermined algorithm may be, for example, the Time-Based One-Time Password Algorithm (RFC6238).

[0215] When the attestation nonce is issued by the attestation nonce issuing unit 20k as described above, an initial setting start message including the attestation nonce is transmitted from the first communication unit 20a to the edge device 10 in accordance with an instruction from the initial setting processing unit 20f (step S41).

[0216] After the process of step S41 is executed, the processes of steps S42 to S44, which correspond to the processes of steps S5 to S7 shown in FIG. 11, are executed.

[0217] When the process of step S44 is executed, the first verification unit 30e included in the certificate authority 30 acquires the certificate signing request transferred from the user terminal 20 in step S44 via the communication unit 30a.

[0218] In this case, the first verification process is executed by the first verification unit 30e. The first verification process is the same as that explained in the first embodiment, and therefore a detailed explanation thereof will be omitted here.

[0219] Further, the second verification unit 30g executes a second verification process. In the second verification process of this embodiment, the second verification unit 30g uses a user ID (user ID passed from the first verification unit 30e) for identifying the user of the user terminal 20 that sent the certificate signing request to acquire an attestation secret associated with the user ID from the attestation secret management unit 30k. The second verification unit 30g generates (calculates) an attestation nonce from the acquired attestation secret, compares the generated attestation nonce with the attestation nonce included in the certificate signing request, and verifies whether the two match. Such verification is successful when the attestation nonce generated from the attestation secret in the certificate authority 30 (second verification unit 30g) matches the attestation nonce included in the certificate signing request.

[0220] As described above, if the attestation nonce is issued in the user terminal 20 by applying the Time-Based One-Time Password Algorithm (RFC6238) to the attestation secret and the current time, the second verification unit 30g generates multiple attestation nonces by applying RFC6238 to the attestation secret obtained from the attestation secret management unit 30k, the current time, and several past times, and verifies whether one of the multiple attestation nonces thus generated matches the attestation nonce included in the certificate signing request.

[0221] In the second verification process executed in this embodiment, the attestation signature, device information, and attestation nonce described in the first embodiment may be further verified.

[0222] If the verification is successful in the first and second verification processes, a public key certificate of the edge device 10 is issued, and the processes of steps S45 to S48, which correspond to the processes of steps S8 to S11 shown in FIG. 11, are executed.

[0223] As described above, in this embodiment, the user terminal 20 issues an attestation nonce generated from an attestation secret shared with the certification authority 30. This eliminates the process of sending the attestation nonce from the certification authority 30 to the user terminal 20, making it possible to reduce the amount of communication between the user terminal 20 and the certification authority 30, compared to the first embodiment described above.

[0224] In this embodiment, the differences from the first embodiment have been mainly described, but this embodiment may be configured in combination with the second embodiment.

[0225] (Fourth embodiment) Next, a fourth 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. Note that the system configuration of the communication system according to this embodiment is the same as that in FIG. 1, so detailed descriptions thereof will be omitted and the description will be made using FIG. 1.

[0226] In the first embodiment described above, it is assumed that the owner of the edge device 10 performs initial settings by directly communicating with the edge device 10 using the user terminal 20. However, in an environment where a large number of edge devices 10 are installed, it may be impractical for the owner of the edge device 10 to perform initial settings for all of the edge devices 10. The same applies to cases where specialized knowledge or a predetermined qualification is required to install the edge device 10. In such cases, the owner of the edge device 10 may consider entrusting the installation of the edge device 10 to another person (having the other person perform the installation on his / her behalf). However, when the installation of the edge device 10 is entrusted to another person, it is preferable that the other person perform the initial settings.

[0227] Therefore, in this embodiment, a configuration will be described in which a third party (hereinafter referred to as an agent) who has been entrusted with the installation of the edge device 10 by the owner of the edge device 10 performs initial settings using a user terminal 20, as described above.

[0228] Fig. 31 shows an example of the functional configuration of the certificate authority 30 in this embodiment. In Fig. 31, the same parts as those in Fig. 4 are given the same reference numerals, and detailed description thereof will be omitted.

[0229] As shown in FIG. 31, the certificate authority 30 further includes an agent information management unit 30l, as compared with the first embodiment described above.

[0230] The agent information management unit 30l manages agent information indicating the correspondence between the owner of the edge device 10 (that is, the entrustor) and the agent.

[0231] 32 shows an example of the agent information. As shown in FIG. 32, the agent information includes an entrustor ID (user ID) for identifying an entrustor (owner of the edge device 10) who entrusted the installation of the edge device 10, an agent ID (user ID) for identifying an agent who has been entrusted with the installation of the edge device 10, a certificate issuable device indicating an edge device 10 owned by the entrustor whose installation has been entrusted to the agent (i.e., an edge device 10 for which the agent can issue a certificate), and an expiration date of the agent information (entry), all of which are associated with each other. Note that the expired agent information may be discarded at a predetermined time or may be updated to agent information including a new expiration date.

[0232] An example of a processing procedure of the communication system 1 according to this embodiment will be described below. For convenience, the description will be made with reference to FIG.

[0233] First, the processes of steps S1 to S7 shown in Fig. 11 described above are executed. In step S6, a user authentication process is executed for the user who uses the user terminal 20. In this embodiment, it is assumed that the user who uses the user terminal 20 is a proxy who installs and initially configures the edge device 10, designated by the entrustor, but the user may also be the entrustor (the owner of the edge device 10). Hereinafter, a user who is authenticated by executing the user authentication process is referred to as an authenticated user.

[0234] When the process of step S7 is executed, the first verification unit 30e included in the certificate authority 30 acquires the certificate signing request transferred from the user terminal 20 in step S7 via the communication unit 30a.

[0235] Here, if the certificate signing request acquired by the first verification unit 30e includes a user ID, the first verification unit 30e refers to the agent information managed by the agent information management unit 30l to confirm whether the user identified by the user ID (i.e., the authenticated user) is a proxy. In this case, if the user ID for identifying the authenticated user is included in the agent information as a proxy ID, it can be confirmed that the authenticated user is a proxy.

[0236] If the authenticated user is an agent, the first verification unit 30e refers to the certificate issuing device associated with the agent ID for identifying the agent, and verifies whether the installation and initial configuration of the edge device 10 identified by the device information included in the certificate signing request has been entrusted to the agent (i.e., whether the agent has legitimate authority to issue a public key certificate for the edge device 10).

[0237] To explain this in more detail using the agent information shown in Figure 32, when a user with a user ID of "yyyy" forwards a certificate signing request to the certification authority 30 (i.e., the certificate signing request includes the user ID "yyyy"), the user identified by the user ID "yyyy" is an agent, and if the serial number "C1" or "C2" associated with the user ID "yyyy" matches the serial number in the device information included in the certificate signing request, it is confirmed that the agent has legitimate authority to issue a public key certificate for the edge device 10, and the verification is successful. In other words, when the authenticated user is a user (agent) with a user ID of "yyyy", public key certificates can be issued only to edge devices 10 with serial numbers "C1" and "C2" (i.e., the edge devices 10 to which public key certificates can be issued are limited).

[0238] On the other hand, if a user with the user ID "xxxx" transfers a certificate signing request to the certificate authority 30, the verification will be successful regardless of the serial number of the device information included in the certificate signing request.

[0239] If the above verification is not successful (fails), the first verification unit 30e (certification authority 30) notifies the user terminal 20 of an error.

[0240] If the verification of whether the agent has legitimate authority to issue a public key certificate for the edge device 10 is successful, the first verification unit 30e acquires the entrustor ID associated with the agent ID for identifying the agent. The first verification unit 30e uses the acquired entrustor ID to perform the first verification process described in the first embodiment.

[0241] In addition, the entrustor ID acquired by the first verification unit 30e is passed to the second verification unit 30g, and the second verification unit 30g uses the entrustor ID to perform the second verification process described in the first embodiment above.

[0242] In other words, in this embodiment, if the authenticated user (the user using the user terminal 20) is an agent, the certification authority 30 can perform the verification process as if the certificate signing request had been transferred by the trustor who entrusted the agent with the installation and initial setup of the edge device 10.

[0243] If the authenticated user is not a proxy, the first and second verification processes may be executed using a user ID for identifying the authenticated user, as in the first embodiment described above.

[0244] Hereinafter, a specific usage mode of the communication system 1 according to this embodiment will be described with reference to FIG.

[0245] In the example shown in FIG. 33, it is assumed that an environmental sensor device installed (deployed) in, for example, a forest or a river operates as an edge device 10, and that the environmental sensor device connects to a disaster prevention service built on a cloud service (communicates with a server device 40 that provides the disaster prevention service). The environmental sensor device is a sensor device that measures sensor data related to, for example, ground movement in a forest, the amount of moisture in the soil in the forest, and the water level in a river, and is manufactured, sold, and delivered by a device manufacturer. The disaster prevention service corresponds to a service that predicts wind and water damage such as landslides and river flooding, and is provided by a disaster prevention service provider designated by, for example, the national or local government.

[0246] Environmental sensor devices connect to networks such as the Internet using wide-area wireless communication technologies such as mobile phone networks, and upload (transmit) sensor data measured by the environmental sensor devices to disaster prevention services. The disaster prevention services constantly analyze the uploaded sensor data to predict the occurrence (risk) of disasters, and issue alerts if the occurrence of such disasters is predicted. When an alert is issued by the disaster prevention service in this way, national or local governments can take action such as urging residents in areas where a disaster is predicted to occur to evacuate.

[0247] In order to provide disaster prevention services, the disaster prevention service provider purchases environmental sensor devices from device manufacturers. The device manufacturers manufacture the environmental sensor devices and, when delivering the manufactured environmental sensor devices to the disaster prevention service provider, register verification information including the device serial number in the certification authority 30 (verification information management unit 30d).

[0248] In this case, the disaster prevention service provider needs to install the environmental sensor devices delivered by the device manufacturer in designated forests or rivers, but if there are a large number of environmental sensor devices and the installation work of the environmental sensor devices involves danger, it will be difficult for the disaster prevention service provider to carry out the installation work.

[0249] Therefore, the disaster prevention service provider will entrust the installation of the environmental sensor device to an installation worker with appropriate experience and qualifications. In this case, the disaster prevention service provider will register agent information, including a client ID for identifying the disaster prevention service provider and an agent ID for identifying the installation worker, in the certification authority 30 (agent information management unit 301).

[0250] When the registration of the agent information is completed as described above, the installation worker installs the environmental sensor device at a predetermined location, turns on the power of the environmental sensor device, and performs initial configuration. Specifically, the user terminal 20 used by the installation worker transmits an initial configuration start message to the environmental sensor device to obtain a certificate signing request from the environmental sensor device, and transfers the obtained certificate signing request to the certification authority 30.

[0251] In this case, the certification authority 30 executes a user authentication process for the installation worker who is using (operating) the user terminal 20 (i.e., authenticates the installation worker), and also references the agent information described above to confirm that the installation worker is an agent who has been entrusted by the disaster prevention service provider with the installation work (and initial setup) of the environmental sensor device. Once it is confirmed that the installation worker is an agent, the certification authority 30 executes the first and second verification processes using the entrustor ID for identifying the disaster prevention service provider as described above, and issues a public key certificate if the verification is successful.

[0252] The public key certificate issued in this way is registered in the environmental sensor device via the user terminal 20. The environmental sensor device connects to the disaster prevention service using the public key certificate registered in the environmental sensor device. This makes it possible to provide disaster prevention services based on sensor data uploaded from the environmental sensor device.

[0253] As described above, in this embodiment, even if an agent who has been entrusted by a client with the installation and initial setup of the edge device 10 uses the user terminal 20 (i.e., the agent installs and initially sets up the edge device 10 on behalf of the owner of the edge device 10), it is possible to easily issue a public key certificate for the edge device 10 in its factory-shipped state (a public key certificate used by the edge device 10 for communication).

[0254] In this embodiment, the differences from the first embodiment have been mainly described, but this embodiment may be configured in combination with the second or third embodiment.

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

[0256] 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]

[0257] 1...communication system, 10...edge device (communication device), 10a...first communication unit, 10b...second communication unit, 10c...request generation unit, 10d...device information management unit, 10e...first key management unit, 10f...registration unit, 10g...second key management unit, 10h...signature generation unit, 10i...application processing unit, 20...user terminal (terminal device), 20a...first communication unit, 20b...second communication unit, 20c...user information management unit, 20d...server information management unit, 20e...attestation nonce acquisition unit, 20f...initial setting processing unit, 20g...certificate acquisition unit, 20h...third communication unit, 20i...verification request unit, 20j...attestation secret management unit, 20k...attestation nonce issuing unit, 30...certification authority, 30a... Communication unit, 30b...attestation nonce issuing unit, 30c...attestation nonce management unit, 30d...verification information management unit, 30e...first verification unit, 30f...attestation key management unit, 30g...second verification unit, 30h...certificate issuing unit, 30i...issuance history management unit, 30j...third verification unit, 30k...attestation secret management unit, 30l...agent information management unit, 40...server device, 51, 52...network, 60...server device, 60a...communication unit, 60b...attestation nonce issuing unit, 60c...attestation nonce management unit, 60d...attestation key management unit, 60e...verification unit, 60f...verification server key management unit, 101...processor, 102...non-volatile memory, 103...main memory, 104...communication I / F.

Claims

1. A communication system including a communication device, a terminal device, and a certificate authority, the communications device transmits to the terminal device a certificate signing request for issuance of a certificate to be used by the communications device to communicate with a server device, the certificate signing request including device information about the communications device, an attestation nonce, and a digital signature generated for the device information and the attestation nonce using a private key for attestation that is stored in advance in the communications device; The terminal device transmits the certificate signing request transmitted from the communication device to the certificate authority; a public attestation key that is a pair of the private attestation key is used to verify the digital signature included in the certificate signing request; The certificate authority issues the certificate according to the verification result. Communication system.

2. 2. The communication system of claim 1, further comprising verifying the device information included in the certificate signing request sent from the terminal device by comparing the device information included in the certificate signing request sent from the terminal device with an expected value of the device information associated with the public key for attestation.

3. The communication system according to claim 2 , further comprising verifying whether an attestation nonce included in the certificate signing request transmitted from the terminal device is within its expiration date.

4. 4. The communication system according to claim 1, wherein the verification is performed by the certificate authority.

5. the certificate authority issues the attestation nonce in response to a request from the terminal device; When the communication device and the terminal device are communicably connected, the terminal device transmits to the communication device an initial setting start message including an attestation nonce issued by the certificate authority, and instructs the communication device to generate the certificate signing request.

5. The communication system according to claim 4.

6. A verification server device that performs the verification is further provided, the verification server device transmits the verification result to the terminal device; The terminal device verifies the verification result transmitted from the verification server device and transmits the verification result to the certification authority. A communication system according to any one of claims 1 to 3.

7. the validation server device issues the attestation nonce in response to a request from the terminal device; When the communication device and the terminal device are communicably connected, the terminal device transmits to the communication device an initial setting start message including an attestation nonce issued by the validation server device, and instructs the communication device to generate the certificate signing request.

7. The communication system according to claim 6.

8. The terminal device issues the attestation nonce generated from an attestation secret shared with the certification authority, and when the communication device and the terminal device are connected so as to be able to communicate, sends an initial setting start message to the communication device including the issued attestation nonce, and instructs the communication device to generate the certificate signing request.A communication system as described in any one of claims 1 to 3.

9. 9. The communication system of claim 8, wherein the certificate authority verifies the attestation nonce included in the certificate signing request sent from the terminal device by comparing the attestation nonce included in the certificate signing request sent from the terminal device with an attestation nonce generated from an attestation secret shared with the terminal device.

10. A communication system described in any one of claims 1 to 3, wherein, if the user using the terminal device that sent the certificate signing request is an initial setup agent for the communication device designated by the owner of the communication device, the certification authority verifies whether the communication device identified by the device information included in the certificate signing request is a device owned by the owner and whether the agent is a device for which a certificate can be issued.

11. A terminal device communicably connected to a communication device and a certificate authority, a receiving means for receiving, from the communication device, a certificate signing request for issuing a certificate used for the communication device to communicate with a server device; a transmitting means for transmitting the received certificate signing request to the certificate authority; Equipped with the certificate signing request includes device information about the communication device, an attestation nonce, and a digital signature generated for the device information and the attestation nonce using a private key for attestation stored in advance in the communication device; a public attestation key that is a pair of the private attestation key is used to verify the digital signature included in the certificate signing request; The certificate is issued by the certification authority according to the verification result. Terminal device.

12. A communication device communicatively connected to a terminal device, a sending means for sending to the terminal device a certificate signing request for issuing a certificate used to communicate with a server device, the certificate signing request including device information about the communication device, an attestation nonce, and a digital signature generated for the device information and the attestation nonce using a private key for attestation stored in advance in the communication device; a public attestation key that is a pair of the private attestation key is used to verify the digital signature included in the certificate signing request; The certificate is issued by a certification authority according to the verification result. Communication devices.

13. In a certification authority communicably connected to a terminal device, a receiving means for receiving from the terminal device a certificate signing request for issuance of a certificate used by the communication device to communicate with a server device, the certificate signing request including device information about the communication device, an attestation nonce, and a digital signature generated for the device information and the attestation nonce using a private key for attestation stored in advance in the communication device; a verification means for verifying the digital signature included in the received certificate signing request by using an attestation public key that is a pair with the attestation private key; issuing means for issuing the certificate in accordance with the verification result; 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: a step of transmitting a certificate signing request from the communication device to the terminal device, the certificate signing request being a request for issuance of a certificate used by the communication device to communicate with a server device, the certificate signing request including device information about the communication device, an attestation nonce, and a digital signature generated for the device information and the attestation nonce using a private key for attestation stored in advance in the communication device; sending a certificate signing request sent from the communication device to the certificate authority from the terminal device; a step of verifying a digital signature included in the certificate signing request using an attestation public key that is a pair with the attestation private key; the certificate authority issuing the certificate in response to the verification result; A method comprising:

15. 1. A method executed by a terminal device communicatively coupled to a communication device and a certificate authority, comprising: receiving a certificate signing request from the communication device requesting issuance of a certificate used by the communication device to communicate with a server device; sending the received certificate signing request to the certificate authority; Equipped with the certificate signing request includes device information about the communication device, an attestation nonce, and a digital signature generated using an attestation private key assigned to the communication device in advance for the device information and the attestation nonce; a public attestation key that is a pair of the private attestation key is used to verify the digital signature included in the certificate signing request; The certificate is issued by the certification authority according to the verification result. method.

16. 1. A method executed by a communication device communicatively connected to a terminal device, comprising: transmitting to the terminal device a certificate signing request for issuing a certificate used to communicate with a server device, the certificate signing request including device information about the communication device, an attestation nonce, and a digital signature generated for the device information and the attestation nonce using a private key for attestation stored in advance in the communication device; a public attestation key that is a pair of the private attestation key is used to verify the digital signature included in the certificate signing request; The certificate is issued by a certification authority according to the verification result. method.

17. A method performed by a certification authority communicatively connected to a terminal device, comprising: receiving, from the terminal device, a certificate signing request for issuance of a certificate to be used by the communication device to communicate with a server device, the certificate signing request including device information about the communication device, an attestation nonce, and a digital signature generated for the device information and the attestation nonce using a private key for attestation stored in advance in the communication device; verifying the digital signature included in the received certificate signing request using an attestation public key that is a pair with the attestation private key; issuing the certificate in response to the verification result; A method comprising:

Images