Communication system, terminal device, communication device, certificate authority, and method

Abstract

To provide a communication system, a terminal device, a communication device, a certificate authority, and a method capable of easily executing issuance of a certificate used for communication.SOLUTION: A communication system sends a device authorization request and device information from a communication device to a certificate authority, sends access information, a user code, and a device code from the certificate authority to the communication device, and sends the access information and the user code from the communication device to a terminal device. The communication system sends the user code from the terminal device to the certificate authority, sends the device information from the certificate authority to the terminal device, requests issuance of an access token from the terminal device to the certificate authority, and issues the access token in the certificate authority. The communication system sends the access token from the certificate authority to the communication device, sends a certificate signing request and the access token from the communication device to the certificate authority, and issues a certificate in the certificate authority.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 an application server device that provides IoT services 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 certification authority is provided. The communication system includes first transmission means for transmitting a device authorization request requesting authorization of the communication device and device information related to the communication device from the communication device to the certification authority, second transmission means for transmitting, in response to the device authorization request, access information for accessing the certification authority and a user code and device code managed in association with the device information from the certification authority to the communication device, third transmission means for transmitting the access information and the user code from the communication device to the terminal device, fourth transmission means for transmitting the user code from the terminal device to the certification authority by the terminal device accessing the certification authority based on the access information, fifth transmission means for transmitting the device information managed in association with the user code from the certification authority to the terminal device, and fifth transmission means for transmitting the user code from the terminal device to the certification authority based on the device information. a first issuing means for issuing, based on a request from the terminal device, an access token that is managed in the certification authority in association with the user code; a second requesting means for requesting acquisition of an access token by transmitting the device code from the communications device to the certification authority; a sixth transmitting means for transmitting, based on a request from the communications device, the access token that is managed in association with the device code from the certification authority to the communications device; a seventh transmitting means for transmitting, from the communications device to the certification authority, a certificate signing request requesting issuance of a certificate used by the communications device to communicate with an application server device, and the access token; and a second issuing means for issuing the certificate in the certification authority based on the certificate signing request and the access token. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a diagram showing an example of a system configuration of a communication system according to a first embodiment. [Figure 2] FIG. 2 is a diagram showing an example of the functional configuration of an edge device. [Figure 3] FIG. 10 is a diagram showing an example of device information. [Figure 4] FIG. 2 is a diagram showing an example of the functional configuration of a user terminal. [Figure 5] FIG. 4 is a diagram showing an example of user information. [Figure 6] FIG. 10 is a diagram showing an example of server information. [Figure 7] FIG. 2 is a diagram showing an example of the functional configuration of a certificate authority. [Figure 8] FIG. 2 is a diagram illustrating an example of a hardware configuration of an edge device. [Figure 9] 1 is a sequence chart showing an example of a processing procedure of a communication system. [Figure 10] FIG. 10 is a diagram showing an example of device authorization session information. [Figure 11] FIG. 10 is a diagram showing an example of verification information. [Figure 12] FIG. 10 is a diagram showing another example of verification information. [Figure 13] FIG. 10 is a diagram showing an example of a device confirmation screen. [Figure 14] FIG. 10 is a diagram showing an example of issuance history information. [Figure 15] FIG. 1 is a diagram for explaining an example of a specific usage mode of a communication system. [Figure 16] FIG. 10 is a diagram showing an example of the system configuration of a communication system according to a second embodiment. [Figure 17] FIG. 2 is a diagram showing an example of the functional configuration of an edge device. [Figure 18] FIG. 2 is a diagram showing an example of a functional configuration of a validation server device. [Figure 19] FIG. 2 is a diagram showing an example of the functional configuration of a certificate authority. [Figure 20] 1 is a sequence chart showing an example of a processing procedure of a communication system. DETAILED DESCRIPTION OF THE INVENTION

[0008] Hereinafter, each embodiment will be described with reference to the drawings. (First embodiment) First, a first embodiment will be described. Fig. 1 shows an example of the system configuration of a communication system according to this embodiment. As shown in Fig. 1, the communication system 1 includes an edge device 10, a user terminal (client terminal) 20, a certificate authority, and an application 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 is configured to communicate with the application server device 40, and thereby operates as part of an application system for providing various IoT services. However, it is assumed that the edge device 10 in this embodiment is in a factory default state and therefore has not been configured to communicate with the application 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 application server device 40. Specifically, when a public key cryptosystem is adopted to ensure security in the communication between the edge device 10 and the application 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 application server device 40 using the public key certificate.

[0014] The application server device 40 operates to provide various IoT services by communicating with the edge device 10. Specifically, the application server device 40 may operate to register sensor data collected by the edge device 10 in the application 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 application 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 application server device 40 may be executed on a server computer managed on-premise within a base such as a business office, or may be executed on a virtual machine implemented on the server computer. The processing of the application server device 40 may also be executed within a communication network provided by a cloud service provider or on a cloud platform on the Internet.

[0016] The communication method applied to the communication between the edge device 10 and the user terminal 20 shown in FIG. 1 may be a wireless communication method or a wired communication method.

[0017] Possible wireless communication methods include, but are not limited to, Bluetooth (registered trademark), Wi-Fi (registered trademark), Zigbee (registered trademark), or infrared communication.

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

[0019] It is sufficient that a mechanism for transmitting information between the edge device 10 and the user terminal 20 is established. For example, if the edge device 10 is configured to have a display, the transmission of information may be realized by reading a two-dimensional code such as a QR code (registered trademark) displayed on the display using a camera mounted on the user terminal 20, such as a smartphone. Furthermore, the transmission of information from the edge device 10 to the user terminal 20 may be realized via a person (user). For example, a character string displayed on a display mounted on the edge device 10 may be read by a person, and the person may input the character string into the user terminal 20.

[0020] In this embodiment, the communication between the edge device 10 and the user terminal 20 includes the transmission of information realized as described above. For this reason, in Fig. 1, the edge device 10 and the user terminal 20 are connected by a dashed line, which is distinguished from other connection lines.

[0021] 1 are communicably connected via a network 51. The edge device 10 and the certificate authority 30 shown in FIG. 1 are communicably connected via a network 52. The edge device 10 and the application server device 40 shown in FIG. 1 are communicably connected via a network 53.

[0022] 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 networks 52 and 53 may be the wireless communication method described above or may be a wired communication method.

[0023] 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 networks 52 and 53. The above-described networks 51 to 53 may be different networks or the same network.

[0024] 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 third communication unit 10c, a device information management unit 10d, a first request generation unit 10e, a second request generation unit 10f, a key management unit 10g, a registration unit 10h, and an application processing unit 10i.

[0025] 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 certificate authority 30 via a network 52. The third communication unit 10c communicates with the application server device 40 via a network 53.

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

[0027] The device information management unit 10d manages information related to the edge device 10 (hereinafter referred to as device information). Fig. 3 shows an example of the device information. In the example shown in Fig. 3, the device information includes, for example, the manufacturer, model, serial number, installation location, manager, and current time of the edge device 10.

[0028] 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 administrator are, for example, information provided by the user terminal 20 via the certificate authority 30. The current time is, for example, initialized by information provided by the certificate authority 30, and is automatically updated as time passes.

[0029] In FIG. 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.).

[0030] The first request generation unit 10e generates a device authorization request requesting the certification authority 30 to authorize the edge device 10. The device authorization request generated by the first request generation unit 10e is transmitted from the second communication unit 10b to the certification authority 30 together with the device information managed by the device information management unit 10d.

[0031] The first request generation unit 10e acquires, via the second communication unit 10b, the access information, user code, and device code transmitted from the certificate authority 30 in response to the device authorization request. The access information is information for accessing the certificate authority 30, and an example of the access information is a verification URL (Uniform Resource Locator) assigned to the certificate authority 30. The verification URL (access information) and user code acquired by the first request generation unit 10e are transmitted from the first communication unit 10a to the user terminal 20.

[0032] The second request generation unit 10f generates an access token acquisition request to request the certificate authority 30 to acquire an access token. The access token corresponds to, for example, authentication information issued by the certificate authority 30 to authenticate a device. The access token acquisition request generated by the second request generation unit 10f is transmitted from the second communication unit 10b to the certificate authority 30.

[0033] The second request generation unit 10f acquires the access token transmitted from the certificate authority 30 in response to the access token acquisition request via the second communication unit 10b. The second request generation unit 10f generates a certificate signing request for requesting the issuance of a public key certificate. The certificate signing request generated by the second request generation unit 10f is transmitted to the certificate authority 30 from the second communication unit 10b together with the access token.

[0034] The key management unit 10g 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 second request generation unit 10f includes the public key of the edge device 10 managed by the key management unit 10g.

[0035] Here, the key pair of the edge device 10 may be generated in response to an instruction from the second request generation unit 10f when the second request generation unit 10f generates a certificate signing request, for example. Alternatively, the key pair may be generated when the power of the edge device 10 is turned on in a factory-shipped state. The key pair of the edge device 10 may also be stored in advance inside the edge device 10. Furthermore, if the key management unit 10g 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.

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

[0037] The registration unit 10h executes a process of registering the public key certificate issued by the certificate authority 30 in response to the above-mentioned certificate signing request in the edge device 10 (key management unit 10g).

[0038] 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 between itself and the application server apparatus 40 (hereinafter referred to as device authentication processing).

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

[0040] 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 verification URL reading unit 20c, a user information management unit 20d, a server information management unit 20e, and a request generation unit 20f.

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

[0042] 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 execute communication and the communication method used by the second communication unit 20b to execute communication may be different or the same.

[0043] The verification URL reading unit 20c obtains the verification URL and the user code transmitted from the edge device 10 via the first communication unit 20a. The verification URL reading unit 20c accesses the certification authority 30 by reading the obtained verification URL. As a result, the user code obtained by the verification URL reading unit 20c is transmitted to the certification authority 30 from the second communication unit 20b.

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

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

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

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

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

[0049] 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 application server device 40, a URL for accessing the application server device 40, and specifications of the API (Application Programming Interface) implemented in the application server device 40 (server API specifications).

[0050] 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 application server device 40, etc.).

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

[0052] The request generation unit 20f generates an access token issuance request that requests the issuance of an access token from the authentication authority 30. The access token issuance request generated by the request generation unit 20f is transmitted from the second communication unit 20b to the authentication authority 30 together with user-specified information.

[0053] In addition, the user-specified information corresponds to, for example, various additional information input by the user into the user terminal 20, and the user-specified information may include part of the user information managed by the above-mentioned user information management unit 20d and part of the server information managed by the server information management unit 20e.

[0054] Fig. 7 shows an example of the functional configuration of the certificate authority 30 shown in Fig. 1. As shown in Fig. 7, the certificate authority 30 includes a first communication unit 30a, a second communication unit 30b, a device authorization request processing unit 30c, a device authorization session management unit 30d, a first verification unit 30f, an access token issuing unit 30g, a second verification unit 30h, a certificate issuing unit 30i, and an issuance history management unit 30j.

[0055] The first communication unit 30a communicates with the user terminal 20 via the network 51. The second communication unit 30b communicates with the edge device 10 via the network 52.

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

[0057] The device authorization request processing unit 30c acquires, via the second communication unit 30b, the device authorization request and device information transmitted from the edge device 10. The device authorization request processing unit 30c processes the device authorization request and issues a user code and a device code for the device information.

[0058] The device authorization session management unit 30d manages the user code and device code issued by the device authorization request processing unit 30c in association with the above-mentioned device information. The information managed by the device authorization session management unit 30d is referred to as device authorization session information. The device authorization session information includes various information related to processes from obtaining (receiving) a device authorization request from the edge device 10 to issuing a public key certificate.

[0059] The verification information management unit 30e manages information (hereinafter referred to as verification information) prepared in advance for verifying a user code. 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 (user code verification unit) 30f acquires the user code transmitted from the user terminal 20 via the first communication unit 30a. The first verification unit 30f verifies the user code based on the verification information managed by the verification information management unit 30e. In this case, the first verification unit 30f verifies whether the user using the user terminal 20 has the authority to issue a certificate for the device associated with (linked to) the user code. If the verification of the user code is successful, the first verification unit 30f acquires device information managed by the device authorization session management unit 30d in association with the user code. The device information acquired by the first verification unit 30f is transmitted from the first communication unit 30a to the user terminal 20.

[0061] The access token issuing unit 30g acquires an access token issuance request transmitted from the user terminal 20 via the first communication unit 30a. The access token issuing unit 30g issues an access token in response to the acquired access token issuance request. The access token issued by the access token issuing unit 30g is managed by the device authorization session management unit 30d. The access token is transmitted from the second communication unit 30b to the edge device 10 in response to an access token acquisition request transmitted from the edge device 10.

[0062] The second verification unit (request verification unit) 30h acquires, via the second communication unit 30b, the certificate signing request transmitted from the edge device 10. The second verification unit 30h verifies the certificate signing request by using the above-mentioned device authorization session information (information managed by the device authorization session management unit 30d).

[0063] If the certificate signing request is successfully verified, the certificate issuing unit 30i issues a public key certificate in response to the certificate signing request. The public key certificate issued by the certificate issuing unit 30i is transmitted from the second communication unit 30b to the edge device 10.

[0064] The issuance history management unit 30j manages information related to public key certificates previously issued by the certificate issuance unit 30i (hereinafter referred to as issuance history information). 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 30j. The issuance history information managed by the issuance history management unit 30j may be used, for example, to determine whether or not to issue an access token.

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

[0066] 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, the certificate authority 30, and the application server device 40.

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

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

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

[0070] Furthermore, some or all of the units 30a to 30j 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.

[0071] In this embodiment, the user terminal 20 further includes an input device and a display device for realizing the above-described user interface. The edge device 10 may further include, for example, a display device, and the user terminal 20 may further include, for example, a camera.

[0072] 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. 9. Here, the processing related to the initial setting of the edge device 10 that communicates with the application server apparatus 40 (initial setting sequence) will be mainly described.

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

[0074] First, when the power of the edge device 10 in a factory-shipped state is turned on, the first request generator 10e included in the edge device 10 generates a device authorization request. The device authorization request is, for example, a Device Authorization Request conforming to RFC 8628. The device authorization request may be generated, for example, when a user presses (operates) a predetermined button provided on the edge device 10.

[0075] The first request generating unit 10e transmits the generated device authorization request and device information (e.g., the manufacturer, model, and serial number of the edge device 10) managed by the device information managing unit 10d to the certificate authority 30 via the second communication unit 10b (step S1). Note that the information (e.g., URL) of the certificate authority 30 to which the device authorization request and device information are to be transmitted may be written in advance when the edge device 10 is manufactured, or may be input by the user.

[0076] Upon receiving the device authorization request and device information transmitted from the edge device 10 in step S1, the device authorization request processing unit 30c included in the certificate authority 30 newly issues a verification URL, a user code, and a device code. The verification URL is a URL indicating a predetermined communication endpoint of the certificate authority 30, and is used by a user to access the certificate authority 30 using a user terminal 20, as will be described later. The user code and the device code are random character strings. Note that the user code may be manually entered by a user, so it is preferable that the user code be a character string that is relatively easy to enter (e.g., a random six-digit number). Furthermore, it is preferable that the device code be a sufficiently long character string (e.g., a random 50-digit alphanumeric string) to resist brute force attacks aimed at decrypting encryption or fraudulently obtaining authentication information.

[0077] Here, the device authorization request processing unit 30c generates device authorization session information (that is, a new entry of the information managed by the device authorization session management unit 30d).

[0078] Fig. 10 shows an example of device authorization session information. As shown in Fig. 10, the device authorization session information includes a user code, a device code, device information, user-specified information, an access token, and an expiration date, all of which are associated with identification information (session ID) assigned to the device authorization session information. The expiration date is set when the device authorization session information is generated, and expired device authorization session information is discarded at a predetermined timing.

[0079] Note that, although FIG. 10 shows device authorization session information with a session ID of "1" and device authorization session information with a session ID of "2", the device authorization session information generated as a new entry by the device authorization request processing unit 30c has blank user-specified information and access token fields, just like the device authorization session information with a session ID of "1".

[0080] As described above, the device authorization session information generated by the device authorization request processing unit 30c is managed by the device authorization session management unit 30d.

[0081] Next, the device authorization request processing unit 30c transmits the verification URL, user code, and device code issued as described above to the edge device 10 via the second communication unit 30b (step S2).

[0082] Upon receiving the verification URL, user code, and device code transmitted from the certificate authority 30 in step S2, the first request generation unit 10e included in the edge device 10 transmits the verification URL and user code to the user terminal 20 via the first communication unit 10a (step S3). The device code is passed from the first request generation unit 10e to the second request generation unit 10f.

[0083] Here, in the description, the verification URL and the user code are transmitted in step S3. However, in the present embodiment, the verification URL and the user code may be transmitted from the edge device 10 to the user terminal 20. Specifically, the verification URL and the user code may be transmitted via a wireless communication method (Bluetooth, Wi-Fi, Zigbee, infrared communication, etc.) or a wired communication method (Ethernet, UART, CAN, etc.). Alternatively, for example, a QR code in which the verification URL and the user code are encoded may be displayed on a display (display device) mounted on the edge device 10, and the QR code may be read by a camera mounted on the user terminal 20, thereby transmitting the verification URL and the user code from the edge device 10 to the user terminal 20. Furthermore, the QR code in which the verification URL is encoded and the user code may be displayed on a display mounted on the edge device 10, and the QR code may be read by a camera mounted on the user terminal 20, and the user who visually views the user code may directly input the user code into the user terminal 20.

[0084] When the process of step S3 is executed, the verification URL reading unit 20c included in the user terminal 20 accesses the certificate authority 30 based on the verification URL received (transmitted) from the edge device 10.

[0085] Next, user authentication processing is executed between the user terminal 20 and the certification authority 30 (step S4). The user authentication processing corresponds to a process in which, for example, a user ID, a password, etc. assigned to a user who uses the user terminal 20 are sent from the user terminal 20 to the certification authority 30, and the certification authority 30 confirms whether the user is a legitimate user who can request the issuance of a public key certificate. Here, the user authentication processing has been described as using a user ID and a password, but the user authentication processing may be any processing for authenticating a user (or the user terminal 20), and other information may be used.

[0086] When the user is authenticated by executing the processing of step S4 (i.e., when user authentication is completed), the verification URL reading unit 20c transmits the user code sent (transmitted) from the edge device 10 as described above to the authentication authority 30 via the second communication unit 20b (step S5).

[0087] When the first verification unit 30f included in the certificate authority 30 receives the user code transmitted from the user terminal 20 in step S5, it verifies whether the user can issue a certificate for the device associated with the user code (i.e., verifies the user code). In this case, the first verification unit 30f searches for device authorization session information (an entry corresponding to the user code) including the received user code, and acquires (reads) the searched device authorization session information from the device authorization session management unit 30d. Next, the first verification unit 30f compares the device authorization session information acquired from the device authorization session management unit 30d with the verification information managed by the verification information management unit 30e to verify the user code.

[0088] An example of user code verification performed by the first verification unit 30f will be described below. Fig. 11 shows an example of verification information. In the example shown in Fig. 11, the verification information includes a user ID for identifying a user, a serial number of the edge device 10 owned by the user, and an expiration date of the verification information, all associated with each other. Verification information (entry) that has expired may be discarded at a predetermined timing, or may be updated with an entry that includes a new expiration date.

[0089] The user code verification is successful when there is verification information that associates the user ID used in the above-mentioned user authentication with the serial number of the device information included in the device authorization session information acquired from the device authorization session management unit 30d (i.e., both the user ID and the serial number match the verification information).On the other hand, the user code verification fails when there is no verification information that associates the above-mentioned user ID with the serial number (i.e., at least one of the user ID and the serial number does not match the verification information).

[0090] 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 also be information including a user ID and a manufacturer of the edge device 10 in association with each other, for example, as shown in Fig. 12. Even in the case of the verification information shown in Fig. 12, the user code can be verified in the same way as in the case of the verification information shown in Fig. 11 described above.

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

[0092] If the verification of the above-mentioned user code is successful, the first verification unit 30f transmits the device information contained in the device authorization session information acquired from the above-mentioned device authorization session management unit 30d to the user terminal 20 via the first communication unit 30a (step S6).

[0093] If the verification of the user code fails, the first verification unit 30f returns a message to the user terminal 20 via the first communication unit 30a indicating that the verification has failed (that is, an error).

[0094] When the process of step S6 is executed, for example, the user terminal 20 displays the device information transmitted from the certificate authority 30 in step S6 on a screen such as that shown in Fig. 13 (hereinafter referred to as a device confirmation screen) and presents it to the user. This allows the user to confirm whether the device information transmitted from the certificate authority 30 (i.e., the device information received by the user terminal 20) indicates the edge device 10 intended by the user. Specifically, the user confirms whether the device information displayed (presented) on the device confirmation screen, for example, matches the device information (such as a serial number) printed on the housing of the edge device 10.

[0095] Furthermore, as shown in FIG. 13, the device confirmation screen may be configured to allow the user to confirm or input additional information to be included in the public key certificate. The additional information confirmed or input on the device confirmation screen corresponds to the user-specified information described above. In the example shown in FIG. 13, the user-specified information includes the user name, user affiliation, user terminal ID, and installation location. The user name, user affiliation, and user terminal ID are information acquired from user information managed by the user information management unit 20d, and cannot be edited (changed) on the device confirmation screen. Meanwhile, the installation location can be input by the user as information describing the location where the edge device 10 is installed. The installation location (information about the installation location) may be automatically input (presented) from, for example, a Global Positioning System (GPS), information about surrounding wireless LAN access points, or other wireless beacons.

[0096] 13, the user-specified information may include information acquired from the server information managed by the server information management unit 20e. Furthermore, information (key-value pairs) arbitrarily input by the user may be added to the user-specified information.

[0097] 13, the device confirmation screen has a "Request issuance" button and a "Cancel" button. When the "Request issuance" button is specified (pressed) by the user on the device confirmation screen, the request generation unit 20f generates an access token issuance request and transmits the generated access token issuance request together with the above-mentioned user-specified information to the authentication authority 30 via the second communication unit 20b (step S7).

[0098] On the other hand, when the user specifies (presses) the "Cancel" button on the device confirmation screen, the issuance of the public key certificate for, for example, the edge device 10 is canceled, and the processing shown in FIG. 9 ends.

[0099] The access token issuing unit 30g included in the authentication authority 30 issues a new access token upon receiving the access token issuance request and the user-specified information transmitted from the user terminal 20 in step S7. The access token issued by the access token issuing unit 30g is, for example, a random character string.

[0100] The access token issued by the access token issuing unit 30g and the user-specified information received by the access token issuing unit 30g are passed to the device authorization session management unit 30d. For example, the above-mentioned access token issuance request includes a user code, and the device authorization session management unit 30d adds the access token and user-specified information passed from the access token issuing unit 30g to the device authorization session information including the user code. As a result, after the access token is issued, the device authorization session information has the access token and user-specified information added (filled in), like the device authorization session information with the session ID "2" shown in FIG. 10.

[0101] Here, when the processing of step S3 described above is executed, the first request generation unit 10e included in the edge device 10 passes the device code to the second request generation unit 10f, and the second request generation unit 10f operates to transmit an access token acquisition request including the device code to the authentication authority 30 via the second communication unit 10b.

[0102] When the device authorization session management unit 30d included in the certificate authority 30 receives the access token acquisition request transmitted from the edge device 10 as described above, the device authorization session management unit 30d searches for device authorization session information (entry) including the device code included in the access token acquisition request. The device authorization session management unit 30d checks whether the searched device authorization session information includes an access token. When the processing of step S7 described above is not executed (i.e., when an access token has not been issued), the device authorization session information does not include an access token (i.e., the access token column is empty). Therefore, the device authorization session management unit 30d returns a message indicating that an access token has not been issued (i.e., a pending message) to the edge device 10 via the second communication unit 30b. When the second request generation unit 10f included in the edge device 10 receives such a pending message from the certificate authority 30, the second request generation unit 10f waits for a predetermined period of time and repeats the operation of transmitting an access token acquisition request again (i.e., executes polling processing).

[0103] On the other hand, assume that an access token acquisition request is transmitted from the edge device 10 to the authentication authority 30 after the processing of step S7 described above is executed (step S8). In this case, the device authorization session management unit 30d included in the authentication authority 30 receives the access token acquisition request transmitted from the edge device 10 and searches for device authorization session information including the device code included in the access token acquisition request. Because the processing of step S7 has already been executed, the device authorization session information thus searched for includes an access token. In this case, the device authorization session management unit 30d acquires the access token included in the searched device authorization session information and transmits the acquired access token to the edge device 10 via the second communication unit 30b (step S9).

[0104] Note that, although it has been described here that device authorization session information including the device code included in the access token acquisition request exists (managed by the device authorization session management unit 30d), if the device authorization session information does not exist, an error is returned from the certificate authority 30 to the edge device 10. When the second request generation unit 10f included in the edge device 10 receives the error from the certificate authority 30, it stops retransmitting the access token acquisition request, and the processing shown in Fig. 9 ends.

[0105] Upon receiving the access token transmitted from the certificate authority 30 in step S9, the second request generation unit 10f included in the edge device 10 generates a certificate signing request. The certificate signing request generated by the second request generation unit 10f is, for example, a Certificate Signing Request (CSR) conforming to PKCS#10 (RFC2986) of the Public-Key Cryptography Standards (PKCS).

[0106] The certificate signing request includes the public key of the edge device 10 managed by the key management unit 10g, but may also include, for example, device information managed by the device information management unit 10d (such as the manufacturer, model, and serial number of the edge device 10) and the date and time when the certificate signing request was generated.

[0107] The second request generating unit 10f transmits the generated certificate signing request and the above-mentioned access token to the certificate authority 30 via the second communication unit 10b (step S10).

[0108] Upon receiving the certificate signing request and the access token transmitted from the edge device 10 in step S10, the second verification unit 30h included in the certificate authority 30 verifies the certificate signing request and the access token.

[0109] The following describes the verification of the certificate signing request and the access token. First, the second verification unit 30h verifies whether the certificate signing request satisfies predetermined requirements. This verification is successful, for example, if the public key included in the certificate signing request can be used with a predetermined encryption algorithm, and fails if the public key included in the certificate signing request cannot be used with the predetermined encryption algorithm.

[0110] The second verification unit 30h also verifies whether or not device authorization session information (entry) including an access token exists. This verification is successful if device authorization session information including the access token is found (acquired from the device authorization session management unit 30d), and fails if device authorization session information including the access token is not found (acquired from the device authorization session management unit 30d).

[0111] If the above-mentioned verification of the certificate signing request or the access token fails, the certificate authority 30 returns an error to the edge device 10.

[0112] On the other hand, if the verification of the certificate signing request and the access token is successful, the certificate issuance unit 30i takes over processing from the second verification unit 30h and issues a public key certificate for the edge device 10 in response to the certificate signing request passed from the second verification unit 30h. When the public key certificate is issued by the certificate issuance unit 30i in this manner, issuance history information related to the issued public key certificate is managed by the issuance history management unit 30j. In addition, the public key certificate for the edge device 10 issued by the certificate issuance unit 30i is transmitted to the edge device 10 via the second communication unit 30b together with the user designation information included in the device authorization session information acquired from the device authorization session management unit 30d as described above (step S11).

[0113] Although the description here assumes that a public key certificate is issued when the certificate signing request and access token are successfully verified, the certificate issuing unit 30i may also issue a public key certificate based on issuance history information (the history of public key certificates issued in the past) managed by the issuance history management unit 30j.

[0114] 14 shows an example of the issuance history information. As shown in Fig. 14, 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 for identifying the edge device 10.

[0115] 14, the certificate issuing unit 30i 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 30j). 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.

[0116] If the certificate issuance unit 30i determines that a certificate for the same public key has been issued in the past, the certificate issuance unit 30i 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 30i may notify the edge device 10 via the second communication unit 30b that the certificate signing request has been discarded, or may notify the administrator of the certificate authority 30 of an alert.

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

[0118] When the registration unit 10h included in the edge device 10 receives the public key certificate and the user-specified information transmitted from the certificate authority 30 in step S11, the registration unit 10h registers the public key certificate in the edge device 10. The user-specified information may be managed (set) inside the edge device 10 (for example, in the device information management unit 10d, etc.). This completes the initial setting of the edge device 10.

[0119] 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 application server apparatus 40 (step S12). Note that in step S12, device authentication processing may be executed to confirm, for example, whether the public key certificate presented by the edge device 10 is a public key certificate that has been legitimately issued for the public key of the edge device 10.

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

[0121] 9, for example, the certificate signing request transmitted from the edge device 10 to the certificate authority 30 may be affixed with a digital signature generated using the private key of the edge device 10. When a digital signature is affixed to the certificate signing request in this way, the certificate signing request can be verified using the digital signature.

[0122] Similarly, the public key certificate transmitted from the certificate authority 30 to the edge device 10 may be affixed with a digital signature generated using the private key of the certificate authority 30. When a digital signature is affixed to the public key certificate in this way, the public key certificate can be verified using the digital signature.

[0123] As described above, the communication system 1 according to this embodiment transmits a device authorization request and device information from the edge device 10 (communication device) to the authentication authority 30, and in response to the device authorization request, transmits a verification URL (access information for accessing the authentication authority 30) and a user code and device code, which are associated with the device information and managed, from the authentication authority 30 to the edge device 10. The communication system 1 also transmits the verification URL and user code from the edge device 10 to the user terminal 20 (terminal apparatus), transmits the user code from the user terminal 20 to the authentication authority by the user terminal 20 accessing the authentication authority 30 based on the verification URL, and transmits device information, which is associated with the user code and managed, from the authentication authority 30 to the user terminal 20. Furthermore, the communication system 1 transmits the user code from the user terminal 20 to the authentication authority 30 based on the device information, to request issuance of an access token, and issues an access token, which is associated with the user code and managed in the authentication authority 30, based on the request from the user terminal 20. The communication system 1 also requests acquisition of an access token by transmitting a device code from the edge device 10 to the certificate authority 30, and transmits the access token, which is managed in association with the device code, from the certificate authority 30 to the edge device 10 based on the request from the edge device 10. Furthermore, the communication system 1 transmits a certificate signing request and an access token from the edge device 10 to the certificate authority 30, and issues a public key certificate in the certificate authority 30 based on the certificate signing request and the access token.

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

[0125] Furthermore, for example, in a configuration in which a public key certificate is simply issued between the edge device 10 and the certification authority 30, it is difficult for the certification authority 30 to determine whether or not it is able to issue a certificate. However, in this embodiment, by using the user terminal 20 (the user instructs the issuance of a public key certificate), it is possible to issue an appropriate public key certificate.

[0126] Here, with reference to FIG. 15, an example of a specific usage mode of the communication system 1 according to this embodiment will be described.

[0127] In FIG. 15, it is assumed that a lighting-integrated device is used as the edge device 10. The lighting-integrated device is a device that is built into lighting equipment installed in a building (facility). This lighting-integrated device is equipped with a sensor that outputs various sensor data. The sensor may be a measurement sensor that measures data such as temperature, humidity, illuminance, carbon dioxide concentration, or vibration, or an image sensor that captures images. The lighting-integrated device also has a function of controlling equipment in a building, for example. The equipment controlled by the lighting-integrated device may be lighting equipment that incorporates the lighting-integrated device, or air conditioning equipment installed in the building.

[0128] The above-described built-in lighting device transmits sensor data (measurement data) output from a sensor provided in the built-in lighting device to an application server apparatus 40 that provides a building management service. The building management service analyzes the sensor data transmitted from the built-in lighting device and controls the facility equipment in the building using the built-in lighting device based on the analysis results, thereby making it possible to maintain an appropriate environment in the building. Note that, in this case, communication between the built-in lighting device and the building management service is performed, for example, via a wired LAN wired inside the building.

[0129] As described above, a public key certificate for the built-in lighting device is required for communication between the building management service and the built-in lighting device. To issue this public key certificate for the built-in lighting device, an installation technician using user terminal 20 performs initial setup work after the building contractor installs the built-in lighting device inside the building together with the lighting equipment.

[0130] To explain the above-mentioned initial setting work in detail, first, the setting worker presses a predetermined button provided on the lighting equipment. This causes the lighting-integrated device to send a device authorization request to the certification authority 30. The certification authority 30 responds to the device authorization request sent from the lighting-integrated device and returns a verification URL, a user code, and a device code to the lighting-integrated device. Note that communication between the lighting-integrated device and the certification authority 30 is assumed to be performed, for example, via a wired LAN.

[0131] Next, the verification URL and user code must be transmitted (communicated) from the built-in lighting device to the user terminal 200, and in this case, visible light communication is used. Visible light communication in this case is realized by encoding data that combines the verification URL and the user code into the blinking timing of the lighting equipment, and controlling the lighting equipment (to turn on and off) according to the blinking timing.

[0132] A user terminal 20 (e.g., a smartphone) used by a setup worker acquires (receives) a verification URL and a user code transmitted (conveyed) from the lighting equipment via visible light communication. Furthermore, the user terminal 20 can communicate with the certification authority 30 by accessing the acquired verification URL. Note that the communication between the user terminal 20 and the certification authority 30 is performed, for example, via a mobile phone line.

[0133] In this case, the user terminal 20 transmits an access token issuance request and user-specified information to the authentication authority 30. The user-specified information may be, for example, location information of the lighting equipment (such as the building name, floor name, room name, and lighting position serial number).

[0134] Although detailed explanation will be omitted below, after the access token issued by the certification authority 30 is obtained by the lighting-integrated device, the lighting-integrated device sends a certificate signing request to the certification authority 30, and a public key certificate for the lighting-integrated device is issued by the certification authority 30.

[0135] In this embodiment, by utilizing a communication system 1 as shown in FIG. 15, for example, it is possible to easily issue an individual public key certificate for each built-in lighting device.

[0136] In addition, in the example shown in Figure 15, the lighting-integrated device performs processing related to initial setup (initial setup sequence) using a wired LAN and visible light communication, so there is no need to install a dedicated communication means for initial setup (for example, a function to perform communication based on Bluetooth), and it is possible to reduce the costs of the lighting-integrated device (edge ​​device 10) and the user terminal 20.

[0137] For example, if the lighting-integrated device is equipped with a small display, the verification URL and user code may be transmitted from the lighting-integrated device to the user terminal 20 by reading a QR code (a two-dimensional code in which the verification URL and user code are encoded) displayed on the display with the user terminal 20 (camera).

[0138] That is, in this embodiment, if the edge device 10 and the user terminal 20 are configured so that the above-mentioned verification URL and user code can be transmitted (communicated) between the edge device 10 and the user terminal 20, it is possible to realize the initial setting for issuing a certificate, but even if the edge device 10 and the user terminal 20 have the function of performing the above-mentioned Bluetooth-based communication, the process related to the initial setting described in this embodiment (i.e., the process shown in FIG. 9) may be executed. In such a configuration, it is possible to reduce the amount of communication between the edge device 10 and the user terminal 20.

[0139] In this embodiment, a configuration is provided in which it is determined whether the user using the user terminal 20 has the authority to issue a public key certificate for the edge device 10 based on device information managed in association with the user code sent from the user terminal 20 to the certification authority 30 and pre-prepared verification information, thereby making it possible to issue a public key certificate in response to a request from a legitimate user.

[0140] Furthermore, in this embodiment, the user terminal 20 presents the device information transmitted from the certificate authority 30 to the user who uses the user terminal 20, and an access token issuance request is transmitted from the user terminal 20 to the certificate authority 30 in accordance with instructions from the user to whom the device information has been presented. This configuration makes it possible to prevent a public key certificate of an edge device 10 that is not intended by the user from being issued.

[0141] Furthermore, in this embodiment, user-specified information is sent from the user terminal 20 to the certification authority 30 together with an access token issuance request, and when a public key certificate is issued, the user-specified information is sent from the certification authority 30 together with the public key certificate to the edge device 10. With this configuration, it becomes possible to easily set information specified by the user in the edge device 10 together with the public key certificate.

[0142] Although the description has been given here assuming that the user-specified information is transmitted from the certificate authority 30 to the edge device 10 together with the public key certificate, the information transmitted together with the public key certificate may be a part of the user-specified information, or may include part or all of the device information. Furthermore, a public key certificate including part or all of the device information and user-specified information described above may be transmitted from the certificate authority 30 to the edge device 10.

[0143] The user-specified information may be input (specified) by the user on the screen on which the device information is presented. This allows the information intended by the user to be registered in the edge device 10.

[0144] 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 components omitted or other components added.

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

[0146] In the first embodiment described above, the edge device sends a device authorization request to the certificate authority in the process related to the initial setting (initial setting sequence). However, if direct trust has not been established in advance between the edge device and the certificate authority, for example, the edge device may send false device information along with the device authorization request. In this case, the certificate authority may issue a certificate to an edge device that should not be issued a certificate, based on false device information.

[0147] Taking the above-mentioned circumstances into consideration, this embodiment differs from the first embodiment described above in that the certificate authority verifies that the device information sent from the edge device is legitimate (i.e., the authenticity of the device information) using a technique called attestation.

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

[0149] As shown in FIG. 16, the communication system 1 according to this embodiment further includes a verification server device 60 different from the application server device 40 in comparison with the first embodiment described above.

[0150] The verification server device 60 is communicably connected to the edge device 10 via the network 54, and is configured to execute the process of verifying the authenticity of the device information described above.

[0151] The validation server device 60 may be communicably connected to the edge device 10 via the network 52 or 53, for example.

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

[0153] Fig. 17 shows an example of the functional configuration of the edge device 10 in this embodiment. In Fig. 17, the same parts as those in Fig. 2 are given the same reference numerals, and detailed description thereof will be omitted.

[0154] 17, the edge device 10 further includes a fourth communication unit 10j, an attestation nonce acquisition unit 10k, a second key management unit 10l, and a third request generation unit 10m, as compared with the first embodiment. Note that in FIG. 17, the key management unit 10g shown in FIG. 4 is conveniently referred to as the first key management unit 10g in order to distinguish it from the second key management unit 10l.

[0155] The fourth communication unit 10j communicates with the validation server device 60 via the network 54. Although the fourth communication unit 10j is illustrated in FIG. 17 as a functional unit separate from the first communication unit 10a, the second communication unit 10b, and the third communication unit 10c, the fourth communication unit 10j may be realized as the same functional unit as at least one of the first communication unit 10a, the second communication unit 10b, and the third communication unit 10c. The communication method used by the fourth communication unit 10j to communicate may be different from or the same as the communication method used by the first communication unit 10a, the communication method used by the second communication unit 10b, and the communication method used by the third communication unit 10c.

[0156] The attestation nonce acquisition unit 10k requests the validation server device 60 to issue an attestation nonce via the fourth communication unit 10j, and acquires (receives) the attestation nonce sent from the validation server device 60 in response to the request. Note that the attestation nonce is a random number used only once (for example, a disposable random character string). The attestation nonce acquired by the attestation nonce acquisition unit 20k is passed from the attestation nonce acquisition unit 10k to the third request generation unit 10m.

[0157] In this embodiment, the second key management unit 10l 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 10l when the edge device 10 is manufactured (i.e., it is stored in advance in the edge device 10). The second key management unit 10l 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).

[0158] The third request generator 10m 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 manager 10d. In the following description, this digital signature will be referred to as the attestation signature.

[0159] The third request generation unit 10m generates a verification request including the device information, the attestation nonce, the attestation signature, and the attestation key ID. The verification request generated by the third request generation unit 10m is transmitted from the fourth communication unit 10j to the verification server device 60.

[0160] In addition, the second key management unit 10l is assumed to be located in hardware that, in principle, prevents data from being read or written from outside (except from the third request generation unit 10m). In other words, in this embodiment, the attestation key is managed so that it can only be used by the third request generation unit 10m (i.e., only the third request generation unit 10m can generate an attestation signature).

[0161] Fig. 18 shows an example of the functional configuration of the validation server device 60 shown in Fig. 16. As shown in Fig. 18, the validation 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 validation server key management unit 60f.

[0162] The communication unit 60a communicates with the edge device 10 via the network 54. The attestation nonce issuing unit 60b accepts a request (attestation nonce issuance request) from the edge device 10 via the communication unit 60a and issues (generates) an attestation nonce. The attestation nonce issuing unit 60b issues an attestation nonce with a different value for each edge device 10 that is the requestor of the attestation nonce issuance request.

[0163] The attestation nonce issued by the attestation nonce issuing unit 60b is transmitted to the edge device 10 via the communication unit 60a, and is also passed to the attestation nonce management unit 60c.

[0164] The attestation nonce management unit 60c manages the expiration date of the attestation nonce passed from the attestation nonce issuing unit 60b in association with the attestation nonce.

[0165] The attestation key management unit 60d manages attestation keys (particularly public keys for attestation) in association with the above-mentioned attestation key IDs.

[0166] The verification unit 60e acquires (receives) a verification request transmitted from the edge device 10 via the communication unit 60a. The verification unit 60e verifies the attestation nonce and attestation signature included in the verification request. In this case, the verification unit 60e refers to information managed by the attestation nonce management unit 60c and the attestation key management unit 60d.

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

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

[0169] As shown in FIG. 19, the certificate authority 30 further includes a third verification unit 30k and a request restriction unit 30l, as compared with the first embodiment described above.

[0170] The verification result by the validation server device 60 in this embodiment is transmitted from the validation server device 60 to the edge device 10, and is also transmitted (transferred) from the edge device 10 to the certificate authority 30. The third verification unit 30k verifies the verification result by the validation server device 60. It is assumed that the public key of the validation server device 60 is held (shared) in advance in the third verification unit 30k, and the verification result by the third verification unit 30k is verified using the public key of the validation server device 60.

[0171] The request limiting unit 30l monitors the frequency (reception frequency) of device authorization requests from the edge device 10, and limits the acceptance of the device authorization requests based on the monitoring results.

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

[0173] First, the attestation nonce acquisition unit 10k included in the edge device 10 requests the validation server device 60 to issue an attestation nonce via the fourth communication unit 10j. In this case, the attestation nonce issuance request is transmitted from the fourth communication unit 10j to the validation server device 60 (step S21).

[0174] The attestation nonce issuing unit 60b included in the validation 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 edge device 10 (step S22). The attestation nonce management unit 60c manages the attestation nonce issued by the attestation nonce issuing unit 60b (i.e., the attestation nonce transmitted to the edge device 10) together with an 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.

[0175] Here, the attestation nonce transmitted in the above-mentioned step S22 is acquired by the attestation nonce acquisition unit 10k via the fourth communication unit 10j. The attestation nonce acquired by the attestation nonce acquisition unit 10k is passed from the attestation nonce acquisition unit 10k to the third request generation unit 10m.

[0176] In this embodiment, before transmitting the device authorization request described in the first embodiment, the third request generation unit 10m generates a verification request. In this case, the third request generation unit 10m acquires device information managed by the device information management unit 10d from the device information management unit 10d, and acquires an attestation key ID and an attestation key managed by the second key management unit 10l from the second key management unit 10l. Using the attestation key acquired from the second key management unit 10l, the third request generation unit 10m generates an attestation signature for the device information acquired from the device information management unit 10d and the attestation nonce passed from the attestation nonce acquisition unit 10k. The attestation signature corresponds to a digital signature using the attestation key for the device information and the attestation nonce. The attestation signature is generated, for example, by performing cryptographic processing using the attestation key (a private key for attestation) on hash values ​​of the device information and the attestation nonce. The attestation signature generated in this manner is used to guarantee the authenticity of the device information.

[0177] The third request generation unit 10m generates a verification request including the device information, the attestation nonce, the attestation signature, and the attestation key ID. The verification request thus generated by the third request generation unit 10m is transmitted from the fourth communication unit 10j to the verification server device 60 (step S23).

[0178] Upon receiving the verification request transmitted from the edge device 10 in step S23, the verification unit 60e included in the verification server 60 verifies the contents of the verification request (for example, the attestation nonce and the attestation signature).

[0179] Specifically, for example, if the attestation nonce issued by the attestation nonce issuing unit 60b is associated with an expiration date and managed by the attestation nonce management unit 60c, the verification unit 60e checks whether the attestation nonce included in the verification request is managed by the attestation nonce management unit 60c and is valid (i.e., the expiration date of the attestation nonce has not expired). This verification of the attestation nonce is successful if the attestation nonce included in the verification request is managed by the attestation nonce management unit 60c and is valid.

[0180] Also, assuming that the attestation key (public key for attestation) is managed by the attestation key management unit 60d in association with the attestation key ID, the verification unit 60e acquires the public key for attestation managed by the attestation key management unit 60d in association with the attestation key ID included in the verification request, and verifies the attestation signature included in the verification request using the acquired public key for attestation. In this case, the verification unit 60e calculates a hash value of the device information and attestation nonce included in the verification request, and performs a process of comparing the calculated hash value with the result (hash value) of encrypting the attestation signature included in the verification request with the public key for attestation. This verification of the attestation signature is successful if the hash values ​​of the device information and attestation nonce match the hash value obtained from the attestation signature.

[0181] If the verification of the attestation nonce and attestation signature is successful, the verification unit 60e obtains the private key of the verification server device 60 managed by the verification server key management unit 60f, and generates a digital signature using the private key of the verification server device 60 for all data including the device information and the attestation nonce. Note that this digital signature is generated by performing cryptographic processing using the private key of the verification server device 60 on the hash values ​​of the device information and the attestation nonce. The data including the device information, the attestation nonce, and the digital signature (hereinafter referred to as verification result data) is transmitted from the communication unit 60a to the edge device 10 (step S24).

[0182] Upon receiving the verification result data transmitted from the verification server apparatus 60 in step S24, the third request generator 10m included in the edge device 10 passes the verification result data to the first request generator 10e.

[0183] The first request generation unit 10e generates a device authorization request. The device authorization request generated by the first request generation unit 10e is the same as that in the first embodiment, and therefore a detailed description thereof will be omitted here.

[0184] In this embodiment, the device authorization request generated by the first request generation unit 10e and the verification result data passed from the third request generation unit 10m to the first request generation unit 10e are transmitted from the second communication unit 10b to the certification authority 30 (step S25).

[0185] Upon receiving the device authorization request and the verification result data transmitted from the edge device 10 in step S25, the device authorization request processing unit 30c included in the certificate authority 30 passes the verification result data to the third verification unit 30k.

[0186] The third verification unit 30k verifies the verification result data passed from the device authorization request processing unit 30c. Specifically, assuming that the third verification unit 30k previously holds the public key of the verification server device 60 (a public key paired with the private key of the verification server device 60), the third verification unit 30k verifies the digital signature included in the verification result data using the public key of the verification server device 60. In verifying the digital signature, a process is executed in which a hash value of the device information and the attestation nonce included in the verification result data is calculated, and the calculated hash value is compared with the result (hash value) of encrypting the digital signature included in the verification result data with the public key of the verification server device 60. The digital signature verification is successful when the hash values ​​of the device information and the attestation nonce included in the verification result data match the hash value obtained from the digital signature.

[0187] If the verification of the digital signature fails, the certificate authority 30 returns an error to the edge device 10.

[0188] Here, in this embodiment, as described above, the authenticity of device information can be verified using the attestation nonce. However, if, for example, a malicious user sends a large number of device authorization requests to the certification authority 30 from multiple edge devices 10, this may exhaust the resources of the certification authority 30 (for example, communication bandwidth, computing power, or memory area), potentially causing the service at the certification authority 30 to be suspended.

[0189] For this reason, the request limiting unit 30l checks the frequency of device authorization requests transmitted from the edge device 10 (i.e., acquired by the device authorization request processing unit 30c), and limits acceptance of the device authorization requests (i.e., determines whether to accept them) according to the frequency of the device authorization requests. In this case, the request limiting unit 30l tallies (the number of) device authorization requests acquired by the device authorization request processing unit 30c, for example, and determines whether the frequency of the device authorization requests exceeds (exceeds) an upper limit.

[0190] Specifically, the device authorization request processing unit 30c allows acceptance of a device authorization request if the frequency of the device authorization request is equal to or less than the upper limit, and denies acceptance of the device authorization request if the frequency of the device authorization request is greater than the upper limit.

[0191] There are various possible methods for counting device authorization requests. For example, by referring to device information included in verification result data transmitted from the edge device 10 together with the device authorization request, if all or part of the manufacturer, model, and serial number included in the device information match, the device authorization request is counted as a device authorization request from the same edge device 10. In this case, the number of device authorization requests thus counted is divided by a certain time interval to obtain a value that is the frequency of device authorization requests, and the frequency of device authorization requests is compared with the upper limit.

[0192] The upper limit value to be compared with the frequency of device authorization requests may be set (managed) in advance, but a different value may be set (managed) based on all or part of the manufacturer, model, and serial number (i.e., depending on the aggregation unit of device authorization requests).

[0193] If the verification of the digital signature included in the verification result data is successful and the acceptance of the device authorization request is permitted, the device authorization request processing unit 30c issues a verification URL, a user code, and a device code, as described in the first embodiment.

[0194] If the verification of the digital signature included in the verification result data fails or if the acceptance of the device authorization request is rejected, the device authorization request is discarded and an error is returned to the edge device 10.

[0195] After the verification URL, user code, and device code are issued by the device authorization request processing unit 30c as described above, the processes of steps S26 to S37, which correspond to the processes of steps S2 to S13 shown in FIG. 9, are executed.

[0196] As described above, in this embodiment, similar to the first embodiment described above, it is possible to easily issue a public key certificate to an edge device 10 in a factory-shipped state, and by verifying the attestation nonce and the attestation signature, it is possible to realize a highly reliable communication system 1.

[0197] Furthermore, in this embodiment, by restricting the acceptance of device authorization requests based on the determination result of whether the frequency of the device authorization requests exceeds an upper limit, it is possible to prevent a malicious user from suspending the services of the certification authority 30, thereby realizing a more reliable communication system 1.

[0198] In the present embodiment, the device authorization request is discarded if the verification of the digital signature included in the verification result data fails. However, for example, if the verification of the digital signature included in the verification result data fails (i.e., if the verification result data is invalid), the upper limit value compared with the frequency of device authorization requests may be lowered (i.e., a strict reception frequency limit may be imposed on the device authorization request) to determine whether to accept the device authorization request. Also, if the verification of the digital signature included in the verification result data is successful (i.e., if the verification result data is valid), the device authorization request may be accepted unconditionally without determining whether to accept the device authorization request (i.e., without imposing a reception frequency limit on the device authorization request). That is, in the present embodiment, the upper limit value compared with the frequency of device authorization requests may be varied based on, for example, the verification result of the digital signature included in the verification result data.

[0199] Furthermore, in this embodiment, the verification of the attestation nonce and the attestation signature has been described as being performed by the verification server device 60, but at least a part of the processing described as being performed by the verification server device 60 may be performed by, for example, the certification authority 30 or another device.

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

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

[0202] 1...communication system, 10...edge device (communication device), 10a...first communication unit, 10b...second communication unit, 10c...third communication unit, 10d...device information management unit, 10e...first request generation unit, 10f...second request generation unit, 10g...key management unit (first key management unit), 10h...registration unit, 10i...application processing unit, 10j...fourth communication unit, 10k...attestation nonce acquisition unit, 10l...second key management unit, 10m...third request generation unit, 20...user terminal (terminal device), 20a...first communication unit, 20b...second communication unit, 20c...verification URL reading unit, 20d...user information management unit, 20e...server information management unit, 20f...request generation unit, 30...certification authority, 30a...first communication unit, 30b...second Communication unit, 30c...device authorization request processing unit, 30d...device authorization session management unit, 30e...verification information management unit, 30f...first verification unit, 30g...access token issuing unit, 30h...second verification unit, 30i...certificate issuing unit, 30j...issuance history management unit, 30k...third verification unit, 30l...request restriction unit, 40...application server device, 51, 52, 53, 54...network, 60...verification 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, a first transmitting means for transmitting a device authorization request requesting authorization of the communication device and device information related to the communication device from the communication device to the certificate authority; a second transmitting means for transmitting, in response to the device authorization request, access information for accessing the certificate authority, and a user code and a device code managed in association with the device information, from the certificate authority to the communication device; a third transmitting means for transmitting the access information and the user code from the communication device to the terminal device; a fourth transmitting means for transmitting the user code from the terminal device to the certification authority by the terminal device accessing the certification authority based on the access information; a fifth transmitting means for transmitting device information managed in association with the user code from the certificate authority to the terminal device; a first request means for requesting issuance of an access token by transmitting the user code from the terminal device to the certificate authority based on the device information; a first issuing means for issuing an access token managed in the certificate authority in association with the user code based on a request from the terminal device; a second request means for requesting acquisition of an access token by transmitting the device code from the communication device to the certificate authority; a sixth transmitting means for transmitting an access token, which is managed in association with the device code, from the certificate authority to the communication device in response to a request from the communication device; a seventh transmitting means for transmitting, from the communication device to the certificate authority, a certificate signing request for requesting issuance of a certificate used for the communication device to communicate with an application server device, and the access token; a second issuing means for issuing the certificate in the certificate authority based on the certificate signing request and the access token; A communication system comprising:

2. The communication system according to claim 1, wherein the certification authority includes a determination means for determining whether a user using the terminal device has the authority to issue the certificate based on device information managed in association with a user code transmitted from the terminal device to the certification authority and on verification information prepared in advance.

3. the terminal device includes a presentation means for presenting the device information transmitted from the certificate authority to the terminal device to a user who uses the terminal device; The first request means requests issuance of the access token in accordance with an instruction from a user to whom the device information is presented. The communication system of claim 1.

4. the first request means transmits user-specified information specified by a user who uses the terminal device to the certificate authority when requesting issuance of the access token; the certificate authority includes an eighth transmitting means for, when the certificate is issued, transmitting the device information and part or all of the user-specified information to the communication device together with the issued certificate.

4. The communication system according to claim 3.

5. the first request means transmits user-specified information specified by a user who uses the terminal device to the certificate authority when requesting issuance of the access token; the certificate authority includes an eighth transmitting means for transmitting a certificate including the device information and part or all of the user-specified information to the communication device when the certificate is issued.

4. The communication system according to claim 3.

6. 6. The communication system according to claim 4, wherein the user-specified information is input by the user on a screen on which the device information is presented.

7. A verification server device is further provided, the communications device includes a ninth transmitting means for transmitting, from the communications device to the validation server apparatus, a verification request including the device information, 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 communications device; the verification server device includes a verification unit that verifies the digital signature included in the verification request by using an attestation public key that is a pair with the attestation private key; The second issuing means issues the certificate based on the verification result by the verifying means. The communication system of claim 1.

8. 2. The communication system according to claim 1, wherein the certificate authority includes a limiting means for limiting acceptance of device authorization requests based on a determination result of whether the frequency of device authorization requests sent from the communication device to the certificate authority exceeds an upper limit value.

9. 9. The communication system according to claim 8, wherein the limiting means manages the upper limit in association with the device information, and counts the frequency of device authorization requests sent from a communication device identified by the device information.

10. further comprising an authentication processing means for executing an authentication process for a user who uses the terminal device between the terminal device and the certification authority; The fourth transmitting means transmits the user code when the user is authenticated by executing the authentication process. A communication system according to any one of claims 1 to 9.

11. A terminal device used to issue a certificate used for a communication device to communicate with an application server device, a first receiving means for receiving, when a device authorization request requesting authorization of the communication device and device information related to the communication device are transmitted from the communication device to an authentication authority, access information for accessing the authentication authority and a user code and a device code managed in association with the device information are transmitted from the authentication authority to the communication device; a transmitting means for accessing the certificate authority based on the access information and transmitting the user code to the certificate authority; a second receiving means for receiving, from the certificate authority, device information managed in association with the user code; a requesting means for requesting issuance of an access token by transmitting the user code to the authentication authority based on the device information; Equipped with the certificate authority issues an access token managed in association with the user code in response to a request from the terminal device; the communication device requests an access token by transmitting the device code to the certificate authority; the certificate authority transmits an access token managed in association with the device code to the communication device in response to a request from the communication device; the communication device transmits a certificate signing request requesting issuance of the certificate and the access token to the certificate authority; The certificate authority issues the certificate based on the certificate signing request and the access token. Terminal device.

12. A communication device configured to communicate with an application server device, comprising: a first transmitting means for transmitting a device authorization request requesting authorization of the communication device and device information related to the communication device to an authentication authority; a first receiving means for receiving, when the device authorization request and the device information are transmitted from the communication device to the certificate authority, access information for accessing the certificate authority and a user code and a device code managed in association with the device information from the certificate authority; a second transmitting means for transmitting the access information and the user code to a terminal device; a second receiving means for receiving, from the authentication authority, an access token managed in association with the device code by transmitting the device code to the authentication authority to request acquisition of the access token; a third transmitting means for transmitting to the certificate authority a certificate signing request for requesting issuance of a certificate used for the communication device to communicate with the application server device, and the access token; Equipped with the terminal device accesses the certification authority based on the access information, thereby transmitting the user code to the certification authority; the certificate authority transmits device information managed in association with the user code to the terminal device; the terminal device requests issuance of an access token by transmitting the user code to the certificate authority based on the device information; the access token is issued by the certificate authority in response to a request from the terminal device, and is managed in association with the user code; The certificate authority issues the certificate based on the certificate signing request and the access token. Communication devices.

13. A certificate authority that issues a certificate used by a communication device to communicate with an application server device, a first receiving means for receiving a device authorization request requesting authorization of the communication device and device information related to the communication device from the communication device; a first transmitting means for transmitting, in response to the device authorization request, access information for accessing the certificate authority, and a user code and a device code that are managed in association with the device information, to the communication device; a second transmission means for transmitting, to the terminal device, device information managed in association with the user code transmitted from the terminal device by the terminal device accessing the authentication authority based on access information transmitted from the communication device; a first issuing means for issuing an access token managed in association with the user code when issuance of the access token is requested by the user code being transmitted from the terminal device based on the device information; a third transmission means for transmitting, when the device code is transmitted from the communication device and acquisition of an access token is requested, an access token managed in association with the device code to the communication device; a second receiving means for receiving a certificate signing request requesting issuance of the certificate and the access token from the communication device; a second issuing means for issuing the certificate based on the certificate signing request and the access token; 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: sending a device authorization request requesting authorization of the communication device and device information about the communication device from the communication device to the certificate authority; transmitting, in response to the device authorization request, access information for accessing the certificate authority, and a user code and a device code that are managed in association with the device information, from the certificate authority to the communication device; transmitting the access information and the user code from the communication device to the terminal device; a step of transmitting the user code from the terminal device to the certification authority by the terminal device accessing the certification authority based on the access information; transmitting device information managed in association with the user code from the certificate authority to the terminal device; a step of requesting issuance of an access token by transmitting the user code from the terminal device to the certificate authority based on the device information; issuing an access token managed in association with the user code in the certificate authority based on a request from the terminal device; transmitting the device code from the communication device to the certificate authority to request an access token; transmitting an access token managed in association with the device code from the certificate authority to the communication device based on a request from the communication device; transmitting, from the communication device to the certificate authority, a certificate signing request for requesting issuance of a certificate used for the communication device to communicate with an application server device, and the access token; issuing the certificate at the certificate authority based on the certificate signing request and the access token; A method comprising:

15. 1. A method executed by a terminal device used to issue a certificate used by a communication device to communicate with an application server device, comprising: receiving, from the communication device, a device authorization request requesting authorization of the communication device and device information related to the communication device to an authentication authority, whereby access information for accessing the authentication authority and a user code and a device code managed in association with the device information are transmitted from the authentication authority to the communication device; transmitting the user code to the certificate authority by accessing the certificate authority based on the access information; receiving device information managed in association with the user code from the certificate authority; requesting issuance of an access token by transmitting the user code to the certificate authority based on the device information; Equipped with the certificate authority issues an access token managed in association with the user code in response to a request from the terminal device; the communication device requests an access token by transmitting the device code to the certificate authority; the certificate authority transmits an access token managed in association with the device code to the communication device in response to a request from the communication device; the communication device transmits a certificate signing request requesting issuance of the certificate and the access token to the certificate authority; The certificate authority issues the certificate based on the certificate signing request and the access token. method.

16. 1. A method performed by a communication device configured to communicate with an application server device, comprising: sending a device authorization request requesting authorization of the communication device and device information regarding the communication device to an authentication authority; receiving, when the device authorization request and the device information are transmitted from the communication device to the certificate authority, access information for accessing the certificate authority and a user code and a device code managed in association with the device information from the certificate authority; transmitting the access information and the user code to a terminal device; transmitting the device code to the certificate authority to request acquisition of an access token, and receiving, from the certificate authority, an access token managed in association with the device code; sending a certificate signing request to the certificate authority to request issuance of a certificate used by the communication device to communicate with the application server device, and the access token; Equipped with the terminal device accesses the certification authority based on the access information, thereby transmitting the user code to the certification authority; the certificate authority transmits device information managed in association with the user code to the terminal device; the terminal device requests issuance of an access token by transmitting the user code to the certificate authority based on the device information; the access token is issued by the certificate authority in response to a request from the terminal device, and is managed in association with the user code; The certificate authority issues the certificate based on the certificate signing request and the access token. method.

17. 1. A method performed by a certificate authority that issues a certificate used by a communication device to communicate with an application server device, comprising: receiving a device authorization request requesting authorization for the communication device and device information regarding the communication device from the communication device; transmitting, in response to the device authorization request, access information for accessing the certificate authority, and a user code and a device code that are managed in association with the device information, to the communication device; a step of transmitting, to the terminal device, device information managed in association with the user code transmitted from the terminal device by the terminal device accessing the authentication authority based on access information transmitted from the communication device; when issuance of an access token is requested by transmitting the user code from the terminal device based on the device information, issuing an access token managed in association with the user code; When the device code is transmitted from the communication device to request acquisition of an access token, transmitting an access token managed in association with the device code to the communication device; receiving a certificate signing request requesting issuance of the certificate and the access token from the communication device; issuing the certificate based on the certificate signing request and the access token; A method comprising:

Images